One document matched: draft-ietf-dime-qos-parameters-01.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC2212 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2212.xml'>
<!ENTITY RFC3393 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3393.xml'>
<!ENTITY RFC2475 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2475.xml'>
<!ENTITY RFC3564 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3564.xml'>
<!ENTITY RFC4124 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4124.xml'>
<!ENTITY RFC2210 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2210.xml'>
<!ENTITY RFC2215 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2215.xml'>
<!ENTITY RFC3181 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3181.xml'>
<!ENTITY RFC4412 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4412.xml'>
<!ENTITY RFC3290 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3290.xml'>
<!ENTITY RFC3140 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3140.xml'>
<!ENTITY RFC2474 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2474.xml'>
<!ENTITY RFC2597 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2597.xml'>
<!ENTITY I-D.ietf-nsis-qspec PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nsis-qspec.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<rfc ipr="full3978" category="std" docName="draft-ietf-dime-qos-parameters-01.txt">
<front>
<title abbrev="QoS Parameters">Quality of Service Parameters for Usage with the AAA
Framework</title>
<author role="editor" initials="J" surname="Korhonen" fullname="Jouni Korhonen">
<organization>TeliaSonera</organization>
<address>
<postal>
<street>Teollisuuskatu 13</street>
<city>Sonera</city>
<code>FIN-00051</code>
<country>Finland</country>
</postal>
<email>jouni.korhonen@teliasonera.com</email>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization abbrev="Nokia Siemens Networks">Nokia Siemens Networks</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<region>Bavaria</region>
<code>81739</code>
<country>Germany</country>
</postal>
<email>Hannes.Tschofenig@nsn.com</email>
<uri>http://www.tschofenig.com</uri>
</address>
</author>
<date year="2007"/>
<area>Operations and Management</area>
<workgroup>Diameter Maintenance and Extensions (DIME)</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Diameter</keyword>
<keyword>QoS Parameters</keyword>
<abstract>
<t> This document defines a number of Quality of Service (QoS) parameters that can be
reused for conveying QoS information within RADIUS and Diameter. </t>
<t>The payloads used to carry these QoS parameters are opaque for the AAA client and the
AAA server itself and interpreted by the respective Resource Management Function.
</t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="introduction" title="Introduction">
<t> This document defines a number of Quality of Service (QoS) parameters that can be
reused for conveying QoS information within RADIUS and Diameter. </t>
<t>The payloads used to carry these QoS parameters are opaque for the AAA client and the
AAA server itself and interpreted by the respective Resource Management Function.
</t>
</section>
<!-- ====================================================================== -->
<section anchor="terms" title="Terminology and Abbreviations">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
described in RFC2119 <xref target="RFC2119"/>. </t>
</section>
<!-- ====================================================================== -->
<section title="Parameter Overview">
<section title="Traffic Model Parameter">
<t> The Traffic Model (TMOD) parameter is a container consisting of four
sub-parameters:<list style="symbols">
<t>rate (r)</t>
<t>bucket size (b)</t>
<t>peak rate (p)</t>
<t>minimum policed unit (m)</t>
</list>
</t>
<t> All four sub-parameters MUST be included in the TMOD parameter. The TMOD
parameter is a mathematically complete way to describe the traffic source. If,
for example, TMOD is set to specify bandwidth only, then set r = peak rate = p,
b = large, m = large. As another example if TMOD is set for TCP traffic, then
set r = average rate, b = large, p = large. </t>
</section>
<section title="Constraints Parameters">
<t> <Path Latency>, <Path Jitter>, <Path
PLR>, and <Path PER> are QoS parameters describing the
desired path latency, path jitter and path bit error rate respectively. </t>
<t>The <Path Latency> parameter refers to the accumulated latency of
the packet forwarding process associated with each QoS aware node along the
path, where the latency is defined to be the mean packet delay added by each
such node. This delay results from speed-of-light propagation delay, from packet
processing limitations, or both. The mean delay reflects the variable queuing
delay that may be present. The purpose of this parameter is to provide a minimum
path latency for use with services which provide estimates or bounds on
additional path delay <xref target="RFC2212"/>.</t>
<t> The procedures for collecting path latency information are outside the scope of
this document.</t>
<t>The <Path Jitter> parameter refers to the accumulated jitter of the
packet forwarding process associated with each QoS aware node along the path,
where the jitter is defined to be the nominal jitter added by each such node. IP
packet jitter, or delay variation, is defined in Section 3.4 of RFC 3393 <xref
target="RFC3393"/>, (Type-P-One-way-ipdv), and where the selection function
includes the packet with minimum delay such that the distribution is equivalent
to 2-point delay variation in <xref target="Y.1540"/>. The suggested evaluation
interval is 1 minute. This jitter results from packet processing limitations,
and includes any variable queuing delay which may be present. The purpose of
this parameter is to provide a nominal path jitter for use with services that
provide estimates or bounds on additional path delay <xref target="RFC2212"/>. </t>
<t> The procedures for collecting path jitter information are outside the scope of
this document. </t>
<t> The <Path PLR> parameter refers to the accumulated packet loss
rate (PLR) of the packet forwarding process associated with each QoS aware node
along the path where the PLR is defined to be the PLR added by each such node. </t>
<t>The <Path PER> parameter refers to the accumulated packet error
rate (PER) of the packet forwarding process associated with each QoS aware node,
where the PER is defined to be the PER added by each such node. </t>
<t> The <Slack Term> parameter refers to the difference between
desired delay and delay obtained by using bandwidth reservation, and which is
used to reduce the resource reservation for a flow <xref target="RFC2212"/>. </t>
<t> The <Preemption Priority> parameter refers to the priority of the
new flow compared with the <Defending Priority> of previously
admitted flows. Once a flow is admitted, the preemption priority becomes
irrelevant. The <Defending Priority> parameter is used to compare
with the preemption priority of new flows. For any specific flow, its preemption
priority MUST always be less than or equal to the defending priority.
<Admission Priority> and <RPH Priority> provide an
essential way to differentiate flows for emergency services, ETS, E911, etc.,
and assign them a higher admission priority than normal priority flows and
best-effort priority flows. </t>
</section>
<section title="Traffic Handling Directives">
<t> The <Excess Treatment> parameter describes how a QoS aware node
will process excess traffic, that is, out-of-profile traffic. Excess traffic MAY
be dropped, shaped and/or remarked. </t>
</section>
<section title="Traffic Classifiers">
<t> Resource reservations might refer to a packet processing with a particular
DiffServ per-hop behavior (PHB) <xref target="RFC2475"/> or to a particular QoS
class, e.g., Y.1541 QoS class or DiffServ-aware MPLS traffic engineering (DSTE)
class type <xref target="RFC3564"/>, <xref target="RFC4124"/>. </t>
</section>
</section>
<section title="Parameter Encoding">
<section title="Parameter Header">
<t>Each QoS parameter is encoded in TLV format. </t>
<t>
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|r|r|r| Parameter ID |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M Flag: When set indicates the subsequent parameter MUST be
interpreted. If the M flag is set and the parameter is not
understood then it leads to an error. If the M flag is not
set and then not understood then it can be ignored.
The r bits are reserved.
Parameter ID: Assigned to each individual QoS parameter
]]></artwork>
</figure>
</t>
</section>
<section title="TMOD-1 Parameter">
<t> <TMOD-1> = <r> <b> <p>
<m> <xref target="RFC2210"/> , <xref target="RFC2215"/>
</t>
<t> The above notation means that the 4 <TMOD-1> sub-parameters must
be carried in the <TMOD-1> parameter. The coding for the
<TMOD-1> parameter is as follows: </t>
<t>
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|r|r|r| 1 |r|r|r|r| 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-1 [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-1 [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-1 [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-1 [m] (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t> The <TMOD> parameters are represented by three floating point
numbers in single-precision IEEE floating point format followed by one 32-bit
integer in network byte order. The first floating point value is the rate (r),
the second floating point value is the bucket size (b), the third floating point
is the peak rate (p), and the first unsigned integer is the minimum policed unit
(m). </t>
<t> When r, b, and p terms are represented as IEEE floating point values, the sign
bit MUST be zero (all values MUST be non-negative). Exponents less than 127
(i.e., 0) are prohibited. Exponents greater than 162 (i.e., positive 35) are
discouraged, except for specifying a peak rate of infinity. Infinity is
represented with an exponent of all ones (255) and a sign bit and mantissa of
all zeroes. </t>
</section>
<section title="TMOD-2 Parameter">
<t> A description of the semantic of the parameter values can be found in <xref
target="RFC2215"/>. The <TMOD-2> parameter may be needed in a
DiffServ environment. The coding for the <TMOD-2> parameter is as
follows: </t>
<t>
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|r|r|r| 2 |r|r|r|r| 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Rate-2 [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TMOD Size-2 [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peak Data Rate-2 [p] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-2 [m] (32-bit unsigned integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t> When r, b, and p terms are represented as IEEE floating point values, the sign
bit MUST be zero (all values MUST be non-negative). </t>
<t> Exponents less than 127 (i.e., 0) are prohibited. Exponents greater than 162
(i.e., positive 35) are discouraged, except for specifying a peak rate of
infinity. Infinity is represented with an exponent of all ones (255) and a sign
bit and mantissa of all zeroes. </t>
</section>
<section title="Path Latency Parameter">
<t> A description of the semantic of the parameter values can be found in <xref
target="RFC2210"/>,<xref target="RFC2215"/>. The coding for the <Path
Latency> parameter is as follows: </t>
<t>
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|r|r|r| 3 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Latency (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t> The Path Latency is a single 32-bit integer in network byte order. The
composition rule for the <Path Latency> parameter is summation
with a clamp of (2**32 - 1) on the maximum value. The latencies are average
values reported in units of one microsecond. A system with resolution less than
one microsecond MUST set unused digits to zero. The total latency added across
all QoS aware nodes along the path can range as high as (2**32)-2. </t>
</section>
<section title="Path Jitter Parameter">
<t>The coding for the <Path Jitter> parameter is as follows: </t>
<t>
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|r|r|r| 4 |r|r|r|r| 4 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Jitter STAT1(variance) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT2(99.9%-ile) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT3(minimum Latency) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT4(Reserved) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t> The Path Jitter is a set of four 32-bit integers in network byte order. The Path
Jitter parameter is the combination of four statistics describing the Jitter
distribution with a clamp of (2**32 - 1) on the maximum of each value. The
jitter STATs are reported in units of one microsecond. </t>
</section>
<section title="Path PLR Parameter">
<t>The coding for the <Path PLR> parameter is as follows: </t>
<t>
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|r|r|r| 5 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Packet Loss Ratio (32-bit floating point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t> The Path PLR is a single 32-bit single precision IEEE floating point number in
network byte order. The PLRs are reported in units of 10^-11. A system with
resolution less than one microsecond MUST set unused digits to zero. The total
PLR added across all QoS aware nodes can range as high as 10^-1. </t>
</section>
<section title="Path PER Parameter">
<t>The coding for the <Path PLR> parameter is as follows: </t>
<t>
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|r|r|r| 6 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Packet Error Ratio (32-bit floating point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t> The Path PER is a single 32-bit single precision IEEE floating point number in
network byte order. The PERs are reported in units of 10^-11. A system with
resolution less than one microsecond MUST set unused digits to zero. The total
PER added across all QoS aware nodes can range as high as 10^-1. </t>
</section>
<section title="Slack Term Parameter">
<t> A description of the semantic of the parameter values can be found in <xref
target="RFC2212"/>, <xref target="RFC2215"/>. The coding for the
<Path PLR> parameter is as follows: </t>
<t>
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|r|r|r| 7 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slack Term [S] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t> The Slack Term parameter S is nonnegative and is measured in microseconds. S is
represented as a 32-bit integer. Its value can range from 0 to (2**32)-1
microseconds. </t>
</section>
<section title="Preemption Priority amp; Defending Priority Parameters">
<t> A description of the semantic of the parameter values can be found in <xref
target="RFC3181"/>. </t>
<t> The coding for the <Preemption Priority> &
<Defending Priority> sub-parameters is as follows: </t>
<t>
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|r|r|r| 8 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preemption Priority | Defending Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t> Preemption Priority: The priority of the new flow compared with the defending
priority of previously admitted flows. Higher values represent higher priority. </t>
<t> Defending Priority: Once a flow is admitted, the preemption priority becomes
irrelevant. Instead, its defending priority is used to compare with the
preemption priority of new flows. </t>
<t> As specified in <xref target="RFC3181"/>, <Preemption Priority>
& <Defending Priority> are 16-bit integer values. </t>
</section>
<section title="Admission Priority Parameter">
<t>A description of the semantic of the parameter values can be found in [Y.1571].
The coding for the <Admission Priority> parameter is as follows: </t>
<t>
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|r|r|r| 9 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Admis.Priority| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t> High priority flows, normal priority flows, and best-effort priority flows can
have access to resources depending on their admission priority value as follows: </t>
<t>
<figure>
<artwork><![CDATA[
Admission Priority:
0 - best-effort priority flow
1 - normal priority flow
2 - high priority flow
255 - not used
]]></artwork>
</figure>
</t>
<t> A reservation without an <Admission Priority> parameter (i.e., set
to 255) MUST be treated as a reservation with an <Admission
Priority> = 1. </t>
</section>
<section title="RPH Priority Parameter">
<t> A description of the semantic of the parameter values can be found in <xref
target="RFC4412"/>. The coding for the <RPH Priority>
parameter is as follows: </t>
<t>
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|r|r|r| 10 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPH Namespace | RPH Priority | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t>
<xref target="RFC4412"/> defines a resource priority header (RPH) with
parameters "RPH Namespace" and "RPH Priority" combination, and if populated is
applicable only to flows with high admission priority, as follows: </t>
<t>
<figure>
<artwork><![CDATA[
RPH Namespace:
0 - dsn
1 - drsn
2 - q735
3 - ets
4 - wps
255 - not used
]]></artwork>
</figure>
</t>
<t> Each namespace has a finite list of relative priority-values. Each is listed
here in the order of lowest priority to highest priority. </t>
<t>
<figure>
<artwork><![CDATA[
RPH Priority:
4 - q735.4
3 - q735.3
2 - q735.2
1 - q735.1
0 - q735.0
4 - ets.4
3 - ets.3
2 - ets.2
1 - ets.1
0 - ets.0
4 - wps.4
3 - wps.3
2 - wps.2
1 - wps.1
0 - wps.0
]]></artwork>
</figure>
</t>
<t> For the 4 priority parameters, the following cases are permissible (procedures
specified in references): </t>
<t>
<figure>
<artwork><![CDATA[
1 parameter: <Admission Priority> [Y.1571]
2 parameters: <Admission Priority>, <RPH Priority> [RFC4412]
2 parameters: <Preemption Priority>, <Defending Priority> [RFC3181]
3 parameters: <Preemption Priority>, <Defending Priority>,
<Admission Priority> [3GPP-1, 3GPP-2, 3GPP-3]
4 parameters: <Preemption Priority>, <Defending Priority>,
<Admission Priority>, <RPH Priority> [3GPP-1, 3GPP-2,
3GPP-3]
]]></artwork>
</figure>
</t>
<t> It is permissible to have <Admission Priority> without <RPH
Priority>, but not permissible to have <RPH Priority>
without <Admission Priority> (alternatively <RPH
Priority> is ignored in instances without <Admission
Priority>). </t>
<!-- <t>
eMLPP-like functionality (as defined in [3GPP-1, 3GPP-2]) specifies
use of <Admission Priority> corresponding to the 'queuing allowed'
part of eMLPP as well as <Preemption/Defending Priority>
corresponding to the 'preemption capable' and 'may be preempted'
parts of eMLPP.</t>
-->
</section>
<section title="Excess Treatment Parameter">
<t>The coding for the <Excess Treatment> parameter is as follows: </t>
<t>
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|r|r|r| 11 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Trtmnt | Remark Value | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t> Excess Treatment: Indicates how the QoS aware node should process out-of-profile
traffic, that is, traffic not covered by the <Traffic> parameter.
Allowed values are as follows:</t>
<t>
<figure>
<artwork><![CDATA[
0: drop
1: shape
2: remark
3: no metering or policing is permitted
]]></artwork>
</figure>
</t>
<t>The default excess treatment in case that none is specified is that there are no
guarantees to excess traffic, i.e., a QoS aware node can do what it finds
suitable.</t>
<t> When excess treatment is set to 'drop', all marked traffic MUST be dropped by a
QoS aware node. </t>
<t> When excess treatment is set to 'shape', it is expected that the QoS Desired
object carries a TMOD parameter. Excess traffic is to be shaped to this TMOD.
When the shaping causes unbounded queue growth at the shaper traffic can be
dropped. </t>
<t> When excess treatment is set to 'remark', the excess treatment parameter MUST
carry the remark value. For example, packets may be remarked to drop remarked to
pertain to a particular QoS class. In the latter case, remarking relates to a
DiffServ-type model, where packets arrive marked as belonging to a certain QoS
class, and when they are identified as excess, they should then be remarked to a
different QoS Class. </t>
<t> If 'no metering or policing is permitted' is signaled, the QoS aware node should
accept the excess treatment parameter set by the sender with special care so
that excess traffic should not cause a problem. To request the Null Meter <xref
target="RFC3290"/> is especially strong, and should be used with caution.
</t>
</section>
<section title="PHB Class Parameter">
<t>A description of the semantic of the parameter values can be found in <xref
target="RFC3140"/>. The coding for the <PHB Class> parameter
is as follows: </t>
<t>
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|r|r|r| 12 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
]]></artwork>
</figure>
</t>
<t> As prescribed in <xref target="RFC3140"/>, the encoding for a single PHB is the
recommended DSCP value for that PHB, left-justified in the 16 bit field, with
bits 6 through 15 set to zero. </t>
<t> The encoding for a set of PHBs is the numerically smallest of the set of
encodings for the various PHBs in the set, with bit 14 set to 1. (Thus for the
AF1x PHBs, the encoding is that of the AF11 PHB, with bit 14 set to 1.) </t>
<t>
<figure>
<artwork><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 X 0|
+---+---+---+---+---+---+---+---+
]]></artwork>
</figure>
</t>
<t> PHBs not defined by standards action, i.e., experimental or local use PHBs as
allowed by <xref target="RFC2474"/>. In this case an arbitrary 12 bit PHB
identification code, assigned by the IANA, is placed left-justified in the 16
bit field. Bit 15 is set to 1, and bit 14 is zero for a single PHB or 1 for a
set of PHBs. Bits 12 and 13 are zero. </t>
<t>
<figure>
<artwork><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHD ID CODE |0 0 X 0|
+---+---+---+---+---+---+---+---+
]]></artwork>
</figure>
</t>
<t> Bits 12 and 13 are reserved either for expansion of the PHB identification code,
or for other use, at some point in the future. </t>
<t> In both cases, when a single PHBID is used to identify a set of PHBs (i.e., bit
14 is set to 1), that set of PHBs MUST constitute a PHB Scheduling Class (i.e.,
use of PHBs from the set MUST NOT cause intra-microflow traffic reordering when
different PHBs from the set are applied to traffic in the same microflow). The
set of AF1x PHBs <xref target="RFC2597"/> is an example of a PHB Scheduling
Class. Sets of PHBs that do not constitute a PHB Scheduling Class can be
identified by using more than one PHBID. </t>
<t> The registries needed to use <xref target="RFC3140"/> already exist. Hence, no
new registry needs to be created for this purpose. </t>
</section>
<section title="DSTE Class Type Parameter">
<t> A description of the semantic of the parameter values can be found in <xref
target="RFC4124"/>. The coding for the <DSTE Class Type>
parameter is as follows:</t>
<t>
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|r|r|r| 13 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|DSTE Cls. Type | (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
]]></artwork>
</figure>
</t>
<t> DSTE Class Type: Indicates the DSTE class type. Values currently allowed are 0,
1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means that the <DSTE Class
Type> parameter is not used. </t>
</section>
<section title="Y.1541 QoS Class Parameter">
<t>A description of the semantic of the parameter values can be found in <xref
target="Y.1541"/>. The coding for the <Y.1541 QoS Class>
parameter is as follows:</t>
<t>
<figure>
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|r|r|r| 14 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Y.1541 QoS Cls.| (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
]]></artwork>
</figure>
</t>
<t> Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently allowed are
0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means that the <Y.1541
QoS Class> parameter is not used. </t>
<t>
<list style="hanging">
<t hangText="Class 0:"><vspace blankLines="1"/> Mean delay <= 100 ms,
delay variation <= 50 ms, loss ratio <= 10^-3. Real-time,
highly interactive applications, sensitive to jitter. Application
examples include VoIP, Video Teleconference. <vspace blankLines="1"/></t>
<t hangText="Class 1:"><vspace blankLines="1"/> Mean delay <= 400 ms,
delay variation <= 50 ms, loss ratio <= 10^-3. Real-time,
interactive applications, sensitive to jitter. Application examples
include VoIP, Video Teleconference. <vspace blankLines="1"/></t>
<t hangText="Class 2:"><vspace blankLines="1"/> Mean delay <= 100 ms,
delay variation unspecified, loss ratio <= 10^-3. Highly
interactive transaction data. Application examples include
signaling.<vspace blankLines="1"/></t>
<t hangText="Class 3:"><vspace blankLines="1"/> Mean delay <= 400 ms,
delay variation unspecified, loss ratio <= 10^-3. Interactive
transaction data. Application examples include signaling.<vspace
blankLines="1"/></t>
<t hangText="Class 4:"><vspace blankLines="1"/> Mean delay <= 1 sec,
delay variation unspecified, loss ratio <= 10^-3. Low Loss Only
applications. Application examples include short transactions, bulk
data, video streaming.<vspace blankLines="1"/>
</t>
<t hangText="Class 5:"><vspace blankLines="1"/> Mean delay unspecified,
delay variation unspecified, loss ratio unspecified. Unspecified
applications. Application examples include traditional applications of
default IP networks.<vspace blankLines="1"/>
</t>
<t hangText="Class 6:"><vspace blankLines="1"/> Mean delay <= 100 ms,
delay variation <= 50 ms, loss ratio <= 10^-5.
Applications that are highly sensitive to loss, such as television
transport, high-capacity TCP transfers, and TDM circuit
emulation.<vspace blankLines="1"/>
</t>
<t hangText="Class 7:"><vspace blankLines="1"/> Mean delay <= 400 ms,
delay variation <= 50 ms, loss ratio <= 10^-5.
Applications that are highly sensitive to loss, such as television
transport, high-capacity TCP transfers, and TDM circuit emulation. </t>
</list>
</t>
</section>
</section>
<!-- ====================================================================== -->
<section title="Extensibility">
<t>This document is designed with extensibility in mind given that different
organizations and groups are used to define their own Quality of Service parameters.
This document provides an initial QoS profile with common set of parameters.
Ideally, these parameters should be used whenever possible but there are cases where
additional parameters might be needed, or where the parameters specified in this
document are used with a different semantic. In this case it is advisable to define
a new QoS profile that may consist of new parameters in addition to parameters
defined in this document or an entirely different set of parameters.</t>
<t>To enable the definition of new QoS profiles a 8 octet registry is defined field that
is represented by a 4-octet vendor and 4-octet specifier field. The vendor field
indicates the type as either standards-specified or vendor-specific. If the four
octets of the vendor field are 0x00000000, then the value is standards-specified and
the registry is maintained by IANA, and any other value represents a vendor-specific
Object Identifier (OID). IANA created registry is split into two value ranges; one
range uses the "Standards Action" and the second range uses "Specification Required"
allocation policy. The latter range is meant to be used by organizations outside the
IETF.</t>
</section>
<!-- ====================================================================== -->
<section title="IANA Considerations">
<t>This document reuses the namespace created in <xref target="I-D.ietf-nsis-qspec"/>
for <list style="numbers">
<t>Admission Priority Parameter </t>
<t>RPH Namespace Parameter </t>
<t>RPH Priority Parameter </t>
<t>Excess Treatment Parameter </t>
<t>DSTE Class Type Parameter </t>
<t>Y.1541 QoS Class Parameter </t>
</list>
</t>
<t>IANA is requested to create the following registries: QoS Profile (32 bits), and
Parameter ID (12 bits)</t>
<section title="QoS Profile">
<t>The QoS Profile refers to a 64 bit long field that is represented by a 4-octet
vendor and 4-octet specifier field. The vendor field indicates the type as
either standards-specified or vendor-specific. If the four octets of the vendor
field are 0x00000000, then the value is standards-specified and the registry is
maintained by IANA, and any other value represents a vendor-specific Object
Identifier (OID). </t>
<t>The specifier field indicates the actual QoS profile. The vendor field 0x00000000
is reserved to indicate that the values in the specifier field are maintained by
IANA. This document requests IANA to create such a registry and to allocate the
value zero (0) for the QoS profile defined in this document.</t>
<t> For any other vendor field, the specifier field is maintained by the vendor. </t>
<t>For the IANA maintained QoS profiles the following allocation policy is defined:</t>
<t>1 to 511: Standards Action </t>
<t>512 to 4095: Specification Required</t>
<t>Standards action is required to depreciate, delete, or modify existing QoS
profile values in the range of 0-511 and a specification is required to
depreciate, delete, or modify existing QoS profile values in the range of
512-4095.</t>
</section>
<section title="Parameter ID">
<t>The Parameter ID refers to a 12 bit long field. </t>
<t>The following values are allocated by this specification. <figure>
<artwork><![CDATA[
(0): <TMOD-1>
(1): <TMOD-2>
(2): <Path Latency>
(3): <Path Jitter>
(4): <Path PLR>
(5): <Path PER>
(6): <Slack Term>
(7): <Preemption Priority> & <Defending Priority>
(8): <Admission Priority>
(9): <RPH Priority>
(10): <Excess Treatment>
(11): <PHB Class>
(12): <DSTE Class Type>
(13): <Y.1541 QoS Class>
]]></artwork>
</figure>
</t>
<t> The allocation policies for further values are as follows:</t>
<t> 14-127: Standards Action</t>
<t>128-255: Private/Experimental Use</t>
<t>255-4095: Specification Required</t>
<t> A standards track document is required to depreciate, delete, or modify existing
Parameter IDs. </t>
</section>
</section>
<!-- ====================================================================== -->
<section title="Security Considerations">
<t>This document does not raise any security concerns as it only defines QoS
parameters.</t>
</section>
<!-- ====================================================================== -->
<section title="Acknowledgements">
<t>The authors would like to thank the NSIS QSPEC <xref target="I-D.ietf-nsis-qspec"/>
authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the NSIS working
group chairs (John Loughney and Martin Stiemerling) and the former Transport Area
Directors (Allison Manking, Jon Peterson) for their help. </t>
</section>
<!-- ====================================================================== -->
</middle>
<back>
<references title="Normative References"> &RFC2119; &RFC2212; &RFC3393;
&RFC2475; &RFC3564; &RFC4124; &RFC2210; &RFC2215; &RFC3181;
&RFC4412; &RFC3290; &RFC3140; &RFC2474; &RFC2597; <reference
anchor="Y.1541">
<front>
<title>Network Performance Objectives for IP-Based Services</title>
<author fullname="ITU-T Recommendation Y.1541" initials="" surname="">
<organization/>
<address>
<email/>
</address>
</author>
<date year="2006"/>
</front>
<seriesInfo name="" value=""/>
<format type="" target=""/>
</reference>
</references>
<references title="Informative References"> &I-D.ietf-nsis-qspec; <reference
anchor="Y.1540">
<front>
<title>Internet Protocol Data Communication Service - IP Packet Transfer and
Availability Performance Parameters</title>
<author fullname="ITU-T Recommendation Y.1540" initials="" surname="">
<organization/>
<address>
<email/>
</address>
</author>
<date year="2002" month="December"/>
</front>
<seriesInfo name="" value=""/>
<format type="" target=""/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:33:01 |