rfc9435xml2.original.xml   rfc9435.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!-- Historic references will result in warnings! --> <!ENTITY nbsp "&#160;">
<!ENTITY RFC1349 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen <!ENTITY zwsp "&#8203;">
ce.RFC.1349.xml"> <!ENTITY nbhy "&#8209;">
<!-- References --> <!ENTITY wj "&#8288;">
<!ENTITY RFC0791 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.0791.xml">
<!ENTITY RFC1122 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.1122.xml">
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2119.xml">
<!ENTITY RFC2474 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2474.xml">
<!ENTITY RFC2597 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2597.xml">
<!ENTITY RFC2760 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2760.xml">
<!ENTITY RFC3086 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3086.xml">
<!ENTITY RFC3246 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3246.xml">
<!ENTITY RFC3260 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3260.xml">
<!ENTITY RFC3270 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3270.xml">
<!ENTITY RFC3552 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3552.xml">
<!ENTITY RFC2475 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.2475.xml">
<!ENTITY RFC3290 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3290.xml">
<!ENTITY RFC3662 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.3662.xml">
<!ENTITY RFC4594 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.4594.xml">
<!ENTITY RFC5127 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5127.xml">
<!ENTITY RFC5129 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5129.xml">
<!ENTITY RFC5160 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5160.xml">
<!ENTITY RFC5415 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5415.xml">
<!ENTITY RFC5865 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.5865.xml">
<!ENTITY RFC8100 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8100.xml">
<!ENTITY RFC8126 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8126.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8174.xml">
<!ENTITY RFC8325 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8325.xml">
<!ENTITY RFC8436 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8436.xml">
<!ENTITY RFC8622 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referen
ce.RFC.8622.xml">
<!ENTITY I-D.ietf-tsvwg-nqb SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bib
xml3/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">
]> ]>
<?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 category="info" docName="draft-ietf-tsvwg-dscp-considerations-13"
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 ***** --> <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" tocInclude="true" tocDepth="4" symRefs="true" sortRefs= "true" updates="" obsoletes="" xml:lang="en" version="3">
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary <title abbrev="Assigning a New DSCP">Considerations for Assigning a New
if the Recommended Differentiated Services Code Point (DSCP)</title>
full title is longer than 39 characters --> <seriesInfo name="RFC" value="9435"/>
<title abbrev="Considerations for assigning a DSCPs">Considerations for
Assigning a new Recommended DiffServ Codepoint (DSCP)</title>
<author fullname="Ana Custura" initials="A" surname="Custura"> <author fullname="Ana Custura" initials="A" surname="Custura">
<organization>University of Aberdeen</organization> <organization>University of Aberdeen</organization>
<address> <address>
<postal> <postal>
<street>School of Engineering</street> <extaddr>School of Engineering</extaddr>
<street>Fraser Noble Building</street> <street>Fraser Noble Building</street>
<city>Aberdeen</city> <city>Aberdeen</city>
<region/>
<region></region>
<code>AB24 3UE</code> <code>AB24 3UE</code>
<country>United Kingdom</country>
<country>UK</country>
</postal> </postal>
<email>ana@erg.abdn.ac.uk</email> <email>ana@erg.abdn.ac.uk</email>
</address> </address>
</author> </author>
<author fullname="Godred Fairhurst" initials="G" surname="Fairhurst"> <author fullname="Godred Fairhurst" initials="G" surname="Fairhurst">
<organization>University of Aberdeen</organization> <organization>University of Aberdeen</organization>
<address> <address>
<postal> <postal>
<street>School of Engineering</street> <extaddr>School of Engineering</extaddr>
<street>Fraser Noble Building</street> <street>Fraser Noble Building</street>
<city>Aberdeen</city> <city>Aberdeen</city>
<region/>
<region></region>
<code>AB24 3UE</code> <code>AB24 3UE</code>
<country>United Kingdom</country>
<country>UK</country>
</postal> </postal>
<email>gorry@erg.abdn.ac.uk</email> <email>gorry@erg.abdn.ac.uk</email>
</address> </address>
</author> </author>
<author fullname="Raffaello Secchi" initials="R" surname="Secchi"> <author fullname="Raffaello Secchi" initials="R" surname="Secchi">
<organization>University of Aberdeen</organization> <organization>University of Aberdeen</organization>
<address> <address>
<postal> <postal>
<street>School of Engineering</street> <extaddr>School of Engineering</extaddr>
<street>Fraser Noble Building</street> <street>Fraser Noble Building</street>
<city>Aberdeen</city> <city>Aberdeen</city>
<region/>
<region></region>
<code>AB24 3UE</code> <code>AB24 3UE</code>
<country>United Kingdom</country>
<country>UK</country>
</postal> </postal>
<email>r.secchi@abdn.ac.uk</email> <email>r.secchi@abdn.ac.uk</email>
</address> </address>
</author> </author>
<date month="July" year="2023"/>
<date day="3" month="March" year="2023" /> <area>tsv</area>
<workgroup>tsvwg</workgroup>
<area>TSVArea</area> <keyword>DSCP</keyword>
<keyword>Diffserv Codepoints</keyword>
<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 Codepoints</keyword>
<abstract> <abstract>
<t>This document discusses considerations for assigning a new <t>This document discusses considerations for assigning a new
recommended DiffServ Code Point (DSCP) for a new standard Per Hop Behavior recommended Differentiated Services Code Point (DSCP) for a standard
(PHB). It considers the common Per-Hop Behavior (PHB). It considers the common observed re-marking
observed re-marking behaviors that the DiffServ field might be subjected behaviors that the Diffserv field might be subjected to along an
to along Internet path. It also notes some implications of using a specific
an Internet path. It also notes some implications of using a specific
DSCP.</t> DSCP.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction">
<t>The Differentiated Services (DiffServ) architecture has been deployed <name>Introduction</name>
<t>The Differentiated Services (Diffserv) architecture has been deployed
in many networks. It provides differentiated traffic forwarding based on in many networks. It provides differentiated traffic forwarding based on
the DiffServ Code Point (DSCP) <xref target="RFC2474"></xref> carried the DSCP carried in the Diffserv field of the IP packet header <xref
in the DiffServ field <xref target="RFC2474"></xref> of the IP packet head target="RFC2474"/>. A common set of DSCPs are defined for both IPv4 and
er. IPv6, and both network protocols use a common IANA registry <xref
A common set of DSCPs are defined for both IPv4 and IPv6, and both network proto target="DSCP-registry"/>.</t>
cols <t>Diffserv associates traffic with a service class and categorizes it
use a common IANA registry <xref target="DSCP-registry"></xref>.</t> into Behavior Aggregates (BAs) <xref target="RFC4594"/>. Configuration
guidelines for service classes are provided in <xref target="RFC4594"/>.
<t>DiffServ associates traffic with a service class <xref target="RFC4594" BAs are associated with a DSCP, which in turn maps to a Per-Hop Behavior
></xref> and (PHB). Treatment differentiation can be achieved by using a variety of
categorises it into Behavior Aggregates <xref target="RFC4594"></xref>. schedulers and queues and also algorithms that implement access to the
Configuration guidelines for service classes are provided in <xref target= physical media.</t>
"RFC4594">RFC4594</xref>. <t>Within a Diffserv domain, operators can set Service Level
Behavior aggregates are associated with a DiffServ Code Point (DSCP), Specifications <xref target="RFC3086"/>, each of which maps to a
which in turn maps to a Per Hop Behavior (PHB). particular Per-Domain Behavior (PDB) that is based on one or more PHBs.
Treatment differentiation can be The PDB defines which PHB (or set of PHBs) and, hence, for a specific
achieved using a variety of schedulers and queues, and also by operator, which DSCP (or set of DSCPs) will be associated with specific
algorithms that implement access to the physical media.</t> BAs as the packets pass through a Diffserv domain. It also defines
whether the packets are re-marked as they are forwarded (i.e.,
<t>Within a DiffServ domain, operators can set service level changing the DSCP of a packet <xref target="RFC2475"/>).</t>
specifications <xref target="RFC3086"></xref>, each of which maps to a partic
ular Per
Domain Behavior (PDB) that is based on one or more PHBs. The
PDB defines which PHB (or set of PHBs) and hence for a specific
operator, which DSCP (or set of DSCPs) will be associated with
specific Behavior Aggregates (BAs) as the packets pass through a DiffServ dom
ain, and
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> <figure anchor="fig1">
<artwork><![CDATA[ <name>The Role of DSCPs in Classifying IP Traffic for Differential Network
Treatment by a Diffserv Node</name>
<artwork><![CDATA[
Application -> Service Application -> Service
Traffic Class Traffic Class
| |
Behavior -> DiffServ -> Per Hop Behavior -> Diffserv -> Per Hop
Aggregate Codepoint Behavior Aggregate Codepoint Behavior
| |
Schedule, Schedule,
Queue, Drop Queue, Drop
]]></artwork> ]]></artwork>
</figure>
<postamble>Figure showing the role of DSCPs in classifying IP <t>This document discusses considerations for assigning a new DSCP for a
traffic for differential network treatment by a DiffServ Node.</postam standard PHB. It considers some commonly observed DSCP re-marking
ble> behaviors that might be experienced along an Internet path. It also
</figure></t> describes some packet forwarding treatments that a packet with a
specific DSCP can expect to receive when forwarded across a link or
<t>This document discusses considerations for assigning a new DSCP for a s subnetwork.</t>
tandard 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 <t>The document is motivated by new opportunities to use Diffserv
end-to-end across multiple domains, such as <xref end-to-end across multiple domains, such as <xref
target="I-D.ietf-tsvwg-nqb"></xref>, proposals to build mechanisms using target="I-D.ietf-tsvwg-nqb"/>, proposals to build mechanisms using DSCPs
DSCPs in other standards-setting organisations, and the desire to use a in other standards-setting organizations, and the desire to use a common
common set of DSCPs across a range of infrastructure (e.g., <xref 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
<xref target="I-D.learmonth-rfc1226-bis"></xref>).</t> target="I-D.learmonth-intarea-rfc1226-bis"/>).</t>
</section> </section>
<section>
<section title="Terminology"> <name>Terminology</name>
<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
in this document are to be interpreted as described in BCP 14 <xref "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
all capitals, as shown here.</t> are to be interpreted as described in BCP&nbsp;14 <xref
target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
<t>DSCPs are specified in the IANA registry <xref target="DSCP-registry">< appear in all capitals, as shown here.
/xref>, </t>
where a variety of different formats are described. <t>DSCPs are specified in the IANA registry <xref
A DSCP can sometimes be referred to by name, such as "CS1", and target="DSCP-registry"/>, where a variety of different formats are
sometimes by a decimal, hex, or binary value. Hex values are represented described. A DSCP can sometimes be referred to by name, such as "CS1",
in text using prefix 0x. Binary values use prefix 0b. and sometimes by a decimal, hex, or binary value. Hex values are
</t> represented in text using prefix "0x". Binary values use prefix "0b".
</t>
<t>In this document, the symbol "&amp;" denotes a bitwise AND of two unsigned
values.</t>
</section> </section>
<section>
<section title="Current usage of DSCPs"> <name>Current Usage of DSCPs</name>
<t>This section describes the current usage of DSCPs.</t> <t>This section describes the current usage of DSCPs.</t>
<section>
<section title="IP-Layer Semantics"> <name>IP-Layer Semantics</name>
<t>The DiffServ architecture specifies the use of the DiffServ field in <t>The Diffserv architecture specifies the use of the Diffserv field
the IPv4 and IPv6 packet headers to carry one of 64 distinct DSCP 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 values. Within a given administrative boundary, each DSCP value can be
mapped to a distinct PHB <xref target="RFC2474"></xref>. When a new PHB mapped to a distinct PHB <xref target="RFC2474"/>. When a new PHB is
is specified, a recommended DSCP value among those 64 values is specified, a recommended DSCP value among those 64 values is normally
normally reserved for that PHB, and is assigned by IANA. An operator reserved for that PHB and is assigned by IANA. An operator is not
is not formally required to use the recommended value; formally required to use the recommended value; indeed, <xref
indeed [RFC2474] states that "the mapping of codepoints to PHBs target="RFC2474"/> states that "the mapping of codepoints to PHBs
MUST be configurable." However, use of the recommended value is <bcp14>MUST</bcp14> be configurable." However, use of the recommended
usually convenient and avoids confusion.</t> value is usually convenient and avoids confusion.</t>
<t>The DSCP space is divided into three pools for the purpose of <t>The DSCP space is divided into three pools for the purpose of
assignment and management <xref target="DSCP-registry"></xref>. A assignment and management <xref target="DSCP-registry"/>. A
summary of the pools is provided in a table (where 'x' refers to a summary of the pools is provided in a table (where 'x' refers to a
bit position with value either '0' or '1'). bit position with value either '0' or '1').
<list style="hanging"> </t>
<t hangText="DSCP Pool 1:">A pool of 32 codepoints with a format <dl newline="false" spacing="normal">
0bxxxxx0, to be assigned by IANA Standards Action <xref <dt>DSCP Pool 1:</dt>
target="RFC8126"></xref>.</t> <dd>A pool of 32 codepoints with a format of 0bxxxxx0, to be assigned
by IANA Standards Action <xref target="RFC8126"/>.</dd>
<t hangText="DSCP Pool 2:">A pool of 16 codepoints with a format of <dt>DSCP Pool 2:</dt>
0bxxxx11, reserved for experimental or local (private) use by <dd>A pool of 16 codepoints with a format of 0bxxxx11, reserved for
network operators (see Sections 4.1 and 4.2 of <xref Experimental or Local (Private) Use by network operators (see
target="RFC8126"></xref>.</t> Sections <xref target="RFC8126" sectionFormat="bare" section="4.1"/>
and <xref target="RFC8126" sectionFormat="bare" section="4.2"/> of
<t hangText="DSCP Pool 3:">A pool of 16 codepoints with a format of <xref target="RFC8126"/>.</dd>
0bxxxx01. <dt>DSCP Pool 3:</dt>
This was initially available for experimental (EXP) or Local Use (LU <dd>A pool of 16 codepoints with a format of 0bxxxx01. This was
), but initially available for Experimental (EXP) Use or Local Use (LU) but
was originally specified to be "preferentially utilized for was originally specified to be "preferentially utilized for
standards assignments" if Pool 1 is ever exhausted. standardized assignments if Pool 1 is ever exhausted" <xref target="RF
Pool 3 C2474"/>.
codepoints are now "utilized for standards assignments and are
no longer available for assignment to experimental or local use" <xr
ef
target="RFC8436"></xref>.
<xref
target="RFC8622"></xref> assigned 0x01 from this pool and consequent
ially
updated <xref target="RFC4594"></xref>. Any future request to assign
0x05
would be expected to similarly update <xref target="RFC4594"></xr
ef>.</t>
</list></t>
<t>
Note that <xref target="RFC4594"></xref>
previously recommended a local use of DSCP values 0x01, 0x03, 0x05 an
d 0x07
(codepoints with the format of 0b000xx1), until updated by <xref
target="RFC8436"></xref>.
</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 the currently assigned DSCPs and their assi
gned PHBs.</postamble>
</figure>
<figure> Pool 3
<preamble></preamble> codepoints are now "utilized for standardized assignments (replacing
the previous availability for experimental or local use)" <xref
target="RFC8436"/>. <xref target="RFC8622"/> assigned 0x01 from
this pool and consequentially updated <xref target="RFC4594"/>. Any
future request to assign 0x05 would be expected to similarly update
<xref target="RFC4594"/>.</dd>
</dl>
<t> Note that <xref target="RFC4594"/> previously recommended a Local
Use of DSCP values 0x01, 0x03, 0x05, and 0x07 (codepoints with the
format of 0b000xx1), until this was updated by <xref
target="RFC8436"/>.
</t>
<t>The DSCP space is shown in the following table. Each row corresponds
to one setting of the first three bits of the DSCP field, and each column to one
setting of the last three bits of the DSCP field.
</t>
<artwork> <table anchor="table1" align="center">
<![CDATA[ <name>Currently Assigned DSCPs and Their Assigned PHBs</name>
+-----+-----------------------+-----------+ <tbody>
| CS | Class Selector | RFC 2474 | <tr>
+-----+-----------------------+-----------+ <td>56/CS7</td>
| BE | Best Effort (CS0) | RFC 2474 | <td>57</td>
+-----+-----------------------+-----------+ <td>58</td>
| AF | Assured Forwarding | RFC 2597 | <td>59</td>
+-----+-----------------------+-----------+ <td>60</td>
| EF | Expedited Forwarding | RFC 3246 | <td>61</td>
+-----+-----------------------+-----------+ <td>62</td>
| VA | Voice Admit | RFC 5865 | <td>63</td>
+-----+-----------------------+-----------+ </tr>
| LE | Lower Effort | RFC 8622 | <tr>
+-----+-----------------------+-----------+ <td>48/CS6</td>
]]> <td>49</td>
</artwork> <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>
<postamble>Table showing the summary of the DSCP abbreviations used in published <table anchor="table2" align="center">
RFCs.</postamble> <name>Abbreviations for DSCPs and PHB Groups</name>
</figure> <tbody>
</t> <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> The above table summarises the DSCP abbreviations used in currently publishe <t><xref target="table2"/> summarizes the DSCP abbreviations used in
d RFCs currently published RFCs, <xref target="RFC2474"/> <xref
<xref target="RFC2474"></xref> <xref target="RFC2597"/> <xref target="RFC3246"/> <xref target="RFC5865"/>
target="RFC2597"></xref> <xref target="RFC3246"></xref> < <xref target="RFC8622"/>, as described in the IANA registry <xref
xref target="DSCP-registry"/>.
target="RFC5865"></xref> <xref target="RFC8622"></xref>, The Default PHB is defined in <xref target="RFC2474" section="4.1" sectionFormat
as described in the IANA registry <xref ="of"/>. This provides Best Effort (BE) forwarding, and the recommended DSCP of
target="DSCP-registry"></xref>. BE, also known as CS0, de '000000' (<xref target="RFC2474" section="4.2.2.1" sectionFormat="of"/>). This
scribes the default forwarding treatment. is the lowest value in the set of Class Selector (CS) DSCPs, and hence is also k
</t> nown as "CS0" <xref target="DSCP-registry"/>.
<t>
NOTE: <xref target="RFC4594"></xref> specified a now deprecated use of
Class Selector 1 (CS1) as the codepoint for the Lower Effort
PHB. <xref target="RFC8622"></xref> updated <xref target="RFC4594"></xref
> and <xref target="RFC8325"></xref>,
and obsoleted <xref target="RFC3662"></xref>, assigning the LE DSCP codep
oint to the Lower Effort
PHB.</t>
<t>The DiffServ architecture allows forwarding treatments to be </t>
<t> NOTE: <xref target="RFC4594"/> specified a now deprecated use of
Class Selector 1 (CS1) as the codepoint for the Lower Effort
PHB. <xref target="RFC8622"/> updated <xref target="RFC4594"/> and
<xref target="RFC8325"/> and obsoleted <xref target="RFC3662"/>,
assigning the LE DSCP codepoint to the Lower Effort PHB.</t>
<t>The Diffserv architecture allows forwarding treatments to be
associated with each DSCP, and the RFC series describes some of these associated with each DSCP, and the RFC series describes some of these
as PHBs. Although DSCPs are intended to identify specific treatment as PHBs. Although DSCPs are intended to identify specific treatment
requirements, multiple DSCPs might also be mapped (aggregated) to the requirements, multiple DSCPs might also be mapped (aggregated) to the
same forwarding treatment. DSCPs can be mapped to treatment same forwarding treatment. DSCPs can be mapped to Treatment Aggregates (
aggregates that might result in re-marking (e.g., <xref TAs)
target="RFC5160">RFC5160</xref> suggests Meta-QoS-Classes to help that might result in re-marking (e.g., <xref target="RFC5160"/>
enable deployment of standard end-to-end QoS classes)</t> suggests Meta-QoS-Classes to help enable deployment of standard
end-to-end QoS classes).</t>
</section> </section>
<section>
<section title="DSCPs used for Network Control Traffic"> <name>DSCPs Used for Network Control Traffic</name>
<t>Network Control Traffic is defined as packet flows that are <t>Network control traffic is defined as packet flows that are
essential for stable operation of the administered network (see <xref essential for stable operation of the administered network (see <xref
target="RFC4594"></xref>, Section 3). The traffic consists of target="RFC4594" sectionFormat="comma" section="3"/>). The traffic
the network control service class and the OAM service class. consists of the network control service class and the OAM service
This traffic is marked with a class. This traffic is marked with a value from a set of CS DSCPs. Thi
value from a set of Class Selector (CS) DSCPs. s traffic is often a special case within a
This traffic is provider network, and ingress traffic with these DSCP markings can be
often a special case within a provider network, and ingress traffic re-marked.</t>
with these DSCP markings can be re-marked.</t>
<t>DSCP CS2 is recommended for the OAM (Operations, Administration, <t>DSCP CS2 is recommended for the OAM (Operations, Administration,
and Maintenance) service class (see <xref target="RFC4594"></xref>, and Maintenance) service class (see <xref target="RFC4594"
Section 3.3).</t> sectionFormat="comma" section="3.3"/>).</t>
<t>DSCP CS6 is recommended for local network control traffic. This <t>DSCP CS6 is recommended for local network control traffic. This
includes routing protocols and OAM traffic that are essential to includes routing protocols and OAM traffic that are essential to
network operation administration, control and management. Section 3.2 network operation administration, control, and management. <xref
of <xref target="RFC4594">RFC4594</xref> recommends that "CS6 marked target="RFC4594" sectionFormat="of" section="3.2"/> recommends that
packet flows from untrusted sources (for example, end-user devices) "CS6 marked packet flows from untrusted sources (for example, end user
SHOULD be dropped or re-marked at ingress to the DiffServ network".</t> devices) <bcp14>SHOULD</bcp14> be dropped or remarked at ingress to
the Diffserv network".</t>
<t>DSCP CS7 is reserved for future use by network control traffic. <t>DSCP CS7 is reserved for future use by network control traffic.
"CS7 marked packets SHOULD NOT be sent across peering points" <xref "CS7 marked packets <bcp14>SHOULD NOT</bcp14> be sent across peering
target="RFC4594"></xref>.</t> points" <xref target="RFC4594" sectionFormat="comma" section="3.1"/>.</t
>
<t>RFC2474 recommends PHBs selected by CS6 and <t><xref target="RFC2474" sectionFormat="of" section="4.2.2.2"/>
CS7 "MUST give packets preferential forwarding treatment by comparison recommends PHBs selected by CS6 and CS7 "<bcp14>MUST</bcp14> give
to packets a preferential forwarding treatment by comparison to the PHB
the PHB selected by codepoint '000000'"<xref target="RFC2474"></xref>.</ selected by codepoint '000000'".</t>
t>
<t> At the time of writing, there is evidence to suggest CS6 is <t> At the time of writing, there is evidence to suggest CS6 is
actively used by network operators for control traffic. A study of actively used by network operators for control traffic. A study of
traffic at a large Internet Exchange showed around 40% of ICMP traffic traffic at a large Internet Exchange showed around 40% of ICMP traffic
carried this mark <xref target="IETF115-IEPG"></xref>. Similarly, another carried this mark <xref target="IETF115-IEPG"/>. Similarly, another
study found many routers re-mark all traffic, except for packets carrying study found many routers re-mark all traffic, except for packets
a DSCP with the format 0b11xxxx (i.e. setting the higher order bits to 0b carrying a DSCP with the format 0b11xxxx (i.e., setting the higher
11, order bits to 0b11, see <xref target="tos-prec-bleach-impact"/> of
see Section 4.2.1 of this document).</t> this document).</t>
</section> </section>
</section> </section>
<section anchor="observed-re-marking">
<section anchor="observed-re-marking" title="Re-marking the DSCP"> <name>Re-marking the DSCP</name>
<t>It is a feature of the DiffServ architecture that the DiffServ field <t>It is a feature of the Diffserv architecture that the Diffserv field
of packets can be re-marked at the Diffserv domain boundaries (see Section of packets can be re-marked at the Diffserv domain boundaries (see <xref
2.3.4.2 of target="RFC2475" sectionFormat="of" section="2.3.4.2"/>). A DSCP can be
<xref target="RFC2475"></xref>). A DSCP can be re-marked at the re-marked at the ingress of a domain. This re-marking can change the
ingress of a domain. This re-marking DSCP value used on the remainder of an IP path, or the network can
can change the DSCP value used on the remainder of an IP path, or the restore the initial DSCP marking at the egress of the domain. The
network can restore the Diffserv field can also be re-marked based on common semantics and
initial DSCP marking at the egress of the domain. The DiffServ agreements between providers at a Diffserv domain boundary. Furthermore, <
field can also be re-marked based on common semantics and agreements xref
between providers at an exchange point. Furthermore, <xref target="RFC2474 target="RFC2474"/> states that re-marking must occur when there is a
"></xref> states possibility of theft or denial-of-service attack.</t>
that re-marking must occur when there is a possibility of theft or denial- <t>A packet that arrives with a DSCP that is not associated with a PHB,
of-service attack.</t> results in an "unknown DSCP." A node could receive a packet with an
"unexpected DSCP" due to misconfiguration, or because there is no
<t> consistent policy in place. The treatment of packets that are marked
The treatment of packets that are marked with an unknown or an with an unknown or an unexpected DSCP at Diffserv domain boundaries is
unexpected DSCP at DiffServ domain boundaries is determined by the policy determined by the policy for a Diffserv domain. If packets are received
for a DiffServ domain. that are marked with an unknown or an unexpected DSCP by a Diffserv
If packets are received that are marked with an unknown or an domain interior node, <xref target="RFC2474"/> recommends forwarding the
unexpected DSCP by a DiffServ domain interior node, <xref target="RFC2474"></xre packet using a default (Best Effort) treatment but without changing the
f> DSCP. This seeks to support incremental Diffserv deployment in existing
recommends forwarding the packet using a networks as well as preserve DSCP markings by routers that have not been
default (best effort) treatment, but without changing the DSCP. configured to support Diffserv (see also <xref target="re-mark"/>).
This seeks to support incremental DiffServ deployment in existing networks <xref target="RFC3260"/> clarifies that this re-marking specified by
as well as preserve DSCP markings by routers that have not been <xref target="RFC2474"/> is intended for interior nodes within a
configured to support DiffServ. (See also <xref target="re-mark"></xref>). Diffserv domain. For Diffserv ingress nodes, the traffic conditioning
required by <xref target="RFC2475"/> applies first.</t>
<xref target="RFC3260"></xref> clarifies that this re-marking specified by <t>Reports measuring existing deployments have defined a set of
RFC2474 categories for DSCP re-marking <xref target="Cus17"/> <xref
is intended for interior nodes within a DiffServ domain. For DiffServ ingress target="Bar18"/> in the following seven observed
nodes the re-marking behaviors:</t>
traffic conditioning required by RFC 2475 applies first. <dl newline="false" spacing="normal">
</t> <dt>Bleach-DSCP:</dt>
<dd>bleaches all traffic (sets the DSCP to zero)</dd>
<t>Reports measuring existing deployments have defined a set of categories <dt>Bleach-ToS-Precedence:</dt>
for DSCP <dd>set the first three bits of the DSCP field to 0b000 (reset the
re-marking <xref target="Cus17"></xref> <xref target="Bar18"></xref> three bits of the former ToS Precedence field, defined in <xref
into the following seven observed re-marking behaviors:</t> target="RFC0791"/> and clarified in <xref target="RFC1122"/>)</dd>
<dt>Bleach-some-ToS:</dt>
<t><list style="hanging"> <dd>set the first three bits of the DSCP field to 0b000 (reset the
<t hangText="Bleach-DSCP:">bleaches all traffic (sets the DSCP to three bits of the former ToS Precedence field), unless the first two
zero);</t> bits of the DSCP field are 0b11</dd>
<dt>Re-mark-ToS:</dt>
<t hangText="Bleach-ToS-Precedence:">set the first three bits of the <dd>set the first three bits of the DSCP field to any value different
DSCP field to 0b000 (reset the 3 bits of the former ToS Precedence from 0b000 (replace the three bits of the former ToS Precedence
field, defined in <xref target="RFC0791"></xref>, and clarified in <x field)</dd>
ref target="RFC1122"></xref>);</t> <dt>Bleach-low:</dt>
<dd>set the last three bits of the DSCP field to 0b000</dd>
<t hangText="Bleach-some-ToS:">set the first three bits of the <dt>Bleach-some-low:</dt>
DSCP field to 0b000 (reset the 3 bits of the former ToS Precedence <dd>set the last three bits of the DSCP field to 0b000, unless the
field), unless the first two bits of the DSCP field are 0b11;</t> first two bits of the DSCP field are 0b11</dd>
<dt>Re-mark-DSCP:</dt>
<t hangText="Re-mark-ToS:">set the first three bits of the DSCP field <dd>re-marks all traffic to one or more particular (non-zero) DSCP
to any value different from 0b000 (replace the 3 bits of the former values</dd>
ToS Precedence field);</t> </dl>
<t>These behaviors are explained in the following subsections and
<t hangText="Bleach-low:">set the last three bits of the DSCP field cross-referenced in the remainder of the document.</t>
to 0b000;</t> <t> The network nodes forming a particular path might or might not have
supported Diffserv. It is not generally possible for an external
<t hangText="Bleach-some-low:">set the last three bits of the DSCP observer to determine which mechanism results in a specific re-marking
field to 0b000, unless the first two bits of the DSCP field are solely from the change in an observed DSCP value.</t>
0b11;</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
<t hangText="Re-mark-DSCP:">re-marks all traffic to one or more partic IPv6 Internet paths between 2017 and 2021 <xref target="Cus17"/>.
ular IPv6 routers were found to perform all the types of re-marking described
(non-zero) DSCP values.</t> above to a lesser extent than IPv4 ones.</t>
</list></t> <section anchor="Bleaching">
<t>These behaviours are explained in the following subsections and <name>Bleaching the DSCP Field</name>
cross-referenced in the remainder of the document.</t> <t>A specific form of re-marking occurs when the Diffserv field is
re-assigned to the default treatment: CS0 (0x00). This results in
<t>
The network nodes forming a particular path might or might not have supp
orted 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>.
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 the DSCP Field">
<t>A specific form of re-marking occurs when the DiffServ field is
re-assigned to the default treatment, CS0 (0x00). This results in
traffic being forwarded using the BE PHB. For example, AF31 (0x1a) traffic being forwarded using the BE PHB. For example, AF31 (0x1a)
would be bleached to CS0.</t> would be bleached to CS0.</t>
<t>A survey reported that resetting all the bits of the Diffserv field
<t>A survey reported that resetting all the bits of the DiffServ field t to 0 was seen to be more prevalent at the edge of the network and
o 0 was seen to be more prevalent rather less common in core networks <xref target="Cus17"/>.</t>
at the edge of the network, and rather less common in core networks
<xref target="Cus17"></xref>.</t>
</section> </section>
<section>
<section title="IP Type of Service manipulations"> <name>IP Type of Service Manipulations</name>
<t>The IETF first defined ToS precedence for IP packets in <xref <t>The IETF first defined ToS precedence for IP packets in <xref
target="RFC0791"></xref>, and updated it to be part of the target="RFC0791"/> and updated it to be part of the ToS field in
ToS Field in <xref target="RFC1349"></xref>. Since 1998, this <xref target="RFC1349"/>. Since 1998, this practice has been
practice has been deprecated by <xref target="RFC2474"></xref>. deprecated by <xref target="RFC2474"/>. <xref target="RFC2474"/>
RFC 2474 defines DSCPs 0bxxx000 as the Class Selector defines DSCPs 0bxxx000 as the Class Selector codepoints, where PHBs
codepoints, where PHBs selected by these codepoints MUST meet the selected by these codepoints <bcp14>MUST</bcp14> meet the "Class
Class Selector PHB Requirements" described in Sec. 4.2.2.2 of that Selector PHB Requirements" described in <xref target="RFC2474"
RFC.</t> sectionFormat="of" section="4.2.2.2"/>.</t>
<t>A recent survey reports practices based on ToS semantics
<t>However, a recent survey reports practices based on ToS semantics hav have not yet been eliminated from the Internet and need to still be
e not yet been considered when making new DSCP assignments <xref
eliminated from the Internet, and need to still be considered when makin target="Cus17"/>.</t>
g <section anchor="tos-prec-bleach-impact">
new DSCP assignments <xref target="Cus17"></xref>.</t> <name>Impact of ToS Precedence Bleaching</name>
<t>Bleaching of the ToS Precedence field (see <xref
<section title="Impact of ToS Precedence Bleaching "> target="observed-re-marking"/>) resets
the first three bits of the DSCP field to zero (the former ToS
<t>Bleaching of the ToS Precedence field (<xref target="observed-re-ma Precedence field), leaving the last three bits unchanged (see <xref
rking">Bleach-ToS-Precedence</xref>) target="RFC2474" sectionFormat="of" section="4.2.1"/>). A Diffserv
resets the first three bits of the DSCP field to zero (the former node can be configured in a way that results in this
ToS Precedence field), leaving the last three bits unchanged (see Sect re-marking. This re-marking can also occur when packets are
ion processed by a router that is not configured with Diffserv (e.g.,
4.2.1 of <xref target="RFC2474"></xref>). A DiffServ node can be configured to operate on the former ToS Precedence field <xref
configured in a way that results in this re-marking. This re-marking target="RFC0791"/>). At the time of writing, this is a common
can also occur when packets are processed by a router that is not conf manipulation of the Diffserv field. The following Figure depicts
igured this re-marking.</t>
with DiffServ (e.g., configured to operate on the former ToS precedenc
e field
<xref target="RFC0791"></xref>). At the time of writing, this is a co
mmon
manipulation of the DiffServ field. The following Figure depicts this
re-marking.</t>
<figure> <figure anchor="fig2">
<preamble></preamble> <name>Bits in the Diffserv Field Modified by Bleaching of the ToS Precedence</na
<artwork><![CDATA[ me>
<artwork><![CDATA[
+-+-+-+-+-+-+
|5|4|3|2|1|0|
+-+-+-+-+-+-+ +-+-+-+-+-+-+
|0 0 0|x x x| |0 0 0|x x x|
+-+-+-+-+-+-+ +-+-+-+-+-+-+
]]></artwork> ]]></artwork>
<postamble>Figure showing bleaching of the ToS Precedence (<xref tar </figure>
get="observed-re-marking">Bleach-ToS-Precedence</xref>),
based on Section 3 of <xref target="RFC1349"></xref>. The bit
positions marked "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 a result of ToS Precedence Bleac
hing, 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>Data on the observed re-marking at the time of writing was presented in <xref
target="IETF115-IEPG"></xref>.</t>
<figure> <t><xref target="fig2"/> shows bleaching of the ToS Precedence (see
<preamble></preamble> <xref target="observed-re-marking"/>), based on <xref
target="RFC1349" sectionFormat="of" section="3"/>. The bit positions
marked 'x' are not changed.</t>
<artwork><![CDATA[ <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
| 0/CS0 | 1/LE | 2 | 3 | 4 | 5 | 6 | 7 | column are re-marked to the smallest DSCP in that column.
+=======+======+=============+====+======+===+=========+====+ Therefore, the DSCPs in the bottom row have higher survivability
|Assigned |Re-marked |EXP/| * | |Re-marked|EXP/| across an end-to-end Internet path.
| |from AF11..41|LU | | |from |LU | </t>
| | | | | |AF13..EF | | <t>Data on the observed re-marking at the time of writing was
+==============+=============+====+======+===+=========+====+ presented in <xref target="IETF115-IEPG"/>.</t>
]]></artwork>
<postamble>Table showing 0b000xxx DSCPs. This highlights any current <table anchor="table4" align="center">
assignments and whether <name>0b000xxx DSCPs</name>
they are affected by any known re-marking behaviors, such as <thead>
ToS Precdence bleaching. <tr>
* DSCP 4 has been historically used by the SSH application<xref target="K <th>0/&wj;CS0</th>
ol10">.</xref>. <th>1/&wj;LE</th>
</postamble> <th>2</th>
</figure> <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>
<t></t> <dl spacing="normal" newline="false">
<t>DSCPs of the form 0b000xxx can be impacted by known re-marking behav <dt>*</dt>
iours of other assigned DSCPs. <dd>DSCP 4 has been historically used by the SSH application <xref
For example, ToS Precedence Bleaching of popular DSCPs AF11, AF21, AF31, target="Kol10"/></dd>
AF41 would result </dl>
in traffic being re-marked with DSCP 2 in the Internet core.
The Lower-Effort Per-Hop Behavior PHB (LE) uses a DSCP of 1. The DSCP val
ue of 4 has been historically used by the SSH application,
following semantics that precede DiffServ <xref target="Kol10"></xref>.</
t>
<t><xref target="observed-re-marking"> Bleach-ToS-Precedence </xref> o <t><xref target="table4"/> shows 0b000xxx DSCPs. This highlights
f packets with a DSCP 'x' result in the DSCP being any current assignments and whether they are affected by any known
re-marked to 'x' &amp; 0x07 and then forwarded using the PHB specified re-marking behaviors, such as ToS Precedence Bleaching.</t>
for the resulting DSCP in that Diffserv domain.
In subsequent networks the packet will receive treatment as specified b
y the domain's operator corresponding to the re-marked codepoint.</t>
<t>A variation of this observed re-marking behavior clears the top thr <t>DSCPs of the form 0b000xxx can be impacted by known re-marking
ee bits of a behaviors of other assigned DSCPs. For example, ToS Precedence
DSCP, unless these have values 0b110 or 0b111 (corresponding to the Bleaching of popular DSCPs AF11, AF21, AF31, and AF41 would result in
CS6 and CS7 DSCPs). As a result, a DSCP value greater than 48 traffic being re-marked with DSCP 2 in the Internet core. The
decimal (0x30) is less likely to be impacted by ToS Precedence Lower Effort (LE) Per-Hop Behavior PHB uses a DSCP of 1. The DSCP
Bleaching.</t> value of 4 has been historically used by the SSH application,
following semantics that precede Diffserv <xref
target="Kol10"/>.</t>
<t>Bleach-ToS-Precedence (see <xref target="observed-re-marking"/>)
of packets with a DSCP 'x' 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, 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>
<section>
<name>Impact of ToS Precedence Re-marking</name>
<t><xref target="RFC2474"/> states:</t>
<blockquote>Implementors should note that the DSCP field is six bits
wide. DS-compliant nodes <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.</blockquote>
<section title="Impact of ToS Precedence Re-marking"> <t>This replaced re-marking according to ToS precedence (see <xref
target="observed-re-marking"/>) <xref target="RFC1349"/>. These
<t><xref target="RFC2474"></xref> states "Implementors should note tha practices based on ToS semantics have not yet been eliminated from
t deployed networks.</t>
the DSCP field is six bits wide. DS-compliant nodes MUST 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 replaced re-marking according
to ToS precedence (<xref target="observed-re-marking">Re-mark-ToS</xref>) <xref
target="RFC1349"></xref>. These practices based on ToS
semantics have not yet been eliminated from deployed networks.</t>
<figure>
<preamble></preamble>
<artwork><![CDATA[ <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| |0 0 1|x x x|
+-+-+-+-+-+-+ +-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>
<postamble>Figure showing the ToS Precedence Re-marking (<xref targe <t><xref target="fig3"/> shows the ToS Precedence Re-marking
t="observed-re-marking">Re-mark-ToS</xref>) (see <xref target="observed-re-marking"/>) observed
observed behavior, based on Section 3 of <xref behavior, based on <xref target="RFC1349" sectionFormat="of"
target="RFC1349"></xref>. The bit positions marked "x" remain unchan section="3"/>. The bit positions marked 'x' remain unchanged.</t>
ged.</postamble> <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
</figure> CS PHB. This re-marking occurs when routers are not configured to
perform Diffserv re-marking.
<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 perf
orm DiffServ re-marking.
</t> </t>
<t>If ToS Precedence Re-marking occurs, packets are forwarded using
<t>If ToS Precedence Re-marking occurs, packets are forwarded using the PHB spec the PHB specified for the resulting DSCP in that domain. For
ified for the resulting DSCP in that domain. example, the AF31 DSCP (0x1a) could be re-marked to either AF11 or
For example, the AF31 DSCP (0x1a) could be re-marked to either AF11 or AF21. AF21. If such a re-marked packet further traverses other Diffserv
If such a re-marked packet further traverses other Diffserv domains, domains, it would receive treatment as specified by each domain's
it would receive treatment as specified by each domain's operator corresponding operator corresponding to the re-marked codepoint.</t>
to the re-marked codepoint.</t> </section>
</section>
</section> </section>
<section anchor="re-mark">
<section anchor="re-mark" title="Re-marking to a Particular DSCP"> <name>Re-marking to a Particular DSCP</name>
<t>A network device might re-mark the Diffserv field of an IP packet
<t>A network device might re-mark the DiffServ field of an IP packet based on a local policy with a specific set of DSCPs (see <xref
based on a local policy with a specific (set of) DSCPs (<xref target="ob target="observed-re-marking"/>).
served-re-marking"> Re-mark-DSCP </xref>). </t>
<t><xref target="RFC2474" sectionFormat="of" section="3"/> recommends:
"Packets received with an unrecognized codepoint <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: CS0 (0x00). This re-marking is
sometimes performed using a Multi-Field (MF) classifier <xref
target="RFC2475"/> <xref target="RFC3290"/> <xref target="RFC4594"/>.
</t> </t>
<t>
Section 3 of <xref target="RFC2474"></xref> recommends:
"Packets received with an unrecognized codepoint SHOULD be forwarded as i
f
they were marked for the Default behavior, and their codepoints
should not be changed." Some networks might not follow this recommendati
on
and instead re-mark packets with these codepoints to the default class, C
S0 (0x00).
This re-marking
is sometimes performed using a Multi-Field (MF) classifier <xref
target="RFC2475"></xref> <xref target="RFC3290"></xref> <xref
target="RFC4594"></xref>.
</t>
<t> <t>
If re-marking occurs, If re-marking occurs, packets are forwarded using the PHB specified
packets are forwarded using the PHB specified for the resulting DSCP in t for the resulting DSCP in that domain. As an example, re-marking
hat domain. traffic AF31, AF32, and AF33 all to a single DSCP, e.g., AF11, stops
As an example, re-marking traffic AF31, AF32 and AF33 all to a single DSC any drop probability differentiation, which may have been expressed by
P, e.g. AF11, stops these three DSCPs. If such a re-marked packet further traverses other
any drop probability differentiation, which may have been expressed domains, it would receive treatment as specified by the domain's
by these three DSCPs. If such a re-marked packet further traverses operator corresponding to the re-marked codepoint. Bleaching (see
other domains, it would receive treatment as specified by the domain's o <xref target="observed-re-marking"/>) is a specific example of this
perator observed re-marking behavior that re-marks to CS0 (0x00) (see <xref
corresponding to the re-marked codepoint. Bleaching target="Bleaching"/>).</t>
(<xref target="observed-re-marking">Bleach-DSCP</xref>) is a specific ex
ample of this observed re-marking behavior that re-marks to CS0
(0x00) - see <xref target="Bleaching"></xref>.</t>
</section> </section>
</section> </section>
<section anchor="lowerlayers">
<section anchor="lowerlayers" title="Interpretation of the IP DSCP at Lower <name>Interpretation of the IP DSCP at Lower Layers</name>
Layers">
<t>Transmission systems and subnetworks can, and do, utilize the <t>Transmission systems and subnetworks can, and do, utilize the
DiffServ field in an IP packet to set a QoS-related field or function at 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 the lower layer. A lower layer could also implement a
function that could re-mark the DSCP used at the IP layer. This traffic-conditioning function that could re-mark the DSCP used at the IP
function is constrained by designs that layer. This function is constrained by designs that utilize fewer than
utilize fewer than 6 bits to express the service class, and therefore 6 bits to express the service class and, therefore, infer a mapping to a
infer a mapping to a smaller L2 QoS field, for example, smaller L2 QoS field, for example, the 3-bit Priority Code Point (PCP) fie
the 3-bit PCP field in an IEEE Ethernet 802.1Q header, the 3-bit UP fiel ld in an IEEE
d or Ethernet 802.1Q header, the 3-bit User Priority (UP) field, or the 3-bit T
the 3-bit Traffic Class field of Multi-Protocol Label Switching (MPLS). raffic Class
A Treatment Aggregate (TA) <xref target="RFC5127"></xref> field of Multi-Protocol Label Switching (MPLS). A Treatment Aggregate
is an optional intermediary mapping groups of BAs to PHBs. (TA) <xref target="RFC5127"/> is an optional intermediary mapping group
</t> of BAs to PHBs.
</t>
<section title="Mapping Specified for IEEE 802"> <section>
<t>The IEEE specifies standards that include mappings for DSCPs to lower <name>Mapping Specified for IEEE 802</name>
layer elements.</t> <t>The IEEE specifies standards that include mappings for DSCPs to
lower layer elements.</t>
<section title="Mapping Specified for IEEE 802.1"> <section>
<name>Mapping Specified for IEEE 802.1</name>
<t>IEEE 802.1Q specified a 3-bit Priority Code Point (PCP) field, which <t>IEEE 802.1Q specified a 3-bit PCP field, which includes a tag
includes a that allows Ethernet frames to be marked as one of eight priority
tag that allows Ethernet frames to be marked as one of eight priority va values <xref target="IEEE-802.1Q"/>. Use of this field is
lues <xref described by various documents, including IEEE P802.1p and IEEE
target="IEEE-802-1Q"></xref>. Use of this field is described by various 802.1D.</t>
documents, including IEEE P802.1p, and IEEE 802.1D.</t> <t>The mapping specified in <xref target="IEEE-802.1Q"/>
revises a previous standard, <xref target="IEEE-802.1D"/>, in
<t>The mapping specified in <xref target="IEEE-802-1Q"></xref> revises an effort to align with Diffserv practice <xref target="RFC4594"/>.
a previous standard <xref target="IEEE-802-1D"></xref>, in an effort In 802.1Q, the traffic types are specified to match the first three
to align with DiffServ practice <xref target="RFC4594"></xref>. bits of a suitable DSCP (e.g., the first three bits of the Expedited F
In 802.1Q, the traffic types are specified to orwarding (EF) DSCP
match the first three bits of a suitable DSCP are mapped to a PCP of 5).</t> <t> In this mapping, PCP0 is used to
(e.g., the first three bits of the EF DSCP are mapped to a PCP of 5).</t> indicate the default Best Effort treatment, and PCP1 indicates a
background traffic class. The remaining PCP values
<t> In this mapping, PCP0 is used to indicate the default indicate increasing priority. Internet control traffic can be
best effort treatment, and PCP1 indicates a background marked as CS6, and network control is marked as CS7.</t>
traffic class. This aligned with the now deprecated use of <t>Other re-marking behaviors have also been implemented in Ethernet
CS1 as the codepoint for the lower effort equipment. Historically, a previous standard, <xref
service, as previously specified in <xref target="RFC4594"></xref>. target="IEEE-802.1D"/>, used both PCP1 (Background) and PCP2
The remaining PCP values indicate increasing priority. (Spare) to indicate lower priority than PCP0, and some other devices
Internet control traffic can be marked as CS6, and network control is do not assign a lower priority to PCP1.</t>
marked as CS7.</t> </section>
<section anchor="mapping_for_802.11">
<t>Other re-marking behaviors have also been implemented in Ethernet equi <name>Mapping Specified for IEEE 802.11</name>
pment. <t><xref target="RFC8325" sectionFormat="of" section="6"/> provides
Historically, a previous standard <xref target="IEEE-802-1D"></xref> a brief overview of IEEE 802.11 QoS. The IEEE <xref
used both PCP1 (Background) and target="IEEE-802.11">802.11 standards</xref> provide Media
PCP2 (Spare) to indicate lower priority than PCP0, and Access Control (MAC) functions to support QoS in WLANs using Access
some other devices do not assign a lower priority to PCP1.</t> Categories (ACs). The upstream UP in the 802.11 header has a 3-bit QoS
value. A DSCP can be mapped to the UP. <xref target="RFC8622"/>
</section> added a mapping for the LE DSCP to
AC_BK (Background).</t>
<section title="Mapping Specified for IEEE 802.11"> <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
<t>Section 6 of <xref target="RFC8325"></xref> provides a is an example of equipment still classifying on ToS Precedence
brief overview of IEEE 802.11 QoS. The IEEE <xref (which could be seen as a simple method to map IP layer Diffserv to
target="IEEE-802-11">802.11 standards</xref> provide MAC functions to layers offering only 3-bit QoS codepoints). Then, in turn, this is
support QoS in WLANs using Access Classes (AC). The upstream User mapped to the four Wi-Fi Multimedia (WMM) Access Categories. The
Priority (UP) in the 802.11 header has a 3-bit QoS value. A DSCP can Wi-Fi Alliance has also specified a more flexible mapping that
be mapped to the UP. <xref target="RFC8622"></xref> added follows <xref target="RFC8325"/> and provides functions at an Access
mapping for the LE DSCP, mapping this to AC_BK (Background)</t> Point (AP) to re-mark packets as well as a QoS Map that maps each
DSCP to an AC <xref target="WIFI-ALLIANCE"/>.</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 to layer
s 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 mappin
g
that follows RFC8325 and provides functions at an AP to re-mark packets a
s
well as a QoS Map that maps each DSCP to an AC <xref target="WIFI-ALLIAN
CE"></xref>.</t>
<figure>
<preamble></preamble>
<figure anchor="fig4">
<name>DSCP Bits Commonly Mapped to the UP in 802.11</name>
<artwork><![CDATA[ <artwork><![CDATA[
+-+-+-+-+-+-+ +-+-+-+-+-+-+
|5|4|3|2|1|0|
+-+-+-+-+-+-+
|x x x|. . .| |x x x|. . .|
+-+-+-+-+-+-+ +-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>
<postamble>Figure showing the DSCP bits commonly mapped to the UP in <t>The bit positions marked 'x' are mapped
802.11. The bit positions marked "x" are mapped to the 3-bit UP value, to the 3-bit UP value, while the ones marked '.' are ignored.</t>
while the ones marked "." are ignored.</postamble>
</figure>
<t></t>
<t><xref target="RFC8325">RFC8325</xref> notes inconsistencies that <t><xref target="RFC8325"/> notes inconsistencies that
can result from such re-marking, and recommends a different mapping to p can result from such re-marking and recommends a different mapping
erform this to perform this re-marking, dependent on the direction in which a
re-marking, dependent on the direction in which a packet is forwarded. packet is forwarded. It provides recommendations for mapping a DSCP
It provides recommendations for mapping a DSCP to an IEEE 802.11 UP to an IEEE 802.11 UP for interconnection between wired and wireless
for interconnection between wired and wireless networks. networks. The recommendation in <xref target="mapping_for_802.11"/> m
The recommendation in Section 5.1.2 maps network control traffic, CS6 and aps network control
CS7, traffic, CS6 and CS7, as well as unassigned DSCPs, to UP 0 when
as well as unassigned DSCPs, to UP 0 when forwarding in the upstream dire forwarding in the upstream direction (wireless-to-wired). It also
ction (wireless-to-wired). recommends mapping CS6 and CS7 traffic to UP 7 when forwarding in
It also recommends mapping CS6 and CS7 traffic to UP 7, the downstream direction (<xref target="RFC8325" sectionFormat="of" se
when forwarding in the downstream direction (Section 4.1).</t> ction="4.1"/>).</t>
<t>For other UPs, <xref target="RFC8325"/> recommends a mapping in
the upstream direction (wireless-to-wired interconnections) that deriv
es the DSCP from the value of the
UP multiplied by 8. This mapping, currently used by
some Access Points (APs), can result in a specific DSCP re-marking beh
avior:</t>
<t>For other UPs, RFC8325 recommends a mapping in the upstream direction <blockquote>wherein DSCP values are derived from UP values by
that derives the multiplying the UP values by 8 (i.e., shifting the three UP bits to
DSCP from the value of the UP multiplied by 8. the left and adding three additional zeros to generate a DSCP
This mapping can result in a specific DSCP re-marking behavior.</t> value). This derived DSCP value is then used for QoS treatment
<t>In the upstream direction (wireless-to-wired interconnections), between the wireless AP and the nearest classification and marking
this mapping can result in a specific DSCP re-marking behavior. policy enforcement point (which may be the centralized wireless LAN
Some Access Points (APs) currently use a controller, relatively deep within the network). Alternatively, in
default UP-to-DSCP mapping <xref target="RFC8325"></xref>, the case where there is no other classification and marking policy
wherein "DSCP values are derived from the layer 2 UP values by enforcement point, then this derived DSCP value will be used on the
multiplying the UP values by eight (i.e., shifting the three UP bits remainder of the Internet path.</blockquote>
to the left and adding three additional zeros to generate a 6-bit DSCP
value). This derived DSCP value is used for QoS treatment between
the wireless AP and the nearest classification and marking policy
enforcement point (which may be a central 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 can result in
re-marking by <xref target="observed-re-marking">Bleach-low</xref>.</t>
<figure> <t>This can result in re-marking by Bleach-low (see <xref
<preamble></preamble> target="observed-re-marking"/>).</t>
<artwork><![CDATA[ <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| |x x x|0 0 0|
+-+-+-+-+-+-+ +-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure>
<postamble>Figure showing the observed re-marking behavior resulting f <t>An alternative to UP-to-DSCP remapping uses the DSCP value of a
rom deriving from UP-to-DSCP mapping in some downstream IP packet (e.g., the Control and Provisioning of Wireless
802.11 networks.</postamble> Access Points, CAPWAP, protocol <xref target="RFC5415"/> maps an IP
</figure> packet Diffserv field to the Diffserv field of the outer IP header
in a CAPWAP tunnel).</t>
<t>An alternative to UP-to-DSCP remapping uses <t>Some current constraints of Wi-Fi mapping are discussed in <xref
the DSCP value of a downstream IP packet (e.g., the Control And Provisio target="RFC8325" sectionFormat="of" section="2"/>. A QoS profile can
ning of Wireless be used to limit the maximum DSCP value used for the upstream and
Access Points (CAPWAP) protocol, <xref target="RFC5415">RFC5415</xref>, downstream traffic.</t>
maps an IP packet DiffServ field to the </section>
DiffServ field of the outer IP header in a CAPWAP </section>
tunnel).</t> <section anchor="mpls">
<name>Diffserv and MPLS</name>
<t>Some current constraints of Wi-Fi mapping are discussed in Section 2 <t>Multi-Protocol Label Switching (MPLS) specified eight MPLS Traffic
of <xref target="RFC8325"></xref>. A QoS profile can be used to limit Classes (TCs), which restrict the number of different treatments <xref
the maximum DSCP value used for the upstream and downstream target="RFC5129"/>. <xref target="RFC5127"/> describes the
traffic.</t> aggregation of Diffserv service classes and introduces four Diffserv TAs
</section> . Traffic
marked with multiple DSCPs can be forwarded in a single MPLS TC.</t>
</section> <t>There are three Label Switching Router (LSR) models: the Pipe, the
Short Pipe, and the Uniform Model <xref target="RFC3270"/>. In the
<section anchor="mpls" title="DiffServ and MPLS"> Uniform and Pipe models, the egress MPLS router forwards traffic based
on the received MPLS TC. The Uniform Model includes an egress DSCP
<t>Multi-Protocol Label Switching (MPLS) specified eight MPLS Traffic rewrite. With the Short Pipe Model, the egress MPLS router forwards
Classes (TCs), which restrict the number of different treatments traffic based on the Diffserv DSCP as present at the egress router. If
<xref target="RFC5129"></xref>. RFC 5127 describes the aggregation of the domain supports IP and MPLS QoS differentiation, controlled
DiffServ TCs <xref target="RFC5127"></xref> behavior requires the DSCP of an (outer) IP header to be assigned or
and introduces four DiffServ Treatment Aggregates. Traffic marked re-written by all domain ingress routers to conform with the domain's
with multiple DSCPs can be forwarded in a single MPLS TC.</t> internal Diffserv deployment. Note that the Short Pipe Model is
prevalent in MPLS domains.
<t>There are three Label-Switched Router (LSR) models: the Pipe, the </t>
Short Pipe and the Uniform Model <xref target="RFC3270"></xref>. <section>
In the Uniform and Pipe models, the egress MPLS router forwards <name>Mapping Specified for MPLS</name>
traffic based on the received MPLS TC. The Uniform Model includes <t><xref target="RFC3270"/> defines a flexible solution
an egress DSCP rewrite. With the Short Pipe Model, the for support of Diffserv over MPLS networks. This allows an MPLS
egress MPLS router forwards traffic based on the 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 deployment.
Note that the Short Pipe Model is prevalent in MPLS domains.
</t>
<section title="Mapping Specified for MPLS">
<t><xref target="RFC3270">RFC3270</xref> defines a flexible solution
for support of DiffServ over MPLS networks. This allows an MPLS
network administrator to select how BAs (marked by DSCPs) are mapped network administrator to select how BAs (marked by DSCPs) are mapped
onto Label Switched Paths (LSPs) to best match the DiffServ, Traffic onto Label Switched Paths (LSPs) to best match the Diffserv, Traffic
Engineering and protection objectives within their particular Engineering, and protection objectives within their particular
network.</t> network.</t>
<t>Mappings from the IP DSCP to the MPLS header are defined in <t>Mappings from the IP DSCP to the MPLS header are defined in
Section 4.2 of <xref target="RFC3270"></xref>.</t> <xref target="RFC3270" sectionFormat="of" section="4.2"/>.</t>
<t>The Pipe Model conveys the "LSP Diff-Serv Information" <t>The Pipe Model conveys the "LSP Diff-Serv Information"
to the LSP Egress so that its forwarding treatment can be based on to the LSP Egress so that its forwarding treatment can be based on
the IP DSCP.</t> the IP DSCP.</t>
<t>When Penultimate Hop Popping (PHP) is used, the Penultimate LSR <t>When Penultimate Hop Popping (PHP) is used, the Penultimate LSR
needs to be aware of the encapsulation mapping for a PHB to needs to be aware of the encapsulation mapping for a PHB to the
the label corresponding to the exposed header to perform DiffServ label corresponding to the exposed header to perform Diffserv
Information Encoding (Section 2.5.2 of <xref Information Encoding (<xref target="RFC3270" sectionFormat="of"
target="RFC3270"></xref>).</t> section="2.5.2"/>).</t>
</section> </section>
<section>
<section title="Mapping Specified for MPLS Short Pipe"> <name>Mapping Specified for MPLS Short Pipe</name>
<t>The Short Pipe Model is an optional variation of the Pipe Model <t>The Short Pipe Model is an optional variation of the Pipe Model
<xref target="RFC3270"></xref>.</t> <xref target="RFC3270"/>.</t>
<t><xref target="ITU-T-Y.1566">ITU-T Y.1566</xref> further defined a
<t>ITU-T <xref target="ITU-T-Y-1566">Y.1566</xref> further defined a
set of four common QoS classes and four auxiliary classes to which a set of four common QoS classes and four auxiliary classes to which a
DSCP can be mapped when interconnecting Ethernet, IP and MPLS DSCP can be mapped when interconnecting Ethernet, IP, and MPLS
networks. <xref target="RFC8100"></xref> describes four networks. <xref target="RFC8100"/> describes four
treatment aggregates for interconnection with four defined DSCPs. TAs for interconnection with four defined DSCPs.
This was motivated by the requirements of MPLS network operators This was motivated by the requirements of MPLS network operators
that use Short-Pipe tunnels, but can be applicable to other that use Short Pipe tunnels but can be applicable to other
networks, both MPLS and non-MPLS.</t> networks, both MPLS and non-MPLS.</t>
<t><xref target="RFC8100"/> recommends preserving the notion of
end-to-end service 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 <xref target="RFC8100"/>
limits the number of DSCPs to 6, and 3 more are suggested for
extension. <xref target="RFC8100"/> respects the deployment of PHB
groups for DS 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 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"/>
behavior) or dealt with via additional agreements among the
operators of the interconnected networks. <xref target="RFC8100"/>
can be extended to support up to 32 DSCPs by future standards. <xref
target="RFC8100"/> is operated by at least one Tier 1 backbone
provider. Use of the MPLS Short Pipe Model favors re-marking
unexpected DSCP values to zero in the absence of additional
agreements, as explained in <xref target="RFC8100"/>. This can
result in bleaching (see <xref target="observed-re-marking"/>).
</t>
<t>RFC8100 recommends preserving the notion of end-to-end service <table anchor="table5" align="center">
classes, and recommends a set of standard DSCPs mapped to a small set <name>The Short Pipe MPLS Mapping from <xref target="RFC8100"/></name>
of <thead>
standard PHBs at interconnection. The key requirement is that the DSCP <tr>
at the <th>Treatment Aggregate <xref target="RFC8100"/></th>
network ingress is restored at the network egress. The current version <th align="center">DSCP</th>
of </tr>
RFC8100 limits the number of DSCPs to 6 and 3 more are suggested for ex </thead>
tension. <tbody>
RFC8100 respects the deployment of PHB groups for DS domain internal us <tr>
e, which <td>Telephony&nbsp;Service&nbsp;Treatment&nbsp;Aggregate</td>
limits the number of acceptable external DSCPs (and possibilities for t <td align="center">EF<br/>VA</td>
heir </tr>
transparent transport or restoration at network boundaries). In this d <tr>
esign, <td>Bulk Real-Time Treatment Aggregate</td>
packets marked with DSCPs not part of the RFC8100 codepoint scheme are <td align="center">AF41<br/>(AF42)*<br/>(AF43)*</td>
treated </tr>
as unexpected and will possibly be re-marked (a <xref target="observed- <tr>
re-marking">Re-mark-DSCP</xref> behavior) or dealt <td>Assured Elastic Treatment Aggregate</td>
with via an additional agreement(s) among the operators of the intercon <td align="center">AF31<br/>AF32<br/>(AF33)**</td>
nected </tr>
networks. RFC8100 can be extended to support up to 32 DSCPs by future <tr>
standards. RFC8100 is operated by at least one Tier 1 backbone provider <td>Default / Elastic Treatment Aggregate</td>
. Use <td align="center">BE/CS0</td>
of the MPLS Short Pipe Model favours re-marking unexpected DSCP values </tr>
to zero <tr>
in the absence of an additional agreement(s), as explained in <xref <td>Network Control: Local Use (LU)</td>
target="RFC8100"></xref>. This can result in bleaching (<xref target="o <td align="center">CS6</td>
bserved-re-marking">Bleach-DSCP</xref>). </tr>
</t> </tbody>
</table>
<figure>
<preamble></preamble>
<artwork><![CDATA[
+--------------------------------------+--------+
| RFC8100 | DSCP |
| Agg. Class | |
+--------------------------------------+--------+
|Telephony Service Treatment Aggregate | EF |
| | VA |
+--------------------------------------+--------+
|Bulk Real-Time Treatment Aggregate | AF41 |
| May be added | (AF42) |
| May be added | (AF43) |
+--------------------------------------+--------+
|Assured Elastic Treatment Aggregate | AF31 |
| | AF32 |
| Reserved for the extension of PHBs| (AF33) |
+--------------------------------------+--------+
|Default / Elastic Treatment Aggregate | BE/CS0 |
+--------------------------------------+--------+
|Network Control: Local Use (LU) | CS6 |
+--------------------------------------+--------+
]]></artwork> <dl spacing="normal" newline="false">
<dt>*</dt>
<dd>May be added</dd>
<dt>**</dt>
<dd>Reserved for the extension of PHBs</dd>
</dl>
<postamble>Table: The short-pipe MPLS mapping from RFC
8100.</postamble>
</figure>
</section> </section>
</section> </section>
<section>
<section title="Mapping Specified for Mobile Networks"> <name>Mapping Specified for Mobile Networks</name>
<t>Mobile LTE and 5G standards have evolved from older Universal
<t>Mobile LTE and 5G standards have evolved from older UMTS standards, Mobile Telecommunications System (UMTS) standards and support
and support DiffServ. LTE (4G) and 5G standards <xref Diffserv. LTE (4G) and 5G standards <xref target="SA-5G"/> identify
target="SA-5G"></xref> identify traffic classes at the interface traffic classes at the interface between User Equipment (UE) and the
between User Equipment (UE) and the mobile Packet Core network by QCI mobile Packet Core network by QCI (QoS Class Identifiers) and 5QI (5G
(QoS Class Identifiers) and 5QI (5G QoS Identifier). The 3GPP QoS Identifier). The 3GPP standards do not define or recommend any
standards do not define or recommend any specific mapping between specific mapping between each QCI or 5QI and Diffserv (and mobile QCIs
each QCI or 5QI and DiffServ (and mobile QCIs are based on several are based on several criteria service class definitions). The way
criteria service class definitions). The way packets are mapped at the packets are mapped at the Packet Data Network Gateway (P-GW) boundary
Packet Gateway (P-GW) boundary is determined by network operators. Howev is determined by network operators. However, TS 23.107 (version
er, TS 16.0.0, applies to LTE and below) mandates that Differentiated
23.107 (version 16.0.0, applies to LTE and below) mandates that Services, defined by the IETF, shall be used to interoperate with IP
Differentiated Services, defined by IETF, shall be used to backbone networks.</t>
interoperate with IP backbone networks.</t>
<t>The GSM Association (GSMA) has defined four aggregated classes and <t>The GSM Association (GSMA) has defined four aggregated classes and
seven associated PHBs in their guidelines for IPX Provider networks seven associated PHBs in their guidelines for IP Packet eXchange (IPX) P
<xref target="GSMA-IR-34"></xref>. rovider networks
This was previously specified as the Inter-Service Provider IP Backbone Guidelin <xref target="GSMA-IR.34"/>. This was previously specified as the
es, "Inter-Service Provider IP Backbone Guidelines" and provides a mobile
and provides a mobile ISP to ISP QoS mapping mechanism, and interconnecti ISP to ISP QoS mapping mechanism and interconnection with other IP
on networks in the general Internet. If provided an IP VPN, the operator
with other IP networks in the general Internet. If provided an is free to apply its DS domain-internal codepoint scheme at outer
IP VPN, the operator is free to apply its DS Domain internal code headers and inner IPX DSCPs may be transported transparently. The
point guidelines also describe a case where the DSCP marking from a Service
scheme at outer headers and inner IPX DSCPs may be transported tr Provider cannot be trusted (depending on the agreement between the
ansparently. Service Provider and its IPX Provider). In this situation, the IPX
The guidelines also describe a case where the DSCP marking from a Provider can re-mark the DSCP value to a static default value.
Service
Provider cannot be trusted (depending on the agreement between th
e Service Provider
and its IPX Provider), in which situation the IPX Provider can re
-mark
the DSCP value to a static default value.
</t> </t>
<t><figure> <table anchor="table6" align="center">
<preamble></preamble> <name>The PHB Mapping Recommended in the Guidelines Recommended in <xref
target="GSMA-IR.34"/></name>
<artwork><![CDATA[ <thead>
+---------------+-------+ <tr>
| GSMA IR.34 | PHB | <th><t>QoS Class in <xref target="GSMA-IR.34"/></t></th>
| Agg. Class | | <th>PHB</th>
+---------------+-------+ </tr>
|Conversational | EF | </thead>
+---------------+-------+ <tbody>
| Streaming | AF41 | <tr>
+---------------+-------+ <td>Conversational</td>
| Interactive | AF31 | <td>EF</td>
+ +-------+ </tr>
| (ordered by | AF32 | <tr>
+ priority, +-------+ <td>Streaming</td>
| AF3 highest) | AF21 | <td>AF41</td>
+ +-------+ </tr>
| | AF11 | <tr>
+---------------+-------+ <td rowspan="4"><t>Interactive</t><t>(ordered by priority, AF3 highest)</t
| Background | CS0 | ></td>
+---------------+-------+ <td>AF31</td>
</tr>
]]></artwork> <tr>
<td>AF32</td>
<postamble>Table showing the PHB mapping recommended in the guidelin </tr>
es recommended in <xref <tr>
target="GSMA-IR-34"></xref>.</postamble> <td>AF21</td>
</figure></t> </tr>
<tr>
<td>AF11</td>
</tr>
<tr>
<td>Background</td>
<td>CS0</td>
</tr>
</tbody>
</table>
<t></t>
</section> </section>
<section>
<section title="Mapping Specified for Carrier Ethernet"> <name>Mapping Specified for Carrier Ethernet</name>
<t>MEF Forum (MEF) provides a mapping of DSCPs at
<t>Metro Ethernet Forum (MEF) provides a mapping of DSCPs at
the IP layer to quality of service markings in the Ethernet frame the IP layer to quality of service markings in the Ethernet frame
headers <xref target="MEF23.1"></xref>.</t> headers <xref target="MEF-23.1"/>.</t>
</section> </section>
<section>
<section title="Re-marking as a Side-effect of Another Policy"> <name>Re-marking as a Side Effect of Another Policy</name>
<t>This includes any other re-marking that does not happen as a result o <t>This includes any other re-marking that does not happen as a result
f traffic conditioning, such as of traffic conditioning, such as policies and L2 procedures that
policies and L2 procedures that result in re-marking traffic as result in re-marking traffic as a side effect of other functions
a side-effect of other functions (e.g., in response to Distributed Denia (e.g., in response to Distributed Denial of Service, DDoS).</t>
l of Service, DDoS).</t>
</section> </section>
<section>
<section title="Summary"> <name>Summary</name>
<t>This section has discussed the various ways in which DSCP re-marking <t>This section has discussed the various ways in which DSCP
behaviors can arise from interactions with lower layers.</t> re-marking behaviors can arise from interactions with lower
<t> A provider service path may consist of sections where multiple a layers.</t>
nd <t> A provider service path may consist of sections where multiple and
changing layers use their own code points to determine changing layers use their own code points to determine differentiated
differentiated forwarding (e.g., IP - MPLS - IP - Ethernet - forwarding (e.g., IP to MPLS to IP to Ethernet to Wi-Fi).</t>
Wi-Fi).</t>
</section> </section>
</section> </section>
<section>
<section title="Considerations for DSCP Selection"> <name>Considerations for DSCP Selection</name>
<t>This section provides advice for the assignment of a new DSCP value. <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 n It is intended to aid the IETF and IESG in considering a request for a
ew DSCP. new DSCP. This section identifies known issues that might influence the
The section identifies known issues that might influence the finally assig finally assigned DSCP and provides a summary of considerations for
ned assignment of a new DSCP.</t>
DSCP, and provides a summary of considerations for assignment of a new <section>
DSCP.</t> <name>Effect of Bleaching and Re-marking to a Single DSCP</name>
<t><xref target="observed-re-marking"/> describes re-marking of the
<section title="Effect of Bleaching and Re-marking to a single DSCP"> DSCP. New DSCP assignments should consider the impact of bleaching or
<t>Section 4 describes re-marking of the DSCP. re-marking (see <xref target="observed-re-marking"/>) to a single
New DSCP assignments should consider the impact of bleaching DSCP, which can limit the ability to provide the expected treatment
(<xref target="observed-re-marking">Bleach-DSCP</xref>) or re-marking (<x end-to-end. This is particularly important for cases where the
ref target="observed-re-marking">Re-mark-DSCP</xref>) to a single DSCP, which ca codepoint is intended to result in lower than Best Effort treatment,
n limit as was the case when defining the LE PHB <xref target="RFC8622"/>.
the ability to provide the expected treatment end-to-end. This is Forwarding LE using the default PHB is in line with <xref
particularly important for cases where the codepoint is intended to target="RFC8622"/>, but it is recommended to maintain the distinct LE
result in lower than best effort treatment, as was the case when DSCP codepoint end-to-end to allow for differentiated treatment by
defining the LE PHB <xref target="RFC8622"></xref>. domains supporting LE. Rewriting the LE DSCP to the default class
Forwarding LE using the default PHB is in line with RFC8622, but (CS0) results in an undesired promotion of the priority for LE traffic
it is recommended to maintain the distinct LE DSCP codepoint in such a domain. Bleaching the lower three bits of the DSCP (both
end-to-end to allow for differentiated treatment by Bleach-low and Bleach-some-low in <xref
domains supporting LE. Rewriting the LE DSCP to the default class (CS0) target="observed-re-marking"/>), as well as re-marking to a particular
results in an undesired promotion of the priority for LE traffic in such DSCP, can result in similar changes of priority relative to traffic
a domain. that is marked with other DSCPs.
Bleaching the lower three bits of the DSCP (both <xref target="observed-r </t>
e-marking">Bleach-low</xref>
and <xref target="observed-re-marking">Bleach-some-low</xref>), as well a
s re-marking to a particular
DSCP can result in similar changes of priority relative to traffic that
is marked with other DSCPs.
</t>
</section> </section>
<section>
<section title="Where the proposed DSCP &gt; 0x07 (7)"> <name>Where the Proposed DSCP &gt; 0x07 (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 <t>Although the IETF specifications require systems to use DSCP
marking semantics in place of methods based on the former ToS field, marking semantics in place of methods based on the former ToS field,
the current recommendation is that any new assignment where the the current recommendation is that any new assignment where the DSCP
DSCP is greater than 0x07 should consider the semantics is greater than 0x07 should consider the semantics associated with the
associated with the resulting DSCP when the ToS Precedence is bleached ( resulting DSCP when the ToS Precedence is bleached
<xref target="observed-re-marking">Bleach-ToS-Precedence</xref> and <xref target (Bleach-ToS-Precedence and Bleach-some-ToS, <xref
="observed-re-marking"> Bleach-some-ToS </xref>) target="observed-re-marking"/>) or ToS Precedence Re-marking
or ToS Precedence Re-marking (<xref target="observed-re-marking">Re-mark- (Re-mark-ToS, <xref target="observed-re-marking"/>) is experienced. For
ToS</xref>) is example, it can be desirable to avoid choosing a DSCP that could be
experienced. For example, it can be desirable to avoid choosing a DSCP re-marked to LE, <xref target="RFC8622">Lower Effort</xref>, which
that could be re-marked to LE, <xref target="RFC8622">Lower could otherwise potentially result in a priority inversion in the
Effort</xref>, which could otherwise potentially result in a priority treatment.</t>
inversion in the treatment.</t>
<section title="Where the proposed DSCP&amp;0x07=0x01">
<t>As a consequence of assigning the LE PHB <xref
target="RFC8622"></xref>, the IETF allocated the DSCP 0b000001 from
Pool 3.</t>
<t>When making assignments where the DSCP has a format: 0bxxx001, <section>
the case of <xref target="observed-re-marking">Bleach-ToS-Precedence</ <name>Where the Proposed DSCP&amp;0x07=0x01</name>
xref> of a <t>This considers a proposed DSCP where the least significant 3 bits to
DSCP to a value of 0x01 needs to be considered. ToS Precedence gether represent a value of 1 (i.e., 0b001).</t>
Bleaching will result in demoting the traffic to the lower effort <t>As a consequence of assigning the LE PHB <xref
traffic class. Care should be taken to consider the implications target="RFC8622"/>, the IETF allocated the DSCP 0b000001 from Pool
of re-marking 3.</t>
when choosing to assign a DSCP with this format.</t> <t>When making assignments where the DSCP has a format "0bxxx001",
the case of 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 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> </section>
<section>
<section title="Where the proposed DSCP &lt;= 0x07 (7)"> <name>Where the Proposed DSCP &lt;= 0x07 (7)</name>
<t>ToS Precedence Bleaching or ToS Precedence Re-marking can unintention <t>This considers a proposed DSCP where the DSCP is less than or equal to
ally result in extra traffic 7.</t>
aggregated to the same DSCP. For example, after experiencing ToS Precede <t>ToS Precedence Bleaching or ToS Precedence Re-marking can
nce unintentionally result in extra traffic aggregated to the same
Bleaching, all traffic marked AF11, AF21, AF31 and AF41 would be DSCP. For example, after experiencing ToS Precedence Bleaching, all
aggregated with traffic marked with DSCP 2 (0x02), increasing the traffic marked AF11, AF21, AF31, and AF41 would be aggregated with
volume of traffic which receives the treatment associated with DSCP 2. traffic marked with DSCP 2 (0x02), increasing the volume of traffic
New DSCP assignments should consider unexpected that receives the treatment associated with DSCP 2. New DSCP
consequences arising from this observed re-marking behavior.</t> assignments should consider unexpected consequences arising from this
observed re-marking behavior.</t>
</section> </section>
<section anchor="networks">
<section anchor= "networks" title="Impact on deployed infrastructure"> <name>Impact on Deployed Infrastructure</name>
<t>Behavior of deployed PHBs and conditioning treatments also needs <t>Behavior of deployed PHBs and conditioning treatments also needs to
to be considered when assigning a new DSCP. Network operators have choic be considered when assigning a new DSCP. Network operators have
es choices when it comes to configuring Diffserv support within their
when it comes to configuring DiffServ support within their domains, and domains, and the observed re-marking behaviors described in the
the observed re-marking behaviors previous section can result from different configurations and
described in the previous section can result from different configuration approaches:</t>
s <dl newline="true" spacing="normal">
and approaches:</t> <dt>Networks not re-marking Diffserv:</dt>
<t><list style="hanging"> <dd>A network that either does not implement PHBs or implements one
<t hangText="Networks not re-marking DiffServ:"> A network that eith or more PHBs while restoring the DSCP field at network egress with
er does not implement PHBs, or the value at network ingress. Operators in this category pass all
implements one or more PHBs whilst restoring the DSCP field a DSCPs transparently.</dd>
t network egress with the value <dt>Networks that condition the DSCP:</dt>
at network ingress. Operators in this category pass all DSCPs <dd>A network that implements more than one PHB and enforces Service
transparently.</t> Level Agreements (SLAs) with its peers. Operators in this category
<t hangText="Networks that condition the DSCP:"> A network that impl use conditioning to ensure that only traffic that matches a policy
ements more than one PHB and enforces is permitted to use a specific DSCP (see <xref target="RFC8100"/>).
Service Level Agreements (SLAs) with its peers. Operators in this categor Operators need to classify the received traffic, assign it to a
y use conditioning to ensure that corresponding PHB, and could re-mark the DSCP to a value that is
only traffic that matches a policy is permitted to use a specific DSCP ( appropriate for the domain's deployed Diffserv infrastructure.</dd>
see <xref target="RFC8100"></xref>). <dt>Networks that re-mark in some other way, which includes:</dt>
Operators need to classify the received traffic, assign it to a correspon <dd>
ding PHB, and could <ol spacing="normal" type="1">
re-mark the DSCP to a value that is appropriate for the domain's deployed <li>Networks containing misconfigured devices that do not comply
DiffServ infrastructure.</t> with the relevant RFCs.</li>
<t hangText="Networks that re-mark in some other way, which includes <li>Networks containing devices that implement an obsolete
:"> specification or contain software bugs.</li>
</t> <li>Networks containing devices that re-mark the DSCP as a
<t><list style='numbers'> result of lower layer interactions.</li>
<t>Networks containing misconfigured devices that do not comply </ol>
with the relevant RFCs.</t> </dd>
<t>Networks containing devices that implement an obsolete specif </dl>
ication or contain software bugs.</t> <t> The DSCP re-marking corresponding to the Bleach-ToS-Precedence
<t>Networks containing devices that re-mark the DSCP as a result (<xref target="observed-re-marking"/>)
of lower layer interactions.</t> observed behavior can arise for various reasons, one of which is old
</list></t> equipment that precedes Diffserv. The same re-marking can also arise
</list></t> in some cases when traffic conditioning is provided by Diffserv
<t> routers at operator boundaries or as a result of misconfiguration.
The DSCP re-marking corresponding to the <xref target="observed-re-markin </t>
g">Bleach-ToS-Precedence</xref>
observed behavior described in Section 4 can arise for various reasons, o
ne of which is old equipment which precedes DiffServ.
The same re-marking can also arise in some cases when traffic conditioning is
provided by DiffServ routers at operator boundaries or as a result
of misconfiguration.
</t>
</section> </section>
<section>
<section title="Considerations to guide the discussion of a proposed new D <name>Considerations to Guide the Discussion of a Proposed New
SCP"> DSCP</name>
<t>A series of questions emerge that need to be answered when <t>A series of questions emerge that need to be answered when
considering a proposal to the IETF that requests a new assignment. considering a proposal to the IETF that requests a new assignment.
These questions include:</t> These questions include:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>Is the request for Local Use within a Diffserv domain that does
<t>Is the request for local use within a DiffServ domain that does n not require interconnection with other Diffserv domains? This
ot require request can use DSCPs in Pool 2 for Local or Experimental Use,
interconnection with other DiffServ domains? This request can use DSC without any IETF specification for the DSCP or associated PHB.</li>
Ps in Pool 2 for local or <li>What are the characteristics of the proposed service class?
experimental use, without any IETF specification for the DSCP or What are the characteristics of the traffic to be carried? What are
associated PHB.</t> the expectations for treatment? </li>
<li>Service classes <xref target="RFC4594"/> that can utilize
<t>What are the characteristics of the proposed service class?: What existing PHBs should use assigned DSCPs to mark their traffic: Could
are the the request be met by using an existing IETF DSCP?</li>
characteristics of the traffic to be carried? What are the <li>Specification of a new recommended DSCP requires Standards
expectations for treatment? </t> Action. <xref target="RFC2474"/> states: "Each standardized PHB
<bcp14>MUST</bcp14> have an associated <bcp14>RECOMMENDED</bcp14>
<t>Service classes <xref target="RFC4594"></xref> that can utilize e codepoint". If approved, new IETF assignments are normally made by
xisting PHBs should use IANA in Pool 1, but the IETF can request assignments to be made from
assigned DSCPs to mark their traffic: Could the request be met by Pool 3 <xref target="RFC8436"/>. Does the Internet Draft contain an
using an existing IETF DSCP?</t> appropriate request to IANA?</li>
<li>The value selected for a new DSCP can impact the ability of an
<t>Specification of a new recommended DSCP requires Standards Action. operator to apply logical functions (e.g., a bitwise mask) to
RFC2474 states: "Each standardized PHB MUST have an associated related codepoints when configuring Diffserv. A suitable value can
RECOMMENDED codepoint". If approved, new IETF assignments are normally simplify configurations by aggregating classification on a range of
made by IANA in Pool 1, but the IETF can request assignments to be DSCPs. This classification based on DSCP ranges can increase the
made from Pool 3 <xref target="RFC8436"></xref>. comprehensibility of documenting forwarding differentiation.</li>
Does the Internet Draft contain an appropriate request to IANA?</t> <li> <xref target="mpls"/> describes examples of treatment
aggregation. What are the effects of treatment aggregation on the
<t>The value selected for a new DSCP can impact the ability of an op proposed DSCP? </li>
erator to apply <li> <xref target="lowerlayers"/> describes some observed treatments
logical functions (e.g., a bitwise mask) to related codepoint by layers below IP. What are the implications of the treatments and
s when configuring DiffServ. mapping described in <xref target="lowerlayers"/> on the proposed
A suitable value can simplify configurations by DSCP? </li>
aggregating classification on a range of DSCPs. This classifi <li>DSCPs are assigned to PHBs and can be used to enable nodes along
cation based on DSCP ranges an end-to-end path to classify the packet for a suitable PHB. <xref
can increase the comprehensibility of documenting forwarding target="observed-re-marking"/> describes some observed re-marking
differentiation.</t> behavior, and <xref target="networks"/> identifies root causes for
<t> why this re-marking is observed. What is the expected effect of
<xref target="mpls"></xref> describes examples of treatment a currently-deployed re-marking on the service, end-to-end or
ggregation. What are the effects of treatment aggregation on the otherwise?</li>
proposed DSCP? </t> </ul>
<t> <xref target="lowerlayers"></xref> describes some observed treat
ments by layers
below IP. What are the implications of the treatments and mapping de
scribed in <xref target="lowerlayers"></xref> on the proposed DSCP? </t>
<t> 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> describes some observed re
-marking behavior,
and <xref target="networks"></xref> identifies root causes for why th
is 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> </section>
</section> </section>
<section anchor="IANA">
<section anchor="Acknowledgements" title="Acknowledgements"> <name>IANA Considerations</name>
<t>The authors acknowledge the helpful discussions and analysis by Greg <t>IANA has added the following text as a note at the top of the "Differentiated
White and Thomas Fossati in a draft concerning NQB. Ruediger Geib and Services Field Codepoints (DSCP)" registry <xref target="DSCP-registry"/>: "See
Brian Carpenter contributed comments, along with other members of the RFC 9435 for considerations when assigning a new codepoint from the DSCP regist
TSVWG.</t> ry."
</section> </t>
</section>
<section anchor="IANA" title="IANA Considerations"> <section anchor="Security">
<name>Security 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 the following separate paragraph to the Note
at the top of the registry page:
"See [RFC-to-be] for considerations when assigning a new codepoint from
the DSCP registry."
</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>The security considerations are discussed in the security <t>The security considerations are discussed in the security
considerations of each cited RFC.</t> considerations of each cited RFC.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<!--?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/referenc
e.RFC.2119.xml"?-->
<!-- These are dependent standards necessary to implement/understand this
RFC -->
&RFC2119;
&RFC2474;
&RFC2475;
&RFC3260;
&RFC3290; <displayreference target="I-D.ietf-tsvwg-nqb" to="NQB-PHB"/>
<displayreference target="I-D.learmonth-intarea-rfc1226-bis" to="AX.25-over-IP"/
&RFC4594; >
&RFC5129;
&RFC8100;
&RFC8436;
<reference anchor="DSCP-registry">
<front>
<title>Differentiated Services Field Codepoints (DSCP)
Registry</title>
<author>
<organization>IANA</organization>
</author>
<date year="2019" />
</front>
<seriesInfo name="" value="https://www.iana.org/assignments/dscp-regis
try/dscp-registry.xhtml"/>
</reference>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. - these are no
t dependent standards -->
&RFC0791;
&RFC1122;
&RFC1349;
&RFC2597;
&RFC3086;
&RFC3246;
&RFC3270;
&RFC3662;
&RFC5127;
&RFC5160;
&RFC5415;
&RFC5865; <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.211
9.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.247
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.247
5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.326
0.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.329
0.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.459
4.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.512
9.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.810
0.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.843
6.xml"/>
&RFC8325; <reference anchor="DSCP-registry" target="https://www.iana.org/assignmen
ts/dscp-registry/">
<front>
<title>Differentiated Services Field Codepoints (DSCP)</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
&RFC8126; </references>;
&RFC8174; <references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.079
1.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.112
2.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.134
9.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.259
7.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.308
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.324
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.817
4.xml"/>
&RFC8622; <reference anchor="RFC3270" target="https://www.rfc-editor.org/info/rfc3270">
<front>
<title>
Multi-Protocol Label Switching (MPLS) Support of Differentiated Services
</title>
<author fullname="F. Le Faucheur" initials="F." surname="Le Faucheur" role="edit
or"/>
<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>
&I-D.ietf-tsvwg-nqb; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.366
2.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.512
7.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.516
0.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.541
5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.586
5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.832
5.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.812
6.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.862
2.xml"/>
<!--- last informational individual specs and other references --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ie tf-tsvwg-nqb.xml"/>
<reference anchor="Kol10"> <reference anchor="Kol10" target="https://lists.freebsd.org/pipermail/free
<front> bsd-stable/2010-July/057710.html">
<title> Bogus DSCP value for SSH </title> <front>
<author initials="A." surname="Kolu"></author> <title>Subject: bogus DSCP value for ssh</title>
<date year="2010" /> <author initials="A." surname="Kolu"/>
</front> <date day="12" month="July" year="2010"/>
<seriesInfo name="online" value="https://lists.freebsd.org/pipermail/free </front>
bsd-stable/2010-July/057710.html"/> <refcontent>message to the freebsd-stable mailing list</refcontent>
</reference> </reference>
<reference anchor="Cus17"> <reference anchor="Cus17">
<front> <front>
<title>Exploring DSCP modification pathologies in mobile edge <title>Exploring DSCP modification pathologies in mobile edge
networks</title> networks</title>
<author initials="A." surname="Custura"></author> <author initials="A." surname="Custura"/>
<author initials="A." surname="Venne"></author> <author initials="A." surname="Venne"/>
<author initials="G." surname="Fairhurst"></author> <author initials="G." surname="Fairhurst"/>
<date year="2017" /> <date month="June" year="2017"/>
</front> </front>
<seriesInfo name="TMA" value="" /> <seriesInfo name="DOI" value="10.23919/TMA.2017.8002923"/>
</reference> <refcontent>2017 Network Traffic Measurement and Analysis Conference (T
MA)</refcontent>
<reference anchor="Bar18"> </reference>
<front>
<title>Can WebRTC QoS Work? A DSCP Measurement Study</title>
<author initials="R." surname="Barik"></author>
<author initials="M." surname="Welzl"></author>
<author initials="A." surname="Elmokashfi"></author>
<author initials="T." surname="Dreibholz"></author>
<author initials="S." surname="Gjessing"></author>
<date month="September" year="2018" />
</front>
<seriesInfo name="ITC" value="30" />
</reference>
<reference anchor="SA-5G">
<front>
<title>System Architecture for 5G</title>
<author>
<organization>3GPP</organization>
</author>
<date year="2019" />
</front>
<seriesInfo name="TS" value="23.501" />
</reference>
<reference anchor="GSMA-IR-34">
<front>
<title>IR.34 Guidelines for IPX Provider networks (Previously
Inter-Service Provider IP Backbone Guidelines)</title>
<author>
<organization>GSM Association</organization>
</author>
<date year="2017" />
</front>
<seriesInfo name="IR" value="34" />
</reference>
<reference anchor="ITU-T-Y-1566">
<front>
<title>Quality of Service Mapping and Interconnection Between
Ethernet, Internet Protocol and Multiprotocol Label Switching
Networks</title>
<author>
<organization>ITU-T</organization>
</author>
<date year="2012" />
</front>
<seriesInfo name="ITU-T" value="Y.1566" />
</reference>
<reference anchor="IEEE-802-11">
<front>
<title>Wireless LAN Medium Access Control (MAC) and Physical Layer
(PHY) Specifications</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2007" />
</front>
<seriesInfo name="IEEE" 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" />
</front>
<seriesInfo name="Wi-Fi QoS Management Specification Version" value="2.0
" />
</reference>
<reference anchor="IEEE-802-1Q">
<front>
<title>IEEE Standard for Local and Metropolitan Area Network--
Bridges and Bridged Networks</title>
<author>
<organization>IEEE</organization>
</author>
<date year="2018" />
</front>
<seriesInfo name="IEEE" value="802.1Q" />
</reference>
<reference anchor="IEEE-802-1D"> <reference anchor="Bar18">
<front> <front>
<title>IEEE Standard for Local and Metropolitan Area Network-- Media <title>Can WebRTC QoS Work? A DSCP Measurement Study</title>
Access Control (MAC) Bridges</title> <author initials="R." surname="Barik"/>
<author> <author initials="M." surname="Welzl"/>
<organization>IEEE</organization> <author initials="A." surname="Elmokashfi"/>
</author> <author initials="T." surname="Dreibholz"/>
<date year="2004" /> <author initials="S." surname="Gjessing"/>
</front> <date month="September" year="2018"/>
<seriesInfo name="IEEE" value="802.1D" /> </front>
</reference> <seriesInfo name="DOI" value="10.1109/ITC30.2018.00034"/>
<refcontent>2018 30th International Teletraffic Congress (ITC 30)</refc
ontent>
</reference>
<reference anchor="IETF115-IEPG"> <reference anchor="SA-5G">
<front> <front>
<title>Real-world DSCP Traversal Measurements</title> <title>System architecture for the 5G System (5GS)</title>
<author initials="A." surname="Custura"> <author>
<organization>University of Aberdeen, UK</organization> <organization>3GPP</organization>
</author> </author>
<date year="2022" /> <date year="2019"/>
</front> </front>
<seriesInfo name="online" value="https://datatracker.ietf.org/meeting/11 <seriesInfo name="TS" value="23.501"/>
5/materials/slides-115-iepg-sessa-considerations-for-assigning-dscps-01" /> </reference>
</reference>
<reference anchor="MEF23.1"> <reference anchor="GSMA-IR.34" target="https://www.gsma.com/newsroom/wp-
<front> content/uploads/IR.34-v17.0.pdf">
<title>MEF Technical Specification MEF 23.1-- Carrier Ethernet Class <front>
of Service ? Phase 2</title> <title>Guidelines for IPX Provider networks (Previously
<author> Inter-Service Provider IP Backbone Guidelines)</title>
<organization>MEF</organization> <author>
</author> <organization>GSM Association</organization>
<date year="2012" /> </author>
</front> <date month="May" year="2021"/>
<seriesInfo name="MEF" value="23.1" /> </front>
</reference> <refcontent>Version 17.0, IR.34</refcontent>
</reference>
&I-D.learmonth-rfc1226-bis; <reference anchor="ITU-T-Y.1566" target="https://www.itu.int/rec/T-REC-Y
</references> .1566/en">
<front>
<title>Quality of service mapping and interconnection between
Ethernet, Internet Protocol and multiprotocol label switching
networks</title>
<author>
<organization>ITU-T Recommendation</organization>
</author>
<date month="July" year="2012"/>
</front>
<seriesInfo name="ITU-T" value="Y.1566"/>
</reference>
<section title="Revision Notes"> <reference anchor="IEEE-802.11" target="https://standards.ieee.org/ieee/
<t>Note to RFC-Editor: please remove this entire section prior to 802.11/7028/">
publication.</t> <front>
<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 month="February" year="2021"/>
</front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2021.9363693"/>
<seriesInfo name="IEEE Standard" value="802.11"/>
</reference>
<t><list style="symbols"> <reference anchor="WIFI-ALLIANCE">
<t>Individual draft -00, initial document.</t> <front>
<title>Wi-Fi QoS Management Specification Version 2.0
</title>
<author>
<organization>Wi-Fi Alliance</organization>
</author>
<date year="2021"/>
</front>
</reference>
<t>Individual draft -01, address comments from Martin Duke; Brian Carp <reference anchor="IEEE-802.1Q">
enter; <front>
Ruediger Geib, and revisions to improve language consistency.</t> <title>IEEE Standard for Local and Metropolitan Area
Network--Bridges and Bridged Networks</title>
<author>
<organization>IEEE</organization>
</author>
<date month="July" year="2018"/>
</front>
<seriesInfo name="IEEE Standard" value="802.1Q-2018"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8403927"/>
</reference>
<t>Individual draft -02, revise to improve language consistency.</t> <reference anchor="IEEE-802.1D">
<front>
<title>IEEE Standard for Local and metropolitan area
network--Media Access Control (MAC) Bridges</title>
<author>
<organization>IEEE</organization>
</author>
<date month="June" year="2004"/>
</front>
<seriesInfo name="IEEE Standard" value="802.1D-2004"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2004.94569"/>
</reference>
<t>Working Group -00, replace individual draft.</t> <reference anchor="IETF115-IEPG" target="https://datatracker.ietf.org/me
<t>Working Group -01, address feedback in preparation for IETF 113 Vien eting/115/materials/slides-115-iepg-sessa-considerations-for-assigning-dscps-01"
na.</t> >
<t>Working Group -02: <front>
<list style="hanging"> <title>Real-world DSCP Traversal Measurements</title>
<t>Consolidate terminology after IETF 113 Vienna. </t> <author initials="A." surname="Custura">
<t>Add clarification to RFC2474 and RFC2475 addressed in RFC3260 (comm <organization>University of Aberdeen, UK</organization>
ents from Ruediger Geib).</t> </author>
<t>Include figures to show the full list of codepoints, their assigned <date month="November" year="2022"/>
PHBs &amp; impact of ToS Precedence Bleaching.</t> </front>
<t>Add network categories that differentiate between network operator </reference>
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 Carpent
er).</t>
<t>Add some refs, improve language consistency (comments from Brian Ca
rpenter).</t>
<t>Clarify figure captions.</t>
</list>
</t>
<t>Working Group -04 <reference anchor="MEF-23.1" target="https://mef.net/Assets/Technical_Sp
<list style="hanging"> ecifications/PDF/MEF_23.1.pdf">
<t>Reference RFC3086 (comment from Brian Carpenter).</t> <front>
<t>Improve references (comments from Ruediger Geib).</t> <title>Implementation Agreement MEF 23.1 Carrier Ethernet Class of S
<t>Clarify intended document audience and scope (comments from Ruedige ervice - Phase 2</title>
r Geib).</t> <author>
<t>Clarify terms and language around re-marking, DiffServ domains and <organization>MEF</organization>
nodes, RFC8100 (comments from Ruediger Geib).</t> </author>
<t>More in-depth on mappings specified for mobile networks/MPLS short- <date month="January" year="2012"/>
pipe (comments from Ruediger Geib).</t> </front>
</list> <seriesInfo name="MEF" value="23.1"/>
</t> </reference>
<t>Working Group -05 <!-- [I-D.learmonth-rfc1226-bis] replaced by [I-D.learmonth-intarea-rfc1226-bis]
<list style="hanging"> IESG state Expired -->
<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 <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<list style="hanging"> learmonth-intarea-rfc1226-bis.xml"/>
<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 i
n the same observed re-marking.</t>
<t>Clarify Treatment Aggregates are part of methods such as MPLS (comm
ents from David Black).</t>
<t>Clarify implications on the rest of the path by re-marking in one d
omain. </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 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 </references>
<list style="hanging"> </references>
<t>Updates to document structure to avoid references in artwork legend
.</t>
<t>Fix DSCP table indentation</t>
<t>Update ref to nqb 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 of CS1</t>
</list>
</t>
<t>Working Group -11
<list style="hanging">
<t>Updated to complete response to AD review and resolved pathology ty
pes to xrefs.</t>
</list>
</t>
<t>Working Group -12
<list style="hanging">
<t>Finalize response to AD review, address comment from Brian Carpente
r.</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 regi
stry 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> <section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors acknowledge the helpful discussions and analysis by
<contact fullname="Greg White"/> and <contact fullname="Thomas
Fossati"/> in a draft concerning NQB. <contact fullname="Ruediger
Geib"/> and <contact fullname="Brian Carpenter"/> contributed comments,
along with other members of the TSVWG.</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 153 change blocks. 
1526 lines changed or deleted 1327 lines changed or added

This html diff was produced by rfcdiff 1.48.