One document matched: draft-ietf-dime-qos-parameters-11.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 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 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 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'>
<!ENTITY RFC3588 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml'>
<!ENTITY RFC3260 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3260.xml'>
<!ENTITY RFC3246 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3246.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="trust200902" category="std" docName="draft-ietf-dime-qos-parameters-11.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, a bandwidth parameter, and a per-hop behavior class object.</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 <xref target="RFC3588"
/>. The current set of QoS parameters defined in this document are a core subset
determined to be useful for a wide range of applications. Additional parameters may be
defined in future documents as the need arises and are for future study. The parameters
are defined as Diameter encoded Attribute Value Pairs (AVPs) described using a modified
version of the Augmented Backus-Naur Form (ABNF), see <xref target="RFC3588"/>. The
datatypes are also taken from <xref target="RFC3588"/>.</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>token rate (r)</t>
<t>bucket depth (b)</t>
<t>peak traffic rate (p)</t>
<t>minimum policed unit (m)</t>
<t>maximum packet size (M)</t>
</list>
</t>
<t> The encoding of the <TMOD-1> and the <TMOD-2> AVP can be
found in <xref target="tmod1"/> and <xref target="tmod2"/>. The semantics of these two
AVPs are described in Section 3.1 of <xref target="RFC2210"/> and in Section 3.6 of
<xref target="RFC2215"/>.</t>
<t>The <TMOD-2> AVP is, for example, needed by some DiffServ applications.
<list style="empty">
<t>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>
</list>
</t>
<t> Resource reservations might refer to a packet processing with a particular DiffServ
per-hop behavior (PHB) (using the <PHB-Class> AVP). A generic description
of the DiffServ architecture can be found in <xref target="RFC2475"/> and the
Differentiated Services Field is described in Section 3 of <xref target="RFC2474"/>.
Updated terminology can be found in <xref target="RFC3260"/>. Standardized Per-Hop
Behavior is, for example, described in <xref target="RFC2597"/> (Assured Forwarding
Per-Hop Behavior) and in <xref target="RFC3246"/> (An Expedited Forwarding Per-Hop
Behavior).</t>
<t>The above-mentioned parameters are intended to support basic integrated and
differentiated services functionality in the network. Additional parameters can be
defined and standardized if required to support specific services in future.</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 >
{ Token-Rate }
{ Bucket-Depth }
{ Peak-Traffic-Rate }
{ Minimum-Policed-Unit }
{ Maximum-Packet-Size }
]]></artwork>
</figure>
</t>
<section title="Token-Rate AVP">
<t> The Token-Rate AVP (AVP Code TBD) is of type Float32.</t>
</section>
<section title="Bucket-Depth AVP">
<t> The Bucket-Depth AVP (AVP Code TBD) is of type Float32.</t>
</section>
<section title="Peak-Traffic-Rate AVP">
<t> The Peak-Traffic-Rate AVP (AVP Code TBD) is of type Float32. </t>
</section>
<section title="Minimum-Policed-Unit AVP">
<t> The Minimum-Policed-Unit AVP (AVP Code TBD) is of type Unsigned32. </t>
</section>
<section title="Maximum-Packet-Size AVP">
<t> The Maximum-Packet-Size AVP (AVP Code TBD) is of type Unsigned32. </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 coding for the TMOD-2 AVP is as follows: <figure>
<artwork><![CDATA[
TMOD-2 ::= < AVP Header: TBD >
{ Token-Rate }
{ Bucket-Depth }
{ Peak-Traffic-Rate }
{ Minimum-Policed-Unit }
{ Maximum-Packet-Size }
]]></artwork>
</figure></t>
</section>
<section title="Bandwidth AVP">
<t> The Bandwidth AVP (AVP Code TBD) is of type Float32 and is measured in octets of IP
datagrams per second. The Bandwidth AVP represents a simplified description of the
following TMOD setting whereby the token rate (r) = peak traffic rate (p), the bucket
depth (b) = large, minimum policed unit (m) = large when only bandwidth has to be
expressed. </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>
<!-- ====================================================================== -->
<section title="Extensibility">
<t>This document is designed with extensibility in mind given that different organizations
and groups are used to defining 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 contains
an Enterprise Number as defined in <xref target="RFC2578"/> taken from the values
maintained in the IANA Enterprise Numbers registry. If the four octets of the vendor
field are 0x00000000 (reserved value for IANA), then the value in the specifier field
MUST be registered with IANA (see Section 5.2). If the vendor field is other than
0x00000000, the value of the specifier field represents a vendor-specific value, where
allocation is the responsibility of the enterprise indicated in the vendor field. </t>
</section>
<!-- ====================================================================== -->
<section title="IANA Considerations">
<section toc="exclude" title="AVP Codes">
<t>IANA is requested to allocate AVP codes in the IETF IANA controlled namespace
registry specified in Section 11.1.1 of <xref target="RFC3588"/> 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 |
|Token-Rate TBD 3.1.1 Float32 |
|Bucket-Depth TBD 3.1.2 Float32 |
|Peak-Traffic-Rate TBD 3.1.3 Float32 |
|Minimum-Policed-Unit TBD 3.1.4 Unsigned32 |
|Maximum-Packet-Size TBD 3.1.5 Unsigned32 |
|TMOD-2 TBD 3.2 Grouped |
|Bandwidth TBD 3.3 Float32 |
|PHB-Class TBD 3.7 Unsigned32 |
+------------------------------------------------------------------+
]]></artwork>
</figure>
</t>
</section>
<section toc="exclude" 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. </t>
<t>If the four octets of the vendor field are 0x00000000, then the value is
standards-specified and a registry will be created to maintain the QoS profile
specifier values. The specifier field indicates the actual QoS profile. Depending on
the value requested, the action needed to request a new value is: <list style="empty">
<t>0 to 511: Standards Action</t>
<t>512 to 32767: Specification Required</t>
<t>32768 to 4294967295: Reserved</t>
</list>
</t>
<t>Standards action is required to add, depreciate, delete, or modify QoS profile values
in the range of 0-511 and a specification is required to add, depreciate, delete, or
modify existing QoS profile values in the range of 512-32767.</t>
<t> 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> Alternative vendor-specific QoS profiles can be created and identified with a
Enterprise Number taken from the IANA registry created by <xref target="RFC2578"/> in
the vendor field combined with a vendor-specific value in the specifier field.
Allocation of the specifier values is the responsibility of the vendor. </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 working group members Cornelia Kappler, Jerry
Ash, Attila Bader, and Dave Oran, the former 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 Ken Carlberg, Lars Eggert, Jan Engelhardt, Francois Le Faucheur,
John Loughney, An Nguyen, Dave Oran, James Polk, Martin Dolly, Martin Stiemerling, and
Magnus Westerlund for their feedback regarding some of the parameters in this documents. </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. Chris Newman, Adrian Farrel and
Pasi Eronen provided feedback during the IESG review.</t>
</section>
<!-- ====================================================================== -->
</middle>
<back>
<references title="Normative References"> &RFC2119; &RFC2210; &RFC2215;
&RFC3140; &RFC2474; &RFC2578; &RFC3588; </references>
<references title="Informative References"> &RFC2475; &RFC2697; &RFC2597;
&RFC3260; &RFC3246; </references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:33:48 |