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/ |