One document matched: draft-ietf-dime-qos-parameters-06.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'>
<!ENTITY RFC5226 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'>
<!ENTITY I-D.ietf-tsvwg-emergency-rsvp PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-tsvwg-emergency-rsvp.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-06.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>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<date year="2008"/>
<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 anchor="parameter" 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 a 32-bit integer value in network byte order 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. They are
represented in network byte order.</t>
</section>
<section title="Admission Priority Parameter">
<t>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>The 'Admis.Priority' field is a 8 bit unsigned integer in network byte order.</t>
<t>The admission control priority of the flow, in terms of access to network bandwidth
in order to provide higher probability of call completion to selected flows. Higher
values represent higher priority. A given Admission Priority is encoded in this
information element using the same value as when encoded in the Admission Priority
parameter defined in Section 6.2.9 of <xref target="I-D.ietf-nsis-qspec"/>, or in the
Admission Priority parameter defined in Section 3.1 of <xref
target="I-D.ietf-tsvwg-emergency-rsvp"/>. In other words, a given value inside the
Admission Priority information element defined in the present document, inside the
<xref target="I-D.ietf-nsis-qspec"/> Admission Priority parameter or inside the
<xref target="I-D.ietf-tsvwg-emergency-rsvp"/> Admission Priority parameter,
refers to the same Admission Priority. </t>
</section>
<section title="Application-Level Resource Priority (ALRP) Parameter">
<t> A description of the semantic of the parameter values can be found in <xref
target="RFC4412"/> and in <xref target="I-D.ietf-tsvwg-emergency-rsvp"/>. The
coding for 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ALRP Namespace | ALRP Priority | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t> The ALRP Namespace field is a 16 bits long unsigned integer in network byte order
and the ALRP Priority field is an 8 bit long unsigned integer in network byte order
containing the specific priority value. </t>
<t>
<xref target="RFC4412"/> defines a resource priority header and established the
initial registry; that registry was later extended by <xref
target="I-D.ietf-tsvwg-emergency-rsvp"/>.</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 (8 bit unsigned integer value in network byte order): 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>
<t>The Remark Value is an 8 bit unsigned integer value in network byte order.</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 section defines the registries and initial codepoint assignments, in accordance
with BCP 26 RFC 5226 <xref target="RFC5226"/>. It also defines the procedural
requirements to be followed by IANA in allocating new codepoints.</t>
<t>IANA is requested to create the following registries listed in the subsections below.</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:<list
style="empty">
<t>1 to 511: Standards Action </t>
<t>512 to 4095: Specification Required</t>
</list>
</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): <ALRP>
(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:<list style="empty">
<t> 14-127: Standards Action</t>
<t>128-255: Private/Experimental Use</t>
<t>255-4095: Specification Required</t>
</list>
</t>
<t> A standards track document is required to depreciate, delete, or modify existing
Parameter IDs. </t>
</section>
<section title="Excess Treatment Parameter">
<t>The Excess Treatment parameter refers to an 8 bit long field. </t>
<t>The following values are allocated by this specification:<list style="empty">
<t> Excess Treatment Value 0: drop</t>
<t> Excess Treatment Value 1: shape</t>
<t> Excess Treatment Value 2: remark</t>
<t> Excess Treatment Value3: no metering or policing is permitted</t>
<t> Excess Treatment Values 4-63: Standards Action</t>
<t> Excess Treatment Value 64-255: Reserved</t>
</list>
</t>
<t>The 8 bit Remark Value allocation policies are as follows:<list style="empty">
<t> 0-63: Specification Required</t>
<t> 64-127: Private/Experimental Use</t>
<t> 128-255: Reserved</t>
</list>
</t>
</section>
<section title="DSTE Class Type Parameter">
<t>The DSTE Class Type parameter refers to an 8 bit long field. </t>
<t>The following values are allocated by this specification:<list style="empty">
<t> DSTE Class Type Value 0: DSTE Class Type 0</t>
<t> DSTE Class Type Value 1: DSTE Class Type 1</t>
<t> DSTE Class Type Value 2: DSTE Class Type 2</t>
<t> DSTE Class Type Value 3: DSTE Class Type 3</t>
<t> DSTE Class Type Value 4: DSTE Class Type 4</t>
<t> DSTE Class Type Value 5: DSTE Class Type 5</t>
<t> DSTE Class Type Value 6: DSTE Class Type 6</t>
<t> DSTE Class Type Value 7: DSTE Class Type 7</t>
<t> DSTE Class Type Values 8-63: Standards Action</t>
<t>DSTE Class Type Values 64-255: Reserved</t>
</list>
</t>
</section>
<section title="Y.1541 QoS Class Parameter">
<t>The Y.1541 QoS Class parameter refers to an 8 bit long field. </t>
<t>The following values are allocated by this specification:<list style="empty">
<t>Y.1541 QoS Class Value 0: Y.1541 QoS Class 0</t>
<t> Y.1541 QoS Class Value 1: Y.1541 QoS Class 1</t>
<t> Y.1541 QoS Class Value 2: Y.1541 QoS Class 2</t>
<t> Y.1541 QoS Class Value 3: Y.1541 QoS Class 3</t>
<t> Y.1541 QoS Class Value 4: Y.1541 QoS Class 4</t>
<t> Y.1541 QoS Class Value 5: Y.1541 QoS Class 5</t>
<t> Y.1541 QoS Class Value 6: Y.1541 QoS Class 6</t>
<t> Y.1541 QoS Class Value 7: Y.1541 QoS Class 7</t>
<t> Y.1541 QoS Class Values 8-63: Standards Action</t>
<t> Y.1541 QoS Class Values 64-255: Reserved</t>
</list>
</t>
</section>
<t>The ALRP Namespace and ALRP Priority field inside the ALRP Parameter take their values
from the registry created by <xref target="RFC4412"/> and extended with <xref
target="I-D.ietf-tsvwg-emergency-rsvp"/> No additional actions are required by IANA
by this specification.</t>
</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 Mankin, Jon Peterson) for their help. </t>
<t>We would like to thank Francois Le Faucheur, John Loughney, Martin Stiemerling, Dave
Oran, An Nguyen, Ken Carlberg, James Polk, Lars Eggert, and Magnus Westerlund for their
help with resolving problems regarding the Admission Priority and the ALRP parameter. </t>
</section>
<!-- ====================================================================== -->
</middle>
<back>
<references title="Normative References"> &RFC2119; &RFC2212; &RFC3393;
&RFC4124; &RFC2210; &RFC2215; &RFC3181;
&RFC4412; &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>
<reference anchor="Y.1571">
<front>
<title>Admission Control Priority Levels in Next Generation Networks</title>
<author fullname="ITU-T Recommendation Y.1571" initials="" surname="">
<organization/>
<address>
<email/>
</address>
</author>
<date month="July" year="2006"/>
</front>
<seriesInfo name="" value=""/>
<format type="" target=""/>
</reference> &I-D.ietf-tsvwg-emergency-rsvp; </references>
<references title="Informative References"> &RFC3564; &RFC3290; &RFC2475; &RFC5226; &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:32:59 |