Skip to main content

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

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Jerome Henry , Tim Szigeti
Last updated 2019-10-14 (Latest revision 2019-04-15)
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-henry-tsvwg-diffserv-to-qci-02
Network Working Group                                           J. Henry
Internet-Draft                                                T. Szigeti
Intended status: Informational                                     Cisco
Expires: April 14, 2020                                 October 12, 2019

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

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) 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
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Henry & Szigeti          Expires April 14, 2020                 [Page 1]
Internet-Draft                DIFFSERV-QCI                  October 2019

   This Internet-Draft will expire on April 14, 2020.

Copyright Notice

   Copyright (c) 2019 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 . . . . . . . . . . . . . . . . .   4
     1.3.  Document Organization . . . . . . . . . . . . . . . . . .   5
     1.4.  Requirements language . . . . . . . . . . . . . . . . . .   5
     1.5.  Terminology Used in this Document . . . . . . . . . . . .   5
   2.  Service Comparison and Default Interoperation of Diffserv and
       3GPP LTE  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     2.1.  Diffserv Domain Boundaries  . . . . . . . . . . . . . . .   7
     2.2.  QCI and Bearer Model in 3GPP  . . . . . . . . . . . . . .   7
     2.3.  QCI Definition and Logic  . . . . . . . . . . . . . . . .   9
       2.3.1.  Conversational  . . . . . . . . . . . . . . . . . . .   9
       2.3.2.  Streaming . . . . . . . . . . . . . . . . . . . . . .   9
       2.3.3.  Interactive . . . . . . . . . . . . . . . . . . . . .  10
       2.3.4.  Background  . . . . . . . . . . . . . . . . . . . . .  10
     2.4.  QCI implementations . . . . . . . . . . . . . . . . . . .  13
     2.5.  GSMA IPX Guidelines Interpretation and Conflicts  . . . .  13
   3.  P-GW Device Marking and Mapping Capability Recommendations  .  14
   4.  DSCP-to-QCI Mapping Recommendations . . . . . . . . . . . . .  15
     4.1.  Control Traffic . . . . . . . . . . . . . . . . . . . . .  15
       4.1.1.  Network Control Protocols . . . . . . . . . . . . . .  15
       4.1.2.  Operations, Administration, and Maintenance (OAM) . .  16
     4.2.  User Traffic  . . . . . . . . . . . . . . . . . . . . . .  16
       4.2.1.  Telephony . . . . . . . . . . . . . . . . . . . . . .  16
       4.2.2.  Signaling . . . . . . . . . . . . . . . . . . . . . .  17
       4.2.3.  Multimedia Conferencing . . . . . . . . . . . . . . .  17
       4.2.4.  Real-Time Interactive . . . . . . . . . . . . . . . .  18
       4.2.5.  Multimedia Streaming  . . . . . . . . . . . . . . . .  18
       4.2.6.  Broadcast Video . . . . . . . . . . . . . . . . . . .  19

Henry & Szigeti          Expires April 14, 2020                 [Page 2]
Internet-Draft                DIFFSERV-QCI                  October 2019

       4.2.7.  Low-Latency Data  . . . . . . . . . . . . . . . . . .  19
       4.2.8.  High-Throughput Data  . . . . . . . . . . . . . . . .  20
       4.2.9.  Standard  . . . . . . . . . . . . . . . . . . . . . .  21
       4.2.10. Low-Priority Data . . . . . . . . . . . . . . . . . .  21
     4.3.  Summary of Recommendations for DSCP-to-QCI Mapping  . . .  22
   5.  QCI-to-DSCP Mapping Recommendations . . . . . . . . . . . . .  24
     5.1.  QCI and Diffserv Logic Reconciliation . . . . . . . . . .  24
     5.2.  Voice QCI [1] . . . . . . . . . . . . . . . . . . . . . .  26
     5.3.  IMS Signaling [5] . . . . . . . . . . . . . . . . . . . .  27
     5.4.  Voice-related QCIs [65, 66, 69] . . . . . . . . . . . . .  27
     5.5.  Video QCIs [67, 2, 4, 71, 72, 73, 74, 76] . . . . . . . .  28
     5.6.  Live streaming and interactive gaming [7] . . . . . . . .  29
     5.7.  Low latency eMBB and AR/VR [80] . . . . . . . . . . . . .  30
     5.8.  V2X messaging [75,3,9]  . . . . . . . . . . . . . . . . .  30
     5.9.  Automation and Transport [82, 83, 84, 85] . . . . . . . .  31
     5.10. Non-mission-critical data [6,8,9] . . . . . . . . . . . .  32
     5.11. Mission-critical data [70]  . . . . . . . . . . . . . . .  32
     5.12. Summary of Recommendations for QCI-to-DSCP Mapping  . . .  33
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  35
   7.  Specific Security Considerations  . . . . . . . . . . . . . .  35
   8.  Security Recommendations for General QoS  . . . . . . . . . .  35
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  36
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  36
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  36
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  38

1.  Introduction

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

Henry & Szigeti          Expires April 14, 2020                 [Page 3]
Internet-Draft                DIFFSERV-QCI                  October 2019

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.  As such, its principles could
   apply to IP traffic carried over cellular DataLink and Physical Layer
   mediums.  Additionally, the principles of [RFC4594] apply to any
   traffic entering the Internet, regardless of its original source
   location.  Thus, [RFC4594] describes different types of traffic
   expected in IP networks and provides guidance as to what DSCP
   marking(s) should be associated with each traffic type.  As such,
   this document draws heavily on [RFC4594] , as well as [RFC5127], and
   [RFC8100].

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

1.2.  Applicability Statement

   This document is applicable to the use of Differentiated Services
   that interconnect with 3GPP cellular networks (referred to as
   cellular, throughout this document, for simplicity).  These
   guidelines are applicable whether cellular network endpoints are IP-
   enabled, in which case these guidelines can apply end-to-end,
   starting from the endpoint operating system, or whether cellular
   network endpoints are either not IP-enabled, or do not enable QoS, in
   which case these guidelines apply at the interconnection point

Henry & Szigeti          Expires April 14, 2020                 [Page 4]
Internet-Draft                DIFFSERV-QCI                  October 2019

   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 and QCI, and showing how QCIs are
      implemented and used.

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

   o  Section 4 proposes a Diffserv to QCI translation scheme, so as to
      carry DSCP values to the 3GPP domains when QCI must be used.

   o  Section 5 proposes a reverse mapping, from QCI to Diffserv.  As
      many QCIs intents do not match existing DSCP 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.

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.

Henry & Szigeti          Expires April 14, 2020                 [Page 5]
Internet-Draft                DIFFSERV-QCI                  October 2019

   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.

   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.

Henry & Szigeti          Expires April 14, 2020                 [Page 6]
Internet-Draft                DIFFSERV-QCI                  October 2019

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

2.1.  Diffserv Domain Boundaries

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

   Additionally, the P-GW interconnects the UE data plane to the
   external networks.  The P-GW is the element that implements Gateway
   GPRS (General Packet Radio Service) Support Node (GGSN)
   functionalities in Evolved Packet Core (EPS) networks.  The GGSN
   includes an IP BS manager function that acts as a Diffserv Edge
   function, and can translate Diffserv parameters to LTE QoS parameters
   (e.g.  QCI) and vice versa.

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

2.2.  QCI and Bearer Model in 3GPP

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

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

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

Henry & Szigeti          Expires April 14, 2020                 [Page 7]
Internet-Draft                DIFFSERV-QCI                  October 2019

   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.
       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.

Henry & Szigeti          Expires April 14, 2020                 [Page 8]
Internet-Draft                DIFFSERV-QCI                  October 2019

   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.
   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

Henry & Szigeti          Expires April 14, 2020                 [Page 9]
Internet-Draft                DIFFSERV-QCI                  October 2019

   (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   |                      |
   +----+----------+----------+--------+--------+----------------------+
   | 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     |

Henry & Szigeti          Expires April 14, 2020                [Page 10]
Internet-Draft                DIFFSERV-QCI                  October 2019

   |    |          |          |        |        | 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       |
   |    |          |          |        |        |                      |
   | 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)               |
   |    |          |          |        |        |                      |

Henry & Szigeti          Expires April 14, 2020                [Page 11]
Internet-Draft                DIFFSERV-QCI                  October 2019

   | 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    |
   |    |          |          |        |        |                      |
   | 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.

Henry & Szigeti          Expires April 14, 2020                [Page 12]
Internet-Draft                DIFFSERV-QCI                  October 2019

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.  GSMA IPX Guidelines Interpretation and Conflicts

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

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

   These GSMA Guidelines were developed without reference to existing
   IETF specifications for various services, referenced in Section 1.1.
   Additionally, the same recommendations remained while new traffic
   types under each 3GPP general class were added.  As such, the GSMA
   recommendations yield to several inconsistencies with [RFC4594],
   including:

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

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

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

Henry & Szigeti          Expires April 14, 2020                [Page 13]
Internet-Draft                DIFFSERV-QCI                  October 2019

   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:

   o  mark DSCP, per Diffserv standards

   o  mark QCI, per the [TS 23.203] standard

   o  support fully-configurable mappings between DSCP and QCI

   o  process DSCP markings set by cellular endpoint devices

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

   o  mark DSCP, per Diffserv standards

Henry & Szigeti          Expires April 14, 2020                [Page 14]
Internet-Draft                DIFFSERV-QCI                  October 2019

   o  mark QCI, per the [TS 23.203] standard

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

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

4.  DSCP-to-QCI Mapping Recommendations

4.1.  Control Traffic

4.1.1.  Network Control Protocols

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

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

   Network Control service is not directly called by any specific QCI
   description, because 3GPP network control does not operate over UE
   data channels.  It should be noted that encapsulated routing
   protocols for encapsulated or overlay networks (e.g., VPN, Network
   Virtualization Overlays, etc.) are not Network Control Traffic for
   any physical network at the cellular space; hence, they SHOULD NOT be
   marked with CS6 in the first place, and are not expected to be
   forwarded to the cellular data plane.

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

Henry & Szigeti          Expires April 14, 2020                [Page 15]
Internet-Draft                DIFFSERV-QCI                  October 2019

4.1.2.  Operations, Administration, and Maintenance (OAM)

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

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

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

4.2.  User Traffic

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

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

4.2.1.  Telephony

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

   3GPP [TS 23.203] describes two QCIs adapted to Voice traffic: QCI 1
   (GBR) and QCI 7 (non-GBR).  However, Telephony traffic as intended in
   [RFC4594] supposes resource allocation control.  Telephony SHOULD be
   configured to receive guaranteed forwarding resources so that all
   packets are forwarded quickly.  The Telephony service class SHOULD be
   configured to use Priority Queuing system.  QCI 7 does not match
   these conditions.  As such, packets marked to EF are RECOMMENDED to

Henry & Szigeti          Expires April 14, 2020                [Page 16]
Internet-Draft                DIFFSERV-QCI                  October 2019

   be mapped to QCI 1, thus admitting it to the GBR Conversational Voice
   category, with a relative priority of 2.

4.2.2.  Signaling

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

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

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

4.2.3.  Multimedia Conferencing

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

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

Henry & Szigeti          Expires April 14, 2020                [Page 17]
Internet-Draft                DIFFSERV-QCI                  October 2019

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

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

4.2.4.  Real-Time Interactive

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

   The primary media type typically carried within the Real-Time
   Interactive service class is video; as such, it is RECOMMENDED to map
   this class into a low latency Category.  Specifically, it is
   RECOMMENDED to map CS4 to QCI 80, thereby admitting Real-Time
   Interactive traffic into the non-GBR category Low Latency eMBB
   (enhanced Mobile Broadband) applications with a relative priority of
   6.8.  In cases where GBR is required, for example because a single
   bearer is allocated for all non-GBR traffic, using a GBR equivalent
   is also acceptable.  In this case, it is RECOMMENDED to map CS4 to
   QCI 3, thereby admitting Real-Time Interactive traffic into the GBR
   category Real-time gaming, with a relative priority of 3.

4.2.5.  Multimedia Streaming

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

   The primary media type typically carried within the Multimedia
   Streaming service class is video; as such, it is RECOMMENDED to map

Henry & Szigeti          Expires April 14, 2020                [Page 18]
Internet-Draft                DIFFSERV-QCI                  October 2019

   this class into a Video Category.  Specifically, it is RECOMMENDED to
   map AF31 to QCI 4, thereby admitting AF31 into the GBR Non
   Conversational Video category, with a relative priority of 5.

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

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

4.2.6.  Broadcast Video

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

   As directly implied by the name, the primary media type typically
   carried within the Broadcast Video service class is video; as such,
   it is RECOMMENDED to map this class into a Video Category.
   Specifically, it is RECOMMENDED to map CS3 to QCI 4, thereby
   admitting Multimedia Streaming into the GBR Non Conversational Video
   category, with a relative priority of 5.  In cases where GBR
   availability is constrained, using a non-GBR equivalent is also
   acceptable.  In this case, it is RECOMMENDED to map CS3 to QCI 6,
   thereby admitting Real-Time Interactive traffic into the non-GBR
   category Video with a relative priority of 6.

4.2.7.  Low-Latency Data

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

Henry & Szigeti          Expires April 14, 2020                [Page 19]
Internet-Draft                DIFFSERV-QCI                  October 2019

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

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

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

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

4.2.8.  High-Throughput Data

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

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

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

Henry & Szigeti          Expires April 14, 2020                [Page 20]
Internet-Draft                DIFFSERV-QCI                  October 2019

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

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

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

4.2.9.  Standard

   The Standard service class is recommended for traffic that has not
   been classified into one of the other supported forwarding service
   classes in the Diffserv network domain.  This service class provides
   the Internet's "best-effort" forwarding behavior.  [RFC4594]
   Section 4.9 states that the "Standard service class MUST use the
   Default Forwarding (DF) PHB".

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

4.2.10.  Low-Priority Data

   The Low-Priority Data service class serves applications that the user
   is willing to accept without service assurances.  This service class
   is specified in [RFC3662] and [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 that could be
   labelled low priority below the best effort category.  As such, it is

Henry & Szigeti          Expires April 14, 2020                [Page 21]
Internet-Draft                DIFFSERV-QCI                  October 2019

   RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP and LE
   DSCP to QCI 9, thereby admitting it to the low priority Video and
   TCP-based traffic category, with a relative priority of 9.

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

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

Henry & Szigeti          Expires April 14, 2020                [Page 22]
Internet-Draft                DIFFSERV-QCI                  October 2019

        +------+-----------------+---------------+----------------+
        | DSCP | Recommended QCI | Resource Type | Priority Level |
        +------+-----------------+---------------+----------------+
        | CS7  | 82              | GBR           | 1.9            |
        |      |                 |               |                |
        | CS6  | 82              | GBR           | 1.9            |
        |      |                 |               |                |
        | EF   | 1               | GBR           | 2              |
        |      |                 |               |                |
        | CS5  | 4               | GBR           | 5              |
        |      |                 |               |                |
        | AF43 | 7               | non-GBR       | 7              |
        |      |                 |               |                |
        | AF42 | 4               | GBR           | 5              |
        |      |                 |               |                |
        | AF41 | 2               | GBR           | 4              |
        |      |                 |               |                |
        | CS4  | 80 3            | non-BGR GBR   | 6.8 3          |
        |      |                 |               |                |
        | AF33 | 8               | non-GBR       | 8              |
        |      |                 |               |                |
        | AF32 | 6               | non-GBR       | 6              |
        |      |                 |               |                |
        | AF31 | 4               | GBR           | 5              |
        |      |                 |               |                |
        | CS3  | 85              | GBR           | 2.1            |
        |      |                 |               |                |
        | AF23 | 8               | Non-GBR       | 8              |
        |      |                 |               |                |
        | AF22 | 6               | Non-GBR       | 6              |
        |      |                 |               |                |
        | AF21 | 70              | Non-GBR       | 5.5            |
        |      |                 |               |                |
        | CS2  | 9               | Non-GBR       | 9              |
        |      |                 |               |                |
        | AF13 | 9               | Non-GBR       | 9              |
        |      |                 |               |                |
        | AF12 | 8               | Non-GBR       | 8              |
        |      |                 |               |                |
        | AF11 | 6               | Non-GBR       | 6              |
        |      |                 |               |                |
        | CS0  | 9               | Non-GBR       | 9              |
        |      |                 |               |                |
        | CS1  | 9               | Non-GBR       | 6.8            |
        |      |                 |               |                |
        | LE   | 9               | Non-GBR       | 6.8            |
        +------+-----------------+---------------+----------------+

Henry & Szigeti          Expires April 14, 2020                [Page 23]
Internet-Draft                DIFFSERV-QCI                  October 2019

5.  QCI-to-DSCP Mapping Recommendations

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

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

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

   In cases where the UE is unable to apply Diffserv marking, or if
   these markings are modified or removed within the 3GPP domain, such
   that these markings may not represent the intent expressed by the UE,
   and in cases where the QCI is available to represent the flow intent,
   the recommendations in this section apply.  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 and Diffserv Logic Reconciliation

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

Henry & Szigeti          Expires April 14, 2020                [Page 24]
Internet-Draft                DIFFSERV-QCI                  October 2019

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

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

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

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

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

Henry & Szigeti          Expires April 14, 2020                [Page 25]
Internet-Draft                DIFFSERV-QCI                  October 2019

   Each QCI is represented with 6 parameters, including an Example
   Services value.  This parameter is representative of the QCI intent.
   Although [TS 23.203] summarizes each QCI intent, this standard is
   only a summary of more complex classification expressed in other 3GPP
   standards.  It is often necessary to refer to these other standards
   to obtain a more complex description of each QCI and the multiple
   type of flows that each QCI represents.

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

   Although 26 QCIs are listed in [TS 23.203], representing two bearer
   types (GBR, non-GBR), 21 priority values, 9 delay budget values, and
   7 loss tolerance values, examining the intent surfaces 9 traffic
   families:

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

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

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

   4.   Video (conversational or not, mission critical or not) [67, 2,
        4, 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]

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

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

5.2.  Voice QCI [1]

   Several QCIs are intended to carry voice traffic.  However, QCI 1
   stands apart from the others.  Its category is Conversational Voice,
   but this QCI is intended to represent the VoLTE voice bearer, for
   dialer and emergency services.  QCI 1 uses a GBR, and has a priority

Henry & Szigeti          Expires April 14, 2020                [Page 26]
Internet-Draft                DIFFSERV-QCI                  October 2019

   level of 2.  Its packet delay budget is 100 ms (from UE to P-GW) with
   a packet error loss of at most 10.E-2.  As the GBR is allocated by
   the infrastructure, QCI 1 is both admitted and allocated dedicated
   resources.  As such, QCI 1 maps in intent and function to [RFC5865],
   Admitted Voice, and is RECOMMENDED for mapping to DSCP 44.

5.3.  IMS Signaling [5]

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

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

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

   o  QCI 65 is GBR, mission critical PTT voice, priority 0.7

   o  QCI 66 is GBR, non-mission critical PTT voice, priority 2

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

   These QCI are Voice in nature, and naturally fit into a proximity
   marking model with DSCP 46 and 44.

   Additionally, lower priority marks higher precedence intent in QCI.
   However, there is no model in [RFC4594] that distinguishes 3 classes
   of voice traffic.  Therefore, new markings are unavoidable.  As such,
   there is a need to group these markings in the Voice category (101
   xxx), and to order 69, 65 and 66 with different markings to reflect
   their different priority levels.

   Among these three QCIs, 69 is non-GBR, intended for mission-critical
   PTT signaling, with the highest priority of the three, at 0.5.  QCI
   69 is intended for signaling, but is latency sensitive, with a low 60
   ms delay budget and a low 10.E-6 loss tolerance.  Being of Signaling
   nature for real time applications, QCI 69 has proximity of intent

Henry & Szigeti          Expires April 14, 2020                [Page 27]
Internet-Draft                DIFFSERV-QCI                  October 2019

   with CS5 (Voice signaling, 40), but this marking is already used by
   QCI 5.  Therefore, it is RECOMMENDED to map QCI 69 to a new DSCP
   marking, 41.

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

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

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

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

   All eight QCIs represent video streams and fit naturally in the AF4x
   category.  However, these QCIs do not match [RFC4594] intent for
   multimedia conferencing, in that they are 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 to an existing AF4x
   category.  In order to avoid mixing admitted and non-admitted video
   in the same class, it is necessary to associate these QCIs to new
   Diffserv classes.

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

   As such, its RECOMMENDED to map QCI 67 against the DSCP value closest
   to AF4x video with lowest discard eligibility (AF41), namely category
   33.

Henry & Szigeti          Expires April 14, 2020                [Page 28]
Internet-Draft                DIFFSERV-QCI                  October 2019

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

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

   QCIs 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.239] 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).

5.6.  Live streaming and interactive gaming [7]

   QCI 7 is non-GBR and intended for live streaming voice or video
   interactive gaming.  Its priority is 7.  It is the only QCI targeting
   this particular traffic mix.  In the Diffserv model, voice and video
   are different categories, and are also different from interactive
   gaming (real time interactive).  In the 3GPP model, live streaming

Henry & Szigeti          Expires April 14, 2020                [Page 29]
Internet-Draft                DIFFSERV-QCI                  October 2019

   video and mission-critical video are defined in other queues with
   high priority (e.g.  QCI 2 for video Live streaming, with a priority
   of 2, or QCI 67 for mission-critical video, with a priority of 1.5).
   By comparison, QCI 7 priority is relatively low (7), with a 100 ms
   budget delay and a comparatively rather high loss tolerance (10.E-3).

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

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

   QCI 80 is intended for low latency eMBB (enhanced Mobile Broadband)
   applications, such as Augmented Reality of Virtual Reality (AR/VR).
   This QCI priority is 6.8,with a low packet delay budget of 10 ms, and
   a packet error loss rate of at most 10.E-6.

   QCI 80 is non-GBR, yet intended for real time applications.  Traffic
   in the AR/VR category typically does not react dynamically to losses,
   requires bandwidth and a low and predictable delay.

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

5.8.  V2X messaging [75,3,9]

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

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

   Similarly, QCI 3 is intended for V2X messages, but can also be used
   for Real time gaming, or Utility traffic (medium voltage

Henry & Szigeti          Expires April 14, 2020                [Page 30]
Internet-Draft                DIFFSERV-QCI                  October 2019

   distribution) or process automation monitoring.  QCI 3 priority is 3.
   QCI 3 is data in nature, but GBR.  Its delay budget is low (50 ms),
   but with some tolerance to loss (10E-3).

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

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

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

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

   QCI 84 is intended for intelligent transport systems.  As such, its
   intent is close to the V2X messaging category.  QCI 84 is also
   admitted (GBR).  However, QCI 84 is intended for traffic with a
   smaller packet delay budget (30 ms vs 50 ms for QCI 75) and a smaller
   packet error loss maximum rate (10.E-6 vs 10.E-2 for QCI 75).As such,
   QCI 84 should be mapped against a category above that of QCIs 75 or
   QCI 3.  Being admitted, QCI 84 does not map easily into an existing
   category.  As such, it is RECOMMENDED to map QCI 84 to category 31.

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

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

Henry & Szigeti          Expires April 14, 2020                [Page 31]
Internet-Draft                DIFFSERV-QCI                  October 2019

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

   As such, it is RECOMMENDED to map QCI 82 to category 27.  Similarly,
   it is RECOMMENDED to map QCI 83 to category 29.

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

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

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

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

5.11.  Mission-critical data [70]

   QCI 70 is non-GBR, intended for mission critical data, with a
   priority of 5.5, a packet delay budget of 200 ms and a packet error
   loss rate tolerance of at most 10.E-6.  The traffic types intended
   for QCI 70 are the same as for QCIs 6,8,9 categories, namely buffered
   streaming video and TCP-based traffic, such as www, email, chat, FTP,
   P2P and other file sharing applications.  However, QCI 70 is
   specifically intended for applications that are mission critical.
   For this reason, QCI 70 priority is higher than QCIs 6, 8 or 9
   priorities (5.5 vs 6, 8 and 9 respectively).  Therefore, QCI 70 fits
   well in the AF2x family, while 6,8,9 are in AF1x.  As QCI 70 displays

Henry & Szigeti          Expires April 14, 2020                [Page 32]
Internet-Draft                DIFFSERV-QCI                  October 2019

   intermediate differentiated treatment, if also fits well with an
   intermediate discard eligibility.  As such, it is RECOMMENDED to map
   QCI 70 to DSCP 20 (AF22).

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

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

   +-----+----------+----------+-------------------------+-------------+
   | QCI | Resource | Priority | Example Services        | Recommended |
   |     | Type     | Level    |                         | DSCP (PHB)  |
   +-----+----------+----------+-------------------------+-------------+
   | 1   | GBR      | 2        | Conversational Voice    | 44 (VA)     |
   |     |          |          |                         |             |
   | 2   | GBR      | 4        | Conversational Video    | 35 (N.A.)   |
   |     |          |          | (Live Streaming)        |             |
   |     |          |          |                         |             |
   | 3   | GBR      | 3        | Real Time Gaming,  V2X  | 19 (N.A.)   |
   |     |          |          | messages, Electricity   |             |
   |     |          |          | distribution (medium    |             |
   |     |          |          | voltage) Process        |             |
   |     |          |          | automation (monitoring) |             |
   |     |          |          |                         |             |
   | 4   | GBR      | 5        | Non-Conversational      | 37 (N.A.)   |
   |     |          |          | Video  (Buffered        |             |
   |     |          |          | Streaming)              |             |
   |     |          |          |                         |             |
   | 65  | GBR      | 0.7      | Mission Critical user   | 42 (N.A.)   |
   |     |          |          | plane  Push To Talk     |             |
   |     |          |          | voice  (e.g., MCPTT)    |             |
   |     |          |          |                         |             |
   | 66  | GBR      | 2        | Non-Mission-Critical    | 43 (N.A.)   |
   |     |          |          | user plane Push To Talk |             |
   |     |          |          | voice                   |             |
   |     |          |          |                         |             |
   | 67  | GBR      | 1.5      | Mission Critical Video  | 33 (N.A.)   |
   |     |          |          | user plane              |             |
   |     |          |          |                         |             |
   | 75  | GBR      | 2.5      | V2X messages            | 17 (N.A.)   |
   |     |          |          |                         |             |
   | 82  | GBR      | 1.9      | Discrete automation     | 27 (N.A.)   |
   |     |          |          | (small packets)         |             |
   |     |          |          |                         |             |
   | 83  | GBR      | 2.2      | Discrete automation     | 29 (N.A.)   |
   |     |          |          | (large packets)         |             |
   |     |          |          |                         |             |
   | 84  | GBR      | 2.4      | Intelligent Transport   | 31 (N.A.)   |

Henry & Szigeti          Expires April 14, 2020                [Page 33]
Internet-Draft                DIFFSERV-QCI                  October 2019

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

Henry & Szigeti          Expires April 14, 2020                [Page 34]
Internet-Draft                DIFFSERV-QCI                  October 2019

6.  IANA Considerations

   This document allocates thirteen codepoints (17, 19, 21, 25, 27, 29,
   31, 33, 35, 37, 41, 42 and 43), further detailed in Section 5, in
   Pool 1 of the code space defined by [RFC2474].

7.  Specific Security Considerations

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

8.  Security Recommendations for General QoS

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

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

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

   o  Setting a traffic conditioning policy reflective of business
      objectives and policy, such that traffic from authorized users
      and/or applications and/or endpoints will be accepted by the
      network; otherwise, packet markings will be "bleached" (i.e., re-
      marked to DSCP DF).  Additionally, Section 5 made it clear that it
      is generally NOT RECOMMENDED to pass through DSCP markings from
      unauthorized, unidentified and/or unauthenticated devices, as
      these are typically considered untrusted sources.  This is
      especially relevant for Internet of Things (IoT) deployments,
      where tens of billions of devices with little or no security
      capabilities are being connected to LTE and IP networks, leaving
      them vulnerable to be utilized as agents for DDoS attacks.  These
      attacks can be amplified with preferential QoS treatments, should
      the packet markings of such devices be trusted.

Henry & Szigeti          Expires April 14, 2020                [Page 35]
Internet-Draft                DIFFSERV-QCI                  October 2019

   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>.

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>.

Henry & Szigeti          Expires April 14, 2020                [Page 36]
Internet-Draft                DIFFSERV-QCI                  October 2019

   [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>.

   [TS23.203]
              3GPP, "Policy and charging control architecture v16.0",
              March 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>.

Henry & Szigeti          Expires April 14, 2020                [Page 37]
Internet-Draft                DIFFSERV-QCI                  October 2019

Authors' Addresses

   Jerome Henry
   Cisco

   Email: jerhenry@cisco.com

   Tim Szigeti
   Cisco

   Email: szigeti@cisco.com

Henry & Szigeti          Expires April 14, 2020                [Page 38]