Diffserv to QCI Mapping
draft-henry-tsvwg-diffserv-to-qci-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Authors | Jerome Henry , Tim Szigeti | ||
Last updated | 2018-10-16 | ||
RFC stream | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-henry-tsvwg-diffserv-to-qci-00
Network Working Group J. Henry Internet-Draft T. Szigeti Expires: April 19, 2019 Cisco October 16, 2018 Diffserv to QCI Mapping draft-henry-tsvwg-diffserv-to-qci-00 Abstract As communication devices become more hybrid, smart devices include more media-rich communication applications, and the boundaries between telecommunication and other applications becomes less clear. Simultaneously, as the end-devices become more mobile, application traffic transits more often between enterprise networks, the Internet, and cellular telecommunication networks. In this context, it is crucial that quality of service be aligned between these different environments. However, this is not always the case by default, and cellular communication networks use a different QoS nomenclature from the Internet and enterprise networks. This document specifies a set of 3rd Generation Partnership Project (3GPP) Quality of Service (QoS) Class Identifiers (QCI) to Differentiated Services Code Point (DSCP) mappings, to reconcile the marking recommendations offered by the 3GPP with the recommendations offered by the IETF, so as to maintain a consistent QoS treatment between cellular networks and the Internet. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 19, 2019. Henry & Szigeti Expires April 19, 2019 [Page 1] Internet-Draft DIFFSERV-QCI October 2018 Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Applicability Statement . . . . . . . . . . . . . . . . . 4 1.3. Document Organization . . . . . . . . . . . . . . . . . . 5 1.4. Requirements language . . . . . . . . . . . . . . . . . . 5 1.5. Terminology Used in this Document . . . . . . . . . . . . 5 2. Service Comparison and Default Interoperation of Diffserv and 3GPP LTE . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Diffserv Domain Boundaries . . . . . . . . . . . . . . . 7 2.2. QCI and Bearer Model in 3GPP . . . . . . . . . . . . . . 7 2.3. QCI Definition and Logic . . . . . . . . . . . . . . . . 9 2.3.1. Conversational . . . . . . . . . . . . . . . . . . . 9 2.3.2. Streaming . . . . . . . . . . . . . . . . . . . . . . 9 2.3.3. Interactive . . . . . . . . . . . . . . . . . . . . . 10 2.3.4. Background . . . . . . . . . . . . . . . . . . . . . 10 2.4. QCI implementations . . . . . . . . . . . . . . . . . . . 12 2.5. GSMA IPX Guidelines Interpretation and Conflicts . . . . 12 3. P-GW Device Marking and Mapping Capability Recommendations . 14 4. DSCP-to-QCI Mapping Recommendations . . . . . . . . . . . . . 14 4.1. Control Traffic . . . . . . . . . . . . . . . . . . . . . 14 4.1.1. Network Control Protocols . . . . . . . . . . . . . . 15 4.1.2. Operations, Administration, and Maintenance (OAM) . . 15 4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Telephony . . . . . . . . . . . . . . . . . . . . . . 16 4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 16 4.2.3. Multimedia Conferencing . . . . . . . . . . . . . . . 17 4.2.4. Real-Time Interactive . . . . . . . . . . . . . . . . 18 4.2.5. Multimedia Streaming . . . . . . . . . . . . . . . . 18 4.2.6. Broadcast Video . . . . . . . . . . . . . . . . . . . 19 4.2.7. Low-Latency Data . . . . . . . . . . . . . . . . . . 19 4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 20 Henry & Szigeti Expires April 19, 2019 [Page 2] Internet-Draft DIFFSERV-QCI October 2018 4.2.9. Standard . . . . . . . . . . . . . . . . . . . . . . 21 4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 21 4.3. Summary of Recommendations for DSCP-to-QCI Mapping . . . 21 5. QCI-to-DSCP Mapping Recommendations . . . . . . . . . . . . . 23 5.1. QCI and Diffserv Logic Reconciliation . . . . . . . . . . 23 5.2. Voice QCI [1] . . . . . . . . . . . . . . . . . . . . . . 25 5.3. IMS Signaling [5] . . . . . . . . . . . . . . . . . . . . 26 5.4. Voice-related QCIs [65, 66, 69] . . . . . . . . . . . . . 26 5.5. Video QCIs [67, 2, 4] . . . . . . . . . . . . . . . . . . 27 5.6. Live streaming and interactive gaming [7] . . . . . . . . 28 5.7. Low latency eMBB and AR/VR [80] . . . . . . . . . . . . . 28 5.8. V2X messaging [75,3,9] . . . . . . . . . . . . . . . . . 29 5.9. Automation and Transport [82, 83, 84, 85] . . . . . . . . 29 5.10. Non-mission-critical data [6,8,9] . . . . . . . . . . . . 30 5.11. Mission-critical data [70] . . . . . . . . . . . . . . . 31 5.12. Summary of Recommendations for QCI-to-DSCP Mapping . . . 31 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 7. Specific Security Considerations . . . . . . . . . . . . . . 33 8. Security Recommendations for General QoS . . . . . . . . . . 33 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 9.1. Normative References . . . . . . . . . . . . . . . . . . 34 9.2. Informative References . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction 3GPP has become the preferred set of standards to define cellular communication principles and protocols. With the augmented capabilities of smartphones, cellular networks increasingly carry non-communication traffic and interconnect with the Internet and Enterprise IP networks. The access networks defined by the 3GPP present several design challenges for ensuring end-to-end quality of service when these networks interconnect with the Internet or to enterprise networks. Some of these challenges relate to the nature of the cellular network itself, being centrally controlled, collision-free and primarily designed around subscription level and associated services, while other challenges relate to the fact that the 3GPP standards are not administered by the same standards body as Internet protocols. While 3GPP has developed tools to enabled QoS over cellular networks, little guidance exists on how to maintain consistency of QoS treatment between cellular networks and the Internet, or IP-based Enterprise networks. The purpose of this document is to provide such guidance. Henry & Szigeti Expires April 19, 2019 [Page 3] Internet-Draft DIFFSERV-QCI October 2018 1.1. Related Work Several RFCs outline Diffserv QoS recommendations over IP networks, including: [RFC2474] specifies the Diffserv Codepoint Field. This RFC also details Class Selectors, as well as the Default Forwarding (DF) treatment. [RFC2475] defines a Diffserv architecture [RFC3246] specifies the Expedited Forwarding (EF) Per-Hop Behavior (PHB) [RFC2597] specifies the Assured Forwarding (AF) PHB. [RFC3662] specifies a Lower Effort Per-Domain Behavior (PDB) [RFC4594] presents Configuration Guidelines for Diffserv Service Classes [RFC5127] presents the Aggregation of Diffserv Service Classes [RFC5865] specifies a DSCP for Capacity Admitted Traffic Note: [RFC4594] is intended to be viewed as a framework for supporting Diffserv in any network, regardless of the underlying data-link or physical layer protocols. As such, its principles could apply to IP traffic carried over cellular DataLink and Physical Layer mediums. Additionally, the principles of [RFC4594] apply to any traffic entering the Internet, regardless of its original source location. Thus, [RFC4594] describes different types of traffic expected in IP networks and provides guidance as to what DSCP marking(s) should be associated with each traffic type. As such, this document draws heavily on [RFC4594] , as well as [RFC5127], and [RFC8100]. In turn, the relevant standard for cellular QoS is 3GPP [TS 23.107], which defines more than 1600 General Packet Radio Service (GPRS) QoS profiles across multiple classes and associated attributes. As this quantity is large and source of potential complexity, the 3GPP Technical Specification Group Services and System Aspects, defining the Policy Charging Control Architecture, leverages a subset of QoS profiles used as QoS Class Identifiers (QCI). This document draws on this specification, which is being progressively updated; the current version of which (at the time of writing) is 3GPP [TS 23.203] v15.4. 1.2. Applicability Statement This document is applicable to the use of Differentiated Services that interconnect with 3GPP cellular networks (referred to as cellular, throughout this document, for simplicity). These guidelines are applicable whether cellular network endpoints are IP- enabled, in which case these guidelines can apply end-to-end, starting from the endpoint operating system, or whether cellular network endpoints are either not IP-enabled, or do not enable QoS, in which case these guidelines apply at the interconnection point between the cellular access network and the Internet or IP network. Henry & Szigeti Expires April 19, 2019 [Page 4] Internet-Draft DIFFSERV-QCI October 2018 Such interconnection point can commonly occur at the infrastructure Radio Unit (eNodeB), within the infrastructure core network (CN), or at the edge of the core network toward the Internet or an Enterprise IP network, for example within the Packet Data Network Gateway (P-GW). 1.3. Document Organization This document is organized as follows: o Section 2 introduces the QoS logic marking applicable to each domain. We introduce the general logic of Diffserv and the notion of domain boundary. We then examine the 3GPP QoS logic, detailing the concept of bearer and QCI, and showing how QCIs are implemented and used. o Section 3 provides general recommendations for QoS support at the 3GPP / Diffserv domains boundaries. o Section 4 proposes a Diffserv to QCI translation scheme, so as to carry DSCP values to the 3GPP domains when QCI must be used. o Section 5 proposes a reverse mapping, from QCI to Diffserv. As many QCIs' intents do not match existing DSCP value, new DSCP values are proposed wherever needed. o Section 6 underlines the resulting IANA requirements for this mapping. o Section 7 and Section 8 examine the security consequences of these new mapping schemes. 1.4. Requirements language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.5. Terminology Used in this Document Key terminology used in this document includes: EPS Bearer: a path that user traffic (IP flows) uses between the UE and the PGW. Henry & Szigeti Expires April 19, 2019 [Page 5] Internet-Draft DIFFSERV-QCI October 2018 GGSN: Gateway GPRS Support Node, responsible for the internetworking between the GPRS network and external networks. PGW performs the GGSN functionalities in EPC. IP BS Manager: Internet Protocol Bearer Service Manager, a function that manages the IP bearer services. Part of this function can include translation of QoS parameters between EPS and external networks. UE: User Equipment, the end-device. EPS Session: a PDN connection, comprised of one or more IP flows, that a UE established and maintains to the EPS. SAE: System Architecture Evolution. RAN: Radio access network, the radio segment of the LTE network EPS. EPC: Evolved Packet Core, the core segment of the LTE network EPS. EPS: Evolved Packet System, the LTE network, comprised of the RANs and EPC. HSS: Home Subscriber Server, the database that contains user-related and subscriber-related information. SGW: Serving Gateway, the point of interconnection between the RAN and the EPC. PGW: Packet Data Network Gateway, point of interconnection between the EPC and external IP networks. MME: Mobility Management Entity: software function that handles the signaling related to mobility and security for the access network. PCEF: Policy and Charging Enforcement Function, provides user traffic handling and QoS within the PGW. PCRF: Policy and Charging Rules Function, a functional entity that provides policy, bandwidth and charging functions for each EPS user. 2. Service Comparison and Default Interoperation of Diffserv and 3GPP LTE Henry & Szigeti Expires April 19, 2019 [Page 6] Internet-Draft DIFFSERV-QCI October 2018 2.1. Diffserv Domain Boundaries It is important to recognize that LTE standards allow support for principles of [RFC2475]. The user equipment (UE) application function may have no active QoS support, or may support Diffserv or IntServ functions [TS 23.207] v15 5.2.2. When Diffserv is supported, an Internet Protocol Bearer Service Manager (IP BS Manager) function integrated to the UE can translate Diffserv parameters into LTE QoS parameters (e.g. QCI). As such, the UE IP BS Manager function may act as a Diffserv domain boundary (as defined in [RFC2475]) between a Diffserv domain present within the UE networking stack and the LTE Radio Access Network. Additionally, the P-GW interconnects the UE data plane to the external networks. The P-GW is the element that implements Gateway GPRS (General Packet Radio Service) Support Node (GGSN) functionalities in Evolved Packet Core (EPS) networks. The GGSN includes an IP BS manager function that acts as a Diffserv Edge function, and can translate Diffserv parameters to LTE QoS parameters (e.g. QCI) and vice versa. As such, LTE standards allow the existence of a Diffserv domain within the UE and outside of the EPS boundaries. The Diffserv domain is not considered within the EPS, where QCIs are used to define and transport QoS parameters. 2.2. QCI and Bearer Model in 3GPP It is important to note that LTE standards (4G, 5G) are an evolution of UMTS standards (2G, 3G) developed in the 1990s. As such, these standards recognize [RFC2475] (1998), but not [RFC4594] (2006). EPS networks rely on the notion of bearers. A bearer is a conduit between the UE and the P-GW, and LTE supports two types of bearers: o GBR: Guaranteed Bit Rate bearers. These bearers allocate network resources associated to a GBR value associated to the bearer. These resources stay allocated (reserved) for the duration of the existence of the GBR bearer and the flow it carries. o Non-GBR bearers: also called default bearers, non-GBR are bearers for which network resources are not permanently allocated during the existence of the bearer and the flow it carries. As such, one or more non-GBR bearer may share the same set of temporal resources. Each EPS bearer is identified by a name and number, and is associated with specific QoS parameters of various types: Henry & Szigeti Expires April 19, 2019 [Page 7] Internet-Draft DIFFSERV-QCI October 2018 1. QoS Class Identifiers (QCI). A QCI is a scalar associated to a bearer, and is used to define the type of traffic and service expected in the bearer. [TS 23.107] v15 defines 4 basic classes: conversational, streaming, interactive and background. These classes are defined more in details in Section 2.3. Each class includes multiple types of traffic, each associated with sets of attributes, thus permitting the definition of more than 1600 different QoS profiles. [TS 23.203] v15 6.1.7.2 reduces the associated complexity by characterizing traffic based on up to 6 attributes, resulting in 21 types of traffic and their associated expected service requirements through the use of 21 scalars (QCI). Each QCI is defined in the relation to the following six performance characteristics: 2. Resource Type (GBR or Non-GBR). 3. Priority: a scalar used as a tie breaker if two packets compete for a given network resource. A lower value indicates a higher priority. 4. Packet Delay Budget: marks the upper bound for the time that a packet may be delayed between the UE and the PCRF (Policy and Charging Rules Function) or the PCEF function (Policy and Charging Enforcement Function) residing inside the P-GW. PCEF supports offline and online charging while PCRF is real-time. Either component, being in charge of policing and charging, can determine resource reservation actions and policies. 5. Packet Error Loss Rate, defines an upper bound for a rate of non- congestion related packet losses. The purpose of the PELR is to allow for appropriate link layer protocol configurations when needed. 6. Maximum Burst Size (only for some GBR QCIs), defines the amount of data which the Radio Access Network (RAN) is expected to deliver within the part of the Packet Delay Budget allocated to the link between the UE and the radio base station. If more data is transmitted from the application, the Packet Delay Budget may be exceeded. 7. Data rate Averaging Window (only for some GBR QCIs), defines the 'sliding window' duration over which the GBR and MBR are calculated. Although [TS 23.203] v15 6.1.7.2 associates each QCI with up to 6 characteristics, it is clear that these characteristics are constrained by bandwidth allocation, in particular on the radio link that are associated with three commonly used parameters: Henry & Szigeti Expires April 19, 2019 [Page 8] Internet-Draft DIFFSERV-QCI October 2018 1. Maximum Bit Rate (MBR), only valid for GBR bearers, defines the maximum sustained traffic rate that the bearer can support. 2. Guaranteed Bit Rate (GBR), only valid for GBR bearers, defines the minimum traffic rate reserved for the bearer. 3. Aggregate MBR (AMBR), defines the total amount of bit rate available for a group of non-GBR bearers. AMBR is often used to provide differentiated service levels to different types of customers. 2.3. QCI Definition and Logic [TS 23.107] v15 6.3 defines four possible traffic classes. These four general classes are used as the foundation from which QCI categories are defined in [TS 23.203]. The categorization is made around the notion of sensitivity to delay. 2.3.1. Conversational The conversational class is intended to carry real-time traffic flows. The expectation of such class is a live conversation between two humans or a group. Examples of such flows include [TS 23.107] v15 6.3.1 telephony speech, but also VoIP and video conferencing. Video conference would be seen as a different class from telephony in the Diffserv model. However, 3GPP positions them in the same general class, as all of them include live conversations. Sensitivity to delay is high because of the real-time nature of the flows. The time relation between the stream entities have to be preserved (to maintain the same experience for all flows and all parties involved in the conversation). 2.3.2. Streaming The streaming class is intended for flows where the user is watching real time video, or listening to real-time audio (or both). The real-time data flow is always aiming at a live (human) destination. It is important to note that the Streaming class is intended to be both a real-time flow and a one-way transport. Two-way real-time traffic belongs to the conversational class, and non-real-time flows belong to the interactive or the background classes. The delay sensitivity is lower than that of Conversational flows, because it is expected that the receiving end includes a time alignment function (e.g. buffering). As the flow is unidirectional, variations in delay do not conversely affect the user experience as long as the variation is within the alignment function boundaries. Henry & Szigeti Expires April 19, 2019 [Page 9] Internet-Draft DIFFSERV-QCI October 2018 2.3.3. Interactive The interactive class is intended for flows where a machine or human is requesting data from a remote equipment (e.g. a server). Examples of human interaction with the remote equipment are: web browsing, data base retrieval, server access. Examples of machines interaction with remote equipment are: polling for measurement records and automatic data base enquiries (tele-machines). Delay sensitivity is average, and is based on round trip time (overall time between emission of the request and reception of the response). 2.3.4. Background The background class applies to flows where the equipment is sending or receiving data files without direct user interaction (e.g. emails, SMS, database transfers etc.) As such, delay sensitivity is low. Background is described as delivery-time insensitive. Based upon the above principles, [TS 23.203] has defined several QCIs. [TS 23.203] Release 15 6.1.7-A defines 21 QCIs: +----+----------+----------+--------+--------+----------------------+ | QC | Resource | Priority | Packet | Packet | Example Services | | I | Type | Level | Delay | Error | | | | | | Budget | Loss | | +----+----------+----------+--------+--------+----------------------+ | 1 | GBR | 2 | 100 ms | 10.E-2 | Conversational Voice | | | | | | | | | 2 | GBR | 4 | 150 ms | 10.E-3 | Conversational Video | | | | | | | (Live Streaming) | | | | | | | | | 3 | GBR | 3 | 50 ms | 10.E-3 | Real Time Gaming, | | | | | | | V2X messages, | | | | | | | Electricity | | | | | | | distribution (medium | | | | | | | voltage) Process | | | | | | | automation | | | | | | | (monitoring) | | | | | | | | | 4 | GBR | 5 | 300 ms | 10.E-6 | Non-Conversational | | | | | | | Video (Buffered | | | | | | | Streaming) | | | | | | | | | 65 | GBR | 0.7 | 75 ms | 10.E-2 | Mission Critical | | | | | | | user plane Push To | | | | | | | Talk voice (e.g., | | | | | | | MCPTT) | | | | | | | | Henry & Szigeti Expires April 19, 2019 [Page 10] Internet-Draft DIFFSERV-QCI October 2018 | 66 | GBR | 2 | 100 ms | 10.E-2 | Non-Mission-Critical | | | | | | | user plane Push To | | | | | | | Talk voice | | | | | | | | | 67 | GBR | 1.5 | 100 ms | 10.E-3 | Mission Critical | | | | | | | Video user plane | | | | | | | | | 75 | GBR | 2.5 | 50 ms | 10.E-2 | V2X messages | | | | | | | | | 82 | GBR | 1.9 | 10 ms | 10.E-6 | Discrete automation | | | | | | | (small packets) | | | | | | | | | 83 | GBR | 2.2 | 10 ms | 10.E-4 | Discrete automation | | | | | | | (large packets) | | | | | | | | | 84 | GBR | 2.4 | 30 ms | 10.E-5 | Intelligent | | | | | | | Transport Systems | | | | | | | | | 85 | GBR | 2.1 | 5 ms | 10.E-5 | Electricity | | | | | | | Distribution - High | | | | | | | Voltage | | | | | | | | | 5 | Non-GBR | 1 | 100 ms | 10.E-6 | IMS Signalling | | | | | | | | | 6 | Non-GBR | 6 | 300 ms | 10.E-6 | Video (Buffered | | | | | | | Streaming) TCP-based | | | | | | | (e.g. www, email, | | | | | | | chat, ftp, p2p file | | | | | | | sharing, progressive | | | | | | | video) | | | | | | | | | 7 | Non-GBR | 7 | 100 ms | 10.E-3 | Voice, Video (live | | | | | | | streaming), | | | | | | | interactive gaming | | | | | | | | | 8 | Non-GBR | 8 | 300 ms | 10.E-6 | Video (buffered | | | | | | | streaming) TCP-based | | | | | | | (e.g. www, email, | | | | | | | chat, ftp, p2p file | | | | | | | sharing, progressive | | | | | | | video) | | | | | | | | | 9 | Non-GBR | 9 | 300 ms | 10.E-6 | Same as 8 | | | | | | | | | 69 | Non-GBR | 0.5 | 60 ms | 10.E-6 | Mission Critical | | | | | | | delay sensitive | | | | | | | signalling (e.g., | | | | | | | MC-PTT signalling, | Henry & Szigeti Expires April 19, 2019 [Page 11] Internet-Draft DIFFSERV-QCI October 2018 | | | | | | MC Video signalling) | | | | | | | | | 70 | Non-GBR | 5.5 | 200 ms | 10.E-6 | Mission Critical | | | | | | | Data (e.g. example | | | | | | | services are the | | | | | | | same as QCI 6/8/9) | | | | | | | | | 79 | Non-GBR | 6.5 | 50 ms | 10.E-2 | V2X messages | | | | | | | | | 80 | Non-GBR | 6.8 | 10 ms | 10.E-2 | Low latency eMMB | | | | | | | applications (TCP | | | | | | | /UDP-based); | | | | | | | augmented reality | +----+----------+----------+--------+--------+----------------------+ Several QCIs cover the same application types. For example, QCIs 6, 8 and 9 all apply to buffered streaming video and web applications. However, LTE context distinguishes several types of customers and environments. As such, QCI 6 can be used for the prioritization of non-real-time data (i.e. most typically TCP-based services/ applications) of MPS (multimedia priority services) subscribers, when the network supports MPS. QCI 8 can be used for a dedicated "premium bearer" (e.g. associated with premium content) for any subscriber or subscriber group, while QCI 9 can be used for the default bearer for non-privileged subscribers. 2.4. QCI implementations [TS 23.203] v15 defines multiple QCIs. However, a UE or a EPS does not need to implement all supported QCIs, even when all matching types of traffic are expected between the UE and the network. In practical implementations, it is common for an EPS to implement one GBR bearer where at least QCI 1 is directed (and optionally other GBR QCIs), and another default bearer where all other traffic to and from the same UE is directed. The QCI associated to that second bearer may depend on the subscriber category. As such, the QCI listed in Section 2.3 are indicative of performance and traffic type classifications, and are not strict in their implementation mandate. 2.5. GSMA IPX Guidelines Interpretation and Conflicts 3GPP standards do not define or recommend any specific mapping between each QCI and Diffserv, and leaves that mapping choice to the operator of the Edge domain boundary (e.g. UE software stack developer, P-GW operator). However, 3GPP defines that "for the IP based backbone, Differentiated Services defined by IETF shall be used" ([TS 23.107] v15 6.4.7). Henry & Szigeti Expires April 19, 2019 [Page 12] Internet-Draft DIFFSERV-QCI October 2018 The GSM Association (GSMA) has published an Inter-Service Provider IP Backbone Guideline reference document [IR.34] that provides technical guidance to participating service providers for connecting IP based networks and services to achieve roaming and inter-working services. The document built upon [RFC3246] and [RFC2597], and upon the initial definition of 4 service classes in [TS 23.107] v15 to recommend a mapping to EF for conversational traffic, to AF41 for Streaming traffic, to AF31, AF21 and AF11 for different traffic in the Interactive class, and to BE for background traffic. These GSMA Guidelines were developed without reference to existing IETF specifications for various services, referenced in Section 1.1. Additionally, the same recommendations remained while new traffic types under each 3GPP general class were added. As such, the GSMA recommendations yield to several inconsistencies with [RFC4594], including: o Recommending EF for real-time (conversational) video, for which [RFC4594] recommends AF41. o Recommending AF31 for DNS traffic, for which [RFC4594] recommends the standard service class (DF) o Recommending AF31 for all types of signaling traffic, thus losing the ability to differentiate between the various types of signaling flows, as recommended in[RFC4594] section 5.1. o Recommending AF21 for WAP browsing and WEB browsing, for which [RFC4594] recommends the High Throughput data class o Recommending AF11 for remote connection protocols, such as telnet or SSH, for which [RFC4594] recommends the OAM class. o Recommending DF for file transfers, for which [RFC4594] recommends the High Throughput Data class. o Recommending DF for email exchanges, for which [RFC4594] recommends the High Throughput Data class. o Recommending DF for MMS exchanged over SMTP, for which [RFC4594] recommends the High Throughput Data class. The document [IR.34] aso does not provide guidance for QCIs other than 1 to 9, leaving the case of the 12 other QCIs unaddressed. Thus, document [IR.34] conflicts with the overall Diffserv traffic- conditioning service plan, both in the services specified and the code points specified for them. As such, these two plans cannot be Henry & Szigeti Expires April 19, 2019 [Page 13] Internet-Draft DIFFSERV-QCI October 2018 normalized. Rather, as discussed in [RFC2474] Section 2, the two domains (GSMA and other IP networks) are different Differentiated Services Domains separated by a Differentiated Services Boundary. At that boundary, code points from one domain are translated to code points for the other, and maybe to Default (zero) if there is no corresponding service to translate to. 3. P-GW Device Marking and Mapping Capability Recommendations This document assumes and RECOMMENDS that all P-GWs (as the interconnects between cellular and other IP networks) and all other interconnection points between cellular and other IP networks support the ability to: o mark DSCP, per Diffserv standards o mark QCI, per the [TS 23.203] standard o support fully-configurable mappings between DSCP and QCI o process DSCP markings set by cellular endpoint devices This document further assumes and RECOMMENDS that all cellular endpoint devices (UE) support the ability to: o mark DSCP, per Diffserv standards o mark QCI, per the [TS 23.203] standard o support fully-configurable mappings between DSCP (set by applications in software) and QCI (set by the operating system and/or the LTE infrastructure) Having made the assumptions and recommendations above, it bears mentioning that while the mappings presented in this document are RECOMMENDED to replace the current common default practices (as discussed in Section 2.3 and Section 2.4), these mapping recommendations are not expected to fit every last deployment model, and as such MAY be overridden by network administrators, as needed. 4. DSCP-to-QCI Mapping Recommendations 4.1. Control Traffic Henry & Szigeti Expires April 19, 2019 [Page 14] Internet-Draft DIFFSERV-QCI October 2018 4.1.1. Network Control Protocols The Network Control service class is used for transmitting packets between network devices (e.g., routers) that require control (routing) information to be exchanged between nodes within the administrative domain, as well as across a peering point between different administrative domains. [RFC4594] Section 3.2 recommends that Network Control Traffic be marked CS6 DSCP. Additionally, as stated in [RFC4594] Section 3.1: "CS7 DSCP value SHOULD be reserved for future use, potentially for future routing or control protocols." Network Control service is not directly called by any specific QCI description, because 3GPP network control does not operate over UE data channels. It should be noted that encapsulated routing protocols for encapsulated or overlay networks (e.g., VPN, Network Virtualization Overlays, etc.) are not Network Control Traffic for any physical network at the cellular space; hence, they SHOULD NOT be marked with CS6 in the first place, and are not expected to be forwarded to the cellular data plane. However, when such network control traffic is forwarded, it is expected to receive a high priority and level of service. As such, packets marked to CS7 DSCP are RECOMMENDED to be mapped to QCI 82, thus benefiting from a dedicated bearer with low packet error loss rate (10.E-4) and low budget delay (10 ms). Similarly, it is RECOMMENDED to map Network Control Traffic marked CS6 to QCI 82, thereby admitting it to the Discrete Automation (GBR) category with a relative priority level of 1.9. 4.1.2. Operations, Administration, and Maintenance (OAM) The OAM (Operations, Administration, and Maintenance) service class is recommended for OAM&P (Operations, Administration, and Maintenance and Provisioning). The OAM service class can include network management protocols, such as SNMP, Secure Shell (SSH), TFTP, Syslog, etc., as well as network services, such as NTP, DNS, DHCP, etc. [RFC4594] Section 3.3, recommends that OAM traffic be marked CS2 DSCP. Applications using this service class require a low packet loss but are relatively not sensitive to delay. This service class is configured to provide good packet delivery for intermittent flows. As such, packets marked to CS2 are RECOMMENDED to be mapped to QCI 9, thus admitting it to the non-GBR Buffered video traffic, with a relative priority of 9. Henry & Szigeti Expires April 19, 2019 [Page 15] Internet-Draft DIFFSERV-QCI October 2018 4.2. User Traffic User traffic is defined as packet flows between different users or subscribers. It is the traffic that is sent to or from end-terminals and that supports a very wide variety of applications and services [RFC4594] Section 4. Network administrators can categorize their applications according to the type of behavior that they require and MAY choose to support all or a subset of the defined service classes. 4.2.1. Telephony The Telephony service class is recommended for applications that require real-time, very low delay, very low jitter, and very low packet loss for relatively constant-rate traffic sources (inelastic traffic sources). This service class SHOULD be used for IP telephony service. The fundamental service offered to traffic in the Telephony service class is minimum jitter, delay, and packet loss service up to a specified upper bound. [RFC4594] Section 4.1 recommends that Telephony traffic be marked EF DSCP. 3GPP [TS 23.203] describes two QCIs adapted to Voice traffic: QCI 1 (GBR) and QCI 7 (non-GBR). However, Telephony traffic as intended in [RFC4594] supposes resource allocation control. Telephony SHOULD be configured to receive guaranteed forwarding resources so that all packets are forwarded quickly. The Telephony service class SHOULD be configured to use Priority Queuing system. QCI 7 does not match these conditions. As such, packets marked to EF are RECOMMENDED to be mapped to QCI 1, thus admitting it to the GBR Conversational Voice category, with a relative priority of 2. 4.2.2. Signaling The Signaling service class is recommended for delay-sensitive client-server (e.g., traditional telephony) and peer-to-peer application signaling. Telephony signaling includes signaling between 1) IP phone and soft-switch, 2) soft-client and soft-switch, and 3) media gateway and soft-switch as well as peer-to-peer using various protocols. This service class is intended to be used for control of sessions and applications. [RFC4594] Section 4.2 recommends that Signaling traffic be marked CS5 DSCP. While Signaling is recommended to receive a superior level of service relative to the default class (i.e., relative to QCI 7), it does not require the highest level of service (i.e., GBR and very high priority). As such, it is RECOMMENDED to map Signaling traffic Henry & Szigeti Expires April 19, 2019 [Page 16] Internet-Draft DIFFSERV-QCI October 2018 marked CS5 DSCP to QCI 4, thereby admitting it to the GBR Non- conversational video category, with a relative priority level of 5. Note: Signaling traffic for native Voice dialer applications should be exchanged over a control channel, and is not expected to be forwarded in the data-plane. However, Signaling for non-native (OTT) applications may be carried in the data-plane. In this case, Signaling traffic is control-plane traffic from the perspective of the voice/video telephony overlay-infrastructure. As such, Signaling should be treated with preferential servicing versus other data-plane flows. 4.2.3. Multimedia Conferencing The Multimedia Conferencing service class is recommended for applications that require real-time service for rate-adaptive traffic. [RFC4594] Section 4.3 recommends Multimedia Conferencing traffic be marked AF4x (that is, AF41, AF42, and AF43, according to the rules defined in [RFC2475]. The Diffserv model allows for three values to allow for different relative priorities of flows of the same nature. The primary media type typically carried within the Multimedia Conferencing service class marked AF41 is video intended to be a component of a real-time exchange; as such, it is RECOMMENDED to map AF41 into the Conversational Video (Live Streaming) category, with a GBR. Specifically, it is RECOMMENDED to map AF41 to QCI 2, thereby admitting AF41 into the GBR Conversational Video, with a relative priority of 4. AF42 is typically reserved for video intended to be a component of real-time exchange, but which criticality is less than traffic carried with a marking of AF41. As such, it is RECOMMENDED to map AF42 into the Conversational Video (Live Streaming) category, with a GBR, but a lower priority than QCI 2. Specifically, it is RECOMMENDED to map AF42 to QCI 4, thereby admitting AF42 into the GBR Conversational Video, with a relative priority of 5. Traffic marked AF43 is typically used for real-time video exchange of lower criticality. As such, it is RECOMMENDED to map AF43 into the Conversational Video (Live Streaming) category, but without a GBR. Specifically, it is RECOMMENDED to map AF43 to QCI 7, thereby admitting AF437 into the non-GBR Voice, Video and Interactive gaming, with a relative priority of 7. Henry & Szigeti Expires April 19, 2019 [Page 17] Internet-Draft DIFFSERV-QCI October 2018 4.2.4. Real-Time Interactive The Real-Time Interactive service class is recommended for applications that require low loss and jitter and very low delay for variable-rate inelastic traffic sources. Such applications may include inelastic video-conferencing applications, but may also include gaming applications (as pointed out in [RFC4594] Sections 2.1 through 2.3 and Section 4.4. [RFC4594] Section 4.4 recommends Real- Time Interactive traffic be marked CS4 DSCP. The primary media type typically carried within the Real-Time Interactive service class is video; as such, it is RECOMMENDED to map this class into a low latency Category. Specifically, it is RECOMMENDED to map CS4 to QCI 80, thereby admitting Real-Time Interactive traffic into the non-GBR category Low Latency eMBB (enhanced Mobile Broadband) applications with a relative priority of 6.8. In cases where GBR is required, for example because a single bearer is allocated for all non-GBR traffic, using a GBR equivalent is also acceptable. In this case, it is RECOMMENDED to map CS4 to QCI 3, thereby admitting Real-Time Interactive traffic into the GBR category Real-time gaming, with a relative priority of 3. 4.2.5. Multimedia Streaming The Multimedia Streaming service class is recommended for applications that require near-real-time packet forwarding of variable-rate elastic traffic sources. Typically, these flows are unidirectional. [RFC4594] Section 4.5 recommends Multimedia Streaming traffic be marked AF3x (that is, AF31, AF32, and AF33, according to the rules defined in [RFC2475]. The primary media type typically carried within the Multimedia Streaming service class is video; as such, it is RECOMMENDED to map this class into a Video Category. Specifically, it is RECOMMENDED to map AF31 to QCI 4, thereby admitting AF31 into the GBR Non Conversational Video category, with a relative priority of 5. Flows marked with AF32 are expected to be of the same nature as flows marked with AF32, but with a lower criticality. As such, these flows may not require a dedicated bearer with GBR. Therefore, it is RECOMMENDED to map AF32 to QCI 6, thereby admitting AF32 traffic into the non-GBR category Video (Buffered Streaming) with a relative priority of 6. Flows marked with AF33 are expected to be of the same nature as flows marked with AF31 and AF32, but with the lowest criticality. As such, it is RECOMMENDED to map AF33 to QCI 8, thereby admitting AF33 Henry & Szigeti Expires April 19, 2019 [Page 18] Internet-Draft DIFFSERV-QCI October 2018 traffic into the non-GBR category Video (Buffered Streaming) with a relative priority of 8. 4.2.6. Broadcast Video The Broadcast Video service class is recommended for applications that require near-real-time packet forwarding with very low packet loss of constant rate and variable-rate inelastic traffic sources. Typically, these flows are unidirectional. [RFC4594] Section 4.6 recommends Broadcast Video traffic be marked CS3 DSCP. As directly implied by the name, the primary media type typically carried within the Broadcast Video service class is video; as such, it is RECOMMENDED to map this class into a Video Category. Specifically, it is RECOMMENDED to map CS3 to QCI 4, thereby admitting Multimedia Streaming into the GBR Non Conversational Video category, with a relative priority of 5. In cases where GBR availability is constrained, using a non-GBR equivalent is also acceptable. In this case, it is RECOMMENDED to map CS3 to QCI 6, thereby admitting Real-Time Interactive traffic into the non-GBR category Video with a relative priority of 6. 4.2.7. Low-Latency Data The Low-Latency Data service class is recommended for elastic and time-sensitive data applications, often of a transactional nature, where a user is waiting for a response via the network in order to continue with a task at hand. As such, these flows are considered foreground traffic, with delays or drops to such traffic directly impacting user productivity. [RFC4594] Section 4.7 recommends Low- Latency Data be marked AF2x (that is, AF21, AF22, and AF23, according to the rules defined in [RFC2475]. The primary media type typically carried within the Low-Latency Data service class is data; as such, it is RECOMMENDED to map this class into a data Category. Specifically, it is RECOMMENDED to map AF21 to QCI 70, thereby admitting AF21 into the non-GBR Mission Critical Data category, with a relative priority of 5.5. Flows marked with AF22 are expected to be of the same nature as flows marked with AF21, but with a lower criticality. Therefore, it is RECOMMENDED to map AF22 to QCI 6, thereby admitting AF22 traffic into the non-GBR category Video and TCP-based traffic, with a relative priority of 6. Flows marked with AF23 are expected to be of the same nature as flows marked with AF21 and AF22, but with the lowest criticality. As such, it is RECOMMENDED to map AF23 to QCI 8, thereby admitting AF23 Henry & Szigeti Expires April 19, 2019 [Page 19] Internet-Draft DIFFSERV-QCI October 2018 traffic into the non-GBR category Video and TCP-based traffic, with a relative priority of 8. It should be noted that a consequence of such classification is that AF22 is mapped to the same QCI as CS3, and AF23 is mapped to the same QCI as AF33. However, this overlap is unavoidable, as some QCIs express intents that are expressed in the Diffserv domain through distinct marking values, grouped in the 3GPP domain under the same general category. 4.2.8. High-Throughput Data The High-Throughput Data service class is recommended for elastic applications that require timely packet forwarding of variable-rate traffic sources and, more specifically, is configured to provide efficient, yet constrained (when necessary) throughput for TCP longer-lived flows. These flows are typically not user interactive. According to [RFC4594] Section 4.8 it can be assumed that this class will consume any available bandwidth and that packets traversing congested links may experience higher queuing delays or packet loss. It is also assumed that this traffic is elastic and responds dynamically to packet loss. [RFC4594] Section 4.8 recommends High- Throughput Data be marked AF1x (that is, AF11, AF12, and AF13, according to the rules defined in [RFC2475]. The primary media type typically carried within the High-Throughput Data service class is data; as such, it is RECOMMENDED to map this class into a data Category. Specifically, it is RECOMMENDED to map AF11 to QCI 6, thereby admitting AF11 into the non-GBR Video and TCP- based traffic category, with a relative priority of 6. Flows marked with AF12 are expected to be of the same nature as flows marked with AF11, but with a lower criticality. Therefore, it is RECOMMENDED to map AF12 to QCI 8, thereby admitting AF12 traffic into the non-GBR category Video and TCP-based traffic, with a relative priority of 8. Flows marked with AF13 are expected to be of the same nature as flows marked with AF11 and AF12, but with the lowest criticality. As such, it is RECOMMENDED to map AF13 to QCI 9, thereby admitting AF13 traffic into the non-GBR category Video and TCP-based traffic, with a relative priority of 9. It should be noted that a consequence of such classification is that AF11 is mapped to the same QCI as CS3 and AF22, AF12 is mapped to the same QCI as Af33 and AF23, and AF13 is mapped to the same QCI as CS2. However, this overlap is unavoidable, as some QCIs express intents Henry & Szigeti Expires April 19, 2019 [Page 20] Internet-Draft DIFFSERV-QCI October 2018 that are expressed in the Diffserv domain through distinct marking values, grouped in the 3GPP domain under the same general category. 4.2.9. Standard The Standard service class is recommended for traffic that has not been classified into one of the other supported forwarding service classes in the Diffserv network domain. This service class provides the Internet's "best-effort" forwarding behavior. [RFC4594] Section 4.9 states that the "Standard service class MUST use the Default Forwarding (DF) PHB". The Standard service class loosely corresponds to the default non-GBR bearer practice in 3GPP. Therefore, it is RECOMMENDED to map Standard service class traffic marked DF DSCP to QCI 9, thereby admitting it to the low priority Video and TCP-based traffic category, with a relative priority of 9. 4.2.10. Low-Priority Data The Low-Priority Data service class serves applications that the user is willing to accept without service assurances. This service class is specified in [RFC3662] and [LE-PHB]. [RFC3662] and [RFC4594] both recommend Low-Priority Data be marked CS1 DSCP. Note: This marking recommendation may change in the future, as [LE- PHB] defines a Lower Effort (LE) PHB for Low-Priority Data traffic and recommends an additional DSCP for this traffic. The Low-Priority Data service class does not have equivalent in the 3GPP domain, where all service is controlled and allocated differentially. As such, there is no clear QCI that could be labelled low priority below the best effort category. As such, it is RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to QCI 9, thereby admitting it to the low priority Video and TCP-based traffic category, with a relative priority of 9. 4.3. Summary of Recommendations for DSCP-to-QCI Mapping The table below summarizes the [RFC4594] DSCP marking recommendations mapped to 3GPP: Henry & Szigeti Expires April 19, 2019 [Page 21] Internet-Draft DIFFSERV-QCI October 2018 +------+-----------------+---------------+----------------+ | DSCP | Recommended QCI | Resource Type | Priority Level | +------+-----------------+---------------+----------------+ | CS7 | 82 | GBR | 1.9 | | | | | | | CS6 | 82 | GBR | 1.9 | | | | | | | EF | 1 | GBR | 2 | | | | | | | CS5 | 4 | GBR | 5 | | | | | | | AF43 | 7 | non-GBR | 7 | | | | | | | AF42 | 4 | GBR | 5 | | | | | | | AF41 | 2 | GBR | 4 | | | | | | | CS4 | 80 3 | non-BGR GBR | 6.8 3 | | | | | | | AF33 | 8 | non-GBR | 8 | | | | | | | AF32 | 6 | non-GBR | 6 | | | | | | | AF31 | 4 | GBR | 5 | | | | | | | CS3 | 85 | GBR | 2.1 | | | | | | | AF23 | 8 | Non-GBR | 8 | | | | | | | AF22 | 6 | Non-GBR | 6 | | | | | | | AF21 | 70 | Non-GBR | 5.5 | | | | | | | CS2 | 9 | Non-GBR | 9 | | | | | | | AF13 | 9 | Non-GBR | 9 | | | | | | | AF12 | 8 | Non-GBR | 8 | | | | | | | AF11 | 6 | Non-GBR | 6 | | | | | | | CS0 | 9 | Non-GBR | 9 | | | | | | | CS1 | 9 | Non-GBR | 6.8 | +------+-----------------+---------------+----------------+ Henry & Szigeti Expires April 19, 2019 [Page 22] Internet-Draft DIFFSERV-QCI October 2018 5. QCI-to-DSCP Mapping Recommendations Traffic travelling from the 3GPP domain toward the Internet or the enterprise domain may already display DSCP marking, if the UE is capable of marking DSCP along with, or without, upstream QCI marking, as detailed in Section 2.1. When Diffserv marking is present in the flows originating from the UE and transiting through the CN (Core Network), and if Diffserv marking are not altered or removed on the path toward the Diffserv domain, then the network can be considered as end-to-end Diffserv compliant. In this case, it is RECOMMENDED that the entity providing the translation from QCI to Diffserv ignores the QCI value and simply forwards unchanged the Diffserv values expressed by the UE in its various flows. This general recommendation is not expected to fit every last deployment model, and as such Diffserv marking MAY be overridden by network administrators, as needed, before the flows are forwarded to the Internet, the enterprise network or the Diffserv domain in general. Additionally, within a given Diffserv domain, it is generally NOT RECOMMENDED to pass through DSCP markings from unauthenticated, unidentified or unauthorized devices, as these are typically considered untrusted sources, as detailed in Section 7. Such risk is limited within the 3GPP domain where no upstream traffic is admitted without prior authentication of the UE. However, this risk exists when UE traffic is forwarded to an enterprise domain to which the UE does not belong. In cases where the UE is unable to apply Diffserv marking, or if these markings are modified or removed within the 3GPP domain, such that these markings may not represent the intent expressed by the UE, and in cases where the QCI is available to represent the flow intent, the recommendations in this section apply. 5.1. QCI and Diffserv Logic Reconciliation The QCIs are defined as relative priorities for traffic flows which are described by combinations of 6 or more parameters, as expressed in Section 2.2. As such, QCIs also represent flows in terms of multi-dimensional needs, not just in terms of relative priorities. This multi-dimensional logic is different from the Diffserv logic, where each traffic class is represented as a combination of needs relative to delay, jitter and loss. This characterization around three parameters allows for the construction of a fairly hierarchical traffic categorization infrastructure, where traffic with high sensitivity to delay and jitter also typically has high sensitivity to loss. Henry & Szigeti Expires April 19, 2019 [Page 23] Internet-Draft DIFFSERV-QCI October 2018 By contrast, the 3GPP QCI structure presents multiple points where dimensions cross one another with different or opposing vectors. For example, IMS signaling (QCI 5) is defined with very high priority (1), low loss tolerance (10-6), but is non-GBR and belongs to the signaling category. By contrast, Conversational voice (QCI 1) has lower priority (2) than IMS signaling, higher loss tolerance (10-2), yet benefits from a GBR. Fitting both QCIs 5 and 1 in a hierarchical model is challenging. At the same time, QCIs represents needs that can apply to different applications of various criticality but sending flows of the same nature. For example, QCIs 6, 8 and 9 all include voice traffic, video traffic, but also email or FTP. What distinguish these QCIs is the criticality of the associated traffic. Diffserv does not envisions voice and FTP as possibly belonging to the same class. As the same time, QCI 2 and QCI 9 include real-time voice traffic. Diffserv does not allow a type of traffic with stated sensitivity to loss, delay and jitter to be split into categories at both end of the priority spectrum. As such, it is not expected that QCIs can be mapped to the Diffserv model strictly and hierarchically. Instead, a better approach is to observe the various QCI categories, and analyze their intent. This process allows for the grouping of several QCIs into hierarchical groups, that can then be translated into ensembles coherent with the Diffserv logic. This approach, in turn, allows for incorporation of new QCIs as the 3GPP model continues to evolve. It should be noted, however, that such approach results in partial incompatibility. Some QCIs represent an intent that is simply not present in the Diffserv model. In that case, attempting to artificially stitch the QCI to an existing Diffserv traffic class and marking would be dangerous. QCI traffic forwarded to the Diffserv domain would be mixed with Diffserv traffic that would represent a very different intent. As such, the result of this classification is that some QCIs call for new Diffserv traffic classes and markings. This consequence is preferable to mixing traffic of different natures into the same pre- existing category. Each QCI is represented with 6 parameters, including an Example Services value. This parameter is representative of the QCI intent. Although [TS 23.203] summarizes each QCI intent, this standard is only a summary of more complex classification expressed in other 3GPP standards. It is often necessary to refer to these other standards to obtain a more complex description of each QCI and the multiple type of flows that each QCI represents. Henry & Szigeti Expires April 19, 2019 [Page 24] Internet-Draft DIFFSERV-QCI October 2018 For the purpose of this document, the QCI intent is the primary classification driver, along with the priority level. The secondary elements, such as priority, delay budget and loss tolerance allow for better refinement of the relative classifications of the QCIs. The resource types (GBR, non-GBR) provide additional visibility into the intent. Although 21 QCIs are listed in [TS 23.203], representing two bearer types (GBR, non-GBR), 20 priority values, 9 delay budget values, and 5 loss tolerance values, examining the intent surfaces 9 traffic families: 1. Voice QCI [1] (dialer / conversational voice) is its own group 2. Voice signaling [5] (IMS) is its own group 3. Voice related (other voice applications, including PTT) [65,66,69] 4. Video (conversational or not, mission critical or not) [67,2,4] 5. Live streaming / interactive gaming is its own group [7] 6. Low latency eMBB, AR/VR is its own group [80] 7. V2X messaging [75,3,9] 8. Automation and Transport [82, 83, 84, 85] 9. Non-mission-critical data [6,8,9] 10. Mission-critical data is its own group [70] 5.2. Voice QCI [1] Several QCIs are intended to carry voice traffic. However, QCI 1 stands apart from the others. Its category is Conversational Voice, but this QCI is intended to represent the VoLTE voice bearer, for dialer and emergency services. QCI 1 uses a GBR, and has a priority level of 2. Its packet delay budget is 100 ms (from UE to P-GW) with a packet error loss of at most 10.E-2. As the GBR is allocated by the infrastructure, QCI 1 is both admitted and allocated dedicated resources. As such, QCI 1 maps in intent and function to [RFC5865], Admitted Voice, and is RECOMMENDED for mapping to DSCP 44. Henry & Szigeti Expires April 19, 2019 [Page 25] Internet-Draft DIFFSERV-QCI October 2018 5.3. IMS Signaling [5] QCI 5 is intended for Signaling. This category does not represent signaling for VoLTE, as such signaling is not conducted over the UE data channels. Instead, QCI 5 is intended for IMS services. IP Multimedia System (IMS) is a framework for delivering multimedia services over IP networks. These services include real-time and video applications, and their signaling is recommended to be carried, whenever possible, using IETF protocols such as SIP. Being of signaling nature, QCI 5 is non-GBR. However, being critical to enabling IMS real-time applications, QCI has a high priority of 1. Its packet delay budget is 100 ms, but packet error loss rate very low, at less than 10.E-6. Overall, QCI 5 maps rather well to the intent of [RFC4594] signaling for real time applications, and as such is RECOMMENDED to map to [RFC4594] Signaling, CS5. 5.4. Voice-related QCIs [65, 66, 69] Several QCIs display the commonality of targeting voice (non-VoLTE) traffic: o QCI 65 is GBR, mission critical PTT voice, priority 0.7 o QCI 66 is GBR, non-mission critical PTT voice, priority 2 o QCI 69 is non-GBR, mission-critical PTT signaling, priority 0.5 These QCI are Voice in nature, and naturally fit into a proximity marking model with DSCP 46 and 44. Additionally, lower priority marks higher precedence intent in QCI. However, there is no model in [RFC4594] that distinguishes 3 classes of voice traffic. Therefore, new markings are unavoidable. As such, there is a need to group these markings in the Voice category (101 xxx), and to order 69, 65 and 66 with different markings to reflect their different priority levels. Among these three QCIs, 69 is non-GBR, intended for mission-critical PTT signaling, with the highest priority of the three, at 0.5. QCI 69 is intended for signaling, but is latency sensitive, with a low 60 ms delay budget and a low 10.E-6 loss tolerance. Being of Signaling nature for real time applications, QCI 69 has proximity of intent with CS5 (Voice signaling, 40), but this marking is already used by QCI 5. Therefore, it is RECOMMENDED to map QCI 69 to a new DSCP marking, 41. Similarly, QCI 66 is GBR and targeted for non-mission critical PTT voice, with a priority level of 2. QCI 66 is Voice in nature, and Henry & Szigeti Expires April 19, 2019 [Page 26] Internet-Draft DIFFSERV-QCI October 2018 GBR. However, QCI 66 is intended for non-mission-critical traffic, and has a lower priority than mission-critical Voice, a higher tolerance for delay (100 ms vs 75). As such, QCI 66 cannot fit within [RFC4594] model mapping real-time voice to the class EF (DSCP 46). Here again, a new marking is needed. As such, this QCI fits in intent and proximity closest to Admitted Voice, but is non-GBR, and therefore non-admitted, guiding a new suggested marking of 43. Then, QCI 65 is GBR, intended for mission critical PTT voice, with a relative low priority index of 0.7. QCI 65 receives GBR and is intended for mission critical traffic. Its priority is higher (0.7 vs 2) than QCI 66, but a lower priority (0.7 vs 0.5) than QCI 69. Additionally, QCI 65 cannot be represented by DSCP 44 (used by QCI 1), or DSCP 46 (use by non-GBR voice). As such, QCI 65 fits between QCI 69 and QCI 66, with a new suggested marking of 42. 5.5. Video QCIs [67, 2, 4] Although six different QCIs have example services that include some form of video traffic, three QCIs are video in nature, QCIs 67, 2, and 4. All 3 QCIs represent video streams and fit naturally in the AF4x category. However, these QCIs do not match [RFC4594] intent for multimedia conferencing, in that they are admitted (being associated to a GBR). They also do not match the category described by [RFC5865] for capacity-admitted traffic. Therefore, there is not a clear possible mapping for any of these QCIs to an existing AF4x category. In order to avoid mixing admitted and non-admitted video in the same class, it is necessary to associate these QCIs to new Diffserv classes. In particular, QCI 67 is GBR, intended for mission-critical video user plane. This QCI is video in nature, and matches traffic that is rate-adaptive, and real time. QCI 67 priority is high (1.5), with a tolerant delay budget (100ms) and rather low loss tolerance (10.E-3). QCI 67 is GBR. As such, its RECOMMENDED to map QCI 67 against the DSCP value closest to AF4x video with lowest discard eligibility (AF41), namely category 33. Similarly, QCI 2 is intended for conversational video (live streaming). This QCI 2 is also video in nature and associated to a GBR, however its priority is lower than QCI 67 (4 vs 1.5). Additionally, its delay budget is also larger (150 ms vs 100 ms). Its packet error loss is also 10.E-3. As such, QCI 2 fits well within a video queue, with a larger drop probability than QCI 67. Henry & Szigeti Expires April 19, 2019 [Page 27] Internet-Draft DIFFSERV-QCI October 2018 Therefore, it is RECOMMENDED to map QCI 2 to the video category with a Diffserv marking of 35. QCI 4 is intended for non-conversational video (buffered streaming), with a priority of 5. This QCI is also video in nature. Although it is buffered, it is admitted, being associated to a GBR. QCI 4 as a lower priority than QCI 67 and QCI 2, and a larger delay budget (300 ms vs 150/100). However, its packet loss tolerance is low (10.E-6). This combination makes it eligible for a video category, but with a higher drop probability than QCI 67 and 2. Therefore, it is RECOMMENDED to map QCI 4 to DSCP 37. 5.6. Live streaming and interactive gaming [7] QCI 7 is non-GBR and intended for live streaming voice or video interactive gaming. Its priority is 7. It is the only QCI targeting this particular traffic mix. In the Diffserv model, voice and video are different categories, and are also different from interactive gaming (real time interactive). In the 3GPP model, live streaming video and mission-critical video are defined in other queues with high priority (e.g. QCI 2 for video Live streaming, with a priority of 2, or QCI 67 for mission-critical video, with a priority of 1.5). By comparison, QCI 7 priority is relatively low (7), with a 100 ms budget delay and a comparatively rather high loss tolerance (10.E-3). As such, QCI 7 first well with bursty (e.g. video) and possibly rate adaptive flows, with possible drop probability. It is also non- admitted (non-GBR), and as such, fits close to [RFC4594] intent for multimedia conferencing, with high discard eligibility. Therefore, it is RECOMMENDED to map QCI 7 to the existing Diffserv category AF43. 5.7. Low latency eMBB and AR/VR [80] QCI 80 is intended for low latency eMBB (enhanced Mobile Broadband) applications, such as Augmented Reality of Virtual Reality (AR/VR). This QCI priority is 6.8,with a low packet delay budget of 10 ms, and a packet error loss rate of at most 10.E-6. QCI 80 is non-GBR, yet intended for real time applications. Traffic in the AR/VR category typically does not react dynamically to losses, requires bandwidth and a low and predictable delay. As such, QCI 80 matches closely the specifications for CS4. Therefore, it is RECOMMENDED to map QCI 80 to the existing category CS4. Henry & Szigeti Expires April 19, 2019 [Page 28] Internet-Draft DIFFSERV-QCI October 2018 5.8. V2X messaging [75,3,9] Three QCIs are intended specifically to carry Vehicle to Anything (V2X) traffic, QCIs 75, 3, and 79. All 3 QCIs are data in nature, and fit naturally into the AF2x category. However, two of these QCIs (75 and 3) are admitted (GBR), and therefore do not fit in the current Diffserv model. QCI 79 is non-admitted, but matches none of the AF2X categories in [RFC4594]. In particular, QCI 75 is GBR, with a rather high priority (2.5), a low delay budget (50 ms), but tolerance to losses (10E-2). Being low latency data in nature, QCI 75 fits well in the AF2X category. However, being admitted, it fits none of the existing markings. Being the highest traffic (in priority) in this low latency data family, QCI 75 is recommended to be mapped to a new category, as close as possible to the AF2X class, and with a low drop probability. As such, it is RECOMMENDED to map QCI 75 to DSCP 17. Similarly, QCI 3 is intended for V2X messages, but can also be used for Real time gaming, or Utility traffic (medium voltage distribution) or process automation monitoring. QCI 3 priority is 3. QCI 3 is data in nature, but GBR. Its delay budget is low (50 ms), but with some tolerance to loss (10E-3). QCI 3 is of the same type as QCI 75, but with a lower priority. Therefore, QCI 3 should be mapped to a category close to the category to which 75 is mapped, but with a higher drop probability. As such, it is RECOMMENDED to map QCI 3 to DSCP 19. Additionally, QCI 79 is also intended for V2X messages. QCI 79 similar in nature to QCIs 75 and 3, but is non-critical (non-GBR). Its priority is also lower (6.5). Its budget delay is similar to that of QCIs 75 and 3 (50 ms), and its packet error loss rate is similar to that of QCI 75 (10.E-2). QCI 79 partially matches AF2X, but is not elastic, and therefore cannot fit exactly in [RFC4594] model. As such, it is recommended to a mapping similar to QCI 75 and 3, with a higher drop probability. Therefore, it is RECOMMENDED to map QCI 79 to DSCP 21. 5.9. Automation and Transport [82, 83, 84, 85] QCI 84 is intended for intelligent transport systems. As such, its intent is close to the V2X messaging category. QCI 84 is also admitted (GBR). However, QCI 84 is intended for traffic with a smaller packet delay budget (30 ms vs 50 ms for QCI 75) and a smaller packet error loss maximum rate (10.E-6 vs 10.E-2 for QCI 75).As such, QCI 84 should be mapped against a category above that of QCIs 75 or Henry & Szigeti Expires April 19, 2019 [Page 29] Internet-Draft DIFFSERV-QCI October 2018 QCI 3. Being admitted, QCI 84 does not map easily into an existing category. As such, it is RECOMMENDED to map QCI 84 to category 31. QCI 85 is intended for electricity distribution (high voltage) communication. As such, it is close in intent to QCI 3. QCI 85 is also GBR. However, QCI 85 priority is lower than that of QCI 3 (2.1 vs 3). QCI 85 has also a very low packet delay budget (5 ms vs 50 ms for QCI 3) and low packet error loss rate (10.E-6 vs 10.E-3 for QCI 3). As such, QCI 84 should be mapped to a category higher than that of QCI 3,with a very low drop probability. As such, it is RECOMMENDED to map QCI 85 to category 25. QCIs 82 and 83 are both intended for discrete automation control traffic. QCI 82 represents traffic with a higher priority (1.9) than traffic matched to QCI 83 (priority 2.2). QCI 82 also expects smaller data bursts (255 bytes) than QCI 83 (1358 bytes). However, both QCIs are admitted (GBR), with the same low packet delay budget (10 ms) and packet error loss maximum rate (10.E-4). As such, QCIs 82 and 83 fit in the same general category, with a higher drop probability assigned to QCI 83. They also fit the general intent category of automation traffic types, with a priority higher than that of other M2M traffic types (e.g. V2X messages). As such, they fit well into the AF3X category. However, being both admitted (GBR), they do not easily map to any existing AF3X category, and require new categories. As such, it is RECOMMENDED to map QCI 82 to category 27. Similarly, it is RECOMMENDED to map QCI 83 to category 29. 5.10. Non-mission-critical data [6,8,9] QCIs 6, 8 and 8 are intended for non-GBR, Video or TCP data traffic. All 3 QCIs are data in nature, non-mission critical, relative low priority and therefore fit naturally into the AF1x category. The inclusion in these QCIs' intent of buffered video is an imperfect fit for AF1X. However, the intent of these QCIs is to match buffered, and non-mission critical traffic. As such, they match the intent of AF1X, even if the Diffserv model would not associate buffered video to non-mission critical, buffered and low priority traffic. The intent of all three QCIs is similar. The difference lies in their priority and criticality. QCI 6 has priority 6, a packet delay budget of 300 ms, and a packet error loss rate of at most 10.E-6. QCI 8 has a priority 8, a packet delay budget of 300 ms, and a packet error loss rate of at most 10.E-6. QCI 9 has priority 9, and also a packet delay budget of 300 Henry & Szigeti Expires April 19, 2019 [Page 30] Internet-Draft DIFFSERV-QCI October 2018 ms and a packet error loss rate of at most 10.E-6. As these three QCIs represent the same intent and are only different in their priority level, using discard eligibility to differentiate them is logical. As such, it is RECOMMENDED to map QCI 6 to category AF11. Similarly, it is RECOMMENDED to map QCI 8 to AF12. And logically, it is RECOMMENDED to map QCI 9 to AF13. 5.11. Mission-critical data [70] QCI 70 is non-GBR, intended for mission critical data, with a priority of 5.5, a packet delay budget of 200 ms and a packet error loss rate tolerance of at most 10.E-6. The traffic types intended for QCI 70 are the same as for QCIs 6,8,9 categories, namely buffered streaming video and TCP-based traffic, such as www, email, chat, FTP, P2P and other file sharing applications. However, QCI 70 is specifically intended for applications that are mission critical. For this reason, QCI 70 priority is higher than QCIs 6, 8 or 9 priorities (5.5 vs 6, 8 and 9 respectively). Therefore, QCI 70 fits well in the AF2x family, while 6,8,9 are in AF1x. As QCI 70 displays intermediate differentiated treatment, if also fits well with an intermediate discard eligibility. As such, it is RECOMMENDED to map QCI 70 to DSCP 20 (AF22). 5.12. Summary of Recommendations for QCI-to-DSCP Mapping The table below summarizes the 3GPP QCI to [RFC4594] DSCP marking recommendations: +-----+----------+----------+-------------------------+-------------+ | QCI | Resource | Priority | Example Services | Recommended | | | Type | Level | | DSCP (PHB) | +-----+----------+----------+-------------------------+-------------+ | 1 | GBR | 2 | Conversational Voice | 44 (VA) | | | | | | | | 2 | GBR | 4 | Conversational Video | 35 (N.A.) | | | | | (Live Streaming) | | | | | | | | | 3 | GBR | 3 | Real Time Gaming, V2X | 19 (N.A.) | | | | | messages, Electricity | | | | | | distribution (medium | | | | | | voltage) Process | | | | | | automation (monitoring) | | | | | | | | | 4 | GBR | 5 | Non-Conversational | 37 (N.A.) | | | | | Video (Buffered | | | | | | Streaming) | | | | | | | | | 65 | GBR | 0.7 | Mission Critical user | 42 (N.A.) | Henry & Szigeti Expires April 19, 2019 [Page 31] Internet-Draft DIFFSERV-QCI October 2018 | | | | plane Push To Talk | | | | | | voice (e.g., MCPTT) | | | | | | | | | 66 | GBR | 2 | Non-Mission-Critical | 43 (N.A.) | | | | | user plane Push To Talk | | | | | | voice | | | | | | | | | 67 | GBR | 1.5 | Mission Critical Video | 33 (N.A.) | | | | | user plane | | | | | | | | | 75 | GBR | 2.5 | V2X messages | 17 (N.A.) | | | | | | | | 82 | GBR | 1.9 | Discrete automation | 27 (N.A.) | | | | | (small packets) | | | | | | | | | 83 | GBR | 2.2 | Discrete automation | 29 (N.A.) | | | | | (large packets) | | | | | | | | | 84 | GBR | 2.4 | Intelligent Transport | 31 (N.A.) | | | | | Systems | | | | | | | | | 85 | GBR | 2.1 | Electricity | 25 (N.A.) | | | | | Distribution - High | | | | | | Voltage | | | | | | | | | 5 | Non-GBR | 1 | IMS Signalling | 40 (CS5) | | | | | | | | 6 | Non-GBR | 6 | Video (Buffered | 10 (AF11) | | | | | Streaming) TCP-based | | | | | | (e.g. www, email, chat, | | | | | | ftp, p2p file sharing, | | | | | | progressive video) | | | | | | | | | 7 | Non-GBR | 7 | Voice, Video (live | 38 (AF43) | | | | | streaming), interactive | | | | | | gaming | | | | | | | | | 8 | Non-GBR | 8 | Video (buffered | 12 (AF12) | | | | | streaming) TCP-based | | | | | | (e.g. www, email, chat, | | | | | | ftp, p2p file sharing, | | | | | | progressive video) | | | | | | | | | 9 | Non-GBR | 9 | Same as 8 | 14 (AF13) | | | | | | | | 69 | Non-GBR | 0.5 | Mission Critical delay | 41 (N.A.) | | | | | sensitive signalling | | | | | | (e.g., MC-PTT | | Henry & Szigeti Expires April 19, 2019 [Page 32] Internet-Draft DIFFSERV-QCI October 2018 | | | | signalling, MC Video | | | | | | signalling) | | | | | | | | | 70 | Non-GBR | 5.5 | Mission Critical Data | 20 (AF22) | | | | | (e.g. example services | | | | | | are the same as QCI | | | | | | 6/8/9) | | | | | | | | | 79 | Non-GBR | 6.5 | V2X messages | 21 (N.A.) | | | | | | | | 80 | Non-GBR | 6.8 | Low latency eMMB | 32 (CS4) | | | | | applications (TCP/UDP- | | | | | | based); augmented | | | | | | reality | | +-----+----------+----------+-------------------------+-------------+ 6. IANA Considerations This document allocates thirteen codepoints (17, 19, 21, 25, 27, 29, 31, 33, 35, 37, 41, 42 and 43), further detailed in Section 5, in Pool 1 of the code space defined by [RFC2474]. 7. Specific Security Considerations The recommendations in this document concern widely deployed wired and wireless network functionality, and, for that reason, do not present additional security concerns that do not already exist in these networks. 8. Security Recommendations for General QoS It may be possible for a wired or wireless device (which could be either a host or a network device) to mark packets (or map packet markings) in a manner that interferes with or degrades existing QoS policies. Such marking or mapping may be done intentionally or unintentionally by developers and/or users and/or administrators of such devices. To illustrate: A gaming application designed to run on a smartphone may request that all its packets be marked DSCP EF. Although the 3GPP infrastructure may only allocate a non-GBR default QCI (e.g. QCI 9) for this traffic, the translation point into the Internet domain may consider the DSCP marking instead of the allocated QCI, and forward this traffic with a marking of EF. This traffic may then interfere with QoS policies intended to provide priority services for business voice applications. Henry & Szigeti Expires April 19, 2019 [Page 33] Internet-Draft DIFFSERV-QCI October 2018 To mitigate such scenarios, it is RECOMMENDED to implement general QoS security measures, including: o Setting a traffic conditioning policy reflective of business objectives and policy, such that traffic from authorized users and/or applications and/or endpoints will be accepted by the network; otherwise, packet markings will be "bleached" (i.e., re- marked to DSCP DF). Additionally, Section 5 made it clear that it is generally NOT RECOMMENDED to pass through DSCP markings from unauthorized, unidentified and/or unauthenticated devices, as these are typically considered untrusted sources. This is especially relevant for Internet of Things (IoT) deployments, where tens of billions of devices with little or no security capabilities are being connected to LTE and IP networks, leaving them vulnerable to be utilized as agents for DDoS attacks. These attacks can be amplified with preferential QoS treatments, should the packet markings of such devices be trusted. o Policing EF marked packet flows, as detailed in [RFC2474] Section 7 and [RFC3246] Section 3. Finally, it should be noted that the recommendations put forward in this document are not intended to address all attack vectors leveraging QoS marking abuse. Mechanisms that may further help mitigate security risks of both wired and wireless networks deploying QoS include strong device- and/or user-authentication, access- control, rate-limiting, control-plane policing, encryption, and other techniques; however, the implementation recommendations for such mechanisms are beyond the scope of this document to address in detail. Suffice it to say that the security of the devices and networks implementing QoS, including QoS mapping between wired and wireless networks, merits consideration in actual deployments. 9. References 9.1. Normative References [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc- editor.org/info/rfc2474>. [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/ RFC2597, June 1999, <https://www.rfc-editor.org/info/ rfc2597>. Henry & Szigeti Expires April 19, 2019 [Page 34] Internet-Draft DIFFSERV-QCI October 2018 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, <https://www.rfc-editor.org/info/rfc3246>. [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic", RFC 5865, DOI 10.17487/RFC5865, May 2010, <https://www.rfc-editor.org/info/rfc5865>. 9.2. Informative References [IR.34] 3GPP, "Guidelines for IPX Provider networks - GSMA", August 2018, <https://www.gsma.com/newsroom/wp-content/ uploads//IR.34-v14.0-3.pdf>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/info/rfc2475>. [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort Per-Domain Behavior (PDB) for Differentiated Services", RFC 3662, DOI 10.17487/RFC3662, December 2003, <https://www.rfc-editor.org/info/rfc3662>. [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, DOI 10.17487/RFC4594, August 2006, <https://www.rfc- editor.org/info/rfc4594>. [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, February 2008, <https://www.rfc-editor.org/info/rfc5127>. [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, March 2017, <https://www.rfc-editor.org/info/rfc8100>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. Henry & Szigeti Expires April 19, 2019 [Page 35] Internet-Draft DIFFSERV-QCI October 2018 [TS23.107] 3GPP, "Quality of Service (QoS) concept and architecture v15.0", June 2018, <www.3gpp.org/dynareport/23107.htm>. [TS23.203] 3GPP, "Policy and charging control architecture v15.4", September 2018, <www.3gpp.org/dynareport/23203.htm>. [TS23.207] 3GPP, "End-to-End Quality of Service (QoS) concept and architecture v15.0", June 2018, <www.3gpp.org/ dynareport/23207.htm>. Authors' Addresses Jerome Henry Cisco Email: jerhenry@cisco.com Tim Szigeti Cisco Email: szigeti@cisco.com Henry & Szigeti Expires April 19, 2019 [Page 36]