draft-ietf-tsvwg-dscp-considerations-00.txt   draft-ietf-tsvwg-dscp-considerations-01.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: January 24, 2022 University of Aberdeen Expires: 28 July 2022 University of Aberdeen
July 23, 2021 24 January 2022
Considerations for Assigning a new Recommended DiffServ Codepoint (DSCP) Considerations for Assigning a new Recommended DiffServ Codepoint (DSCP)
draft-ietf-tsvwg-dscp-considerations-00 draft-ietf-tsvwg-dscp-considerations-01
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 behaviours 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
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 January 24, 2022. This Internet-Draft will expire on 28 July 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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 Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 5
4.1. Bleaching the DSCP Field . . . . . . . . . . . . . . . . 6 4.1. Bleaching the DSCP Field . . . . . . . . . . . . . . . . 6
4.2. IP Type of Service manipulations . . . . . . . . . . . . 6 4.2. IP Type of Service manipulations . . . . . . . . . . . . 6
4.2.1. Impact of ToS Precedence Bleaching . . . . . . . . . 6 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 . . . . . . . . . 7
4.3. Remarking to a Particular DSCP . . . . . . . . . . . . . 7 4.3. Remarking to a Particular DSCP . . . . . . . . . . . . . 8
5. Interpretation of the IP DSCP at Lower Layers . . . . . . . . 8 5. Interpretation of the IP DSCP at Lower Layers . . . . . . . . 8
5.1. Mapping Specified for IEEE 802.11 . . . . . . . . . . . . 8 5.1. Mapping Specified for IEEE 802 . . . . . . . . . . . . . 8
5.2. Mappings Specified for MPLS . . . . . . . . . . . . . . . 9 5.1.1. Mapping Specified for IEEE 802.1 . . . . . . . . . . 8
5.2.1. Mappings Specified for MPLS . . . . . . . . . . . . . 10 5.1.2. Mapping Specified for IEEE 802.11 . . . . . . . . . . 9
5.2.2. Mappings Specified for MPLS Short Pipe . . . . . . . 10 5.2. Mappings Specified for MPLS . . . . . . . . . . . . . . . 10
5.3. Mapping Specified for Mobile Networks . . . . . . . . . . 11 5.2.1. Mappings Specified for MPLS . . . . . . . . . . . . . 11
5.4. Mappings Specified for Carrier Ethernet . . . . . . . . . 12 5.2.2. Mappings Specified for MPLS Short Pipe . . . . . . . 11
5.5. Remarking as a Side-effect of Another Policy . . . . . . 12 5.3. Mapping Specified for Mobile Networks . . . . . . . . . . 12
5.4. Mappings Specified for Carrier Ethernet . . . . . . . . . 13
5.5. Remarking as a Side-effect of Another Policy . . . . . . 13
5.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Considerations for DSCP Selection . . . . . . . . . . . . . . 13 6. Considerations for DSCP Selection . . . . . . . . . . . . . . 14
6.1. Effect of Bleaching . . . . . . . . . . . . . . . . . . . 13 6.1. Effect of Bleaching . . . . . . . . . . . . . . . . . . . 14
6.2. Where the proposed DSCP > 0x07 (7) . . . . . . . . . . . 13 6.2. Where the proposed DSCP > 0x07 (7) . . . . . . . . . . . 14
6.3. Where the proposed DSCP < 0x07 (7) . . . . . . . . . . . 13 6.3. Where the proposed DSCP < 0x07 (7) . . . . . . . . . . . 14
6.3.1. Where the proposed DSCP&&0x07=0x01 . . . . . . . . . 14 6.3.1. Where the proposed DSCP&&0x07=0x01 . . . . . . . . . 14
6.4. Impact on deployed infrastructure . . . . . . . . . . . . 14 6.4. Impact on deployed infrastructure . . . . . . . . . . . . 15
6.5. Questions to guide discussion of a proposed new DSCP . . 14 6.5. Questions to guide discussion of a proposed new DSCP . . 15
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16 10.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 18 Appendix A. Revision Notes . . . . . . . . . . . . . . . . . . . 19
Appendix B. Table of DSCP Values . . . . . . . . . . . . . . . . 18 Appendix B. Table of DSCP Values . . . . . . . . . . . . . . . . 20
Appendix C. Example of operational practice and operator Appendix C. Example of operational practice and operator
requirements. . . . . . . . . . . . . . . . . . . . 19 requirements. . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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 value of the Diffserv field [RFC2474] carried in the IP
packet header. 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,
skipping to change at page 6, line 5 skipping to change at page 6, line 5
Section 4.3). Section 4.3).
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 five behaviours:
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) ;
Remark-ToS: set the first three bits of the DCSP field to any value 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
first two bits of the DSCP field are 0b11;
Remark-ToS: set the first three bits of the DSCP field to any value
different than 0b000 (replace the 3 bits of the former ToS different than 0b000 (replace the 3 bits of the former ToS
Precedence field); Precedence field);
Bleach-low: set the last three bits of the DSCP field to 0b000; Bleach-low: set the last three bits of the DSCP field to 0b000;
Bleach-some-low: set the last three bits of the DSCP field to 0b000, Bleach-some-low: set the last three bits of the DSCP field to 0b000,
unless the first two bits of the DSCP field are 0b11; unless the first two bits of the DSCP field are 0b11;
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.
skipping to change at page 8, line 22 skipping to change at page 8, line 34
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 mappings 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.11 5.1. Mapping Specified for IEEE 802
<< This section is currently seeking more input. >> << This section is currently seeking more input. >>
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 (for example, Voice, which has PCP value 5, matches the
first three bits of EF). However, [IEEE-802-1D] maps both PCP1 first three bits of EF). However, [IEEE-802-1D] maps both PCP1
(Background) and PCP2 (Spare) to indicate lower priority than PCP0, (Background) and PCP2 (Spare) to indicate lower priority than PCP0,
RFC 8622. Therefore, different behaviour is expected depending on RFC 8622. Therefore, different behaviour is expected depending on
the age of deployed devices. the age of deployed devices.
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. Most existing WiFi
implementations [RFC8325] use a default mapping that utilises the implementations [RFC8325] use a default mapping that utilises the
three most significant bits of the DiffServ Field to the 802.11 UP. three most significant bits of the DiffServ Field to the 802.11 UP.
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.
RFC 8325 [RFC8325] proposes several recommendations for mapping a
DSCP to an IEEE 802.11 UP for wired-to-wireless interconnection. The
DSCP value of a downstream IP packet can be used (e.g., the Control
And Provisioning of Wireless Access Points (CAPWAP) protocol,
RFC5415, maps an IP packet Diffserv field to the Diffserv field of
outer IP headier in a CAPWAP tunnel).
Some current constraints of WiFi mapping are discussed in section 2
of [RFC8325]. A QoS profile can be used to limit the maximum DSCP
value used for the upstream and downstream traffic.
+-+-+-+-+-+-+ +-+-+-+-+-+-+
|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.
This UP mapping can result in a specific DSCP remarking pathology.
In the upstream direction, some Access Points (APs) currently use a
default UP-to-DSCP mapping RFC8325 [RFC8325], wherein "DSCP values
are derived from the layer 2 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 generate a 6 bit DSCP value). This derived
DSCP value is then used for QoS treatment between the wireless AP and
the nearest classification and marking policy enforcement point
(which may be the centralized wireless LAN controller, relatively
deep within the network). Alternatively, in the case where there is
no other classification and marking policy enforcement point, then
this derived DSCP value will be used on the remainder of the Internet
path." This behaviour can result in remarking /Reset-low/.
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. remarking, and recommends how to perform this remarking. It proposes
several recommendations for mapping a DSCP to an IEEE 802.11 UP for
wired-to-wireless interconnection. The recommendation includes
mapping network control traffic CS6 and CS7, as well unassigned
codepoints, to UP 0.
In the upstream direction (wireless-to-wired interconnections, this
mapping can result in a specific DSCP remarking pathology. Some
Access Points (APs) currently use a default UP-to-DSCP mapping
RFC8325 [RFC8325], wherein "DSCP values are derived from the layer 2
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
generate a 6 bit DSCP value). This derived DSCP value is then used
for QoS treatment between the wireless AP and the nearest
classification and marking policy enforcement point (which may be the
centralized wireless LAN controller, relatively deep within the
network). Alternatively, in the case where there is no other
classification and marking policy enforcement point, then this
derived DSCP value will be used on the remainder of the Internet
path." This behaviour can result in remarking /Reset-low/.
+-+-+-+-+-+-+ +-+-+-+-+-+-+
|x x x|0 0 0| |x x x|0 0 0|
+-+-+-+-+-+-+ +-+-+-+-+-+-+
Figure showing the DSCP bits commonly mapped to the UP in 802.11. Figure showing the pathology resulting from deriving from UP-to-DSCP
mapping in some 802.11 networks.
An alternative to UP-to-DSCP remapping is using the DSCP value of a
downstream IP packet (e.g., the Control And Provisioning of Wireless
Access Points (CAPWAP) protocol, RFC5415, maps an IP packet Diffserv
field to the Diffserv field of outer IP headier in a CAPWAP tunnel).
Some current constraints of WiFi mapping are discussed in section 2
of [RFC8325]. A QoS profile can be used to limit the maximum DSCP
value used for the upstream and downstream traffic.
5.2. Mappings Specified for MPLS 5.2. Mappings Specified for MPLS
<< This section is currently seeking more input. >> << 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 (e.g., see [RFC5129]). RFC 5127 describes aggregation of DiffServ
TCs [RFC5127], and introduces four DiffServ Treatment Aggregates. TCs [RFC5127], and introduces four DiffServ Treatment Aggregates.
Traffic marked with multiple DSCPs can be forwarded in a single MPLS Traffic marked with multiple DSCPs can be forwarded in a single MPLS
skipping to change at page 14, line 32 skipping to change at page 15, line 27
DSCPs across their domain. In other domains, policing can ensure DSCPs across their domain. In other domains, policing can ensure
that only traffic that matches a policy is permitted to use a that only traffic that matches a policy is permitted to use a
specific DSCP (e.g., as in MPLS TC). specific DSCP (e.g., as in MPLS TC).
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:
o How is the proposed service class characterised? - What are the * 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?
o 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? How would the proposed new DSCP be used to
map traffic to a new or existing PHB? map traffic to a new or existing PHB?
o Diffserv domains can use the codepoints in Pool 2 for local or * Diffserv domains can use the codepoints in Pool 2 for local or
experimental use, without any IETF specification for the DSCP or experimental use, without any IETF specification for the DSCP or
associated PHB: Could the request be met by using a DSCP chosen associated PHB: Could the request be met by using a DSCP chosen
from Pool 2? from Pool 2? Or is the DSCP intended to be used at network
interconnections?
o This documents describes some observed marking behaviors (see also * This documents describes some observed marking behaviors (see also
below): What is the expected effect of currently-deployed below): What is the expected effect of currently-deployed
remarking on the end-to-end service? remarking on the end-to-end service?
o Many DiffServ domains support only a small number of treatment * Many DiffServ domains support only a small number of treatment
aggregates: What are the effects of treatment aggregation on the aggregates: What are the effects of treatment aggregation on the
proposed method? proposed method?
o This documents describes some observed treatments by layers below * This documents describes some observed treatments by layers below
IP: 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?
Specification of a new recommended DSCP requires Standards Action. Specification of a new recommended DSCP requires Standards Action.
RFC2474 states: "Each standardized PHB MUST have an associated RFC2474 states: "Each standardized PHB MUST have an associated
RECOMMENDED codepoint". If approved, new IETF assignments are RECOMMENDED codepoint". If approved, new IETF assignments are
normally made by IANA in Pool 1, but the IETF can request assignments normally made by IANA in Pool 1, but the IETF can request assignments
to be made from Pool 3 [RFC8436]. to be made from Pool 3 [RFC8436].
7. Acknowledgments 7. Acknowledgments
skipping to change at page 16, line 51 skipping to change at page 18, line 7
modification pathologies in mobile edge networks", TMA , modification pathologies in mobile edge networks", TMA ,
2017. 2017.
[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", draft- Behavior (NQB PHB) for Differentiated Services", Work in
ietf-tsvwg-nqb-03 (work in progress), November 2020. Progress, Internet-Draft, draft-ietf-tsvwg-nqb-03, 2
November 2020, <http://www.ietf.org/internet-drafts/draft-
ietf-tsvwg-nqb-03.txt>.
[I-D.learmonth-rfc1226-bis] [I-D.learmonth-rfc1226-bis]
Learmonth, I., "Internet Protocol Encapsulation of AX.25 Learmonth, I., "Internet Protocol Encapsulation of AX.25
Frames", draft-learmonth-rfc1226-bis-03 (work in Frames", Work in Progress, Internet-Draft, draft-
progress), May 2020. learmonth-rfc1226-bis-03, 19 May 2020,
<http://www.ietf.org/internet-drafts/draft-learmonth-
rfc1226-bis-03.txt>.
[IEEE-802-11] [IEEE-802-11]
IEEE, "Wireless LAN Medium Access Control (MAC) and IEEE, "Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications", IEEE 802.11, 2007. Physical Layer (PHY) Specifications", IEEE 802.11, 2007.
[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.
skipping to change at page 18, line 30 skipping to change at page 19, line 40
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.
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.
o Individual draft -00 * Individual draft -00
o Individual draft -01; Comments from Martin Duke; Brian Carpenter; * Individual draft -01; Comments from Martin Duke; Brian Carpenter;
Ruediger Geib, and revisions to improve language consistency. Ruediger Geib, and revisions to improve language consistency.
o Individual draft -02; Revisions to improve language consistency. * Individual draft -02; Revisions to improve language consistency.
o Working Group -00, replacing draft-ietf-tsvwg-dscp-considerations- * Working Group -00, replacing draft-ietf-tsvwg-dscp-considerations-
02. 02.
Appendix B. Table of DSCP Values Appendix B. Table of DSCP Values
This table may help in the discussion of DSCP remarking. The current This table may help in the discussion of DSCP remarking. The current
assignments are at: Section 8. assignments are at: Section 8.
+-------+------+------+------+------+------+------+------+------+ +-------+------+------+------+------+------+------+------+------+
|Hi \ Lo|0b 000|0b 001|0b 010|0b 011|0b 100|0b 101|0b 110|0b 111| |Hi \ Lo|0b 000|0b 001|0b 010|0b 011|0b 100|0b 101|0b 110|0b 111|
+-------+------+------+------+------+------+------+------+------+ +-------+------+------+------+------+------+------+------+------+
skipping to change at page 19, line 49 skipping to change at page 21, line 5
Instead, operational practice might prefer a simple to configure and Instead, operational practice might prefer a simple to configure and
operate, comprehensible with limited expertise for monitoring and operate, comprehensible with limited expertise for monitoring and
debugging. debugging.
- For discussion: - For discussion:
There are a set of different expectations of traffic sources and There are a set of different expectations of traffic sources and
sinks that set DSCP markings: sinks that set DSCP markings:
o Is the setting behaviour intended to enable a local or sectional * Is the setting behaviour intended to enable a local or sectional
differential treatment, without expecting end-to-end service differential treatment, without expecting end-to-end service
differentiation? differentiation?
Example: A sender domain that sets DSCPs to influence stream Example: A sender domain that sets DSCPs to influence stream
playout priorities in receiver browsers, or any/many unknown playout priorities in receiver browsers, or any/many unknown
intentions when setting DSCPs. intentions when setting DSCPs.
o Is the setting behaviour intended to enable a local or sectional * Is the setting behaviour intended to enable a local or sectional
differential treatment, without expecting end-to-end service differential treatment, without expecting end-to-end service
differentiation? differentiation?
Example: A sender domain that sets DSCPs to influence stream Example: A sender domain that sets DSCPs to influence stream
playout priorities in receiver browsers, or any/many unknown playout priorities in receiver browsers, or any/many unknown
intentions when setting a DSCP. intentions when setting a DSCP.
o Is the setting behaviour intended to enable end-to-end service * Is the setting behaviour intended to enable end-to-end service
differentiation with an expectation of interconnection agreements differentiation with an expectation of interconnection agreements
in place? in place?
Example: Provider interconnection agreements, e.g., for the Example: Provider interconnection agreements, e.g., for the
public telephony service. public telephony service.
o Is the setting behaviour intended to enable end-to-end service * Is the setting behaviour intended to enable end-to-end service
differentiation without an expectation of interconnection differentiation without an expectation of interconnection
agreements in place? agreements in place?
Example: The Non-Queue-Building or Lower Effort PHBs. Example: The Non-Queue-Building or Lower Effort PHBs.
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 AB24 3UE Aberdeen
UK AB24 3UE
United Kingdom
Email: ana@erg.abdn.ac.uk Email: ana@erg.abdn.ac.uk
Godred Fairhurst Godred Fairhurst
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Fraser Noble Building Fraser Noble Building
Aberdeen AB24 3UE Aberdeen
UK AB24 3UE
United Kingdom
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
Raffaello Secchi Raffaello Secchi
University of Aberdeen University of Aberdeen
School of Engineering School of Engineering
Fraser Noble Building Fraser Noble Building
Aberdeen AB24 3UE Aberdeen
UK AB24 3UE
United Kingdom
Email: r.secchi@abdn.ac.uk Email: r.secchi@abdn.ac.uk
 End of changes. 42 change blocks. 
93 lines changed or deleted 115 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/