Diameter Maintenance and J. Korhonen, Ed.
Extensions (DIME) TeliaSonera
Internet-Draft H. Tschofenig
Intended status: Standards Track Nokia Siemens Networks
Expires: November 27, 2008 May 26, 2008
Quality of Service Parameters for Usage with the AAA Framework
draft-ietf-dime-qos-parameters-04.txt
draft-ietf-dime-qos-parameters-05.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
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
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 27, 2008.
Abstract
This document defines a number of Quality of Service (QoS) parameters
that can be reused for conveying QoS information within RADIUS and
Diameter.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 4
1.1. Traffic Model Parameter . . . . . . . . . . . . . . . . . 4
1.2. Constraints Parameters . . . . . . . . . . . . . . . . . . 4
1.3. Traffic Handling Directives . . . . . . . . . . . . . . . 5
1.4. Traffic Classes . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 6
3. Parameter Overview AVP Definition . . . . . . . . . . . . . . . . . . . . . . 3 . . 6
3.1. Traffic Model Parameter TMOD-1 AVP . . . . . . . . . . . . . . . . . 3
3.2. Constraints Parameters . . . . . . . 6
3.1.1. TMOD-Rate-1 AVP . . . . . . . . . . . 3
3.3. Traffic Handling Directives . . . . . . . . 6
3.1.2. TMOD-Size-1 AVP . . . . . . . 5
3.4. Traffic Classifiers . . . . . . . . . . . . 6
3.1.3. Peak-Data-Rate-1 AVP . . . . . . . 5
4. Parameter Encoding . . . . . . . . . . 6
3.1.4. Minimum-Policed-Unit-1 AVP . . . . . . . . . . . . 5
4.1. Parameter Header . . 6
3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . 5
4.2. TMOD-1 Parameter . . . . . 7
3.2.1. TMOD-Rate-2 AVP . . . . . . . . . . . . . . . . 5
4.3. TMOD-2 Parameter . . . 7
3.2.2. TMOD-Size-2 AVP . . . . . . . . . . . . . . . . . . 6
4.4. Path Latency Parameter . 7
3.2.3. Peak-Data-Rate-2 AVP . . . . . . . . . . . . . . . . . 7
4.5. Path Jitter Parameter
3.2.4. Minimum-Policed-Unit-2 AVP . . . . . . . . . . . . . . 7
3.3. Path-Latency AVP . . . . 7
4.6. Path PLR Parameter . . . . . . . . . . . . . . . . . 7
3.4. Path-Jitter AVP . . . 8
4.7. Path PER Parameter . . . . . . . . . . . . . . . . . . 8
3.4.1. Path-Jitter-STAT1 AVP . . 8
4.8. Slack Term Parameter . . . . . . . . . . . . . . 8
3.4.2. Path-Jitter-STAT2 AVP . . . . . 9
4.9. Preemption Priority amp; Defending Priority Parameters . . 9
4.10. Admission Priority Parameter . . . . . . . . . 8
3.4.3. Path-Jitter-STAT3 AVP . . . . . . 10
4.11. Application-Level Resource Priority (ALRP) Parameter . . . 10
4.12. Excess Treatment Parameter . . . . . . . 8
3.4.4. Path-Jitter-STAT4 AVP . . . . . . . . . 11
4.13. PHB Class Parameter . . . . . . . 8
3.5. Path-PLR AVP . . . . . . . . . . . . 12
4.14. DSTE Class Type Parameter . . . . . . . . . . . 8
3.6. Path-PER AVP . . . . . 13
4.15. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 13
5. Extensibility . . 9
3.7. Slack-Term AVP . . . . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations 9
3.8. Priority AVP . . . . . . . . . . . . . . . . . . . . . 15
6.1. QoS Profile . . 9
3.8.1. Preemption-Priority AVP . . . . . . . . . . . . . . . 9
3.8.2. Defending-Priority AVP . . . . . . 16
6.2. Parameter ID . . . . . . . . . . 9
3.9. Admission-Priority AVP . . . . . . . . . . . . . 16
6.3. Excess Treatment Parameter . . . . . 9
3.10. ALRP AVP . . . . . . . . . . . 17
6.4. DSTE Class Type Parameter . . . . . . . . . . . . . . 10
3.10.1. ALRP-Namespace AVP . . 17
6.5. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 18
7. Security Considerations 10
3.10.2. ALRP-Priority AVP . . . . . . . . . . . . . . . . . . 10
3.11. Excess-Treatment AVP . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . 10
3.11.1. Excess-Treatment-Value AVP . . . . . 18
9. References . . . . . . . . . 11
3.11.2. Remark-Value AVP . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . 11
3.11.3. PHB-Class AVP . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . 12
3.11.4. DSTE-Class-Type AVP . . . . . . . . . . . . . . . 20
Authors' Addresses . . 13
3.11.5. Y.1541-QoS-Class AVP . . . . . . . . . . . . . . . . . 13
4. Extensibility . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22
1. Introduction . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5.1. QoS Profile . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. AVP Allocations . . . . . . . . . . . . . . . . . . . . . 16
5.3. Excess-Treatment AVP . . . . . . . . . . . . . . . . . . . 16
5.4. DSTE-Class-Type AVP . . . . . . . . . . . . . . . . . . . 16
5.5. Y.1541-QoS-Class AVP . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
1. Introduction
This document defines a number of Quality of Service (QoS) parameters
that can be reused for conveying QoS information within RADIUS and
Diameter.
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
3.1. Traffic Model Parameter
The Traffic Model (TMOD) parameter is a container consisting of four
sub-parameters:
o rate (r)
o bucket size (b)
o peak rate (p)
o minimum policed unit (m)
All four sub-parameters MUST be included in the TMOD parameter. The
TMOD parameter is a mathematically complete way to describe the
traffic source. If, for example, TMOD is set to specify bandwidth
only, then set r = peak rate = p, b = large, m = large. As another
example if TMOD is set for TCP traffic, then set r = average rate, b
= large, p = large.
3.2. Constraints Parameters
<Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> are can be reused for conveying QoS
parameters describing the desired path latency, path jitter information within RADIUS and path
bit error rate respectively.
Diameter.
The <Path Latency> parameter refers to the accumulated latency subsequent section give an overview of the
packet forwarding process associated with each QoS aware node along
the path, where the latency is parameters defined to be the mean packet delay
added by each such node. This delay results from speed-of-light
propagation delay, from packet processing limitations, or both. The
mean delay reflects the variable queuing delay that may be present.
The purpose of
this document.
1.1. Traffic Model Parameter
The Traffic Model (TMOD) 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 container consisting of this document. four
sub-parameters:
o rate (r)
o bucket size (b)
o peak rate (p)
o minimum policed unit (m)
The <Path Jitter> TMOD 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 a mathematically complete way 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 describe 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
traffic source. If, for example, TMOD is set to provide a nominal path jitter specify bandwidth
only, then set r = peak rate = p, b = large, m = large. As another
example if TMOD is set for use with services
that provide estimates or bounds on additional TCP traffic, then set r = average rate, b
= large, p = large.
1.2. Constraints Parameters
<Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> are QoS
parameters describing the desired path delay [RFC2212].
The procedures for collecting latency, path jitter information are outside the
scope of this document. and path
bit error rate respectively.
The <Path PLR> Latency> parameter refers to the accumulated packet loss rate
(PLR) latency of the
packet forwarding process associated with each QoS aware node along
the path path, where the PLR latency 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 mean packet forwarding process associated with each QoS aware
node, where the PER is defined to be the PER delay
added by each such node.
The <Slack Term> parameter refers to the difference between desired This delay and results from speed-of-light
propagation delay, from packet processing limitations, or both. The
mean delay obtained by using bandwidth reservation, and which is
used to reduce reflects the resource reservation for a flow [RFC2212]. variable queuing delay that may be present.
The <Preemption Priority> parameter refers to the priority of the new
flow compared with the <Defending Priority> purpose of previously admitted
flows. Once a flow is admitted, the preemption priority becomes
irrelevant. The <Defending Priority> this parameter is used to compare
with the preemption priority of new flows. For any specific flow,
its preemption priority MUST always be less than or equal is to the
defending priority. <Admission Priority> and <RPH Priority> provide
an essential way to differentiate flows for emergency services, ETS,
E911, etc., and assign them a higher admission priority than normal
priority flows and best-effort priority flows.
3.3. Traffic Handling Directives minimum path latency
for use with services which provide estimates or bounds on additional
path delay [RFC2212].
The <Excess Treatment> <Path Jitter> parameter describes how a refers to the accumulated jitter of the
packet forwarding process associated with each QoS aware node will
process excess traffic, that is, out-of-profile traffic. Excess
traffic MAY be dropped, shaped and/or remarked.
3.4. Traffic Classifiers
Resource reservations might refer along
the path, where the jitter is defined to a be the nominal jitter added
by each such node. IP packet processing with a
particular DiffServ per-hop behavior (PHB) [RFC2475] or to a
particular QoS class, e.g., Y.1541 QoS class jitter, or DiffServ-aware MPLS
traffic engineering (DSTE) class type [RFC3564], [RFC4124].
4. Parameter Encoding
4.1. Parameter Header
Each QoS parameter delay variation, is encoded defined
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 Section 3.4 of RFC 3393 [RFC3393], (Type-P-One-way-ipdv), and
where the subsequent 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 MUST be
interpreted. If the M flag is set and 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 is not
understood then it leads refers to an error. If the M flag accumulated packet loss rate
(PLR) of the packet forwarding process associated with each QoS aware
node along the path where the PLR is not
set and then not understood then it can defined to be ignored. the PLR added by
each such node.
The r bits are reserved.
Parameter ID: Assigned <Path PER> parameter refers to the accumulated packet error rate
(PER) of the packet forwarding process associated with each individual QoS parameter
4.2. TMOD-1 Parameter
<TMOD-1> = <r> <b> <p> <m> [RFC2210] , [RFC2215]
The above notation means that aware
node, where the 4 <TMOD-1> sub-parameters must PER is defined to be
carried in the <TMOD-1> parameter. PER added by each such node.
The coding for the <TMOD-1> <Slack Term> 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 refers to the difference between desired
delay and delay obtained by one 32-bit
integer in network byte order. The first floating point value using bandwidth reservation, and which is
used to reduce the
rate (r), resource reservation for a flow [RFC2212].
The <Preemption Priority> parameter refers to the second floating point value is priority of the bucket size (b), new
flow compared with the
third floating point <Defending Priority> of previously admitted
flows. Once a flow is admitted, the peak rate (p), and the first unsigned
integer preemption priority becomes
irrelevant. The <Defending Priority> parameter is used to compare
with 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 preemption priority of new flows. For any specific flow,
its preemption priority MUST always 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 or equal to the
defending priority. <Admission Priority> and <RPH Priority> provide
an exponent of
all ones (255) essential way to differentiate flows for emergency services, ETS,
E911, etc., and assign them a sign bit higher admission priority than normal
priority flows and mantissa of all zeroes.
4.3. TMOD-2 Parameter
A description of the semantic of the best-effort priority flows.
1.3. Traffic Handling Directives
The <Excess Treatment< parameter values can describes how a QoS aware node will
process excess traffic, that is, out-of-profile traffic. Excess
traffic MAY be found in
[RFC2215]. dropped, shaped and/or remarked.
1.4. Traffic Classes
Resource reservations might refer to a packet processing with a
particular DiffServ per-hop behavior (PHB) [RFC2475] or to a
particular QoS class, e.g., Y.1541 QoS class or DiffServ-aware MPLS
traffic engineering (DSTE) class type [RFC3564], [RFC4124].
2. Terminology and Abbreviations
The <TMOD-2> parameter may key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be needed interpreted as described in a DiffServ
environment. RFC2119 [RFC2119].
3. AVP Definition
3.1. TMOD-1 AVP
The coding for TMOD-1 AVP is obtained from [RFC2210] and [RFC2215]. The
structure of the <TMOD-2> parameter 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| 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
TMOD-1 ::= < AVP Header: TBD >
{ TMOD-Rate-1 }
{ TMOD-Size-1 }
{ Peak-Data-Rate-1 }
{ Minimum-Policed-Unit-1 }
3.1.1. TMOD-Rate-1 AVP
The TMOD-Rate-1 AVP (AVP Code TBD) is of type Float32 and contains
the rate (r).
3.1.2. TMOD-Size-1 AVP
The TMOD-Size-1 AVP (AVP Code TBD) is of type Float32 and contains
the bucket size (b).
3.1.3. Peak-Data-Rate-1 AVP
The Peak-Data-Rate-1 AVP (AVP Code TBD) is of type Float32 and
contains the peak rate (p).
3.1.4. Minimum-Policed-Unit-1 AVP
The Minimum-Policed-Unit-1 AVP (AVP Code TBD) is of type Unsigned32
and contains the minimum policed unit (m).
The values r, b, and p terms are represented as IEEE floating point values, values
and 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
3.2. TMOD-2 AVP
A description of the semantic of the parameter values can be found in
[RFC2210],[RFC2215]. The coding for the <Path Latency> 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| 3 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Latency (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path Latency is a single 32-bit integer in network byte order.
The composition rule for the <Path Latency> parameter is summation
with a clamp of (2**32 - 1) on the maximum value. The latencies are
average values reported in units of one microsecond. A system with
resolution less than one microsecond MUST set unused digits to zero.
The total latency added across all QoS aware nodes along of the path semantic of the parameter values can
range as high as (2**32)-2.
4.5. Path Jitter Parameter be found in
[RFC2215]. The TMOD-2 AVP is useful in a DiffServ environment. The
coding for the <Path Jitter> parameter 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| 4 |r|r|r|r| 4 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Jitter STAT1(variance) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT2(99.9%-ile) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT3(minimum Latency) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Jitter STAT4(Reserved) (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Path Jitter
TMOD-2 ::= < AVP Header: TBD >
{ TMOD-Rate-2 }
{ TMOD-Size-2 }
{ Peak-Data-Rate-2 }
{ Minimum-Policed-Unit-2 }
3.2.1. TMOD-Rate-2 AVP
The TMOD-Rate-2 AVP (AVP Code TBD) is a set of four 32-bit integers in network byte
order. The Path Jitter parameter is type Float32 and contains
the combination rate (r).
3.2.2. TMOD-Size-2 AVP
The TMOD-Size-2 AVP (AVP Code TBD) is of four
statistics describing type Float32 and contains
the Jitter distribution with a clamp bucket size (b).
3.2.3. Peak-Data-Rate-2 AVP
The Peak-Data-Rate-2 AVP (AVP Code TBD) is of (2**32
- 1) on type Float32 and
contains the maximum peak rate (p).
3.2.4. Minimum-Policed-Unit-2 AVP
The Minimum-Policed-Unit-2 AVP (AVP Code TBD) is of each value. type Unsigned32
and contains the minimum policed unit (m).
The jitter STATs values r, b, and p are reported in
units of one microsecond.
4.6. Path PLR Parameter
The coding for the <Path PLR> parameter is represented 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| 5 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Packet Loss Ratio (32-bit IEEE floating point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ point values
and 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.
3.3. Path-Latency AVP
The Path PLR semantic of the parameter values can be found in [RFC2210] and
[RFC2215]. The Path-Latency AVP (AVP Code TBD) is of type Integer32.
The composition rule for the path latency is summation with a single 32-bit single precision IEEE floating point
number in network byte order. clamp
of (2**32 - 1) on the maximum value. The PLRs latencies are average
values reported in units of
10^-11. one microsecond. A system with
resolution less than one microsecond MUST set unused digits to zero.
The total PLR latency added across all QoS aware nodes along the path can
range as high as 10^-1.
4.7. Path PER Parameter (2**32)-2.
3.4. Path-Jitter AVP
The coding for the <Path PLR> parameter Path-Jitter 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| 6 |r|r|r|r| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| Path Packet Error Ratio (32-bit floating point) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Path-Jitter ::= < AVP Header: TBD >
{ Path-Jitter-STAT1 }
{ Path-Jitter-STAT2 }
{ Path-Jitter-STAT3 }
{ Path-Jitter-STAT4 }
3.4.1. Path-Jitter-STAT1 AVP
The Path-Jitter-STAT1 AVP (AVP Code TBD) is of type Integer32 and
contains the variance.
3.4.2. Path-Jitter-STAT2 AVP
The Path-Jitter-STAT2 AVP (AVP Code TBD) is of type Integer32 and
contains the 99.9%-ile.
3.4.3. Path-Jitter-STAT3 AVP
The Path-Jitter-STAT3 AVP (AVP Code TBD) is of type Integer32 and
contains the minimum latency.
3.4.4. Path-Jitter-STAT4 AVP
The Path-Jitter-STAT4 AVP (AVP Code TBD) is of type Integer32 and is
reserved for future use.
The Path PER Path-Jitter AVP is the combination of four statistics describing
the jitter distribution with a single 32-bit single precision IEEE floating point
number clamp of (2**32 - 1) on the maximum of
each value. The jitter STATs are reported in network byte order. units of one
microsecond.
3.5. Path-PLR AVP
The Path-PLR AVP (AVP Code TBD) is of type Float32 and contains the
path packet loss ratio. The PERs PLRs are reported in units of 10^-11. A
system with resolution less than one microsecond MUST set unused
digits to zero. The total PER PLR added across all QoS aware nodes can
range as high as 10^-1.
4.8. Slack Term Parameter
A description of the semantic of the parameter values can be found in
[RFC2212], [RFC2215]. The coding for the <Path PLR> 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| 7 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Slack Term [S] (32-bit integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ high as 10^-1.
3.6. Path-PER AVP
The Path-PER AVP (AVP Code TBD) is of type Float32 and contains the
path packet error ratio. The Slack Term parameter S PERs are reported in units of 10^-11.
A system with resolution less than one microsecond MUST set unused
digits to zero. The total PER added across all QoS aware nodes can
range as high as 10^-1.
3.7. Slack-Term AVP
The Slack-Term AVP (AVP Code TBD) is a 32-bit integer value of type Integer32 and its
semantic can be found in network byte
order [RFC2212] and is [RFC2215]. The Slack-Term AVP
contains values measured in microseconds. S is represented as a 32-bit
integer. Its microseconds and its value can range from
0 to (2**32)-1 microseconds.
4.9. Preemption
3.8. Priority amp; Defending AVP
The Priority Parameters AVP is a grouped AVP consisting of two AVPs, the
Preemption-Priority and the Defending-Priority AVP. A description of
the semantic of the parameter values can be found in [RFC3181].
The coding for the <Preemption Priority> & <Defending Priority> sub-
parameters 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| 8 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preemption Priority | Defending
Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Preemption Priority: The ::= < AVP Header: TBD >
{ Preemption-Priority }
{ Defending-Priority }
3.8.1. Preemption-Priority AVP
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.
Defending Priority:
3.8.2. Defending-Priority AVP
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.
As specified in [RFC3181], <Preemption Priority> & <Defending
Priority> are 16-bit integer values. They are represented in network
byte order.
4.10. Admission Priority Parameter
The coding for the <Admission Priority> 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| 9 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Admis.Priority| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The 'Admis.Priority' field
3.9. Admission-Priority AVP
The Admission-Priority AVP (AVP Code TBD) is a 8 bit unsigned integer in network
byte order. of type Unsigned32.
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 admission priority is encoded in this information
element using the same value as when encoded in the Admission Admission-
Priority parameter AVP defined in Section 6.2.9 of [I-D.ietf-nsis-qspec], or in
the Admission Priority parameter defined in Section 3.1 of
[I-D.ietf-tsvwg-emergency-rsvp]. In other words, a given value
inside the Admission Priority information element defined in other words, a given value
inside the
present document, Admission-Priority AVP, inside the [I-D.ietf-nsis-qspec] Admission Priority
admission priority parameter or inside the
[I-D.ietf-tsvwg-emergency-rsvp] Admission
Priority admission priority parameter, refers
to the same Admission Priority.
4.11. admission priority.
3.10. ALRP AVP
The Application-Level Resource Priority (ALRP) Parameter 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
[RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for
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| 10 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ALRP Namespace |
ALRP Priority | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ALRP Namespace field ::= < AVP Header: TBD >
{ ALRP-Namespace }
{ ALRP-Priority }
3.10.1. ALRP-Namespace AVP
The ALRP-Namespace AVP (AVP Code TBD) is a 16 bits long unsigned integer in
network byte order and the ALRP Priority field of type Unsigned32.
3.10.2. ALRP-Priority AVP
The Path-Jitter-STAT4 AVP (AVP Code TBD) is an 8 bit long
unsigned integer in network byte order containing the specific
priority value. of type Unsigned32.
[RFC4412] defines a resource priority header and established the
initial registry; that registry was later extended by
[I-D.ietf-tsvwg-emergency-rsvp].
4.12. Excess
3.11. Excess-Treatment AVP
The Excess-Treatment AVP is a grouped AVP consisting of two AVPs, the
Treatment Parameter and the Remark-Value AVP.
The coding for the <Excess Treatment> parameter Excess-Treatment 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| 11 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Excess Trtmnt | Remark Value | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Excess Treatment (8 bit unsigned integer value in network byte
order): Indicates
Excess-Treatment ::= < AVP Header: TBD >
{ Excess-Treatment-Value }
[ Remark-Value ]
3.11.1. Excess-Treatment-Value AVP
The Excess-Treatment-Value AVP (AVP Code TBD) is of type Enumerated
and indicates how the a QoS aware node should process out-of-
profile traffic, that is, traffic not covered by the <Traffic>
parameter. Allowed out-of-profile
traffic. The following values are as follows: currently defined:
0: drop
1: shape
2: remark
3: no metering or policing is permitted
The default excess treatment in case that none is specified is that there
are no guarantees to excess traffic, i.e., a QoS aware node can do
what it finds suitable.
When excess the treatment is set to 'drop', all marked traffic MUST be
dropped by a QoS aware node.
When excess the treatment is set to 'shape', it is expected that the QoS
Desired object carries
parameters conveyed as part of QoS-Desired are used to reshape the
traffic (for example a TMOD parameter. Excess traffic is to be
shaped to this TMOD. parameter indicated as QoS desired).
When the shaping causes unbounded queue growth at the shaper traffic
can be dropped.
When excess the treatment is set to 'remark', the excess treatment parameter
MUST carry the remark value. For example, packets may be remarked to
drop remarked to pertain to a particular QoS class. In the latter
case, remarking relates to a DiffServ-type model, where packets
arrive marked as belonging to a certain QoS class, and when they are
identified as excess, they should then be remarked to a different QoS
Class. The Remark-Value AVP carries the information used for re-
marking.
If 'no metering or policing is permitted' is signaled, indicated, the QoS aware
node should accept the excess treatment parameter set by the sender with special care
so that excess traffic should not cause a problem. To request the
Null Meter [RFC3290] is especially strong, and should be used with
caution.
The Remark Value
3.11.2. Remark-Value AVP
The Remark-Value AVP (AVP Code TBD) is of type Unsigned32 and
contains the DSCP value the excess traffic should be remarked to.
3.11.3. PHB-Class AVP
The PHB-Class AVP (AVP Code TBD) is of type OctetString and is an 8 bit unsigned integer value in network byte
order.
4.13. PHB Class Parameter two
octets long. A description of the semantic of the parameter values
can be found in [RFC3140]. The coding for the <PHB Class> parameter values 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| 12 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
As prescribed in [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.
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.)
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 X 0|
+---+---+---+---+---+---+---+---+
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
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.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHD ID CODE |0 0 X 0|
+---+---+---+---+---+---+---+---+
Bits 12 and 13 are reserved either for expansion of the PHB
identification code, or for other use, at some point in the future.
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
[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.
The registries needed to use [RFC3140] already exist. Hence, no new
registry needs to be created for this purpose.
4.14. DSTE Class Type Parameter
3.11.4. DSTE-Class-Type AVP
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
[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
Currently, the DSTE class type. Values values of alues 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
3.11.5. Y.1541-QoS-Class AVP
The Y.1541-QoS-Class AVP (AVP Code TBD) is not used.
4.15. Y.1541 QoS Class Parameter of type Unsigned32. A
description of the semantic of the parameter values can be found in
[Y.1541]. The coding for
Currently, the <Y.1541 QoS Class> 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| 14 |r|r|r|r| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Y.1541 QoS Cls.| (Reserved) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Y.1541 QoS Class: Indicates allowed values of the Y.1541 QoS Class. Values currently
allowed class are 0, 1, 2, 3,
4, 5, 6, 7. A value of 255 (all 1's) means
that the <Y.1541 QoS Class> parameter is not used.
Class 0:
Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <=
10^-3. Real-time, highly interactive applications, sensitive to
jitter. Application examples include VoIP, Video Teleconference.
Class 1:
Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <=
10^-3. Real-time, interactive applications, sensitive to jitter.
Application examples include VoIP, Video Teleconference.
Class 2:
Mean delay <= 100 ms, delay variation unspecified, loss ratio <=
10^-3. Highly interactive transaction data. Application examples
include signaling.
Class 3:
Mean delay <= 400 ms, delay variation unspecified, loss ratio <=
10^-3. Interactive transaction data. Application examples
include signaling.
Class 4:
Mean delay <= 1 sec, delay variation unspecified, loss ratio <=
10^-3. Low Loss Only applications. Application examples include
short transactions, bulk data, video streaming.
Class 5:
Mean delay unspecified, delay variation unspecified, loss ratio
unspecified. Unspecified applications. Application examples
include traditional applications of default IP networks.
Class 6:
Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <=
10^-5. Applications that are highly sensitive to loss, such as
television transport, high-capacity TCP transfers, and TDM circuit
emulation.
Class 7:
Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <=
10^-5. Applications that are highly sensitive to loss, such as
television transport, high-capacity TCP transfers, and TDM circuit
emulation.
5.
4. Extensibility
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 QoS parameters. Ideally, these parameters
should be used whenever possible but there are cases where additional
parameters might be needed, or where the parameters specified in this
document are used with a different semantic. In this case it is
advisable to define a new QoS profile that may consist of new
parameters in addition to parameters defined in this document or an
entirely different set of parameters.
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. A QoS profile groups together a bunch of QoS
parameters for usage in a specific environment. The vendor field
indicates the type as either standards-specified or vendor-specific.
If the four octets of the vendor field are 0x00000000, then the value
is standards-specified and the registry is maintained by IANA, and
any other value represents a vendor-specific Object Identifier (OID).
IANA created registry is split into two value ranges; one range uses
the "Standards Action" and the second range uses "Specification
Required" allocation policy. The latter range is meant to be used by
organizations outside the IETF.
6.
5. IANA Considerations
This section defines the registries and initial codepoint
assignments, in accordance with BCP 26 RFC 2434 [RFC2434]. [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
subsections below.
6.1.
5.1. QoS Profile
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).
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.
For any other vendor field, the specifier field is maintained by the
vendor.
For the IANA maintained QoS profiles the following allocation policy
is defined:
1 to 511: Standards Action
512 to 4095: Specification Required
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.
6.2. Parameter ID
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 profile values are as follows:
14-127: Standards Action
128-255: Private/Experimental Use
255-4095: Specification Required
A standards track document in the range of 0-511 and a specification
is required to depreciate, delete, or modify existing Parameter IDs.
6.3. Excess Treatment Parameter
The Excess Treatment parameter refers QoS profile
values in the range of 512-4095.
5.2. AVP Allocations
This specification assigns the values TBD1 to an 8 bit long field. TBD2 from the AVP Code
namespace defined in [RFC3588]. See Section 3 for the assignment of
the namespace in this specification.
5.3. Excess-Treatment AVP
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: Value 3: no metering or policing is permitted
Excess Treatment Values 4-63: Standards Action
Excess Treatment Value 64-255: 64-2^32-1: Reserved
The 8 bit Remark Value allocation policies are as follows:
0-63: Specification Required
64-127: Private/Experimental Use
128-255: Reserved
6.4. DSTE Class Type Parameter
The DSTE Class Type parameter refers to an 8 bit long field.
5.4. DSTE-Class-Type AVP
The following values are allocated by this specification:
DSTE Class Type Value 0: DSTE Class Type 0
DSTE Class Type Value 1: DSTE Class Type 1
DSTE Class Type Value 2: DSTE Class Type 2
DSTE Class Type Value 3: DSTE Class Type 3
DSTE Class Type Value 4: DSTE Class Type 4
DSTE Class Type Value 5: DSTE Class Type 5
DSTE Class Type Value 6: DSTE Class Type 6
DSTE Class Type Value 7: DSTE Class Type 7
DSTE Class Type Values 8-63: Standards Action
DSTE Class Type Values 64-255: 64-2^32-1: Reserved
6.5. Y.1541 QoS Class Parameter
The Y.1541 QoS Class parameter refers to an 8 bit long field.
5.5. Y.1541-QoS-Class AVP
The following values are allocated by this specification:
Y.1541 QoS Class Value 0: Y.1541 QoS Class 0
Y.1541 QoS Class Value 1: Y.1541 QoS Class 1
Y.1541 QoS Class Value 2: Y.1541 QoS Class 2
Y.1541 QoS Class Value 3: Y.1541 QoS Class 3
Y.1541 QoS Class Value 4: Y.1541 QoS Class 4
Y.1541 QoS Class Value 5: Y.1541 QoS Class 5
Y.1541 QoS Class Value 6: Y.1541 QoS Class 6
Y.1541 QoS Class Value 7: Y.1541 QoS Class 7
Y.1541 QoS Class Values 8-63: Standards Action
Y.1541 QoS Class Values 64-255: 64-2^32-1: Reserved
The ALRP Namespace values in the ALRP-Namespace and ALRP Priority field ALRP-Priority AV{ inside the
ALRP Parameter AVP 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.
6. Security Considerations
This document does not raise any security concerns as it only defines
QoS parameters.
8.
7. Acknowledgements
The authors would like to thank the NSIS QSPEC [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.
We would like to thank Francois Le Faucheur, John Loughney, Martin
Stiemerling, Dave Oran, An Nguyen, Ken Carlberg, James Polk, Lars
Eggert, and Magnus Westerlund for their help with resolving problems
regarding the Admission Priority and the ALRP parameter.
9.
8. References
9.1.
8.1. Normative References
[I-D.ietf-tsvwg-emergency-rsvp]
Faucheur, F., Polk, J., and K. Carlberg, "Resource
ReSerVation Protovol (RSVP) Extensions for Emergency
Services", draft-ietf-tsvwg-emergency-rsvp-08 (work in
progress), May 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
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
Parameters for Integrated Service Network Elements",
RFC 2215, September 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur,
"Per Hop Behavior Identification Codes", RFC 3140,
June 2001.
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element",
RFC 3181, October 2001.
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
Informal Management Model for Diffserv Routers", RFC 3290,
May 2002.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002.
[RFC3564] Le Faucheur, F.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and W. Lai, "Requirements for Support of
Differentiated Services-aware MPLS Traffic Engineering", J.
Arkko, "Diameter Base Protocol", RFC 3564, July 3588, September 2003.
[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124,
June 2005.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)",
RFC 4412, February 2006.
[Y.1541] "Network Performance Objectives for IP-Based Services", ,
2006.
[Y.1571] "Admission Control Priority Levels in Next Generation
Networks", , July 2006.
9.2.
8.2. Informative References
[I-D.ietf-nsis-qspec]
Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP
QSPEC Template", draft-ietf-nsis-qspec-20 (work in
progress), April 2008.
[RFC2434]
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
Informal Management Model for Diffserv Routers", RFC 3290,
May 2002.
[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of
Differentiated Services-aware MPLS Traffic Engineering",
RFC 3564, July 2003.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. 5226,
May 2008.
[Y.1540] "Internet Protocol Data Communication Service - IP Packet
Transfer and Availability Performance Parameters", ,
December 2002.
Authors' Addresses
Jouni Korhonen (editor)
TeliaSonera
Teollisuuskatu 13
Sonera FIN-00051
Finland
Email: jouni.korhonen@teliasonera.com
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@nsn.com Hannes.Tschofenig@gmx.net
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.