idnits 2.17.1 draft-henry-tsvwg-diffserv-to-qci-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1759 has weird spacing: '...| Video user ...' == Line 1817 has weird spacing: '...| delay sensi...' == Line 1824 has weird spacing: '...ervices are t...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (April 13, 2020) is 1467 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '67' on line 1485 -- Looks like a reference, but probably isn't: '2' on line 1485 -- Looks like a reference, but probably isn't: '4' on line 1485 -- Looks like a reference, but probably isn't: '71' on line 1485 -- Looks like a reference, but probably isn't: '72' on line 1485 -- Looks like a reference, but probably isn't: '73' on line 1485 -- Looks like a reference, but probably isn't: '74' on line 1485 -- Looks like a reference, but probably isn't: '76' on line 1485 -- Looks like a reference, but probably isn't: '1' on line 1406 -- Looks like a reference, but probably isn't: '5' on line 1419 -- Looks like a reference, but probably isn't: '7' on line 1558 -- Looks like a reference, but probably isn't: '80' on line 1579 -- Looks like a reference, but probably isn't: '75' on line 1593 -- Looks like a reference, but probably isn't: '3' on line 1593 -- Looks like a reference, but probably isn't: '9' on line 1680 -- Looks like a reference, but probably isn't: '82' on line 1634 -- Looks like a reference, but probably isn't: '83' on line 1634 -- Looks like a reference, but probably isn't: '84' on line 1634 -- Looks like a reference, but probably isn't: '85' on line 1634 -- Looks like a reference, but probably isn't: '86' on line 1634 -- Looks like a reference, but probably isn't: '6' on line 1680 -- Looks like a reference, but probably isn't: '8' on line 1680 -- Looks like a reference, but probably isn't: '70' on line 1707 -- Looks like a reference, but probably isn't: '65' on line 1435 -- Looks like a reference, but probably isn't: '66' on line 1435 -- Looks like a reference, but probably isn't: '69' on line 1435 -- Obsolete informational reference (is this intentional?): RFC 3662 (Obsoleted by RFC 8622) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 28 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Henry 3 Internet-Draft T. Szigeti 4 Intended status: Informational Cisco 5 Expires: October 15, 2020 L. Contreras 6 Telefonica 7 April 13, 2020 9 Diffserv to QCI Mapping 10 draft-henry-tsvwg-diffserv-to-qci-04 12 Abstract 14 As communication devices become more hybrid, smart devices include 15 more media-rich communication applications, and the boundaries 16 between telecommunication and other applications becomes less clear. 17 Simultaneously, as the end-devices become more mobile, application 18 traffic transits more often between enterprise networks, the 19 Internet, and cellular telecommunication networks, sometimes using 20 simultaneously more than one path and network type. In this context, 21 it is crucial that quality of service be aligned between these 22 different environments. However, this is not always the case by 23 default, and cellular communication networks use a different QoS 24 nomenclature from the Internet and enterprise networks. This 25 document specifies a set of 3rd Generation Partnership Project (3GPP) 26 Quality of Service (QoS) Class Identifiers (QCI) and 5G QoS 27 Identifiers (5QI) to Differentiated Services Code Point (DSCP) 28 mappings, to reconcile the marking recommendations offered by the 29 3GPP with the recommendations offered by the IETF, so as to maintain 30 a consistent QoS treatment between cellular networks and the 31 Internet. This mapping can be used by enterprises or implementers 32 expecting traffic to flow through both types of network, and wishing 33 to align the QoS treatment applied to one network under their control 34 with the QoS treatment applied to the other network. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on October 15, 2020. 53 Copyright Notice 55 Copyright (c) 2020 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 4 72 1.2. Applicability Statement . . . . . . . . . . . . . . . . . 5 73 1.3. Document Organization . . . . . . . . . . . . . . . . . . 5 74 1.4. Requirements language . . . . . . . . . . . . . . . . . . 6 75 1.5. Terminology Used in this Document . . . . . . . . . . . . 6 76 2. Service Comparison and Default Interoperation of Diffserv and 77 3GPP LTE and 5G . . . . . . . . . . . . . . . . . . . . . . . 7 78 2.1. Diffserv Domain Boundaries . . . . . . . . . . . . . . . 7 79 2.2. QCI and Bearer Model in 3GPP . . . . . . . . . . . . . . 8 80 2.3. QCI Definition and Logic . . . . . . . . . . . . . . . . 9 81 2.3.1. Conversational . . . . . . . . . . . . . . . . . . . 9 82 2.3.2. Streaming . . . . . . . . . . . . . . . . . . . . . . 10 83 2.3.3. Interactive . . . . . . . . . . . . . . . . . . . . . 10 84 2.3.4. Background . . . . . . . . . . . . . . . . . . . . . 10 85 2.4. QCI implementations . . . . . . . . . . . . . . . . . . . 13 86 2.5. 5QI and flow-based QoS Model in 3GPP 5G . . . . . . . . . 13 87 2.6. GSMA IPX Guidelines Interpretation and Conflicts . . . . 17 88 3. P-GW Device Marking and Mapping Capability Recommendations . 18 89 4. DSCP to QCI or 5QI Mapping Recommendations . . . . . . . . . 19 90 4.1. Control Traffic . . . . . . . . . . . . . . . . . . . . . 19 91 4.1.1. Network Control Protocols . . . . . . . . . . . . . . 19 92 4.1.2. Operations, Administration, and Maintenance (OAM) . . 20 93 4.2. User Traffic . . . . . . . . . . . . . . . . . . . . . . 20 94 4.2.1. Telephony . . . . . . . . . . . . . . . . . . . . . . 21 95 4.2.2. Signaling . . . . . . . . . . . . . . . . . . . . . . 21 96 4.2.3. Multimedia Conferencing . . . . . . . . . . . . . . . 22 97 4.2.4. Real-Time Interactive . . . . . . . . . . . . . . . . 22 98 4.2.5. Multimedia Streaming . . . . . . . . . . . . . . . . 23 99 4.2.6. Broadcast Video . . . . . . . . . . . . . . . . . . . 23 100 4.2.7. Low-Latency Data . . . . . . . . . . . . . . . . . . 24 101 4.2.8. High-Throughput Data . . . . . . . . . . . . . . . . 25 102 4.2.9. Standard . . . . . . . . . . . . . . . . . . . . . . 25 103 4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . . 26 104 4.3. Summary of Recommendations for DSCP-to-QCI Mapping . . . 26 105 5. QCI and 5QI to DSCP Mapping Recommendations . . . . . . . . . 28 106 5.1. QCI, 5QI and Diffserv Logic Reconciliation . . . . . . . 28 107 5.2. Voice [1] . . . . . . . . . . . . . . . . . . . . . . . . 31 108 5.3. IMS Signaling [5] . . . . . . . . . . . . . . . . . . . . 31 109 5.4. Voice-related QCIs and 5QIs [65, 66, 69] . . . . . . . . 31 110 5.5. Video QCIs and 5QIs [67, 2, 4, 71, 72, 73, 74, 76] . . . 32 111 5.6. Live streaming and interactive gaming [7] . . . . . . . . 34 112 5.7. Low latency eMBB and AR/VR [80] . . . . . . . . . . . . . 34 113 5.8. V2X messaging [75,3,9] . . . . . . . . . . . . . . . . . 35 114 5.9. Automation and Transport [82, 83, 84, 85, 86] . . . . . . 35 115 5.10. Non-mission-critical data [6,8,9] . . . . . . . . . . . . 36 116 5.11. Mission-critical data [70] . . . . . . . . . . . . . . . 37 117 5.12. Summary of Recommendations for QCI or 5QI to DSCP Mapping 37 118 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 119 7. Specific Security Considerations . . . . . . . . . . . . . . 40 120 8. Security Recommendations for General QoS . . . . . . . . . . 40 121 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 122 9.1. Normative References . . . . . . . . . . . . . . . . . . 41 123 9.2. Informative References . . . . . . . . . . . . . . . . . 42 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 126 1. Introduction 128 3GPP has become the preferred set of standards to define cellular 129 communication principles and protocols. With the augmented 130 capabilities of smartphones, cellular networks increasingly carry 131 non-communication traffic and interconnect with the Internet and 132 Enterprise IP networks. The access networks defined by the 3GPP 133 present several design challenges for ensuring end-to-end quality of 134 service when these networks interconnect with the Internet or to 135 enterprise networks. Some of these challenges relate to the nature 136 of the cellular network itself, being centrally controlled, 137 collision-free and primarily designed around subscription level and 138 associated services, while other challenges relate to the fact that 139 the 3GPP standards are not administered by the same standards body as 140 Internet protocols. While 3GPP has developed tools to enable QoS 141 over cellular networks, little guidance exists on how to maintain 142 consistency of QoS treatment between cellular networks and the 143 Internet, or IP-based Enterprise networks. As such, enterprises and 144 other operators managing traffic flowing through both 3GPP and 145 Internet Protocol links do not always know how to translate 3GPP QoS 146 identifiers into Internet Protocol QoS identifiers and vice versa.The 147 purpose of this document is to provide such guidance. 149 1.1. Related Work 151 Several RFCs outline Diffserv QoS recommendations over IP networks, 152 including: 154 [RFC2474] specifies the Diffserv Codepoint Field. This RFC also 155 details Class Selectors, as well as the Default Forwarding (DF) 156 treatment. [RFC2475] defines a Diffserv architecture [RFC3246] 157 specifies the Expedited Forwarding (EF) Per-Hop Behavior (PHB) 158 [RFC2597] specifies the Assured Forwarding (AF) PHB. [RFC3662] 159 specifies a Lower Effort Per-Domain Behavior (PDB) [RFC4594] presents 160 Configuration Guidelines for Diffserv Service Classes [RFC5127] 161 presents the Aggregation of Diffserv Service Classes [RFC5865] 162 specifies a DSCP for Capacity Admitted Traffic [RFC8622] presents the 163 Lower-Effort Per-Hop Behavior (LE-PHB) for Diffserv 165 Note: [RFC4594] is intended to be viewed as a framework for 166 supporting Diffserv in any network, regardless of the underlying 167 data-link or physical layer protocols. Its principles could apply to 168 IP traffic carried over cellular DataLink and Physical Layer mediums. 169 Additionally, the principles of [RFC4594] apply to any traffic 170 entering the Internet, regardless of its original source location. 171 Thus, [RFC4594] describes different types of traffic expected in IP 172 networks and provides guidance as to what DSCP marking(s) should be 173 associated with each traffic type. As such, this document draws 174 heavily on [RFC4594] , as well as [RFC5127], and [RFC8100]. 176 In turn, the relevant standard for cellular LTE QoS is 3GPP [TS 177 23.107], which defines more than 1600 General Packet Radio Service 178 (GPRS) QoS profiles across multiple classes and associated 179 attributes. As this quantity is large and source of potential 180 complexity, the 3GPP Technical Specification Group Services and 181 System Aspects, defining the Policy Charging Control Architecture, 182 leverages a subset of QoS profiles used as QoS Class Identifiers 183 (QCI). For 5G communications, [TS 23.501] defines 5G QoS 184 Identifiers. This document draws on these specifications, which are 185 being progressively updated; the current version of which (at the 186 time of writing) are 3GPP [TS 23.203] v16.2.0 and 3GPP [TS 23.501] 187 v16.3.0. 189 1.2. Applicability Statement 191 This document is applicable to the use of Differentiated Services 192 that interconnect with 3GPP LTE or 5G cellular networks (referred to 193 as cellular, throughout this document, for simplicity). These 194 guidelines are applicable whether cellular network endpoints are IP- 195 enabled, in which case these guidelines can apply end-to-end, 196 starting from the endpoint operating system, or whether cellular 197 network endpoints are either not IP-enabled, or do not enable QoS, in 198 which case these guidelines apply at the interconnection point 199 between the cellular access network and the Internet or IP network. 200 Such interconnection point can commonly occur at the infrastructure 201 Radio Unit (eNodeB), within the infrastructure core network (CN), or 202 at the edge of the core network toward the Internet or an Enterprise 203 IP network, for example within the Packet Data Network Gateway 204 (P-GW). 206 1.3. Document Organization 208 This document is organized as follows: 210 o Section 2 introduces the QoS logic marking applicable to each 211 domain. We introduce the general logic of Diffserv and the notion 212 of domain boundary. We then examine the 3GPP QoS logic, detailing 213 the concept of bearer, QCI and 5QIs, and showing how QCIs and 5QIs 214 are implemented and used. 216 o Section 3 provides general recommendations for QoS support at the 217 3GPP / Diffserv domains boundaries. 219 o Section 4 proposes a Diffserv to QCI translation scheme, so as to 220 suggest DSCP values that can be directly translated into QCIs or 221 5QIs values, when traffic moves into a 3GPP domain where QCIs or 222 5QIs must be used. 224 o Section 5 proposes a reverse mapping, from QCI to Diffserv. As 225 many QCIs intents do not match existing DSCP values, new DSCP 226 values are proposed wherever needed. 228 o Section 6 underlines the resulting IANA requirements for this 229 mapping. 231 o Section 7 and Section 8 examine the security consequences of these 232 new mapping schemes. 234 1.4. Requirements language 236 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 237 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 238 "OPTIONAL" in this document are to be interpreted as described in in 239 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 240 capitals, as shown here. 242 1.5. Terminology Used in this Document 244 Key terminology used in this document includes: 246 EPS Bearer: a path that user traffic (IP flows) uses between the UE 247 and the PGW. 249 GGSN: Gateway GPRS Support Node, responsible for the internetworking 250 between the GPRS network and external networks. PGW performs the 251 GGSN functionalities in EPC. 253 IP BS Manager: Internet Protocol Bearer Service Manager, a function 254 that manages the IP bearer services. Part of this function can 255 include translation of QoS parameters between EPS and external 256 networks. 258 UE: User Equipment, the end-device. 260 EPS Session: a PDN connection, comprised of one or more IP flows, 261 that a UE established and maintains to the EPS. 263 SAE: System Architecture Evolution. 265 RAN: Radio access network, the radio segment of the LTE network EPS. 267 EPC: Evolved Packet Core, the core segment of the LTE network EPS. 269 EPS: Evolved Packet System, the LTE network, comprised of the RANs 270 and EPC. 272 HSS: Home Subscriber Server, the database that contains user-related 273 and subscriber-related information. 275 LUS: Live Uplink Streaming, a video flow (often real-time) sent from 276 a source to a sink. 278 SGW: Serving Gateway, the point of interconnection between the RAN 279 and the EPC. 281 PGW: Packet Data Network Gateway, point of interconnection between 282 the EPC and external IP networks. 284 MME: Mobility Management Entity: software function that handles the 285 signaling related to mobility and security for the access network. 287 PCEF: Policy and Charging Enforcement Function, provides user traffic 288 handling and QoS within the PGW. 290 PCRF: Policy and Charging Rules Function, a functional entity that 291 provides policy, bandwidth and charging functions for each EPS user. 293 2. Service Comparison and Default Interoperation of Diffserv and 3GPP 294 LTE and 5G 296 2.1. Diffserv Domain Boundaries 298 It is important to recognize that 3GPP standards allow support for 299 principles of [RFC2475]. The user equipment (UE) application 300 function may have no active QoS support, or may support Diffserv or 301 IntServ functions [TS 23.207] v15 5.2.2. When Diffserv is supported, 302 an Internet Protocol Bearer Service Manager (IP BS Manager) function 303 integrated to the UE can translate Diffserv parameters into LTE QoS 304 parameters (e.g. QCI). As such, the UE IP BS Manager function may 305 act as a Diffserv domain boundary (as defined in [RFC2475]) between a 306 Diffserv domain present within the UE networking stack and the LTE 307 Radio Access Network. 309 Additionally, the P-GW interconnects the UE data plane to the 310 external networks. The P-GW is the element that implements Gateway 311 GPRS (General Packet Radio Service) Support Node (GGSN) 312 functionalities in Evolved Packet Core (EPS) networks. The GGSN 313 includes an IP BS manager function that acts as a Diffserv Edge 314 function, and can translate Diffserv parameters to 3GPP QoS 315 parameters (e.g. QCI or 5G NSA 5QI) and vice versa. In SA 5G, the 316 user plane and control plane are separated, and the P-GW for the user 317 plane (PGW-U) joins the Service Gateway (SGW-U) into the User Plane 318 Function (UPF). 320 As such, 3GPP standards allow the existence of a Diffserv domain 321 within the UE and outside of the EPS boundaries. The Diffserv domain 322 is not considered within the EPS, where QCIs or 5QIs are used to 323 define and transport QoS parameters. 325 2.2. QCI and Bearer Model in 3GPP 327 It is important to note that LTE (4G) and 5G standards are an 328 evolution of UMTS standards (2G, 3G) developed in the 1990s. As 329 such, these standards recognize [RFC2475] (1998), but not [RFC4594] 330 (2006). EPS networks rely on the notion of bearers. A bearer is a 331 conduit between the UE and the P-GW, and LTE supports two types of 332 bearers: 334 o GBR: Guaranteed Bit Rate bearers. These bearers allocate network 335 resources associated to a GBR value associated to the bearer. 336 These resources stay allocated (reserved) for the duration of the 337 existence of the GBR bearer and the flow it carries. 339 o Non-GBR bearers: also called default bearers, non-GBR are bearers 340 for which network resources are not permanently allocated during 341 the existence of the bearer and the flow it carries. As such, one 342 or more non-GBR bearer may share the same set of temporal 343 resources. 345 Each EPS bearer is identified by a name and number, and is associated 346 with specific QoS parameters of various types: 348 1. QoS Class Identifiers (QCI). A QCI is a scalar associated to a 349 bearer, and is used to define the type of traffic and service 350 expected in the bearer. [TS 23.107] v15 defines 4 basic classes: 351 conversational, streaming, interactive and background. These 352 classes are defined more in details in Section 2.3. Each class 353 includes multiple types of traffic, each associated with sets of 354 attributes, thus permitting the definition of more than 1600 355 different QoS profiles. [TS 23.203] v16 6.1.7.2 reduces the 356 associated complexity by characterizing traffic based on up to 6 357 attributes, resulting in 26 types of traffic and their associated 358 expected service requirements through the use of 26 scalars 359 (QCI). Each QCI is defined in the relation to the following six 360 performance characteristics: 362 2. Resource Type (GBR or Non-GBR). 364 3. Priority: a scalar used as a tie breaker if two packets compete 365 for a given network resource. A lower value indicates a higher 366 priority. 368 4. Packet Delay Budget: marks the upper bound for the time that a 369 packet may be delayed between the UE and the PCRF (Policy and 370 Charging Rules Function) or the PCEF function (Policy and 371 Charging Enforcement Function) residing inside the P-GW. PCEF 372 supports offline and online charging while PCRF is real-time. 374 Either component, being in charge of policing and charging, can 375 determine resource reservation actions and policies. 377 5. Packet Error Loss Rate, defines an upper bound for a rate of non- 378 congestion related packet losses. The purpose of the PELR is to 379 allow for appropriate link layer protocol configurations when 380 needed. 382 6. Maximum Burst Size (only for some GBR QCIs), defines the amount 383 of data which the Radio Access Network (RAN) is expected to 384 deliver within the part of the Packet Delay Budget allocated to 385 the link between the UE and the radio base station. If more data 386 is transmitted from the application, the Packet Delay Budget may 387 be exceeded. 389 7. Data rate Averaging Window (only for some GBR QCIs), defines the 390 'sliding window' duration over which the GBR and MBR are 391 calculated. 393 Although [TS 23.203] v16 6.1.7.2 associates each QCI with up to 6 394 characteristics, it is clear that these characteristics are 395 constrained by bandwidth allocation, in particular on the radio link 396 that are associated with three commonly used parameters: 398 1. Maximum Bit Rate (MBR), only valid for GBR bearers, defines the 399 maximum sustained traffic rate that the bearer can support. 401 2. Guaranteed Bit Rate (GBR), only valid for GBR bearers, defines 402 the minimum traffic rate reserved for the bearer. 404 3. Aggregate MBR (AMBR), defines the total amount of bit rate 405 available for a group of non-GBR bearers. AMBR is often used to 406 provide differentiated service levels to different types of 407 customers. 409 2.3. QCI Definition and Logic 411 [TS 23.107] v15 6.3 defines four possible traffic classes. These 412 four general classes are used as the foundation from which QCI 413 categories are defined in [TS 23.203]. The categorization is made 414 around the notion of sensitivity to delay. 416 2.3.1. Conversational 418 The conversational class is intended to carry real-time traffic 419 flows. The expectation of such class is a live conversation between 420 two humans or a group. Examples of such flows include [TS 23.107] 421 v15 6.3.1 telephony speech, but also VoIP and video conferencing. 423 Video conference would be seen as a different class from telephony in 424 the Diffserv model. However, 3GPP positions them in the same general 425 class, as all of them include live conversations. Sensitivity to 426 delay is high because of the real-time nature of the flows. The time 427 relation between the stream entities have to be preserved (to 428 maintain the same experience for all flows and all parties involved 429 in the conversation). 431 2.3.2. Streaming 433 The streaming class is intended for flows where the user is watching 434 real time video, or listening to real-time audio (or both). The 435 real-time data flow is always aiming at a live (human) destination. 436 It is important to note that the Streaming class is intended to be 437 both a real-time flow and a one-way transport. Two-way real-time 438 traffic belongs to the conversational class, and non-real-time flows 439 belong to the interactive or the background classes. The delay 440 sensitivity is lower than that of Conversational flows, because it is 441 expected that the receiving end includes a time alignment function 442 (e.g. buffering). As the flow is unidirectional, variations in delay 443 do not conversely affect the user experience as long as the variation 444 is within the alignment function boundaries. 446 2.3.3. Interactive 448 The interactive class is intended for flows where a machine or human 449 is requesting data from a remote equipment (e.g. a server). Examples 450 of human interaction with the remote equipment are: web browsing, 451 data base retrieval, server access. Examples of machines interaction 452 with remote equipment are: polling for measurement records and 453 automatic data base enquiries (tele-machines). Delay sensitivity is 454 average, and is based on round trip time (overall time between 455 emission of the request and reception of the response). 457 2.3.4. Background 459 The background class applies to flows where the equipment is sending 460 or receiving data files without direct user interaction (e.g. emails, 461 SMS, database transfers etc.) As such, delay sensitivity is low. 462 Background is described as delivery-time insensitive. 464 Based upon the above principles, [TS 23.203] has defined several 465 QCIs. [TS 23.203] Release 16 6.1.7-A defines 26 QCIs: 467 +----+----------+----------+--------+--------+----------------------+ 468 | QC | Resource | Priority | Packet | Packet | Example Services | 469 | I | Type | Level | Delay | Error | | 470 | | | | Budget | Loss | | 471 +----+----------+----------+--------+--------+----------------------+ 472 | 1 | GBR | 2 | 100 ms | 10.E-2 | Conversational Voice | 473 | | | | | | | 474 | 2 | GBR | 4 | 150 ms | 10.E-3 | Conversational Video | 475 | | | | | | (Live Streaming) | 476 | | | | | | | 477 | 3 | GBR | 3 | 50 ms | 10.E-3 | Real Time Gaming, | 478 | | | | | | V2X messages, | 479 | | | | | | Electricity | 480 | | | | | | distribution (medium | 481 | | | | | | voltage) Process | 482 | | | | | | automation | 483 | | | | | | (monitoring) | 484 | | | | | | | 485 | 4 | GBR | 5 | 300 ms | 10.E-6 | Non-Conversational | 486 | | | | | | Video (Buffered | 487 | | | | | | Streaming) | 488 | | | | | | | 489 | 65 | GBR | 0.7 | 75 ms | 10.E-2 | Mission Critical | 490 | | | | | | user plane Push To | 491 | | | | | | Talk voice (e.g., | 492 | | | | | | MCPTT) | 493 | | | | | | | 494 | 66 | GBR | 2 | 100 ms | 10.E-2 | Non-Mission-Critical | 495 | | | | | | user plane Push To | 496 | | | | | | Talk voice | 497 | | | | | | | 498 | 67 | GBR | 1.5 | 100 ms | 10.E-3 | Mission Critical | 499 | | | | | | Video user plane | 500 | | | | | | | 501 | 75 | GBR | 2.5 | 50 ms | 10.E-2 | V2X messages | 502 | | | | | | | 503 | 71 | GBR | 5.6 | 150 ms | 10.E-6 | "Live" Uplink | 504 | | | | | | Streaming | 505 | | | | | | | 506 | 72 | GBR | 5.6 | 300 ms | 10.E-4 | "Live" Uplink | 507 | | | | | | Streaming | 508 | | | | | | | 509 | 73 | GBR | 5.6 | 300 ms | 10.E-8 | "Live" Uplink | 510 | | | | | | Streaming | 511 | | | | | | | 512 | 74 | GBR | 5.6 | 500 ms | 10.E-8 | "Live" Uplink | 513 | | | | | | Streaming | 514 | | | | | | | 515 | 76 | GBR | 5.6 | 500 ms | 10.E-4 | "Live" Uplink | 516 | | | | | | Streaming | 517 | | | | | | | 518 | 5 | Non-GBR | 1 | 100 ms | 10.E-6 | IMS Signalling | 519 | | | | | | | 520 | 6 | Non-GBR | 6 | 300 ms | 10.E-6 | Video (Buffered | 521 | | | | | | Streaming) TCP-based | 522 | | | | | | (e.g. www, email, | 523 | | | | | | chat, ftp, p2p file | 524 | | | | | | sharing, progressive | 525 | | | | | | video) | 526 | | | | | | | 527 | 7 | Non-GBR | 7 | 100 ms | 10.E-3 | Voice, Video (live | 528 | | | | | | streaming), | 529 | | | | | | interactive gaming | 530 | | | | | | | 531 | 8 | Non-GBR | 8 | 300 ms | 10.E-6 | Video (buffered | 532 | | | | | | streaming) TCP-based | 533 | | | | | | (e.g. www, email, | 534 | | | | | | chat, ftp, p2p file | 535 | | | | | | sharing, progressive | 536 | | | | | | video) | 537 | | | | | | | 538 | 9 | Non-GBR | 9 | 300 ms | 10.E-6 | Same as 8 | 539 | | | | | | | 540 | 69 | Non-GBR | 0.5 | 60 ms | 10.E-6 | Mission Critical | 541 | | | | | | delay sensitive | 542 | | | | | | signalling (e.g., | 543 | | | | | | MC-PTT signalling, | 544 | | | | | | MC Video signalling) | 545 | | | | | | | 546 | 70 | Non-GBR | 5.5 | 200 ms | 10.E-6 | Mission Critical | 547 | | | | | | Data (e.g. example | 548 | | | | | | services are the | 549 | | | | | | same as QCI 6/8/9) | 550 | | | | | | | 551 | 79 | Non-GBR | 6.5 | 50 ms | 10.E-2 | V2X messages | 552 | | | | | | | 553 | 80 | Non-GBR | 6.8 | 10 ms | 10.E-2 | Low latency eMMB | 554 | | | | | | applications | 555 | | | | | | (TCP/UDP-based); | 556 | | | | | | augmented reality | 557 | | | | | | | 558 | 82 | GBR | 1.9 | 10 ms | 10.E-6 | Discrete automation | 559 | | | | | | (small packets) | 560 | | | | | | | 561 | 83 | GBR | 2.2 | 10 ms | 10.E-4 | Discrete automation | 562 | | | | | | (large packets) | 563 | | | | | | | 564 | 84 | GBR | 2.4 | 30 ms | 10.E-5 | Intelligent | 565 | | | | | | Transport Systems | 566 | | | | | | | 567 | 85 | GBR | 2.1 | 5 ms | 10.E-5 | Electricity | 568 | | | | | | Distribution - High | 569 | | | | | | Voltage | 570 +----+----------+----------+--------+--------+----------------------+ 572 Several QCIs cover the same application types. For example, QCIs 6, 573 8 and 9 all apply to buffered streaming video and web applications. 574 However, LTE context distinguishes several types of customers and 575 environments. As such, QCI 6 can be used for the prioritization of 576 non-real-time data (i.e. most typically TCP-based services/ 577 applications) of MPS (multimedia priority services) subscribers, when 578 the network supports MPS. QCI 8 can be used for a dedicated "premium 579 bearer" (e.g. associated with premium content) for any subscriber or 580 subscriber group, while QCI 9 can be used for the default bearer for 581 non-privileged subscribers. 583 2.4. QCI implementations 585 [TS 23.203] v16 defines multiple QCIs. However, a UE or a EPS does 586 not need to implement all supported QCIs, even when all matching 587 types of traffic are expected between the UE and the network. In 588 practical implementations, it is common for an EPS to implement one 589 GBR bearer where at least QCI 1 is directed (and optionally other GBR 590 QCIs), and another default bearer where all other traffic to and from 591 the same UE is directed. The QCI associated to that second bearer 592 may depend on the subscriber category. As such, the QCI listed in 593 Section 2.3 are indicative of performance and traffic type 594 classifications, and are not strict in their implementation mandate. 596 2.5. 5QI and flow-based QoS Model in 3GPP 5G 598 While 4G LTE QoS is enforced at the EPS bearer level, 5G QoS focuses 599 on the transported flows. A QoS Flow ID (QFI) identifies a given QoS 600 Flow. In the User Plane, the traffic with a given QFI within a PDU 601 session is treated in the same way. The 5G QoS Identifier (5QI) is 602 used in 3GPP to identify a specific QoS forwarding behavior for a 5G 603 QoS Flow (similar to the QCI value for LTE, with the difference that 604 5QI applies to a flow, carried at some point in a bearer, while QCI 605 applies to a bearer within which certain types of flows are 606 expected). As such, the 5QI defines packet loss rate, packet delay 607 budget etc. In the 5G system, the entity named Session Management 608 Function (SMF) manages the QoS information. The SMF provides QFI 609 information to the Radio Access Network (RAN) for mapping the various 610 QoS flows to access network resources (i.e., data radio bearers). 611 The RAN performs packet marking in the uplink on a per QoS Flow 612 basis, with a marking value determined by the QFI and a treatment 613 matching the asscoiated 5QI. The SMF also instructs the User Plane 614 Function (UPF) for classification, bandwidth enforcement and marking 615 of the user plane traffic in downlink. Such packet marking 616 information includes the QFI and the transport level packet marking 617 value (i.e., the value of the DSCP field in the outer IP header). In 618 [TS 23.501], 3GPP provides the 5G QoS characteristics associated with 619 the 5QIs, and specifies the packet forwarding treatment that a QoS 620 Flow receives end-to-end, from the UE up to the UPF (and back). The 621 characteristics considered are: 623 o Resource type, i.e., if the flow requires resources to be 624 allocated for Guaranteed Bandwidth Rate (GBR), delay critical GBR 625 (DCGBR), or non-GBR. 627 o Default priority level 629 o Packet delay budget (PDB), including the PDB consumed in the 5G 630 core network 632 o Packet Error Rate (PER) 634 o Averaging window (in milliseconds), applicable for GBR and delay- 635 critical GBR 637 o Default maximum data burst volume (in bytes), applicable for 638 delay-critical GBR only 640 The following table shows a simplified version from the standardized 641 [TS 23.501] 5QI to QoS characteristics mapping. 643 +----+-------+-------+------+-------+-------+-------+---------------+ 644 | 5Q | Resou | Prior | Pack | Packe | Defau | Defau | Example | 645 | I | rce | ity | et D | t | lt | lt | Services | 646 | | Type | Level | elay | Error | Max | Avg W | | 647 | | | | Budg | Rate | Burst | indow | | 648 | | | | et | | | | | 649 +----+-------+-------+------+-------+-------+-------+---------------+ 650 | 1 | GBR | 20 | 100 | 10.E- | N/A | 2000 | Conversationa | 651 | | | | ms | 2 | | | l voice | 652 | | | | | | | | | 653 | 2 | GBR | 40 | 150 | 10.E- | N/A | 2000 | Conversationa | 654 | | | | ms | 3 | | | l video (live | 655 | | | | | | | | streaming) | 656 | | | | | | | | | 657 | 3 | GBR | 30 | 50 | 10.E- | N/A | 2000 | Real time | 658 | | | | ms | 3 | | | gaming, V2X | 659 | | | | | | | | messages, | 660 | | | | | | | | medium | 661 | | | | | | | | voltage | 662 | | | | | | | | electricity | 663 | | | | | | | | dist. | 664 | | | | | | | | | 665 | 4 | GBR | 50 | 300 | 10.E- | N/A | 2000 | non-conversat | 666 | | | | ms | 6 | | | ional video | 667 | | | | | | | | (buffered | 668 | | | | | | | | streaming) | 669 | | | | | | | | | 670 | 65 | GBR | 7 | 75 | 10.E- | N/A | 2000 | Mission | 671 | | | | ms | 2 | | | critical user | 672 | | | | | | | | plane push- | 673 | | | | | | | | to-talk voice | 674 | | | | | | | | (e.g. MCPTT) | 675 | | | | | | | | | 676 | 66 | GBR | 20 | 100 | 10.E- | N/A | 2000 | Non-mission | 677 | | | | ms | 3 | | | critical user | 678 | | | | | | | | plane push- | 679 | | | | | | | | to-talk voice | 680 | | | | | | | | | 681 | 67 | GBR | 15 | 100 | 10.E- | N/A | 2000 | Mission | 682 | | | | ms | 3 | | | critical user | 683 | | | | | | | | plane video | 684 | | | | | | | | | 685 | 71 | GBR | 56 | 150 | 10.E- | N/A | 2000 | "Live" uplink | 686 | | | | ms | 6 | | | streaming | 687 | | | | | | | | | 688 | 72 | GBR | 56 | 300 | 10.E- | N/A | 2000 | "Live" uplink | 689 | | | | ms | 4 | | | streaming | 690 | | | | | | | | | 691 | 73 | GBR | 56 | 300 | 10.E- | N/A | 2000 | "Live" uplink | 692 | | | | ms | 8 | | | streaming | 693 | | | | | | | | | 694 | 74 | GBR | 56 | 500 | 10.E- | N/A | 2000 | "Live" uplink | 695 | | | | ms | 8 | | | streaming | 696 | | | | | | | | | 697 | 76 | GBR | 56 | 500 | 10.E- | N/A | 2000 | "Live" uplink | 698 | | | | ms | 4 | | | streaming | 699 | | | | | | | | | 700 | 5 | non- | 10 | 100 | 10.E- | N/A | N/A | IMS signaling | 701 | | GBR | | ms | 6 | | | | 702 | | | | | | | | | 703 | 6 | non- | 60 | 300 | 10.E- | N/A | N/A | Video | 704 | | GBR | | ms | 6 | | | (Buffered | 705 | | | | | | | | Streaming) | 706 | | | | | | | | TCP-based | 707 | | | | | | | | (e.g. www, | 708 | | | | | | | | email, chat, | 709 | | | | | | | | etc.) | 710 | | | | | | | | | 711 | 7 | non- | 70 | 100 | 10.E- | N/A | N/A | Voice, Video | 712 | | GBR | | ms | 3 | | | (live | 713 | | | | | | | | streaming), | 714 | | | | | | | | interactive | 715 | | | | | | | | gaming | 716 | | | | | | | | | 717 | 8 | non- | 80 | 300 | 10.E- | N/A | N/A | Video | 718 | | GBR | | ms | 6 | | | (Buffered | 719 | | | | | | | | Streaming) | 720 | | | | | | | | TCP-based | 721 | | | | | | | | (e.g. www, | 722 | | | | | | | | email, chat, | 723 | | | | | | | | etc.) | 724 | | | | | | | | | 725 | 9 | non- | 90 | 300 | 10.E- | N/A | N/A | Same as 8 | 726 | | GBR | | ms | 6 | | | | 727 | | | | | | | | | 728 | 69 | non- | 5 | 60 | 10.E- | N/A | N/A | Mission | 729 | | GBR | | ms | 6 | | | Critical | 730 | | | | | | | | delay | 731 | | | | | | | | sensitive | 732 | | | | | | | | signalling | 733 | | | | | | | | (e.g., MC- | 734 | | | | | | | | PMC) | 735 | | | | | | | | | 736 | 70 | non- | 55 | 200 | 10.E- | N/A | N/A | Mission | 737 | | GBR | | ms | 6 | | | critical data | 738 | | | | | | | | (e.g. same | 739 | | | | | | | | examples as | 740 | | | | | | | | QCI/5QI 6,7,8 | 741 | | | | | | | | | 742 | 79 | non- | 65 | 50 | 10.E- | N/A | N/A | V2X messages | 743 | | GBR | | ms | 2 | | | | 744 | | | | | | | | | 745 | 80 | non- | 68 | 10 | 10.E- | N/A | N/A | Low latency | 746 | | GBR | | ms | 6 | | | eMMB | 747 | | | | | | | | applications | 748 | | | | | | | | (TCP/UDP- | 749 | | | | | | | | based); | 750 | | | | | | | | augmented | 751 | | | | | | | | reality | 752 | | | | | | | | | 753 | 82 | DCGBR | 19 | 10 | 10.E- | 255 B | 2000 | Discrete | 754 | | | | ms | 4 | | ms | automation | 755 | | | | | | | | | 756 | 83 | DCGBR | 22 | 10 | 10.E- | 1354 | 2000 | Discrete | 757 | | | | ms | 4 | B | ms | automation | 758 | | | | | | | | | 759 | 84 | DCGBR | 24 | 30 | 10.E- | 1354 | 2000 | Intelligent | 760 | | | | ms | 5 | B | ms | Transport | 761 | | | | | | | | Systems | 762 | | | | | | | | | 763 | 85 | DCGBR | 21 | 5 ms | 10.E- | 255 B | 2000 | Electricity | 764 | | | | | 5 | | ms | distribution, | 765 | | | | | | | | High voltage, | 766 | | | | | | | | V2X | 767 | | | | | | | | | 768 | 86 | DCGBR | 18 | 5 ms | 10.E- | 1354 | 2000 | V2X, | 769 | | | | | 4 | B | ms | collision | 770 | | | | | | | | avoidance, | 771 | | | | | | | | platooning, | 772 | | | | | | | | self driving | 773 +----+-------+-------+------+-------+-------+-------+---------------+ 775 Although the focus of 5QI and that of QCI is different, it should be 776 noted that the traffic examples provided by each QCI match the 777 traffic intent for a 5QI with matching number. The 5QI default 778 priority level is a tenfold expression of the QCI priority level (and 779 this document will refer to the QCI priority levels for simplicity) 780 As such, any given QCI or 5QI can be equivalised to the same DSCP 781 value. In turn, an application and its given DSCP value can be 782 expressed either in a QCI or a 5QI (provided that both exist for the 783 assooiated traffic or application). 785 2.6. GSMA IPX Guidelines Interpretation and Conflicts 787 3GPP standards do not define or recommend any specific mapping 788 between each QCI or 5QI and Diffserv, and leaves that mapping choice 789 to the operator of the Edge domain boundary (e.g. UE software stack 790 developer, P-GW operator). However, 3GPP defines that "for the IP 791 based backbone, Differentiated Services defined by IETF shall be 792 used" ([TS 23.107] v15 6.4.7). 794 The GSM Association (GSMA) has published an Inter-Service Provider IP 795 Backbone Guideline reference document [ir.34] that provides technical 796 guidance to participating service providers for connecting IP based 797 networks and services to achieve roaming and inter-working services. 798 The document built upon [RFC3246] and [RFC2597], and upon the initial 799 definition of 4 service classes in [TS 23.107] v15 to recommend a 800 mapping to EF for conversational traffic, to AF41 for Streaming 801 traffic, to AF31, AF21 and AF11 for different traffic in the 802 Interactive class, and to BE for background traffic. 804 These GSMA Guidelines were developed without reference to existing 805 IETF specifications for various services, referenced in Section 1.1. 806 Additionally, the same recommendations remained while new traffic 807 types under each 3GPP general class were added. As such, the GSMA 808 recommendations yield to several inconsistencies with [RFC4594], 809 including: 811 o Recommending EF for real-time (conversational) video, for which 812 [RFC4594] recommends AF41. 814 o Recommending AF31 for DNS traffic, for which [RFC4594] recommends 815 the standard service class (DF) 817 o Recommending AF31 for all types of signaling traffic, thus losing 818 the ability to differentiate between the various types of 819 signaling flows, as recommended in[RFC4594] section 5.1. 821 o Recommending AF21 for WAP browsing and WEB browsing, for which 822 [RFC4594] recommends the High Throughput data class 824 o Recommending AF11 for remote connection protocols, such as telnet 825 or SSH, for which [RFC4594] recommends the OAM class. 827 o Recommending DF for file transfers, for which [RFC4594] recommends 828 the High Throughput Data class. 830 o Recommending DF for email exchanges, for which [RFC4594] 831 recommends the High Throughput Data class. 833 o Recommending DF for MMS exchanged over SMTP, for which [RFC4594] 834 recommends the High Throughput Data class. 836 The document [ir.34] aso does not provide guidance for QCIs other 837 than 1 to 9, leaving the case of the 12 other QCIs unaddressed. 839 Thus, document [ir.34] conflicts with the overall Diffserv traffic- 840 conditioning service plan, both in the services specified and the 841 code points specified for them. As such, these two plans cannot be 842 normalized. Rather, as discussed in [RFC2474] Section 2, the two 843 domains (GSMA and other IP networks) are different Differentiated 844 Services Domains separated by a Differentiated Services Boundary. At 845 that boundary, code points from one domain are translated to code 846 points for the other, and maybe to Default (zero) if there is no 847 corresponding service to translate to. 849 3. P-GW Device Marking and Mapping Capability Recommendations 851 This document assumes and RECOMMENDS that all P-GWs (as the 852 interconnects between cellular and other IP networks) and all other 853 interconnection points between cellular and other IP networks support 854 the ability to: 856 o mark DSCP, per Diffserv standards 858 o mark QCI, per the [TS 23.203] standard, or 5QI, as per the [TS 859 23.501] standard 861 o support fully-configurable mappings between DSCP and QCI or 5QI 863 o process DSCP markings set by cellular endpoint devices 865 This document further assumes and RECOMMENDS that all cellular 866 endpoint devices (UE) support the ability to: 868 o mark DSCP, per Diffserv standards 870 o mark QCI, per the [TS 23.203] standard, OR 5QI, per the [TS 871 23.501] standard 873 o support fully-configurable mappings between DSCP (set by 874 applications in software) and QCI or 5QI (set by the operating 875 system and/or the LTE infrastructure) 877 Having made the assumptions and recommendations above, it bears 878 mentioning that while the mappings presented in this document are 879 RECOMMENDED to replace the current common default practices (as 880 discussed in Section 2.3 and Section 2.4), these mapping 881 recommendations are not expected to fit every last deployment model, 882 and as such MAY be overridden by network administrators, as needed. 884 4. DSCP to QCI or 5QI Mapping Recommendations 886 4.1. Control Traffic 888 4.1.1. Network Control Protocols 890 The Network Control service class is used for transmitting packets 891 between network devices (e.g., routers) that require control 892 (routing) information to be exchanged between nodes within the 893 administrative domain, as well as across a peering point between 894 different administrative domains. 896 [RFC4594] Section 3.2 recommends that Network Control Traffic be 897 marked CS6 DSCP. Additionally, as stated in [RFC4594] Section 3.1: 898 "CS7 DSCP value SHOULD be reserved for future use, potentially for 899 future routing or control protocols." 901 Network Control service is not directly called by any specific QCI or 902 5QI description, because 3GPP network control does not operate over 903 UE data channels. It should be noted that encapsulated routing 904 protocols for encapsulated or overlay networks (e.g., VPN, Network 905 Virtualization Overlays, etc.) are not Network Control Traffic for 906 any physical network at the cellular space; hence, they SHOULD NOT be 907 marked with CS6 in the first place, and are not expected to be 908 forwarded to the cellular data plane. 910 However, when such network control traffic is forwarded, it is 911 expected to receive a high priority and level of service. As such, 912 packets marked to CS7 DSCP are RECOMMENDED to be mapped to QCI 82, 913 thus benefiting from a dedicated bearer with low packet error loss 914 rate (10.E-4) and low budget delay (10 ms). Similarly, it is 915 RECOMMENDED to map Network Control Traffic marked CS6 to QCI/5QI 82, 916 thereby admitting it to the Discrete Automation (GBR) category with a 917 relative priority level of 1.9/19. 919 4.1.2. Operations, Administration, and Maintenance (OAM) 921 The OAM (Operations, Administration, and Maintenance) service class 922 is recommended for OAM&P (Operations, Administration, and Maintenance 923 and Provisioning). The OAM service class can include network 924 management protocols, such as SNMP, Secure Shell (SSH), TFTP, Syslog, 925 etc., as well as network services, such as NTP, DNS, DHCP, etc. 927 [RFC4594] Section 3.3, recommends that OAM traffic be marked CS2 928 DSCP. 930 Applications using this service class require a low packet loss but 931 are relatively not sensitive to delay. This service class is 932 configured to provide good packet delivery for intermittent flows. 933 As such, packets marked to CS2 are RECOMMENDED to be mapped to 934 QCI/5QI 9, thus admitting it to the non-GBR Buffered video traffic, 935 with a relative priority of 9/90. 937 4.2. User Traffic 939 User traffic is defined as packet flows between different users or 940 subscribers. It is the traffic that is sent to or from end-terminals 941 and that supports a very wide variety of applications and services 942 [RFC4594] Section 4. 944 Network administrators can categorize their applications according to 945 the type of behavior that they require and MAY choose to support all 946 or a subset of the defined service classes. 948 4.2.1. Telephony 950 The Telephony service class is recommended for applications that 951 require real-time, very low delay, very low jitter, and very low 952 packet loss for relatively constant-rate traffic sources (inelastic 953 traffic sources). This service class SHOULD be used for IP telephony 954 service. The fundamental service offered to traffic in the Telephony 955 service class is minimum jitter, delay, and packet loss service up to 956 a specified upper bound. [RFC4594] Section 4.1 recommends that 957 Telephony traffic be marked EF DSCP. 959 3GPP [TS 23.203] describes two QCIs adapted to Voice traffic: QCI 1 960 (GBR) and QCI 7 (non-GBR). The same logic is found in [TS 23.501] 961 for the same 5QIs. However, Telephony traffic as intended in 962 [RFC4594] supposes resource allocation control. Telephony SHOULD be 963 configured to receive guaranteed forwarding resources so that all 964 packets are forwarded quickly. The Telephony service class SHOULD be 965 configured to use Priority Queuing system. QCI 7 does not match 966 these conditions. As such, packets marked to EF are RECOMMENDED to 967 be mapped to QCI/5QI 1, thus admitting it to the GBR Conversational 968 Voice category, with a relative priority of 2/20. 970 4.2.2. Signaling 972 The Signaling service class is recommended for delay-sensitive 973 client-server (e.g., traditional telephony) and peer-to-peer 974 application signaling. Telephony signaling includes signaling 975 between 1) IP phone and soft-switch, 2) soft-client and soft-switch, 976 and 3) media gateway and soft-switch as well as peer-to-peer using 977 various protocols. This service class is intended to be used for 978 control of sessions and applications. [RFC4594] Section 4.2 979 recommends that Signaling traffic be marked CS5 DSCP. 981 While Signaling is recommended to receive a superior level of service 982 relative to the default class (e.g., relative to QCI 7), it does not 983 require the highest level of service (i.e., GBR and very high 984 priority). As such, it is RECOMMENDED to map Signaling traffic 985 marked CS5 DSCP to QCI/5QI 4, thereby admitting it to the GBR Non- 986 conversational video category, with a relative priority level of 987 5/50. 989 Note: Signaling traffic for native Voice dialer applications should 990 be exchanged over a control channel, and is not expected to be 991 forwarded in the data-plane. However, Signaling for non-native (OTT) 992 applications may be carried in the data-plane. In this case, 993 Signaling traffic is control-plane traffic from the perspective of 994 the voice/video telephony overlay-infrastructure. As such, Signaling 995 should be treated with preferential servicing versus other data-plane 996 flows. 998 4.2.3. Multimedia Conferencing 1000 The Multimedia Conferencing service class is recommended for 1001 applications that require real-time service for rate-adaptive 1002 traffic. [RFC4594] Section 4.3 recommends Multimedia Conferencing 1003 traffic be marked AF4x (that is, AF41, AF42, and AF43, according to 1004 the rules defined in [RFC2475]. The Diffserv model allows for three 1005 values to allow for different relative priorities of flows of the 1006 same nature. 1008 The primary media type typically carried within the Multimedia 1009 Conferencing service class marked AF41 is video intended to be a 1010 component of a real-time exchange; as such, it is RECOMMENDED to map 1011 AF41 into the Conversational Video (Live Streaming) category, with a 1012 GBR. Specifically, it is RECOMMENDED to map AF41 to QCI/5QI 2, 1013 thereby admitting AF41 into the GBR Conversational Video, with a 1014 relative priority of 4/40. 1016 AF42 is typically reserved for video intended to be a component of 1017 real-time exchange, but which criticality is less than traffic 1018 carried with a marking of AF41. As such, it is RECOMMENDED to map 1019 AF42 into the Conversational Video (Live Streaming) category, with a 1020 GBR, but a lower priority than QCI/5QI 2. Specifically, it is 1021 RECOMMENDED to map AF42 to QCI/5QI 4, thereby admitting AF42 into the 1022 GBR Conversational Video, with a relative priority of 5/50. 1024 Traffic marked AF43 is typically used for real-time video exchange of 1025 lower criticality. As such, it is RECOMMENDED to map AF43 into the 1026 Conversational Video (Live Streaming) category, but without a GBR. 1027 Specifically, it is RECOMMENDED to map AF43 to QCI/5QI 7, thereby 1028 admitting AF437 into the non-GBR Voice, Video and Interactive gaming, 1029 with a relative priority of 7/70. 1031 4.2.4. Real-Time Interactive 1033 The Real-Time Interactive service class is recommended for 1034 applications that require low loss and jitter and very low delay for 1035 variable-rate inelastic traffic sources. Such applications may 1036 include inelastic video-conferencing applications, but may also 1037 include gaming applications (as pointed out in [RFC4594] Sections 2.1 1038 through 2.3 and Section 4.4. [RFC4594] Section 4.4 recommends Real- 1039 Time Interactive traffic be marked CS4 DSCP. 1041 The primary media type typically carried within the Real-Time 1042 Interactive service class is video; as such, it is RECOMMENDED to map 1043 this class into a low latency Category. Specifically, it is 1044 RECOMMENDED to map CS4 to QCI 80, thereby admitting Real-Time 1045 Interactive traffic into the non-GBR category Low Latency eMBB 1046 (enhanced Mobile Broadband) applications with a relative priority of 1047 6.8. In cases where GBR is required, for example because a single 1048 bearer is allocated for all non-GBR traffic, using a GBR equivalent 1049 is also acceptable. In this case, it is RECOMMENDED to map CS4 to 1050 QCI/5QI 3, thereby admitting Real-Time Interactive traffic into the 1051 GBR category Real-time gaming, with a relative priority of 3/30. 1053 4.2.5. Multimedia Streaming 1055 The Multimedia Streaming service class is recommended for 1056 applications that require near-real-time packet forwarding of 1057 variable-rate elastic traffic sources. Typically, these flows are 1058 unidirectional. [RFC4594] Section 4.5 recommends Multimedia 1059 Streaming traffic be marked AF3x (that is, AF31, AF32, and AF33, 1060 according to the rules defined in [RFC2475]. 1062 The primary media type typically carried within the Multimedia 1063 Streaming service class is video; as such, it is RECOMMENDED to map 1064 this class into a Video Category. Specifically, it is RECOMMENDED to 1065 map AF31 to QCI/5QI 4, thereby admitting AF31 into the GBR Non 1066 Conversational Video category, with a relative priority of 5/50. 1068 Flows marked with AF32 are expected to be of the same nature as flows 1069 marked with AF32, but with a lower criticality. As such, these flows 1070 may not require a dedicated bearer with GBR. Therefore, it is 1071 RECOMMENDED to map AF32 to QCI/5QI 6, thereby admitting AF32 traffic 1072 into the non-GBR category Video (Buffered Streaming) with a relative 1073 priority of 6/60. 1075 Flows marked with AF33 are expected to be of the same nature as flows 1076 marked with AF31 and AF32, but with the lowest criticality. As such, 1077 it is RECOMMENDED to map AF33 to QCI/5QI 8, thereby admitting AF33 1078 traffic into the non-GBR category Video (Buffered Streaming) with a 1079 relative priority of 8/80. 1081 4.2.6. Broadcast Video 1083 The Broadcast Video service class is recommended for applications 1084 that require near-real-time packet forwarding with very low packet 1085 loss of constant rate and variable-rate inelastic traffic sources. 1086 Typically, these flows are unidirectional. [RFC4594] Section 4.6 1087 recommends Broadcast Video traffic be marked CS3 DSCP. 1089 As directly implied by the name, the primary media type typically 1090 carried within the Broadcast Video service class is video; as such, 1091 it is RECOMMENDED to map this class into a Video Category. 1092 Specifically, it is RECOMMENDED to map CS3 to QCI/5QI 4, thereby 1093 admitting Multimedia Streaming into the GBR Non Conversational Video 1094 category, with a relative priority of 5/50. In cases where GBR 1095 availability is constrained, using a non-GBR equivalent is also 1096 acceptable. In this case, it is RECOMMENDED to map CS3 to QCI/5QI 6, 1097 thereby admitting Real-Time Interactive traffic into the non-GBR 1098 category Video with a relative priority of 6/60. 1100 4.2.7. Low-Latency Data 1102 The Low-Latency Data service class is recommended for elastic and 1103 time-sensitive data applications, often of a transactional nature, 1104 where a user is waiting for a response via the network in order to 1105 continue with a task at hand. As such, these flows are considered 1106 foreground traffic, with delays or drops to such traffic directly 1107 impacting user productivity. [RFC4594] Section 4.7 recommends Low- 1108 Latency Data be marked AF2x (that is, AF21, AF22, and AF23, according 1109 to the rules defined in [RFC2475]. 1111 The primary media type typically carried within the Low-Latency Data 1112 service class is data; as such, it is RECOMMENDED to map this class 1113 into a data Category. Specifically, it is RECOMMENDED to map AF21 to 1114 QCI/5QI 70, thereby admitting AF21 into the non-GBR Mission Critical 1115 Data category, with a relative priority of 5.5/55. 1117 Flows marked with AF22 are expected to be of the same nature as flows 1118 marked with AF21, but with a lower criticality. Therefore, it is 1119 RECOMMENDED to map AF22 to QCI/5QI 6, thereby admitting AF22 traffic 1120 into the non-GBR category Video and TCP-based traffic, with a 1121 relative priority of 6/60. 1123 Flows marked with AF23 are expected to be of the same nature as flows 1124 marked with AF21 and AF22, but with the lowest criticality. As such, 1125 it is RECOMMENDED to map AF23 to QCI/5QI 8, thereby admitting AF23 1126 traffic into the non-GBR category Video and TCP-based traffic, with a 1127 relative priority of 8/80. 1129 It should be noted that a consequence of such classification is that 1130 AF22 is mapped to the same QCI and 5QI as CS3, and AF23 is mapped to 1131 the same QCI and 5QI as AF33. However, this overlap is unavoidable, 1132 as some QCIs and 5QIs express intents that are expressed in the 1133 Diffserv domain through distinct marking values, grouped in the 3GPP 1134 domain under the same general category. 1136 4.2.8. High-Throughput Data 1138 The High-Throughput Data service class is recommended for elastic 1139 applications that require timely packet forwarding of variable-rate 1140 traffic sources and, more specifically, is configured to provide 1141 efficient, yet constrained (when necessary) throughput for TCP 1142 longer-lived flows. These flows are typically not user interactive. 1144 According to [RFC4594] Section 4.8 it can be assumed that this class 1145 will consume any available bandwidth and that packets traversing 1146 congested links may experience higher queuing delays or packet loss. 1147 It is also assumed that this traffic is elastic and responds 1148 dynamically to packet loss. [RFC4594] Section 4.8 recommends High- 1149 Throughput Data be marked AF1x (that is, AF11, AF12, and AF13, 1150 according to the rules defined in [RFC2475]. 1152 The primary media type typically carried within the High-Throughput 1153 Data service class is data; as such, it is RECOMMENDED to map this 1154 class into a data Category. Specifically, it is RECOMMENDED to map 1155 AF11 to QCI/5QI 6, thereby admitting AF11 into the non-GBR Video and 1156 TCP-based traffic category, with a relative priority of 6/60. 1158 Flows marked with AF12 are expected to be of the same nature as flows 1159 marked with AF11, but with a lower criticality. Therefore, it is 1160 RECOMMENDED to map AF12 to QCI/5QI 8, thereby admitting AF12 traffic 1161 into the non-GBR category Video and TCP-based traffic, with a 1162 relative priority of 8/80. 1164 Flows marked with AF13 are expected to be of the same nature as flows 1165 marked with AF11 and AF12, but with the lowest criticality. As such, 1166 it is RECOMMENDED to map AF13 to QCI/5QI 9, thereby admitting AF13 1167 traffic into the non-GBR category Video and TCP-based traffic, with a 1168 relative priority of 9/90. 1170 It should be noted that a consequence of such classification is that 1171 AF11 is mapped to the same QCI as CS3 and AF22, AF12 is mapped to the 1172 same QCI and 5QI as Af33 and AF23, and AF13 is mapped to the same QCI 1173 and 5QI as CS2. However, this overlap is unavoidable, as some QCIs 1174 and 5QIs express intents that are expressed in the Diffserv domain 1175 through distinct marking values, grouped in the 3GPP domain under the 1176 same general category. 1178 4.2.9. Standard 1180 The Standard service class is recommended for traffic that has not 1181 been classified into one of the other supported forwarding service 1182 classes in the Diffserv network domain. This service class provides 1183 the Internet's "best-effort" forwarding behavior. [RFC4594] 1184 Section 4.9 states that the "Standard service class MUST use the 1185 Default Forwarding (DF) PHB". 1187 The Standard service class loosely corresponds to the default non-GBR 1188 bearer practice in 3GPP. Therefore, it is RECOMMENDED to map 1189 Standard service class traffic marked DF DSCP to QCI/5QI 9, thereby 1190 admitting it to the low priority Video and TCP-based traffic 1191 category, with a relative priority of 9/90. 1193 4.2.10. Low-Priority Data 1195 The Low-Priority Data service class serves applications that the user 1196 is willing to accept without service assurances. This service class 1197 is specified in [RFC3662] and [RFC8622]. [RFC3662] and [RFC4594] 1198 both recommend Low-Priority Data be marked CS1 DSCP. [RFC8622] 1199 updates these recommendations and suggests the LE (000001) marking. 1200 As such, this document aligns with this recommendation and notes that 1201 CS1 marking has become ambiguous. 1203 The Low-Priority Data service class does not have equivalent in the 1204 3GPP domain, where all service is controlled and allocated 1205 differentially. As such, there is no clear QCI or 5QI that could be 1206 labelled low priority below the best effort category. As such, it is 1207 RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP and LE 1208 DSCP to QCI/5QI 9, thereby admitting it to the low priority Video and 1209 TCP-based traffic category, with a relative priority of 9/90. 1211 4.3. Summary of Recommendations for DSCP-to-QCI Mapping 1213 The table below summarizes the [RFC4594] DSCP marking recommendations 1214 mapped to 3GPP: 1216 +------+--------------------+---------------+-----------------------+ 1217 | DSCP | Recommended | Resource Type | Priority Level | 1218 | | QCI/5QI | | (QCI/5QI) | 1219 +------+--------------------+---------------+-----------------------+ 1220 | CS7 | 82 | GBR | 1.9 / 19 | 1221 | | | | | 1222 | CS6 | 82 | GBR | 1.9 / 19 | 1223 | | | | | 1224 | EF | 1 | GBR | 2 / 20 | 1225 | | | | | 1226 | CS5 | 4 | GBR | 5 / 50 | 1227 | | | | | 1228 | AF43 | 7 | non-GBR | 7 / 70 | 1229 | | | | | 1230 | AF42 | 4 | GBR | 5 / 50 | 1231 | | | | | 1232 | AF41 | 2 | GBR | 4 / 40 | 1233 | | | | | 1234 | CS4 | 80 3 | non-BGR GBR | 6.8 / 68, 3 / 30 | 1235 | | | | | 1236 | AF33 | 8 | non-GBR | 8 / 80 | 1237 | | | | | 1238 | AF32 | 6 | non-GBR | 6 / 60 | 1239 | | | | | 1240 | AF31 | 4 | GBR | 5 / 50 | 1241 | | | | | 1242 | CS3 | 85 | GBR | 2.1 / 21 | 1243 | | | | | 1244 | AF23 | 8 | Non-GBR | 8 / 80 | 1245 | | | | | 1246 | AF22 | 6 | Non-GBR | 6 / 60 | 1247 | | | | | 1248 | AF21 | 70 | Non-GBR | 5.5 / 55 | 1249 | | | | | 1250 | CS2 | 9 | Non-GBR | 9 / 90 | 1251 | | | | | 1252 | AF13 | 9 | Non-GBR | 9 / 90 | 1253 | | | | | 1254 | AF12 | 8 | Non-GBR | 8 / 80 | 1255 | | | | | 1256 | AF11 | 6 | Non-GBR | 6 / 60 | 1257 | | | | | 1258 | CS0 | 9 | Non-GBR | 9 / 90 | 1259 | | | | | 1260 | CS1 | 9 | Non-GBR | 6.8 / 68 | 1261 | | | | | 1262 | LE | 9 | Non-GBR | 6.8 / 68 | 1263 +------+--------------------+---------------+-----------------------+ 1265 5. QCI and 5QI to DSCP Mapping Recommendations 1267 Traffic travelling from the 3GPP domain toward the Internet or the 1268 enterprise domain may already display DSCP marking, if the UE is 1269 capable of marking DSCP along with, or without, upstream QCI bearer 1270 or 5QI marking, as detailed in Section 2.1. 1272 When Diffserv marking is present in the flows originating from the UE 1273 and transiting through the CN (Core Network), and if Diffserv marking 1274 are not altered or removed on the path toward the Diffserv domain, 1275 then the network can be considered as end-to-end Diffserv compliant. 1276 In this case, it is RECOMMENDED that the entity providing the 1277 translation from 3GPP to Diffserv ignores the QCI or 5QI value and 1278 simply forwards unchanged the Diffserv values expressed by the UE in 1279 its various flows. 1281 This general recommendation is not expected to fit every last 1282 deployment model, and as such Diffserv marking MAY be overridden by 1283 network administrators, as needed, before the flows are forwarded to 1284 the Internet, the enterprise network or the Diffserv domain in 1285 general. Additionally, within a given Diffserv domain, it is 1286 generally NOT RECOMMENDED to pass through DSCP markings from 1287 unauthenticated, unidentified or unauthorized devices, as these are 1288 typically considered untrusted sources, as detailed in Section 7. 1289 Such risk is limited within the 3GPP domain where no upstream traffic 1290 is admitted without prior authentication of the UE. However, this 1291 risk exists when UE traffic is forwarded to an enterprise domain to 1292 which the UE does not belong. 1294 In cases where the UE is unable to apply Diffserv marking, or if 1295 these markings are modified or removed within the 3GPP domain, such 1296 that these markings may not represent the intent expressed by the UE, 1297 and in cases where the QCI is available to represent the flow intent, 1298 the recommendations in this section apply. These recommendations MAY 1299 apply to the boundary between the 3GPP and the Diffserv model, and 1300 MAY also apply to the Diffserv domain, when a given applicaiton 1301 traffic flows through both the 3GPP and the Diffserv domains (e.g. 1302 multiple paths) and when the enteprise administrator wishes to ensure 1303 that the same QoS intent is applied for both paths. 1305 5.1. QCI, 5QI and Diffserv Logic Reconciliation 1307 The QCIs and 5QIs are defined as relative priorities for traffic 1308 flows which are described by combinations of 6 or more parameters, as 1309 expressed in Section 2.2. As such, QCIs and 5QIs also represent 1310 flows in terms of multi-dimensional needs, not just in terms of 1311 relative priorities. This multi-dimensional logic is different from 1312 the Diffserv logic, where each traffic class is represented as a 1313 combination of needs relative to delay, jitter and loss. This 1314 characterization around three parameters allows for the construction 1315 of a fairly hierarchical traffic categorization infrastructure, where 1316 traffic with high sensitivity to delay and jitter also typically has 1317 high sensitivity to loss. 1319 By contrast, the 3GPP QCI and 5QI structure presents multiple points 1320 where dimensions cross one another with different or opposing 1321 vectors. For example, IMS signaling (QCI or 5QI 5) is defined with 1322 very high priority (1/10), low loss tolerance (10-6), but is non-GBR 1323 and belongs to the signaling category. By contrast, Conversational 1324 voice (QCI or 5QI 1) has lower priority (2/20) than IMS signaling, 1325 higher loss tolerance (10-2), yet benefits from a GBR. Fitting both 1326 QCIs or 5QIs 5 and 1 in a hierarchical model is challenging. 1328 At the same time, QCIs and 5QIs represent needs that can apply to 1329 different applications of various criticality but sending flows of 1330 the same nature. For example, QCIs or 5QIs 6, 8 and 9 all include 1331 voice traffic, video traffic, but also email or FTP. What 1332 distinguish these QCIs/5QIs is the criticality of the associated 1333 traffic. Diffserv does not envisions voice and FTP as possibly 1334 belonging to the same class. As the same time, QCIs or 5QIs 2 and 9 1335 include real-time voice traffic. Diffserv does not allow a type of 1336 traffic with stated sensitivity to loss, delay and jitter to be split 1337 into categories at both end of the priority spectrum. 1339 As such, it is not expected that QCIs and 5QIs can be mapped to the 1340 Diffserv model strictly and hierarchically. Instead, a better 1341 approach is to observe the various QCI and 5QI categories, and 1342 analyze their intent. This process allows for the grouping of 1343 several QCIs or 5QIs into hierarchical groups, that can then be 1344 translated into ensembles coherent with the Diffserv logic. This 1345 approach, in turn, allows for incorporation of new QCIs and 5QIs as 1346 the 3GPP model continues to evolve. 1348 It should be noted, however, that such approach results in partial 1349 incompatibility. Some QCIs or 5QIs represent an intent that is 1350 simply not present in the Diffserv model. In that case, attempting 1351 to artificially stitch the QCI/5QI to an existing Diffserv traffic 1352 class and marking would be dangerous. QCI or 5QI traffic forwarded 1353 to the Diffserv domain would be mixed with Diffserv traffic that 1354 would represent a very different intent. 1356 As such, the result of this classification is that some QCIs and 5QIs 1357 call for new Diffserv traffic classes and markings. This consequence 1358 is preferable to mixing traffic of different natures into the same 1359 pre-existing category. 1361 Each QCI is represented with 6 parameters and each 5QI with 7 1362 parameters, including an Example Services value. This parameter is 1363 representative of the QCI or 5QI intent. Although [TS 23.203] and 1364 [TS 23.501] summarize each QCI or 5QI intent, these standards contain 1365 only summaries of more complex classifications expressed in other 1366 3GPP standards. It is often necessary to refer to these other 1367 standards to obtain a more complete description of each QCI/5QI and 1368 the multiple type of flows that each QCI or 5QI represents. 1370 For the purpose of this document, the QCI or 5QI intent is the 1371 primary classification driver, along with the priority level. The 1372 secondary elements, such as priority, delay budget and loss tolerance 1373 allow for better refinement of the relative classifications of the 1374 QCIs and 5QIs. The resource types (GBR, DElay-critical GBR, non-GBR) 1375 provide additional visibility into the intent. 1377 Although 26 QCIs are listed in [TS 23.203] and 27 5QIs in [TS 1378 23.501], representing two (GBR, non-GBR) or three resource types 1379 (GBR, non-GBR, Delay-Critical GBR) respectively, 21 and 22 priority 1380 values, 9 delay budget values, and 7 loss tolerance values, examining 1381 the intent in fact surfaces 9 traffic families: 1383 1. Voice QCI/5QI [1] (dialer / conversational voice) is its own 1384 group 1386 2. Voice signaling [5] (IMS) is its own group 1388 3. Voice related (other voice applications, including PTT) [65, 66, 1389 69] 1391 4. Video (conversational or not, mission critical or not) [67, 2, 1392 4, 71, 72, 73, 74, 76] 1394 5. Live streaming / interactive gaming is its own group [7] 1396 6. Low latency eMBB, AR/VR is its own group [80] 1398 7. V2X messaging [75, 3, 9] 1400 8. Automation and Transport [82, 83, 84, 85, 86] 1402 9. Non-mission-critical data [6, 8, 9] 1404 10. Mission-critical data is its own group [70] 1406 5.2. Voice [1] 1408 Several QCIs or 5QIs are intended to carry voice traffic. However, 1409 QCI/5QI 1 stands apart from the others. Its category is 1410 Conversational Voice, but this QCI/5QI is intended to represent the 1411 VoLTE voice bearer, for dialer and emergency services. QCI/5QI 1 1412 uses a GBR, and has a priority level of 2/20. Its packet delay 1413 budget is 100 ms (from UE to P-GW) with a packet error loss of at 1414 most 10.E-2. As the GBR is allocated by the infrastructure, QCI/5QI 1415 1 is both admitted and allocated dedicated resources. As such, 1416 QCI/5QI 1 maps in intent and function to [RFC5865], Admitted Voice, 1417 and is RECOMMENDED for mapping to DSCP 44. 1419 5.3. IMS Signaling [5] 1421 QCI/5QI 5 is intended for Signaling. This category does not 1422 represent signaling for VoLTE, as such signaling is not conducted 1423 over the UE data channels. Instead, QCI/5QI 5 is intended for IMS 1424 services. IP Multimedia System (IMS) is a framework for delivering 1425 multimedia services over IP networks. These services include real- 1426 time and video applications, and their signaling is recommended to be 1427 carried, whenever possible, using IETF protocols such as SIP. Being 1428 of signaling nature, QCI/5QI 5 is non-GBR. However, being critical 1429 to enabling IMS real-time applications, QCI/5QI 5 has a high priority 1430 of 1/10. Its packet delay budget is 100 ms, but packet error loss 1431 rate very low, at less than 10.E-6. Overall, QCI/5QI 5 maps rather 1432 well to the intent of [RFC4594] signaling for real time applications, 1433 and as such is RECOMMENDED to map to [RFC4594] Signaling, CS5. 1435 5.4. Voice-related QCIs and 5QIs [65, 66, 69] 1437 Several QCIs/5QIs display the commonality of targeting voice (non- 1438 VoLTE) traffic: 1440 o QCI/5QI 65 is GBR, mission critical PTT voice, priority 0.7/7 1442 o QCI/5QI 66 is GBR, non-mission critical PTT voice, priority 2/20 1444 o QCI/5QI 69 is non-GBR, mission-critical PTT signaling, priority 1445 0.5/5 1447 These QCIs/5QIs are Voice in nature, and naturally fit into a 1448 proximity marking model with DSCP 46 and 44. 1450 Additionally, lower priority marks higher precedence intent in QCI 1451 and 5QI. However, there is no model in [RFC4594] that distinguishes 1452 3 classes of voice traffic. Therefore, new markings are unavoidable. 1453 As such, there is a need to group these markings in the Voice 1454 category (101 xxx), and to order 69, 65 and 66 with different 1455 markings to reflect their different priority levels. 1457 Among these three QCIs/5QIs, 69 is non-GBR, intended for mission- 1458 critical PTT signaling, with the highest priority of the three, at 1459 0.5/5. 69 is intended for signaling, but is latency sensitive, with a 1460 low 60 ms delay budget and a low 10.E-6 loss tolerance. Being of 1461 Signaling nature for real time applications, QCI/5QI 69 has proximity 1462 of intent with CS5 (Voice signaling, 40), but this marking is already 1463 used by QCI/5QI 5. Therefore, it is RECOMMENDED to map QCI/5QI 69 to 1464 a new DSCP marking, 41. 1466 Similarly, QCI/5QI 66 is GBR and targeted for non-mission critical 1467 PTT voice, with a priority level of 2/20. 66 is Voice in nature, and 1468 GBR. However, 66 is intended for non-mission-critical traffic, and 1469 has a lower priority than mission-critical Voice, a higher tolerance 1470 for delay (100 ms vs 75). As such, 66 cannot fit within [RFC4594] 1471 model mapping real-time voice to the class EF (DSCP 46). Here again, 1472 a new marking is needed. As such, this QCI/5QI fits in intent and 1473 proximity closest to Admitted Voice, but is non-GBR, and therefore 1474 non-admitted, guiding a new suggested DSCp marking of 43. 1476 Then, QCI/5QI 65 is GBR, intended for mission critical PTT voice, 1477 with a relative low priority index of 0.7/7. QCI/5QI 65 receives GBR 1478 and is intended for mission critical traffic. Its priority is higher 1479 (0.7 vs 2) than QCI/5QI 66, but a lower priority (0.7/7 vs 0.5/5) 1480 than QCI/5QI 69. Additionally, 65 cannot be represented by DSCP 44 1481 (used by QCI/5QI 1), or DSCP 46 (used by non-GBR voice). As such, 1482 QCI/5QI 65 fits between QCIs/5QIs 69 66, with a new suggested DSCP 1483 marking of 42. 1485 5.5. Video QCIs and 5QIs [67, 2, 4, 71, 72, 73, 74, 76] 1487 Although six different QCIs and 5QIs have example services that 1488 include some form of video traffic, eight QCIs and 5QIs are video in 1489 nature, 67, 2, 4, 71, 72, 73, 74, and 76. 1491 All eight QCIs/5QIs represent video streams and fit naturally in the 1492 AF4x category. However, these QCIs/5QIs do not match [RFC4594] 1493 intent for multimedia conferencing, in that they are all admitted 1494 (being associated to a GBR). They also do not match the category 1495 described by [RFC5865] for capacity-admitted traffic. Therefore, 1496 there is not a clear possible mapping for any of these QCIs and 5QIs 1497 to an existing AF4x category. In order to avoid mixing admitted and 1498 non-admitted video in the same class, it is necessary to associate 1499 these QCIs/5QIs to new Diffserv classes. 1501 In particular, QCI/5QI 67 is GBR, intended for mission-critical video 1502 user plane. This QCI/5QI is video in nature, and matches traffic 1503 that is rate-adaptive, and real time. 67 priority is high (1.5/15), 1504 with a tolerant delay budget (100ms) and rather low loss tolerance 1505 (10.E-3). 67 is GBR. 1507 As such, it is RECOMMENDED to map QCI/5QI 67 against the DSCP value 1508 closest to AF4x video with lowest discard eligibility (AF41), namely 1509 DSCP 33. 1511 Similarly, QCI/5QI 2 is intended for conversational video (live 1512 streaming). 2 is also video in nature and associated to a GBR, 1513 however its priority is lower than 67 (4/40 vs 1.5/15). 1514 Additionally, its delay budget is also larger (150 ms vs 100 ms). 1515 Its packet error loss is also 10.E-3. As such, 2 fits well within a 1516 video queue, with a larger drop probability than 67. Therefore, it 1517 is RECOMMENDED to map QCI/5QI 2 to the video category with a Diffserv 1518 marking of 35. 1520 QCIs/5QIs 71, 72, 73, 74 and 76 are intended for "Live" Uplink 1521 Streaming (LUS) services, where an end-user with a radio connection 1522 (for example a reporter or a drone) streams live video feed into the 1523 network or to a second party ([TS 26.939]). This traffic is GBR. 1524 However, [TS 26.939] defines LUS and also differentiates GBR from MBR 1525 and TBR. At the time of the admission, the infrastructure can offer 1526 a Guaranteed Bit Rate, which should match the bare minimum rate 1527 expected by the application (and its codec). Because of the 1528 burstiness nature of video, the Maximum Bit Rate (MBR) available to 1529 the trannsmission should be much higher than the GBR. In fact, the 1530 Target Bit Rate (TBR), which is the prefered service operation point 1531 for that application, is likely close to the MBR. Thus, the 1532 application will receive a treatment between the GBR and the TBR. 1533 This allocated bit rate will directly translate in video quality 1534 changes, where an available bit rate close to the GBR will result in 1535 a lower Mean Opinion Score than a bit rate close to the TBR. As the 1536 application detects the contraints on the available bit rate, it may 1537 adapt by changing its codec and compression scheme accordingly. 1538 Flows with higher compression will have higher delay tolerance and 1539 budget (as a single packet burst represents a larger segment of the 1540 video flow) but lower loss tolerance (as each lost packet represents 1541 a larger segment of the video flow). As such, 71, 72, 73, 74 and 76 1542 express intents similar to QCI/5QI 2, with additional constraints on 1543 the directionality of the flow (upstream only) and the bit rate 1544 applied by the infrastructure. These constraints are orthogonal to 1545 the intent of the flow. As such, it is RECOMMENDED to map QCIs/5QIs 1546 71, 72, 73, 74 and 76 to the same DSCP value as QCI/5QI 2, and thus 1547 to the video category with a Diffserv marking of 35. 1549 QCI/5QI 4 is intended for non-conversational video (buffered 1550 streaming), with a priority of 5/50. 4 is also video in nature. 1551 Although it is buffered, it is admitted, being associated to a GBR. 1552 QCI/5QI 4 as a lower priority than QCIs/5QIs 67 and 2, and a larger 1553 delay budget (300 ms vs 150/100). However, its packet loss tolerance 1554 is low (10.E-6). This combination makes it eligible for a video 1555 category, but with a higher drop probability than 67 and 2. 1556 Therefore, it is RECOMMENDED to map QCI/5QI 4 to DSCP 37. 1558 5.6. Live streaming and interactive gaming [7] 1560 QCI/5QI 7 is non-GBR and intended for live streaming voice or video 1561 interactive gaming. Its priority is 7/70. It is the only QCI/5QI 1562 targeting this particular traffic mix. In the Diffserv model, voice 1563 and video are different categories, and are also different from 1564 interactive gaming (real time interactive). In the 3GPP model, live 1565 streaming video and mission-critical video are defined in other 1566 queues with high priority (e.g. QCI or 5QI 2 for video Live 1567 streaming, with a priority of 2/20, or QCI/5QI 67 for mission- 1568 critical video, with a priority of 1.5/15). By comparison, QCI/5QI 7 1569 priority is relatively low (7/70), with a 100 ms budget delay and a 1570 comparatively rather high loss tolerance (10.E-3). 1572 As such, 7 fits well with bursty (e.g. video) and possibly rate 1573 adaptive flows, with possible drop probability. It is also non- 1574 admitted (non-GBR), and as such, fits close to [RFC4594] intent for 1575 multimedia conferencing, with high discard eligibility. Therefore, 1576 it is RECOMMENDED to map QCI/5QI 7 to the existing Diffserv category 1577 AF43. 1579 5.7. Low latency eMBB and AR/VR [80] 1581 QCI/5QI 80 is intended for low latency eMBB (enhanced Mobile 1582 Broadband) applications, such as Augmented Reality of Virtual Reality 1583 (AR/VR). 80 priority is 6.8/68, with a low packet delay budget of 10 1584 ms, and a packet error loss rate of at most 10.E-6. 80 is non-GBR, 1585 yet intended for real time applications. Traffic in the AR/VR 1586 category typically does not react dynamically to losses, requires 1587 bandwidth and a low and predictable delay. 1589 As such, QCI/5QI 80 matches closely the specifications for CS4. 1590 Therefore, it is RECOMMENDED to map QCI/5QI 80 to the existing 1591 category CS4. 1593 5.8. V2X messaging [75,3,9] 1595 Three QCIs/5QIs are intended specifically to carry Vehicle to 1596 Anything (V2X) traffic, 75, 3, and 79. All 3 QCIs/5QIs are data in 1597 nature, and fit naturally into the AF2x category. However, two of 1598 these (75 and 3) are admitted (GBR), and therefore do not fit in the 1599 current Diffserv model. 79 is non-admitted, but matches none of the 1600 AF2X categories in [RFC4594]. 1602 In particular, QCI/5QI 75 is GBR, with a rather high priority 1603 (2.5/25), a low delay budget (50 ms), but tolerance to losses (10E- 1604 2). Being low latency data in nature, 75 fits well in the AF2X 1605 category. However, being admitted, it fits none of the existing 1606 markings. Being the highest traffic (in priority) in this low 1607 latency data family, 75 is recommended to be mapped to a new 1608 category, as close as possible to the AF2X class, and with a low drop 1609 probability. As such, it is RECOMMENDED to map QCI/5QI 75 to DSCP 1610 17. 1612 Similarly, QCI/5QI 3 is intended for V2X messages, but can also be 1613 used for Real time gaming, or Utility traffic (medium voltage 1614 distribution) or process automation monitoring. QCI/5QI 3 priority 1615 is 3/30. 3 is data in nature, but GBR. Its delay budget is low (50 1616 ms), but with some tolerance to loss (10E-3). 1618 QCI/5QI 3 is of the same type as QCI/5QI 75, but with a lower 1619 priority. Therefore, 3 should be mapped to a category close to the 1620 category to which 75 is mapped, but with a higher drop probability. 1621 As such, it is RECOMMENDED to map QCI/5QI 3 to DSCP 19. 1623 Additionally, QCI/5QI 79 is also intended for V2X messages. 79 is 1624 similar in nature to 75 and 3, but is non-critical (non-GBR). Its 1625 priority is also lower (6.5/65). Its budget delay is similar to that 1626 of 75 and 3 (50 ms), and its packet error loss rate is similar to 1627 that of 75 (10.E-2). 1629 79 partially matches AF2X, but is not elastic, and therefore cannot 1630 fit exactly in [RFC4594] model. As such, it is recommended to a 1631 mapping similar to QCI/5QIs 75 and 3, with a higher drop probability. 1632 Therefore, it is RECOMMENDED to map QCI/5QI 79 to DSCP 21. 1634 5.9. Automation and Transport [82, 83, 84, 85, 86] 1636 QCI/5QI 84 is intended for intelligent transport systems. As such, 1637 its intent is close to the V2X messaging category. QCI 84 is also 1638 admitted (GBR in [TS 23.203] and Delay-Critical GBR in [TS 23.501]). 1639 However, 84 is intended for traffic with a smaller packet delay 1640 budget (30 ms vs 50 ms for QCI/5QI 75) and a smaller packet error 1641 loss maximum rate (10.E-6 vs 10.E-2 for QCI/5QI 75). As such, 84 1642 should be mapped against a category above that of 75 or 3. Being 1643 admitted, 84 does not map easily into an existing category. As such, 1644 it is RECOMMENDED to map QCI/5QI 84 to DSCP category 31. 1646 5QI 86 is also intended for intelligent transport systems, and fits 1647 in the same general category as 84. 86 is also admitted (Delay- 1648 Critical GBR), with a higher priority (18) than 84 but similar burst 1649 rate (1354 bytes). 5QI 86 therefore fits into a category close to 1650 that of 84. As such, it is RECOMMENDED to map 5QI 86 to DSCP 1651 captegory 29. 1653 QCI/5QI 85 is intended for electricity distribution (high voltage) 1654 communication. As such, it is close in intent to QCI/5QI 3. 85 is 1655 also GBR. However, 85 priority is lower than that of QCI/5QI 3 1656 (2.1/21 vs 3/30). 85 has also a very low packet delay budget (5 ms vs 1657 50 ms for QCI/5QI 3) and low packet error loss rate (10.E-6 vs 10.E-3 1658 for QCI/5QI 3). As such, 84 should be mapped to a category higher 1659 than that of QCI/5QI 3,with a very low drop probability. As such, it 1660 is RECOMMENDED to map QCI/5QI 85 to DSCP category 23. 1662 QCIs/5QIs 82 and 83 are both intended for discrete automation control 1663 traffic. 82 represents traffic with a higher priority (1.9/19) than 1664 traffic matched to 83 (priority 2.2/22). 82 also expects smaller data 1665 bursts (255 bytes) than 83 (1358 bytes). However, both QCIs are 1666 admitted (GBR), with the same low packet delay budget (10 ms) and 1667 packet error loss maximum rate (10.E-4). 1669 As such, 82 and 83 fit in the same general category, with a higher 1670 drop probability assigned to 83. They also fit the general intent 1671 category of automation traffic types, with a priority higher than 1672 that of other M2M traffic types (e.g. V2X messages). As such, they 1673 fit well into the AF3X category. However, being both admitted (GBR), 1674 they do not easily map to any existing AF3X category, and require new 1675 categories. 1677 As such, it is RECOMMENDED to map QCI/5QI 82 to DSCP category 25. 1678 Similarly, it is RECOMMENDED to map QCI/5QI 83 to DSCP category 79. 1680 5.10. Non-mission-critical data [6,8,9] 1682 QCIs/5QIs 6, 8 and 8 are intended for non-GBR, Video or TCP data 1683 traffic. All 3 QCIs/5QIs are data in nature, non-mission critical, 1684 relative low priority and therefore fit naturally into the AF1x 1685 category. The inclusion in these QCIs/5QIs' intent of buffered video 1686 is an imperfect fit for AF1X. However, the intent of these QCIs/5QIs 1687 is to match buffered, and non-mission critical traffic. As such, 1688 they match the intent of AF1X, even if the Diffserv model would not 1689 associate buffered video to non-mission critical, buffered and low 1690 priority traffic. 1692 The intent of all three QCIs/5QIs is similar. The difference lies in 1693 their priority and criticality. 1695 QCI/5QI 6 has priority 6/60, a packet delay budget of 300 ms, and a 1696 packet error loss rate of at most 10.E-6. QCI/5QI 8 has a priority 1697 8/80, a packet delay budget of 300 ms, and a packet error loss rate 1698 of at most 10.E-6. QCI/5QI 9 has priority 9/90, and also a packet 1699 delay budget of 300 ms and a packet error loss rate of at most 1700 10.E-6. As these three QCIs/5QIs represent the same intent and are 1701 only different in their priority level, using discard eligibility to 1702 differentiate them is logical. As such, it is RECOMMENDED to map 1703 QCI/5QI 6 to category AF11. Similarly, it is RECOMMENDED to map 1704 QCI/5QI 8 to AF12. And logically, it is RECOMMENDED to map QCI/5QI 9 1705 to AF13. 1707 5.11. Mission-critical data [70] 1709 QCI/5QI 70 is non-GBR, intended for mission critical data, with a 1710 priority of 5.5/55, a packet delay budget of 200 ms and a packet 1711 error loss rate tolerance of at most 10.E-6. The traffic types 1712 intended for 70 are the same as for QCIs/5QIs 6,8,9 categories, 1713 namely buffered streaming video and TCP-based traffic, such as www, 1714 email, chat, FTP, P2P and other file sharing applications. However, 1715 70 is specifically intended for applications that are mission 1716 critical. For this reason, 70 priority is higher than 6, 8 or 9 1717 priorities (5.5/55 vs 6/60, 8/80 and 9/90 respectively). Therefore, 1718 70 fits well in the AF2x family, while 6,8,9 are in AF1x. As 70 1719 displays intermediate differentiated treatment, if also fits well 1720 with an intermediate discard eligibility. As such, it is RECOMMENDED 1721 to map QCI/5QI 70 to DSCP 20 (AF22). 1723 5.12. Summary of Recommendations for QCI or 5QI to DSCP Mapping 1725 The table below summarizes the 3GPP QCI and 5QI to [RFC4594] DSCP 1726 marking recommendations: 1728 +--------+----------+----------+----------------------+-------------+ 1729 | QCI/5Q | Resource | Priority | Example Services | Recommended | 1730 | I | Type | Level | | DSCP (PHB) | 1731 +--------+----------+----------+----------------------+-------------+ 1732 | 1 | GBR | 2 | Conversational Voice | 44 (VA) | 1733 | | | | | | 1734 | 2 | GBR | 4 | Conversational Video | 35 (N.A.) | 1735 | | | | (Live Streaming) | | 1736 | | | | | | 1737 | 3 | GBR | 3 | Real Time Gaming, | 19 (N.A.) | 1738 | | | | V2X messages, | | 1739 | | | | Electricity | | 1740 | | | | distribution (medium | | 1741 | | | | voltage) Process | | 1742 | | | | automation | | 1743 | | | | (monitoring) | | 1744 | | | | | | 1745 | 4 | GBR | 5 | Non-Conversational | 37 (N.A.) | 1746 | | | | Video (Buffered | | 1747 | | | | Streaming) | | 1748 | | | | | | 1749 | 65 | GBR | 0.7 | Mission Critical | 42 (N.A.) | 1750 | | | | user plane Push To | | 1751 | | | | Talk voice (e.g., | | 1752 | | | | MCPTT) | | 1753 | | | | | | 1754 | 66 | GBR | 2 | Non-Mission-Critical | 43 (N.A.) | 1755 | | | | user plane Push To | | 1756 | | | | Talk voice | | 1757 | | | | | | 1758 | 67 | GBR | 1.5 | Mission Critical | 33 (N.A.) | 1759 | | | | Video user plane | | 1760 | | | | | | 1761 | 75 | GBR | 2.5 | V2X messages | 17 (N.A.) | 1762 | | | | | | 1763 | 71 | GBR | 5.6 | Live uplink | 35 (N.A.) | 1764 | | | | streaming | | 1765 | | | | | | 1766 | 72 | GBR | 5.6 | Live uplink | 35 (N.A.) | 1767 | | | | streaming | | 1768 | | | | | | 1769 | 73 | GBR | 5.6 | Live uplink | 35 (N.A.) | 1770 | | | | streaming | | 1771 | | | | | | 1772 | 74 | GBR | 5.6 | Live uplink | 35 (N.A.) | 1773 | | | | streaming | | 1774 | | | | | | 1775 | 76 | GBR | 5.6 | Live uplink | 35 (N.A.) | 1776 | | | | streaming | | 1777 | | | | | | 1778 | 82 | GBR | 1.9 | Discrete automation | 25 (N.A.) | 1779 | | | | (small packets) | | 1780 | | | | | | 1781 | 83 | GBR | 2.2 | Discrete automation | 27 (N.A.) | 1782 | | | | (large packets) | | 1783 | | | | | | 1784 | 84 | GBR | 2.4 | Intelligent | 31 (N.A.) | 1785 | | | | Transport Systems | | 1786 | | | | | | 1787 | 85 | GBR | 2.1 | Electricity | 23 (N.A.) | 1788 | | | | Distribution - High | | 1789 | | | | Voltage | | 1790 | | | | | | 1791 | 86 | GBR | 1.8 | Intelligent | 29 (N.A.) | 1792 | | | | Transport Systems | | 1793 | | | | | | 1794 | 5 | Non-GBR | 1 | IMS Signalling | 40 (CS5) | 1795 | | | | | | 1796 | 6 | Non-GBR | 6 | Video (Buffered | 10 (AF11) | 1797 | | | | Streaming) TCP-based | | 1798 | | | | (e.g. www, email, | | 1799 | | | | chat, ftp, p2p file | | 1800 | | | | sharing, progressive | | 1801 | | | | video) | | 1802 | | | | | | 1803 | 7 | Non-GBR | 7 | Voice, Video (live | 38 (AF43) | 1804 | | | | streaming), | | 1805 | | | | interactive gaming | | 1806 | | | | | | 1807 | 8 | Non-GBR | 8 | Video (buffered | 12 (AF12) | 1808 | | | | streaming) TCP-based | | 1809 | | | | (e.g. www, email, | | 1810 | | | | chat, ftp, p2p file | | 1811 | | | | sharing, progressive | | 1812 | | | | video) | | 1813 | | | | | | 1814 | 9 | Non-GBR | 9 | Same as 8 | 14 (AF13) | 1815 | | | | | | 1816 | 69 | Non-GBR | 0.5 | Mission Critical | 41 (N.A.) | 1817 | | | | delay sensitive | | 1818 | | | | signalling (e.g., | | 1819 | | | | MC-PTT signalling, | | 1820 | | | | MC Video signalling) | | 1821 | | | | | | 1822 | 70 | Non-GBR | 5.5 | Mission Critical | 20 (AF22) | 1823 | | | | Data (e.g. example | | 1824 | | | | services are the | | 1825 | | | | same as QCI 6/8/9) | | 1826 | | | | | | 1827 | 79 | Non-GBR | 6.5 | V2X messages | 21 (N.A.) | 1828 | | | | | | 1829 | 80 | Non-GBR | 6.8 | Low latency eMMB | 32 (CS4) | 1830 | | | | applications | | 1831 | | | | (TCP/UDP-based); | | 1832 | | | | augmented reality | | 1833 +--------+----------+----------+----------------------+-------------+ 1835 6. IANA Considerations 1837 This document has no IANA actions. Although this document suggests 1838 the use of codepoints in the Pool 1 of the codespace defined in 1839 [RFC2474], no exclusive attribution is requested. The recommended 1840 utilisation of seven codepoints in Pool 2 and six codepoints in pool 1841 3 is also intended as a recommendation for experimental or Local Use, 1842 as defined in [RFC2474]. 1844 7. Specific Security Considerations 1846 The recommendations in this document concern widely deployed wired 1847 and wireless network functionality, and, for that reason, do not 1848 present additional security concerns that do not already exist in 1849 these networks. 1851 8. Security Recommendations for General QoS 1853 It may be possible for a wired or wireless device (which could be 1854 either a host or a network device) to mark packets (or map packet 1855 markings) in a manner that interferes with or degrades existing QoS 1856 policies. Such marking or mapping may be done intentionally or 1857 unintentionally by developers and/or users and/or administrators of 1858 such devices. 1860 To illustrate: A gaming application designed to run on a smartphone 1861 may request that all its packets be marked DSCP EF. Although the 1862 3GPP infrastructure may only allocate a non-GBR default QCI (e.g. 1863 QCI 9) for this traffic, the translation point into the Internet 1864 domain may consider the DSCP marking instead of the allocated QCI, 1865 and forward this traffic with a marking of EF. This traffic may then 1866 interfere with QoS policies intended to provide priority services for 1867 business voice applications. 1869 To mitigate such scenarios, it is RECOMMENDED to implement general 1870 QoS security measures, including: 1872 o Setting a traffic conditioning policy reflective of business 1873 objectives and policy, such that traffic from authorized users 1874 and/or applications and/or endpoints will be accepted by the 1875 network; otherwise, packet markings will be "bleached" (i.e., re- 1876 marked to DSCP DF). Additionally, Section 5 made it clear that it 1877 is generally NOT RECOMMENDED to pass through DSCP markings from 1878 unauthorized, unidentified and/or unauthenticated devices, as 1879 these are typically considered untrusted sources. This is 1880 especially relevant for Internet of Things (IoT) deployments, 1881 where tens of billions of devices with little or no security 1882 capabilities are being connected to LTE and IP networks, leaving 1883 them vulnerable to be utilized as agents for DDoS attacks. These 1884 attacks can be amplified with preferential QoS treatments, should 1885 the packet markings of such devices be trusted. 1887 o Policing EF marked packet flows, as detailed in [RFC2474] 1888 Section 7 and [RFC3246] Section 3. 1890 Finally, it should be noted that the recommendations put forward in 1891 this document are not intended to address all attack vectors 1892 leveraging QoS marking abuse. Mechanisms that may further help 1893 mitigate security risks of both wired and wireless networks deploying 1894 QoS include strong device- and/or user-authentication, access- 1895 control, rate-limiting, control-plane policing, encryption, and other 1896 techniques; however, the implementation recommendations for such 1897 mechanisms are beyond the scope of this document to address in 1898 detail. Suffice it to say that the security of the devices and 1899 networks implementing QoS, including QoS mapping between wired and 1900 wireless networks, merits consideration in actual deployments. 1902 9. References 1904 9.1. Normative References 1906 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1907 "Definition of the Differentiated Services Field (DS 1908 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1909 DOI 10.17487/RFC2474, December 1998, 1910 . 1912 [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, 1913 "Assured Forwarding PHB Group", RFC 2597, 1914 DOI 10.17487/RFC2597, June 1999, 1915 . 1917 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 1918 J., Courtney, W., Davari, S., Firoiu, V., and D. 1919 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 1920 Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002, 1921 . 1923 [RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated 1924 Services Code Point (DSCP) for Capacity-Admitted Traffic", 1925 RFC 5865, DOI 10.17487/RFC5865, May 2010, 1926 . 1928 9.2. Informative References 1930 [ir.34] 3gpp, "guidelines for ipx provider networks - gsma", 1931 August 2018, . 1934 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1935 Requirement Levels", BCP 14, RFC 2119, 1936 DOI 10.17487/RFC2119, March 1997, 1937 . 1939 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1940 and W. Weiss, "An Architecture for Differentiated 1941 Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, 1942 . 1944 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 1945 Per-Domain Behavior (PDB) for Differentiated Services", 1946 RFC 3662, DOI 10.17487/RFC3662, December 2003, 1947 . 1949 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 1950 Guidelines for DiffServ Service Classes", RFC 4594, 1951 DOI 10.17487/RFC4594, August 2006, 1952 . 1954 [RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of 1955 Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127, 1956 February 2008, . 1958 [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection 1959 Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, 1960 March 2017, . 1962 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1963 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1964 May 2017, . 1966 [RFC8622] Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for 1967 Differentiated Services", RFC 8622, DOI 10.17487/RFC8622, 1968 June 2019, . 1970 [TS23.107] 1971 3gpp, "quality of service (qos) concept and architecture 1972 v15.0", June 2018, . 1974 [TS23.203] 1975 3gpp, "policy and charging control architecture v16.0", 1976 December 2019, . 1978 [TS23.207] 1979 3gpp, "end-to-end quality of service (qos) concept and 1980 architecture v15.0", June 2018, . 1983 [TS23.501] 1984 3gpp, "system architecture for the 5G System (5GS) v15.0", 1985 December 2019, . 1987 [TS26.939] 1988 3gpp, "guidelines on the framework for live uplink 1989 streaming (FLUS) v15.0", September 2019, . 1992 Authors' Addresses 1994 Jerome Henry 1995 Cisco 1997 Email: jerhenry@cisco.com 1999 Tim Szigeti 2000 Cisco 2002 Email: szigeti@cisco.com 2004 Luis Miguel Contreras Murillo 2005 Telefonica 2007 Email: luismiguel.contrerasmurillo@telefonica.com