draft-ietf-dime-qos-parameters-07.txt   draft-ietf-dime-qos-parameters-08.txt 
Diameter Maintenance and J. Korhonen, Ed. Diameter Maintenance and J. Korhonen, Ed.
Extensions (DIME) TeliaSonera Extensions (DIME) H. Tschofenig
Internet-Draft H. Tschofenig Internet-Draft Nokia Siemens Networks
Intended status: Standards Track Nokia Siemens Networks Intended status: Standards Track December 18, 2008
Expires: May 5, 2009 November 1, 2008 Expires: June 21, 2009
Quality of Service Parameters for Usage with the AAA Framework Quality of Service Parameters for Usage with Diameter
draft-ietf-dime-qos-parameters-07.txt draft-ietf-dime-qos-parameters-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 5, 2009. This Internet-Draft will expire on June 21, 2009.
Copyright Notice
Copyright (c) 2008 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract Abstract
This document defines a number of Quality of Service (QoS) parameters This document defines a number of Quality of Service (QoS) parameters
that can be reused for conveying QoS information within RADIUS and that can be reused for conveying QoS information within Diameter.
Diameter.
The payloads used to carry these QoS parameters are opaque for the The payloads used to carry these QoS parameters are opaque for the
AAA client and the AAA server itself and interpreted by the AAA client and the AAA server itself and interpreted by the
respective Resource Management Function. respective Resource Management Function.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. Parameter Overview . . . . . . . . . . . . . . . . . . . . . . 3 3. QoS Parameter Encoding . . . . . . . . . . . . . . . . . . . . 4
3.1. Traffic Model Parameter . . . . . . . . . . . . . . . . . 3 3.1. TMOD-1 AVP . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Constraints Parameters . . . . . . . . . . . . . . . . . . 3 3.1.1. TMOD-Rate AVP . . . . . . . . . . . . . . . . . . . . 4
3.3. Traffic Handling Directives . . . . . . . . . . . . . . . 5 3.1.2. TMOD-Size AVP . . . . . . . . . . . . . . . . . . . . 4
3.4. Traffic Classifiers . . . . . . . . . . . . . . . . . . . 5 3.1.3. Peak-Data-Rate AVP . . . . . . . . . . . . . . . . . . 4
4. Parameter Encoding . . . . . . . . . . . . . . . . . . . . . . 5 3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 4
4.1. Parameter Header . . . . . . . . . . . . . . . . . . . . . 5 3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. TMOD-1 Parameter . . . . . . . . . . . . . . . . . . . . . 5 3.3. Priority AVP . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. TMOD-2 Parameter . . . . . . . . . . . . . . . . . . . . . 6 3.3.1. Preemption-Priority AVP . . . . . . . . . . . . . . . 5
4.4. Path Latency Parameter . . . . . . . . . . . . . . . . . . 7 3.3.2. Defending-Priority AVP . . . . . . . . . . . . . . . . 5
4.5. Path Jitter Parameter . . . . . . . . . . . . . . . . . . 7 3.4. Admission-Priority AVP . . . . . . . . . . . . . . . . . . 5
4.6. Path PLR Parameter . . . . . . . . . . . . . . . . . . . . 8 3.5. ALRP AVP . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.7. Path PER Parameter . . . . . . . . . . . . . . . . . . . . 8 3.5.1. ALRP-Namespace AVP . . . . . . . . . . . . . . . . . . 6
4.8. Slack Term Parameter . . . . . . . . . . . . . . . . . . . 8 3.5.2. ALRP-Priority AVP . . . . . . . . . . . . . . . . . . 6
4.9. Preemption Priority amp; Defending Priority Parameters . . 9 3.6. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 6
4.10. Admission Priority Parameter . . . . . . . . . . . . . . . 9 3.6.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 6
4.11. Application-Level Resource Priority (ALRP) Parameter . . . 10 3.6.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 7
4.12. Excess Treatment Parameter . . . . . . . . . . . . . . . . 11 3.6.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 7
4.13. PHB Class Parameter . . . . . . . . . . . . . . . . . . . 12 3.7. DSTE-Class-Type AVP . . . . . . . . . . . . . . . . . . . 7
4.13.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . 12 4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8
4.13.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4.13.3. Case 3: Experimental or Local Use PHBs . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
4.14. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
4.15. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
6.1. QoS Profile . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Parameter ID . . . . . . . . . . . . . . . . . . . . . . . 15
6.3. Excess Treatment Parameter . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
1. Introduction 1. Introduction
This document defines a number of Quality of Service (QoS) parameters This document defines a number of Quality of Service (QoS) parameters
that can be reused for conveying QoS information within RADIUS and that can be reused for conveying QoS information within the Diameter
Diameter. protocol.
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.
2. Terminology and Abbreviations
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 [RFC2119].
3. Parameter Overview This document defines an initial QoS profile containing a set of QoS
AVPs.
3.1. Traffic Model Parameter The traffic model (TMOD) AVPs are containers consisting of four AVPs
and is a way to describe the traffic source.
The Traffic Model (TMOD) parameter is a container consisting of four
sub-parameters:
o rate (r) o rate (r)
o bucket size (b) o bucket size (b)
o peak rate (p) o peak rate (p)
o minimum policed unit (m) o minimum policed unit (m)
All four sub-parameters MUST be included in the TMOD parameter. The The encoding of <TMOD-1> and <TMOD-2> can be found in Section 3.1 and
TMOD parameter is a mathematically complete way to describe the Section 3.2 and the semantic is described in [RFC2210] and in
traffic source. If, for example, TMOD is set to specify bandwidth [RFC2215]. <TMOD-2> is, for example, needed by some DiffServ
only, then set r = peak rate = p, b = large, m = large. As another applications. I t is typically assumed that DiffServ EF traffic is
example if TMOD is set for TCP traffic, then set r = average rate, b shaped at the ingress by a single rate token bucket. Therefore, a
= large, p = large. single TMOD parameter is sufficient to signal DiffServ EF traffic.
However, for DiffServ AF traffic two sets of token bucket parameters
3.2. Constraints Parameters are needed, one token bucket for the average traffic and one token
bucket for the burst traffic. [RFC2697] defines a Single Rate Three
<Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> are QoS Color Marker (srTCM), which meters a traffic stream and marks its
parameters describing the desired path latency, path jitter and path packets according to three traffic parameters, Committed Information
error rate respectively. 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
The <Path Latency> parameter refers to the accumulated latency of the does not exceed the CBS, yellow if it does exceed the CBS, but not
packet forwarding process associated with each QoS aware node along the EBS, and red otherwise. [RFC2697] defines specific procedures
the path, where the latency is defined to be the mean packet delay using two token buckets that run at the same rate. Therefore, two
added by each such node. This delay results from speed-of-light TMOD AVPs are sufficient to distinguish among three levels of drop
propagation delay, from packet processing limitations, or both. The precedence. An example is also described in the appendix of
mean delay reflects the variable queuing delay that may be present. [RFC2597].
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 [RFC2212].
The procedures for collecting path latency information are outside
the scope of this document.
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 [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 [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 [RFC2212].
The procedures for collecting path jitter information are outside the
scope of this document.
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 path PLR is defined to be the PLR added
by each such node.
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 path PER is defined to be the PER added by each such
node.
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 [RFC2212].
The <Preemption Priority> parameter refers to the priority of the new The <Preemption-Priority> AVP refers to the priority of a new flow
flow compared with the <Defending Priority> of previously admitted compared with the <Defending-Priority> AVP of previously admitted
flows. Once a flow is admitted, the preemption priority becomes flows. Once a flow is admitted, the preemption priority becomes
irrelevant. The <Defending Priority> parameter is used to compare irrelevant. The <Defending-Priority> AVP is used to compare with the
with the preemption priority of new flows. For any specific flow, preemption priority of new flows. For any specific flow, its
its preemption priority MUST always be less than or equal to the preemption priority is always less than or equal to the defending
defending priority. <Admission Priority> and <RPH Priority> provide priority.
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.
3.3. Traffic Handling Directives
The <Excess Treatment> parameter describes how a QoS aware node will
process excess traffic, that is, out-of-profile traffic. Dopping,
shaping or remarking are possible actions.
3.4. Traffic Classifiers 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.
Resource reservations might refer to a packet processing with a Resource reservations might refer to a packet processing with a
particular DiffServ per-hop behavior (PHB) [RFC2475] or to a particular DiffServ per-hop behavior (PHB) [RFC2475] (using the <PHB-
particular QoS class, e.g., Y.1541 QoS class or DiffServ-aware MPLS Class> AVP) or to a particular QoS class, e.g., a DiffServ-aware MPLS
traffic engineering (DSTE) class type [RFC3564], [RFC4124]. traffic engineering (DSTE) class type, as described in [RFC3564] and
in [RFC4124], using the <DSTE-Class-Type> AVP.
4. Parameter Encoding
4.1. Parameter Header
Each QoS parameter is encoded in TLV format.
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
Length: Indicates the length of the subsequent data in 32-bit words.
4.2. TMOD-1 Parameter
<TMOD-1> = <r> <b> <p> <m> [RFC2210] , [RFC2215]
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:
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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).
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.
4.3. TMOD-2 Parameter
A description of the semantic of the parameter values can be found in
[RFC2215]. The <TMOD-2> parameter may be needed in a DiffServ
environment. The coding for the <TMOD-2> parameter is as follows:
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
4.4. Path Latency Parameter
A description of the semantic of the parameter values can be found in 2. Terminology and Abbreviations
[RFC2210],[RFC2215]. The coding for the <Path Latency> parameter is
as follows:
0 1 2 3 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
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 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ document are to be interpreted as described in RFC2119 [RFC2119].
|M|r|r|r| 3 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Latency (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path Latency is a single 32-bit integer in network byte order. 3. QoS Parameter Encoding
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.
4.5. Path Jitter Parameter 3.1. TMOD-1 AVP
The coding for the <Path Jitter> parameter is as follows: The TMOD-1 AVP is obtained from [RFC2210] and [RFC2215]. The
structure of the AVP is as follows:
0 1 2 3 TMOD-1 ::= < AVP Header: TBD >
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 { TMOD-Rate }
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ { TMOD-Size }
|M|r|r|r| 4 |r|r|r|r| 4 | { Peak-Data-Rate }
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ { Minimum-Policed-Unit }
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
4.6. Path PLR Parameter 3.1.1. TMOD-Rate AVP
The coding for the <Path PLR> parameter is as follows: The TMOD-Rate AVP (AVP Code TBD) is of type Float32 and contains the
rate (r).
0 1 2 3 3.1.2. TMOD-Size AVP
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path PLR is a single 32-bit single precision IEEE floating point The TMOD-Size AVP (AVP Code TBD) is of type Float32 and contains the
number in network byte order. The PLRs are reported in units of bucket size (b).
10^-11. A system with resolution less than one microsecond MUST set
unused digits to zero.
4.7. Path PER Parameter 3.1.3. Peak-Data-Rate AVP
The coding for the <Path PER> parameter is as follows: The Peak-Data-Rate AVP (AVP Code TBD) is of type Float32 and contains
the peak rate (p).
0 1 2 3 3.1.4. Minimum-Policed-Unit AVP
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path PER is a single 32-bit single precision IEEE floating point The Minimum-Policed-Unit AVP (AVP Code TBD) is of type Unsigned32 and
number in network byte order. The PERs are reported in units of contains the minimum policed unit (m).
10^-11. A system with resolution less than one microsecond MUST set
unused digits to zero.
4.8. Slack Term Parameter 3.2. TMOD-2 AVP
A description of the semantic of the parameter values can be found in A description of the semantic of the parameter values can be found in
[RFC2212], [RFC2215]. The coding for the <Slack Term> parameter is [RFC2215]. The TMOD-2 AVP is useful in a DiffServ environment. The
as follows: coding for the TMOD-2 AVP is as follows:
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
4.9. Preemption Priority amp; Defending Priority Parameters
A description of the semantic of the parameter values can be found in TMOD-2 ::= < AVP Header: TBD >
[RFC3181]. { TMOD-Rate }
{ TMOD-Size }
{ Peak-Data-Rate }
{ Minimum-Policed-Unit }
The coding for the <Preemption Priority> & <Defending Priority> sub- 3.3. Priority AVP
parameters is as follows:
0 1 2 3 The Priority AVP is a grouped AVP consisting of two AVPs, the
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 Preemption-Priority and the Defending-Priority AVP. A description of
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the semantic can be found in [RFC3181].
|M|r|r|r| 8 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preemption Priority | Defending Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Preemption Priority: The priority of the new flow compared with the Priority ::= < AVP Header: TBD >
defending priority of previously admitted flows. Higher values { Preemption-Priority }
represent higher priority. { Defending-Priority }
Defending Priority: Once a flow is admitted, the preemption priority 3.3.1. Preemption-Priority AVP
becomes irrelevant. Instead, its defending priority is used to
compare with the preemption priority of new flows.
As specified in [RFC3181], <Preemption Priority> & <Defending The Preemption-Priority AVP (AVP Code TBD) is of type Unsigned32 and
Priority> are 16-bit integer values. They are represented in network it indicates the priority of the new flow compared with the defending
byte order. priority of previously admitted flows. Higher values represent
higher priority.
4.10. Admission Priority Parameter 3.3.2. Defending-Priority AVP
The coding for the <Admission Priority> parameter is as follows: 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.
0 1 2 3 3.4. Admission-Priority AVP
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'Admis.Priority' field is a 8 bit unsigned integer in network The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32.
byte order.
The admission control priority of the flow, in terms of access to The admission control priority of the flow, in terms of access to
network bandwidth in order to provide higher probability of call network bandwidth in order to provide higher probability of call
completion to selected flows. Higher values represent higher completion to selected flows. Higher values represent higher
priority. A given Admission Priority is encoded in this information priority. A given admission priority is encoded in this information
element using the same value as when encoded in the Admission element using the same value as when encoded in the Admission-
Priority parameter defined in Section 6.2.9 of [I-D.ietf-nsis-qspec], Priority AVP defined in Section 3.1 of
or in the Admission Priority parameter defined in Section 3.1 of [I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter).
[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 [I-D.ietf-nsis-qspec] Admission Priority
parameter or inside the [I-D.ietf-tsvwg-emergency-rsvp] Admission
Priority parameter, refers to the same Admission Priority.
4.11. Application-Level Resource Priority (ALRP) Parameter 3.5. ALRP AVP
The Application-Level Resource Priority (ALRP) AVP is a grouped AVP
consisting of two AVPs, the ALRP-Namespace and the ALRP-Priority AVP.
A description of the semantic of the parameter values can be found in A description of the semantic of the parameter values can be found in
[RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for
parameter is as follows: parameter is as follows:
0 1 2 3 ALRP ::= < AVP Header: TBD >
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 { ALRP-Namespace }
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ { ALRP-Priority }
|M|r|r|r| 10 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ALRP Namespace | (Reserved) | ALRP Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
[RFC4412] defines a resource priority header and established the
initial registry; the encoding of the values in that registry was
later extended by [I-D.ietf-tsvwg-emergency-rsvp].
4.12. Excess Treatment Parameter
The coding for the <Excess Treatment> parameter is as follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
0: drop
1: shape
2: remark
3: no metering or policing is permitted
Further values can be registered as described in Section 6.3.
The default excess treatment in case that none is specified is that 3.5.1. ALRP-Namespace AVP
there are no guarantees to excess traffic, i.e., a QoS aware node can
do what it finds suitable.
When excess treatment is set to 'drop', all marked traffic MUST be The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32.
dropped by a QoS aware node.
When excess treatment is set to 'shape', it is expected that the QoS 3.5.2. ALRP-Priority AVP
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.
When excess treatment is set to 'remark', the excess treatment The ALRP-Priority AVP (AVP Code TBD) is of type Unsigned32.
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.
If 'no metering or policing is permitted' is signaled, the QoS aware [RFC4412] defines a resource priority header and established the
node should accept the excess treatment parameter set by the sender initial registry. That registry was later extended by
with special care so that excess traffic should not cause a problem. [I-D.ietf-tsvwg-emergency-rsvp].
To request the Null Meter [RFC3290] is especially strong, and should
be used with caution.
The Remark Value is an 8 bit unsigned integer value in network byte 3.6. PHB-Class AVP
order.
4.13. PHB Class Parameter The PHB-Class AVP (AVP Code TBD) is of type Unsigned32.
A description of the semantic of the parameter values can be found in A description of the semantic of the parameter values can be found in
[RFC3140]. The registries needed for usage with [RFC3140] already [RFC3140]. The registries needed for usage with [RFC3140] already
exist and hence no new registry needs to be created by this document. exist and hence no new registry needs to be created by this document.
The coding for the <PHB Class> parameter is as follows and three The encoding requires three cases need to be differentiated. All
different cases need to be differentiated. The header format is bits indicated as "reserved" MUST be set to zero (0).
shown in the subsequent figure below and is used by all three cases
defined in the subsequent sub-sections.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.13.1. Case 1: Single PHB 3.6.1. Case 1: Single PHB
As prescribed in [RFC3140], the encoding for a single PHB is the As prescribed in [RFC3140], the encoding for a single PHB is the
recommended DSCP value for that PHB, left-justified in the 16 bit recommended DSCP value for that PHB, left-justified in the 16 bit
field, with bits 6 through 15 set to zero. field, with bits 6 through 15 set to zero.
0 1 2 3 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 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) | | DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.13.2. Case 2: Set of PHBs 3.6.2. Case 2: Set of PHBs
The encoding for a set of PHBs is the numerically smallest of the set 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. 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 (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with
bit 14 set to 1.) bit 14 set to 1.)
0 1 2 3 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 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) | | DSCP |0 0 0 0 0 0 0 0 1 0| (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.13.3. Case 3: Experimental or Local Use PHBs 3.6.3. Case 3: Experimental or Local Use PHBs
PHBs not defined by standards action, i.e., experimental or local use PHBs not defined by standards action, i.e., experimental or local use
PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB
identification code, assigned by the IANA, is placed left-justified 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 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. single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero.
Bits 12 and 13 are reserved either for expansion of the PHB Bits 12 and 13 are reserved either for expansion of the PHB
identification code, or for other use, at some point in the future. identification code, or for other use, at some point in the future.
skipping to change at page 13, line 34 skipping to change at page 7, line 42
intra-microflow traffic reordering when different PHBs from the set intra-microflow traffic reordering when different PHBs from the set
are applied to traffic in the same microflow). The set of AF1x PHBs are applied to traffic in the same microflow). The set of AF1x PHBs
[RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that [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 do not constitute a PHB Scheduling Class can be identified by using
more than one PHBID. more than one PHBID.
0 1 2 3 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 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) | | PHD ID CODE |0 0 1 0| (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4.14. DSTE Class Type Parameter
A description of the semantic of the parameter values can be found in
[RFC4124]. The coding for the <DSTE Class Type> parameter is as
follows:
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) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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.
4.15. Y.1541 QoS Class Parameter
A description of the semantic of the parameter values can be found in 3.7. DSTE-Class-Type AVP
[Y.1541]. The coding for the <Y.1541 QoS Class> parameter is as
follows:
0 1 2 3 The DSTE-Class-Type AVP (AVP Code TBD) is of type Unsigned32. A
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 description of the semantic of the parameter values can be found in
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [RFC4124].
|M|r|r|r| 14 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Y.1541 QoS Cls.| (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently Currently, the values of alues currently allowed are 1, 2, 3, 4, 5,
allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means 6, 7. The value of zero (0) is marked as reserved in [RFC4124].
that the <Y.1541 QoS Class> parameter is not used. Furthermore, the CLASSTYPE attribute in [RFC4124] is 32 bits in
length with 29 bits reserved.
5. Extensibility 4. Extensibility
This document is designed with extensibility in mind given that This document is designed with extensibility in mind given that
different organizations and groups are used to define their own different organizations and groups are used to define their own
Quality of Service parameters. This document provides an initial QoS Quality of Service parameters. This document provides an initial QoS
profile with common set of parameters. Ideally, these parameters profile with common set of parameters. Ideally, these parameters
should be used whenever possible but there are cases where additional should be used whenever possible but there are cases where additional
parameters might be needed, or where the parameters specified in this parameters might be needed, or where the parameters specified in this
document are used with a different semantic. In this case it is document are used with a different semantic. In this case it is
advisable to define a new QoS profile that may consist of new advisable to define a new QoS profile that may consist of new
parameters in addition to parameters defined in this document or an parameters in addition to parameters defined in this document or an
skipping to change at page 15, line 5 skipping to change at page 8, line 33
specifier field. The vendor field indicates the type as either specifier field. The vendor field indicates the type as either
standards-specified or vendor-specific. If the four octets of the standards-specified or vendor-specific. If the four octets of the
vendor field are 0x00000000, then the value is standards-specified vendor field are 0x00000000, then the value is standards-specified
and the registry is maintained by IANA as Enterprise Numbers defined and the registry is maintained by IANA as Enterprise Numbers defined
in [RFC2578], and any other value represents a vendor-specific Object in [RFC2578], and any other value represents a vendor-specific Object
Identifier (OID). IANA created registry is split into two value Identifier (OID). IANA created registry is split into two value
ranges; one range uses the "Standards Action" and the second range ranges; one range uses the "Standards Action" and the second range
uses "Specification Required" allocation policy. The latter range is uses "Specification Required" allocation policy. The latter range is
meant to be used by organizations outside the IETF. meant to be used by organizations outside the IETF.
6. IANA Considerations 5. IANA Considerations
This section defines the registries and initial codepoint 5.1. AVP Codes
assignments, in accordance with BCP 26 RFC 5226 [RFC5226]. It also
defines the procedural requirements to be followed by IANA in
allocating new codepoints.
IANA is requested to create the following registries listed in the IANA is requested to allocate AVP codes for the following AVPs that
subsections below. are defined in this document.
6.1. QoS Profile +------------------------------------------------------------------+
| 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 |
|Priority TBD 3.3 Grouped |
|Preemption-Priority TBD 3.3.1 Unsigned32 |
|Defending-Priority TBD 3.3.2 Unsigned32 |
|Admission-Priority TBD 3.4 Unsigned32 |
|ALRP TBD 3.5 Grouped |
|ALRP-Namespace TBD 3.5.1 Unsigned32 |
|ALRP-Priority TBD 3.5.2 Unsigned32 |
|PHB-Class TBD 3.6 Unsigned32 |
|DSTE-Class-Type TBD 3.7 Unsigned32 |
+------------------------------------------------------------------+
5.2. QoS Profile
IANA is requested to create the following registry.
The QoS Profile refers to a 64 bit long field that is represented by 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 a 4-octet vendor and 4-octet specifier field. The vendor field
indicates the type as either standards-specified or vendor-specific. indicates the type as either standards-specified or vendor-specific.
If the four octets of the vendor field are 0x00000000, then the value If the four octets of the vendor field are 0x00000000, then the value
is standards-specified and the registry is maintained by IANA, and is standards-specified and the registry is maintained by IANA, and
any other value represents a vendor-specific Object Identifier (OID). any other value represents a vendor-specific Object Identifier (OID).
The specifier field indicates the actual QoS profile. The vendor The specifier field indicates the actual QoS profile. The vendor
field 0x00000000 is reserved to indicate that the values in the field 0x00000000 is reserved to indicate that the values in the
specifier field are maintained by IANA. This document requests IANA specifier field are maintained by IANA. This document requests IANA
to create such a registry and to allocate the value zero (0) for the to create such a registry and to allocate the value zero (0) for the
QoS profile defined in this document. QoS profile defined in this document.
For any other vendor field, the specifier field is maintained by the For any other vendor field, the specifier field is maintained by the
vendor. vendor.
For the IANA maintained QoS profiles the following allocation policy For the IANA maintained QoS profiles the following allocation policy
is defined: is defined:
1 to 511: Standards Action 0 to 511: Standards Action
512 to 4095: Specification Required 512 to 4095: Specification Required
Standards action is required to depreciate, delete, or modify Standards action is required to depreciate, delete, or modify
existing QoS profile values in the range of 0-511 and a specification existing QoS profile values in the range of 0-511 and a specification
is required to depreciate, delete, or modify existing QoS profile is required to depreciate, delete, or modify existing QoS profile
values in the range of 512-4095. values in the range of 512-4095.
6.2. Parameter ID 6. Security Considerations
The Parameter ID refers to a 12 bit long field.
The following values are allocated by this specification.
(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>
The allocation policies for further values are as follows:
14-127: Standards Action
128-255: Private/Experimental Use
255-4095: Specification Required
A standards track document is required to depreciate, delete, or
modify existing Parameter IDs.
6.3. Excess Treatment Parameter
The Excess Treatment parameter refers to an 8 bit long field.
The following values are allocated by this specification:
Excess Treatment Value 0: drop
Excess Treatment Value 1: shape
Excess Treatment Value 2: remark
Excess Treatment Value3: no metering or policing is permitted
Excess Treatment Values 4-63: Standards Action
Excess Treatment Value 64-255: Reserved
The 8 bit Remark Value allocation policies are as follows:
0-63: Specification Required
64-127: Private/Experimental Use
128-255: Reserved
The ALRP Namespace and ALRP Priority field inside the ALRP Parameter
take their values from the registry created by [RFC4412] and extended
with [I-D.ietf-tsvwg-emergency-rsvp] No additional actions are
required by IANA by this specification.
7. Security Considerations
This document does not raise any security concerns as it only defines This document does not raise any security concerns as it only defines
QoS parameters. QoS parameters and does not yet describe how they are exchanged in a
AAA protocol. Security considerations are described in documents
using this specification.
8. Acknowledgements 7. Acknowledgements
The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec] The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec]
authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the
NSIS working group chairs (John Loughney and Martin Stiemerling) and NSIS working group chairs (John Loughney and Martin Stiemerling) and
the former Transport Area Directors (Allison Mankin, Jon Peterson) the former Transport Area Directors (Allison Mankin, Jon Peterson)
for their help. for their help. This document re-uses content from the NSIS QSPEC
[I-D.ietf-nsis-qspec] specification.
We would like to thank Francois Le Faucheur, John Loughney, Martin We would like to thank Ken Carlberg, Lars Eggert, Jan Engelhardt,
Stiemerling, Dave Oran, An Nguyen, Ken Carlberg, James Polk, Lars Francois Le Faucheur, John Loughney, An Nguyen, Dave Oran, James
Eggert, and Magnus Westerlund for their help with resolving problems Polk, Martin Stiemerling, and Magnus Westerlund for their help with
regarding the Admission Priority and the ALRP parameter. resolving problems regarding the Admission Priority and the ALRP
parameter.
Elwyn Davies provided a detailed review of the specification. Elwyn
helped to investigate what QoS mechanisms are deployed in networks
today. Jerry Ash, Al Morton, Mayutan Arumaithurai and Xiaoming Fu
provided help with the semantic of some QSPEC parameters.
We would like to thank Dan Romascanu for his detailed Area Director We would like to thank Dan Romascanu for his detailed Area Director
review comments. review comments and Scott Bradner for his Transport Area Directorate
review.
9. References 8. References
9.1. Normative References 8.1. Normative References
[I-D.ietf-tsvwg-emergency-rsvp] [I-D.ietf-tsvwg-emergency-rsvp]
Faucheur, F., Polk, J., and K. Carlberg, "Resource Faucheur, F., Polk, J., and K. Carlberg, "Resource
ReSerVation Protovol (RSVP) Extensions for Emergency ReSerVation Protovol (RSVP) Extensions for Emergency
Services", draft-ietf-tsvwg-emergency-rsvp-09 (work in Services", draft-ietf-tsvwg-emergency-rsvp-09 (work in
progress), October 2008. progress), October 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997. Services", RFC 2210, September 1997.
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification
of Guaranteed Quality of Service", RFC 2212,
September 1997.
[RFC2215] Shenker, S. and J. Wroclawski, "General Characterization [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements", Parameters for Integrated Service Network Elements",
RFC 2215, September 1997. RFC 2215, September 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
skipping to change at page 18, line 22 skipping to change at page 11, line 32
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999. "Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur,
"Per Hop Behavior Identification Codes", RFC 3140, "Per Hop Behavior Identification Codes", RFC 3140,
June 2001. June 2001.
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element",
RFC 3181, October 2001. RFC 3181, October 2001.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002.
[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124, Diffserv-aware MPLS Traffic Engineering", RFC 4124,
June 2005. June 2005.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)", Priority for the Session Initiation Protocol (SIP)",
RFC 4412, February 2006. RFC 4412, February 2006.
[Y.1541] "ITU-T Recommendation Y.1541, Network Performance 8.2. Informative References
Objectives for IP-Based Services", , 2006.
9.2. Informative References
[I-D.ietf-nsis-qspec] [I-D.ietf-nsis-qspec]
Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC
QSPEC Template", draft-ietf-nsis-qspec-20 (work in Template", draft-ietf-nsis-qspec-21 (work in progress),
progress), April 2008. November 2008.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, September 1999.
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
Informal Management Model for Diffserv Routers", RFC 3290, Informal Management Model for Diffserv Routers", RFC 3290,
May 2002. May 2002.
[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of
Differentiated Services-aware MPLS Traffic Engineering", Differentiated Services-aware MPLS Traffic Engineering",
RFC 3564, July 2003. RFC 3564, July 2003.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[Y.1540] "ITU-T Recommendation Y.1540, Internet Protocol Data
Communication Service - IP Packet Transfer and
Availability Performance Parameters", , December 2002.
Authors' Addresses Authors' Addresses
Jouni Korhonen (editor) Jouni Korhonen (editor)
TeliaSonera Nokia Siemens Networks
Teollisuuskatu 13 Linnoitustie 6
Sonera FIN-00051 Espoo 02600
Finland Finland
Email: jouni.korhonen@teliasonera.com Email: jouni.korhonen@nsn.com
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 86 change blocks. 
554 lines changed or deleted 239 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/