One document matched: draft-ietf-dime-qos-parameters-09.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 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'>
<!ENTITY RFC2578 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml'>
<!ENTITY RFC2697 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2697.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="trust200811" category="std" docName="draft-ietf-dime-qos-parameters-09.txt">
<front>
<title abbrev="QoS Parameters">Quality of Service Parameters for Usage with Diameter</title>
<author role="editor" initials="J" surname="Korhonen" fullname="Jouni Korhonen">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<email>jouni.korhonen@nsn.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>
<author fullname="Elwyn Davies" initials="E.B." surname="Davies">
<organization>Folly Consulting</organization>
<address>
<postal>
<street/>
<city>Soham</city>
<code/>
<country>UK</country>
</postal>
<phone>+44 7889 488 335</phone>
<email>elwynd@dial.pipex.com</email>
</address>
</author>
<date year="2009"/>
<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 Diameter. </t>
<t>The defined QoS information includes data traffic parameters for describing a token
bucket filter, bandwidth, defending and preemption priority, admission priority,
application-level resource priority, per-hop behavior class, and DiffServ-aware
Multiprotocol Label Switching (MPLS) traffic engineering.</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 the Diameter protocol. </t>
<t>This document defines an initial QoS profile containing a set of QoS AVPs.</t>
<t> The traffic model (TMOD) AVPs are containers consisting of four AVPs and is a way to
describe the traffic source. </t>
<t>
<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>
<!-- 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. -->
The encoding of <TMOD-1> and <TMOD-2> can be found in <xref
target="tmod1"/> and <xref target="tmod2"/> and the semantic is described in <xref
target="RFC2210"/> and in <xref target="RFC2215"/>. <TMOD-2> is, for
example, needed by some DiffServ applications. It is typically assumed that DiffServ EF
traffic is shaped at the ingress by a single rate token bucket. Therefore, a single TMOD
parameter is sufficient to signal DiffServ EF traffic. However, for DiffServ AF traffic
two sets of token bucket parameters are needed, one token bucket for the average traffic
and one token bucket for the burst traffic. <xref target="RFC2697"/> defines a Single
Rate Three Color Marker (srTCM), which meters a traffic stream and marks its packets
according to three traffic parameters, Committed Information Rate (CIR), Committed Burst
Size (CBS), and Excess Burst Size (EBS), to be either green, yellow, or red. A packet is
marked green if it does not exceed the CBS, yellow if it does exceed the CBS, but not
the EBS, and red otherwise. <xref target="RFC2697"/> defines specific procedures using
two token buckets that run at the same rate. Therefore, two TMOD AVPs are sufficient to
distinguish among three levels of drop precedence. An example is also described in the
appendix of <xref target="RFC2597"/>. </t>
<t> The <Preemption-Priority> AVP refers to the priority of a new flow
compared with the <Defending-Priority> AVP of previously admitted flows.
Once a flow is admitted, the preemption priority becomes irrelevant. The
<Defending-Priority> AVP is used to compare with the preemption priority
of new flows. For any specific flow, its preemption priority is always less than or
equal to the defending priority. </t>
<t>The <Admission-Priority> AVP and <ALRP> AVP 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>
<t> Resource reservations might refer to a packet processing with a particular DiffServ
per-hop behavior (PHB) <xref target="RFC2475"/> (using the <PHB-Class>
AVP) or to a particular QoS class, e.g., a DiffServ-aware MPLS traffic engineering
(DSTE) class type, as described in <xref target="RFC3564"/> and in <xref
target="RFC4124"/>, using the <DSTE-Class-Type> AVP. </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 anchor="parameter" title="QoS Parameter Encoding">
<section anchor="tmod1" title="TMOD-1 AVP">
<t>The TMOD-1 AVP is obtained from <xref target="RFC2210"/> and <xref target="RFC2215"
/>. The structure of the AVP is as follows: <figure>
<artwork><![CDATA[
TMOD-1 ::= < AVP Header: TBD >
{ TMOD-Rate }
{ TMOD-Size }
{ Peak-Data-Rate }
{ Minimum-Policed-Unit }
]]></artwork>
</figure>
</t>
<section title="TMOD-Rate AVP">
<t> The TMOD-Rate AVP (AVP Code TBD) is of type Float32 and contains the rate
(r).</t>
</section>
<section title="TMOD-Size AVP">
<t> The TMOD-Size AVP (AVP Code TBD) is of type Float32 and contains the bucket size
(b).</t>
</section>
<section title="Peak-Data-Rate AVP">
<t> The Peak-Data-Rate AVP (AVP Code TBD) is of type Float32 and contains the peak
rate (p). </t>
</section>
<section title="Minimum-Policed-Unit AVP">
<t> The Minimum-Policed-Unit AVP (AVP Code TBD) is of type Unsigned32 and contains
the minimum policed unit (m). </t>
</section>
</section>
<section anchor="tmod2" title="TMOD-2 AVP">
<t> A description of the semantic of the parameter values can be found in <xref
target="RFC2215"/>. The TMOD-2 AVP is useful in a DiffServ environment. The coding
for the TMOD-2 AVP is as follows: <figure>
<artwork><![CDATA[
TMOD-2 ::= < AVP Header: TBD >
{ TMOD-Rate }
{ TMOD-Size }
{ Peak-Data-Rate }
{ Minimum-Policed-Unit }
]]></artwork>
</figure></t>
</section>
<section title="Bandwidth AVP">
<t> The Bandwidth AVP (AVP Code TBD) is of type Float32 and is measured in bytes of IP
datagrams per second. </t>
</section>
<section title="Priority AVP">
<t>The Priority AVP is a grouped AVP consisting of two AVPs, the Preemption-Priority and
the Defending-Priority AVP. A description of the semantic can be found in <xref
target="RFC3181"/>. </t>
<t>
<figure>
<artwork><![CDATA[
Priority ::= < AVP Header: TBD >
{ Preemption-Priority }
{ Defending-Priority }
]]></artwork>
</figure>
</t>
<section title="Preemption-Priority AVP">
<t> The Preemption-Priority AVP (AVP Code TBD) is of type Unsigned32 and it indicates
the priority of the new flow compared with the defending priority of previously
admitted flows. Higher values represent higher priority. </t>
</section>
<section title="Defending-Priority AVP">
<t> The Defending-Priority AVP (AVP Code TBD) is of type Unsigned32. 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>
</section>
</section>
<section title="Admission-Priority AVP">
<t>The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32. </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
AVP defined in Section 3.1 of <xref target="I-D.ietf-tsvwg-emergency-rsvp"/>
(Admission Priority parameter).</t>
</section>
<section title="ALRP AVP">
<t>The Application-Level Resource Priority (ALRP) AVP is a grouped AVP consisting of two
AVPs, the ALRP-Namespace and the ALRP-Priority AVP.</t>
<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[
ALRP ::= < AVP Header: TBD >
{ ALRP-Namespace }
{ ALRP-Priority }
]]></artwork>
</figure>
</t>
<section title="ALRP-Namespace AVP">
<t> The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32. </t>
</section>
<section title="ALRP-Priority AVP">
<t> The ALRP-Priority AVP (AVP Code TBD) is of type Unsigned32. </t>
</section>
<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="PHB-Class AVP">
<t>The PHB-Class AVP (AVP Code TBD) is of type Unsigned32. </t>
<t>A description of the semantic of the parameter values can be found in <xref
target="RFC3140"/>. The registries needed for usage with <xref target="RFC3140"/>
already exist and hence no new registry needs to be created by this document. The
encoding requires three cases need to be differentiated. All bits indicated as
"reserved" MUST be set to zero (0). </t>
<section title="Case 1: Single PHB">
<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>
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
</section>
<section title="Case 2: Set of PHBs">
<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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 1 0| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
</section>
<section title="Case 3: Experimental or Local Use PHBs">
<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> 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>
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHD ID CODE |0 0 1 0| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
</section>
</section>
<section title="DSTE-Class-Type AVP">
<t>The DSTE-Class-Type AVP (AVP Code TBD) is of type Unsigned32. A description of the
semantic of the parameter values can be found in <xref target="RFC4124"/>. </t>
<t> Currently, the values of alues currently allowed are 1, 2, 3, 4, 5, 6, 7. The value
of zero (0) is marked as reserved in <xref target="RFC4124"/>. Furthermore, the
CLASSTYPE attribute in <xref target="RFC4124"/> is 32 bits in length with 29 bits
reserved.</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 that 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. Finally, it is also possible to register a specific QoS
profile that defines a specific set of QoS values rather than parameters that need to be
filled with values in order to be used.</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 as Enterprise Numbers defined in <xref target="RFC2578"/>, 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">
<section toc="exclude" title="AVP Codes">
<t>IANA is requested to allocate AVP codes for the following AVPs that are defined in
this document.</t>
<t>
<figure>
<artwork><![CDATA[
+------------------------------------------------------------------+
| AVP Section |
|AVP Name Code Defined Data Type |
+------------------------------------------------------------------+
|TMOD-1 TBD 3.1 Grouped |
|TMOD-Rate TBD 3.1.1 Float32 |
|TMOD-Size TBD 3.1.2 Float32 |
|Peak-Data-Rate TBD 3.1.3 Float32 |
|Minimum-Policed-Unit TBD 3.1.4 Unsigned32 |
|TMOD-2 TBD 3.2 Grouped |
|Bandwidth TBD 3.3 Float32 |
|Priority TBD 3.4 Grouped |
|Preemption-Priority TBD 3.4.1 Unsigned32 |
|Defending-Priority TBD 3.4.2 Unsigned32 |
|Admission-Priority TBD 3.5 Unsigned32 |
|ALRP TBD 3.6 Grouped |
|ALRP-Namespace TBD 3.6.1 Unsigned32 |
|ALRP-Priority TBD 3.6.2 Unsigned32 |
|PHB-Class TBD 3.7 Unsigned32 |
|DSTE-Class-Type TBD 3.8 Unsigned32 |
+------------------------------------------------------------------+
]]></artwork>
</figure>
</t>
</section>
<section toc="exclude" title="QoS Profile">
<t>IANA is requested to create the following registry.</t>
<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>0 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>
<!-- ====================================================================== -->
<section title="Security Considerations">
<t>This document does not raise any security concerns as it only defines QoS parameters and
does not yet describe how they are exchanged in a AAA protocol. Security considerations
are described in documents using this specification.</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. The authors of this document are thankful
for the suggestions and input received from the NSIS QSPEC <xref
target="I-D.ietf-nsis-qspec"/> authors.</t>
<t>We would like to thank Ken Carlberg, Lars Eggert, Jan Engelhardt, Francois Le Faucheur,
John Loughney, An Nguyen, Dave Oran, James Polk, Martin Stiemerling, and Magnus
Westerlund for their help with resolving problems regarding the Admission Priority and
the ALRP parameter. </t>
<t>Jerry Ash, Al Morton, Mayutan Arumaithurai and Xiaoming Fu provided help with the
semantic of some QSPEC parameters. </t>
<t>We would like to thank Dan Romascanu for his detailed Area Director review comments and
Scott Bradner for his Transport Area Directorate review.</t>
</section>
<!-- ====================================================================== -->
</middle>
<back>
<references title="Normative References"> &RFC2119; &RFC4124; &RFC2210;
&RFC2215; &RFC3181; &RFC4412; &RFC3140; &RFC2474; &RFC2597;
&I-D.ietf-tsvwg-emergency-rsvp; &RFC2578; </references>
<references title="Informative References"> &RFC3564; &RFC3290; &RFC2475;
&RFC5226; &I-D.ietf-nsis-qspec; &RFC2697; </references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:56:47 |