<?xml version="1.0" encoding="US-ASCII"?> encoding="UTF-8"?>

<!DOCTYPE rfc [
<!-- Historic references will result in warnings! -->
<!ENTITY RFC1349 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1349.xml">
<!-- References -->
<!ENTITY RFC0791 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml">
<!ENTITY RFC1122 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2474 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml">
<!ENTITY RFC2597 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2597.xml">
<!ENTITY RFC2760 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2760.xml">
<!ENTITY RFC3086 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3086.xml">
<!ENTITY RFC3246 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3246.xml">
<!ENTITY RFC3260 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3260.xml">
<!ENTITY RFC3270 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3270.xml">
<!ENTITY RFC3552 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC2475 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2475.xml">
<!ENTITY RFC3290 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3290.xml">
<!ENTITY RFC3662 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3662.xml">
<!ENTITY RFC4594 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4594.xml">
<!ENTITY RFC5127 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5127.xml">
<!ENTITY RFC5129 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5129.xml">
<!ENTITY RFC5160 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5160.xml">
<!ENTITY RFC5415 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5415.xml">
  <!ENTITY RFC5865 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5865.xml"> nbsp    "&#160;">
  <!ENTITY RFC8100 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8100.xml"> zwsp   "&#8203;">
  <!ENTITY RFC8126 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"> nbhy   "&#8209;">
  <!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8325 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8325.xml">
<!ENTITY RFC8436 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8436.xml">
<!ENTITY RFC8622 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8622.xml">
<!ENTITY I-D.ietf-tsvwg-nqb SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-tsvwg-nqb-15.xml">
<!ENTITY I-D.learmonth-rfc1226-bis SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-learmonth-rfc1226-bis-03.xml"> wj     "&#8288;">
]>
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="info" consensus="true" docName="draft-ietf-tsvwg-dscp-considerations-13" number="9435" ipr="trust200902" submissionType="IETF">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** --> tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" updates="" obsoletes="" xml:lang="en" version="3">

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
         full title is longer than 39 characters -->
    <title abbrev="Considerations for assigning abbrev="Assigning a DSCPs">Considerations New DSCP">Considerations for Assigning a new New
    Recommended DiffServ Codepoint Differentiated Services Code Point (DSCP)</title>
    <seriesInfo name="RFC" value="9435"/>
    <author fullname="Ana Custura" initials="A" surname="Custura">
      <organization>University of Aberdeen</organization>
      <address>
        <postal>
          <street>School
          <extaddr>School of Engineering</street> Engineering</extaddr>
          <street>Fraser Noble Building</street>
          <city>Aberdeen</city>

          <region></region>
          <region/>
          <code>AB24 3UE</code>

          <country>UK</country>
          <country>United Kingdom</country>
        </postal>
        <email>ana@erg.abdn.ac.uk</email>
      </address>
    </author>
    <author fullname="Godred Fairhurst" initials="G" surname="Fairhurst">
      <organization>University of Aberdeen</organization>
      <address>
        <postal>
          <street>School
          <extaddr>School of Engineering</street> Engineering</extaddr>
          <street>Fraser Noble Building</street>
          <city>Aberdeen</city>

          <region></region>
          <region/>
          <code>AB24 3UE</code>

          <country>UK</country>
          <country>United Kingdom</country>
        </postal>
        <email>gorry@erg.abdn.ac.uk</email>
      </address>
    </author>
    <author fullname="Raffaello Secchi" initials="R" surname="Secchi">
      <organization>University of Aberdeen</organization>
      <address>
        <postal>
          <street>School
          <extaddr>School of Engineering</street> Engineering</extaddr>
          <street>Fraser Noble Building</street>
          <city>Aberdeen</city>

          <region></region>
          <region/>
          <code>AB24 3UE</code>

          <country>UK</country>
          <country>United Kingdom</country>
        </postal>
        <email>r.secchi@abdn.ac.uk</email>
      </address>
    </author>
    <date day="3" month="March" year="2023" />

    <area>TSVArea</area>

    <workgroup>TSVWG</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.
         If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>DSCP DiffServ month="July" year="2023"/>
    <area>tsv</area>
    <workgroup>tsvwg</workgroup>
    <keyword>DSCP</keyword>
    <keyword>Diffserv Codepoints</keyword>

    <abstract>
      <t>This document discusses considerations for assigning a new
      recommended DiffServ Differentiated Services Code Point (DSCP) for a new standard Per Hop
      Per-Hop Behavior (PHB). It considers the common observed re-marking
      behaviors that the DiffServ Diffserv field might be subjected to along an
      Internet path. It also notes some implications of using a specific
      DSCP.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> anchor="introduction">
      <name>Introduction</name>
      <t>The Differentiated Services (DiffServ) (Diffserv) architecture has been deployed
      in many networks. It provides differentiated traffic forwarding based on
      the DiffServ Code Point (DSCP) <xref target="RFC2474"></xref> DSCP carried in the DiffServ Diffserv field <xref target="RFC2474"></xref> of the IP packet header. header <xref
      target="RFC2474"/>.  A common set of DSCPs are defined for both IPv4 and
      IPv6, and both network protocols use a common IANA registry <xref target="DSCP-registry"></xref>.</t>

      <t>DiffServ
      target="DSCP-registry"/>.</t>
      <t>Diffserv associates traffic with a service class <xref target="RFC4594"></xref> and
      categorises categorizes it
      into Behavior Aggregates (BAs) <xref target="RFC4594"></xref>. target="RFC4594"/>.  Configuration
      guidelines for service classes are provided in <xref target="RFC4594">RFC4594</xref>.
      Behavior aggregates target="RFC4594"/>.
      BAs are associated with a DiffServ Code Point (DSCP), DSCP, which in turn maps to a Per Hop Per-Hop Behavior
      (PHB).  Treatment differentiation can be achieved by using a variety of
      schedulers and queues, queues and also by algorithms that implement access to the
      physical media.</t>
      <t>Within a DiffServ Diffserv domain, operators can set service level
   specifications Service Level
      Specifications <xref target="RFC3086"></xref>, target="RFC3086"/>, each of which maps to a
      particular Per
   Domain Per-Domain Behavior (PDB) that is based on one or more PHBs.
      The PDB defines which PHB (or set of PHBs) and hence and, hence, for a specific
      operator, which DSCP (or set of DSCPs) will be associated with specific Behavior Aggregates (BAs)
      BAs as the packets pass through a DiffServ domain, and Diffserv domain. It also defines
      whether the packets are re-marked as they are forwarded (i.e.,
      changing the DSCP of a packet <xref target="RFC2475"></xref>).</t>

      <t><figure> target="RFC2475"/>).</t>

<figure anchor="fig1">
<name>The Role of DSCPs in Classifying IP Traffic for Differential Network
Treatment by a Diffserv Node</name>
<artwork><![CDATA[
Application -> Service
Traffic        Class
                 |
               Behavior  -> DiffServ Diffserv -> Per Hop
               Aggregate    Codepoint   Behavior
                                          |
                                        Schedule,
                                        Queue, Drop
]]></artwork>

          <postamble>Figure showing the role of DSCPs in classifying IP
          traffic for differential network treatment by a DiffServ Node.</postamble>
        </figure></t>
</figure>

      <t>This document discusses considerations for assigning a new DSCP for a
      standard PHB. It considers some commonly observed DSCP re-marking
      behaviors that might be experienced along an Internet path. It also
      describes some packet forwarding treatments that a packet with a
      specific DSCP can expect to receive when forwarded across a link or
      subnetwork.</t>

      <t>The document is motivated by new opportunities to use DiffServ Diffserv
      end-to-end across multiple domains, such as <xref
      target="I-D.ietf-tsvwg-nqb"></xref>,
      target="I-D.ietf-tsvwg-nqb"/>, proposals to build mechanisms using DSCPs
      in other standards-setting organisations, organizations, and the desire to use a common
      set of DSCPs across a range of infrastructure (e.g., <xref
      target="RFC8622"></xref><xref target="I-D.ietf-tsvwg-nqb">,</xref>,
      target="RFC8622"/>, <xref target="I-D.ietf-tsvwg-nqb"/>, <xref target="I-D.learmonth-rfc1226-bis"></xref>).</t>
      target="I-D.learmonth-intarea-rfc1226-bis"/>).</t>
    </section>

    <section title="Terminology">

      <t>The
    <section>
      <name>Terminology</name>
        <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
        "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
        NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
        "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
        "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
        are to be interpreted as described in BCP 14 BCP&nbsp;14 <xref
        target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
        appear in all capitals, as shown here.</t> here.
        </t>
      <t>DSCPs are specified in the IANA registry <xref target="DSCP-registry"></xref>,
      target="DSCP-registry"/>, where a variety of different formats are
      described.  A DSCP can sometimes be referred to by name, such as "CS1",
      and sometimes by a decimal, hex, or binary value. Hex values are
      represented in text using prefix 0x. "0x". Binary values use prefix 0b. "0b".
      </t>
   <t>In this document, the symbol "&amp;" denotes a bitwise AND of two unsigned values.</t>
    </section>

    <section title="Current usage
    <section>
      <name>Current Usage of DSCPs"> DSCPs</name>
      <t>This section describes the current usage of DSCPs.</t>

      <section title="IP-Layer Semantics">
      <section>
        <name>IP-Layer Semantics</name>
        <t>The DiffServ Diffserv architecture specifies the use of the DiffServ Diffserv field
        in the IPv4 and IPv6 packet headers to carry one of 64 distinct DSCP
        values. Within a given administrative boundary, each DSCP value can be
        mapped to a distinct PHB <xref target="RFC2474"></xref>. target="RFC2474"/>. When a new PHB is
        specified, a recommended DSCP value among those 64 values is normally
        reserved for that PHB, PHB and is assigned by IANA. An operator is not
        formally required to use the recommended value;
        indeed [RFC2474] indeed, <xref
        target="RFC2474"/> states that "the mapping of codepoints to PHBs
        MUST
        <bcp14>MUST</bcp14> be configurable." However, use of the recommended
        value is usually convenient and avoids confusion.</t>
        <t>The DSCP space is divided into three pools for the purpose of
        assignment and management <xref target="DSCP-registry"></xref>. target="DSCP-registry"/>. A
        summary of the pools is provided in a table (where 'x' refers to a
        bit position with value either '0' or '1').
	<list style="hanging">
            <t hangText="DSCP
        </t>
        <dl newline="false" spacing="normal">
          <dt>DSCP Pool 1:">A 1:</dt>
          <dd>A pool of 32 codepoints with a format of 0bxxxxx0, to be assigned
          by IANA Standards Action <xref
            target="RFC8126"></xref>.</t>

            <t hangText="DSCP target="RFC8126"/>.</dd>
          <dt>DSCP Pool 2:">A 2:</dt>
          <dd>A pool of 16 codepoints with a format of 0bxxxx11, reserved for experimental
          Experimental or local (private) use Local (Private) Use by network operators (see
          Sections 4.1 <xref target="RFC8126" sectionFormat="bare" section="4.1"/>
          and 4.2 <xref target="RFC8126" sectionFormat="bare" section="4.2"/> of
          <xref
            target="RFC8126"></xref>.</t>

            <t hangText="DSCP target="RFC8126"/>.</dd>
          <dt>DSCP Pool 3:">A 3:</dt>
          <dd>A pool of 16 codepoints with a format of 0bxxxx01.  This was
          initially available for experimental Experimental (EXP) Use or Local Use (LU), (LU) but
          was originally specified to be "preferentially utilized for
            standards assignments"
          standardized assignments if Pool 1 is ever exhausted. exhausted" <xref target="RFC2474"/>.

 Pool 3
          codepoints are now "utilized for standards standardized assignments and are
            no longer available (replacing
          the previous availability for assignment to experimental or local use" use)" <xref
            target="RFC8436"></xref>.
          target="RFC8436"/>.  <xref
            target="RFC8622"></xref> target="RFC8622"/> assigned 0x01 from
          this pool and consequentially updated <xref target="RFC4594"></xref>. target="RFC4594"/>. Any
          future request to assign 0x05 would be expected to similarly update
          <xref target="RFC4594"></xref>.</t>
          </list></t> target="RFC4594"/>.</dd>
        </dl>
        <t> Note that <xref target="RFC4594"></xref> target="RFC4594"/> previously recommended a local use Local
        Use of DSCP values 0x01, 0x03, 0x05 0x05, and 0x07 (codepoints with the
        format of 0b000xx1), until this was updated by <xref
            target="RFC8436"></xref>.
        target="RFC8436"/>.
        </t>
        <t>The DSCP space is shown in the following table.

          <figure>
            <preamble></preamble>

<artwork><![CDATA[
+---------+------+---------+-----+---------+-----+---------+----+
| 56/CS7  | 57   | 58      | 59  | 60      | 61  | 62      | 63 |
+---------+------+---------+-----+---------+-----+---------+----+
| 48/CS6  | 49   | 50      | 51  | 52      | 53  | 54      | 55 |
+---------+------+---------+-----+---------+-----+---------+----+
| 40/CS5  | 41   | 42      | 43  | 44/VA   | 45  | 46/EF   | 47 |
+---------+------+---------+-----+---------+-----+---------+----+
| 32/CS4  | 33   | 34/AF41 | 35  | 36/AF42 | 37  | 38/AF43 | 39 |
+---------+------+---------+-----+---------+-----+---------+----+
| 24/CS3  | 25   | 26/AF31 | 27  | 28/AF32 | 29  | 30/AF33 | 31 |
+---------+------+---------+-----+---------+-----+---------+----+
| 16/CS2  | 17   | 18/AF21 | 19  | 20/AF22 | 21  | 22/AF23 | 23 |
+---------+------+---------+-----+---------+-----+---------+----+
| 8/CS1   | 9    | 10/AF11 | 11  | 12/AF12 | 13  | 14/AF13 | 15 |
+---------+------+---------+-----+---------+-----+---------+----+
| 0/CS0   | 1/LE | 2       | 3   | 4       | 5   | 6       | 7  |
+---------+------+---------+-----+---------+-----+---------+----+
]]></artwork>

            <postamble>Table showing Each row corresponds to one setting of the currently assigned DSCPs first three bits of the DSCP field, and their assigned PHBs.</postamble>
          </figure>

          <figure>
            <preamble></preamble>

 <artwork>
<![CDATA[
+-----+-----------------------+-----------+
| CS  | Class Selector        | RFC 2474  |
+-----+-----------------------+-----------+
| BE  | Best Effort (CS0)     | RFC 2474  |
+-----+-----------------------+-----------+
| AF  | Assured Forwarding    | RFC 2597  |
+-----+-----------------------+-----------+
| EF  | Expedited Forwarding  | RFC 3246  |
+-----+-----------------------+-----------+
| VA  | Voice Admit           | RFC 5865  |
+-----+-----------------------+-----------+
| LE  | Lower Effort          | RFC 8622  |
+-----+-----------------------+-----------+
]]>
</artwork>

<postamble>Table showing each column to one setting of the summary last three bits of the DSCP abbreviations used in published RFCs.</postamble>
          </figure> field.
	</t>

<t> The above table summarises

<table anchor="table1" align="center">
  <name>Currently Assigned DSCPs and Their Assigned PHBs</name>
  <tbody>
    <tr>
      <td>56/CS7</td>
      <td>57</td>
      <td>58</td>
      <td>59</td>
      <td>60</td>
      <td>61</td>
      <td>62</td>
      <td>63</td>
    </tr>
    <tr>
      <td>48/CS6</td>
      <td>49</td>
      <td>50</td>
      <td>51</td>
      <td>52</td>
      <td>53</td>
      <td>54</td>
      <td>55</td>
    </tr>
    <tr>
      <td>40/CS5</td>
      <td>41</td>
      <td>42</td>
      <td>43</td>
      <td>44/VA</td>
      <td>45</td>
      <td>46/EF</td>
      <td>47</td>
    </tr>
    <tr>
      <td>32/CS4</td>
      <td>33</td>
      <td>34/AF41</td>
      <td>35</td>
      <td>36/AF42</td>
      <td>37</td>
      <td>38/AF43</td>
      <td>39</td>
    </tr>
    <tr>
      <td>24/CS3</td>
      <td>25</td>
      <td>26/AF31</td>
      <td>27</td>
      <td>28/AF32</td>
      <td>29</td>
      <td>30/AF33</td>
      <td>31</td>
    </tr>
    <tr>
      <td>16/CS2</td>
      <td>17</td>
      <td>18/AF21</td>
      <td>19</td>
      <td>20/AF22</td>
      <td>21</td>
      <td>22/AF23</td>
      <td>23</td>
    </tr>
    <tr>
      <td>8/CS1</td>
      <td>9</td>
      <td>10/AF11</td>
      <td>11</td>
      <td>12/AF12</td>
      <td>13</td>
      <td>14/AF13</td>
      <td>15</td>
    </tr>
  </tbody>
  <tfoot>
    <tr>
      <th>0/CS0</th>
      <th>1/LE</th>
      <th>2</th>
      <th>3</th>
      <th>4</th>
      <th>5</th>
      <th>6</th>
      <th>7</th>
    </tr>
  </tfoot>
</table>

<table anchor="table2" align="center">
<name>Abbreviations for DSCPs and PHB Groups</name>
<tbody>
  <tr>
    <td>CS</td>
    <td>Class Selector</td>
    <td><xref target="RFC2474"/></td>
  </tr>
  <tr>
    <td>BE</td>
    <td>Best Effort (CS0)</td>
    <td><xref target="RFC2474"/></td>
  </tr>
  <tr>
    <td>AF</td>
    <td>Assured Forwarding</td>
    <td><xref target="RFC2597"/></td>
  </tr>
  <tr>
    <td>EF</td>
    <td>Expedited Forwarding</td>
    <td><xref target="RFC3246"/></td>
  </tr>
  <tr>
    <td>VA</td>
    <td>Voice Admit</td>
    <td><xref target="RFC5865"/></td>
  </tr>
  <tr>
    <td>LE</td>
    <td>Lower Effort</td>
    <td><xref target="RFC8622"/></td>
  </tr>
</tbody>
</table>

        <t><xref target="table2"/> summarizes the DSCP abbreviations used in
        currently published RFCs RFCs, <xref target="RFC2474"></xref> target="RFC2474"/> <xref
                       target="RFC2597"></xref>
        target="RFC2597"/> <xref target="RFC3246"></xref> target="RFC3246"/> <xref
                       target="RFC5865"></xref> target="RFC5865"/>
        <xref target="RFC8622"></xref>, target="RFC8622"/>, as described in the IANA registry <xref
                       target="DSCP-registry"></xref>. BE,
        target="DSCP-registry"/>.
The Default PHB is defined in <xref target="RFC2474" section="4.1" sectionFormat="of"/>. This provides Best Effort (BE) forwarding, and the recommended DSCP of '000000' (<xref target="RFC2474" section="4.2.2.1" sectionFormat="of"/>). This
is the lowest value in the set of Class Selector (CS) DSCPs, and hence is also known as CS0, describes the default forwarding treatment. "CS0" <xref target="DSCP-registry"/>.

        </t>
        <t> NOTE: <xref target="RFC4594"></xref> target="RFC4594"/> specified a now deprecated use of
        Class Selector 1 (CS1) as the codepoint for the Lower Effort
        PHB. <xref target="RFC8622"></xref> target="RFC8622"/> updated <xref target="RFC4594"></xref> target="RFC4594"/> and
        <xref target="RFC8325"></xref>, target="RFC8325"/> and obsoleted <xref target="RFC3662"></xref>, target="RFC3662"/>,
        assigning the LE DSCP codepoint to the Lower Effort PHB.</t>
        <t>The DiffServ Diffserv architecture allows forwarding treatments to be
        associated with each DSCP, and the RFC series describes some of these
        as PHBs. Although DSCPs are intended to identify specific treatment
        requirements, multiple DSCPs might also be mapped (aggregated) to the
        same forwarding treatment. DSCPs can be mapped to treatment
        aggregates Treatment Aggregates (TAs)
        that might result in re-marking (e.g., <xref
        target="RFC5160">RFC5160</xref> target="RFC5160"/>
        suggests Meta-QoS-Classes to help enable deployment of standard
        end-to-end QoS classes)</t> classes).</t>
      </section>

      <section title="DSCPs used
      <section>
        <name>DSCPs Used for Network Control Traffic"> Traffic</name>
        <t>Network Control Traffic control traffic is defined as packet flows that are
        essential for stable operation of the administered network (see <xref
        target="RFC4594"></xref>, Section 3).
        target="RFC4594" sectionFormat="comma" section="3"/>). The traffic
        consists of the network control service class and the OAM service
        class.  This traffic is marked with a value from a set of Class Selector (CS) CS DSCPs.  This traffic is often a special case within a
        provider network, and ingress traffic with these DSCP markings can be
        re-marked.</t>
        <t>DSCP CS2 is recommended for the OAM (Operations, Administration,
        and Maintenance) service class (see <xref target="RFC4594"></xref>,
        Section 3.3).</t> target="RFC4594"
        sectionFormat="comma" section="3.3"/>).</t>
        <t>DSCP CS6 is recommended for local network control traffic. This
        includes routing protocols and OAM traffic that are essential to
        network operation administration, control control, and management. Section 3.2
        of  <xref target="RFC4594">RFC4594</xref>
        target="RFC4594" sectionFormat="of" section="3.2"/> recommends that
        "CS6 marked packet flows from untrusted sources (for example, end-user end user
        devices)
        SHOULD <bcp14>SHOULD</bcp14> be dropped or re-marked remarked at ingress to
        the DiffServ Diffserv network".</t>
        <t>DSCP CS7 is reserved for future use by network control traffic.
        "CS7 marked packets SHOULD NOT <bcp14>SHOULD NOT</bcp14> be sent across peering
        points" <xref
        target="RFC4594"></xref>.</t>

	<t>RFC2474 target="RFC4594" sectionFormat="comma" section="3.1"/>.</t>
        <t><xref target="RFC2474" sectionFormat="of" section="4.2.2.2"/>
        recommends PHBs selected by CS6 and CS7  "MUST "<bcp14>MUST</bcp14> give
        packets a preferential forwarding treatment by comparison to the PHB
        selected by codepoint '000000'"<xref target="RFC2474"></xref>.</t> '000000'".</t>
        <t> At the time of writing, there is evidence to suggest CS6 is
        actively used by network operators for control traffic. A study of
        traffic at a large Internet Exchange showed around 40% of ICMP traffic
        carried this mark <xref target="IETF115-IEPG"></xref>. target="IETF115-IEPG"/>. Similarly, another
        study found many routers re-mark all traffic, except for packets
        carrying a DSCP with the format 0b11xxxx (i.e. (i.e., setting the higher
        order bits to 0b11, see Section 4.2.1 <xref target="tos-prec-bleach-impact"/> of
        this document).</t>
      </section>
    </section>
    <section anchor="observed-re-marking" title="Re-marking anchor="observed-re-marking">
      <name>Re-marking the DSCP"> DSCP</name>
      <t>It is a feature of the DiffServ Diffserv architecture that the DiffServ Diffserv field
      of packets can be re-marked at the Diffserv domain boundaries (see Section 2.3.4.2 of <xref target="RFC2475"></xref>).
      target="RFC2475" sectionFormat="of" section="2.3.4.2"/>). A DSCP can be
      re-marked at the ingress of a domain. This re-marking can change the
      DSCP value used on the remainder of an IP path, or the network can
      restore the initial DSCP marking at the egress of the domain. The DiffServ
      Diffserv field can also be re-marked based on common semantics and
      agreements between providers at an exchange point. a Diffserv domain boundary. Furthermore, <xref target="RFC2474"></xref>
      target="RFC2474"/> states that re-marking must occur when there is a
      possibility of theft or denial-of-service attack.</t>

	    <t>
      <t>A packet that arrives with a DSCP that is not associated with a PHB,
      results in an "unknown DSCP." A node could receive a packet with an
      "unexpected DSCP" due to misconfiguration, or because there is no
      consistent policy in place. The treatment of packets that are marked
      with an unknown or an unexpected DSCP at DiffServ Diffserv domain boundaries is
      determined by the policy for a DiffServ Diffserv domain.  If packets are received
      that are marked with an unknown or an unexpected DSCP by a DiffServ Diffserv
      domain interior node, <xref target="RFC2474"></xref> target="RFC2474"/> recommends forwarding the
      packet using a default (best effort) treatment, (Best Effort) treatment but without changing the
      DSCP.  This seeks to support incremental DiffServ Diffserv deployment in existing
      networks as well as preserve DSCP markings by routers that have not been
      configured to support DiffServ. (See Diffserv (see also <xref target="re-mark"></xref>). target="re-mark"/>).
      <xref target="RFC3260"></xref> target="RFC3260"/> clarifies that this re-marking specified by RFC2474
      <xref target="RFC2474"/> is intended for interior nodes within a DiffServ
      Diffserv domain. For DiffServ Diffserv ingress nodes nodes, the traffic conditioning
      required by RFC 2475 <xref target="RFC2475"/> applies first.
</t> first.</t>
      <t>Reports measuring existing deployments have defined a set of
      categories for DSCP re-marking <xref target="Cus17"></xref> target="Cus17"/> <xref target="Bar18"></xref>
      into
      target="Bar18"/> in the following seven observed
      re-marking behaviors:</t>

      <t><list style="hanging">
          <t hangText="Bleach-DSCP:">bleaches
      <dl newline="false" spacing="normal">
        <dt>Bleach-DSCP:</dt>
        <dd>bleaches all traffic (sets the DSCP to
          zero);</t>

          <t hangText="Bleach-ToS-Precedence:">set zero)</dd>
        <dt>Bleach-ToS-Precedence:</dt>
        <dd>set the first three bits of the DSCP field to 0b000 (reset the 3
        three bits of the former ToS Precedence field, defined in <xref target="RFC0791"></xref>,
        target="RFC0791"/> and clarified in <xref target="RFC1122"></xref>);</t>

          <t hangText="Bleach-some-ToS:">set target="RFC1122"/>)</dd>
        <dt>Bleach-some-ToS:</dt>
        <dd>set the first three bits of the DSCP field to 0b000 (reset the 3
        three bits of the former ToS Precedence field), unless the first two
        bits of the DSCP field are 0b11;</t>

          <t hangText="Re-mark-ToS:">set 0b11</dd>
        <dt>Re-mark-ToS:</dt>
        <dd>set the first three bits of the DSCP field to any value different
        from 0b000 (replace the 3 three bits of the former ToS Precedence field);</t>

          <t hangText="Bleach-low:">set
        field)</dd>
        <dt>Bleach-low:</dt>
        <dd>set the last three bits of the DSCP field to 0b000;</t>

          <t hangText="Bleach-some-low:">set 0b000</dd>
        <dt>Bleach-some-low:</dt>
        <dd>set the last three bits of the DSCP field to 0b000, unless the
        first two bits of the DSCP field are
          0b11;</t>

          <t hangText="Re-mark-DSCP:">re-marks 0b11</dd>
        <dt>Re-mark-DSCP:</dt>
        <dd>re-marks all traffic to one or more particular (non-zero) DSCP values.</t>
        </list></t>
        values</dd>
      </dl>
      <t>These behaviours behaviors are explained in the following subsections and
      cross-referenced in the remainder of the document.</t>
      <t> The network nodes forming a particular path might or might not have
      supported DiffServ. Diffserv.  It is not generally possible for an external
      observer to determine which mechanism results in a specific re-marking
      solely from the change in an observed DSCP value.</t>
      <t>NOTE: More than one mechanism could result in the same DSCP
      re-marking (see below). These behaviors were measured on both IPv4 and
      IPv6 Internet paths between 2017 and 2021<xref target="Cus17"></xref>. 2021 <xref target="Cus17"/>.
      IPv6 routers were found to perform all the types of re-marking described
      above to a lesser extent than IPv4 ones.</t>
      <section anchor="Bleaching" title="Bleaching anchor="Bleaching">
        <name>Bleaching the DSCP Field"> Field</name>
        <t>A specific form of re-marking occurs when the DiffServ Diffserv field is
        re-assigned to the default treatment, treatment: CS0 (0x00). This results in
        traffic being forwarded using the BE PHB. For example, AF31 (0x1a)
        would be bleached to CS0.</t>
        <t>A survey reported that resetting all the bits of the DiffServ Diffserv field
        to 0 was seen to be more prevalent at the edge of the network, network and
        rather less common in core networks <xref target="Cus17"></xref>.</t> target="Cus17"/>.</t>
      </section>

      <section title="IP
      <section>
        <name>IP Type of Service manipulations"> Manipulations</name>
        <t>The IETF first defined ToS precedence for IP packets in <xref
        target="RFC0791"></xref>,
        target="RFC0791"/> and updated it to be part of the ToS Field field in
        <xref target="RFC1349"></xref>. target="RFC1349"/>. Since 1998, this practice has been
        deprecated by <xref target="RFC2474"></xref>.
        RFC 2474 target="RFC2474"/>.  <xref target="RFC2474"/>
        defines DSCPs 0bxxx000 as the Class Selector codepoints, where PHBs
        selected by these codepoints MUST <bcp14>MUST</bcp14> meet the
        Class "Class
        Selector PHB Requirements" described in Sec. 4.2.2.2 of that
        RFC.</t>

        <t>However, a <xref target="RFC2474"
        sectionFormat="of" section="4.2.2.2"/>.</t>
        <t>A recent survey reports practices based on ToS semantics
        have not yet been eliminated from the Internet, Internet and need to still be
        considered when making new DSCP assignments <xref target="Cus17"></xref>.</t>
        target="Cus17"/>.</t>
        <section title="Impact anchor="tos-prec-bleach-impact">
          <name>Impact of ToS Precedence Bleaching "> Bleaching</name>
          <t>Bleaching of the ToS Precedence field (<xref target="observed-re-marking">Bleach-ToS-Precedence</xref>) (see <xref
          target="observed-re-marking"/>) resets
          the first three bits of the DSCP field to zero (the former ToS
          Precedence field), leaving the last three bits unchanged (see Section
          4.2.1 of <xref target="RFC2474"></xref>).
          target="RFC2474" sectionFormat="of" section="4.2.1"/>). A DiffServ Diffserv
          node can be configured in a way that results in this
          re-marking. This re-marking can also occur when packets are
          processed by a router that is not configured with DiffServ Diffserv (e.g.,
          configured to operate on the former ToS precedence Precedence field <xref target="RFC0791"></xref>).
          target="RFC0791"/>). At the time of writing, this is a common
          manipulation of the DiffServ Diffserv field. The following Figure depicts
          this re-marking.</t>

          <figure>
            <preamble></preamble>

<figure anchor="fig2">
<name>Bits in the Diffserv Field Modified by Bleaching of the ToS Precedence</name>
<artwork><![CDATA[
+-+-+-+-+-+-+
|5|4|3|2|1|0|
+-+-+-+-+-+-+
|0 0 0|x x x|
+-+-+-+-+-+-+
]]></artwork>
            <postamble>Figure showing
</figure>

          <t><xref target="fig2"/> shows bleaching of the ToS Precedence (<xref target="observed-re-marking">Bleach-ToS-Precedence</xref>), (see
          <xref target="observed-re-marking"/>), based on Section 3 of <xref target="RFC1349"></xref>.
          target="RFC1349" sectionFormat="of" section="3"/>. The bit positions
          marked "x" 'x' are not changed.</postamble>
          </figure>

          <t></t>

          <figure>
            <preamble></preamble>

            <artwork><![CDATA[
  +--------+------+---------+----+---------+----+---------+----+
  | 56/CS7 | 57   | 58      | 59 | 60      | 61 | 62      | 63 |
  +--------+------+---------+----+---------+----+---------+----+
  | 48/CS6 | 49   | 50      | 51 | 52      | 53 | 54      | 55 |
  +--------+------+---------+----+---------+----+---------+----+
  | 40/CS5 | 41   | 42      | 43 | 44/VA   | 45 | 46/EF   | 47 |
  +--------+------+---------+----+---------+----+---------+----+
  | 32/CS4 | 33   | 34/AF41 | 35 | 36/AF42 | 37 | 38/AF43 | 39 |
  +--------+------+---------+----+---------+----+---------+----+
  | 24/CS3 | 25   | 26/AF31 | 27 | 28/AF32 | 29 | 30/AF33 | 31 |
  +--------+------+---------+----+---------+----+---------+----+
  | 16/CS2 | 17   | 18/AF21 | 19 | 20/AF22 | 21 | 22/AF23 | 23 |
  +--------+------+---------+----+---------+----+---------+----+
  | 8/CS1  | 9    | 10/AF11 | 11 | 12/AF12 | 13 | 14/AF13 | 15 |
  +========+======+=========+====+=========+====+=========+====+
  | 0/CS0  | 1/LE | 2       | 3  | 4       | 5  | 6       | 7  |
  +========+======+=========+====+=========+====+=========+====+

]]></artwork>

            <postamble>Table of DSCP values. As changed.</t>

<table anchor="table3" align="center">
<name>DSCP Values</name>
  <tbody>
    <tr>
      <td>56/CS7</td>
      <td>57</td>
      <td>58</td>
      <td>59</td>
      <td>60</td>
      <td>61</td>
      <td>62</td>
      <td>63</td>
    </tr>
    <tr>
      <td>48/CS6</td>
      <td>49</td>
      <td>50</td>
      <td>51</td>
      <td>52</td>
      <td>53</td>
      <td>54</td>
      <td>55</td>
    </tr>
    <tr>
      <td>40/CS5</td>
      <td>41</td>
      <td>42</td>
      <td>43</td>
      <td>44/VA</td>
      <td>45</td>
      <td>46/EF</td>
      <td>47</td>
    </tr>
    <tr>
      <td>32/CS4</td>
      <td>33</td>
      <td>34/AF41</td>
      <td>35</td>
      <td>36/AF42</td>
      <td>37</td>
      <td>38/AF43</td>
      <td>39</td>
    </tr>
    <tr>
      <td>24/CS3</td>
      <td>25</td>
      <td>26/AF31</td>
      <td>27</td>
      <td>28/AF32</td>
      <td>29</td>
      <td>30/AF33</td>
      <td>31</td>
    </tr>
    <tr>
      <td>16/CS2</td>
      <td>17</td>
      <td>18/AF21</td>
      <td>19</td>
      <td>20/AF22</td>
      <td>21</td>
      <td>22/AF23</td>
      <td>23</td>
    </tr>
    <tr>
      <td>8/CS1</td>
      <td>9</td>
      <td>10/AF11</td>
      <td>11</td>
      <td>12/AF12</td>
      <td>13</td>
      <td>14/AF13</td>
      <td>15</td>
    </tr>
  </tbody>
  <tfoot>
    <tr>
      <th>0/CS0</th>
      <th>1/LE</th>
      <th>2</th>
      <th>3</th>
      <th>4</th>
      <th>5</th>
      <th>6</th>
      <th>7</th>
    </tr>
  </tfoot>
</table>

          <t>As a result of ToS Precedence Bleaching, each of the DSCPs in a
          column are re-marked to the smallest DSCP in that column.
          Therefore, the DSCPs in the bottom row have higher survivability
          across an end-to-end Internet path.
            </postamble>
          </figure>
          </t>
          <t>Data on the observed re-marking at the time of writing was
          presented in <xref target="IETF115-IEPG"></xref>.</t>

          <figure>
            <preamble></preamble>

            <artwork><![CDATA[

+=======+======+=============+====+======+===+=========+====+
| 0/CS0 | 1/LE | 2           | 3  | target="IETF115-IEPG"/>.</t>

<table anchor="table4" align="center">
<name>0b000xxx DSCPs</name>
  <thead>
    <tr>
      <th>0/&wj;CS0</th>
      <th>1/&wj;LE</th>
      <th>2</th>
      <th>3</th>
      <th>4</th>
      <th>5</th>
      <th>6</th>
      <th>7</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td rowspan="1" colspan="2">Assigned</td>
      <td>Re-marked from AF11..41</td>
      <td>EXP/LU</td>
      <td>*</td>
      <td></td>
      <td>Re-marked from AF13..EF</td>
      <td>EXP/LU</td>
    </tr>
  </tbody>
</table>

<dl spacing="normal" newline="false">
  <dt>*</dt>
  <dd>DSCP 4    | 5 | 6       | 7  |
+=======+======+=============+====+======+===+=========+====+
|Assigned      |Re-marked    |EXP/| *    |   |Re-marked|EXP/|
|              |from AF11..41|LU  |      |   |from     |LU  |
|              |             |    |      |   |AF13..EF |    |
+==============+=============+====+======+===+=========+====+
]]></artwork>

            <postamble>Table showing has been historically used by the SSH application <xref
  target="Kol10"/></dd>
</dl>

          <t><xref target="table4"/> shows 0b000xxx DSCPs. This highlights
          any current assignments and whether they are affected by any known
          re-marking behaviors, such as ToS Precdence bleaching.
	* DSCP 4 has been historically used by the SSH application<xref target="Kol10">.</xref>.
            </postamble>
          </figure>

          <t></t> Precedence Bleaching.</t>

          <t>DSCPs of the form 0b000xxx can be impacted by known re-marking behaviours
          behaviors of other assigned DSCPs.  For example, ToS Precedence
          Bleaching of popular DSCPs AF11, AF21, AF31, and AF41 would result in
          traffic being re-marked with DSCP 2 in the Internet core.  The Lower-Effort
          Lower Effort (LE) Per-Hop Behavior PHB (LE) uses a DSCP of 1. The DSCP
          value of 4 has been historically used by the SSH application,
          following semantics that precede DiffServ Diffserv <xref target="Kol10"></xref>.</t>

          <t><xref target="observed-re-marking"> Bleach-ToS-Precedence </xref>
          target="Kol10"/>.</t>

          <t>Bleach-ToS-Precedence (see <xref target="observed-re-marking"/>)
          of packets with a DSCP 'x' result results in the DSCP being re-marked to 'x'
          &amp; 0x07 and then forwarded using the PHB specified for the
          resulting DSCP in that Diffserv domain.  In subsequent networks networks, the
          packet will receive treatment as specified by the domain's operator
          corresponding to the re-marked codepoint.</t>
          <t>A variation of this observed re-marking behavior clears the top
          three bits of a DSCP, unless these have values 0b110 or 0b111
          (corresponding to the CS6 and CS7 DSCPs). As a result, a DSCP value
          greater than 48 decimal (0x30) is less likely to be impacted by ToS
          Precedence Bleaching.</t>
        </section>

        <section title="Impact
        <section>
          <name>Impact of ToS Precedence Re-marking"> Re-marking</name>
          <t><xref target="RFC2474"></xref> states "Implementors target="RFC2474"/> states:</t>
	  <blockquote>Implementors should note that the DSCP field is six bits
	  wide. DS-compliant nodes MUST <bcp14>MUST</bcp14> select PHBs by matching
	  against the entire 6-bit DSCP field, e.g., by treating the value of
	  the field as a table index which is used to select a particular
	  packet handling mechanism which has been implemented in that device". This
	  device.</blockquote>

	  <t>This replaced re-marking according to ToS precedence (<xref target="observed-re-marking">Re-mark-ToS</xref>) (see <xref
	  target="observed-re-marking"/>) <xref target="RFC1349"></xref>. target="RFC1349"/>. These
	  practices based on ToS semantics have not yet been eliminated from
	  deployed networks.</t>

          <figure>
            <preamble></preamble>

<figure anchor="fig3">
<name>Bits in the Diffserv Field Modified by ToS Precedence Re-marking</name>
<artwork><![CDATA[
+-+-+-+-+-+-+
|5|4|3|2|1|0|
+-+-+-+-+-+-+
|0 0 1|x x x|
+-+-+-+-+-+-+
]]></artwork>

            <postamble>Figure showing
</figure>

          <t><xref target="fig3"/> shows the ToS Precedence Re-marking (<xref target="observed-re-marking">Re-mark-ToS</xref>)
          (see <xref target="observed-re-marking"/>) observed
          behavior, based on Section 3 of <xref
            target="RFC1349"></xref>. target="RFC1349" sectionFormat="of"
          section="3"/>. The bit positions marked "x" 'x' remain unchanged.</postamble>

          </figure> unchanged.</t>
          <t>A less common re-marking, ToS Precedence Re-marking sets the
          first three bits of the DSCP to a non-zero value corresponding to a
          CS PHB. This re-marking occurs when routers are not configured to
          perform DiffServ Diffserv re-marking.
          </t>
          <t>If ToS Precedence Re-marking occurs, packets are forwarded using
          the PHB specified for the resulting DSCP in that domain.  For
          example, the AF31 DSCP (0x1a) could be re-marked to either AF11 or
          AF21.  If such a re-marked packet further traverses other Diffserv
          domains, it would receive treatment as specified by each domain's
          operator corresponding to the re-marked codepoint.</t>
        </section>
      </section>
      <section anchor="re-mark" title="Re-marking anchor="re-mark">
        <name>Re-marking to a Particular DSCP"> DSCP</name>
        <t>A network device might re-mark the DiffServ Diffserv field of an IP packet
        based on a local policy with a specific (set of) DSCPs (<xref target="observed-re-marking"> Re-mark-DSCP </xref>).
        </t>

        <t>
	Section 3 set of DSCPs (see <xref target="RFC2474"></xref>
        target="observed-re-marking"/>).
        </t>
        <t><xref target="RFC2474" sectionFormat="of" section="3"/> recommends:
        "Packets received with an unrecognized codepoint SHOULD <bcp14>SHOULD</bcp14>
        be forwarded as if they were marked for the Default behavior, and
        their codepoints should not be changed."  Some networks might not
        follow this recommendation and instead re-mark packets with these
        codepoints to the default class, class: CS0 (0x00).  This re-marking is
        sometimes performed using a Multi-Field (MF) classifier <xref
        target="RFC2475"></xref>
        target="RFC2475"/> <xref target="RFC3290"></xref> target="RFC3290"/> <xref
        target="RFC4594"></xref>. target="RFC4594"/>.
        </t>
        <t>
        If re-marking occurs, packets are forwarded using the PHB specified
        for the resulting DSCP in that domain.  As an example, re-marking
        traffic AF31, AF32 AF32, and AF33 all to a single DSCP, e.g. e.g., AF11, stops
        any drop probability differentiation, which may have been expressed by
        these three DSCPs. If such a re-marked packet further traverses other
        domains, it would receive treatment as specified by the domain's
        operator corresponding to the re-marked codepoint. Bleaching
        (<xref target="observed-re-marking">Bleach-DSCP</xref>) (see
        <xref target="observed-re-marking"/>) is a specific example of this
        observed re-marking behavior that re-marks to CS0 (0x00) - see (see <xref target="Bleaching"></xref>.</t>
        target="Bleaching"/>).</t>
      </section>
    </section>
    <section anchor="lowerlayers" title="Interpretation anchor="lowerlayers">
      <name>Interpretation of the IP DSCP at Lower Layers"> Layers</name>
      <t>Transmission systems and subnetworks can, and do, utilize the
      DiffServ
      Diffserv field in an IP packet to set a QoS-related field or function at
      the lower layer.  A lower layer could also implement a traffic conditioning
      traffic-conditioning function that could re-mark the DSCP used at the IP
      layer.  This function is constrained by designs that utilize fewer than
      6 bits to express the service class, and therefore class and, therefore, infer a mapping to a
      smaller L2 QoS field, for example, the 3-bit PCP Priority Code Point (PCP) field in an IEEE
      Ethernet 802.1Q header, the 3-bit UP field User Priority (UP) field, or the 3-bit Traffic Class
      field of Multi-Protocol Label Switching (MPLS).  A Treatment Aggregate
      (TA) <xref target="RFC5127"></xref> target="RFC5127"/> is an optional intermediary mapping groups group
      of BAs to PHBs.
      </t>

     <section title="Mapping
      <section>
        <name>Mapping Specified for IEEE 802"> 802</name>
        <t>The IEEE specifies standards that include mappings for DSCPs to
        lower layer elements.</t>

       <section title="Mapping
        <section>
          <name>Mapping Specified for IEEE 802.1"> 802.1</name>
          <t>IEEE 802.1Q specified a 3-bit Priority Code Point (PCP) PCP field, which includes a tag
          that allows Ethernet frames to be marked as one of eight priority
          values <xref
        target="IEEE-802-1Q"></xref>. target="IEEE-802.1Q"/>. Use of this field is
          described by various documents, including IEEE P802.1p, P802.1p and IEEE
          802.1D.</t>
          <t>The mapping specified in <xref target="IEEE-802-1Q"></xref> target="IEEE-802.1Q"/>
          revises a previous standard standard, <xref target="IEEE-802-1D"></xref>, target="IEEE-802.1D"/>, in
          an effort to align with DiffServ Diffserv practice <xref target="RFC4594"></xref>. target="RFC4594"/>.
          In 802.1Q, the traffic types are specified to match the first three
          bits of a suitable DSCP (e.g., the first three bits of the EF Expedited Forwarding (EF) DSCP
          are mapped to a PCP of 5).</t> <t> In this mapping, PCP0 is used to
          indicate the default
        best effort Best Effort treatment, and PCP1 indicates a
          background traffic class. This aligned with the now deprecated use of
	CS1 as the codepoint for the lower effort
	service, as previously specified in <xref target="RFC4594"></xref>.  The remaining PCP values
          indicate increasing priority.  Internet control traffic can be
          marked as CS6, and network control is marked as CS7.</t>
          <t>Other re-marking behaviors have also been implemented in Ethernet
          equipment.  Historically, a previous standard standard, <xref target="IEEE-802-1D"></xref>
          target="IEEE-802.1D"/>, used both PCP1 (Background) and PCP2
          (Spare) to indicate lower priority than PCP0, and some other devices
          do not assign a lower priority to PCP1.</t>
        </section>
        <section title="Mapping anchor="mapping_for_802.11">
          <name>Mapping Specified for IEEE 802.11">

        <t>Section 6 of <xref target="RFC8325"></xref> 802.11</name>
          <t><xref target="RFC8325" sectionFormat="of" section="6"/> provides
          a brief overview of IEEE 802.11 QoS. The IEEE <xref
        target="IEEE-802-11">802.11
          target="IEEE-802.11">802.11 standards</xref> provide MAC Media
          Access Control (MAC) functions to support QoS in WLANs using Access Classes (AC).
          Categories (ACs). The upstream User
        Priority (UP) UP in the 802.11 header has a 3-bit QoS
          value. A DSCP can be mapped to the UP. <xref target="RFC8622"></xref> target="RFC8622"/>
          added a mapping for the LE DSCP, mapping this DSCP to
          AC_BK (Background)</t> (Background).</t>
          <t>Most current Wi-Fi implementations use a default mapping that
          maps the first three bits of the DSCP to the 802.11 UP value. This
          is an example of equipment still classifying on ToS Precedence
          (which could be seen as a simple method to map IP layer DiffServ Diffserv to
          layers offering only 3-bit QoS codepoints). Then, in turn, this is
          mapped to the four Wi-Fi Multimedia (WMM) Access Categories. The
          Wi-Fi Alliance has also specified a more flexible mapping that
          follows RFC8325 <xref target="RFC8325"/> and provides functions at an AP Access
          Point (AP) to re-mark packets as well as a QoS Map that maps each
          DSCP to an AC <xref target="WIFI-ALLIANCE"></xref>.</t>

       <figure>
          <preamble></preamble> target="WIFI-ALLIANCE"/>.</t>

<figure anchor="fig4">
<name>DSCP Bits Commonly Mapped to the UP in 802.11</name>
<artwork><![CDATA[
+-+-+-+-+-+-+
|5|4|3|2|1|0|
+-+-+-+-+-+-+
|x x x|. . .|
+-+-+-+-+-+-+
]]></artwork>

          <postamble>Figure showing the DSCP bits commonly mapped to the UP in
          802.11. The
</figure>

<t>The bit positions marked "x" 'x' are mapped
to the 3-bit UP value, while the ones marked "." '.' are ignored.</postamble>
        </figure>

        <t></t> ignored.</t>

          <t><xref target="RFC8325">RFC8325</xref> target="RFC8325"/> notes inconsistencies that
          can result from such re-marking, re-marking and recommends a different mapping
          to perform this re-marking, dependent on the direction in which a
          packet is forwarded.  It provides recommendations for mapping a DSCP
          to an IEEE 802.11 UP for interconnection between wired and wireless
          networks.  The recommendation in Section 5.1.2 <xref target="mapping_for_802.11"/> maps network control
          traffic, CS6 and CS7, as well as unassigned DSCPs, to UP 0 when
          forwarding in the upstream direction (wireless-to-wired).  It also
          recommends mapping CS6 and CS7 traffic to UP 7, 7 when forwarding in
          the downstream direction (Section 4.1).</t> (<xref target="RFC8325" sectionFormat="of" section="4.1"/>).</t>
          <t>For other UPs, RFC8325 <xref target="RFC8325"/> recommends a mapping in
          the upstream direction (wireless-to-wired interconnections) that derives the DSCP from the value of the
          UP multiplied by 8.  This mapping mapping, currently used by
          some Access Points (APs), can result in a specific DSCP re-marking behavior.</t>
        <t>In the upstream direction (wireless-to-wired interconnections),
	this mapping can result in a specific behavior:</t>

	  <blockquote>wherein DSCP re-marking behavior.
        Some Access Points (APs) currently use a
        default UP-to-DSCP mapping <xref target="RFC8325"></xref>,
        wherein "DSCP values are derived from the layer 2 UP values by
	  multiplying the UP values by eight 8 (i.e., shifting the three UP bits to
	  the left and adding three additional zeros to generate a 6-bit DSCP
	  value).  This derived DSCP value is then used for QoS treatment
	  between the wireless AP and the nearest classification and marking
	  policy enforcement point (which may be a central the centralized wireless LAN
	  controller, relatively deep within the network).  Alternatively, in
	  the case where there is no other classification and marking policy
	  enforcement point, then this derived DSCP value will be used on the
	  remainder of the Internet path." This path.</blockquote>

	  <t>This can result in re-marking by Bleach-low (see <xref target="observed-re-marking">Bleach-low</xref>.</t>

        <figure>
          <preamble></preamble>
	  target="observed-re-marking"/>).</t>

<figure anchor="fig5">
<name>Bits in the Diffserv Field Modified by Re-marking Observed as a Result of UP-to-DSCP Mapping in Some 802.11 Networks</name>
<artwork><![CDATA[
+-+-+-+-+-+-+
|5|4|3|2|1|0|
+-+-+-+-+-+-+
|x x x|0 0 0|
+-+-+-+-+-+-+
]]></artwork>

          <postamble>Figure showing the observed re-marking behavior resulting from deriving from UP-to-DSCP mapping in some
         802.11 networks.</postamble>
</figure>

          <t>An alternative to UP-to-DSCP remapping uses the DSCP value of a
          downstream IP packet (e.g., the Control And and Provisioning of Wireless
          Access Points (CAPWAP) protocol, Points, CAPWAP, protocol <xref target="RFC5415">RFC5415</xref>, target="RFC5415"/> maps an IP
          packet DiffServ Diffserv field to the
	DiffServ Diffserv field of the outer IP header
          in a CAPWAP tunnel).</t>
          <t>Some current constraints of Wi-Fi mapping are discussed in Section 2
        of <xref target="RFC8325"></xref>.
          target="RFC8325" sectionFormat="of" section="2"/>. A QoS profile can
          be used to limit the maximum DSCP value used for the upstream and
          downstream traffic.</t>
        </section>
      </section>
      <section anchor="mpls" title="DiffServ anchor="mpls">
        <name>Diffserv and MPLS"> MPLS</name>
        <t>Multi-Protocol Label Switching (MPLS) specified eight MPLS Traffic
        Classes (TCs), which restrict the number of different treatments <xref target="RFC5129"></xref>.  RFC 5127
        target="RFC5129"/>.  <xref target="RFC5127"/> describes the
        aggregation of
   DiffServ TCs <xref target="RFC5127"></xref> Diffserv service classes and introduces four DiffServ Treatment Aggregates. Diffserv TAs.  Traffic
        marked with multiple DSCPs can be forwarded in a single MPLS TC.</t>
        <t>There are three Label-Switched Label Switching Router (LSR) models: the Pipe, the
        Short Pipe Pipe, and the Uniform Model <xref target="RFC3270"></xref>. target="RFC3270"/>.  In the
        Uniform and Pipe models, the egress MPLS router forwards traffic based
        on the received MPLS TC. The Uniform Model includes an egress DSCP
        rewrite. With the Short Pipe Model, the egress MPLS router forwards
        traffic based on the DiffServ Diffserv DSCP as present at the egress router. If
        the domain supports IP and MPLS QoS differentiation, controlled
        behavior requires the DSCP of an (outer) IP header to be assigned or
        re-written by all domain ingress routers to conform with the domain's
        internal DiffServ Diffserv deployment.  Note that the Short Pipe Model is
        prevalent in MPLS domains.
        </t>

        <section title="Mapping
        <section>
          <name>Mapping Specified for MPLS"> MPLS</name>
          <t><xref target="RFC3270">RFC3270</xref> target="RFC3270"/> defines a flexible solution
          for support of DiffServ Diffserv over MPLS networks. This allows an MPLS
          network administrator to select how BAs (marked by DSCPs) are mapped
          onto Label Switched Paths (LSPs) to best match the DiffServ, Diffserv, Traffic
          Engineering
          Engineering, and protection objectives within their particular
          network.</t>
          <t>Mappings from the IP DSCP to the MPLS header are defined in
          Section 4.2 of
          <xref target="RFC3270"></xref>.</t> target="RFC3270" sectionFormat="of" section="4.2"/>.</t>
          <t>The Pipe Model conveys the "LSP Diff-Serv Information"
          to the LSP Egress so that its forwarding treatment can be based on
          the IP DSCP.</t>
          <t>When Penultimate Hop Popping (PHP) is used, the Penultimate LSR
          needs to be aware of the encapsulation mapping for a PHB to the
          label corresponding to the exposed header to perform DiffServ Diffserv
          Information Encoding (Section 2.5.2 of <xref
          target="RFC3270"></xref>).</t> (<xref target="RFC3270" sectionFormat="of"
          section="2.5.2"/>).</t>
        </section>

        <section title="Mapping
        <section>
          <name>Mapping Specified for MPLS Short Pipe"> Pipe</name>
          <t>The Short Pipe Model is an optional variation of the Pipe Model
          <xref target="RFC3270"></xref>.</t>

          <t>ITU-T <xref target="ITU-T-Y-1566">Y.1566</xref> target="RFC3270"/>.</t>
          <t><xref target="ITU-T-Y.1566">ITU-T Y.1566</xref> further defined a
          set of four common QoS classes and four auxiliary classes to which a
          DSCP can be mapped when interconnecting Ethernet, IP IP, and MPLS
          networks. <xref target="RFC8100"></xref> target="RFC8100"/> describes four
          treatment aggregates
          TAs for interconnection with four defined DSCPs.
          This was motivated by the requirements of MPLS network operators
          that use Short-Pipe tunnels, Short Pipe tunnels but can be applicable to other
          networks, both MPLS and non-MPLS.</t>

	  <t>RFC8100
          <t><xref target="RFC8100"/> recommends preserving the notion of
          end-to-end service
          classes, classes and recommends a set of standard DSCPs
          mapped to a small set of standard PHBs at interconnection.  The key
          requirement is that the DSCP at the network ingress is restored at
          the network egress.  The current version of
         RFC8100 <xref target="RFC8100"/>
          limits the number of DSCPs to 6 6, and 3 more are suggested for
          extension.
         RFC8100  <xref target="RFC8100"/> respects the deployment of PHB
          groups for DS domain internal domain-internal use, which limits the number of
          acceptable external DSCPs (and possibilities for their transparent
          transport or restoration at network boundaries).  In this design,
          packets marked with DSCPs not part of the RFC8100 codepoint scheme <xref
          target="RFC8100"/> are treated as unexpected and will possibly be
          re-marked (a Re-mark-DSCP, see <xref target="observed-re-marking">Re-mark-DSCP</xref> target="observed-re-marking"/>
          behavior) or dealt with via an additional agreement(s) agreements among the
          operators of the interconnected networks.  RFC8100  <xref target="RFC8100"/>
          can be extended to support up to 32 DSCPs by future standards. RFC8100 <xref
          target="RFC8100"/> is operated by at least one Tier 1 backbone
          provider.  Use of the MPLS Short Pipe Model favours favors re-marking
          unexpected DSCP values to zero in the absence of an additional agreement(s),
          agreements, as explained in <xref
         target="RFC8100"></xref>. target="RFC8100"/>. This can
          result in bleaching (<xref target="observed-re-marking">Bleach-DSCP</xref>). (see <xref target="observed-re-marking"/>).
          </t>

          <figure>
            <preamble></preamble>

            <artwork><![CDATA[
+--------------------------------------+--------+
|  RFC8100                             |  DSCP  |
|  Agg. Class                          |        |
+--------------------------------------+--------+
|Telephony Service Treatment

<table anchor="table5" align="center">
  <name>The Short Pipe MPLS Mapping from <xref target="RFC8100"/></name>
  <thead>
    <tr>
      <th>Treatment Aggregate |   EF   |
|                                      |   VA   |
+--------------------------------------+--------+
|Bulk <xref target="RFC8100"/></th>
      <th align="center">DSCP</th>
    </tr>
  </thead>
    <tbody>
    <tr>
      <td>Telephony&nbsp;Service&nbsp;Treatment&nbsp;Aggregate</td>
      <td align="center">EF<br/>VA</td>
    </tr>
    <tr>
      <td>Bulk Real-Time Treatment Aggregate    |  AF41  |
|                         May be added | (AF42) |
|                         May be added | (AF43) |
+--------------------------------------+--------+
|Assured Aggregate</td>
      <td align="center">AF41<br/>(AF42)*<br/>(AF43)*</td>
    </tr>
    <tr>
      <td>Assured Elastic Treatment Aggregate   |  AF31  |
|                                      |  AF32  |
|    Reserved for the extension of PHBs| (AF33) |
+--------------------------------------+--------+
|Default Aggregate</td>
      <td align="center">AF31<br/>AF32<br/>(AF33)**</td>
    </tr>
    <tr>
      <td>Default / Elastic Treatment Aggregate | BE/CS0 |
+--------------------------------------+--------+
|Network Aggregate</td>
      <td align="center">BE/CS0</td>
    </tr>
    <tr>
      <td>Network Control: Local Use (LU)       |  CS6   |
+--------------------------------------+--------+

]]></artwork>

            <postamble>Table: The short-pipe MPLS mapping from RFC
            8100.</postamble>
          </figure> (LU)</td>
      <td align="center">CS6</td>
    </tr>
  </tbody>
</table>

        <dl spacing="normal" newline="false">
	    <dt>*</dt>
	    <dd>May be added</dd>
	    <dt>**</dt>
	    <dd>Reserved for the extension of PHBs</dd>
	</dl>

        </section>
      </section>

      <section title="Mapping
      <section>
        <name>Mapping Specified for Mobile Networks"> Networks</name>
        <t>Mobile LTE and 5G standards have evolved from older UMTS standards, Universal
        Mobile Telecommunications System (UMTS) standards and support DiffServ.
        Diffserv. LTE (4G) and 5G standards <xref
        target="SA-5G"></xref> target="SA-5G"/> identify
        traffic classes at the interface between User Equipment (UE) and the
        mobile Packet Core network by QCI (QoS Class Identifiers) and 5QI (5G
        QoS Identifier). The 3GPP standards do not define or recommend any
        specific mapping between each QCI or 5QI and DiffServ Diffserv (and mobile QCIs
        are based on several criteria service class definitions). The way
        packets are mapped at the Packet Data Network Gateway (P-GW) boundary
        is determined by network operators. However, TS 23.107 (version
        16.0.0, applies to LTE and below) mandates that Differentiated
        Services, defined by the IETF, shall be used to interoperate with IP
        backbone networks.</t>
        <t>The GSM Association (GSMA) has defined four aggregated classes and
        seven associated PHBs in their guidelines for IPX IP Packet eXchange (IPX) Provider networks
        <xref target="GSMA-IR-34"></xref>. target="GSMA-IR.34"/>.  This was previously specified as the Inter-Service
        "Inter-Service Provider IP Backbone Guidelines, Guidelines" and provides a mobile
        ISP to ISP QoS mapping mechanism, mechanism and interconnection with other IP
        networks in the general Internet. If provided an IP VPN, the operator
        is free to apply its DS Domain internal domain-internal codepoint scheme at outer
        headers and inner IPX DSCPs may be transported transparently.  The
        guidelines also describe a case where the DSCP marking from a Service
        Provider cannot be trusted (depending on the agreement between the
        Service Provider and its IPX Provider), in which situation Provider). In this situation, the IPX
        Provider can re-mark the DSCP value to a static default value.
        </t>

        <t><figure>
            <preamble></preamble>

            <artwork><![CDATA[
+---------------+-------+
|  GSMA IR.34   |  PHB  |
|  Agg. Class   |       |
+---------------+-------+
|Conversational |  EF   |
+---------------+-------+
| Streaming     | AF41  |
+---------------+-------+
| Interactive   | AF31  |
+               +-------+
| (ordered by   | AF32  |
+   priority,   +-------+
| AF3 highest)  | AF21  |
+               +-------+
|               | AF11  |
+---------------+-------+
| Background    | CS0   |
+---------------+-------+

]]></artwork>

            <postamble>Table showing the

<table anchor="table6" align="center">
  <name>The PHB mapping recommended Mapping Recommended in the guidelines recommended Guidelines Recommended in <xref
            target="GSMA-IR-34"></xref>.</postamble>
          </figure></t>

        <t></t>
  target="GSMA-IR.34"/></name>
  <thead>
    <tr>
      <th><t>QoS Class in <xref target="GSMA-IR.34"/></t></th>
      <th>PHB</th>
    </tr>
  </thead>
    <tbody>
    <tr>
      <td>Conversational</td>
      <td>EF</td>
    </tr>
    <tr>
      <td>Streaming</td>
      <td>AF41</td>
    </tr>
    <tr>
      <td rowspan="4"><t>Interactive</t><t>(ordered by priority, AF3 highest)</t></td>
      <td>AF31</td>
    </tr>
    <tr>
      <td>AF32</td>
    </tr>
    <tr>
      <td>AF21</td>
    </tr>
    <tr>
      <td>AF11</td>
    </tr>
    <tr>
      <td>Background</td>
      <td>CS0</td>
    </tr>
  </tbody>
</table>

      </section>

      <section title="Mapping
      <section>
        <name>Mapping Specified for Carrier Ethernet">

        <t>Metro Ethernet Ethernet</name>
        <t>MEF Forum (MEF) provides a mapping of DSCPs at
        the IP layer to quality of service markings in the Ethernet frame
        headers <xref target="MEF23.1"></xref>.</t> target="MEF-23.1"/>.</t>
      </section>

      <section title="Re-marking
      <section>
        <name>Re-marking as a Side-effect Side Effect of Another Policy"> Policy</name>
        <t>This includes any other re-marking that does not happen as a result
        of traffic conditioning, such as policies and L2 procedures that
        result in re-marking traffic as a side-effect side effect of other functions
        (e.g., in response to Distributed Denial of Service, DDoS).</t>
      </section>

      <section title="Summary">
      <section>
        <name>Summary</name>
        <t>This section has discussed the various ways in which DSCP
        re-marking behaviors can arise from interactions with lower
        layers.</t>
        <t> A provider service path may consist of sections where multiple and
        changing layers use their own code points to determine differentiated
        forwarding (e.g., IP - to MPLS - to IP - to Ethernet - to Wi-Fi).</t>
      </section>
    </section>

    <section title="Considerations
    <section>
      <name>Considerations for DSCP Selection"> Selection</name>
      <t>This section provides advice for the assignment of a new DSCP value.
      It is intended to aid the IETF and IESG in considering a request for a
      new DSCP.
      The  This section identifies known issues that might influence the
      finally assigned
      DSCP, DSCP and provides a summary of considerations for
      assignment of a new DSCP.</t>

      <section title="Effect
      <section>
        <name>Effect of Bleaching and Re-marking to a single DSCP">
        <t>Section 4 Single DSCP</name>
        <t><xref target="observed-re-marking"/> describes re-marking of the
        DSCP.  New DSCP assignments should consider the impact of bleaching
  	(<xref target="observed-re-marking">Bleach-DSCP</xref>) or
        re-marking (<xref target="observed-re-marking">Re-mark-DSCP</xref>) (see <xref target="observed-re-marking"/>) to a single
        DSCP, which can limit the ability to provide the expected treatment
        end-to-end.  This is particularly important for cases where the
        codepoint is intended to result in lower than best effort Best Effort treatment,
        as was the case when defining the LE PHB <xref target="RFC8622"></xref>. target="RFC8622"/>.
        Forwarding LE using the default PHB is in line with RFC8622, <xref
        target="RFC8622"/>, but it is recommended to maintain the distinct LE
        DSCP codepoint end-to-end to allow for differentiated treatment by
        domains supporting LE. Rewriting the LE DSCP to the default class
        (CS0) results in an undesired promotion of the priority for LE traffic
        in such a domain.  Bleaching the lower three bits of the DSCP (both <xref target="observed-re-marking">Bleach-low</xref>
        Bleach-low and Bleach-some-low in <xref target="observed-re-marking">Bleach-some-low</xref>),
        target="observed-re-marking"/>), as well as re-marking to a particular
  	 DSCP
        DSCP, can result in similar changes of priority relative to traffic
        that is marked with other DSCPs.
        </t>
      </section>

      <section title="Where
      <section>
        <name>Where the proposed Proposed DSCP &gt; 0x07 (7)"> (7)</name>
	<t>This considers a proposed DSCP with a codepoint larger than 7.</t>
        <t>Although the IETF specifications require systems to use DSCP
        marking semantics in place of methods based on the former ToS field,
        the current recommendation is that any new assignment where the DSCP
        is greater than 0x07 should consider the semantics associated with the
        resulting DSCP when the ToS Precedence is bleached (<xref target="observed-re-marking">Bleach-ToS-Precedence</xref>
        (Bleach-ToS-Precedence and Bleach-some-ToS, <xref target="observed-re-marking"> Bleach-some-ToS </xref>)
        target="observed-re-marking"/>) or ToS Precedence Re-marking (<xref target="observed-re-marking">Re-mark-ToS</xref>)
        (Re-mark-ToS, <xref target="observed-re-marking"/>) is experienced. For
        example, it can be desirable to avoid choosing a DSCP that could be
        re-marked to LE, <xref target="RFC8622">Lower Effort</xref>, which
        could otherwise potentially result in a priority inversion in the
        treatment.</t>
	 <section title="Where

        <section>
          <name>Where the Proposed DSCP&amp;0x07=0x01</name>
	  <t>This considers a proposed DSCP&amp;0x07=0x01"> DSCP where the least significant 3 bits together represent a value of 1 (i.e., 0b001).</t>
          <t>As a consequence of assigning the LE PHB <xref
          target="RFC8622"></xref>,
          target="RFC8622"/>, the IETF allocated the DSCP 0b000001 from Pool
          3.</t>
          <t>When making assignments where the DSCP has a format: 0bxxx001, format "0bxxx001",
          the case of <xref target="observed-re-marking">Bleach-ToS-Precedence</xref> Bleach-ToS-Precedence (<xref
          target="observed-re-marking"/>) of a DSCP to a value of 0x01 needs
          to be considered. ToS Precedence Bleaching will result in demoting
          the traffic to the lower effort
          traffic class. Lower Effort PHB. Care should be taken
          to consider the implications of re-marking when choosing to assign a
          DSCP with this format.</t>
        </section>
      </section>

      <section title="Where
      <section>
        <name>Where the proposed Proposed DSCP &lt;= 0x07 (7)"> (7)</name>
	<t>This considers a proposed DSCP where the DSCP is less than or equal to 7.</t>
        <t>ToS Precedence Bleaching or ToS Precedence Re-marking can
        unintentionally result in extra traffic aggregated to the same
        DSCP. For example, after experiencing ToS Precedence Bleaching, all
        traffic marked AF11, AF21, AF31 AF31, and AF41 would be aggregated with
        traffic marked with DSCP 2 (0x02), increasing the volume of traffic which
        that receives the treatment associated with DSCP 2.  New DSCP
        assignments should consider unexpected consequences arising from this
        observed re-marking behavior.</t>
      </section>
      <section anchor= "networks" title="Impact anchor="networks">
        <name>Impact on deployed infrastructure"> Deployed Infrastructure</name>
        <t>Behavior of deployed PHBs and conditioning treatments also needs to
        be considered when assigning a new DSCP. Network operators have
        choices when it comes to configuring DiffServ Diffserv support within their
        domains, and the observed re-marking behaviors described in the
        previous section can result from different configurations and
        approaches:</t>
        <t><list style="hanging">
            <t hangText="Networks
        <dl newline="true" spacing="normal">
          <dt>Networks not re-marking DiffServ:"> A Diffserv:</dt>
          <dd>A network that either does not implement PHBs, PHBs or implements one
          or more PHBs whilst while restoring the DSCP field at network egress with
          the value at network ingress. Operators in this category pass all
          DSCPs transparently.</t>
            <t hangText="Networks transparently.</dd>
          <dt>Networks that condition the DSCP:"> A DSCP:</dt>
          <dd>A network that implements more than one PHB and enforces Service
          Level Agreements (SLAs) with its peers. Operators in this category
          use conditioning to ensure that only traffic that matches a policy
          is permitted to use a specific DSCP (see <xref target="RFC8100"></xref>). target="RFC8100"/>).
          Operators need to classify the received traffic, assign it to a
          corresponding PHB, and could re-mark the DSCP to a value that is
          appropriate for the domain's deployed DiffServ infrastructure.</t>
            <t hangText="Networks Diffserv infrastructure.</dd>
          <dt>Networks that re-mark in some other way, which includes:">
            </t>
                <t><list style='numbers'>
                <t>Networks includes:</dt>
          <dd>
            <ol spacing="normal" type="1">
	      <li>Networks containing misconfigured devices that do not comply
	      with the relevant RFCs.</t>
                <t>Networks RFCs.</li>
              <li>Networks containing devices that implement an obsolete
              specification or contain software bugs.</t>
                <t>Networks bugs.</li>
              <li>Networks containing devices that re-mark the DSCP as a
              result of lower layer interactions.</t>
		</list></t>
       </list></t> interactions.</li>
            </ol>
          </dd>
        </dl>
        <t> The DSCP re-marking corresponding to the <xref target="observed-re-marking">Bleach-ToS-Precedence</xref> Bleach-ToS-Precedence
        (<xref target="observed-re-marking"/>)
        observed behavior described in Section 4 can arise for various reasons, one of which is old
        equipment which that precedes DiffServ. Diffserv.  The same re-marking can also arise
        in some cases when traffic conditioning is provided by DiffServ Diffserv
        routers at operator boundaries or as a result of misconfiguration.
        </t>
      </section>

      <section title="Considerations
      <section>
        <name>Considerations to guide Guide the discussion Discussion of a proposed new DSCP"> Proposed New
        DSCP</name>
        <t>A series of questions emerge that need to be answered when
        considering a proposal to the IETF that requests a new assignment.
        These questions include:</t>

        <t><list style="symbols">
            <t>Is
        <ul spacing="normal">
          <li>Is the request for local use Local Use within a DiffServ Diffserv domain that does
          not require interconnection with other DiffServ Diffserv domains? This
          request can use DSCPs in Pool 2 for local Local or
            experimental use, Experimental Use,
          without any IETF specification for the DSCP or associated PHB.</t>

	    <t>What PHB.</li>
          <li>What are the characteristics of the proposed service class?: class?
          What are the characteristics of the traffic to be carried? What are
          the expectations for treatment? </t>

            <t>Service </li>
          <li>Service classes <xref target="RFC4594"></xref> target="RFC4594"/> that can utilize
          existing PHBs should use assigned DSCPs to mark their traffic: Could
          the request be met by using an existing IETF DSCP?</t>

   	   <t>Specification DSCP?</li>
          <li>Specification of a new recommended DSCP requires Standards
          Action.
        RFC2474  <xref target="RFC2474"/> states: "Each standardized PHB MUST
          <bcp14>MUST</bcp14> have an associated
        RECOMMENDED <bcp14>RECOMMENDED</bcp14>
          codepoint". If approved, new IETF assignments are normally made by
          IANA in Pool 1, but the IETF can request assignments to be made from
          Pool 3 <xref target="RFC8436"></xref>. target="RFC8436"/>.  Does the Internet Draft contain an
          appropriate request to IANA?</t>

            <t>The IANA?</li>
          <li>The value selected for a new DSCP can impact the ability of an
          operator to apply logical functions (e.g., a bitwise mask) to
          related codepoints when configuring DiffServ. Diffserv.  A suitable value can
          simplify configurations by aggregating classification on a range of
          DSCPs. This classification based on DSCP ranges can increase the
          comprehensibility of documenting forwarding differentiation.</t>
	     <t> differentiation.</li>
          <li> <xref target="mpls"></xref> target="mpls"/> describes examples of treatment
          aggregation. What are the effects of treatment aggregation on the
          proposed DSCP? </t>

            <t> </li>
          <li> <xref target="lowerlayers"></xref> target="lowerlayers"/> describes some observed treatments
          by layers below IP. What are the implications of the treatments and
          mapping described in <xref target="lowerlayers"></xref> target="lowerlayers"/> on the proposed
          DSCP? </t>

            <t> DSCPs </li>
          <li>DSCPs are assigned to PHBs and can be used to enable nodes along
          an end-to-end path to classify the packet for a suitable PHB.  <xref target="observed-re-marking"></xref>
          target="observed-re-marking"/> describes some observed re-marking
          behavior, and <xref target="networks"></xref> target="networks"/> identifies root causes for
          why this re-marking is observed.  What is the expected effect of
          currently-deployed re-marking on the service, end-to-end or otherwise?</t>

          </list></t>
      </section>
          otherwise?</li>
        </ul>
      </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors acknowledge the helpful discussions and analysis by Greg
      White and Thomas Fossati in a draft concerning NQB. Ruediger Geib and
      Brian Carpenter contributed comments, along with other members of the
      TSVWG.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> anchor="IANA">
      <name>IANA Considerations</name>
<t>IANA is requested to append the page for the
	Differentiated Services Field Codepoints (DSCP)
  	registry at:
	https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml.
        This request is to add has added the following separate paragraph to the Note text as a note at the top of the "Differentiated Services Field Codepoints (DSCP)" registry page: <xref target="DSCP-registry"/>: "See [RFC-to-be] RFC 9435 for considerations when assigning a new codepoint from the DSCP registry."
</t>
</section>
    <section anchor="Security" title="Security Considerations"> anchor="Security">
      <name>Security Considerations</name>
      <t>The security considerations are discussed in the security
      considerations of each cited RFC.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      <!--?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->

      <!-- These are dependent standards necessary to implement/understand this RFC -->

      &RFC2119;

      &RFC2474;

      &RFC2475;

      &RFC3260;

      &RFC3290;

      &RFC4594;

      &RFC5129;

      &RFC8100;

      &RFC8436;

<displayreference target="I-D.ietf-tsvwg-nqb" to="NQB-PHB"/>
<displayreference target="I-D.learmonth-intarea-rfc1226-bis" to="AX.25-over-IP"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2475.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3260.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3290.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4594.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5129.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8100.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8436.xml"/>

        <reference anchor="DSCP-registry"> anchor="DSCP-registry" target="https://www.iana.org/assignments/dscp-registry/">
          <front>
            <title>Differentiated Services Field Codepoints (DSCP)
          Registry</title> (DSCP)</title>
            <author>
              <organization>IANA</organization>
            </author>
          <date year="2019" />
          </front>

          <seriesInfo name="" value="https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml"/>
        </reference>

      </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. - these are not dependent standards -->

      &RFC0791;

      &RFC1122;

      &RFC1349;

      &RFC2597;

      &RFC3086;

      &RFC3246;

      &RFC3270;
      &RFC3662;

      &RFC5127;

      &RFC5160;

      &RFC5415;

      &RFC5865;

      &RFC8325;

      &RFC8126;

      &RFC8174;

      &RFC8622;

      &I-D.ietf-tsvwg-nqb;

      <!--- last informational individual specs and other references -->

      <references>
        <name>Informative References</name>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1122.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1349.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2597.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3086.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3246.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

<reference anchor="Kol10"> anchor="RFC3270" target="https://www.rfc-editor.org/info/rfc3270">
<front>
<title> Bogus
Multi-Protocol Label Switching (MPLS) Support of Differentiated Services
</title>
<author fullname="F. Le Faucheur" initials="F." surname="Le Faucheur" role="editor"/>
<author fullname="L. Wu" initials="L." surname="Wu"/>
<author fullname="B. Davie" initials="B." surname="Davie"/>
<author fullname="S. Davari" initials="S." surname="Davari"/>
<author fullname="P. Vaananen" initials="P." surname="Vaananen"/>
<author fullname="R. Krishnan" initials="R." surname="Krishnan"/>
<author fullname="P. Cheval" initials="P." surname="Cheval"/>
<author fullname="J. Heinanen" initials="J." surname="Heinanen"/>
<date month="May" year="2002"/>
</front>
<seriesInfo name="RFC" value="3270"/>
<seriesInfo name="DOI" value="10.17487/RFC3270"/>
</reference>

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3662.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5127.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5160.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5415.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5865.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8325.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8622.xml"/>

      <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tsvwg-nqb.xml"/>

      <reference anchor="Kol10" target="https://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057710.html">
          <front>
            <title>Subject: bogus DSCP value for SSH </title> ssh</title>
            <author initials="A." surname="Kolu"></author> surname="Kolu"/>
            <date year="2010" /> day="12" month="July" year="2010"/>
          </front>
       <seriesInfo name="online" value="https://lists.freebsd.org/pipermail/freebsd-stable/2010-July/057710.html"/>
	  <refcontent>message to the freebsd-stable mailing list</refcontent>
        </reference>

        <reference anchor="Cus17">
          <front>
            <title>Exploring DSCP modification pathologies in mobile edge
          networks</title>
            <author initials="A." surname="Custura"></author> surname="Custura"/>
            <author initials="A." surname="Venne"></author> surname="Venne"/>
            <author initials="G." surname="Fairhurst"></author> surname="Fairhurst"/>
            <date year="2017" /> month="June" year="2017"/>
          </front>
          <seriesInfo name="TMA" value="" /> name="DOI" value="10.23919/TMA.2017.8002923"/>
	  <refcontent>2017 Network Traffic Measurement and Analysis Conference (TMA)</refcontent>
        </reference>

        <reference anchor="Bar18">
          <front>
            <title>Can WebRTC QoS Work? A DSCP Measurement Study</title>
            <author initials="R." surname="Barik"></author> surname="Barik"/>
            <author initials="M." surname="Welzl"></author> surname="Welzl"/>
            <author initials="A." surname="Elmokashfi"></author> surname="Elmokashfi"/>
            <author initials="T." surname="Dreibholz"></author> surname="Dreibholz"/>
            <author initials="S." surname="Gjessing"></author> surname="Gjessing"/>
            <date month="September" year="2018" /> year="2018"/>
          </front>
	  <seriesInfo name="ITC" value="30" /> name="DOI" value="10.1109/ITC30.2018.00034"/>
	  <refcontent>2018 30th International Teletraffic Congress (ITC 30)</refcontent>
        </reference>

        <reference anchor="SA-5G">
          <front>
            <title>System Architecture architecture for 5G</title> the 5G System (5GS)</title>
            <author>
              <organization>3GPP</organization>
            </author>
            <date year="2019" /> year="2019"/>
          </front>
          <seriesInfo name="TS" value="23.501" /> value="23.501"/>
        </reference>

        <reference anchor="GSMA-IR-34"> anchor="GSMA-IR.34" target="https://www.gsma.com/newsroom/wp-content/uploads/IR.34-v17.0.pdf">
          <front>
          <title>IR.34 Guidelines
            <title>Guidelines for IPX Provider networks (Previously
            Inter-Service Provider IP Backbone Guidelines)</title>
            <author>
              <organization>GSM Association</organization>
            </author>
            <date year="2017" /> month="May" year="2021"/>
          </front>
        <seriesInfo name="IR" value="34" />
	  <refcontent>Version 17.0, IR.34</refcontent>
        </reference>

        <reference anchor="ITU-T-Y-1566"> anchor="ITU-T-Y.1566" target="https://www.itu.int/rec/T-REC-Y.1566/en">
          <front>
            <title>Quality of Service Mapping service mapping and Interconnection Between interconnection between
            Ethernet, Internet Protocol and Multiprotocol Label Switching
          Networks</title> multiprotocol label switching
            networks</title>
            <author>
            <organization>ITU-T</organization>
              <organization>ITU-T Recommendation</organization>
            </author>
            <date year="2012" /> month="July" year="2012"/>
          </front>
          <seriesInfo name="ITU-T" value="Y.1566" /> value="Y.1566"/>
        </reference>

        <reference anchor="IEEE-802-11"> anchor="IEEE-802.11" target="https://standards.ieee.org/ieee/802.11/7028/">
          <front>
          <title>Wireless
            <title>IEEE Standard for Information Technology -
            Telecommunications and Information Exchange Between Systems -
            Local and Metropolitan Area Networks - Specific Requirements -
            Part 11: Wireless LAN Medium Access Control (MAC) and Physical
            Layer (PHY) Specifications</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date year="2007" /> month="February" year="2021"/>
          </front>
	  <seriesInfo name="IEEE" value="802.11" /> name="DOI" value="10.1109/IEEESTD.2021.9363693"/>
          <seriesInfo name="IEEE Standard" value="802.11"/>
        </reference>

        <reference anchor="WIFI-ALLIANCE">
          <front>
            <title>Wi-Fi QoS Management Specification Version 2.0
            </title>
            <author>
              <organization>Wi-Fi Alliance</organization>
            </author>
            <date year="2021" /> year="2021"/>
          </front>
        <seriesInfo name="Wi-Fi QoS Management Specification Version" value="2.0" />
        </reference>

        <reference anchor="IEEE-802-1Q"> anchor="IEEE-802.1Q">
          <front>
            <title>IEEE Standard for Local and Metropolitan Area Network--
          Bridges
            Network--Bridges and Bridged Networks</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date year="2018" /> month="July" year="2018"/>
          </front>
          <seriesInfo name="IEEE" value="802.1Q" /> name="IEEE Standard" value="802.1Q-2018"/>
	  <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8403927"/>
        </reference>

        <reference anchor="IEEE-802-1D"> anchor="IEEE-802.1D">
          <front>
            <title>IEEE Standard for Local and Metropolitan Area Network-- Media metropolitan area
            network--Media Access Control (MAC) Bridges</title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date year="2004" /> month="June" year="2004"/>
          </front>
          <seriesInfo name="IEEE" value="802.1D" /> name="IEEE Standard" value="802.1D-2004"/>
	  <seriesInfo name="DOI" value="10.1109/IEEESTD.2004.94569"/>
        </reference>

        <reference anchor="IETF115-IEPG"> anchor="IETF115-IEPG" target="https://datatracker.ietf.org/meeting/115/materials/slides-115-iepg-sessa-considerations-for-assigning-dscps-01">
          <front>
            <title>Real-world DSCP Traversal Measurements</title>
            <author initials="A." surname="Custura">
              <organization>University of Aberdeen, UK</organization>
            </author>
	    <date year="2022" /> month="November" year="2022"/>
          </front>
        <seriesInfo name="online" value="https://datatracker.ietf.org/meeting/115/materials/slides-115-iepg-sessa-considerations-for-assigning-dscps-01" />
        </reference>

        <reference anchor="MEF23.1"> anchor="MEF-23.1" target="https://mef.net/Assets/Technical_Specifications/PDF/MEF_23.1.pdf">
          <front>
          <title>MEF Technical Specification
            <title>Implementation Agreement MEF 23.1-- 23.1 Carrier Ethernet Class of Service ? - Phase 2</title>
            <author>
              <organization>MEF</organization>
            </author>
            <date year="2012" /> month="January" year="2012"/>
          </front>
          <seriesInfo name="MEF" value="23.1" /> value="23.1"/>
        </reference>

      &I-D.learmonth-rfc1226-bis;

<!-- [I-D.learmonth-rfc1226-bis] replaced by [I-D.learmonth-intarea-rfc1226-bis] IESG state Expired -->

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.learmonth-intarea-rfc1226-bis.xml"/>

      </references>
    </references>

    <section title="Revision Notes">
      <t>Note to RFC-Editor: please remove this entire section prior to
      publication.</t>

      <t><list style="symbols">
          <t>Individual draft -00, initial document.</t>

          <t>Individual draft -01, address comments from Martin Duke; Brian Carpenter;
          Ruediger Geib, and revisions to improve language consistency.</t>

          <t>Individual draft -02, revise to improve language consistency.</t>

          <t>Working Group -00, replace individual draft.</t>
	  <t>Working Group -01, address feedback in preparation for IETF 113 Vienna.</t>
          <t>Working Group -02:
          <list style="hanging">
          <t>Consolidate terminology after IETF 113 Vienna. </t>
          <t>Add clarification to RFC2474 and RFC2475 addressed in RFC3260 (comments from Ruediger Geib).</t>
          <t>Include figures to show anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors acknowledge the full list of codepoints, their assigned PHBs &amp; impact of ToS Precedence Bleaching.</t>
          <t>Add network categories that differentiate between network operator approaches to DiffServ.</t>
          <t>Add Terminology section to clarify representations of DSCPs.</t>
          </list>
          </t>
	  <t>Working Group -03
           <list style="hanging">
          <t>Add table to explain DSCP abbreviations (comment from Brian Carpenter).</t>
          <t>Add some refs, improve language consistency (comments from Brian Carpenter).</t>
          <t>Clarify figure captions.</t>
          </list>
          </t>

          <t>Working Group -04
           <list style="hanging">
          <t>Reference RFC3086 (comment from Brian Carpenter).</t>
          <t>Improve references (comments from Ruediger Geib).</t>
          <t>Clarify intended document audience and scope (comments from Ruediger Geib).</t>
          <t>Clarify terms and language around re-marking, DiffServ domains helpful discussions and nodes, RFC8100 (comments from Ruediger Geib).</t>
          <t>More in-depth on mappings specified for mobile networks/MPLS short-pipe (comments from Ruediger Geib).</t>
          </list>
       	</t>

           <t>Working Group -05
           <list style="hanging">
          <t>Clarify meaning of RFC2474 with respect to IP precedence (comments from Ruediger Geib).</t>
          <t>Add note on understanding the process of re-marking (comments from Ruediger Geib).</t>
          <t>Improve readability.</t>
          </list>
       	</t>

           <t>Working Group -06
           <list style="hanging">
          <t>Quote RFC2474 with respect to IP precedence (comments from Ruediger Geib).</t>
          <t>Ensure it is clear that different re-marking processes may result in the same observed re-marking.</t>
          <t>Clarify Treatment Aggregates are part of methods such as MPLS (comments from David Black).</t>
          <t>Clarify implications on the rest of the path analysis by re-marking in one domain. </t>
          <t>Include all observed re-marking behaviors in Section 6.</t>
          <t>Remove mentions of DSCP 5 being provisionally assigned to NQB.</t>
          <t>Clarify scope of network control traffic
      <contact fullname="Greg White"/> and <contact fullname="Thomas
      Fossati"/> in Section 3.2.</t>
          <t>Improve readibility.</t>
          </list>
       	</t>
           <t>Working Group -07
           <list style="hanging">
          <t>Update Section 4 to clarify both types of paths measured.</t>
          <t>Revised
		  paragraph 2 in Introduction</t>
          </list>
        </t>
  <t>Working Group -08
           <list style="hanging">
          <t>Update after Shepherd review with additional comments from R. Geib. D. Black and B. Carpenter provided comments on relationship to RFC 2474.</t>
          </list>
        </t>

<t>Working Group -09
           <list style="hanging">
          <t>Updates to document structure to avoid references in artwork legend.</t>
          <t>Fix DSCP table indentation</t>
          <t>Update ref to nqb a draft to -15</t>
          </list>
        </t>
<t>Working Group -10
           <list style="hanging">
          <t>Document updated after AD review</t>
          <t>Add clarification on former use concerning NQB. <contact fullname="Ruediger
      Geib"/> and <contact fullname="Brian Carpenter"/> contributed comments,
      along with other members of CS1</t>
          </list>
        </t>
<t>Working Group -11
           <list style="hanging">
          <t>Updated to complete response to AD review and resolved pathology types to xrefs.</t>
          </list>
        </t>
<t>Working Group -12
           <list style="hanging">
          <t>Finalize response to AD review, address comment from Brian Carpenter.</t>
          </list>
        </t>
<t>Working Group -13
           <list style="hanging">
          <t>Review by Erik Kline</t>
	  <t>Added recommended change by IANA to cite this document from the registry when it is published.</t>
	  <t>The latest DSCP contribution to IEPG was at IETF-115.</t>
	  <t>Consistently use re-mark instead of remark.</t>
	  <t>Improve artwork abbreviations</t>
	  <t>Address NiTs from John Scudder</t>
          </list>
        </t>

        </list></t> TSVWG.</t>
    </section>

  </back>

</rfc>