--- 1/draft-ietf-dime-qos-parameters-05.txt 2008-05-26 22:12:17.000000000 +0200 +++ 2/draft-ietf-dime-qos-parameters-06.txt 2008-05-26 22:12:17.000000000 +0200 @@ -1,19 +1,19 @@ Diameter Maintenance and J. Korhonen, Ed. Extensions (DIME) TeliaSonera Internet-Draft H. Tschofenig Intended status: Standards Track Nokia Siemens Networks Expires: November 27, 2008 May 26, 2008 Quality of Service Parameters for Usage with the AAA Framework - draft-ietf-dime-qos-parameters-05.txt + draft-ietf-dime-qos-parameters-06.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -38,99 +38,93 @@ This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Traffic Model Parameter . . . . . . . . . . . . . . . . . 4 - 1.2. Constraints Parameters . . . . . . . . . . . . . . . . . . 4 - 1.3. Traffic Handling Directives . . . . . . . . . . . . . . . 5 - 1.4. Traffic Classes . . . . . . . . . . . . . . . . . . . . . 5 - 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 6 - 3. AVP Definition . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1. TMOD-1 AVP . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3.1.1. TMOD-Rate-1 AVP . . . . . . . . . . . . . . . . . . . 6 - 3.1.2. TMOD-Size-1 AVP . . . . . . . . . . . . . . . . . . . 6 - 3.1.3. Peak-Data-Rate-1 AVP . . . . . . . . . . . . . . . . . 6 - 3.1.4. Minimum-Policed-Unit-1 AVP . . . . . . . . . . . . . . 6 - 3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.2.1. TMOD-Rate-2 AVP . . . . . . . . . . . . . . . . . . . 7 - 3.2.2. TMOD-Size-2 AVP . . . . . . . . . . . . . . . . . . . 7 - 3.2.3. Peak-Data-Rate-2 AVP . . . . . . . . . . . . . . . . . 7 - 3.2.4. Minimum-Policed-Unit-2 AVP . . . . . . . . . . . . . . 7 - 3.3. Path-Latency AVP . . . . . . . . . . . . . . . . . . . . . 7 - 3.4. Path-Jitter AVP . . . . . . . . . . . . . . . . . . . . . 8 - 3.4.1. Path-Jitter-STAT1 AVP . . . . . . . . . . . . . . . . 8 - 3.4.2. Path-Jitter-STAT2 AVP . . . . . . . . . . . . . . . . 8 - 3.4.3. Path-Jitter-STAT3 AVP . . . . . . . . . . . . . . . . 8 - 3.4.4. Path-Jitter-STAT4 AVP . . . . . . . . . . . . . . . . 8 - 3.5. Path-PLR AVP . . . . . . . . . . . . . . . . . . . . . . . 8 - 3.6. Path-PER AVP . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.7. Slack-Term AVP . . . . . . . . . . . . . . . . . . . . . . 9 - 3.8. Priority AVP . . . . . . . . . . . . . . . . . . . . . . . 9 - 3.8.1. Preemption-Priority AVP . . . . . . . . . . . . . . . 9 - 3.8.2. Defending-Priority AVP . . . . . . . . . . . . . . . . 9 - 3.9. Admission-Priority AVP . . . . . . . . . . . . . . . . . . 9 - 3.10. ALRP AVP . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 3.10.1. ALRP-Namespace AVP . . . . . . . . . . . . . . . . . . 10 - 3.10.2. ALRP-Priority AVP . . . . . . . . . . . . . . . . . . 10 - 3.11. Excess-Treatment AVP . . . . . . . . . . . . . . . . . . . 10 - 3.11.1. Excess-Treatment-Value AVP . . . . . . . . . . . . . . 11 - 3.11.2. Remark-Value AVP . . . . . . . . . . . . . . . . . . . 11 - 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 + 3. Parameter Overview . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1. Traffic Model Parameter . . . . . . . . . . . . . . . . . 3 + 3.2. Constraints Parameters . . . . . . . . . . . . . . . . . . 3 + 3.3. Traffic Handling Directives . . . . . . . . . . . . . . . 5 + 3.4. Traffic Classifiers . . . . . . . . . . . . . . . . . . . 5 + 4. Parameter Encoding . . . . . . . . . . . . . . . . . . . . . . 5 + 4.1. Parameter Header . . . . . . . . . . . . . . . . . . . . . 5 + 4.2. TMOD-1 Parameter . . . . . . . . . . . . . . . . . . . . . 5 + 4.3. TMOD-2 Parameter . . . . . . . . . . . . . . . . . . . . . 6 + 4.4. Path Latency Parameter . . . . . . . . . . . . . . . . . . 7 + 4.5. Path Jitter Parameter . . . . . . . . . . . . . . . . . . 7 + 4.6. Path PLR Parameter . . . . . . . . . . . . . . . . . . . . 8 + 4.7. Path PER Parameter . . . . . . . . . . . . . . . . . . . . 8 + 4.8. Slack Term Parameter . . . . . . . . . . . . . . . . . . . 9 + 4.9. Preemption Priority amp; Defending Priority Parameters . . 9 + 4.10. Admission Priority Parameter . . . . . . . . . . . . . . . 10 + 4.11. Application-Level Resource Priority (ALRP) Parameter . . . 10 + 4.12. Excess Treatment Parameter . . . . . . . . . . . . . . . . 11 + 4.13. PHB Class Parameter . . . . . . . . . . . . . . . . . . . 12 + 4.14. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 13 + 4.15. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 13 + 5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 15 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 6.1. QoS Profile . . . . . . . . . . . . . . . . . . . . . . . 16 + 6.2. Parameter ID . . . . . . . . . . . . . . . . . . . . . . . 16 + 6.3. Excess Treatment Parameter . . . . . . . . . . . . . . . . 17 + 6.4. DSTE Class Type Parameter . . . . . . . . . . . . . . . . 17 + 6.5. Y.1541 QoS Class Parameter . . . . . . . . . . . . . . . . 18 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 + Intellectual Property and Copyright Statements . . . . . . . . . . 22 1. Introduction This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. - The subsequent section give an overview of the parameters defined by - this document. + 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. -1.1. Traffic Model Parameter +2. Terminology and Abbreviations + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC2119 [RFC2119]. + +3. Parameter Overview + +3.1. Traffic Model Parameter The Traffic Model (TMOD) parameter is a container consisting of four sub-parameters: o rate (r) o bucket size (b) o peak rate (p) o minimum policed unit (m) - The TMOD parameter is a mathematically complete way to describe the + All four sub-parameters MUST be included in the TMOD parameter. The + TMOD parameter is a mathematically complete way to describe the traffic source. If, for example, TMOD is set to specify bandwidth only, then set r = peak rate = p, b = large, m = large. As another example if TMOD is set for TCP traffic, then set r = average rate, b = large, p = large. -1.2. Constraints Parameters +3.2. Constraints Parameters , , , and are QoS parameters describing the desired path latency, path jitter and path bit error rate respectively. The parameter refers to the accumulated latency of the packet forwarding process associated with each QoS aware node along 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 propagation delay, from packet processing limitations, or both. The @@ -128,24 +122,28 @@ , , , and are QoS parameters describing the desired path latency, path jitter and path bit error rate respectively. The parameter refers to the accumulated latency of the packet forwarding process associated with each QoS aware node along 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 propagation delay, from packet processing limitations, or both. The mean delay reflects the variable queuing delay that may be present. + 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 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 @@ -172,319 +170,357 @@ flow compared with the of previously admitted flows. Once a flow is admitted, the preemption priority becomes irrelevant. The parameter is used to compare with the preemption priority of new flows. For any specific flow, its preemption priority MUST always be less than or equal to the defending priority. and 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. -1.3. Traffic Handling Directives +3.3. Traffic Handling Directives - The parameter describes how a QoS aware node will process excess traffic, that is, out-of-profile traffic. Excess traffic MAY be dropped, shaped and/or remarked. -1.4. Traffic Classes +3.4. Traffic Classifiers Resource reservations might refer to a packet processing with a particular DiffServ per-hop behavior (PHB) [RFC2475] or to a particular QoS class, e.g., Y.1541 QoS class or DiffServ-aware MPLS traffic engineering (DSTE) class type [RFC3564], [RFC4124]. -2. Terminology and Abbreviations - - The 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. AVP Definition +4. Parameter Encoding -3.1. TMOD-1 AVP +4.1. Parameter Header - The TMOD-1 AVP is obtained from [RFC2210] and [RFC2215]. The - structure of the AVP is as follows: + Each QoS parameter is encoded in TLV format. - TMOD-1 ::= < AVP Header: TBD > - { TMOD-Rate-1 } - { TMOD-Size-1 } - { Peak-Data-Rate-1 } - { Minimum-Policed-Unit-1 } + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -3.1.1. TMOD-Rate-1 AVP + 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 TMOD-Rate-1 AVP (AVP Code TBD) is of type Float32 and contains - the rate (r). + The r bits are reserved. -3.1.2. TMOD-Size-1 AVP + Parameter ID: Assigned to each individual QoS parameter - The TMOD-Size-1 AVP (AVP Code TBD) is of type Float32 and contains - the bucket size (b). +4.2. TMOD-1 Parameter -3.1.3. Peak-Data-Rate-1 AVP + =

[RFC2210] , [RFC2215] - The Peak-Data-Rate-1 AVP (AVP Code TBD) is of type Float32 and - contains the peak rate (p). + The above notation means that the 4 sub-parameters must be + carried in the parameter. The coding for the + parameter is as follows: -3.1.4. Minimum-Policed-Unit-1 AVP + 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 Minimum-Policed-Unit-1 AVP (AVP Code TBD) is of type Unsigned32 - and contains the minimum policed unit (m). + The 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). - 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). + 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. -3.2. TMOD-2 AVP +4.3. TMOD-2 Parameter A description of the semantic of the parameter values can be found in - [RFC2215]. The TMOD-2 AVP is useful in a DiffServ environment. The - coding for the TMOD-2 AVP is as follows: - - TMOD-2 ::= < AVP Header: TBD > - { TMOD-Rate-2 } - { TMOD-Size-2 } - { Peak-Data-Rate-2 } - { Minimum-Policed-Unit-2 } - -3.2.1. TMOD-Rate-2 AVP - - The TMOD-Rate-2 AVP (AVP Code TBD) is of type Float32 and contains - the rate (r). - -3.2.2. TMOD-Size-2 AVP - - The TMOD-Size-2 AVP (AVP Code TBD) is of type Float32 and contains - 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). + [RFC2215]. The parameter may be needed in a DiffServ + environment. The coding for the parameter is as follows: - 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). + 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. -3.3. Path-Latency AVP +4.4. Path Latency Parameter - The semantic of the parameter values can be found in [RFC2210] and - [RFC2215]. The Path-Latency AVP (AVP Code TBD) is of type Integer32. + A description of the semantic of the parameter values can be found in + [RFC2210],[RFC2215]. The coding for the parameter is + as follows: - The composition rule for the path latency 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 + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |M|r|r|r| 3 |r|r|r|r| 1 | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + | Path Latency (32-bit integer) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Path Latency is a single 32-bit integer in network byte order. + The composition rule for the parameter is summation + with a clamp of (2**32 - 1) on the maximum value. The latencies are + average values reported in units of one microsecond. A system with resolution less than one microsecond MUST set unused digits to zero. The total latency added across all QoS aware nodes along the path can range as high as (2**32)-2. -3.4. Path-Jitter AVP +4.5. Path Jitter Parameter - The coding for the Path-Jitter AVP is as follows: + The coding for the parameter is as follows: - Path-Jitter ::= < AVP Header: TBD > - { Path-Jitter-STAT1 } - { Path-Jitter-STAT2 } - { Path-Jitter-STAT3 } - { Path-Jitter-STAT4 } + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |M|r|r|r| 4 |r|r|r|r| 4 | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + | Path Jitter STAT1(variance) (32-bit integer) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Path Jitter STAT2(99.9%-ile) (32-bit integer) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Path Jitter STAT3(minimum Latency) (32-bit integer) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Path Jitter STAT4(Reserved) (32-bit integer) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -3.4.1. Path-Jitter-STAT1 AVP + 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. - The Path-Jitter-STAT1 AVP (AVP Code TBD) is of type Integer32 and - contains the variance. +4.6. Path PLR Parameter -3.4.2. Path-Jitter-STAT2 AVP + The coding for the parameter is as follows: - The Path-Jitter-STAT2 AVP (AVP Code TBD) is of type Integer32 and - contains the 99.9%-ile. + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |M|r|r|r| 5 |r|r|r|r| 1 | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + | Path Packet Loss Ratio (32-bit floating point) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -3.4.3. Path-Jitter-STAT3 AVP + The Path PLR is a single 32-bit single precision IEEE floating point + 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. - The Path-Jitter-STAT3 AVP (AVP Code TBD) is of type Integer32 and - contains the minimum latency. +4.7. Path PER Parameter -3.4.4. Path-Jitter-STAT4 AVP + The coding for the parameter is as follows: - The Path-Jitter-STAT4 AVP (AVP Code TBD) is of type Integer32 and is - reserved for future use. + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |M|r|r|r| 6 |r|r|r|r| 1 | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + | Path Packet Error Ratio (32-bit floating point) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - The Path-Jitter AVP 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. + The Path PER is a single 32-bit single precision IEEE floating point + number in network byte order. The PERs are reported in units of + 10^-11. A system with resolution less than one microsecond MUST set + unused digits to zero. The total PER added across all QoS aware + nodes can range as high as 10^-1. -3.5. Path-PLR AVP +4.8. Slack Term Parameter - The Path-PLR AVP (AVP Code TBD) is of type Float32 and contains the - path packet loss ratio. 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. + A description of the semantic of the parameter values can be found in + [RFC2212], [RFC2215]. The coding for the parameter is as + follows: -3.6. Path-PER AVP + 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 Path-PER AVP (AVP Code TBD) is of type Float32 and contains the - path packet error ratio. The PERs are reported in units of 10^-11. - A system with resolution less than one microsecond MUST set unused - digits to zero. The total PER added across all QoS aware nodes can - range as high as 10^-1. + 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. Its value can range from 0 to (2**32)-1 microseconds. -3.7. Slack-Term AVP +4.9. Preemption Priority amp; Defending Priority Parameters - The Slack-Term AVP (AVP Code TBD) is of type Integer32 and its - 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. + A description of the semantic of the parameter values can be found in + [RFC3181]. -3.8. Priority AVP + The coding for the & sub- + parameters is as follows: - The Priority AVP is a grouped AVP consisting of two AVPs, the - Preemption-Priority and the Defending-Priority AVP. A description of - the semantic can be found in [RFC3181]. + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |M|r|r|r| 8 |r|r|r|r| 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Preemption Priority | Defending Priority | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Priority ::= < AVP Header: TBD > - { Preemption-Priority } - { Defending-Priority } + Preemption Priority: The priority of the new flow compared with the + defending priority of previously admitted flows. Higher values + represent higher priority. -3.8.1. Preemption-Priority AVP + Defending Priority: 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. - The Preemption-Priority AVP (AVP Code TBD) is of type Unsigned32 and - it indicates the priority of the new flow compared with the defending - priority of previously admitted flows. Higher values represent - higher priority. + As specified in [RFC3181], & are 16-bit integer values. They are represented in network + byte order. -3.8.2. Defending-Priority AVP +4.10. Admission Priority Parameter - 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. + The coding for the parameter is as follows: -3.9. Admission-Priority AVP + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |M|r|r|r| 9 |r|r|r|r| 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Admis.Priority| (Reserved) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - The Admission-Priority AVP (AVP Code TBD) is of type Unsigned32. + The 'Admis.Priority' field is a 8 bit unsigned integer in network + byte order. The admission control priority of the flow, in terms of access to network bandwidth in order to provide higher probability of call completion to selected flows. Higher values represent higher - priority. A given admission priority is encoded in this information - element using the same value as when encoded in the Admission- - Priority AVP defined in Section 6.2.9 of [I-D.ietf-nsis-qspec], or in - the Admission Priority parameter defined in Section 3.1 of + priority. A given Admission Priority is encoded in this information + 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], + or in the Admission Priority parameter defined in Section 3.1 of [I-D.ietf-tsvwg-emergency-rsvp]. In other words, a given value - inside the Admission-Priority AVP, 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. - -3.10. ALRP AVP + 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. - The Application-Level Resource Priority (ALRP) AVP is a grouped AVP - consisting of two AVPs, the ALRP-Namespace and the ALRP-Priority AVP. +4.11. Application-Level Resource Priority (ALRP) Parameter A description of the semantic of the parameter values can be found in [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for parameter is as follows: - ALRP ::= < AVP Header: TBD > - { ALRP-Namespace } - { ALRP-Priority } - -3.10.1. ALRP-Namespace AVP - - The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32. - -3.10.2. ALRP-Priority AVP + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |M|r|r|r| 10 |r|r|r|r| 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ALRP Namespace | ALRP Priority | (Reserved) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - The Path-Jitter-STAT4 AVP (AVP Code TBD) is of type Unsigned32. + 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; that registry was later extended by [I-D.ietf-tsvwg-emergency-rsvp]. -3.11. Excess-Treatment AVP - - The Excess-Treatment AVP is a grouped AVP consisting of two AVPs, the - Treatment and the Remark-Value AVP. - - The coding for the Excess-Treatment AVP is as follows: +4.12. Excess Treatment Parameter - Excess-Treatment ::= < AVP Header: TBD > - { Excess-Treatment-Value } - [ Remark-Value ] + The coding for the parameter is as follows: -3.11.1. Excess-Treatment-Value AVP + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - 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: + 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 + parameter. Allowed values are as follows: 0: drop 1: shape 2: remark 3: no metering or policing is permitted - The default treatment in case that none is specified is that there - are no guarantees to excess traffic, i.e., a QoS aware node can do - what it finds suitable. + The default excess treatment in case that none is specified is that + there are no guarantees to excess traffic, i.e., a QoS aware node can + do what it finds suitable. - When the treatment is set to 'drop', all marked traffic MUST be + When excess treatment is set to 'drop', all marked traffic MUST be dropped by a QoS aware node. - When the treatment is set to 'shape', it is expected that QoS - parameters conveyed as part of QoS-Desired are used to reshape the - traffic (for example a TMOD parameter indicated as QoS desired). - When the shaping causes unbounded queue growth at the shaper traffic - can be dropped. - - When the treatment is set to 'remark', the excess treatment parameter - MUST carry the remark value. For example, packets may be remarked to - drop remarked to pertain to a particular QoS class. In the latter - case, remarking relates to a DiffServ-type model, where packets - arrive marked as belonging to a certain QoS class, and when they are - identified as excess, they should then be remarked to a different QoS - Class. The Remark-Value AVP carries the information used for re- - marking. + When excess treatment is set to 'shape', it is expected that the QoS + 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. - If 'no metering or policing is permitted' is indicated, the QoS aware - node should accept the treatment set by the sender with special care - so that excess traffic should not cause a problem. To request the - Null Meter [RFC3290] is especially strong, and should be used with - caution. + When excess treatment is set to 'remark', the excess treatment + parameter MUST carry the remark value. For example, packets may be + remarked to drop remarked to pertain to a particular QoS class. In + the latter case, remarking relates to a DiffServ-type model, where + packets arrive marked as belonging to a certain QoS class, and when + they are identified as excess, they should then be remarked to a + different QoS Class. -3.11.2. Remark-Value AVP + If 'no metering or policing is permitted' is signaled, the QoS aware + node should accept the excess treatment parameter set by the sender + with special care so that excess traffic should not cause a problem. + To request the Null Meter [RFC3290] is especially strong, and should + be used with caution. - The Remark-Value AVP (AVP Code TBD) is of type Unsigned32 and - contains the DSCP value the excess traffic should be remarked to. + The Remark Value is an 8 bit unsigned integer value in network byte + order. -3.11.3. PHB-Class AVP +4.13. PHB Class Parameter - 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: + A description of the semantic of the parameter values can be found in + [RFC3140]. The coding for the 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| 12 |r|r|r|r| 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ As prescribed in [RFC3140], the encoding for a single PHB is the recommended DSCP value for that PHB, left-justified in the 16 bit field, with bits 6 through 15 set to zero. The encoding for a set of PHBs is the numerically smallest of the set of encodings for the various PHBs in the set, with bit 14 set to 1. (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with @@ -516,37 +552,55 @@ Scheduling Class (i.e., use of PHBs from the set MUST NOT cause intra-microflow traffic reordering when different PHBs from the set are applied to traffic in the same microflow). The set of AF1x PHBs [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that do not constitute a PHB Scheduling Class can be identified by using more than one PHBID. The registries needed to use [RFC3140] already exist. Hence, no new registry needs to be created for this purpose. -3.11.4. DSTE-Class-Type AVP +4.14. DSTE Class Type Parameter - The DSTE-Class-Type AVP (AVP Code TBD) is of type Unsigned32. A - description of the semantic of the parameter values can be found in - [RFC4124]. + A description of the semantic of the parameter values can be found in + [RFC4124]. The coding for the parameter is as + follows: - Currently, the values of alues currently allowed are 0, 1, 2, 3, 4, - 5, 6, 7. + 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) | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ -3.11.5. Y.1541-QoS-Class AVP + 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 parameter is not used. - The Y.1541-QoS-Class AVP (AVP Code TBD) is of type Unsigned32. A - description of the semantic of the parameter values can be found in - [Y.1541]. +4.15. Y.1541 QoS Class Parameter - Currently, the allowed values of the Y.1541 QoS class are 0, 1, 2, 3, - 4, 5, 6, 7. + A description of the semantic of the parameter values can be found in + [Y.1541]. The coding for the parameter is as + follows: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |M|r|r|r| 14 |r|r|r|r| 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Y.1541 QoS Cls.| (Reserved) | + +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ + + Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently + allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means + that the parameter is not used. Class 0: Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-3. Real-time, highly interactive applications, sensitive to jitter. Application examples include VoIP, Video Teleconference. Class 1: Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= @@ -584,57 +638,56 @@ television transport, high-capacity TCP transfers, and TDM circuit emulation. Class 7: Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-5. Applications that are highly sensitive to loss, such as television transport, high-capacity TCP transfers, and TDM circuit emulation. -4. Extensibility +5. Extensibility This document is designed with extensibility in mind given that different organizations and groups are used to define their own Quality of Service parameters. This document provides an initial QoS - profile with common set of QoS parameters. Ideally, these parameters + profile with common set of parameters. Ideally, these parameters should be used whenever possible but there are cases where additional parameters might be needed, or where the parameters specified in this document are used with a different semantic. In this case it is advisable to define a new QoS profile that may consist of new parameters in addition to parameters defined in this document or an entirely different set of parameters. To enable the definition of new QoS profiles a 8 octet registry is defined field that is represented by a 4-octet vendor and 4-octet - specifier field. A QoS profile groups together a bunch of QoS - parameters for usage in a specific environment. The vendor field - indicates the type as either standards-specified or vendor-specific. - If the four octets of the vendor field are 0x00000000, then the value - is standards-specified and the registry is maintained by IANA, and - any other value represents a vendor-specific Object Identifier (OID). - IANA created registry is split into two value ranges; one range uses - the "Standards Action" and the second range uses "Specification - Required" allocation policy. The latter range is meant to be used by + specifier field. The vendor field indicates the type as either + standards-specified or vendor-specific. If the four octets of the + vendor field are 0x00000000, then the value is standards-specified + and the registry is maintained by IANA, and any other value + represents a vendor-specific Object Identifier (OID). IANA created + registry is split into two value ranges; one range uses the + "Standards Action" and the second range uses "Specification Required" + allocation policy. The latter range is meant to be used by organizations outside the IETF. -5. IANA Considerations +6. IANA Considerations This section defines the registries and initial codepoint - assignments, in accordance with BCP 26 RFC 2434 [RFC5226]. It also + 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 subsections below. -5.1. QoS Profile +6.1. QoS Profile The QoS Profile refers to a 64 bit long field that is represented by a 4-octet vendor and 4-octet specifier field. The vendor field indicates the type as either standards-specified or vendor-specific. If the four octets of the vendor field are 0x00000000, then the value is standards-specified and the registry is maintained by IANA, and any other value represents a vendor-specific Object Identifier (OID). The specifier field indicates the actual QoS profile. The vendor field 0x00000000 is reserved to indicate that the values in the @@ -648,90 +701,124 @@ For the IANA maintained QoS profiles the following allocation policy is defined: 1 to 511: Standards Action 512 to 4095: Specification Required Standards action is required to depreciate, delete, or modify existing QoS profile values in the range of 0-511 and a specification is required to depreciate, delete, or modify existing QoS profile values in the range of 512-4095. -5.2. AVP Allocations +6.2. Parameter ID - 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 Parameter ID refers to a 12 bit long field. -5.3. Excess-Treatment AVP + The following values are allocated by this specification. + + (0): + (1): + (2): + (3): + (4): + (5): + (6): + (7): & + (8): + (9): + (10): + (11): + (12): + (13): + + 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 Value 3: no metering or policing is permitted Excess Treatment Values 4-63: Standards Action - Excess Treatment Value 64-2^32-1: Reserved + Excess Treatment Value 64-255: Reserved -5.4. DSTE-Class-Type AVP + 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. The following values are allocated by this specification: DSTE Class Type Value 0: DSTE Class Type 0 DSTE Class Type Value 1: DSTE Class Type 1 DSTE Class Type Value 2: DSTE Class Type 2 DSTE Class Type Value 3: DSTE Class Type 3 DSTE Class Type Value 4: DSTE Class Type 4 DSTE Class Type Value 5: DSTE Class Type 5 DSTE Class Type Value 6: DSTE Class Type 6 DSTE Class Type Value 7: DSTE Class Type 7 DSTE Class Type Values 8-63: Standards Action - DSTE Class Type Values 64-2^32-1: Reserved + DSTE Class Type Values 64-255: Reserved -5.5. Y.1541-QoS-Class AVP +6.5. Y.1541 QoS Class Parameter + + The Y.1541 QoS Class parameter refers to an 8 bit long field. The following values are allocated by this specification: Y.1541 QoS Class Value 0: Y.1541 QoS Class 0 Y.1541 QoS Class Value 1: Y.1541 QoS Class 1 Y.1541 QoS Class Value 2: Y.1541 QoS Class 2 Y.1541 QoS Class Value 3: Y.1541 QoS Class 3 Y.1541 QoS Class Value 4: Y.1541 QoS Class 4 Y.1541 QoS Class Value 5: Y.1541 QoS Class 5 Y.1541 QoS Class Value 6: Y.1541 QoS Class 6 Y.1541 QoS Class Value 7: Y.1541 QoS Class 7 Y.1541 QoS Class Values 8-63: Standards Action - Y.1541 QoS Class Values 64-2^32-1: Reserved + Y.1541 QoS Class Values 64-255: Reserved - The values in the ALRP-Namespace and ALRP-Priority AV{ inside the - ALRP AVP take their values from the registry created by [RFC4412] and - extended with [I-D.ietf-tsvwg-emergency-rsvp] No additional actions - are required by IANA by this specification. + 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. -6. Security Considerations +7. Security Considerations This document does not raise any security concerns as it only defines QoS parameters. -7. Acknowledgements +8. Acknowledgements The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec] authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the NSIS working group chairs (John Loughney and Martin Stiemerling) and the former Transport Area Directors (Allison Mankin, Jon Peterson) for their help. We would like to thank Francois Le Faucheur, John Loughney, Martin Stiemerling, Dave Oran, An Nguyen, Ken Carlberg, James Polk, Lars Eggert, and Magnus Westerlund for their help with resolving problems regarding the Admission Priority and the ALRP parameter. -8. References +9. References -8.1. Normative References +9.1. Normative References [I-D.ietf-tsvwg-emergency-rsvp] Faucheur, F., Polk, J., and K. Carlberg, "Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services", draft-ietf-tsvwg-emergency-rsvp-08 (work in progress), May 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. @@ -758,38 +845,35 @@ "Per Hop Behavior Identification Codes", RFC 3140, June 2001. [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001. [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. - [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. - Arkko, "Diameter Base Protocol", RFC 3588, September 2003. - [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005. [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006. [Y.1541] "Network Performance Objectives for IP-Based Services", , 2006. [Y.1571] "Admission Control Priority Levels in Next Generation Networks", , July 2006. -8.2. Informative References +9.2. Informative References [I-D.ietf-nsis-qspec] Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC Template", draft-ietf-nsis-qspec-20 (work in progress), April 2008. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.