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