draft-ietf-dime-qos-parameters-04.txt   draft-ietf-dime-qos-parameters-05.txt 
Diameter Maintenance and J. Korhonen, Ed. Diameter Maintenance and J. Korhonen, Ed.
Extensions (DIME) TeliaSonera Extensions (DIME) TeliaSonera
Internet-Draft H. Tschofenig Internet-Draft H. Tschofenig
Intended status: Standards Track Nokia Siemens Networks Intended status: Standards Track Nokia Siemens Networks
Expires: November 27, 2008 May 26, 2008 Expires: November 27, 2008 May 26, 2008
Quality of Service Parameters for Usage with the AAA Framework 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 Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. 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
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 RADIUS and
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 1.1. Traffic Model Parameter . . . . . . . . . . . . . . . . . 4
3. Parameter Overview . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Constraints Parameters . . . . . . . . . . . . . . . . . . 4
3.1. Traffic Model Parameter . . . . . . . . . . . . . . . . . 3 1.3. Traffic Handling Directives . . . . . . . . . . . . . . . 5
3.2. Constraints Parameters . . . . . . . . . . . . . . . . . . 3 1.4. Traffic Classes . . . . . . . . . . . . . . . . . . . . . 5
3.3. Traffic Handling Directives . . . . . . . . . . . . . . . 5 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 6
3.4. Traffic Classifiers . . . . . . . . . . . . . . . . . . . 5 3. AVP Definition . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Parameter Encoding . . . . . . . . . . . . . . . . . . . . . . 5 3.1. TMOD-1 AVP . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Parameter Header . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. TMOD-Rate-1 AVP . . . . . . . . . . . . . . . . . . . 6
4.2. TMOD-1 Parameter . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. TMOD-Size-1 AVP . . . . . . . . . . . . . . . . . . . 6
4.3. TMOD-2 Parameter . . . . . . . . . . . . . . . . . . . . . 6 3.1.3. Peak-Data-Rate-1 AVP . . . . . . . . . . . . . . . . . 6
4.4. Path Latency Parameter . . . . . . . . . . . . . . . . . . 7 3.1.4. Minimum-Policed-Unit-1 AVP . . . . . . . . . . . . . . 6
4.5. Path Jitter Parameter . . . . . . . . . . . . . . . . . . 7 3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 7
4.6. Path PLR Parameter . . . . . . . . . . . . . . . . . . . . 8 3.2.1. TMOD-Rate-2 AVP . . . . . . . . . . . . . . . . . . . 7
4.7. Path PER Parameter . . . . . . . . . . . . . . . . . . . . 8 3.2.2. TMOD-Size-2 AVP . . . . . . . . . . . . . . . . . . . 7
4.8. Slack Term Parameter . . . . . . . . . . . . . . . . . . . 9 3.2.3. Peak-Data-Rate-2 AVP . . . . . . . . . . . . . . . . . 7
4.9. Preemption Priority amp; Defending Priority Parameters . . 9 3.2.4. Minimum-Policed-Unit-2 AVP . . . . . . . . . . . . . . 7
4.10. Admission Priority Parameter . . . . . . . . . . . . . . . 10 3.3. Path-Latency AVP . . . . . . . . . . . . . . . . . . . . . 7
4.11. Application-Level Resource Priority (ALRP) Parameter . . . 10 3.4. Path-Jitter AVP . . . . . . . . . . . . . . . . . . . . . 8
4.12. Excess Treatment Parameter . . . . . . . . . . . . . . . . 11 3.4.1. Path-Jitter-STAT1 AVP . . . . . . . . . . . . . . . . 8
4.13. PHB Class Parameter . . . . . . . . . . . . . . . . . . . 12 3.4.2. Path-Jitter-STAT2 AVP . . . . . . . . . . . . . . . . 8
4.14. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 13 3.4.3. Path-Jitter-STAT3 AVP . . . . . . . . . . . . . . . . 8
4.15. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 13 3.4.4. Path-Jitter-STAT4 AVP . . . . . . . . . . . . . . . . 8
5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 15 3.5. Path-PLR AVP . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 3.6. Path-PER AVP . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. QoS Profile . . . . . . . . . . . . . . . . . . . . . . . 16 3.7. Slack-Term AVP . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Parameter ID . . . . . . . . . . . . . . . . . . . . . . . 16 3.8. Priority AVP . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Excess Treatment Parameter . . . . . . . . . . . . . . . . 17 3.8.1. Preemption-Priority AVP . . . . . . . . . . . . . . . 9
6.4. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 17 3.8.2. Defending-Priority AVP . . . . . . . . . . . . . . . . 9
6.5. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 18 3.9. Admission-Priority AVP . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 3.10. ALRP AVP . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 3.10.1. ALRP-Namespace AVP . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.10.2. ALRP-Priority AVP . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 3.11. Excess-Treatment AVP . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 20 3.11.1. Excess-Treatment-Value AVP . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 3.11.2. Remark-Value AVP . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 22 3.11.3. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . 12
3.11.4. DSTE-Class-Type AVP . . . . . . . . . . . . . . . . . 13
3.11.5. Y.1541-QoS-Class AVP . . . . . . . . . . . . . . . . . 13
4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 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 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 RADIUS and
Diameter. Diameter.
The payloads used to carry these QoS parameters are opaque for the The subsequent section give an overview of the parameters defined by
AAA client and the AAA server itself and interpreted by the this document.
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 1.1. Traffic Model Parameter
The Traffic Model (TMOD) parameter is a container consisting of four The Traffic Model (TMOD) parameter is a container consisting of four
sub-parameters: 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 TMOD parameter is a mathematically complete way to describe the
TMOD parameter is a mathematically complete way to describe the
traffic source. If, for example, TMOD is set to specify bandwidth traffic source. If, for example, TMOD is set to specify bandwidth
only, then set r = peak rate = p, b = large, m = large. As another 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 example if TMOD is set for TCP traffic, then set r = average rate, b
= large, p = large. = large, p = large.
3.2. Constraints Parameters 1.2. Constraints Parameters
<Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> are QoS <Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> are QoS
parameters describing the desired path latency, path jitter and path parameters describing the desired path latency, path jitter and path
bit error rate respectively. bit error rate respectively.
The <Path Latency> parameter refers to the accumulated latency of the The <Path Latency> parameter refers to the accumulated latency of the
packet forwarding process associated with each QoS aware node along packet forwarding process associated with each QoS aware node along
the path, where the latency is defined to be the mean packet delay the path, where the latency is defined to be the mean packet delay
added by each such node. This delay results from speed-of-light added by each such node. This delay results from speed-of-light
propagation delay, from packet processing limitations, or both. The propagation delay, from packet processing limitations, or both. The
skipping to change at page 4, line 4 skipping to change at page 4, line 41
<Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> are QoS <Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> are QoS
parameters describing the desired path latency, path jitter and path parameters describing the desired path latency, path jitter and path
bit error rate respectively. bit error rate respectively.
The <Path Latency> parameter refers to the accumulated latency of the The <Path Latency> parameter refers to the accumulated latency of the
packet forwarding process associated with each QoS aware node along packet forwarding process associated with each QoS aware node along
the path, where the latency is defined to be the mean packet delay the path, where the latency is defined to be the mean packet delay
added by each such node. This delay results from speed-of-light added by each such node. This delay results from speed-of-light
propagation delay, from packet processing limitations, or both. The propagation delay, from packet processing limitations, or both. The
mean delay reflects the variable queuing delay that may be present. mean delay reflects the variable queuing delay that may be present.
The purpose of this parameter is to provide a minimum path latency The purpose of this parameter is to provide a minimum path latency
for use with services which provide estimates or bounds on additional for use with services which provide estimates or bounds on additional
path delay [RFC2212]. 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 The <Path Jitter> parameter refers to the accumulated jitter of the
packet forwarding process associated with each QoS aware node along packet forwarding process associated with each QoS aware node along
the path, where the jitter is defined to be the nominal jitter added 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 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 in Section 3.4 of RFC 3393 [RFC3393], (Type-P-One-way-ipdv), and
where the selection function includes the packet with minimum delay where the selection function includes the packet with minimum delay
such that the distribution is equivalent to 2-point delay variation such that the distribution is equivalent to 2-point delay variation
in [Y.1540]. The suggested evaluation interval is 1 minute. This in [Y.1540]. The suggested evaluation interval is 1 minute. This
jitter results from packet processing limitations, and includes any jitter results from packet processing limitations, and includes any
variable queuing delay which may be present. The purpose of this variable queuing delay which may be present. The purpose of this
skipping to change at page 5, line 5 skipping to change at page 5, line 36
flow compared with the <Defending Priority> of previously admitted flow compared with the <Defending Priority> 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> parameter is used to compare
with the preemption priority of new flows. For any specific flow, with the preemption priority of new flows. For any specific flow,
its preemption priority MUST always be less than or equal to the its preemption priority MUST always be less than or equal to the
defending priority. <Admission Priority> and <RPH Priority> provide defending priority. <Admission Priority> and <RPH Priority> provide
an essential way to differentiate flows for emergency services, ETS, an essential way to differentiate flows for emergency services, ETS,
E911, etc., and assign them a higher admission priority than normal E911, etc., and assign them a higher admission priority than normal
priority flows and best-effort priority flows. priority flows and best-effort priority flows.
3.3. Traffic Handling Directives 1.3. Traffic Handling Directives
The <Excess Treatment> parameter describes how a QoS aware node will The <Excess Treatment< parameter describes how a QoS aware node will
process excess traffic, that is, out-of-profile traffic. Excess process excess traffic, that is, out-of-profile traffic. Excess
traffic MAY be dropped, shaped and/or remarked. traffic MAY be dropped, shaped and/or remarked.
3.4. Traffic Classifiers 1.4. Traffic Classes
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] or to a
particular QoS class, e.g., Y.1541 QoS class or DiffServ-aware MPLS particular QoS class, e.g., Y.1541 QoS class or DiffServ-aware MPLS
traffic engineering (DSTE) class type [RFC3564], [RFC4124]. traffic engineering (DSTE) class type [RFC3564], [RFC4124].
4. Parameter Encoding 2. Terminology and Abbreviations
4.1. Parameter Header 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].
Each QoS parameter is encoded in TLV format. 3. AVP Definition
0 1 2 3 3.1. TMOD-1 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| Parameter ID |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M Flag: When set indicates the subsequent parameter MUST be The TMOD-1 AVP is obtained from [RFC2210] and [RFC2215]. The
interpreted. If the M flag is set and the parameter is not structure of the AVP is as follows:
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. TMOD-1 ::= < AVP Header: TBD >
{ TMOD-Rate-1 }
{ TMOD-Size-1 }
{ Peak-Data-Rate-1 }
{ Minimum-Policed-Unit-1 }
Parameter ID: Assigned to each individual QoS parameter 3.1.1. TMOD-Rate-1 AVP
4.2. TMOD-1 Parameter The TMOD-Rate-1 AVP (AVP Code TBD) is of type Float32 and contains
the rate (r).
<TMOD-1> = <r> <b> <p> <m> [RFC2210] , [RFC2215] 3.1.2. TMOD-Size-1 AVP
The above notation means that the 4 <TMOD-1> sub-parameters must be The TMOD-Size-1 AVP (AVP Code TBD) is of type Float32 and contains
carried in the <TMOD-1> parameter. The coding for the <TMOD-1> the bucket size (b).
parameter is as follows:
0 1 2 3 3.1.3. Peak-Data-Rate-1 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| 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 The Peak-Data-Rate-1 AVP (AVP Code TBD) is of type Float32 and
in single-precision IEEE floating point format followed by one 32-bit contains the peak rate (p).
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, 3.1.4. Minimum-Policed-Unit-1 AVP
the sign bit MUST be zero (all values MUST be non-negative).
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 are represented as IEEE floating 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 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater
than 162 (i.e., positive 35) are discouraged, except for specifying a than 162 (i.e., positive 35) are discouraged, except for specifying a
peak rate of infinity. Infinity is represented with an exponent of peak rate of infinity. Infinity is represented with an exponent of
all ones (255) and a sign bit and mantissa of all zeroes. all ones (255) and a sign bit and mantissa of all zeroes.
4.3. TMOD-2 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
[RFC2215]. The <TMOD-2> parameter may be needed in a DiffServ [RFC2215]. The TMOD-2 AVP is useful in a DiffServ environment. The
environment. The coding for the <TMOD-2> parameter is as follows: coding for the TMOD-2 AVP is as follows:
0 1 2 3 TMOD-2 ::= < 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-2 }
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ { TMOD-Size-2 }
|M|r|r|r| 2 |r|r|r|r| 4 | { Peak-Data-Rate-2 }
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ { Minimum-Policed-Unit-2 }
| TMOD Rate-2 [r] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.1. TMOD-Rate-2 AVP
| TMOD Size-2 [b] (32-bit IEEE floating point number) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The TMOD-Rate-2 AVP (AVP Code TBD) is of type Float32 and contains
| Peak Data Rate-2 [p] (32-bit IEEE floating point number) | the rate (r).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Policed Unit-2 [m] (32-bit unsigned integer) | 3.2.2. TMOD-Size-2 AVP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When r, b, and p terms are represented as IEEE floating point values, The TMOD-Size-2 AVP (AVP Code TBD) is of type Float32 and contains
the sign bit MUST be zero (all values MUST be non-negative). the bucket size (b).
3.2.3. Peak-Data-Rate-2 AVP
The Peak-Data-Rate-2 AVP (AVP Code TBD) is of type Float32 and
contains the peak rate (p).
3.2.4. Minimum-Policed-Unit-2 AVP
The Minimum-Policed-Unit-2 AVP (AVP Code TBD) is of type Unsigned32
and contains the minimum policed unit (m).
The values r, b, and p are represented as IEEE floating 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 Exponents less than 127 (i.e., 0) are prohibited. Exponents greater
than 162 (i.e., positive 35) are discouraged, except for specifying a than 162 (i.e., positive 35) are discouraged, except for specifying a
peak rate of infinity. Infinity is represented with an exponent of peak rate of infinity. Infinity is represented with an exponent of
all ones (255) and a sign bit and mantissa of all zeroes. all ones (255) and a sign bit and mantissa of all zeroes.
4.4. Path Latency Parameter 3.3. Path-Latency 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 The semantic of the parameter values can be found in [RFC2210] and
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 [RFC2215]. The Path-Latency AVP (AVP Code TBD) is of type Integer32.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 is summation with a clamp
The composition rule for the <Path Latency> parameter is summation of (2**32 - 1) on the maximum value. The latencies are average
with a clamp of (2**32 - 1) on the maximum value. The latencies are values reported in units of one microsecond. A system with
average values reported in units of one microsecond. A system with
resolution less than one microsecond MUST set unused digits to zero. resolution less than one microsecond MUST set unused digits to zero.
The total latency added across all QoS aware nodes along the path can The total latency added across all QoS aware nodes along the path can
range as high as (2**32)-2. range as high as (2**32)-2.
4.5. Path Jitter Parameter 3.4. Path-Jitter AVP
The coding for the <Path Jitter> parameter is as follows: The coding for the Path-Jitter AVP is as follows:
0 1 2 3 Path-Jitter ::= < 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 { Path-Jitter-STAT1 }
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ { Path-Jitter-STAT2 }
|M|r|r|r| 4 |r|r|r|r| 4 | { Path-Jitter-STAT3 }
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ { Path-Jitter-STAT4 }
| 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 3.4.1. Path-Jitter-STAT1 AVP
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 The Path-Jitter-STAT1 AVP (AVP Code TBD) is of type Integer32 and
contains the variance.
The coding for the <Path PLR> parameter is as follows: 3.4.2. Path-Jitter-STAT2 AVP
0 1 2 3 The Path-Jitter-STAT2 AVP (AVP Code TBD) is of type Integer32 and
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 contains the 99.9%-ile.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 3.4.3. Path-Jitter-STAT3 AVP
number in network byte order. The PLRs are reported in units of
10^-11. A system with resolution less than one microsecond MUST set
unused digits to zero. The total PLR added across all QoS aware
nodes can range as high as 10^-1.
4.7. Path PER Parameter The Path-Jitter-STAT3 AVP (AVP Code TBD) is of type Integer32 and
contains the minimum latency.
The coding for the <Path PLR> parameter is as follows: 3.4.4. Path-Jitter-STAT4 AVP
0 1 2 3 The Path-Jitter-STAT4 AVP (AVP Code TBD) is of type Integer32 and is
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 reserved for future use.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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 Path-Jitter AVP is the combination of four statistics describing
number in network byte order. The PERs are reported in units of the jitter distribution with a clamp of (2**32 - 1) on the maximum of
10^-11. A system with resolution less than one microsecond MUST set each value. The jitter STATs are reported in units of one
unused digits to zero. The total PER added across all QoS aware microsecond.
nodes can range as high as 10^-1.
4.8. Slack Term Parameter 3.5. Path-PLR AVP
A description of the semantic of the parameter values can be found in The Path-PLR AVP (AVP Code TBD) is of type Float32 and contains the
[RFC2212], [RFC2215]. The coding for the <Path PLR> parameter is as path packet loss ratio. The PLRs are reported in units of 10^-11. A
follows: system with resolution less than one microsecond MUST set unused
digits to zero. The total PLR added across all QoS aware nodes can
range as high as 10^-1.
0 1 2 3 3.6. Path-PER 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| 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 The Path-PER AVP (AVP Code TBD) is of type Float32 and contains the
order and is measured in microseconds. S is represented as a 32-bit path packet error ratio. The PERs are reported in units of 10^-11.
integer. Its value can range from 0 to (2**32)-1 microseconds. 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.
4.9. Preemption Priority amp; Defending Priority Parameters 3.7. Slack-Term AVP
A description of the semantic of the parameter values can be found in The Slack-Term AVP (AVP Code TBD) is of type Integer32 and its
[RFC3181]. semantic can be found in [RFC2212] and [RFC2215]. The Slack-Term AVP
contains values measured in microseconds and its value can range from
0 to (2**32)-1 microseconds.
The coding for the <Preemption Priority> & <Defending Priority> sub- 3.8. 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.8.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.8.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.9. 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 6.2.9 of [I-D.ietf-nsis-qspec], or in
or in the Admission Priority parameter defined in Section 3.1 of the Admission Priority parameter defined in Section 3.1 of
[I-D.ietf-tsvwg-emergency-rsvp]. In other words, a given value [I-D.ietf-tsvwg-emergency-rsvp]. In other words, a given value
inside the Admission Priority information element defined in the inside the Admission-Priority AVP, inside the [I-D.ietf-nsis-qspec]
present document, inside the [I-D.ietf-nsis-qspec] Admission Priority admission priority parameter or inside the
parameter or inside the [I-D.ietf-tsvwg-emergency-rsvp] Admission [I-D.ietf-tsvwg-emergency-rsvp] admission priority parameter, refers
Priority parameter, refers to the same Admission Priority. to the same admission priority.
4.11. Application-Level Resource Priority (ALRP) Parameter 3.10. 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 | ALRP Priority | (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ALRP Namespace field is a 16 bits long unsigned integer in 3.10.1. ALRP-Namespace AVP
network byte order and the ALRP Priority field is an 8 bit long
unsigned integer in network byte order containing the specific The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32.
priority value.
3.10.2. ALRP-Priority AVP
The Path-Jitter-STAT4 AVP (AVP Code TBD) is of type Unsigned32.
[RFC4412] defines a resource priority header and established the [RFC4412] defines a resource priority header and established the
initial registry; that registry was later extended by initial registry; that registry was later extended by
[I-D.ietf-tsvwg-emergency-rsvp]. [I-D.ietf-tsvwg-emergency-rsvp].
4.12. Excess Treatment Parameter 3.11. Excess-Treatment AVP
The coding for the <Excess Treatment> parameter is as follows: The Excess-Treatment AVP is a grouped AVP consisting of two AVPs, the
Treatment and the Remark-Value AVP.
0 1 2 3 The coding for the Excess-Treatment AVP is as follows:
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 Excess-Treatment ::= < AVP Header: TBD >
order): Indicates how the QoS aware node should process out-of- { Excess-Treatment-Value }
profile traffic, that is, traffic not covered by the <Traffic> [ Remark-Value ]
parameter. Allowed values are as follows:
3.11.1. Excess-Treatment-Value AVP
The Excess-Treatment-Value AVP (AVP Code TBD) is of type Enumerated
and indicates how a QoS aware node should process out-of-profile
traffic. The following values are currently defined:
0: drop 0: drop
1: shape 1: shape
2: remark 2: remark
3: no metering or policing is permitted 3: no metering or policing is permitted
The default excess treatment in case that none is specified is that The default treatment in case that none is specified is that there
there are no guarantees to excess traffic, i.e., a QoS aware node can are no guarantees to excess traffic, i.e., a QoS aware node can do
do what it finds suitable. what it finds suitable.
When excess treatment is set to 'drop', all marked traffic MUST be When the treatment is set to 'drop', all marked traffic MUST be
dropped by a QoS aware node. dropped by a QoS aware node.
When excess treatment is set to 'shape', it is expected that the QoS When the treatment is set to 'shape', it is expected that QoS
Desired object carries a TMOD parameter. Excess traffic is to be parameters conveyed as part of QoS-Desired are used to reshape the
shaped to this TMOD. When the shaping causes unbounded queue growth traffic (for example a TMOD parameter indicated as QoS desired).
at the shaper traffic can be dropped. When the shaping causes unbounded queue growth at the shaper traffic
can be dropped.
When excess treatment is set to 'remark', the excess treatment When the treatment is set to 'remark', the excess treatment parameter
parameter MUST carry the remark value. For example, packets may be MUST carry the remark value. For example, packets may be remarked to
remarked to drop remarked to pertain to a particular QoS class. In drop remarked to pertain to a particular QoS class. In the latter
the latter case, remarking relates to a DiffServ-type model, where case, remarking relates to a DiffServ-type model, where packets
packets arrive marked as belonging to a certain QoS class, and when arrive marked as belonging to a certain QoS class, and when they are
they are identified as excess, they should then be remarked to a identified as excess, they should then be remarked to a different QoS
different QoS Class. Class. The Remark-Value AVP carries the information used for re-
marking.
If 'no metering or policing is permitted' is signaled, the QoS aware If 'no metering or policing is permitted' is indicated, the QoS aware
node should accept the excess treatment parameter set by the sender node should accept the treatment set by the sender with special care
with special care so that excess traffic should not cause a problem. so that excess traffic should not cause a problem. To request the
To request the Null Meter [RFC3290] is especially strong, and should Null Meter [RFC3290] is especially strong, and should be used with
be used with caution. caution.
The Remark Value is an 8 bit unsigned integer value in network byte 3.11.2. Remark-Value AVP
order.
4.13. PHB Class Parameter The Remark-Value AVP (AVP Code TBD) is of type Unsigned32 and
contains the DSCP value the excess traffic should be remarked to.
A description of the semantic of the parameter values can be found in 3.11.3. PHB-Class AVP
[RFC3140]. The coding for the <PHB Class> parameter is as follows:
The PHB-Class AVP (AVP Code TBD) is of type OctetString and is two
octets long. A description of the semantic of the parameter values
can be found in [RFC3140]. The coding for the values is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|r|r|r| 12 |r|r|r|r| 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) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
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.
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
skipping to change at page 13, line 26 skipping to change at page 13, line 13
Scheduling Class (i.e., use of PHBs from the set MUST NOT cause Scheduling Class (i.e., use of PHBs from the set MUST NOT cause
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.
The registries needed to use [RFC3140] already exist. Hence, no new The registries needed to use [RFC3140] already exist. Hence, no new
registry needs to be created for this purpose. registry needs to be created for this purpose.
4.14. DSTE Class Type Parameter 3.11.4. DSTE-Class-Type AVP
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 The DSTE-Class-Type AVP (AVP Code TBD) is of type Unsigned32. A
allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means description of the semantic of the parameter values can be found in
that the <DSTE Class Type> parameter is not used. [RFC4124].
4.15. Y.1541 QoS Class Parameter Currently, the values of alues currently allowed are 0, 1, 2, 3, 4,
5, 6, 7.
A description of the semantic of the parameter values can be found in 3.11.5. Y.1541-QoS-Class AVP
[Y.1541]. The coding for the <Y.1541 QoS Class> parameter is as
follows:
0 1 2 3 The Y.1541-QoS-Class 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [Y.1541].
|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 allowed values of the Y.1541 QoS class are 0, 1, 2, 3,
allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means 4, 5, 6, 7.
that the <Y.1541 QoS Class> parameter is not used.
Class 0: Class 0:
Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <=
10^-3. Real-time, highly interactive applications, sensitive to 10^-3. Real-time, highly interactive applications, sensitive to
jitter. Application examples include VoIP, Video Teleconference. jitter. Application examples include VoIP, Video Teleconference.
Class 1: Class 1:
Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <=
skipping to change at page 15, line 19 skipping to change at page 14, line 37
television transport, high-capacity TCP transfers, and TDM circuit television transport, high-capacity TCP transfers, and TDM circuit
emulation. emulation.
Class 7: Class 7:
Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <=
10^-5. Applications that are highly sensitive to loss, such as 10^-5. Applications that are highly sensitive to loss, such as
television transport, high-capacity TCP transfers, and TDM circuit television transport, high-capacity TCP transfers, and TDM circuit
emulation. emulation.
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 QoS 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
entirely different set of parameters. entirely different set of parameters.
To enable the definition of new QoS profiles a 8 octet registry is 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 defined field that is represented by a 4-octet vendor and 4-octet
specifier field. The vendor field indicates the type as either specifier field. A QoS profile groups together a bunch of QoS
standards-specified or vendor-specific. If the four octets of the parameters for usage in a specific environment. The vendor field
vendor field are 0x00000000, then the value is standards-specified indicates the type as either standards-specified or vendor-specific.
and the registry is maintained by IANA, and any other value If the four octets of the vendor field are 0x00000000, then the value
represents a vendor-specific Object Identifier (OID). IANA created is standards-specified and the registry is maintained by IANA, and
registry is split into two value ranges; one range uses the any other value represents a vendor-specific Object Identifier (OID).
"Standards Action" and the second range uses "Specification Required" IANA created registry is split into two value ranges; one range uses
allocation policy. The latter range is meant to be used by 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. organizations outside the IETF.
6. IANA Considerations 5. IANA Considerations
This section defines the registries and initial codepoint This section defines the registries and initial codepoint
assignments, in accordance with BCP 26 RFC 2434 [RFC2434]. It also assignments, in accordance with BCP 26 RFC 2434 [RFC5226]. It also
defines the procedural requirements to be followed by IANA in defines the procedural requirements to be followed by IANA in
allocating new codepoints. allocating new codepoints.
IANA is requested to create the following registries listed in the IANA is requested to create the following registries listed in the
subsections below. subsections below.
6.1. QoS Profile 5.1. QoS Profile
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
skipping to change at page 16, line 36 skipping to change at page 16, line 6
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 1 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 5.2. AVP Allocations
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 This specification assigns the values TBD1 to TBD2 from the AVP Code
namespace defined in [RFC3588]. See Section 3 for the assignment of
the namespace in this specification.
The Excess Treatment parameter refers to an 8 bit long field. 5.3. Excess-Treatment AVP
The following values are allocated by this specification: The following values are allocated by this specification:
Excess Treatment Value 0: drop Excess Treatment Value 0: drop
Excess Treatment Value 1: shape Excess Treatment Value 1: shape
Excess Treatment Value 2: remark Excess Treatment Value 2: remark
Excess Treatment Value3: no metering or policing is permitted Excess Treatment Value3: no metering or policing is permitted
Excess Treatment Values 4-63: Standards Action Excess Treatment Values 4-63: Standards Action
Excess Treatment Value 64-255: Reserved Excess Treatment Value 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: The following values are allocated by this specification:
DSTE Class Type Value 0: DSTE Class Type 0 DSTE Class Type Value 0: DSTE Class Type 0
DSTE Class Type Value 1: DSTE Class Type 1 DSTE Class Type Value 1: DSTE Class Type 1
DSTE Class Type Value 2: DSTE Class Type 2 DSTE Class Type Value 2: DSTE Class Type 2
DSTE Class Type Value 3: DSTE Class Type 3 DSTE Class Type Value 3: DSTE Class Type 3
DSTE Class Type Value 4: DSTE Class Type 4 DSTE Class Type Value 4: DSTE Class Type 4
DSTE Class Type Value 5: DSTE Class Type 5 DSTE Class Type Value 5: DSTE Class Type 5
DSTE Class Type Value 6: DSTE Class Type 6 DSTE Class Type Value 6: DSTE Class Type 6
DSTE Class Type Value 7: DSTE Class Type 7 DSTE Class Type Value 7: DSTE Class Type 7
DSTE Class Type Values 8-63: Standards Action DSTE Class Type Values 8-63: Standards Action
DSTE Class Type Values 64-255: Reserved DSTE Class Type Values 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: The following values are allocated by this specification:
Y.1541 QoS Class Value 0: Y.1541 QoS Class 0 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 1: Y.1541 QoS Class 1
Y.1541 QoS Class Value 2: Y.1541 QoS Class 2 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 3: Y.1541 QoS Class 3
Y.1541 QoS Class Value 4: Y.1541 QoS Class 4 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 5: Y.1541 QoS Class 5
Y.1541 QoS Class Value 6: Y.1541 QoS Class 6 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 Value 7: Y.1541 QoS Class 7
Y.1541 QoS Class Values 8-63: Standards Action Y.1541 QoS Class Values 8-63: Standards Action
Y.1541 QoS Class Values 64-255: Reserved Y.1541 QoS Class Values 64-2^32-1: Reserved
The ALRP Namespace and ALRP Priority field inside the ALRP Parameter The values in the ALRP-Namespace and ALRP-Priority AV{ inside the
take their values from the registry created by [RFC4412] and extended ALRP AVP take their values from the registry created by [RFC4412] and
with [I-D.ietf-tsvwg-emergency-rsvp] No additional actions are extended with [I-D.ietf-tsvwg-emergency-rsvp] No additional actions
required by IANA by this specification. are required by IANA by this specification.
7. Security Considerations 6. 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.
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.
We would like to thank Francois Le Faucheur, John Loughney, Martin We would like to thank Francois Le Faucheur, John Loughney, Martin
Stiemerling, Dave Oran, An Nguyen, Ken Carlberg, James Polk, Lars Stiemerling, Dave Oran, An Nguyen, Ken Carlberg, James Polk, Lars
Eggert, and Magnus Westerlund for their help with resolving problems Eggert, and Magnus Westerlund for their help with resolving problems
regarding the Admission Priority and the ALRP parameter. regarding the Admission Priority and the ALRP parameter.
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-08 (work in Services", draft-ietf-tsvwg-emergency-rsvp-08 (work in
progress), May 2008. progress), May 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.
skipping to change at page 19, line 36 skipping to change at page 18, line 10
[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.
[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, [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.
[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 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393, Metric for IP Performance Metrics (IPPM)", RFC 3393,
November 2002. November 2002.
[RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Differentiated Services-aware MPLS Traffic Engineering", Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
RFC 3564, July 2003.
[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] "Network Performance Objectives for IP-Based Services", , [Y.1541] "Network Performance Objectives for IP-Based Services", ,
2006. 2006.
[Y.1571] "Admission Control Priority Levels in Next Generation [Y.1571] "Admission Control Priority Levels in Next Generation
Networks", , July 2006. Networks", , July 2006.
9.2. Informative References 8.2. Informative References
[I-D.ietf-nsis-qspec] [I-D.ietf-nsis-qspec]
Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP
QSPEC Template", draft-ietf-nsis-qspec-20 (work in QSPEC Template", draft-ietf-nsis-qspec-20 (work in
progress), April 2008. progress), April 2008.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
IANA Considerations Section in RFCs", BCP 26, RFC 2434, and W. Weiss, "An Architecture for Differentiated
October 1998. 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 5226,
May 2008.
[Y.1540] "Internet Protocol Data Communication Service - IP Packet [Y.1540] "Internet Protocol Data Communication Service - IP Packet
Transfer and Availability Performance Parameters", , Transfer and Availability Performance Parameters", ,
December 2002. December 2002.
Authors' Addresses Authors' Addresses
Jouni Korhonen (editor) Jouni Korhonen (editor)
TeliaSonera TeliaSonera
Teollisuuskatu 13 Teollisuuskatu 13
skipping to change at page 21, line 22 skipping to change at page 19, line 36
Email: jouni.korhonen@teliasonera.com Email: jouni.korhonen@teliasonera.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@nsn.com Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
 End of changes. 106 change blocks. 
399 lines changed or deleted 315 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/