[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

Network Working Group                                           J. Henry
Internet-Draft                                                T. Szigeti
Intended status: Informational                                     Cisco
Expires: October 15, 2020                                   L. Contreras
                                                              Telefonica
                                                          April 13, 2020


                        Diffserv to QCI Mapping
                  draft-henry-tsvwg-diffserv-to-qci-04

Abstract

   As communication devices become more hybrid, smart devices include
   more media-rich communication applications, and the boundaries
   between telecommunication and other applications becomes less clear.
   Simultaneously, as the end-devices become more mobile, application
   traffic transits more often between enterprise networks, the
   Internet, and cellular telecommunication networks, sometimes using
   simultaneously more than one path and network type.  In this context,
   it is crucial that quality of service be aligned between these
   different environments.  However, this is not always the case by
   default, and cellular communication networks use a different QoS
   nomenclature from the Internet and enterprise networks.  This
   document specifies a set of 3rd Generation Partnership Project (3GPP)
   Quality of Service (QoS) Class Identifiers (QCI) and 5G QoS
   Identifiers (5QI) to Differentiated Services Code Point (DSCP)
   mappings, to reconcile the marking recommendations offered by the
   3GPP with the recommendations offered by the IETF, so as to maintain
   a consistent QoS treatment between cellular networks and the
   Internet.  This mapping can be used by enterprises or implementers
   expecting traffic to flow through both types of network, and wishing
   to align the QoS treatment applied to one network under their control
   with the QoS treatment applied to the other network.

Status of This Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any




Henry, et al.           Expires October 15, 2020                [Page 1]


Internet-Draft                DIFFSERV-QCI                    April 2020


   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on October 15, 2020.

Copyright Notice

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

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Related Work  . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Applicability Statement . . . . . . . . . . . . . . . . .   5
     1.3.  Document Organization . . . . . . . . . . . . . . . . . .   5
     1.4.  Requirements language . . . . . . . . . . . . . . . . . .   6
     1.5.  Terminology Used in this Document . . . . . . . . . . . .   6
   2.  Service Comparison and Default Interoperation of Diffserv and
       3GPP LTE and 5G . . . . . . . . . . . . . . . . . . . . . . .   7
     2.1.  Diffserv Domain Boundaries  . . . . . . . . . . . . . . .   7
     2.2.  QCI and Bearer Model in 3GPP  . . . . . . . . . . . . . .   8
     2.3.  QCI Definition and Logic  . . . . . . . . . . . . . . . .   9
       2.3.1.  Conversational  . . . . . . . . . . . . . . . . . . .   9
       2.3.2.  Streaming . . . . . . . . . . . . . . . . . . . . . .  10
       2.3.3.  Interactive . . . . . . . . . . . . . . . . . . . . .  10
       2.3.4.  Background  . . . . . . . . . . . . . . . . . . . . .  10
     2.4.  QCI implementations . . . . . . . . . . . . . . . . . . .  13
     2.5.  5QI and flow-based QoS Model in 3GPP 5G . . . . . . . . .  13
     2.6.  GSMA IPX Guidelines Interpretation and Conflicts  . . . .  17
   3.  P-GW Device Marking and Mapping Capability Recommendations  .  18
   4.  DSCP to QCI or 5QI Mapping Recommendations  . . . . . . . . .  19
     4.1.  Control Traffic . . . . . . . . . . . . . . . . . . . . .  19
       4.1.1.  Network Control Protocols . . . . . . . . . . . . . .  19
       4.1.2.  Operations, Administration, and Maintenance (OAM) . .  20
     4.2.  User Traffic  . . . . . . . . . . . . . . . . . . . . . .  20
       4.2.1.  Telephony . . . . . . . . . . . . . . . . . . . . . .  21
       4.2.2.  Signaling . . . . . . . . . . . . . . . . . . . . . .  21



Henry, et al.           Expires October 15, 2020                [Page 2]


Internet-Draft                DIFFSERV-QCI                    April 2020


       4.2.3.  Multimedia Conferencing . . . . . . . . . . . . . . .  22
       4.2.4.  Real-Time Interactive . . . . . . . . . . . . . . . .  22
       4.2.5.  Multimedia Streaming  . . . . . . . . . . . . . . . .  23
       4.2.6.  Broadcast Video . . . . . . . . . . . . . . . . . . .  23
       4.2.7.  Low-Latency Data  . . . . . . . . . . . . . . . . . .  24
       4.2.8.  High-Throughput Data  . . . . . . . . . . . . . . . .  25
       4.2.9.  Standard  . . . . . . . . . . . . . . . . . . . . . .  25
       4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . .  26
     4.3.  Summary of Recommendations for DSCP-to-QCI Mapping  . . .  26
   5.  QCI and 5QI to DSCP Mapping Recommendations . . . . . . . . .  28
     5.1.  QCI, 5QI and Diffserv Logic Reconciliation  . . . . . . .  28
     5.2.  Voice [1] . . . . . . . . . . . . . . . . . . . . . . . .  31
     5.3.  IMS Signaling [5] . . . . . . . . . . . . . . . . . . . .  31
     5.4.  Voice-related QCIs and 5QIs [65, 66, 69]  . . . . . . . .  31
     5.5.  Video QCIs and 5QIs [67, 2, 4, 71, 72, 73, 74, 76]  . . .  32
     5.6.  Live streaming and interactive gaming [7] . . . . . . . .  34
     5.7.  Low latency eMBB and AR/VR [80] . . . . . . . . . . . . .  34
     5.8.  V2X messaging [75,3,9]  . . . . . . . . . . . . . . . . .  35
     5.9.  Automation and Transport [82, 83, 84, 85, 86] . . . . . .  35
     5.10. Non-mission-critical data [6,8,9] . . . . . . . . . . . .  36
     5.11. Mission-critical data [70]  . . . . . . . . . . . . . . .  37
     5.12. Summary of Recommendations for QCI or 5QI to DSCP Mapping  37
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  40
   7.  Specific Security Considerations  . . . . . . . . . . . . . .  40
   8.  Security Recommendations for General QoS  . . . . . . . . . .  40
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  41
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  41
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  42
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  43

1.  Introduction

   3GPP has become the preferred set of standards to define cellular
   communication principles and protocols.  With the augmented
   capabilities of smartphones, cellular networks increasingly carry
   non-communication traffic and interconnect with the Internet and
   Enterprise IP networks.  The access networks defined by the 3GPP
   present several design challenges for ensuring end-to-end quality of
   service when these networks interconnect with the Internet or to
   enterprise networks.  Some of these challenges relate to the nature
   of the cellular network itself, being centrally controlled,
   collision-free and primarily designed around subscription level and
   associated services, while other challenges relate to the fact that
   the 3GPP standards are not administered by the same standards body as
   Internet protocols.  While 3GPP has developed tools to enable QoS
   over cellular networks, little guidance exists on how to maintain
   consistency of QoS treatment between cellular networks and the
   Internet, or IP-based Enterprise networks.  As such, enterprises and



Henry, et al.           Expires October 15, 2020                [Page 3]


Internet-Draft                DIFFSERV-QCI                    April 2020


   other operators managing traffic flowing through both 3GPP and
   Internet Protocol links do not always know how to translate 3GPP QoS
   identifiers into Internet Protocol QoS identifiers and vice versa.The
   purpose of this document is to provide such guidance.

1.1.  Related Work

   Several RFCs outline Diffserv QoS recommendations over IP networks,
   including:

   [RFC2474] specifies the Diffserv Codepoint Field.  This RFC also
   details Class Selectors, as well as the Default Forwarding (DF)
   treatment.  [RFC2475] defines a Diffserv architecture [RFC3246]
   specifies the Expedited Forwarding (EF) Per-Hop Behavior (PHB)
   [RFC2597] specifies the Assured Forwarding (AF) PHB.  [RFC3662]
   specifies a Lower Effort Per-Domain Behavior (PDB) [RFC4594] presents
   Configuration Guidelines for Diffserv Service Classes [RFC5127]
   presents the Aggregation of Diffserv Service Classes [RFC5865]
   specifies a DSCP for Capacity Admitted Traffic [RFC8622] presents the
   Lower-Effort Per-Hop Behavior (LE-PHB) for Diffserv

   Note: [RFC4594] is intended to be viewed as a framework for
   supporting Diffserv in any network, regardless of the underlying
   data-link or physical layer protocols.  Its principles could apply to
   IP traffic carried over cellular DataLink and Physical Layer mediums.
   Additionally, the principles of [RFC4594] apply to any traffic
   entering the Internet, regardless of its original source location.
   Thus, [RFC4594] describes different types of traffic expected in IP
   networks and provides guidance as to what DSCP marking(s) should be
   associated with each traffic type.  As such, this document draws
   heavily on [RFC4594] , as well as [RFC5127], and [RFC8100].

   In turn, the relevant standard for cellular LTE QoS is 3GPP [TS
   23.107], which defines more than 1600 General Packet Radio Service
   (GPRS) QoS profiles across multiple classes and associated
   attributes.  As this quantity is large and source of potential
   complexity, the 3GPP Technical Specification Group Services and
   System Aspects, defining the Policy Charging Control Architecture,
   leverages a subset of QoS profiles used as QoS Class Identifiers
   (QCI).  For 5G communications, [TS 23.501] defines 5G QoS
   Identifiers.  This document draws on these specifications, which are
   being progressively updated; the current version of which (at the
   time of writing) are 3GPP [TS 23.203] v16.2.0 and 3GPP [TS 23.501]
   v16.3.0.







Henry, et al.           Expires October 15, 2020                [Page 4]


Internet-Draft                DIFFSERV-QCI                    April 2020


1.2.  Applicability Statement

   This document is applicable to the use of Differentiated Services
   that interconnect with 3GPP LTE or 5G cellular networks (referred to
   as cellular, throughout this document, for simplicity).  These
   guidelines are applicable whether cellular network endpoints are IP-
   enabled, in which case these guidelines can apply end-to-end,
   starting from the endpoint operating system, or whether cellular
   network endpoints are either not IP-enabled, or do not enable QoS, in
   which case these guidelines apply at the interconnection point
   between the cellular access network and the Internet or IP network.
   Such interconnection point can commonly occur at the infrastructure
   Radio Unit (eNodeB), within the infrastructure core network (CN), or
   at the edge of the core network toward the Internet or an Enterprise
   IP network, for example within the Packet Data Network Gateway
   (P-GW).

1.3.  Document Organization

   This document is organized as follows:

   o  Section 2 introduces the QoS logic marking applicable to each
      domain.  We introduce the general logic of Diffserv and the notion
      of domain boundary.  We then examine the 3GPP QoS logic, detailing
      the concept of bearer, QCI and 5QIs, and showing how QCIs and 5QIs
      are implemented and used.

   o  Section 3 provides general recommendations for QoS support at the
      3GPP / Diffserv domains boundaries.

   o  Section 4 proposes a Diffserv to QCI translation scheme, so as to
      suggest DSCP values that can be directly translated into QCIs or
      5QIs values, when traffic moves into a 3GPP domain where QCIs or
      5QIs must be used.

   o  Section 5 proposes a reverse mapping, from QCI to Diffserv.  As
      many QCIs intents do not match existing DSCP values, new DSCP
      values are proposed wherever needed.

   o  Section 6 underlines the resulting IANA requirements for this
      mapping.

   o  Section 7 and Section 8 examine the security consequences of these
      new mapping schemes.







Henry, et al.           Expires October 15, 2020                [Page 5]


Internet-Draft                DIFFSERV-QCI                    April 2020


1.4.  Requirements language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

1.5.  Terminology Used in this Document

   Key terminology used in this document includes:

   EPS Bearer: a path that user traffic (IP flows) uses between the UE
   and the PGW.

   GGSN: Gateway GPRS Support Node, responsible for the internetworking
   between the GPRS network and external networks.  PGW performs the
   GGSN functionalities in EPC.

   IP BS Manager: Internet Protocol Bearer Service Manager, a function
   that manages the IP bearer services.  Part of this function can
   include translation of QoS parameters between EPS and external
   networks.

   UE: User Equipment, the end-device.

   EPS Session: a PDN connection, comprised of one or more IP flows,
   that a UE established and maintains to the EPS.

   SAE: System Architecture Evolution.

   RAN: Radio access network, the radio segment of the LTE network EPS.

   EPC: Evolved Packet Core, the core segment of the LTE network EPS.

   EPS: Evolved Packet System, the LTE network, comprised of the RANs
   and EPC.

   HSS: Home Subscriber Server, the database that contains user-related
   and subscriber-related information.

   LUS: Live Uplink Streaming, a video flow (often real-time) sent from
   a source to a sink.

   SGW: Serving Gateway, the point of interconnection between the RAN
   and the EPC.





Henry, et al.           Expires October 15, 2020                [Page 6]


Internet-Draft                DIFFSERV-QCI                    April 2020


   PGW: Packet Data Network Gateway, point of interconnection between
   the EPC and external IP networks.

   MME: Mobility Management Entity: software function that handles the
   signaling related to mobility and security for the access network.

   PCEF: Policy and Charging Enforcement Function, provides user traffic
   handling and QoS within the PGW.

   PCRF: Policy and Charging Rules Function, a functional entity that
   provides policy, bandwidth and charging functions for each EPS user.

2.  Service Comparison and Default Interoperation of Diffserv and 3GPP
    LTE and 5G

2.1.  Diffserv Domain Boundaries

   It is important to recognize that 3GPP standards allow support for
   principles of [RFC2475].  The user equipment (UE) application
   function may have no active QoS support, or may support Diffserv or
   IntServ functions [TS 23.207] v15 5.2.2.  When Diffserv is supported,
   an Internet Protocol Bearer Service Manager (IP BS Manager) function
   integrated to the UE can translate Diffserv parameters into LTE QoS
   parameters (e.g.  QCI).  As such, the UE IP BS Manager function may
   act as a Diffserv domain boundary (as defined in [RFC2475]) between a
   Diffserv domain present within the UE networking stack and the LTE
   Radio Access Network.

   Additionally, the P-GW interconnects the UE data plane to the
   external networks.  The P-GW is the element that implements Gateway
   GPRS (General Packet Radio Service) Support Node (GGSN)
   functionalities in Evolved Packet Core (EPS) networks.  The GGSN
   includes an IP BS manager function that acts as a Diffserv Edge
   function, and can translate Diffserv parameters to 3GPP QoS
   parameters (e.g.  QCI or 5G NSA 5QI) and vice versa.  In SA 5G, the
   user plane and control plane are separated, and the P-GW for the user
   plane (PGW-U) joins the Service Gateway (SGW-U) into the User Plane
   Function (UPF).

   As such, 3GPP standards allow the existence of a Diffserv domain
   within the UE and outside of the EPS boundaries.  The Diffserv domain
   is not considered within the EPS, where QCIs or 5QIs are used to
   define and transport QoS parameters.








Henry, et al.           Expires October 15, 2020                [Page 7]


Internet-Draft                DIFFSERV-QCI                    April 2020


2.2.  QCI and Bearer Model in 3GPP

   It is important to note that LTE (4G) and 5G standards are an
   evolution of UMTS standards (2G, 3G) developed in the 1990s.  As
   such, these standards recognize [RFC2475] (1998), but not [RFC4594]
   (2006).  EPS networks rely on the notion of bearers.  A bearer is a
   conduit between the UE and the P-GW, and LTE supports two types of
   bearers:

   o  GBR: Guaranteed Bit Rate bearers.  These bearers allocate network
      resources associated to a GBR value associated to the bearer.
      These resources stay allocated (reserved) for the duration of the
      existence of the GBR bearer and the flow it carries.

   o  Non-GBR bearers: also called default bearers, non-GBR are bearers
      for which network resources are not permanently allocated during
      the existence of the bearer and the flow it carries.  As such, one
      or more non-GBR bearer may share the same set of temporal
      resources.

   Each EPS bearer is identified by a name and number, and is associated
   with specific QoS parameters of various types:

   1.  QoS Class Identifiers (QCI).  A QCI is a scalar associated to a
       bearer, and is used to define the type of traffic and service
       expected in the bearer.  [TS 23.107] v15 defines 4 basic classes:
       conversational, streaming, interactive and background.  These
       classes are defined more in details in Section 2.3.  Each class
       includes multiple types of traffic, each associated with sets of
       attributes, thus permitting the definition of more than 1600
       different QoS profiles.  [TS 23.203] v16 6.1.7.2 reduces the
       associated complexity by characterizing traffic based on up to 6
       attributes, resulting in 26 types of traffic and their associated
       expected service requirements through the use of 26 scalars
       (QCI).  Each QCI is defined in the relation to the following six
       performance characteristics:

   2.  Resource Type (GBR or Non-GBR).

   3.  Priority: a scalar used as a tie breaker if two packets compete
       for a given network resource.  A lower value indicates a higher
       priority.

   4.  Packet Delay Budget: marks the upper bound for the time that a
       packet may be delayed between the UE and the PCRF (Policy and
       Charging Rules Function) or the PCEF function (Policy and
       Charging Enforcement Function) residing inside the P-GW.  PCEF
       supports offline and online charging while PCRF is real-time.



Henry, et al.           Expires October 15, 2020                [Page 8]


Internet-Draft                DIFFSERV-QCI                    April 2020


       Either component, being in charge of policing and charging, can
       determine resource reservation actions and policies.

   5.  Packet Error Loss Rate, defines an upper bound for a rate of non-
       congestion related packet losses.  The purpose of the PELR is to
       allow for appropriate link layer protocol configurations when
       needed.

   6.  Maximum Burst Size (only for some GBR QCIs), defines the amount
       of data which the Radio Access Network (RAN) is expected to
       deliver within the part of the Packet Delay Budget allocated to
       the link between the UE and the radio base station.  If more data
       is transmitted from the application, the Packet Delay Budget may
       be exceeded.

   7.  Data rate Averaging Window (only for some GBR QCIs), defines the
       'sliding window' duration over which the GBR and MBR are
       calculated.

   Although [TS 23.203] v16 6.1.7.2 associates each QCI with up to 6
   characteristics, it is clear that these characteristics are
   constrained by bandwidth allocation, in particular on the radio link
   that are associated with three commonly used parameters:

   1.  Maximum Bit Rate (MBR), only valid for GBR bearers, defines the
       maximum sustained traffic rate that the bearer can support.

   2.  Guaranteed Bit Rate (GBR), only valid for GBR bearers, defines
       the minimum traffic rate reserved for the bearer.

   3.  Aggregate MBR (AMBR), defines the total amount of bit rate
       available for a group of non-GBR bearers.  AMBR is often used to
       provide differentiated service levels to different types of
       customers.

2.3.  QCI Definition and Logic

   [TS 23.107] v15 6.3 defines four possible traffic classes.  These
   four general classes are used as the foundation from which QCI
   categories are defined in [TS 23.203].  The categorization is made
   around the notion of sensitivity to delay.

2.3.1.  Conversational

   The conversational class is intended to carry real-time traffic
   flows.  The expectation of such class is a live conversation between
   two humans or a group.  Examples of such flows include [TS 23.107]
   v15 6.3.1 telephony speech, but also VoIP and video conferencing.



Henry, et al.           Expires October 15, 2020                [Page 9]


Internet-Draft                DIFFSERV-QCI                    April 2020


   Video conference would be seen as a different class from telephony in
   the Diffserv model.  However, 3GPP positions them in the same general
   class, as all of them include live conversations.  Sensitivity to
   delay is high because of the real-time nature of the flows.  The time
   relation between the stream entities have to be preserved (to
   maintain the same experience for all flows and all parties involved
   in the conversation).

2.3.2.  Streaming

   The streaming class is intended for flows where the user is watching
   real time video, or listening to real-time audio (or both).  The
   real-time data flow is always aiming at a live (human) destination.
   It is important to note that the Streaming class is intended to be
   both a real-time flow and a one-way transport.  Two-way real-time
   traffic belongs to the conversational class, and non-real-time flows
   belong to the interactive or the background classes.  The delay
   sensitivity is lower than that of Conversational flows, because it is
   expected that the receiving end includes a time alignment function
   (e.g. buffering).  As the flow is unidirectional, variations in delay
   do not conversely affect the user experience as long as the variation
   is within the alignment function boundaries.

2.3.3.  Interactive

   The interactive class is intended for flows where a machine or human
   is requesting data from a remote equipment (e.g. a server).  Examples
   of human interaction with the remote equipment are: web browsing,
   data base retrieval, server access.  Examples of machines interaction
   with remote equipment are: polling for measurement records and
   automatic data base enquiries (tele-machines).  Delay sensitivity is
   average, and is based on round trip time (overall time between
   emission of the request and reception of the response).

2.3.4.  Background

   The background class applies to flows where the equipment is sending
   or receiving data files without direct user interaction (e.g. emails,
   SMS, database transfers etc.)  As such, delay sensitivity is low.
   Background is described as delivery-time insensitive.

   Based upon the above principles, [TS 23.203] has defined several
   QCIs.  [TS 23.203] Release 16 6.1.7-A defines 26 QCIs:

   +----+----------+----------+--------+--------+----------------------+
   | QC | Resource | Priority | Packet | Packet | Example Services     |
   | I  | Type     | Level    | Delay  | Error  |                      |
   |    |          |          | Budget | Loss   |                      |



Henry, et al.           Expires October 15, 2020               [Page 10]


Internet-Draft                DIFFSERV-QCI                    April 2020


   +----+----------+----------+--------+--------+----------------------+
   | 1  | GBR      | 2        | 100 ms | 10.E-2 | Conversational Voice |
   |    |          |          |        |        |                      |
   | 2  | GBR      | 4        | 150 ms | 10.E-3 | Conversational Video |
   |    |          |          |        |        | (Live Streaming)     |
   |    |          |          |        |        |                      |
   | 3  | GBR      | 3        | 50 ms  | 10.E-3 | Real Time Gaming,    |
   |    |          |          |        |        | V2X messages,        |
   |    |          |          |        |        | Electricity          |
   |    |          |          |        |        | distribution (medium |
   |    |          |          |        |        | voltage) Process     |
   |    |          |          |        |        | automation           |
   |    |          |          |        |        | (monitoring)         |
   |    |          |          |        |        |                      |
   | 4  | GBR      | 5        | 300 ms | 10.E-6 | Non-Conversational   |
   |    |          |          |        |        | Video  (Buffered     |
   |    |          |          |        |        | Streaming)           |
   |    |          |          |        |        |                      |
   | 65 | GBR      | 0.7      | 75 ms  | 10.E-2 | Mission Critical     |
   |    |          |          |        |        | user plane Push To   |
   |    |          |          |        |        | Talk voice (e.g.,    |
   |    |          |          |        |        | MCPTT)               |
   |    |          |          |        |        |                      |
   | 66 | GBR      | 2        | 100 ms | 10.E-2 | Non-Mission-Critical |
   |    |          |          |        |        | user plane Push To   |
   |    |          |          |        |        | Talk voice           |
   |    |          |          |        |        |                      |
   | 67 | GBR      | 1.5      | 100 ms | 10.E-3 | Mission Critical     |
   |    |          |          |        |        | Video user plane     |
   |    |          |          |        |        |                      |
   | 75 | GBR      | 2.5      | 50 ms  | 10.E-2 | V2X messages         |
   |    |          |          |        |        |                      |
   | 71 | GBR      | 5.6      | 150 ms | 10.E-6 | "Live" Uplink        |
   |    |          |          |        |        | Streaming            |
   |    |          |          |        |        |                      |
   | 72 | GBR      | 5.6      | 300 ms | 10.E-4 | "Live" Uplink        |
   |    |          |          |        |        | Streaming            |
   |    |          |          |        |        |                      |
   | 73 | GBR      | 5.6      | 300 ms | 10.E-8 | "Live" Uplink        |
   |    |          |          |        |        | Streaming            |
   |    |          |          |        |        |                      |
   | 74 | GBR      | 5.6      | 500 ms | 10.E-8 | "Live" Uplink        |
   |    |          |          |        |        | Streaming            |
   |    |          |          |        |        |                      |
   | 76 | GBR      | 5.6      | 500 ms | 10.E-4 | "Live" Uplink        |
   |    |          |          |        |        | Streaming            |
   |    |          |          |        |        |                      |
   | 5  | Non-GBR  | 1        | 100 ms | 10.E-6 | IMS Signalling       |



Henry, et al.           Expires October 15, 2020               [Page 11]


Internet-Draft                DIFFSERV-QCI                    April 2020


   |    |          |          |        |        |                      |
   | 6  | Non-GBR  | 6        | 300 ms | 10.E-6 | Video (Buffered      |
   |    |          |          |        |        | Streaming) TCP-based |
   |    |          |          |        |        | (e.g. www, email,    |
   |    |          |          |        |        | chat, ftp, p2p file  |
   |    |          |          |        |        | sharing, progressive |
   |    |          |          |        |        | video)               |
   |    |          |          |        |        |                      |
   | 7  | Non-GBR  | 7        | 100 ms | 10.E-3 | Voice, Video (live   |
   |    |          |          |        |        | streaming),          |
   |    |          |          |        |        | interactive gaming   |
   |    |          |          |        |        |                      |
   | 8  | Non-GBR  | 8        | 300 ms | 10.E-6 | Video (buffered      |
   |    |          |          |        |        | streaming) TCP-based |
   |    |          |          |        |        | (e.g. www, email,    |
   |    |          |          |        |        | chat, ftp, p2p file  |
   |    |          |          |        |        | sharing, progressive |
   |    |          |          |        |        | video)               |
   |    |          |          |        |        |                      |
   | 9  | Non-GBR  | 9        | 300 ms | 10.E-6 | Same as 8            |
   |    |          |          |        |        |                      |
   | 69 | Non-GBR  | 0.5      | 60 ms  | 10.E-6 | Mission Critical     |
   |    |          |          |        |        | delay sensitive      |
   |    |          |          |        |        | signalling (e.g.,    |
   |    |          |          |        |        | MC-PTT signalling,   |
   |    |          |          |        |        | MC Video signalling) |
   |    |          |          |        |        |                      |
   | 70 | Non-GBR  | 5.5      | 200 ms | 10.E-6 | Mission Critical     |
   |    |          |          |        |        | Data (e.g. example   |
   |    |          |          |        |        | services are the     |
   |    |          |          |        |        | same as QCI 6/8/9)   |
   |    |          |          |        |        |                      |
   | 79 | Non-GBR  | 6.5      | 50 ms  | 10.E-2 | V2X messages         |
   |    |          |          |        |        |                      |
   | 80 | Non-GBR  | 6.8      | 10 ms  | 10.E-2 | Low latency eMMB     |
   |    |          |          |        |        | applications         |
   |    |          |          |        |        | (TCP/UDP-based);     |
   |    |          |          |        |        | augmented reality    |
   |    |          |          |        |        |                      |
   | 82 | GBR      | 1.9      | 10 ms  | 10.E-6 | Discrete automation  |
   |    |          |          |        |        | (small packets)      |
   |    |          |          |        |        |                      |
   | 83 | GBR      | 2.2      | 10 ms  | 10.E-4 | Discrete automation  |
   |    |          |          |        |        | (large packets)      |
   |    |          |          |        |        |                      |
   | 84 | GBR      | 2.4      | 30 ms  | 10.E-5 | Intelligent          |
   |    |          |          |        |        | Transport Systems    |
   |    |          |          |        |        |                      |



Henry, et al.           Expires October 15, 2020               [Page 12]


Internet-Draft                DIFFSERV-QCI                    April 2020


   | 85 | GBR      | 2.1      | 5 ms   | 10.E-5 | Electricity          |
   |    |          |          |        |        | Distribution -  High |
   |    |          |          |        |        | Voltage              |
   +----+----------+----------+--------+--------+----------------------+

   Several QCIs cover the same application types.  For example, QCIs 6,
   8 and 9 all apply to buffered streaming video and web applications.
   However, LTE context distinguishes several types of customers and
   environments.  As such, QCI 6 can be used for the prioritization of
   non-real-time data (i.e. most typically TCP-based services/
   applications) of MPS (multimedia priority services) subscribers, when
   the network supports MPS.  QCI 8 can be used for a dedicated "premium
   bearer" (e.g. associated with premium content) for any subscriber or
   subscriber group, while QCI 9 can be used for the default bearer for
   non-privileged subscribers.

2.4.  QCI implementations

   [TS 23.203] v16 defines multiple QCIs.  However, a UE or a EPS does
   not need to implement all supported QCIs, even when all matching
   types of traffic are expected between the UE and the network.  In
   practical implementations, it is common for an EPS to implement one
   GBR bearer where at least QCI 1 is directed (and optionally other GBR
   QCIs), and another default bearer where all other traffic to and from
   the same UE is directed.  The QCI associated to that second bearer
   may depend on the subscriber category.  As such, the QCI listed in
   Section 2.3 are indicative of performance and traffic type
   classifications, and are not strict in their implementation mandate.

2.5.  5QI and flow-based QoS Model in 3GPP 5G

   While 4G LTE QoS is enforced at the EPS bearer level, 5G QoS focuses
   on the transported flows.  A QoS Flow ID (QFI) identifies a given QoS
   Flow.  In the User Plane, the traffic with a given QFI within a PDU
   session is treated in the same way.  The 5G QoS Identifier (5QI) is
   used in 3GPP to identify a specific QoS forwarding behavior for a 5G
   QoS Flow (similar to the QCI value for LTE, with the difference that
   5QI applies to a flow, carried at some point in a bearer, while QCI
   applies to a bearer within which certain types of flows are
   expected).  As such, the 5QI defines packet loss rate, packet delay
   budget etc.  In the 5G system, the entity named Session Management
   Function (SMF) manages the QoS information.  The SMF provides QFI
   information to the Radio Access Network (RAN) for mapping the various
   QoS flows to access network resources (i.e., data radio bearers).
   The RAN performs packet marking in the uplink on a per QoS Flow
   basis, with a marking value determined by the QFI and a treatment
   matching the asscoiated 5QI.  The SMF also instructs the User Plane
   Function (UPF) for classification, bandwidth enforcement and marking



Henry, et al.           Expires October 15, 2020               [Page 13]


Internet-Draft                DIFFSERV-QCI                    April 2020


   of the user plane traffic in downlink.  Such packet marking
   information includes the QFI and the transport level packet marking
   value (i.e., the value of the DSCP field in the outer IP header).  In
   [TS 23.501], 3GPP provides the 5G QoS characteristics associated with
   the 5QIs, and specifies the packet forwarding treatment that a QoS
   Flow receives end-to-end, from the UE up to the UPF (and back).  The
   characteristics considered are:

   o  Resource type, i.e., if the flow requires resources to be
      allocated for Guaranteed Bandwidth Rate (GBR), delay critical GBR
      (DCGBR), or non-GBR.

   o  Default priority level

   o  Packet delay budget (PDB), including the PDB consumed in the 5G
      core network

   o  Packet Error Rate (PER)

   o  Averaging window (in milliseconds), applicable for GBR and delay-
      critical GBR

   o  Default maximum data burst volume (in bytes), applicable for
      delay-critical GBR only

   The following table shows a simplified version from the standardized
   [TS 23.501] 5QI to QoS characteristics mapping.

   +----+-------+-------+------+-------+-------+-------+---------------+
   | 5Q | Resou | Prior | Pack | Packe | Defau | Defau | Example       |
   | I  | rce   | ity   | et D | t     | lt    | lt    | Services      |
   |    | Type  | Level | elay | Error | Max   | Avg W |               |
   |    |       |       | Budg | Rate  | Burst | indow |               |
   |    |       |       | et   |       |       |       |               |
   +----+-------+-------+------+-------+-------+-------+---------------+
   | 1  | GBR   | 20    | 100  | 10.E- | N/A   | 2000  | Conversationa |
   |    |       |       | ms   | 2     |       |       | l voice       |
   |    |       |       |      |       |       |       |               |
   | 2  | GBR   | 40    | 150  | 10.E- | N/A   | 2000  | Conversationa |
   |    |       |       | ms   | 3     |       |       | l video (live |
   |    |       |       |      |       |       |       | streaming)    |
   |    |       |       |      |       |       |       |               |
   | 3  | GBR   | 30    | 50   | 10.E- | N/A   | 2000  | Real time     |
   |    |       |       | ms   | 3     |       |       | gaming, V2X   |
   |    |       |       |      |       |       |       | messages,     |
   |    |       |       |      |       |       |       | medium        |
   |    |       |       |      |       |       |       | voltage       |
   |    |       |       |      |       |       |       | electricity   |



Henry, et al.           Expires October 15, 2020               [Page 14]


Internet-Draft                DIFFSERV-QCI                    April 2020


   |    |       |       |      |       |       |       | dist.         |
   |    |       |       |      |       |       |       |               |
   | 4  | GBR   | 50    | 300  | 10.E- | N/A   | 2000  | non-conversat |
   |    |       |       | ms   | 6     |       |       | ional video   |
   |    |       |       |      |       |       |       | (buffered     |
   |    |       |       |      |       |       |       | streaming)    |
   |    |       |       |      |       |       |       |               |
   | 65 | GBR   | 7     | 75   | 10.E- | N/A   | 2000  | Mission       |
   |    |       |       | ms   | 2     |       |       | critical user |
   |    |       |       |      |       |       |       | plane push-   |
   |    |       |       |      |       |       |       | to-talk voice |
   |    |       |       |      |       |       |       | (e.g. MCPTT)  |
   |    |       |       |      |       |       |       |               |
   | 66 | GBR   | 20    | 100  | 10.E- | N/A   | 2000  | Non-mission   |
   |    |       |       | ms   | 3     |       |       | critical user |
   |    |       |       |      |       |       |       | plane push-   |
   |    |       |       |      |       |       |       | to-talk voice |
   |    |       |       |      |       |       |       |               |
   | 67 | GBR   | 15    | 100  | 10.E- | N/A   | 2000  | Mission       |
   |    |       |       | ms   | 3     |       |       | critical user |
   |    |       |       |      |       |       |       | plane video   |
   |    |       |       |      |       |       |       |               |
   | 71 | GBR   | 56    | 150  | 10.E- | N/A   | 2000  | "Live" uplink |
   |    |       |       | ms   | 6     |       |       | streaming     |
   |    |       |       |      |       |       |       |               |
   | 72 | GBR   | 56    | 300  | 10.E- | N/A   | 2000  | "Live" uplink |
   |    |       |       | ms   | 4     |       |       | streaming     |
   |    |       |       |      |       |       |       |               |
   | 73 | GBR   | 56    | 300  | 10.E- | N/A   | 2000  | "Live" uplink |
   |    |       |       | ms   | 8     |       |       | streaming     |
   |    |       |       |      |       |       |       |               |
   | 74 | GBR   | 56    | 500  | 10.E- | N/A   | 2000  | "Live" uplink |
   |    |       |       | ms   | 8     |       |       | streaming     |
   |    |       |       |      |       |       |       |               |
   | 76 | GBR   | 56    | 500  | 10.E- | N/A   | 2000  | "Live" uplink |
   |    |       |       | ms   | 4     |       |       | streaming     |
   |    |       |       |      |       |       |       |               |
   | 5  | non-  | 10    | 100  | 10.E- | N/A   | N/A   | IMS signaling |
   |    | GBR   |       | ms   | 6     |       |       |               |
   |    |       |       |      |       |       |       |               |
   | 6  | non-  | 60    | 300  | 10.E- | N/A   | N/A   | Video         |
   |    | GBR   |       | ms   | 6     |       |       | (Buffered     |
   |    |       |       |      |       |       |       | Streaming)    |
   |    |       |       |      |       |       |       | TCP-based     |
   |    |       |       |      |       |       |       | (e.g. www,    |
   |    |       |       |      |       |       |       | email, chat,  |
   |    |       |       |      |       |       |       | etc.)         |
   |    |       |       |      |       |       |       |               |



Henry, et al.           Expires October 15, 2020               [Page 15]


Internet-Draft                DIFFSERV-QCI                    April 2020


   | 7  | non-  | 70    | 100  | 10.E- | N/A   | N/A   | Voice, Video  |
   |    | GBR   |       | ms   | 3     |       |       | (live         |
   |    |       |       |      |       |       |       | streaming),   |
   |    |       |       |      |       |       |       | interactive   |
   |    |       |       |      |       |       |       | gaming        |
   |    |       |       |      |       |       |       |               |
   | 8  | non-  | 80    | 300  | 10.E- | N/A   | N/A   | Video         |
   |    | GBR   |       | ms   | 6     |       |       | (Buffered     |
   |    |       |       |      |       |       |       | Streaming)    |
   |    |       |       |      |       |       |       | TCP-based     |
   |    |       |       |      |       |       |       | (e.g. www,    |
   |    |       |       |      |       |       |       | email, chat,  |
   |    |       |       |      |       |       |       | etc.)         |
   |    |       |       |      |       |       |       |               |
   | 9  | non-  | 90    | 300  | 10.E- | N/A   | N/A   | Same as 8     |
   |    | GBR   |       | ms   | 6     |       |       |               |
   |    |       |       |      |       |       |       |               |
   | 69 | non-  | 5     | 60   | 10.E- | N/A   | N/A   | Mission       |
   |    | GBR   |       | ms   | 6     |       |       | Critical      |
   |    |       |       |      |       |       |       | delay         |
   |    |       |       |      |       |       |       | sensitive     |
   |    |       |       |      |       |       |       | signalling    |
   |    |       |       |      |       |       |       | (e.g., MC-    |
   |    |       |       |      |       |       |       | PMC)          |
   |    |       |       |      |       |       |       |               |
   | 70 | non-  | 55    | 200  | 10.E- | N/A   | N/A   | Mission       |
   |    | GBR   |       | ms   | 6     |       |       | critical data |
   |    |       |       |      |       |       |       | (e.g. same    |
   |    |       |       |      |       |       |       | examples as   |
   |    |       |       |      |       |       |       | QCI/5QI 6,7,8 |
   |    |       |       |      |       |       |       |               |
   | 79 | non-  | 65    | 50   | 10.E- | N/A   | N/A   | V2X messages  |
   |    | GBR   |       | ms   | 2     |       |       |               |
   |    |       |       |      |       |       |       |               |
   | 80 | non-  | 68    | 10   | 10.E- | N/A   | N/A   | Low latency   |
   |    | GBR   |       | ms   | 6     |       |       | eMMB          |
   |    |       |       |      |       |       |       | applications  |
   |    |       |       |      |       |       |       | (TCP/UDP-     |
   |    |       |       |      |       |       |       | based);       |
   |    |       |       |      |       |       |       | augmented     |
   |    |       |       |      |       |       |       | reality       |
   |    |       |       |      |       |       |       |               |
   | 82 | DCGBR | 19    | 10   | 10.E- | 255 B | 2000  | Discrete      |
   |    |       |       | ms   | 4     |       | ms    | automation    |
   |    |       |       |      |       |       |       |               |
   | 83 | DCGBR | 22    | 10   | 10.E- | 1354  | 2000  | Discrete      |
   |    |       |       | ms   | 4     | B     | ms    | automation    |
   |    |       |       |      |       |       |       |               |



Henry, et al.           Expires October 15, 2020               [Page 16]


Internet-Draft                DIFFSERV-QCI                    April 2020


   | 84 | DCGBR | 24    | 30   | 10.E- | 1354  | 2000  | Intelligent   |
   |    |       |       | ms   | 5     | B     | ms    | Transport     |
   |    |       |       |      |       |       |       | Systems       |
   |    |       |       |      |       |       |       |               |
   | 85 | DCGBR | 21    | 5 ms | 10.E- | 255 B | 2000  | Electricity   |
   |    |       |       |      | 5     |       | ms    | distribution, |
   |    |       |       |      |       |       |       | High voltage, |
   |    |       |       |      |       |       |       | V2X           |
   |    |       |       |      |       |       |       |               |
   | 86 | DCGBR | 18    | 5 ms | 10.E- | 1354  | 2000  | V2X,          |
   |    |       |       |      | 4     | B     | ms    | collision     |
   |    |       |       |      |       |       |       | avoidance,    |
   |    |       |       |      |       |       |       | platooning,   |
   |    |       |       |      |       |       |       | self driving  |
   +----+-------+-------+------+-------+-------+-------+---------------+

   Although the focus of 5QI and that of QCI is different, it should be
   noted that the traffic examples provided by each QCI match the
   traffic intent for a 5QI with matching number.  The 5QI default
   priority level is a tenfold expression of the QCI priority level (and
   this document will refer to the QCI priority levels for simplicity)
   As such, any given QCI or 5QI can be equivalised to the same DSCP
   value.  In turn, an application and its given DSCP value can be
   expressed either in a QCI or a 5QI (provided that both exist for the
   assooiated traffic or application).

2.6.  GSMA IPX Guidelines Interpretation and Conflicts

   3GPP standards do not define or recommend any specific mapping
   between each QCI or 5QI and Diffserv, and leaves that mapping choice
   to the operator of the Edge domain boundary (e.g.  UE software stack
   developer, P-GW operator).  However, 3GPP defines that "for the IP
   based backbone, Differentiated Services defined by IETF shall be
   used" ([TS 23.107] v15 6.4.7).

   The GSM Association (GSMA) has published an Inter-Service Provider IP
   Backbone Guideline reference document [ir.34] that provides technical
   guidance to participating service providers for connecting IP based
   networks and services to achieve roaming and inter-working services.
   The document built upon [RFC3246] and [RFC2597], and upon the initial
   definition of 4 service classes in [TS 23.107] v15 to recommend a
   mapping to EF for conversational traffic, to AF41 for Streaming
   traffic, to AF31, AF21 and AF11 for different traffic in the
   Interactive class, and to BE for background traffic.

   These GSMA Guidelines were developed without reference to existing
   IETF specifications for various services, referenced in Section 1.1.
   Additionally, the same recommendations remained while new traffic



Henry, et al.           Expires October 15, 2020               [Page 17]


Internet-Draft                DIFFSERV-QCI                    April 2020


   types under each 3GPP general class were added.  As such, the GSMA
   recommendations yield to several inconsistencies with [RFC4594],
   including:

   o  Recommending EF for real-time (conversational) video, for which
      [RFC4594] recommends AF41.

   o  Recommending AF31 for DNS traffic, for which [RFC4594] recommends
      the standard service class (DF)

   o  Recommending AF31 for all types of signaling traffic, thus losing
      the ability to differentiate between the various types of
      signaling flows, as recommended in[RFC4594] section 5.1.

   o  Recommending AF21 for WAP browsing and WEB browsing, for which
      [RFC4594] recommends the High Throughput data class

   o  Recommending AF11 for remote connection protocols, such as telnet
      or SSH, for which [RFC4594] recommends the OAM class.

   o  Recommending DF for file transfers, for which [RFC4594] recommends
      the High Throughput Data class.

   o  Recommending DF for email exchanges, for which [RFC4594]
      recommends the High Throughput Data class.

   o  Recommending DF for MMS exchanged over SMTP, for which [RFC4594]
      recommends the High Throughput Data class.

   The document [ir.34] aso does not provide guidance for QCIs other
   than 1 to 9, leaving the case of the 12 other QCIs unaddressed.

   Thus, document [ir.34] conflicts with the overall Diffserv traffic-
   conditioning service plan, both in the services specified and the
   code points specified for them.  As such, these two plans cannot be
   normalized.  Rather, as discussed in [RFC2474] Section 2, the two
   domains (GSMA and other IP networks) are different Differentiated
   Services Domains separated by a Differentiated Services Boundary.  At
   that boundary, code points from one domain are translated to code
   points for the other, and maybe to Default (zero) if there is no
   corresponding service to translate to.

3.  P-GW Device Marking and Mapping Capability Recommendations

   This document assumes and RECOMMENDS that all P-GWs (as the
   interconnects between cellular and other IP networks) and all other
   interconnection points between cellular and other IP networks support
   the ability to:



Henry, et al.           Expires October 15, 2020               [Page 18]


Internet-Draft                DIFFSERV-QCI                    April 2020


   o  mark DSCP, per Diffserv standards

   o  mark QCI, per the [TS 23.203] standard, or 5QI, as per the [TS
      23.501] standard

   o  support fully-configurable mappings between DSCP and QCI or 5QI

   o  process DSCP markings set by cellular endpoint devices

   This document further assumes and RECOMMENDS that all cellular
   endpoint devices (UE) support the ability to:

   o  mark DSCP, per Diffserv standards

   o  mark QCI, per the [TS 23.203] standard, OR 5QI, per the [TS
      23.501] standard

   o  support fully-configurable mappings between DSCP (set by
      applications in software) and QCI or 5QI (set by the operating
      system and/or the LTE infrastructure)

   Having made the assumptions and recommendations above, it bears
   mentioning that while the mappings presented in this document are
   RECOMMENDED to replace the current common default practices (as
   discussed in Section 2.3 and Section 2.4), these mapping
   recommendations are not expected to fit every last deployment model,
   and as such MAY be overridden by network administrators, as needed.

4.  DSCP to QCI or 5QI Mapping Recommendations

4.1.  Control Traffic

4.1.1.  Network Control Protocols

   The Network Control service class is used for transmitting packets
   between network devices (e.g., routers) that require control
   (routing) information to be exchanged between nodes within the
   administrative domain, as well as across a peering point between
   different administrative domains.

   [RFC4594] Section 3.2 recommends that Network Control Traffic be
   marked CS6 DSCP.  Additionally, as stated in [RFC4594] Section 3.1:
   "CS7 DSCP value SHOULD be reserved for future use, potentially for
   future routing or control protocols."

   Network Control service is not directly called by any specific QCI or
   5QI description, because 3GPP network control does not operate over
   UE data channels.  It should be noted that encapsulated routing



Henry, et al.           Expires October 15, 2020               [Page 19]


Internet-Draft                DIFFSERV-QCI                    April 2020


   protocols for encapsulated or overlay networks (e.g., VPN, Network
   Virtualization Overlays, etc.) are not Network Control Traffic for
   any physical network at the cellular space; hence, they SHOULD NOT be
   marked with CS6 in the first place, and are not expected to be
   forwarded to the cellular data plane.

   However, when such network control traffic is forwarded, it is
   expected to receive a high priority and level of service.  As such,
   packets marked to CS7 DSCP are RECOMMENDED to be mapped to QCI 82,
   thus benefiting from a dedicated bearer with low packet error loss
   rate (10.E-4) and low budget delay (10 ms).  Similarly, it is
   RECOMMENDED to map Network Control Traffic marked CS6 to QCI/5QI 82,
   thereby admitting it to the Discrete Automation (GBR) category with a
   relative priority level of 1.9/19.

4.1.2.  Operations, Administration, and Maintenance (OAM)

   The OAM (Operations, Administration, and Maintenance) service class
   is recommended for OAM&P (Operations, Administration, and Maintenance
   and Provisioning).  The OAM service class can include network
   management protocols, such as SNMP, Secure Shell (SSH), TFTP, Syslog,
   etc., as well as network services, such as NTP, DNS, DHCP, etc.

   [RFC4594] Section 3.3, recommends that OAM traffic be marked CS2
   DSCP.

   Applications using this service class require a low packet loss but
   are relatively not sensitive to delay.  This service class is
   configured to provide good packet delivery for intermittent flows.
   As such, packets marked to CS2 are RECOMMENDED to be mapped to
   QCI/5QI 9, thus admitting it to the non-GBR Buffered video traffic,
   with a relative priority of 9/90.

4.2.  User Traffic

   User traffic is defined as packet flows between different users or
   subscribers.  It is the traffic that is sent to or from end-terminals
   and that supports a very wide variety of applications and services
   [RFC4594] Section 4.

   Network administrators can categorize their applications according to
   the type of behavior that they require and MAY choose to support all
   or a subset of the defined service classes.








Henry, et al.           Expires October 15, 2020               [Page 20]


Internet-Draft                DIFFSERV-QCI                    April 2020


4.2.1.  Telephony

   The Telephony service class is recommended for applications that
   require real-time, very low delay, very low jitter, and very low
   packet loss for relatively constant-rate traffic sources (inelastic
   traffic sources).  This service class SHOULD be used for IP telephony
   service.  The fundamental service offered to traffic in the Telephony
   service class is minimum jitter, delay, and packet loss service up to
   a specified upper bound.  [RFC4594] Section 4.1 recommends that
   Telephony traffic be marked EF DSCP.

   3GPP [TS 23.203] describes two QCIs adapted to Voice traffic: QCI 1
   (GBR) and QCI 7 (non-GBR).  The same logic is found in [TS 23.501]
   for the same 5QIs.  However, Telephony traffic as intended in
   [RFC4594] supposes resource allocation control.  Telephony SHOULD be
   configured to receive guaranteed forwarding resources so that all
   packets are forwarded quickly.  The Telephony service class SHOULD be
   configured to use Priority Queuing system.  QCI 7 does not match
   these conditions.  As such, packets marked to EF are RECOMMENDED to
   be mapped to QCI/5QI 1, thus admitting it to the GBR Conversational
   Voice category, with a relative priority of 2/20.

4.2.2.  Signaling

   The Signaling service class is recommended for delay-sensitive
   client-server (e.g., traditional telephony) and peer-to-peer
   application signaling.  Telephony signaling includes signaling
   between 1) IP phone and soft-switch, 2) soft-client and soft-switch,
   and 3) media gateway and soft-switch as well as peer-to-peer using
   various protocols.  This service class is intended to be used for
   control of sessions and applications.  [RFC4594] Section 4.2
   recommends that Signaling traffic be marked CS5 DSCP.

   While Signaling is recommended to receive a superior level of service
   relative to the default class (e.g., relative to QCI 7), it does not
   require the highest level of service (i.e., GBR and very high
   priority).  As such, it is RECOMMENDED to map Signaling traffic
   marked CS5 DSCP to QCI/5QI 4, thereby admitting it to the GBR Non-
   conversational video category, with a relative priority level of
   5/50.

   Note: Signaling traffic for native Voice dialer applications should
   be exchanged over a control channel, and is not expected to be
   forwarded in the data-plane.  However, Signaling for non-native (OTT)
   applications may be carried in the data-plane.  In this case,
   Signaling traffic is control-plane traffic from the perspective of
   the voice/video telephony overlay-infrastructure.  As such, Signaling




Henry, et al.           Expires October 15, 2020               [Page 21]


Internet-Draft                DIFFSERV-QCI                    April 2020


   should be treated with preferential servicing versus other data-plane
   flows.

4.2.3.  Multimedia Conferencing

   The Multimedia Conferencing service class is recommended for
   applications that require real-time service for rate-adaptive
   traffic.  [RFC4594] Section 4.3 recommends Multimedia Conferencing
   traffic be marked AF4x (that is, AF41, AF42, and AF43, according to
   the rules defined in [RFC2475].  The Diffserv model allows for three
   values to allow for different relative priorities of flows of the
   same nature.

   The primary media type typically carried within the Multimedia
   Conferencing service class marked AF41 is video intended to be a
   component of a real-time exchange; as such, it is RECOMMENDED to map
   AF41 into the Conversational Video (Live Streaming) category, with a
   GBR.  Specifically, it is RECOMMENDED to map AF41 to QCI/5QI 2,
   thereby admitting AF41 into the GBR Conversational Video, with a
   relative priority of 4/40.

   AF42 is typically reserved for video intended to be a component of
   real-time exchange, but which criticality is less than traffic
   carried with a marking of AF41.  As such, it is RECOMMENDED to map
   AF42 into the Conversational Video (Live Streaming) category, with a
   GBR, but a lower priority than QCI/5QI 2.  Specifically, it is
   RECOMMENDED to map AF42 to QCI/5QI 4, thereby admitting AF42 into the
   GBR Conversational Video, with a relative priority of 5/50.

   Traffic marked AF43 is typically used for real-time video exchange of
   lower criticality.  As such, it is RECOMMENDED to map AF43 into the
   Conversational Video (Live Streaming) category, but without a GBR.
   Specifically, it is RECOMMENDED to map AF43 to QCI/5QI 7, thereby
   admitting AF437 into the non-GBR Voice, Video and Interactive gaming,
   with a relative priority of 7/70.

4.2.4.  Real-Time Interactive

   The Real-Time Interactive service class is recommended for
   applications that require low loss and jitter and very low delay for
   variable-rate inelastic traffic sources.  Such applications may
   include inelastic video-conferencing applications, but may also
   include gaming applications (as pointed out in [RFC4594] Sections 2.1
   through 2.3 and Section 4.4.  [RFC4594] Section 4.4 recommends Real-
   Time Interactive traffic be marked CS4 DSCP.

   The primary media type typically carried within the Real-Time
   Interactive service class is video; as such, it is RECOMMENDED to map



Henry, et al.           Expires October 15, 2020               [Page 22]


Internet-Draft                DIFFSERV-QCI                    April 2020


   this class into a low latency Category.  Specifically, it is
   RECOMMENDED to map CS4 to QCI 80, thereby admitting Real-Time
   Interactive traffic into the non-GBR category Low Latency eMBB
   (enhanced Mobile Broadband) applications with a relative priority of
   6.8.  In cases where GBR is required, for example because a single
   bearer is allocated for all non-GBR traffic, using a GBR equivalent
   is also acceptable.  In this case, it is RECOMMENDED to map CS4 to
   QCI/5QI 3, thereby admitting Real-Time Interactive traffic into the
   GBR category Real-time gaming, with a relative priority of 3/30.

4.2.5.  Multimedia Streaming

   The Multimedia Streaming service class is recommended for
   applications that require near-real-time packet forwarding of
   variable-rate elastic traffic sources.  Typically, these flows are
   unidirectional.  [RFC4594] Section 4.5 recommends Multimedia
   Streaming traffic be marked AF3x (that is, AF31, AF32, and AF33,
   according to the rules defined in [RFC2475].

   The primary media type typically carried within the Multimedia
   Streaming service class is video; as such, it is RECOMMENDED to map
   this class into a Video Category.  Specifically, it is RECOMMENDED to
   map AF31 to QCI/5QI 4, thereby admitting AF31 into the GBR Non
   Conversational Video category, with a relative priority of 5/50.

   Flows marked with AF32 are expected to be of the same nature as flows
   marked with AF32, but with a lower criticality.  As such, these flows
   may not require a dedicated bearer with GBR.  Therefore, it is
   RECOMMENDED to map AF32 to QCI/5QI 6, thereby admitting AF32 traffic
   into the non-GBR category Video (Buffered Streaming) with a relative
   priority of 6/60.

   Flows marked with AF33 are expected to be of the same nature as flows
   marked with AF31 and AF32, but with the lowest criticality.  As such,
   it is RECOMMENDED to map AF33 to QCI/5QI 8, thereby admitting AF33
   traffic into the non-GBR category Video (Buffered Streaming) with a
   relative priority of 8/80.

4.2.6.  Broadcast Video

   The Broadcast Video service class is recommended for applications
   that require near-real-time packet forwarding with very low packet
   loss of constant rate and variable-rate inelastic traffic sources.
   Typically, these flows are unidirectional.  [RFC4594] Section 4.6
   recommends Broadcast Video traffic be marked CS3 DSCP.

   As directly implied by the name, the primary media type typically
   carried within the Broadcast Video service class is video; as such,



Henry, et al.           Expires October 15, 2020               [Page 23]


Internet-Draft                DIFFSERV-QCI                    April 2020


   it is RECOMMENDED to map this class into a Video Category.
   Specifically, it is RECOMMENDED to map CS3 to QCI/5QI 4, thereby
   admitting Multimedia Streaming into the GBR Non Conversational Video
   category, with a relative priority of 5/50.  In cases where GBR
   availability is constrained, using a non-GBR equivalent is also
   acceptable.  In this case, it is RECOMMENDED to map CS3 to QCI/5QI 6,
   thereby admitting Real-Time Interactive traffic into the non-GBR
   category Video with a relative priority of 6/60.

4.2.7.  Low-Latency Data

   The Low-Latency Data service class is recommended for elastic and
   time-sensitive data applications, often of a transactional nature,
   where a user is waiting for a response via the network in order to
   continue with a task at hand.  As such, these flows are considered
   foreground traffic, with delays or drops to such traffic directly
   impacting user productivity.  [RFC4594] Section 4.7 recommends Low-
   Latency Data be marked AF2x (that is, AF21, AF22, and AF23, according
   to the rules defined in [RFC2475].

   The primary media type typically carried within the Low-Latency Data
   service class is data; as such, it is RECOMMENDED to map this class
   into a data Category.  Specifically, it is RECOMMENDED to map AF21 to
   QCI/5QI 70, thereby admitting AF21 into the non-GBR Mission Critical
   Data category, with a relative priority of 5.5/55.

   Flows marked with AF22 are expected to be of the same nature as flows
   marked with AF21, but with a lower criticality.  Therefore, it is
   RECOMMENDED to map AF22 to QCI/5QI 6, thereby admitting AF22 traffic
   into the non-GBR category Video and TCP-based traffic, with a
   relative priority of 6/60.

   Flows marked with AF23 are expected to be of the same nature as flows
   marked with AF21 and AF22, but with the lowest criticality.  As such,
   it is RECOMMENDED to map AF23 to QCI/5QI 8, thereby admitting AF23
   traffic into the non-GBR category Video and TCP-based traffic, with a
   relative priority of 8/80.

   It should be noted that a consequence of such classification is that
   AF22 is mapped to the same QCI and 5QI as CS3, and AF23 is mapped to
   the same QCI and 5QI as AF33.  However, this overlap is unavoidable,
   as some QCIs and 5QIs express intents that are expressed in the
   Diffserv domain through distinct marking values, grouped in the 3GPP
   domain under the same general category.







Henry, et al.           Expires October 15, 2020               [Page 24]


Internet-Draft                DIFFSERV-QCI                    April 2020


4.2.8.  High-Throughput Data

   The High-Throughput Data service class is recommended for elastic
   applications that require timely packet forwarding of variable-rate
   traffic sources and, more specifically, is configured to provide
   efficient, yet constrained (when necessary) throughput for TCP
   longer-lived flows.  These flows are typically not user interactive.

   According to [RFC4594] Section 4.8 it can be assumed that this class
   will consume any available bandwidth and that packets traversing
   congested links may experience higher queuing delays or packet loss.
   It is also assumed that this traffic is elastic and responds
   dynamically to packet loss.  [RFC4594] Section 4.8 recommends High-
   Throughput Data be marked AF1x (that is, AF11, AF12, and AF13,
   according to the rules defined in [RFC2475].

   The primary media type typically carried within the High-Throughput
   Data service class is data; as such, it is RECOMMENDED to map this
   class into a data Category.  Specifically, it is RECOMMENDED to map
   AF11 to QCI/5QI 6, thereby admitting AF11 into the non-GBR Video and
   TCP-based traffic category, with a relative priority of 6/60.

   Flows marked with AF12 are expected to be of the same nature as flows
   marked with AF11, but with a lower criticality.  Therefore, it is
   RECOMMENDED to map AF12 to QCI/5QI 8, thereby admitting AF12 traffic
   into the non-GBR category Video and TCP-based traffic, with a
   relative priority of 8/80.

   Flows marked with AF13 are expected to be of the same nature as flows
   marked with AF11 and AF12, but with the lowest criticality.  As such,
   it is RECOMMENDED to map AF13 to QCI/5QI 9, thereby admitting AF13
   traffic into the non-GBR category Video and TCP-based traffic, with a
   relative priority of 9/90.

   It should be noted that a consequence of such classification is that
   AF11 is mapped to the same QCI as CS3 and AF22, AF12 is mapped to the
   same QCI and 5QI as Af33 and AF23, and AF13 is mapped to the same QCI
   and 5QI as CS2.  However, this overlap is unavoidable, as some QCIs
   and 5QIs express intents that are expressed in the Diffserv domain
   through distinct marking values, grouped in the 3GPP domain under the
   same general category.

4.2.9.  Standard

   The Standard service class is recommended for traffic that has not
   been classified into one of the other supported forwarding service
   classes in the Diffserv network domain.  This service class provides
   the Internet's "best-effort" forwarding behavior.  [RFC4594]



Henry, et al.           Expires October 15, 2020               [Page 25]


Internet-Draft                DIFFSERV-QCI                    April 2020


   Section 4.9 states that the "Standard service class MUST use the
   Default Forwarding (DF) PHB".

   The Standard service class loosely corresponds to the default non-GBR
   bearer practice in 3GPP.  Therefore, it is RECOMMENDED to map
   Standard service class traffic marked DF DSCP to QCI/5QI 9, thereby
   admitting it to the low priority Video and TCP-based traffic
   category, with a relative priority of 9/90.

4.2.10.  Low-Priority Data

   The Low-Priority Data service class serves applications that the user
   is willing to accept without service assurances.  This service class
   is specified in [RFC3662] and [RFC8622].  [RFC3662] and [RFC4594]
   both recommend Low-Priority Data be marked CS1 DSCP.  [RFC8622]
   updates these recommendations and suggests the LE (000001) marking.
   As such, this document aligns with this recommendation and notes that
   CS1 marking has become ambiguous.

   The Low-Priority Data service class does not have equivalent in the
   3GPP domain, where all service is controlled and allocated
   differentially.  As such, there is no clear QCI or 5QI that could be
   labelled low priority below the best effort category.  As such, it is
   RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP and LE
   DSCP to QCI/5QI 9, thereby admitting it to the low priority Video and
   TCP-based traffic category, with a relative priority of 9/90.

4.3.  Summary of Recommendations for DSCP-to-QCI Mapping

   The table below summarizes the [RFC4594] DSCP marking recommendations
   mapped to 3GPP:




















Henry, et al.           Expires October 15, 2020               [Page 26]


Internet-Draft                DIFFSERV-QCI                    April 2020


   +------+--------------------+---------------+-----------------------+
   | DSCP | Recommended        | Resource Type | Priority Level        |
   |      | QCI/5QI            |               | (QCI/5QI)             |
   +------+--------------------+---------------+-----------------------+
   | CS7  | 82                 | GBR           | 1.9 / 19              |
   |      |                    |               |                       |
   | CS6  | 82                 | GBR           | 1.9 / 19              |
   |      |                    |               |                       |
   | EF   | 1                  | GBR           | 2 / 20                |
   |      |                    |               |                       |
   | CS5  | 4                  | GBR           | 5 / 50                |
   |      |                    |               |                       |
   | AF43 | 7                  | non-GBR       | 7 / 70                |
   |      |                    |               |                       |
   | AF42 | 4                  | GBR           | 5 / 50                |
   |      |                    |               |                       |
   | AF41 | 2                  | GBR           | 4 / 40                |
   |      |                    |               |                       |
   | CS4  | 80 3               | non-BGR GBR   | 6.8 / 68, 3 / 30      |
   |      |                    |               |                       |
   | AF33 | 8                  | non-GBR       | 8 / 80                |
   |      |                    |               |                       |
   | AF32 | 6                  | non-GBR       | 6 / 60                |
   |      |                    |               |                       |
   | AF31 | 4                  | GBR           | 5 / 50                |
   |      |                    |               |                       |
   | CS3  | 85                 | GBR           | 2.1 / 21              |
   |      |                    |               |                       |
   | AF23 | 8                  | Non-GBR       | 8 / 80                |
   |      |                    |               |                       |
   | AF22 | 6                  | Non-GBR       | 6 / 60                |
   |      |                    |               |                       |
   | AF21 | 70                 | Non-GBR       | 5.5 / 55              |
   |      |                    |               |                       |
   | CS2  | 9                  | Non-GBR       | 9 / 90                |
   |      |                    |               |                       |
   | AF13 | 9                  | Non-GBR       | 9 / 90                |
   |      |                    |               |                       |
   | AF12 | 8                  | Non-GBR       | 8 / 80                |
   |      |                    |               |                       |
   | AF11 | 6                  | Non-GBR       | 6 / 60                |
   |      |                    |               |                       |
   | CS0  | 9                  | Non-GBR       | 9 / 90                |
   |      |                    |               |                       |
   | CS1  | 9                  | Non-GBR       | 6.8 / 68              |
   |      |                    |               |                       |
   | LE   | 9                  | Non-GBR       | 6.8 / 68              |
   +------+--------------------+---------------+-----------------------+



Henry, et al.           Expires October 15, 2020               [Page 27]


Internet-Draft                DIFFSERV-QCI                    April 2020


5.  QCI and 5QI to DSCP Mapping Recommendations

   Traffic travelling from the 3GPP domain toward the Internet or the
   enterprise domain may already display DSCP marking, if the UE is
   capable of marking DSCP along with, or without, upstream QCI bearer
   or 5QI marking, as detailed in Section 2.1.

   When Diffserv marking is present in the flows originating from the UE
   and transiting through the CN (Core Network), and if Diffserv marking
   are not altered or removed on the path toward the Diffserv domain,
   then the network can be considered as end-to-end Diffserv compliant.
   In this case, it is RECOMMENDED that the entity providing the
   translation from 3GPP to Diffserv ignores the QCI or 5QI value and
   simply forwards unchanged the Diffserv values expressed by the UE in
   its various flows.

   This general recommendation is not expected to fit every last
   deployment model, and as such Diffserv marking MAY be overridden by
   network administrators, as needed, before the flows are forwarded to
   the Internet, the enterprise network or the Diffserv domain in
   general.  Additionally, within a given Diffserv domain, it is
   generally NOT RECOMMENDED to pass through DSCP markings from
   unauthenticated, unidentified or unauthorized devices, as these are
   typically considered untrusted sources, as detailed in Section 7.
   Such risk is limited within the 3GPP domain where no upstream traffic
   is admitted without prior authentication of the UE.  However, this
   risk exists when UE traffic is forwarded to an enterprise domain to
   which the UE does not belong.

   In cases where the UE is unable to apply Diffserv marking, or if
   these markings are modified or removed within the 3GPP domain, such
   that these markings may not represent the intent expressed by the UE,
   and in cases where the QCI is available to represent the flow intent,
   the recommendations in this section apply.  These recommendations MAY
   apply to the boundary between the 3GPP and the Diffserv model, and
   MAY also apply to the Diffserv domain, when a given applicaiton
   traffic flows through both the 3GPP and the Diffserv domains (e.g.
   multiple paths) and when the enteprise administrator wishes to ensure
   that the same QoS intent is applied for both paths.

5.1.  QCI, 5QI and Diffserv Logic Reconciliation

   The QCIs and 5QIs are defined as relative priorities for traffic
   flows which are described by combinations of 6 or more parameters, as
   expressed in Section 2.2.  As such, QCIs and 5QIs also represent
   flows in terms of multi-dimensional needs, not just in terms of
   relative priorities.  This multi-dimensional logic is different from
   the Diffserv logic, where each traffic class is represented as a



Henry, et al.           Expires October 15, 2020               [Page 28]


Internet-Draft                DIFFSERV-QCI                    April 2020


   combination of needs relative to delay, jitter and loss.  This
   characterization around three parameters allows for the construction
   of a fairly hierarchical traffic categorization infrastructure, where
   traffic with high sensitivity to delay and jitter also typically has
   high sensitivity to loss.

   By contrast, the 3GPP QCI and 5QI structure presents multiple points
   where dimensions cross one another with different or opposing
   vectors.  For example, IMS signaling (QCI or 5QI 5) is defined with
   very high priority (1/10), low loss tolerance (10-6), but is non-GBR
   and belongs to the signaling category.  By contrast, Conversational
   voice (QCI or 5QI 1) has lower priority (2/20) than IMS signaling,
   higher loss tolerance (10-2), yet benefits from a GBR.  Fitting both
   QCIs or 5QIs 5 and 1 in a hierarchical model is challenging.

   At the same time, QCIs and 5QIs represent needs that can apply to
   different applications of various criticality but sending flows of
   the same nature.  For example, QCIs or 5QIs 6, 8 and 9 all include
   voice traffic, video traffic, but also email or FTP.  What
   distinguish these QCIs/5QIs is the criticality of the associated
   traffic.  Diffserv does not envisions voice and FTP as possibly
   belonging to the same class.  As the same time, QCIs or 5QIs 2 and 9
   include real-time voice traffic.  Diffserv does not allow a type of
   traffic with stated sensitivity to loss, delay and jitter to be split
   into categories at both end of the priority spectrum.

   As such, it is not expected that QCIs and 5QIs can be mapped to the
   Diffserv model strictly and hierarchically.  Instead, a better
   approach is to observe the various QCI and 5QI categories, and
   analyze their intent.  This process allows for the grouping of
   several QCIs or 5QIs into hierarchical groups, that can then be
   translated into ensembles coherent with the Diffserv logic.  This
   approach, in turn, allows for incorporation of new QCIs and 5QIs as
   the 3GPP model continues to evolve.

   It should be noted, however, that such approach results in partial
   incompatibility.  Some QCIs or 5QIs represent an intent that is
   simply not present in the Diffserv model.  In that case, attempting
   to artificially stitch the QCI/5QI to an existing Diffserv traffic
   class and marking would be dangerous.  QCI or 5QI traffic forwarded
   to the Diffserv domain would be mixed with Diffserv traffic that
   would represent a very different intent.

   As such, the result of this classification is that some QCIs and 5QIs
   call for new Diffserv traffic classes and markings.  This consequence
   is preferable to mixing traffic of different natures into the same
   pre-existing category.




Henry, et al.           Expires October 15, 2020               [Page 29]


Internet-Draft                DIFFSERV-QCI                    April 2020


   Each QCI is represented with 6 parameters and each 5QI with 7
   parameters, including an Example Services value.  This parameter is
   representative of the QCI or 5QI intent.  Although [TS 23.203] and
   [TS 23.501] summarize each QCI or 5QI intent, these standards contain
   only summaries of more complex classifications expressed in other
   3GPP standards.  It is often necessary to refer to these other
   standards to obtain a more complete description of each QCI/5QI and
   the multiple type of flows that each QCI or 5QI represents.

   For the purpose of this document, the QCI or 5QI intent is the
   primary classification driver, along with the priority level.  The
   secondary elements, such as priority, delay budget and loss tolerance
   allow for better refinement of the relative classifications of the
   QCIs and 5QIs.  The resource types (GBR, DElay-critical GBR, non-GBR)
   provide additional visibility into the intent.

   Although 26 QCIs are listed in [TS 23.203] and 27 5QIs in [TS
   23.501], representing two (GBR, non-GBR) or three resource types
   (GBR, non-GBR, Delay-Critical GBR) respectively, 21 and 22 priority
   values, 9 delay budget values, and 7 loss tolerance values, examining
   the intent in fact surfaces 9 traffic families:

   1.   Voice QCI/5QI [1] (dialer / conversational voice) is its own
        group

   2.   Voice signaling [5] (IMS) is its own group

   3.   Voice related (other voice applications, including PTT) [65, 66,
        69]

   4.   Video (conversational or not, mission critical or not) [67, 2,
        4, 71, 72, 73, 74, 76]

   5.   Live streaming / interactive gaming is its own group [7]

   6.   Low latency eMBB, AR/VR is its own group [80]

   7.   V2X messaging [75, 3, 9]

   8.   Automation and Transport [82, 83, 84, 85, 86]

   9.   Non-mission-critical data [6, 8, 9]

   10.  Mission-critical data is its own group [70]







Henry, et al.           Expires October 15, 2020               [Page 30]


Internet-Draft                DIFFSERV-QCI                    April 2020


5.2.  Voice [1]

   Several QCIs or 5QIs are intended to carry voice traffic.  However,
   QCI/5QI 1 stands apart from the others.  Its category is
   Conversational Voice, but this QCI/5QI is intended to represent the
   VoLTE voice bearer, for dialer and emergency services.  QCI/5QI 1
   uses a GBR, and has a priority level of 2/20.  Its packet delay
   budget is 100 ms (from UE to P-GW) with a packet error loss of at
   most 10.E-2.  As the GBR is allocated by the infrastructure, QCI/5QI
   1 is both admitted and allocated dedicated resources.  As such,
   QCI/5QI 1 maps in intent and function to [RFC5865], Admitted Voice,
   and is RECOMMENDED for mapping to DSCP 44.

5.3.  IMS Signaling [5]

   QCI/5QI 5 is intended for Signaling.  This category does not
   represent signaling for VoLTE, as such signaling is not conducted
   over the UE data channels.  Instead, QCI/5QI 5 is intended for IMS
   services.  IP Multimedia System (IMS) is a framework for delivering
   multimedia services over IP networks.  These services include real-
   time and video applications, and their signaling is recommended to be
   carried, whenever possible, using IETF protocols such as SIP.  Being
   of signaling nature, QCI/5QI 5 is non-GBR.  However, being critical
   to enabling IMS real-time applications, QCI/5QI 5 has a high priority
   of 1/10.  Its packet delay budget is 100 ms, but packet error loss
   rate very low, at less than 10.E-6.  Overall, QCI/5QI 5 maps rather
   well to the intent of [RFC4594] signaling for real time applications,
   and as such is RECOMMENDED to map to [RFC4594] Signaling, CS5.

5.4.  Voice-related QCIs and 5QIs [65, 66, 69]

   Several QCIs/5QIs display the commonality of targeting voice (non-
   VoLTE) traffic:

   o  QCI/5QI 65 is GBR, mission critical PTT voice, priority 0.7/7

   o  QCI/5QI 66 is GBR, non-mission critical PTT voice, priority 2/20

   o  QCI/5QI 69 is non-GBR, mission-critical PTT signaling, priority
      0.5/5

   These QCIs/5QIs are Voice in nature, and naturally fit into a
   proximity marking model with DSCP 46 and 44.

   Additionally, lower priority marks higher precedence intent in QCI
   and 5QI.  However, there is no model in [RFC4594] that distinguishes
   3 classes of voice traffic.  Therefore, new markings are unavoidable.
   As such, there is a need to group these markings in the Voice



Henry, et al.           Expires October 15, 2020               [Page 31]


Internet-Draft                DIFFSERV-QCI                    April 2020


   category (101 xxx), and to order 69, 65 and 66 with different
   markings to reflect their different priority levels.

   Among these three QCIs/5QIs, 69 is non-GBR, intended for mission-
   critical PTT signaling, with the highest priority of the three, at
   0.5/5. 69 is intended for signaling, but is latency sensitive, with a
   low 60 ms delay budget and a low 10.E-6 loss tolerance.  Being of
   Signaling nature for real time applications, QCI/5QI 69 has proximity
   of intent with CS5 (Voice signaling, 40), but this marking is already
   used by QCI/5QI 5.  Therefore, it is RECOMMENDED to map QCI/5QI 69 to
   a new DSCP marking, 41.

   Similarly, QCI/5QI 66 is GBR and targeted for non-mission critical
   PTT voice, with a priority level of 2/20. 66 is Voice in nature, and
   GBR.  However, 66 is intended for non-mission-critical traffic, and
   has a lower priority than mission-critical Voice, a higher tolerance
   for delay (100 ms vs 75).  As such, 66 cannot fit within [RFC4594]
   model mapping real-time voice to the class EF (DSCP 46).  Here again,
   a new marking is needed.  As such, this QCI/5QI fits in intent and
   proximity closest to Admitted Voice, but is non-GBR, and therefore
   non-admitted, guiding a new suggested DSCp marking of 43.

   Then, QCI/5QI 65 is GBR, intended for mission critical PTT voice,
   with a relative low priority index of 0.7/7.  QCI/5QI 65 receives GBR
   and is intended for mission critical traffic.  Its priority is higher
   (0.7 vs 2) than QCI/5QI 66, but a lower priority (0.7/7 vs 0.5/5)
   than QCI/5QI 69.  Additionally, 65 cannot be represented by DSCP 44
   (used by QCI/5QI 1), or DSCP 46 (used by non-GBR voice).  As such,
   QCI/5QI 65 fits between QCIs/5QIs 69 66, with a new suggested DSCP
   marking of 42.

5.5.  Video QCIs and 5QIs [67, 2, 4, 71, 72, 73, 74, 76]

   Although six different QCIs and 5QIs have example services that
   include some form of video traffic, eight QCIs and 5QIs are video in
   nature, 67, 2, 4, 71, 72, 73, 74, and 76.

   All eight QCIs/5QIs represent video streams and fit naturally in the
   AF4x category.  However, these QCIs/5QIs do not match [RFC4594]
   intent for multimedia conferencing, in that they are all admitted
   (being associated to a GBR).  They also do not match the category
   described by [RFC5865] for capacity-admitted traffic.  Therefore,
   there is not a clear possible mapping for any of these QCIs and 5QIs
   to an existing AF4x category.  In order to avoid mixing admitted and
   non-admitted video in the same class, it is necessary to associate
   these QCIs/5QIs to new Diffserv classes.





Henry, et al.           Expires October 15, 2020               [Page 32]


Internet-Draft                DIFFSERV-QCI                    April 2020


   In particular, QCI/5QI 67 is GBR, intended for mission-critical video
   user plane.  This QCI/5QI is video in nature, and matches traffic
   that is rate-adaptive, and real time. 67 priority is high (1.5/15),
   with a tolerant delay budget (100ms) and rather low loss tolerance
   (10.E-3). 67 is GBR.

   As such, it is RECOMMENDED to map QCI/5QI 67 against the DSCP value
   closest to AF4x video with lowest discard eligibility (AF41), namely
   DSCP 33.

   Similarly, QCI/5QI 2 is intended for conversational video (live
   streaming). 2 is also video in nature and associated to a GBR,
   however its priority is lower than 67 (4/40 vs 1.5/15).
   Additionally, its delay budget is also larger (150 ms vs 100 ms).
   Its packet error loss is also 10.E-3.  As such, 2 fits well within a
   video queue, with a larger drop probability than 67.  Therefore, it
   is RECOMMENDED to map QCI/5QI 2 to the video category with a Diffserv
   marking of 35.

   QCIs/5QIs 71, 72, 73, 74 and 76 are intended for "Live" Uplink
   Streaming (LUS) services, where an end-user with a radio connection
   (for example a reporter or a drone) streams live video feed into the
   network or to a second party ([TS 26.939]).  This traffic is GBR.
   However, [TS 26.939] defines LUS and also differentiates GBR from MBR
   and TBR.  At the time of the admission, the infrastructure can offer
   a Guaranteed Bit Rate, which should match the bare minimum rate
   expected by the application (and its codec).  Because of the
   burstiness nature of video, the Maximum Bit Rate (MBR) available to
   the trannsmission should be much higher than the GBR.  In fact, the
   Target Bit Rate (TBR), which is the prefered service operation point
   for that application, is likely close to the MBR.  Thus, the
   application will receive a treatment between the GBR and the TBR.
   This allocated bit rate will directly translate in video quality
   changes, where an available bit rate close to the GBR will result in
   a lower Mean Opinion Score than a bit rate close to the TBR.  As the
   application detects the contraints on the available bit rate, it may
   adapt by changing its codec and compression scheme accordingly.
   Flows with higher compression will have higher delay tolerance and
   budget (as a single packet burst represents a larger segment of the
   video flow) but lower loss tolerance (as each lost packet represents
   a larger segment of the video flow).  As such, 71, 72, 73, 74 and 76
   express intents similar to QCI/5QI 2, with additional constraints on
   the directionality of the flow (upstream only) and the bit rate
   applied by the infrastructure.  These constraints are orthogonal to
   the intent of the flow.  As such, it is RECOMMENDED to map QCIs/5QIs
   71, 72, 73, 74 and 76 to the same DSCP value as QCI/5QI 2, and thus
   to the video category with a Diffserv marking of 35.




Henry, et al.           Expires October 15, 2020               [Page 33]


Internet-Draft                DIFFSERV-QCI                    April 2020


   QCI/5QI 4 is intended for non-conversational video (buffered
   streaming), with a priority of 5/50. 4 is also video in nature.
   Although it is buffered, it is admitted, being associated to a GBR.
   QCI/5QI 4 as a lower priority than QCIs/5QIs 67 and 2, and a larger
   delay budget (300 ms vs 150/100).  However, its packet loss tolerance
   is low (10.E-6).  This combination makes it eligible for a video
   category, but with a higher drop probability than 67 and 2.
   Therefore, it is RECOMMENDED to map QCI/5QI 4 to DSCP 37.

5.6.  Live streaming and interactive gaming [7]

   QCI/5QI 7 is non-GBR and intended for live streaming voice or video
   interactive gaming.  Its priority is 7/70.  It is the only QCI/5QI
   targeting this particular traffic mix.  In the Diffserv model, voice
   and video are different categories, and are also different from
   interactive gaming (real time interactive).  In the 3GPP model, live
   streaming video and mission-critical video are defined in other
   queues with high priority (e.g.  QCI or 5QI 2 for video Live
   streaming, with a priority of 2/20, or QCI/5QI 67 for mission-
   critical video, with a priority of 1.5/15).  By comparison, QCI/5QI 7
   priority is relatively low (7/70), with a 100 ms budget delay and a
   comparatively rather high loss tolerance (10.E-3).

   As such, 7 fits well with bursty (e.g. video) and possibly rate
   adaptive flows, with possible drop probability.  It is also non-
   admitted (non-GBR), and as such, fits close to [RFC4594] intent for
   multimedia conferencing, with high discard eligibility.  Therefore,
   it is RECOMMENDED to map QCI/5QI 7 to the existing Diffserv category
   AF43.

5.7.  Low latency eMBB and AR/VR [80]

   QCI/5QI 80 is intended for low latency eMBB (enhanced Mobile
   Broadband) applications, such as Augmented Reality of Virtual Reality
   (AR/VR). 80 priority is 6.8/68, with a low packet delay budget of 10
   ms, and a packet error loss rate of at most 10.E-6. 80 is non-GBR,
   yet intended for real time applications.  Traffic in the AR/VR
   category typically does not react dynamically to losses, requires
   bandwidth and a low and predictable delay.

   As such, QCI/5QI 80 matches closely the specifications for CS4.
   Therefore, it is RECOMMENDED to map QCI/5QI 80 to the existing
   category CS4.








Henry, et al.           Expires October 15, 2020               [Page 34]


Internet-Draft                DIFFSERV-QCI                    April 2020


5.8.  V2X messaging [75,3,9]

   Three QCIs/5QIs are intended specifically to carry Vehicle to
   Anything (V2X) traffic, 75, 3, and 79.  All 3 QCIs/5QIs are data in
   nature, and fit naturally into the AF2x category.  However, two of
   these (75 and 3) are admitted (GBR), and therefore do not fit in the
   current Diffserv model. 79 is non-admitted, but matches none of the
   AF2X categories in [RFC4594].

   In particular, QCI/5QI 75 is GBR, with a rather high priority
   (2.5/25), a low delay budget (50 ms), but tolerance to losses (10E-
   2).  Being low latency data in nature, 75 fits well in the AF2X
   category.  However, being admitted, it fits none of the existing
   markings.  Being the highest traffic (in priority) in this low
   latency data family, 75 is recommended to be mapped to a new
   category, as close as possible to the AF2X class, and with a low drop
   probability.  As such, it is RECOMMENDED to map QCI/5QI 75 to DSCP
   17.

   Similarly, QCI/5QI 3 is intended for V2X messages, but can also be
   used for Real time gaming, or Utility traffic (medium voltage
   distribution) or process automation monitoring.  QCI/5QI 3 priority
   is 3/30. 3 is data in nature, but GBR.  Its delay budget is low (50
   ms), but with some tolerance to loss (10E-3).

   QCI/5QI 3 is of the same type as QCI/5QI 75, but with a lower
   priority.  Therefore, 3 should be mapped to a category close to the
   category to which 75 is mapped, but with a higher drop probability.
   As such, it is RECOMMENDED to map QCI/5QI 3 to DSCP 19.

   Additionally, QCI/5QI 79 is also intended for V2X messages. 79 is
   similar in nature to 75 and 3, but is non-critical (non-GBR).  Its
   priority is also lower (6.5/65).  Its budget delay is similar to that
   of 75 and 3 (50 ms), and its packet error loss rate is similar to
   that of 75 (10.E-2).

   79 partially matches AF2X, but is not elastic, and therefore cannot
   fit exactly in [RFC4594] model.  As such, it is recommended to a
   mapping similar to QCI/5QIs 75 and 3, with a higher drop probability.
   Therefore, it is RECOMMENDED to map QCI/5QI 79 to DSCP 21.

5.9.  Automation and Transport [82, 83, 84, 85, 86]

   QCI/5QI 84 is intended for intelligent transport systems.  As such,
   its intent is close to the V2X messaging category.  QCI 84 is also
   admitted (GBR in [TS 23.203] and Delay-Critical GBR in [TS 23.501]).
   However, 84 is intended for traffic with a smaller packet delay
   budget (30 ms vs 50 ms for QCI/5QI 75) and a smaller packet error



Henry, et al.           Expires October 15, 2020               [Page 35]


Internet-Draft                DIFFSERV-QCI                    April 2020


   loss maximum rate (10.E-6 vs 10.E-2 for QCI/5QI 75).  As such, 84
   should be mapped against a category above that of 75 or 3.  Being
   admitted, 84 does not map easily into an existing category.  As such,
   it is RECOMMENDED to map QCI/5QI 84 to DSCP category 31.

   5QI 86 is also intended for intelligent transport systems, and fits
   in the same general category as 84. 86 is also admitted (Delay-
   Critical GBR), with a higher priority (18) than 84 but similar burst
   rate (1354 bytes). 5QI 86 therefore fits into a category close to
   that of 84.  As such, it is RECOMMENDED to map 5QI 86 to DSCP
   captegory 29.

   QCI/5QI 85 is intended for electricity distribution (high voltage)
   communication.  As such, it is close in intent to QCI/5QI 3. 85 is
   also GBR.  However, 85 priority is lower than that of QCI/5QI 3
   (2.1/21 vs 3/30). 85 has also a very low packet delay budget (5 ms vs
   50 ms for QCI/5QI 3) and low packet error loss rate (10.E-6 vs 10.E-3
   for QCI/5QI 3).  As such, 84 should be mapped to a category higher
   than that of QCI/5QI 3,with a very low drop probability.  As such, it
   is RECOMMENDED to map QCI/5QI 85 to DSCP category 23.

   QCIs/5QIs 82 and 83 are both intended for discrete automation control
   traffic. 82 represents traffic with a higher priority (1.9/19) than
   traffic matched to 83 (priority 2.2/22). 82 also expects smaller data
   bursts (255 bytes) than 83 (1358 bytes).  However, both QCIs are
   admitted (GBR), with the same low packet delay budget (10 ms) and
   packet error loss maximum rate (10.E-4).

   As such, 82 and 83 fit in the same general category, with a higher
   drop probability assigned to 83.  They also fit the general intent
   category of automation traffic types, with a priority higher than
   that of other M2M traffic types (e.g.  V2X messages).  As such, they
   fit well into the AF3X category.  However, being both admitted (GBR),
   they do not easily map to any existing AF3X category, and require new
   categories.

   As such, it is RECOMMENDED to map QCI/5QI 82 to DSCP category 25.
   Similarly, it is RECOMMENDED to map QCI/5QI 83 to DSCP category 79.

5.10.  Non-mission-critical data [6,8,9]

   QCIs/5QIs 6, 8 and 8 are intended for non-GBR, Video or TCP data
   traffic.  All 3 QCIs/5QIs are data in nature, non-mission critical,
   relative low priority and therefore fit naturally into the AF1x
   category.  The inclusion in these QCIs/5QIs' intent of buffered video
   is an imperfect fit for AF1X.  However, the intent of these QCIs/5QIs
   is to match buffered, and non-mission critical traffic.  As such,
   they match the intent of AF1X, even if the Diffserv model would not



Henry, et al.           Expires October 15, 2020               [Page 36]


Internet-Draft                DIFFSERV-QCI                    April 2020


   associate buffered video to non-mission critical, buffered and low
   priority traffic.

   The intent of all three QCIs/5QIs is similar.  The difference lies in
   their priority and criticality.

   QCI/5QI 6 has priority 6/60, a packet delay budget of 300 ms, and a
   packet error loss rate of at most 10.E-6.  QCI/5QI 8 has a priority
   8/80, a packet delay budget of 300 ms, and a packet error loss rate
   of at most 10.E-6.  QCI/5QI 9 has priority 9/90, and also a packet
   delay budget of 300 ms and a packet error loss rate of at most
   10.E-6.  As these three QCIs/5QIs represent the same intent and are
   only different in their priority level, using discard eligibility to
   differentiate them is logical.  As such, it is RECOMMENDED to map
   QCI/5QI 6 to category AF11.  Similarly, it is RECOMMENDED to map
   QCI/5QI 8 to AF12.  And logically, it is RECOMMENDED to map QCI/5QI 9
   to AF13.

5.11.  Mission-critical data [70]

   QCI/5QI 70 is non-GBR, intended for mission critical data, with a
   priority of 5.5/55, a packet delay budget of 200 ms and a packet
   error loss rate tolerance of at most 10.E-6.  The traffic types
   intended for 70 are the same as for QCIs/5QIs 6,8,9 categories,
   namely buffered streaming video and TCP-based traffic, such as www,
   email, chat, FTP, P2P and other file sharing applications.  However,
   70 is specifically intended for applications that are mission
   critical.  For this reason, 70 priority is higher than 6, 8 or 9
   priorities (5.5/55 vs 6/60, 8/80 and 9/90 respectively).  Therefore,
   70 fits well in the AF2x family, while 6,8,9 are in AF1x.  As 70
   displays intermediate differentiated treatment, if also fits well
   with an intermediate discard eligibility.  As such, it is RECOMMENDED
   to map QCI/5QI 70 to DSCP 20 (AF22).

5.12.  Summary of Recommendations for QCI or 5QI to DSCP Mapping

   The table below summarizes the 3GPP QCI and 5QI to [RFC4594] DSCP
   marking recommendations:

   +--------+----------+----------+----------------------+-------------+
   | QCI/5Q | Resource | Priority | Example Services     | Recommended |
   | I      | Type     | Level    |                      | DSCP (PHB)  |
   +--------+----------+----------+----------------------+-------------+
   | 1      | GBR      | 2        | Conversational Voice | 44 (VA)     |
   |        |          |          |                      |             |
   | 2      | GBR      | 4        | Conversational Video | 35 (N.A.)   |
   |        |          |          | (Live Streaming)     |             |
   |        |          |          |                      |             |



Henry, et al.           Expires October 15, 2020               [Page 37]


Internet-Draft                DIFFSERV-QCI                    April 2020


   | 3      | GBR      | 3        | Real Time Gaming,    | 19 (N.A.)   |
   |        |          |          | V2X messages,        |             |
   |        |          |          | Electricity          |             |
   |        |          |          | distribution (medium |             |
   |        |          |          | voltage) Process     |             |
   |        |          |          | automation           |             |
   |        |          |          | (monitoring)         |             |
   |        |          |          |                      |             |
   | 4      | GBR      | 5        | Non-Conversational   | 37 (N.A.)   |
   |        |          |          | Video  (Buffered     |             |
   |        |          |          | Streaming)           |             |
   |        |          |          |                      |             |
   | 65     | GBR      | 0.7      | Mission Critical     | 42 (N.A.)   |
   |        |          |          | user plane  Push To  |             |
   |        |          |          | Talk voice  (e.g.,   |             |
   |        |          |          | MCPTT)               |             |
   |        |          |          |                      |             |
   | 66     | GBR      | 2        | Non-Mission-Critical | 43 (N.A.)   |
   |        |          |          | user plane Push To   |             |
   |        |          |          | Talk voice           |             |
   |        |          |          |                      |             |
   | 67     | GBR      | 1.5      | Mission Critical     | 33 (N.A.)   |
   |        |          |          | Video  user plane    |             |
   |        |          |          |                      |             |
   | 75     | GBR      | 2.5      | V2X messages         | 17 (N.A.)   |
   |        |          |          |                      |             |
   | 71     | GBR      | 5.6      | Live uplink          | 35 (N.A.)   |
   |        |          |          | streaming            |             |
   |        |          |          |                      |             |
   | 72     | GBR      | 5.6      | Live uplink          | 35 (N.A.)   |
   |        |          |          | streaming            |             |
   |        |          |          |                      |             |
   | 73     | GBR      | 5.6      | Live uplink          | 35 (N.A.)   |
   |        |          |          | streaming            |             |
   |        |          |          |                      |             |
   | 74     | GBR      | 5.6      | Live uplink          | 35 (N.A.)   |
   |        |          |          | streaming            |             |
   |        |          |          |                      |             |
   | 76     | GBR      | 5.6      | Live uplink          | 35 (N.A.)   |
   |        |          |          | streaming            |             |
   |        |          |          |                      |             |
   | 82     | GBR      | 1.9      | Discrete automation  | 25 (N.A.)   |
   |        |          |          | (small packets)      |             |
   |        |          |          |                      |             |
   | 83     | GBR      | 2.2      | Discrete automation  | 27 (N.A.)   |
   |        |          |          | (large packets)      |             |
   |        |          |          |                      |             |
   | 84     | GBR      | 2.4      | Intelligent          | 31 (N.A.)   |



Henry, et al.           Expires October 15, 2020               [Page 38]


Internet-Draft                DIFFSERV-QCI                    April 2020


   |        |          |          | Transport Systems    |             |
   |        |          |          |                      |             |
   | 85     | GBR      | 2.1      | Electricity          | 23 (N.A.)   |
   |        |          |          | Distribution -  High |             |
   |        |          |          | Voltage              |             |
   |        |          |          |                      |             |
   | 86     | GBR      | 1.8      | Intelligent          | 29 (N.A.)   |
   |        |          |          | Transport Systems    |             |
   |        |          |          |                      |             |
   | 5      | Non-GBR  | 1        | IMS Signalling       | 40 (CS5)    |
   |        |          |          |                      |             |
   | 6      | Non-GBR  | 6        | Video (Buffered      | 10 (AF11)   |
   |        |          |          | Streaming) TCP-based |             |
   |        |          |          | (e.g. www, email,    |             |
   |        |          |          | chat, ftp, p2p file  |             |
   |        |          |          | sharing, progressive |             |
   |        |          |          | video)               |             |
   |        |          |          |                      |             |
   | 7      | Non-GBR  | 7        | Voice, Video (live   | 38 (AF43)   |
   |        |          |          | streaming),          |             |
   |        |          |          | interactive gaming   |             |
   |        |          |          |                      |             |
   | 8      | Non-GBR  | 8        | Video (buffered      | 12 (AF12)   |
   |        |          |          | streaming) TCP-based |             |
   |        |          |          | (e.g. www, email,    |             |
   |        |          |          | chat, ftp, p2p file  |             |
   |        |          |          | sharing, progressive |             |
   |        |          |          | video)               |             |
   |        |          |          |                      |             |
   | 9      | Non-GBR  | 9        | Same as 8            | 14 (AF13)   |
   |        |          |          |                      |             |
   | 69     | Non-GBR  | 0.5      | Mission Critical     | 41 (N.A.)   |
   |        |          |          | delay  sensitive     |             |
   |        |          |          | signalling  (e.g.,   |             |
   |        |          |          | MC-PTT signalling,   |             |
   |        |          |          | MC Video signalling) |             |
   |        |          |          |                      |             |
   | 70     | Non-GBR  | 5.5      | Mission Critical     | 20 (AF22)   |
   |        |          |          | Data  (e.g. example  |             |
   |        |          |          | services  are the    |             |
   |        |          |          | same as QCI 6/8/9)   |             |
   |        |          |          |                      |             |
   | 79     | Non-GBR  | 6.5      | V2X messages         | 21 (N.A.)   |
   |        |          |          |                      |             |
   | 80     | Non-GBR  | 6.8      | Low latency eMMB     | 32 (CS4)    |
   |        |          |          | applications         |             |
   |        |          |          | (TCP/UDP-based);     |             |
   |        |          |          | augmented reality    |             |



Henry, et al.           Expires October 15, 2020               [Page 39]


Internet-Draft                DIFFSERV-QCI                    April 2020


   +--------+----------+----------+----------------------+-------------+

6.  IANA Considerations

   This document has no IANA actions.  Although this document suggests
   the use of codepoints in the Pool 1 of the codespace defined in
   [RFC2474], no exclusive attribution is requested.  The recommended
   utilisation of seven codepoints in Pool 2 and six codepoints in pool
   3 is also intended as a recommendation for experimental or Local Use,
   as defined in [RFC2474].

7.  Specific Security Considerations

   The recommendations in this document concern widely deployed wired
   and wireless network functionality, and, for that reason, do not
   present additional security concerns that do not already exist in
   these networks.

8.  Security Recommendations for General QoS

   It may be possible for a wired or wireless device (which could be
   either a host or a network device) to mark packets (or map packet
   markings) in a manner that interferes with or degrades existing QoS
   policies.  Such marking or mapping may be done intentionally or
   unintentionally by developers and/or users and/or administrators of
   such devices.

   To illustrate: A gaming application designed to run on a smartphone
   may request that all its packets be marked DSCP EF.  Although the
   3GPP infrastructure may only allocate a non-GBR default QCI (e.g.
   QCI 9) for this traffic, the translation point into the Internet
   domain may consider the DSCP marking instead of the allocated QCI,
   and forward this traffic with a marking of EF.  This traffic may then
   interfere with QoS policies intended to provide priority services for
   business voice applications.

   To mitigate such scenarios, it is RECOMMENDED to implement general
   QoS security measures, including:

   o  Setting a traffic conditioning policy reflective of business
      objectives and policy, such that traffic from authorized users
      and/or applications and/or endpoints will be accepted by the
      network; otherwise, packet markings will be "bleached" (i.e., re-
      marked to DSCP DF).  Additionally, Section 5 made it clear that it
      is generally NOT RECOMMENDED to pass through DSCP markings from
      unauthorized, unidentified and/or unauthenticated devices, as
      these are typically considered untrusted sources.  This is
      especially relevant for Internet of Things (IoT) deployments,



Henry, et al.           Expires October 15, 2020               [Page 40]


Internet-Draft                DIFFSERV-QCI                    April 2020


      where tens of billions of devices with little or no security
      capabilities are being connected to LTE and IP networks, leaving
      them vulnerable to be utilized as agents for DDoS attacks.  These
      attacks can be amplified with preferential QoS treatments, should
      the packet markings of such devices be trusted.

   o  Policing EF marked packet flows, as detailed in [RFC2474]
      Section 7 and [RFC3246] Section 3.

   Finally, it should be noted that the recommendations put forward in
   this document are not intended to address all attack vectors
   leveraging QoS marking abuse.  Mechanisms that may further help
   mitigate security risks of both wired and wireless networks deploying
   QoS include strong device- and/or user-authentication, access-
   control, rate-limiting, control-plane policing, encryption, and other
   techniques; however, the implementation recommendations for such
   mechanisms are beyond the scope of this document to address in
   detail.  Suffice it to say that the security of the devices and
   networks implementing QoS, including QoS mapping between wired and
   wireless networks, merits consideration in actual deployments.

9.  References

9.1.  Normative References

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              DOI 10.17487/RFC2474, December 1998,
              <https://www.rfc-editor.org/info/rfc2474>.

   [RFC2597]  Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
              "Assured Forwarding PHB Group", RFC 2597,
              DOI 10.17487/RFC2597, June 1999,
              <https://www.rfc-editor.org/info/rfc2597>.

   [RFC3246]  Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
              J., Courtney, W., Davari, S., Firoiu, V., and D.
              Stiliadis, "An Expedited Forwarding PHB (Per-Hop
              Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
              <https://www.rfc-editor.org/info/rfc3246>.

   [RFC5865]  Baker, F., Polk, J., and M. Dolly, "A Differentiated
              Services Code Point (DSCP) for Capacity-Admitted Traffic",
              RFC 5865, DOI 10.17487/RFC5865, May 2010,
              <https://www.rfc-editor.org/info/rfc5865>.





Henry, et al.           Expires October 15, 2020               [Page 41]


Internet-Draft                DIFFSERV-QCI                    April 2020


9.2.  Informative References

   [ir.34]    3gpp, "guidelines for ipx provider networks - gsma",
              August 2018, <https://www.gsma.com/newsroom/wp-content/
              uploads//ir.34-v14.0-3.pdf>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
              <https://www.rfc-editor.org/info/rfc2475>.

   [RFC3662]  Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
              Per-Domain Behavior (PDB) for Differentiated Services",
              RFC 3662, DOI 10.17487/RFC3662, December 2003,
              <https://www.rfc-editor.org/info/rfc3662>.

   [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
              Guidelines for DiffServ Service Classes", RFC 4594,
              DOI 10.17487/RFC4594, August 2006,
              <https://www.rfc-editor.org/info/rfc4594>.

   [RFC5127]  Chan, K., Babiarz, J., and F. Baker, "Aggregation of
              Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127,
              February 2008, <https://www.rfc-editor.org/info/rfc5127>.

   [RFC8100]  Geib, R., Ed. and D. Black, "Diffserv-Interconnection
              Classes and Practice", RFC 8100, DOI 10.17487/RFC8100,
              March 2017, <https://www.rfc-editor.org/info/rfc8100>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8622]  Bless, R., "A Lower-Effort Per-Hop Behavior (LE PHB) for
              Differentiated Services", RFC 8622, DOI 10.17487/RFC8622,
              June 2019, <https://www.rfc-editor.org/info/rfc8622>.

   [TS23.107]
              3gpp, "quality of service (qos) concept and architecture
              v15.0", June 2018, <www.3gpp.org/dynareport/23107.htm>.






Henry, et al.           Expires October 15, 2020               [Page 42]


Internet-Draft                DIFFSERV-QCI                    April 2020


   [TS23.203]
              3gpp, "policy and charging control architecture v16.0",
              December 2019, <www.3gpp.org/dynareport/23203.htm>.

   [TS23.207]
              3gpp, "end-to-end quality of service (qos) concept and
              architecture v15.0", June 2018, <www.3gpp.org/
              dynareport/23207.htm>.

   [TS23.501]
              3gpp, "system architecture for the 5G System (5GS) v15.0",
              December 2019, <www.3gpp.org/dynareport/23501.htm>.

   [TS26.939]
              3gpp, "guidelines on the framework for live uplink
              streaming (FLUS) v15.0", September 2019, <www.3gpp.org/
              dynareport/26939.htm>.

Authors' Addresses

   Jerome Henry
   Cisco

   Email: jerhenry@cisco.com


   Tim Szigeti
   Cisco

   Email: szigeti@cisco.com


   Luis Miguel Contreras Murillo
   Telefonica

   Email: luismiguel.contrerasmurillo@telefonica.com















Henry, et al.           Expires October 15, 2020               [Page 43]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/