draft-ietf-tsvwg-dscp-considerations-01.txt   draft-ietf-tsvwg-dscp-considerations-02.txt 
TSVWG A. Custura TSVWG A. Custura
Internet-Draft G. Fairhurst Internet-Draft G. Fairhurst
Intended status: Informational R. Secchi Intended status: Informational R. Secchi
Expires: 28 July 2022 University of Aberdeen Expires: 13 November 2022 University of Aberdeen
24 January 2022 12 May 2022
Considerations for Assigning a new Recommended DiffServ Codepoint (DSCP) Considerations for Assigning a new Recommended DiffServ Codepoint (DSCP)
draft-ietf-tsvwg-dscp-considerations-01 draft-ietf-tsvwg-dscp-considerations-02
Abstract Abstract
This document discusses considerations for assigning a new This document discusses considerations for assigning a new
recommended DiffServ Code Point (DSCP). It considers the common recommended DiffServ Code Point (DSCP). It considers the common
remarking behaviours that the Diffserv field might be subjected to remarking pathologies that the DiffServ field might be subjected to
along an Internet path. It also notes some implications of using a along an Internet path. It also notes some implications of using a
specific DSCP. specific DSCP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 July 2022. This Internet-Draft will expire on 13 November 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Current usage of DSCPs . . . . . . . . . . . . . . . . . . . 4 3. Current usage of DSCPs . . . . . . . . . . . . . . . . . . . 4
3.1. IP-Layer Semantics . . . . . . . . . . . . . . . . . . . 4 3.1. IP-Layer Semantics . . . . . . . . . . . . . . . . . . . 4
3.2. Network Control Traffic . . . . . . . . . . . . . . . . . 5 3.2. Network Control Traffic . . . . . . . . . . . . . . . . . 5
4. Remarking the DSCP . . . . . . . . . . . . . . . . . . . . . 5 4. Remarking the DSCP . . . . . . . . . . . . . . . . . . . . . 6
4.1. Bleaching the DSCP Field . . . . . . . . . . . . . . . . 6 4.1. Bleaching the DSCP Field . . . . . . . . . . . . . . . . 7
4.2. IP Type of Service manipulations . . . . . . . . . . . . 6 4.2. IP Type of Service manipulations . . . . . . . . . . . . 7
4.2.1. Impact of ToS Precedence Bleaching . . . . . . . . . 7 4.2.1. Impact of ToS Precedence Bleaching . . . . . . . . . 7
4.2.2. Impact of ToS Precedence Remarking . . . . . . . . . 7 4.2.2. Impact of ToS Precedence Remarking . . . . . . . . . 9
4.3. Remarking to a Particular DSCP . . . . . . . . . . . . . 8 4.3. Remarking to a Particular DSCP . . . . . . . . . . . . . 9
5. Interpretation of the IP DSCP at Lower Layers . . . . . . . . 8 5. Interpretation of the IP DSCP at Lower Layers . . . . . . . . 10
5.1. Mapping Specified for IEEE 802 . . . . . . . . . . . . . 8 5.1. Mapping Specified for IEEE 802 . . . . . . . . . . . . . 10
5.1.1. Mapping Specified for IEEE 802.1 . . . . . . . . . . 8 5.1.1. Mapping Specified for IEEE 802.1 . . . . . . . . . . 10
5.1.2. Mapping Specified for IEEE 802.11 . . . . . . . . . . 9 5.1.2. Mapping Specified for IEEE 802.11 . . . . . . . . . . 10
5.2. Mappings Specified for MPLS . . . . . . . . . . . . . . . 10 5.2. DiffServ and MPLS . . . . . . . . . . . . . . . . . . . . 12
5.2.1. Mappings Specified for MPLS . . . . . . . . . . . . . 11 5.2.1. Mapping Specified for MPLS . . . . . . . . . . . . . 12
5.2.2. Mappings Specified for MPLS Short Pipe . . . . . . . 11 5.2.2. Mapping Specified for MPLS Short Pipe . . . . . . . . 12
5.3. Mapping Specified for Mobile Networks . . . . . . . . . . 12 5.3. Mapping Specified for Mobile Networks . . . . . . . . . . 13
5.4. Mappings Specified for Carrier Ethernet . . . . . . . . . 13 5.4. Mapping Specified for Carrier Ethernet . . . . . . . . . 14
5.5. Remarking as a Side-effect of Another Policy . . . . . . 13 5.5. Remarking as a Side-effect of Another Policy . . . . . . 14
5.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Considerations for DSCP Selection . . . . . . . . . . . . . . 14 6. Considerations for DSCP Selection . . . . . . . . . . . . . . 15
6.1. Effect of Bleaching . . . . . . . . . . . . . . . . . . . 14 6.1. Effect of Bleaching . . . . . . . . . . . . . . . . . . . 15
6.2. Where the proposed DSCP > 0x07 (7) . . . . . . . . . . . 14 6.2. Where the proposed DSCP > 0x07 (7) . . . . . . . . . . . 15
6.3. Where the proposed DSCP < 0x07 (7) . . . . . . . . . . . 14 6.3. Where the proposed DSCP < 0x07 (7) . . . . . . . . . . . 15
6.3.1. Where the proposed DSCP&&0x07=0x01 . . . . . . . . . 14 6.3.1. Where the proposed DSCP&0x07=0x01 . . . . . . . . . . 15
6.4. Impact on deployed infrastructure . . . . . . . . . . . . 15 6.4. Impact on deployed infrastructure . . . . . . . . . . . . 16
6.5. Questions to guide discussion of a proposed new DSCP . . 15 6.5. Questions to guide discussion of a proposed new DSCP . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 19 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 21
Appendix B. Table of DSCP Values . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Appendix C. Example of operational practice and operator
requirements. . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The Differentiated Services (DiffServ) architecture has been deployed The Differentiated Services (DiffServ) architecture has been deployed
in many networks. It provides differentiated traffic forwarding in many networks. It provides differentiated traffic forwarding
based on the value of the Diffserv field [RFC2474] carried in the IP based on the DiffServ Code Point (DSCP) [RFC2474] carried in the
packet header. DiffServ field [RFC2474] of the IP packet header.
Internet traffic can be associated with a service class, and Internet traffic can be associated with a service class, and
categorised into Behavior Aggregates [RFC4594]. In IP networks, categorised into Behavior Aggregates [RFC4594]. In IP networks,
these are associated with a DiffServ Code Point (DSCP) [RFC2474]. these are associated with a DSCP. Each DSCP is mapped to a Per Hop
Each DSCP is mapped to a Per Hop Behaviour (PHB). A treatment Behaviour (PHB). A treatment aggregate is concerned only with the
aggregate is concerned only with the forwarding treatment of the forwarding treatment of the aggregated traffic, which could be mapped
aggregated traffic, which could be marked with multiple DSCPs from a set of DSCP values [RFC5127]. Treatment differentiation can
[RFC5127]. Treatment differentiation can be realised using a variety be realised using a variety of schedulers and queues, and also by
of schedulers and queues, and also by algorithms that implement algorithms that implement access to the physical media.
access to the physical media.
Application -> Service Application -> Service
Traffic Class Traffic Class
| |
Behavior -> DiffServ -> Per Hop Behavior -> DiffServ -> Per Hop
Aggregate Codepoint Behavior Aggregate Codepoint Behavior
| |
Treatment -> Schedule Treatment -> Schedule
Aggregate Queue, Drop Aggregate Queue, Drop
Figure showing the role of DSCPs in classifying IP traffic for Figure showing the role of DSCPs in classifying IP traffic for
differential network treatment. differential network treatment.
This document discusses considerations for assigning a new DSCP. It This document discusses considerations for assigning a new DSCP. It
considers some commonly observed DSCP remarking behaviours that might considers some commonly observed DSCP remarking pathologies that
be experienced along an Internet path. It also describes some packet might be experienced along an Internet path. It also describes some
forwarding treatments that a packet with a specific DSCP can expect packet forwarding treatments that a packet with a specific DSCP can
to receive when forwarded across a link or subnetwork. expect to receive when forwarded across a link or subnetwork.
The document is motivated by new opportunities to use DiffServ end- The document is motivated by new opportunities to use DiffServ end-
to-end across multiple domains, such as [I-D.ietf-tsvwg-nqb], to-end across multiple domains, such as [I-D.ietf-tsvwg-nqb],
proposals to build mechanisms using DSCPs in other standards-setting proposals to build mechanisms using DSCPs in other standards-setting
organisations, and the desire to use a common set of DSCPs across a organisations, and the desire to use a common set of DSCPs across a
range of infrastructure (e.g., [RFC8622], [I-D.ietf-tsvwg-nqb], range of infrastructure (e.g., [RFC8622], [I-D.ietf-tsvwg-nqb],
[I-D.learmonth-rfc1226-bis]). [I-D.learmonth-rfc1226-bis]).
2. Requirements Language 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
DSCPs are specified in the IANA registry [DSCP-registry] where a
variety of different formats are described. A DSCP can sometimes
referred to by name, such as "CS1", and sometimes by a decimal, hex,
or binary value. Hex values will be represented in text using prefix
0x. Binary values will use prefix 0b.
3. Current usage of DSCPs 3. Current usage of DSCPs
This section describes current usage of DSCPs. This section describes current usage of DSCPs.
3.1. IP-Layer Semantics 3.1. IP-Layer Semantics
The DiffServ architecture specifies use of the Diffserv field in the The DiffServ architecture specifies use of the DiffServ field in the
IPv4 and IPv6 packet headers to carry one of 64 distinct DSCP values. IPv4 and IPv6 packet headers to carry one of 64 distinct DSCP values.
Within a given administrative boundary, each DSCP value can be mapped Within a given administrative boundary, each DSCP value can be mapped
to a distinct PHB[RFC2474]. When a new PHB is standardized, a to a distinct PHB [RFC2474]. When a new PHB is standardized, a
recommended DSCP value among those 64 values is normally reserved for recommended DSCP value among those 64 values is normally reserved for
that PHB. that PHB, and is assigned by IANA.
The DSCP space is divided into three pools for the purpose of The DSCP space is divided into three pools for the purpose of
assignment and management [DSCP-registry]. The pools are defined in assignment and management [DSCP-registry]. This use of the pools can
the following table (where 'x' refers to either a bit position with be summnarised in a table (where 'x' refers to either a bit position
value '0' or '1'). with value '0' or '1').
DSCP Pool 1 A pool of 32 codepoints with a format 0bxxxxx0, to be DSCP Pool 1: A pool of 32 codepoints with a format 0bxxxxx0, to be
assigned by IANA Standards Action [RFC8126]. assigned by IANA Standards Action [RFC8126].
DSCP Pool 2 A pool of 16 codepoints with a format 0bxxxx11, reserved DSCP Pool 2: A pool of 16 codepoints with a format 0bxxxx11,
for experimental or local (private) use by network operators (see reserved for experimental or local (private) use by network
sections 4.1 and 4.2 of [RFC8126]. operators (see sections 4.1 and 4.2 of [RFC8126].
DSCP Pool 3 A pool of 16 codepoints with a 0bxxxx01. This was DSCP Pool 3: A pool of 16 codepoints with a 0bxxxx01. This was
initially available for experimental or local use, but which was initially available for experimental or local use, but which was
originally specified to be preferentially utilised for originally specified to be preferentially utilised for
standardized assignments if Pool 1 is ever exhausted. Pool 3 standardized assignments if Pool 1 is ever exhausted. Pool 3
codepoints are now utilised for standardized assignments and are codepoints are now utilised for standardized assignments and are
no longer available for experimental or local use [RFC8436]. no longer available for experimental or local use [RFC8436].
The DSCP space is shown in the following Figure.
+---------+-------+----------+-----+----------+-----+----------+-----+
| 56/CS7 | 57 | 58 | 59 | 60 | 61 | 62 | 63 |
+---------+-------+----------+-----+----------+-----+----------+-----+
| 48/CS6 | 49 | 50 | 51 | 52 | 53 | 54 | 55 |
+---------+-------+----------+-----+----------+-----+----------+-----+
| 40/CS5 | 41 | 42 | 43 | 44/VA | 45 | 46/EF | 47 |
+---------+-------+----------+-----+----------+-----+----------+-----+
| 32/CS4 | 33 | 34/AF41 | 35 | 36/AF42 | 37 | 38/AF43 | 39 |
+---------+-------+----------+-----+----------+-----+----------+-----+
| 24/CS3 | 25 | 26/AF31 | 27 | 28/AF32 | 29 | 30/AF33 | 31 |
+---------+-------+----------+-----+----------+-----+----------+-----+
| 16/CS2 | 17 | 18/AF21 | 19 | 20/AF22 | 21 | 22/AF23 | 23 |
+---------+-------+----------+-----+----------+-----+----------+-----+
| 8/CS1 | 9 | 10/AF11 | 11 | 12/AF12 | 13 | 14/AF13 | 15 |
+---------+-------+----------+-----+----------+-----+----------+-----+
| 0/CS0 | 1/LE | 2 | 3 | 4 | 5 | 6 | 7 |
+---------+-------+----------+-----+----------+-----+----------+-----+
Figure showing the current list of assigned DSCPs and their assigned
PHBs.
The DiffServ architecture allows forwarding treatments to be The DiffServ architecture allows forwarding treatments to be
associated with each DSCP, and the RFC series describes some of these associated with each DSCP, and the RFC series describes some of these
as PHBs. Although DSCPs are intended to identify specific treatment as PHBs. Although DSCPs are intended to identify specific treatment
requirements, multiple DSCPs might also be mapped (aggregated) to the requirements, multiple DSCPs might also be mapped (aggregated) to the
same forwarding treatment. Several IP standards map treatment same forwarding treatment. Several IP standards map treatment
aggregates to DSCPs, that might result in remarking: RFC5160 aggregates to DSCPs, that might result in remarking: RFC5160
[RFC5160] suggests Meta-QoS-Classes to help enable deployment of [RFC5160] suggests Meta-QoS-Classes to help enable deployment of
standardized end-to-end QoS classes. standardized end-to-end QoS classes.
Note: A DSCP is sometimes referred to by name, such as "CS1", and
sometimes by a decimal, hex, or binary value [DSCP-registry].
3.2. Network Control Traffic 3.2. Network Control Traffic
Network Control Traffic is defined as packet flows that are essential Network Control Traffic is defined as packet flows that are essential
for stable operation of the administered network (see [RFC4594], for stable operation of the administered network (see [RFC4594],
Section 3). This traffic is marked using a set of Class Selector Section 3). This traffic is marked with a value from a set of Class
(CS) DSCPs. Such network control traffic is often a special case Selector (CS) DSCPs. This traffic is often a special case within a
within a provider network, and ingress traffic with these DSCP provider network, and ingress traffic with these DSCP markings can be
markings can be remarked. remarked.
DSCP CS2 is recommended for the OAM (Operations, Administration, and DSCP CS2 is recommended for the OAM (Operations, Administration, and
Maintenance) service class (see [RFC4594], Section 3.3). Maintenance) service class (see [RFC4594], Section 3.3).
The DSCP CS6 is recommended for local network control traffic. This DSCP CS6 is recommended for local network control traffic. This
includes routing protocols and OAM traffic that are essential to includes routing protocols and OAM traffic that are essential to
network operation administration, control and management. network operation administration, control and management.
Section 3.2 of RFC4594 [RFC4594] recommends that "CS6 marked packet Section 3.2 of RFC4594 [RFC4594] recommends that "CS6 marked packet
flows from untrusted sources (for example, end user devices) SHOULD flows from untrusted sources (for example, end user devices) SHOULD
be dropped or remarked at ingress to the DiffServ network". be dropped or remarked at ingress to the DiffServ network".
DSCP CS7 is reserved for future use by network control traffic. "CS7 DSCP CS7 is reserved for future use by network control traffic. "CS7
marked packets SHOULD NOT be sent across peering points" [RFC4594]. marked packets SHOULD NOT be sent across peering points" [RFC4594].
At the time of writing, there is evidence to suggest CS6 is actively
used by network operators for control traffic. A study of traffic at
a large Internet Exchange showed around 40% of ICMP traffic carried
this mark [IETF113DSCP]. Similarly, another study found many routers
remark all traffic except those packets with a DSCP that sets the
higher order bits to 0b11 (see Section 4 of this document).
4. Remarking the DSCP 4. Remarking the DSCP
It is a feature of the DiffServ architecture that the Diffserv field It is a feature of the DiffServ architecture that the DiffServ field
of packets can be remarked at domain boundaries (see section 2.3.4.2 of packets can be remarked at domain boundaries (see section 2.3.4.2
of RFC2475 [RFC2475]). A DSCP can be remarked at the ingress of a of RFC2475 [RFC2475]). A DSCP can be remarked at the ingress of a
DiffServ domain. This can be with or without restoring the initial DiffServ domain. This remarking can change the DSCP value used on
DSCP marking at the egress of the same domain. The Diffserv field the remainder of an IP path, or the network can restore the initial
can also be re-marked based upon common semantics and agreements DSCP marking at the egress of the domain. The DiffServ field can
between providers at an exchange point. also be remarked based upon common semantics and agreements between
providers at an exchange point. Furthermore, RFC 2475 states that
remarking must occur when there is a possibility of theft/denial-of-
service attack.
If packets are received that are marked with an unknown or an If packets are received that are marked with an unknown or an
unexpected DSCP, RFC2474 [RFC2474] recommends forwarding the packet unexpected DSCP, RFC2474 [RFC2474] recommends forwarding the packet
using a default (best effort) treatment, but without changing the using a default (best effort) treatment, but without changing the
DSCP. This seeks to support incremental DiffServ deployment in DSCP. This seeks to support incremental DiffServ deployment in
existing networks as well as preserving DSCP markings by routers that existing networks as well as preserve DSCP markings by routers that
have not been configured to support DiffServ. (See also have not been configured to support DiffServ. (See also
Section 4.3). Section 4.3). RFC3260 [RFC3260] clarifies that this remarking
specified by RFC2474 is intended for interior nodes within a DiffServ
domain. For DiffServ ingress nodes the traffic conditioning required
by RFC 2475 applies first.
Reports measuring existing deployments have categorised DSCP Reports measuring existing deployments have categorised DSCP
remarking [Custura] [Barik] into the following five behaviours: remarking [Custura] [Barik] into the following seven remarking
pathologies:
Bleach: bleaches all traffic (sets the DSCP to zero); Bleach: bleaches all traffic (sets the DSCP to zero);
Bleach-ToS-Precedence: set the first three bits of the DSCP field to Bleach-ToS-Precedence: set the first three bits of the DSCP field to
0b000 (reset the 3 bits of the former ToS Precedence field) ; 0b000 (reset the 3 bits of the former ToS Precedence field) ;
Bleach-some-ToS: set the first three bits of the DSCP field to 0b000 Bleach-some-ToS: set the first three bits of the DSCP field to 0b000
(reset the 3 bits of the former ToS Precedence field), unless the (reset the 3 bits of the former ToS Precedence field), unless the
first two bits of the DSCP field are 0b11; first two bits of the DSCP field are 0b11;
skipping to change at page 6, line 28 skipping to change at page 7, line 22
Remark: remarks all traffic to one or more particular (non-zero) Remark: remarks all traffic to one or more particular (non-zero)
DSCP values. DSCP values.
4.1. Bleaching the DSCP Field 4.1. Bleaching the DSCP Field
A specific form of remarking occurs when the DiffServ field is re- A specific form of remarking occurs when the DiffServ field is re-
assigned to the default treatment, CS0 (0x00). This results in assigned to the default treatment, CS0 (0x00). This results in
traffic being forwarded using the BE PHB. For example, AF31 (0x1a) traffic being forwarded using the BE PHB. For example, AF31 (0x1a)
would be bleached to CS0. would be bleached to CS0.
Resetting all the bits of the DiffServ field to 0 is more prevalent A survey reported that resetting all the bits of the DiffServ field
at the edge of the network, and rather less common in core networks to 0 was seen to be more prevalent at the edge of the network, and
[Custura]. rather less common in core networks [Custura].
4.2. IP Type of Service manipulations 4.2. IP Type of Service manipulations
The IETF first defined ToS precedence for IP packets [RFC0791], The IETF first defined ToS precedence for IP packets [RFC0791],
updated by specification as a part of the ToS Field RFC1349 updated by specification as a part of the ToS Field RFC1349
[RFC1349]. Since 1998, this practice has been deprecated by RFC2474 [RFC1349]. Since 1998, this practice has been deprecated by RFC2474
[RFC2474]. RFC 2474 defines codepoints 0x xxx000 as the Class [RFC2474]. RFC 2474 defines DSCPs 0bxxx000 as the Class Selector
Selector codepoints, where PHBs selected by these codepoints MUST codepoints, where PHBs selected by these codepoints MUST meet the
meet the Class Selector PHB Requirements" described in Sec. 4.2.2.2 Class Selector PHB Requirements" described in Sec. 4.2.2.2 of that
of that RFC. RFC.
However, practices based on ToS semantics have not yet been However, a recent survey reports practices based on ToS semantics
eliminated from Internet, and need to still be considered when making have not yet been eliminated from Internet, and need to still be
new DSCP assignments. considered when making new DSCP assignments [Custura].
4.2.1. Impact of ToS Precedence Bleaching 4.2.1. Impact of ToS Precedence Bleaching
ToS Precedence Bleaching (/Bleach-ToS-Precedence/) is a practice that ToS Precedence Bleaching (/Bleach-ToS-Precedence/) is a practice that
resets to zero the upper 3 bits of the DSCP field (the former ToS resets the first three bits of the DSCP field to zero (the former ToS
Precedence field), leaving the lower bits unchanged (see section Precedence field), leaving the last three bits unchanged (see section
4.2.1 of RFC2474 [RFC2474]). This behaviour is distinctive of non- 4.2.1 of RFC2474 [RFC2474]). This remarking is distinctive of non-
DiffServ aware routers and one of the more common manipulations of DiffServ aware routers and a common manipulation of the DiffServ
the DiffServ field. field. The following Figure provides details.
+-+-+-+-+-+-+ +-+-+-+-+-+-+
|0 0 0|x x x| |0 0 0|x x x|
+-+-+-+-+-+-+ +-+-+-+-+-+-+
Figure showing the ToS Precedence Bleaching (/Bleach-ToS-Precedence/) Figure showing the ToS Precedence Bleaching (/Bleach-ToS-Precedence/)
pathology, based on Section 3 of RFC1349 [RFC1349]. pathology, based on Section 3 of RFC1349 [RFC1349].
+---------+-------+----------+-----+----------+-----+----------+-----+
| 56/CS7 | 57 | 58 | 59 | 60 | 61 | 62 | 63 |
+---------+-------+----------+-----+----------+-----+----------+-----+
| 48/CS6 | 49 | 50 | 51 | 52 | 53 | 54 | 55 |
+---------+-------+----------+-----+----------+-----+----------+-----+
| 40/CS5 | 41 | 42 | 43 | 44/VA | 45 | 46/EF | 47 |
+---------+-------+----------+-----+----------+-----+----------+-----+
| 32/CS4 | 33 | 34/AF41 | 35 | 36/AF42 | 37 | 38/AF43 | 39 |
+---------+-------+----------+-----+----------+-----+----------+-----+
| 24/CS3 | 25 | 26/AF31 | 27 | 28/AF32 | 29 | 30/AF33 | 31 |
+---------+-------+----------+-----+----------+-----+----------+-----+
| 16/CS2 | 17 | 18/AF21 | 19 | 20/AF22 | 21 | 22/AF23 | 23 |
+---------+-------+----------+-----+----------+-----+----------+-----+
| 8/CS1 | 9 | 10/AF11 | 11 | 12/AF12 | 13 | 14/AF13 | 15 |
+=========+=======+==========+=====+==========+=====+==========+=====+
| 0/CS0 | 1/LE | 2 | 3 | 4 | 5 | 6 | 7 |
+=========+=======+==========+=====+==========+=====+==========+=====+
As a result of ToS Precedence Bleaching, all the DSCPs in each column
are remarked to the smallest DSCP in that column. The DSCPs in the
bottom row therefore have a higher survivability across an end-to-end
Internet path.
+=========+=======+============+====+======+======+============+====+
| 0/CS0 | 1/LE | 2 | 3 | 4 | 5 | 6 | 7 |
+=========+=======+============+====+======+======+============+====+
|Assigned |ToS Prec Bl.|EXP/|Used |Future|ToS Prec Bl.|Exp/|
| |of AF11..41 |LU |by SSH|NQB |of AF13..EF |LU |
+=================+============+====+======+======+============+====+
Figure showing 0b000xxx DSCPs, highlighting any current assignments
and whether they are affected by any known pathologies. For example,
ToS Precedence Bleaching of popular DSCPs AF11,21,31,41 would result
in traffic being remarked with DSCP 2 in the Internet core. DSCP 4
has been historically used by the SSH application, following
semantics which precede DiffServ[DSCP4].
If ToS Precedence Bleaching occurs, packets with a DSCP 'x' would be If ToS Precedence Bleaching occurs, packets with a DSCP 'x' would be
remarked and then would be treated according to the PHB specified for remarked to 'x' & 0x07and then would be treated according to the
'x' & 0x07. For example, AF31 (0x1a) would be remarked to DSCP 2 corresponding PHB.
(0x02).
A variation of this behaviour clears the top three bits of a DSCP, A variation of this pathology clears the top three bits of a DSCP,
unless these have values 0b110 or 0b111 (corresponding to the CS6 and unless these have values 0b110 or 0b111 (corresponding to the CS6 and
CS7 codepoints). As a result, a DSCP value greater than 48 decimal CS7 DSCPs). As a result, a DSCP value greater than 48 decimal (0x30)
(0x30) is less likely to be impacted by ToS Precedence Bleaching. is less likely to be impacted by ToS Precedence Bleaching.
4.2.2. Impact of ToS Precedence Remarking 4.2.2. Impact of ToS Precedence Remarking
Practices based on ToS Precedence Remarking (/Remark-ToS/) RFC1349 Practices based on ToS Precedence Remarking (/Remark-ToS/) RFC1349
[RFC1349] were deprecated by RFC2474 [RFC2474]. These practices [RFC1349] were deprecated by RFC2474 [RFC2474]. These practices
based on ToS semantics have not yet been eliminated from deployed based on ToS semantics have not yet been eliminated from deployed
networks. networks.
+-+-+-+-+-+-+ +-+-+-+-+-+-+
|0 0 1|x x x| |0 0 1|x x x|
+-+-+-+-+-+-+ +-+-+-+-+-+-+
Figure showing an example of ToS Remarking (/Remark/) pathology, Figure showing ToS Precedence Remarking (/Remark-ToS/) pathology,
based on Section 3 of RFC1349 [RFC1349]. based on Section 3 of RFC1349 [RFC1349].
A less common behaviour, ToS precedence remarking sets the upper A less common remarking, ToS Precedence Remarking sets the first
three bits of the DSCP field to a non-zero value corresponding to a three bits of the DSCP to a non-zero value corresponding to a CS PHB.
CS PHB. This behaviour is distinctive of non-DiffServ aware routers. This remarking is distinctive of non-DiffServ aware routers.
If remarking occurs, packets are treated using the PHB specified for If remarking occurs, packets are forwarded using the PHB specified
the resulting codepoint. For example, the AF31 DSCP (0x1a) could be for the resulting DSCP. For example, the AF31 DSCP (0x1a) could be
remarked to either AF11 or AF21. remarked to either AF11 or AF21.
4.3. Remarking to a Particular DSCP 4.3. Remarking to a Particular DSCP
A network device might remark the Diffserv field of an IP packet A network device might remark the DiffServ field of an IP packet
based on a local policy with a specific (set of) DSCPs, /Remark/. based on a local policy with a specific (set of) DSCPs, /Remark/.
This is sometimes performed using a Multi-Field (MF) classifier This is sometimes performed using a Multi-Field (MF) classifier
[RFC2475] [RFC3290] [RFC4594]. For example, a common behaviour is to [RFC2475] [RFC3290] [RFC4594]. For example, a common remarking is to
mark all traffic to a single DSCP, thus removing any traffic remark all traffic to a single DSCP, thus removing any traffic
differentiation (see Section 4.1). Bleaching (/Bleach/) is a differentiation (see Section 4.1). Bleaching (/Bleach/) is a
specific example of this that remarks to CS0 (0x00). specific example of this pathology that remarks to CS0 (0x00).
In another example, some networks do not follow the recommendation in In another example, some networks do not follow the recommendation in
RFC2475 [RFC2475], and instead remark packets with an unknown or RFC2475 [RFC2475], and instead remark packets with an unknown or
unexpected DSCP to the default class, CS0 (0x00) to ensure that unexpected DSCP to the default class, CS0 (0x00) to ensure that
appropriate DSCPs are used within a DiffServ domain. (e.g., see appropriate DSCPs are used within a DiffServ domain. (e.g., see
[RFC8100]). [RFC8100]).
5. Interpretation of the IP DSCP at Lower Layers 5. Interpretation of the IP DSCP at Lower Layers
Transmission systems and subnetworks can, and do, utilise the Transmission systems and subnetworks can, and do, utilise the
Diffserv field in an IP packet to select a lower layer forwarding DiffServ field in an IP packet to select a lower layer forwarding
treatment. In many cases, this use is constrained by designs that treatment. In many cases, this use is constrained by designs that
utilise fewer than 6 bits to express the service class, and therefore utilise fewer than 6 bits to express the service class, and therefore
infer mappings to a smaller L2 QoS field, for example, WiFi or Multi- infer mapping to a smaller L2 QoS field, for example, WiFi or Multi-
Protocol Label Switching (MPLS). Protocol Label Switching (MPLS).
5.1. Mapping Specified for IEEE 802 5.1. Mapping Specified for IEEE 802
<< This section is currently seeking more input. >> The IEEE specifies standards that include mappings for DSCPs to lower
layer elements.
5.1.1. Mapping Specified for IEEE 802.1 5.1.1. Mapping Specified for IEEE 802.1
A 3-bit Priority Code Point (PCP) is specified in the IEEE 802.1Q tag A 3-bit Priority Code Point (PCP) is specified in the IEEE 802.1Q tag
to mark Ethernet frames to one of eight priority values to mark Ethernet frames to one of eight priority values
[IEEE-802-1Q]. The value zero indicates the default best effort [IEEE-802-1Q]. The value zero indicates the default best effort
treatment, and the value one indicates a background traffic class. treatment, and the value one indicates a background traffic class.
The remaining values indicate increasing priority. Internet control The remaining values indicate increasing priority. Internet control
traffic can be marked as six, and network control is marked as seven. traffic can be marked as six, and network control is marked as seven.
The mapping specified in [IEEE-802-1Q] revises a previous standard The mapping specified in [IEEE-802-1Q] revises a previous standard
[IEEE-802-1D], in an effort to align with Diffserv practice: the [IEEE-802-1D], in an effort to align with DiffServ practice: the
traffic types are specified to match the first three bits of a traffic types are specified to match the first three bits of a
suitable DSCP (for example, Voice, which has PCP value 5, matches the suitable DSCP (e.g., the first three bits of the EF DSCP is mapped to
first three bits of EF). However, [IEEE-802-1D] maps both PCP1 a PCP of 5). However, [IEEE-802-1D] maps both PCP1 (Background) and
(Background) and PCP2 (Spare) to indicate lower priority than PCP0, PCP2 (Spare) to indicate lower priority than PCP0, RFC8622.
RFC 8622. Therefore, different behaviour is expected depending on Therefore, different remarking pathologies are expected depending on
the age of deployed devices. the age of deployed devices.
5.1.2. Mapping Specified for IEEE 802.11 5.1.2. Mapping Specified for IEEE 802.11
Section 6 of RFC 8325 [RFC8325] provides a brief overview of IEEE Section 6 of RFC 8325 [RFC8325] provides a brief overview of IEEE
802.11 QoS. The IEEE 802.11 standards [IEEE-802-11] provide MAC 802.11 QoS. The IEEE 802.11 standards [IEEE-802-11] provide MAC
functions to support QoS in WLANs using Access Classes (AC). The functions to support QoS in WLANs using Access Classes (AC). The
upstream User Priority (UP) in the 802.11 header has a 3-bit QoS upstream User Priority (UP) in the 802.11 header has a 3-bit QoS
value. A DSCP can be mapped to the UP. Most existing WiFi value. A DSCP can be mapped to the UP.
implementations [RFC8325] use a default mapping that utilises the
three most significant bits of the DiffServ Field to the 802.11 UP. Most existing WiFi implementations [RFC8325] use a default mapping
that maps the first three bits of the DSCP to the 802.11 UP value.
This is then in turn mapped to the four WiFi Multimedia (WMM) Access This is then in turn mapped to the four WiFi Multimedia (WMM) Access
Categories. Categories. The Wi-Fi Alliance has also specified a more flexible
mapping that follows RFC8325 and provides functions at an AP to
remark packets as well as a QoS Map that maps each DSCP to an AC
[WIFI-ALLIANCE].
+-+-+-+-+-+-+ +-+-+-+-+-+-+
|x x x|. . .| |x x x|. . .|
+-+-+-+-+-+-+ +-+-+-+-+-+-+
Figure showing the DSCP bits commonly mapped to the UP in 802.11. Figure showing the DSCP bits commonly mapped to the UP in 802.11.
RFC8325 [RFC8325] notes inconsistencies that can result from such RFC8325 [RFC8325] notes inconsistencies that can result from such
remarking, and recommends how to perform this remarking. It proposes remarking, and recommends how to perform this remarking. It proposes
several recommendations for mapping a DSCP to an IEEE 802.11 UP for several recommendations for mapping a DSCP to an IEEE 802.11 UP for
wired-to-wireless interconnection. The recommendation includes wired-to-wireless interconnection. The recommendation includes
mapping network control traffic CS6 and CS7, as well unassigned mapping network control traffic CS6 and CS7, as well unassigned
codepoints, to UP 0. DSCPs, to UP 0.
In the upstream direction (wireless-to-wired interconnections, this In the upstream direction (wireless-to-wired interconnections, this
mapping can result in a specific DSCP remarking pathology. Some mapping can result in a specific DSCP remarking pathology. Some
Access Points (APs) currently use a default UP-to-DSCP mapping Access Points (APs) currently use a default UP-to-DSCP mapping
RFC8325 [RFC8325], wherein "DSCP values are derived from the layer 2 RFC8325 [RFC8325], wherein "DSCP values are derived from the layer 2
UP values by multiplying the UP values by eight (i.e., shifting the UP values by multiplying the UP values by eight (i.e., shifting the
three UP bits to the left and adding three additional zeros to three UP bits to the left and adding three additional zeros to
generate a 6 bit DSCP value). This derived DSCP value is then used generate a 6-bit DSCP value). This derived DSCP value is used for
for QoS treatment between the wireless AP and the nearest QoS treatment between the wireless AP and the nearest classification
classification and marking policy enforcement point (which may be the and marking policy enforcement point (which may be the centralized
centralized wireless LAN controller, relatively deep within the wireless LAN controller, relatively deep within the network).
network). Alternatively, in the case where there is no other Alternatively, in the case where there is no other classification and
classification and marking policy enforcement point, then this marking policy enforcement point, then this derived DSCP value will
derived DSCP value will be used on the remainder of the Internet be used on the remainder of the Internet path." This can result in
path." This behaviour can result in remarking /Reset-low/. remarking /Reset-low/.
+-+-+-+-+-+-+ +-+-+-+-+-+-+
|x x x|0 0 0| |x x x|0 0 0|
+-+-+-+-+-+-+ +-+-+-+-+-+-+
Figure showing the pathology resulting from deriving from UP-to-DSCP Figure showing the pathology resulting from deriving from UP-to-DSCP
mapping in some 802.11 networks. mapping in some 802.11 networks.
An alternative to UP-to-DSCP remapping is using the DSCP value of a An alternative to UP-to-DSCP remapping uses the DSCP value of a
downstream IP packet (e.g., the Control And Provisioning of Wireless downstream IP packet (e.g., the Control And Provisioning of Wireless
Access Points (CAPWAP) protocol, RFC5415, maps an IP packet Diffserv Access Points (CAPWAP) protocol, RFC5415, maps an IP packet DiffServ
field to the Diffserv field of outer IP headier in a CAPWAP tunnel). field to the DiffServ field of outer IP header in a CAPWAP tunnel).
Some current constraints of WiFi mapping are discussed in section 2 Some current constraints of WiFi mapping are discussed in section 2
of [RFC8325]. A QoS profile can be used to limit the maximum DSCP of [RFC8325]. A QoS profile can be used to limit the maximum DSCP
value used for the upstream and downstream traffic. value used for the upstream and downstream traffic.
5.2. Mappings Specified for MPLS 5.2. DiffServ and MPLS
<< This section is currently seeking more input. >>
Multi-Protocol Label Switching (MPLS) specified eight MPLS Traffic Multi-Protocol Label Switching (MPLS) specified eight MPLS Traffic
Classes (TCs), which restricts the number of different treatments Classes (TCs), which restricts the number of different treatments
(e.g., see [RFC5129]). RFC 5127 describes aggregation of DiffServ [RFC5129]. RFC 5127 describes aggregation of DiffServ TCs [RFC5127],
TCs [RFC5127], and introduces four DiffServ Treatment Aggregates. and introduces four DiffServ Treatment Aggregates. Traffic marked
Traffic marked with multiple DSCPs can be forwarded in a single MPLS with multiple DSCPs can be forwarded in a single MPLS TC.
TC.
There are three Label-Switched Router (LSR) behaviors: the Pipe, the There are three Label-Switched Router (LSR) behaviors: the Pipe, the
Short Pipe and the Uniform Model [RFC3270]. These only differ when a Short Pipe and the Uniform Model [RFC3270]. These only differ when a
LSP performs a push or a pop. LSP performs a push or a pop.
5.2.1. Mappings Specified for MPLS 5.2.1. Mapping Specified for MPLS
RFC3270 [RFC3270] defines a flexible solution for support of DiffServ RFC3270 [RFC3270] defines a flexible solution for support of DiffServ
over MPLS networks. This allows an MPLS network administrator to over MPLS networks. This allows an MPLS network administrator to
select how BAs (marked by DSCPs) are mapped onto Label Switched Paths select how BAs (marked by DSCPs) are mapped onto Label Switched Paths
(LSPs) to best match the DiffServ, Traffic Engineering and protection (LSPs) to best match the DiffServ, Traffic Engineering and protection
objectives within their particular network. objectives within their particular network.
Mappings from the IP DSCP to the MPLS header are defined in Mapping from the IP DSCP to the MPLS header are defined in
Section 4.2 of [RFC3270]. Section 4.2 of [RFC3270].
Using the Pipe Model, the "LSP Diff-Serv Information" is conveyed to The Pipe Model conveys the "LSP Diff-Serv Information" to the LSP
the LSP Egress so that its forwarding treatment can be based on the Egress so that its forwarding treatment can be based on the IP DSCP.
IP DSCP.
When Penultimate Hop Popping (PHP) is used, the Penultimate LSR needs When Penultimate Hop Popping (PHP) is used, the Penultimate LSR needs
to be aware of the set of PHB to encapsulation mappings for the label to be aware of the encapsulation mapping for a PHB to the label
corresponding to the exposed header to perform DiffServ Information corresponding to the exposed header to perform DiffServ Information
Encoding (Section 2.5.2 of RFC3270 [RFC3270]). Encoding (Section 2.5.2 of RFC3270 [RFC3270]).
5.2.2. Mappings Specified for MPLS Short Pipe 5.2.2. Mapping Specified for MPLS Short Pipe
<< This section is currently seeking more input. >>
The Short Pipe Model is an optional variation of the Pipe Model The Short Pipe Model is an optional variation of the Pipe Model
[RFC3270]. [RFC3270].
ITU-T Y.1566 [ITU-T-Y-1566] further defined a set of four common QoS ITU-T Y.1566 [ITU-T-Y-1566] further defined a set of four common QoS
classes and four auxiliary classes to which a DSCP can be mapped when classes and four auxiliary classes to which a DSCP can be mapped when
interconnecting Ethernet, IP and MPLS networks. RFC8100 [RFC8100] interconnecting Ethernet, IP and MPLS networks. RFC8100 [RFC8100]
proposes four treatment aggregates for interconnection with four proposes four treatment aggregates for interconnection with four
defined DSCPs. This was motivated by the requirements of MPLS defined DSCPs. This was motivated by the requirements of MPLS
network operators that use Short-Pipe tunnels, but can be applicable network operators that use Short-Pipe tunnels, but can be applicable
to other networks, both MPLS and non-MPLS. to other networks, both MPLS and non-MPLS.
RFC8100 recommends preserving the notion of end-to-end service RFC8100 recommends preserving the notion of end-to-end service
classes, and recommends that the original DSCP marking is not changed classes, and recommends that the original DSCP marking is not changed
when treatment aggregates are used. The key requirement is that the when treatment aggregates are used. The key requirement is that the
DSCP at the network ingress is restored at the network egress. This DSCP at the network ingress is restored at the network egress. This
is only feasible in general for a small number of DSCPs. In this is only feasible in general for a small number of DSCPs. In this
design, packets marked with other DSCPs can be re-marked (This can design, packets marked with other DSCPs can be remarked (a /Remark/
result in the /Remark/ behaviour) or dealt with via an additional pathology) or dealt with via an additional agreement(s) among the
agreement(s) among the operators of the interconnected networks. Use operators of the interconnected networks. Use of the MPLS Short Pipe
of the MPLS Short Pipe Model favours re-marking unexpected DSCP Model favours remarking unexpected DSCP values to zero in the absence
values to zero in the absence of an additional agreement(s), as of an additional agreement(s), as explained in RFC8100 [RFC8100].
explained in RFC8100 [RFC8100]. This can result in bleaching This can result in bleaching (/Bleach/).
(/Bleach/).
+--------------------------------------+--------+ +--------------------------------------+--------+
| RFC8100 | DSCP | | RFC8100 | DSCP |
| Agg. Class | | | Agg. Class | |
+--------------------------------------+--------+ +--------------------------------------+--------+
|Telephony Service Treatment Aggregate | EF | |Telephony Service Treatment Aggregate | EF |
| | VA | | | VA |
+--------------------------------------+--------+ +--------------------------------------+--------+
|Bulk Real-Time Treatment Aggregate | AF41 | |Bulk Real-Time Treatment Aggregate | AF41 |
| May be added | (AF42) | | May be added | (AF42) |
skipping to change at page 12, line 25 skipping to change at page 13, line 32
+--------------------------------------+--------+ +--------------------------------------+--------+
|Assured Elastic Treatment Aggregate | AF31 | |Assured Elastic Treatment Aggregate | AF31 |
| | AF32 | | | AF32 |
| Reserved for the extension of PHBs| (AF33) | | Reserved for the extension of PHBs| (AF33) |
+--------------------------------------+--------+ +--------------------------------------+--------+
|Default / Elastic Treatment Aggregate | BE/CS0 | |Default / Elastic Treatment Aggregate | BE/CS0 |
+--------------------------------------+--------+ +--------------------------------------+--------+
|Network Control: Local Use | CS6 | |Network Control: Local Use | CS6 |
+--------------------------------------+--------+ +--------------------------------------+--------+
Figure showing the short-pipe MPLS mapping from RFC 8100. The short-pipe MPLS mapping from RFC 8100.
5.3. Mapping Specified for Mobile Networks 5.3. Mapping Specified for Mobile Networks
<< This section is currently seeking more input. >>
Mobile LTE and 5G standards have evolved from older UMTS standards, Mobile LTE and 5G standards have evolved from older UMTS standards,
and are Diffserv aware. LTE (4G) and 5G standards [SA-5G] identify and are DiffServ aware. LTE (4G) and 5G standards [SA-5G] identify
traffic classes at the interface between User Equipment (UE) and the traffic classes at the interface between User Equipment (UE) and the
mobile Packet Core network by QCI (QoS Class Identifiers) and 5QI (5G mobile Packet Core network by QCI (QoS Class Identifiers) and 5QI (5G
QoS Identifier). The 3GPP standards do not define or recommend any QoS Identifier). The 3GPP standards do not define or recommend any
specific mappings between each QCI or 5QI and Diffserv (and mobile specific mapping between each QCI or 5QI and DiffServ (and mobile
QCIs are based on several criteria service class definitions). The QCIs are based on several criteria service class definitions). The
way packets are mapped at the Packet Gateway (P-GW) boundary is way packets are mapped at the Packet Gateway (P-GW) boundary is
determined by operators. However, TS 23.107 (version 16.0.0, applies determined by operators. However, TS 23.107 (version 16.0.0, applies
to LTE and below) mandates that Differentiated Services, defined by to LTE and below) mandates that Differentiated Services, defined by
IETF, shall be used to interoperate with IP backbone networks. IETF, shall be used to interoperate with IP backbone networks.
The GSM Association (GSMA) has defined four aggregated classes and The GSM Association (GSMA) has defined four aggregated classes and
seven associated PHBs in their guidelines for IPX Provider networks seven associated PHBs in their guidelines for IPX Provider networks
GSMA IR.34 [GSMA-IR-34]. This was previously specified as the Inter- GSMA IR.34 [GSMA-IR-34]. This was previously specified as the Inter-
Service Provider IP Backbone Guidelines, and provides a mobile ISP to Service Provider IP Backbone Guidelines, and provides a mobile ISP to
ISP QoS mapping mechanism, and interconnection with other IP networks ISP QoS mapping mechanism, and interconnection with other IP networks
in the general Internet. This describes the case where the DSCP in the general Internet. This describes the case where the DSCP
marking from a Service Provider cannot be trusted (depending on the marking from a Service Provider cannot be trusted (depending on the
agreement between the Service Provider and its IPX Provider), agreement between the Service Provider and its IPX Provider),
allowing the IPX Provider to correct the DSCP value to a static allowing the IPX Provider to remark the DSCP value to a static
default value. default value.
+---------------+-------+ +---------------+-------+
| GSMA IR.34 | PHB | | GSMA IR.34 | PHB |
| Agg. Class | | | Agg. Class | |
+---------------+-------+ +---------------+-------+
|Conversational | EF | |Conversational | EF |
+---------------+-------+ +---------------+-------+
| Streaming | AF41 | | Streaming | AF41 |
+---------------+-------+ +---------------+-------+
skipping to change at page 13, line 24 skipping to change at page 14, line 31
+ +-------+ + +-------+
| (ordered by | AF32 | | (ordered by | AF32 |
+ priority, +-------+ + priority, +-------+
| AF3 highest) | AF21 | | AF3 highest) | AF21 |
+ +-------+ + +-------+
| | AF11 | | | AF11 |
+---------------+-------+ +---------------+-------+
| Background | CS0 | | Background | CS0 |
+---------------+-------+ +---------------+-------+
Figure showing the PHB mapping from GSMA IR.34 [GSMA-IR-34]. Figure showing the PHB mapping recommended in the guidelines proposed
in GSMA IR.34 [GSMA-IR-34].
5.4. Mappings Specified for Carrier Ethernet
<< This section is currently seeking more input. >> 5.4. Mapping Specified for Carrier Ethernet
Metro Ethernet Forum (MEF) provides mappings of DSCP codepoints at Metro Ethernet Forum (MEF) provides a mapping of DSCPs at the IP
the IP layer to quality of service markings in the Ethernet frame layer to quality of service markings in the Ethernet frame headers
headers MEF 23.1 [MEF23.1]. MEF 23.1 [MEF23.1].
5.5. Remarking as a Side-effect of Another Policy 5.5. Remarking as a Side-effect of Another Policy
The result of applying a QoS policy (such as matching the IP address, The result of applying a QoS policy (such as matching the IP address,
or traffic reaching a rate limit) could also result in a packet being or traffic reaching a rate limit) could also result in a packet being
remarked to a different DSCP (/Remark/) when it is not admitted to a remarked to a different DSCP (/Remark/) when it is not admitted to a
service. Traffic marked with an EF and VA DSCP are often policed by service. Traffic marked with an EF and VA DSCP are often policed by
such policies. such policies.
Policies and L2 procedures can also result in remarking traffic as a Policies and L2 procedures can also result in remarking traffic as a
side-effect of other functions (e.g., in response to DDos). side-effect of other functions (e.g., in response to DDos).
5.6. Summary 5.6. Summary
<< This section might contain a summary table >> This section has discussed the various ways in which DSCP remarking
pathologies can arise from interactions with lower layers.
6. Considerations for DSCP Selection 6. Considerations for DSCP Selection
This section provides advice for the assignment of a new DSCP value. This section provides advic e for the assignment of a new DSCP value.
It identifies known issues that might influence the finally assigned It identifies known issues that might influence the finally assigned
DSCP, followed by a summary of considerations for assignment of a new DSCP, followed by a summary of considerations for assignment of a new
DSCP. DSCP.
6.1. Effect of Bleaching 6.1. Effect of Bleaching
New DSCP assignments should consider the impact of bleaching, which New DSCP assignments should consider the impact of bleaching, which
can limit the ability to provide the expected treatment end-to-end. can limit the ability to provide the expected treatment end-to-end.
This is particularly important for cases where the codepoint is This is particularly important for cases where the codepoint is
intended to result in lower than best effort treatment, as was the intended to result in lower than best effort treatment, as was the
case when defining the LE PHB [RFC8622]. In this case, bleaching, or case when defining the LE PHB [RFC8622]. In this case, bleaching, or
remarking to "CS0" would result in elevating the lower effort traffic remarking to "CS0" would result in elevating the lower effort traffic
to the default class. This is an example of priority inversion. to the default class. This is an example of priority inversion.
6.2. Where the proposed DSCP > 0x07 (7) 6.2. Where the proposed DSCP > 0x07 (7)
Although the IETF specifications require systems to use DSCP marking Although the IETF specifications require systems to use DSCP marking
semantics in place of methods based on the former ToS field, the semantics in place of methods based on the former ToS field, the
current recommendation is that any new assignment where the codepoint current recommendation is that any new assignment where the DSCP is
is greater than 0x07 should consider the semantics associated with greater than 0x07 should consider the semantics associated with the
the resulting DSCP when ToS precedence bleaching is experienced. For resulting DSCP when ToS Precedence Bleaching is experienced. For
example, it can be desirable to avoid choosing a DSCP that could be example, it can be desirable to avoid choosing a DSCP that could be
remarked to LE, Lower Effort [RFC8622], which could otherwise remarked to LE, Lower Effort [RFC8622], which could otherwise
potentially result in a priority inversion in the treatment. potentially result in a priority inversion in the treatment.
6.3. Where the proposed DSCP < 0x07 (7) 6.3. Where the proposed DSCP < 0x07 (7)
ToS bleaching can unintentionally result in extra traffic aggregated ToS Precedence Bleaching can unintentionally result in extra traffic
to the same DSCP. For example, after experiencing ToS Bleaching, all aggregated to the same DSCP. For example, after experiencing ToS
traffic marked AF11, AF21, AF31 and AF41 would be aggregated with Precedence Bleaching, all traffic marked AF11, AF21, AF31 and AF41
traffic marked with DSCP 2 (0x02), increasing the volume of traffic would be aggregated with traffic marked with DSCP 2 (0x02),
which receives the treatment associated with DSCP 2. New DiffServ increasing the volume of traffic which receives the treatment
codepoint assignments should consider unexpected consequences arising associated with DSCP 2. New DiffServ Codepoint assignments should
from ToS bleaching. consider unexpected consequences arising from this pathology.
6.3.1. Where the proposed DSCP&&0x07=0x01 6.3.1. Where the proposed DSCP&0x07=0x01
As a consequence of assigning the LE PHB [RFC8622], the IETF As a consequence of assigning the LE PHB [RFC8622], the IETF
allocated the DSCP 000001b from Pool 3. allocated the DSCP 0b000001 from Pool 3.
When making assignments where the DSCP has a format: xxx 001b, the When making assignments where the DSCP has a format: 0bxxx001, the
case of ToS Precedence Bleaching (/Bleach-ToS-Precedence/) of a DSCP case of ToS Precedence Bleaching (/Bleach-ToS-Precedence/) of a DSCP
to a value of 0x01 needs to be considered. ToS Precedence Bleaching to a value of 0x01 needs to be considered. ToS Precedence Bleaching
will result in demoting the traffic to the lower effort traffic will result in demoting the traffic to the lower effort traffic
class. Care should be taken to consider the implications that a DSCP class. Care should be taken to consider the implications of
in this category could be remarked as LE. remarking when shooing to assign a DSCP with tyhis format.
6.4. Impact on deployed infrastructure 6.4. Impact on deployed infrastructure
Behaviour of deployed PHBs and conditioning treatments also needs to Behaviour of deployed PHBs and conditioning treatments also needs to
be considered when assigning a new DSCP. In some domains, a network be considered when assigning a new DSCP. Network operators have
operator can provide transparent transport of unknown or unassigned choices when it comes to configuring DiffServ support within their
DSCPs across their domain. In other domains, policing can ensure domains, and the pathologies described in the previous section can
that only traffic that matches a policy is permitted to use a result from different configurations and approaches:
specific DSCP (e.g., as in MPLS TC).
Networks not remarking DiffServ: A network that implements one or
more PHBs, and does not remark DSCPs. Operators in this category
pass all DSCPs transparently.
Networks that condition the DSCP: A network that implements more
than one PHB and enforces SLAs with its peers. Operators in this
category use conditioning to ensure that only traffic that matches
a policy is permitted to use a specific DSCP (see RFC8100
[RFC8100]). This requires operators to choose to support or
remark a new DSCP assignment.
Networks that remark in some other way , which includes:
1. Networks containing misconfigured devices that do not comply
with the relevent RFCs.
2. Networks containing devices that implement an obsolete
specification or contain software bugs.
3. Networks containing devices that remark the DSCP as a result
of lower layer interactions.
For example, the ToS Precedence Bleaching (/Bleach-ToS-Precedence/)
pathology cannot arise in the case of networks not remarking
DiffServ, but can arise as a result of traffic conditioning at
operator boundaries. It can also arise in the case of
misconfiguration or in netwroks using old equipment which precedes
DiffServ.
6.5. Questions to guide discussion of a proposed new DSCP 6.5. Questions to guide discussion of a proposed new DSCP
A series of questions emerge that need to be answered when A series of questions emerge that need to be answered when
considering a proposal to the IETF that requests a new assignment. considering a proposal to the IETF that requests a new assignment.
These questions include: These questions include:
* How is the proposed service class characterised? - What are the * Is the request for local use within a DiffServ domain that does
not require interconnection with other DiffServ domains? This can
use DSCPs in Pool 2 for local or experimental use, without any
IETF specification for the DSCP or associated PHB.
* How is the proposed service class characterised? What are the
characteristics of the traffic to be carried? What are the characteristics of the traffic to be carried? What are the
expectations for treatment? expectations for treatment?
* Service Classes that can utilise existing PHBs should use assigned * Service Classes that can utilise existing PHBs should use assigned
DSCPs to mark their traffic: Could the request be met by using an DSCPs to mark their traffic: Could the request be met by using an
existing IETF DSCP? How would the proposed new DSCP be used to existing IETF DSCP? The proposed new treatement be used to map
map traffic to a new or existing PHB? traffic to a new or existing PHB.
* Diffserv domains can use the codepoints in Pool 2 for local or
experimental use, without any IETF specification for the DSCP or
associated PHB: Could the request be met by using a DSCP chosen
from Pool 2? Or is the DSCP intended to be used at network
interconnections?
* This documents describes some observed marking behaviors (see also * Does the service class request assigning new DSCP? Specification
below): What is the expected effect of currently-deployed of a new recommended DSCP requires Standards Action. RFC2474
remarking on the end-to-end service? states: "Each standardized PHB MUST have an associated RECOMMENDED
codepoint". If approved, new IETF assignments are normally made
by IANA in Pool 1, but the IETF can request assignments to be made
from Pool 3 [RFC8436].
* Many DiffServ domains support only a small number of treatment * Many What are the effects of treatment aggregation on the proposed
aggregates: What are the effects of treatment aggregation on the method? Section 5.2 describes examples of treatment aggregation.
proposed method?
* This documents describes some observed treatments by layers below * What are the implications of using the proposed DSCP on the
IP: What are the implications of using the proposed DSCP on the
expected lower layers over which the traffic may be forwarded? expected lower layers over which the traffic may be forwarded?
Section 5 describes some observed treatments by layers below IP.
Specification of a new recommended DSCP requires Standards Action. * If a new DSCP is needed for an end-to-end service, then what is
RFC2474 states: "Each standardized PHB MUST have an associated the expected effect of currently-deployed remarking on the end-to-
RECOMMENDED codepoint". If approved, new IETF assignments are end service? Section 4 describes some observed remarking
normally made by IANA in Pool 1, but the IETF can request assignments pathologies, and Section 6.4 identifies root causes for why these
to be made from Pool 3 [RFC8436]. remarking pathologies are observed.
7. Acknowledgments 7. Acknowledgments
The authors acknowledge the helpful discussions and analysis by Greg The authors acknowledge the helpful discussions and analysis by Greg
White and Thomas Fossati in a draft concerning NQB. We look forward White and Thomas Fossati in a draft concerning NQB. Ruediger Geib,
to further comments and review. and Brian Carpenter contributed comments, along with other memebers
of the TSVWG.
8. IANA Considerations 8. IANA Considerations
This memo provides information to assist in considering new This memo provides information to assist in considering new
assignments to the IANA DSCP registry assignments to the IANA DSCP registry
(https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml). (https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml).
This memo includes no request to IANA, or update to the IANA This memo includes no request to IANA, or update to the IANA
procedures. procedures.
skipping to change at page 17, line 10 skipping to change at page 18, line 43
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<https://www.rfc-editor.org/info/rfc2474>. <https://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>. <https://www.rfc-editor.org/info/rfc2475>.
[RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, DOI 10.17487/RFC3260, April 2002,
<https://www.rfc-editor.org/info/rfc3260>.
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
Informal Management Model for Diffserv Routers", RFC 3290, Informal Management Model for Diffserv Routers", RFC 3290,
DOI 10.17487/RFC3290, May 2002, DOI 10.17487/RFC3290, May 2002,
<https://www.rfc-editor.org/info/rfc3290>. <https://www.rfc-editor.org/info/rfc3290>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006, DOI 10.17487/RFC4594, August 2006,
<https://www.rfc-editor.org/info/rfc4594>. <https://www.rfc-editor.org/info/rfc4594>.
skipping to change at page 17, line 44 skipping to change at page 19, line 34
10.2. Informative References 10.2. Informative References
[Barik] Barik, R., Welzl, M., Elmokashfi, A., Dreibholz, T., and [Barik] Barik, R., Welzl, M., Elmokashfi, A., Dreibholz, T., and
S. Gjessing, "Can WebRTC QoS Work? A DSCP Measurement S. Gjessing, "Can WebRTC QoS Work? A DSCP Measurement
Study", ITC 30, September 2018. Study", ITC 30, September 2018.
[Custura] Custura, A., Venne, A., and G. Fairhurst, "Exploring DSCP [Custura] Custura, A., Venne, A., and G. Fairhurst, "Exploring DSCP
modification pathologies in mobile edge networks", TMA , modification pathologies in mobile edge networks", TMA ,
2017. 2017.
[DSCP4] Kolu, A., "Bogus DSCP value for SSH", online
https://lists.freebsd.org/pipermail/freebsd-
stable/2010-July/057710.html, 2010.
[GSMA-IR-34] [GSMA-IR-34]
GSM Association, "IR.34 Guidelines for IPX Provider GSM Association, "IR.34 Guidelines for IPX Provider
networks (Previously Inter-Service Provider IP Backbone networks (Previously Inter-Service Provider IP Backbone
Guidelines)", IR 34, 2017. Guidelines)", IR 34, 2017.
[I-D.ietf-tsvwg-nqb] [I-D.ietf-tsvwg-nqb]
White, G. and T. Fossati, "A Non-Queue-Building Per-Hop White, G. and T. Fossati, "A Non-Queue-Building Per-Hop
Behavior (NQB PHB) for Differentiated Services", Work in Behavior (NQB PHB) for Differentiated Services", Work in
Progress, Internet-Draft, draft-ietf-tsvwg-nqb-03, 2 Progress, Internet-Draft, draft-ietf-tsvwg-nqb-03, 2
November 2020, <http://www.ietf.org/internet-drafts/draft- November 2020, <http://www.ietf.org/internet-drafts/draft-
skipping to change at page 18, line 33 skipping to change at page 20, line 22
[IEEE-802-1D] [IEEE-802-1D]
IEEE, "IEEE Standard for Local and Metropolitan Area IEEE, "IEEE Standard for Local and Metropolitan Area
Network-- Media Access Control (MAC) Bridges", Network-- Media Access Control (MAC) Bridges",
IEEE 802.1D, 2004. IEEE 802.1D, 2004.
[IEEE-802-1Q] [IEEE-802-1Q]
IEEE, "IEEE Standard for Local and Metropolitan Area IEEE, "IEEE Standard for Local and Metropolitan Area
Network-- Bridges and Bridged Networks", IEEE 802.1Q, Network-- Bridges and Bridged Networks", IEEE 802.1Q,
2018. 2018.
[IETF113DSCP]
Custura, A. and G. Fairhurst, "Considerations for
assigning DSCPs", IETF 113 Proceedings
https://datatracker.ietf.org/meeting/113/materials/slides-
113-tsvwg-61-dscp-considerations-07, 2022.
[ITU-T-Y-1566] [ITU-T-Y-1566]
ITU-T, "Quality of Service Mapping and Interconnection ITU-T, "Quality of Service Mapping and Interconnection
Between Ethernet, Internet Protocol and Multiprotocol Between Ethernet, Internet Protocol and Multiprotocol
Label Switching Networks", ITU-T Y.1566, 2012. Label Switching Networks", ITU-T Y.1566, 2012.
[MEF23.1] MEF, "MEF Technical Specification MEF 23.1-- Carrier [MEF23.1] MEF, "MEF Technical Specification MEF 23.1-- Carrier
Ethernet Class of Service ? Phase 2", MEF 23.1, 2012. Ethernet Class of Service ? Phase 2", MEF 23.1, 2012.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981, DOI 10.17487/RFC0791, September 1981,
skipping to change at page 19, line 35 skipping to change at page 21, line 29
[RFC8325] Szigeti, T., Henry, J., and F. Baker, "Mapping Diffserv to [RFC8325] Szigeti, T., Henry, J., and F. Baker, "Mapping Diffserv to
IEEE 802.11", RFC 8325, DOI 10.17487/RFC8325, February IEEE 802.11", RFC 8325, DOI 10.17487/RFC8325, February
2018, <https://www.rfc-editor.org/info/rfc8325>. 2018, <https://www.rfc-editor.org/info/rfc8325>.
[RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for [RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for
Differentiated Services", RFC 8622, DOI 10.17487/RFC8622, Differentiated Services", RFC 8622, DOI 10.17487/RFC8622,
June 2019, <https://www.rfc-editor.org/info/rfc8622>. June 2019, <https://www.rfc-editor.org/info/rfc8622>.
[SA-5G] 3GPP, "System Architecture for 5G", TS 23.501, 2019. [SA-5G] 3GPP, "System Architecture for 5G", TS 23.501, 2019.
[WIFI-ALLIANCE]
Wi-Fi Alliance, "Wi-Fi QoS Management Specification
Version 2.0", Wi-Fi QoS Management Specification
Version 2.0, 2021.
Appendix A. Revision Notes Appendix A. Revision Notes
Note to RFC-Editor: please remove this entire section prior to Note to RFC-Editor: please remove this entire section prior to
publication. publication.
* Individual draft -00 * Individual draft -00, initial document.
* Individual draft -01; Comments from Martin Duke; Brian Carpenter;
Ruediger Geib, and revisions to improve language consistency.
* Individual draft -02; Revisions to improve language consistency.
* Working Group -00, replacing draft-ietf-tsvwg-dscp-considerations-
02.
Appendix B. Table of DSCP Values
This table may help in the discussion of DSCP remarking. The current
assignments are at: Section 8.
+-------+------+------+------+------+------+------+------+------+
|Hi \ Lo|0b 000|0b 001|0b 010|0b 011|0b 100|0b 101|0b 110|0b 111|
+-------+------+------+------+------+------+------+------+------+
| 0b 000|BE/DE |LE | CU |Pool 3| CU | CU | CU |Pool 3|
| | CSO | | |LU/EXP| | | |LU/EXP|
+-------+------+------+------+------+------+------+------+------+
| 0b 001|CS1 | CU |AF11 |LU/EXP|AF12 | CU |AF13 |LU/EXP|
+-------+------+------+------+------+------+------+------+------+
| 0b 010|CS2 | CU |AF21 |LU/EXP|AF22 | CU |AF23 |LU/EXP|
+-------+------+------+------+------+------+------+------+------+
| 0b 011|CS3 | CU |AF31 |LU/EXP|AF32 | CU |AF33 |LU/EXP|
+-------+------+------+------+------+------+------+------+------+
| 0b 100|CS4 | CU |AF41 |LU/EXP|AF42 | CU |AF43 |LU/EXP|
+-------+------+------+------+------+------+------+------+------+
| 0b 101|CS5 | CU | CU |LU/EXP|VA | CU |EF |LU/EXP|
+-------+------+------+------+------+------+------+------+------+
| 0b 110|CS6 | CU | CU |LU/EXP| CU | CU | CU |LU/EXP|
+-------+------+------+------+------+------+------+------+------+
| 0b 111|CS7 | CU | CU |LU/EXP| CU | CU | CU |LU/EXP|
+-------+------+------+------+------+------+------+------+------+
LU/EXP - Local or Experimental Use
CU - Currently Unassigned (reserved for IANA allocation)
Table: Summary of Currently Assigned DSCP Values
Appendix C. Example of operational practice and operator requirements.
RFC5127 backbone networks are often over provisioned under stable
operating conditions. Operating and maintaining a plethora of
differentiated, DSCP based service differentiations can be
operationally difficult. Network Operations staff might not be happy
to reconfigure all or a majority of the backbone routers in response
to frequent DSCP-to-PHB mapping table configuration changes.
Instead, operational practice might prefer a simple to configure and
operate, comprehensible with limited expertise for monitoring and
debugging.
- For discussion: * Individual draft -01, address comments from Martin Duke; Brian
Carpenter; Ruediger Geib, and revisions to improve language
consistency.
There are a set of different expectations of traffic sources and * Individual draft -02, revise to improve language consistency.
sinks that set DSCP markings:
* Is the setting behaviour intended to enable a local or sectional * Working Group -00, replace individual draft.
differential treatment, without expecting end-to-end service
differentiation?
Example: A sender domain that sets DSCPs to influence stream * Working Group -01, address feedback in preparation for IETF 113
playout priorities in receiver browsers, or any/many unknown Vienna.
intentions when setting DSCPs.
* Is the setting behaviour intended to enable a local or sectional * Working Group -02:
differential treatment, without expecting end-to-end service
differentiation?
Example: A sender domain that sets DSCPs to influence stream Consolidate terminology after IETF 113 Vienna.
playout priorities in receiver browsers, or any/many unknown
intentions when setting a DSCP.
* Is the setting behaviour intended to enable end-to-end service Add clarification to RFC2474 and RFC2475 addressed in RFC3260
differentiation with an expectation of interconnection agreements (Comments from Ruediger Geib).
in place?
Example: Provider interconnection agreements, e.g., for the Include figures to show the full list of codepoints, their
public telephony service. assigned PHBs & impact of ToS Precedence Bleaching.
* Is the setting behaviour intended to enable end-to-end service Add network categories that differentiate between network
differentiation without an expectation of interconnection operator approaches to DiffServ.
agreements in place?
Example: The Non-Queue-Building or Lower Effort PHBs. Add Terminology section to clarify representations of DSCPs.
Authors' Addresses Authors' Addresses
Ana Custura Ana Custura
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Fraser Noble Building Fraser Noble Building
Aberdeen Aberdeen
AB24 3UE AB24 3UE
United Kingdom United Kingdom
 End of changes. 102 change blocks. 
296 lines changed or deleted 353 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/