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 Frameworkdraft-ietf-dime-qos-parameters-04.txtdraft-ietf-dime-qos-parameters-05.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 27, 2008. Abstract This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .34 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 . . . . . . . . . . . . . . . .36 3.Parameter OverviewAVP Definition . . . . . . . . . . . . . . . . . . . . . .3. . 6 3.1.Traffic Model ParameterTMOD-1 AVP . . . . . . . . . . . . . . . . .3 3.2. Constraints Parameters. . . . . . . 6 3.1.1. TMOD-Rate-1 AVP . . . . . . . . . . .3 3.3. Traffic Handling Directives. . . . . . . . 6 3.1.2. TMOD-Size-1 AVP . . . . . . .5 3.4. Traffic Classifiers. . . . . . . . . . . . 6 3.1.3. Peak-Data-Rate-1 AVP . . . . . . .5 4. Parameter Encoding. . . . . . . . . . 6 3.1.4. Minimum-Policed-Unit-1 AVP . . . . . . . . . . . .5 4.1. Parameter Header. . 6 3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . .5 4.2. TMOD-1 Parameter. . . . . 7 3.2.1. TMOD-Rate-2 AVP . . . . . . . . . . . . . . . .5 4.3. TMOD-2 Parameter. . . 7 3.2.2. TMOD-Size-2 AVP . . . . . . . . . . . . . . . . . .6 4.4. Path Latency Parameter. 7 3.2.3. Peak-Data-Rate-2 AVP . . . . . . . . . . . . . . . . . 74.5. Path Jitter Parameter3.2.4. Minimum-Policed-Unit-2 AVP . . . . . . . . . . . . . . 7 3.3. Path-Latency AVP . . . .7 4.6. Path PLR Parameter. . . . . . . . . . . . . . . . . 7 3.4. Path-Jitter AVP . . .8 4.7. Path PER Parameter. . . . . . . . . . . . . . . . . . 8 3.4.1. Path-Jitter-STAT1 AVP . .8 4.8. Slack Term Parameter. . . . . . . . . . . . . . 8 3.4.2. Path-Jitter-STAT2 AVP . . . . .9 4.9. Preemption Priority amp; Defending Priority Parameters. .9 4.10. Admission Priority Parameter. . . . . . . . . 8 3.4.3. Path-Jitter-STAT3 AVP . . . . . .10 4.11. Application-Level Resource Priority (ALRP) Parameter. . .10 4.12. Excess Treatment Parameter. . . . . . . 8 3.4.4. Path-Jitter-STAT4 AVP . . . . . . . . .11 4.13. PHB Class Parameter. . . . . . . 8 3.5. Path-PLR AVP . . . . . . . . . . . .12 4.14. DSTE Class Type Parameter. . . . . . . . . . . 8 3.6. Path-PER AVP . . . . .13 4.15. Y.1541 QoS Class Parameter. . . . . . . . . . . . . . . .13 5. Extensibility. . 9 3.7. Slack-Term AVP . . . . . . . . . . . . . . . . . . . . . .15 6. IANA Considerations9 3.8. Priority AVP . . . . . . . . . . . . . . . . . . . . .15 6.1. QoS Profile. . 9 3.8.1. Preemption-Priority AVP . . . . . . . . . . . . . . . 9 3.8.2. Defending-Priority AVP . . . . . .16 6.2. Parameter ID. . . . . . . . . . 9 3.9. Admission-Priority AVP . . . . . . . . . . . . .16 6.3. Excess Treatment Parameter. . . . . 9 3.10. ALRP AVP . . . . . . . . . . .17 6.4. DSTE Class Type Parameter. . . . . . . . . . . . . . 10 3.10.1. ALRP-Namespace AVP . .17 6.5. Y.1541 QoS Class Parameter. . . . . . . . . . . . . . . .18 7. Security Considerations10 3.10.2. ALRP-Priority AVP . . . . . . . . . . . . . . . . . . 10 3.11. Excess-Treatment AVP .18 8. Acknowledgements. . . . . . . . . . . . . . . . . . 10 3.11.1. Excess-Treatment-Value AVP . . . . .18 9. References. . . . . . . . . 11 3.11.2. Remark-Value AVP . . . . . . . . . . . . . . . . .19 9.1. Normative References. . 11 3.11.3. PHB-Class AVP . . . . . . . . . . . . . . . . .19 9.2. Informative References. . . 12 3.11.4. DSTE-Class-Type AVP . . . . . . . . . . . . . . .20 Authors' Addresses. . 13 3.11.5. Y.1541-QoS-Class AVP . . . . . . . . . . . . . . . . . 13 4. Extensibility . . . . .20 Intellectual Property and Copyright Statements. . . . . . . . . .22 1. Introduction. . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5.1. QoS Profile . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. AVP Allocations . . . . . . . . . . . . . . . . . . . . . 16 5.3. Excess-Treatment AVP . . . . . . . . . . . . . . . . . . . 16 5.4. DSTE-Class-Type AVP . . . . . . . . . . . . . . . . . . . 16 5.5. Y.1541-QoS-Class AVP . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 1. Introduction This document defines a number of Quality of Service (QoS) parameters thatcan be reused for conveying QoS information within RADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted by the respective Resource Management Function. 2. Terminology and Abbreviations The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. 3. Parameter Overview 3.1. Traffic Model Parameter The Traffic Model (TMOD) parameter is a container consisting of four sub-parameters: o rate (r) o bucket size (b) o peak rate (p) o minimum policed unit (m) All four sub-parameters MUST be included in the TMOD parameter. The TMOD parameter is a mathematically complete way to describe the traffic source. If, for example, TMOD is set to specify bandwidth only, then set r = peak rate = p, b = large, m = large. As another example if TMOD is set for TCP traffic, then set r = average rate, b = large, p = large. 3.2. Constraints Parameters <Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> arecan be reused for conveying QoSparameters describing the desired path latency, path jitterinformation within RADIUS andpath bit error rate respectively.Diameter. The<Path Latency> parameter refers to the accumulated latencysubsequent section give an overview of thepacket forwarding process associated with each QoS aware node along the path, where the latency isparameters definedto be the mean packet delay addedbyeach 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 ofthis document. 1.1. Traffic Model Parameter The Traffic Model (TMOD) parameter isto provideaminimum 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 scopecontainer consisting ofthis document.four sub-parameters: o rate (r) o bucket size (b) o peak rate (p) o minimum policed unit (m) The<Path Jitter>TMOD parameterrefers to the accumulated jitter of the packet forwarding process associated with each QoS aware node along the path, where the jitterisdefineda mathematically complete way tobe 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 thatdescribe thedistribution 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 parametertraffic source. If, for example, TMOD is set toprovide a nominal path jitterspecify bandwidth only, then set r = peak rate = p, b = large, m = large. As another example if TMOD is set foruse with services that provide estimates or bounds on additionalTCP traffic, then set r = average rate, b = large, p = large. 1.2. Constraints Parameters <Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> are QoS parameters describing the desired pathdelay [RFC2212]. The procedures for collectinglatency, path jitterinformation are outside the scope of this document.and path bit error rate respectively. The <PathPLR>Latency> parameter refers to the accumulatedpacket loss rate (PLR)latency of the packet forwarding process associated with each QoS aware node along thepathpath, where thePLRlatency is defined to be thePLR added by each such node. The <Path PER> parameter refers to the accumulated packet error rate (PER) of themean packetforwarding process associated with each QoS aware node, where the PER is defined to be the PERdelay added by each such node.The <Slack Term> parameter refers to the difference between desiredThis delayandresults from speed-of-light propagation delay, from packet processing limitations, or both. The mean delayobtained by using bandwidth reservation, and which is used to reducereflects theresource reservation for a flow [RFC2212].variable queuing delay that may be present. The<Preemption Priority> parameter refers to the priority of the new flow compared with the <Defending Priority>purpose ofpreviously admitted flows. Once a flow is admitted, the preemption priority becomes irrelevant. The <Defending Priority>this parameteris used to compare with the preemption priority of new flows. For any specific flow, its preemption priority MUST always be less than or equalis tothe defending priority. <Admission Priority> and <RPH Priority>providean essential way to differentiate flows for emergency services, ETS, E911, etc., and assign themahigher admission priority than normal priority flows and best-effort priority flows. 3.3. Traffic Handling Directivesminimum path latency for use with services which provide estimates or bounds on additional path delay [RFC2212]. The<Excess Treatment><Path Jitter> parameterdescribes how arefers to the accumulated jitter of the packet forwarding process associated with each QoS aware nodewill process excess traffic, that is, out-of-profile traffic. Excess traffic MAY be dropped, shaped and/or remarked. 3.4. Traffic Classifiers Resource reservations might referalong the path, where the jitter is defined toabe the nominal jitter added by each such node. IP packetprocessing with a particular DiffServ per-hop behavior (PHB) [RFC2475] or to a particular QoS class, e.g., Y.1541 QoS classjitter, orDiffServ-aware MPLS traffic engineering (DSTE) class type [RFC3564], [RFC4124]. 4. Parameter Encoding 4.1. Parameter Header Each QoS parameterdelay variation, isencodeddefined inTLV format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| Parameter ID |r|r|r|r| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M Flag: When set indicatesSection 3.4 of RFC 3393 [RFC3393], (Type-P-One-way-ipdv), and where thesubsequentselection 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 parameterMUST be interpreted. If the M flagisset andto provide a nominal path jitter for use with services that provide estimates or bounds on additional path delay [RFC2212]. The procedures for collecting path jitter information are outside the scope of this document. The <Path PLR> parameteris not understood then it leadsrefers toan error. IftheM flagaccumulated packet loss rate (PLR) of the packet forwarding process associated with each QoS aware node along the path where the PLR isnot set and then not understood then it candefined to beignored.the PLR added by each such node. Ther bits are reserved. Parameter ID: Assigned<Path PER> parameter refers to the accumulated packet error rate (PER) of the packet forwarding process associated with eachindividualQoSparameter 4.2. TMOD-1 Parameter <TMOD-1> = <r> <b> <p> <m> [RFC2210] , [RFC2215] The above notation means thataware node, where the4 <TMOD-1> sub-parameters mustPER is defined to becarried inthe<TMOD-1> parameter.PER added by each such node. Thecoding for the <TMOD-1><Slack Term> parameteris as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 1 |r|r|r|r| 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TMOD Rate-1 [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TMOD Size-1 [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Data Rate-1 [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Policed Unit-1 [m] (32-bit unsigned integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The <TMOD> parameters are represented by three floating point numbers in single-precision IEEE floating point format followedrefers to the difference between desired delay and delay obtained byone 32-bit integer in network byte order. The first floating point valueusing bandwidth reservation, and which is used to reduce therate (r),resource reservation for a flow [RFC2212]. The <Preemption Priority> parameter refers to thesecond floating point value ispriority of thebucket size (b),new flow compared with thethird floating point<Defending Priority> of previously admitted flows. Once a flow is admitted, thepeak rate (p), and the first unsigned integerpreemption priority becomes irrelevant. The <Defending Priority> parameter is used to compare with theminimum policed unit (m). When r, b, and p terms are represented as IEEE floating point values, the sign bit MUST be zero (all valuespreemption priority of new flows. For any specific flow, its preemption priority MUST always benon-negative). Exponentsless than127 (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 withor equal to the defending priority. <Admission Priority> and <RPH Priority> provide anexponent of all ones (255)essential way to differentiate flows for emergency services, ETS, E911, etc., and assign them asign bithigher admission priority than normal priority flows andmantissa of all zeroes. 4.3. TMOD-2 Parameter A description of the semantic of thebest-effort priority flows. 1.3. Traffic Handling Directives The <Excess Treatment< parametervalues candescribes how a QoS aware node will process excess traffic, that is, out-of-profile traffic. Excess traffic MAY befound in [RFC2215].dropped, shaped and/or remarked. 1.4. Traffic Classes Resource reservations might refer to a packet processing with a particular DiffServ per-hop behavior (PHB) [RFC2475] or to a particular QoS class, e.g., Y.1541 QoS class or DiffServ-aware MPLS traffic engineering (DSTE) class type [RFC3564], [RFC4124]. 2. Terminology and Abbreviations The<TMOD-2> parameter maykey words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to beneededinterpreted as described ina DiffServ environment.RFC2119 [RFC2119]. 3. AVP Definition 3.1. TMOD-1 AVP Thecoding forTMOD-1 AVP is obtained from [RFC2210] and [RFC2215]. The structure of the<TMOD-2> parameterAVP is as follows:0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 2 |r|r|r|r| 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TMOD Rate-2 [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TMOD Size-2 [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Data Rate-2 [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Policed Unit-2 [m] (32-bit unsigned integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ WhenTMOD-1 ::= < AVP Header: TBD > { TMOD-Rate-1 } { TMOD-Size-1 } { Peak-Data-Rate-1 } { Minimum-Policed-Unit-1 } 3.1.1. TMOD-Rate-1 AVP The TMOD-Rate-1 AVP (AVP Code TBD) is of type Float32 and contains the rate (r). 3.1.2. TMOD-Size-1 AVP The TMOD-Size-1 AVP (AVP Code TBD) is of type Float32 and contains the bucket size (b). 3.1.3. Peak-Data-Rate-1 AVP The Peak-Data-Rate-1 AVP (AVP Code TBD) is of type Float32 and contains the peak rate (p). 3.1.4. Minimum-Policed-Unit-1 AVP The Minimum-Policed-Unit-1 AVP (AVP Code TBD) is of type Unsigned32 and contains the minimum policed unit (m). The values r, b, and ptermsare represented as IEEE floating pointvalues,values and the sign bit MUST be zero (all values MUST be non-negative). Exponents less than 127 (i.e., 0) are prohibited. Exponents greater than 162 (i.e., positive 35) are discouraged, except for specifying a peak rate of infinity. Infinity is represented with an exponent of all ones (255) and a sign bit and mantissa of all zeroes.4.4. Path Latency Parameter3.2. TMOD-2 AVP A descriptionof the semantic of the parameter values can be found in [RFC2210],[RFC2215]. The coding for the <Path Latency> parameter is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 3 |r|r|r|r| 1 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | Path Latency (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Path Latency is a single 32-bit integer in network byte order. The composition rule for the <Path Latency> parameter is summation with a clamp of (2**32 - 1) on the maximum value. The latencies are average values reported in units of one microsecond. A system with resolution less than one microsecond MUST set unused digits to zero. The total latency added across all QoS aware nodes alongof thepathsemantic of the parameter values canrange as high as (2**32)-2. 4.5. Path Jitter Parameterbe found in [RFC2215]. The TMOD-2 AVP is useful in a DiffServ environment. The coding for the<Path Jitter> parameterTMOD-2 AVP is as follows:0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 4 |r|r|r|r| 4 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | Path Jitter STAT1(variance) (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Jitter STAT2(99.9%-ile) (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Jitter STAT3(minimum Latency) (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Jitter STAT4(Reserved) (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Path JitterTMOD-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) isa setoffour 32-bit integers in network byte order. The Path Jitter parameter istype Float32 and contains thecombinationrate (r). 3.2.2. TMOD-Size-2 AVP The TMOD-Size-2 AVP (AVP Code TBD) is offour statistics describingtype Float32 and contains theJitter distribution with a clampbucket size (b). 3.2.3. Peak-Data-Rate-2 AVP The Peak-Data-Rate-2 AVP (AVP Code TBD) is of(2**32 - 1) ontype Float32 and contains themaximumpeak rate (p). 3.2.4. Minimum-Policed-Unit-2 AVP The Minimum-Policed-Unit-2 AVP (AVP Code TBD) is ofeach value.type Unsigned32 and contains the minimum policed unit (m). Thejitter STATsvalues r, b, and p arereported in units of one microsecond. 4.6. Path PLR Parameter The coding for the <Path PLR> parameter isrepresented asfollows: 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-bitIEEE floatingpoint) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+point values and the sign bit MUST be zero (all values MUST be non-negative). Exponents less than 127 (i.e., 0) are prohibited. Exponents greater than 162 (i.e., positive 35) are discouraged, except for specifying a peak rate of infinity. Infinity is represented with an exponent of all ones (255) and a sign bit and mantissa of all zeroes. 3.3. Path-Latency AVP ThePath PLRsemantic of the parameter values can be found in [RFC2210] and [RFC2215]. The Path-Latency AVP (AVP Code TBD) is of type Integer32. The composition rule for the path latency is summation with asingle 32-bit single precision IEEE floating point number in network byte order.clamp of (2**32 - 1) on the maximum value. ThePLRslatencies are average values reported in units of10^-11.one microsecond. A system with resolution less than one microsecond MUST set unused digits to zero. The totalPLRlatency added across all QoS aware nodes along the path can range as high as10^-1. 4.7. Path PER Parameter(2**32)-2. 3.4. Path-Jitter AVP The coding for the<Path PLR> parameterPath-Jitter AVP is as follows:0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 6 |r|r|r|r| 1 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | Path Packet Error Ratio (32-bit floating point) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Path-Jitter ::= < AVP Header: TBD > { Path-Jitter-STAT1 } { Path-Jitter-STAT2 } { Path-Jitter-STAT3 } { Path-Jitter-STAT4 } 3.4.1. Path-Jitter-STAT1 AVP The Path-Jitter-STAT1 AVP (AVP Code TBD) is of type Integer32 and contains the variance. 3.4.2. Path-Jitter-STAT2 AVP The Path-Jitter-STAT2 AVP (AVP Code TBD) is of type Integer32 and contains the 99.9%-ile. 3.4.3. Path-Jitter-STAT3 AVP The Path-Jitter-STAT3 AVP (AVP Code TBD) is of type Integer32 and contains the minimum latency. 3.4.4. Path-Jitter-STAT4 AVP The Path-Jitter-STAT4 AVP (AVP Code TBD) is of type Integer32 and is reserved for future use. ThePath PERPath-Jitter AVP is the combination of four statistics describing the jitter distribution with asingle 32-bit single precision IEEE floating point numberclamp of (2**32 - 1) on the maximum of each value. The jitter STATs are reported innetwork byte order.units of one microsecond. 3.5. Path-PLR AVP The Path-PLR AVP (AVP Code TBD) is of type Float32 and contains the path packet loss ratio. ThePERsPLRs are reported in units of 10^-11. A system with resolution less than one microsecond MUST set unused digits to zero. The totalPERPLR added across all QoS aware nodes can range ashigh as 10^-1. 4.8. Slack Term Parameter A description of the semantic of the parameter values can be found in [RFC2212], [RFC2215]. The coding for the <Path PLR> parameter is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 7 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Slack Term [S] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+high as 10^-1. 3.6. Path-PER AVP The Path-PER AVP (AVP Code TBD) is of type Float32 and contains the path packet error ratio. TheSlack Term parameter SPERs are reported in units of 10^-11. A system with resolution less than one microsecond MUST set unused digits to zero. The total PER added across all QoS aware nodes can range as high as 10^-1. 3.7. Slack-Term AVP The Slack-Term AVP (AVP Code TBD) isa 32-bit integer valueof type Integer32 and its semantic can be found innetwork byte order[RFC2212] andis[RFC2215]. The Slack-Term AVP contains values measured inmicroseconds. S is represented as a 32-bit integer. Itsmicroseconds and its value can range from 0 to (2**32)-1 microseconds.4.9. Preemption3.8. Priorityamp; DefendingAVP The PriorityParametersAVP is a grouped AVP consisting of two AVPs, the Preemption-Priority and the Defending-Priority AVP. A description of the semanticof the parameter valuescan be found in [RFC3181].The coding for the <Preemption Priority> & <Defending Priority> sub- parameters is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 8 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preemption Priority | DefendingPriority| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Preemption Priority: The::= < AVP Header: TBD > { Preemption-Priority } { Defending-Priority } 3.8.1. Preemption-Priority AVP The Preemption-Priority AVP (AVP Code TBD) is of type Unsigned32 and it indicates the priority of the new flow compared with the defending priority of previously admitted flows. Higher values represent higher priority.Defending Priority:3.8.2. Defending-Priority AVP The Defending-Priority AVP (AVP Code TBD) is of type Unsigned32. Once a flow is admitted, the preemption priority becomes irrelevant. Instead, its defending priority is used to compare with the preemption priority of new flows.As specified in [RFC3181], <Preemption Priority> & <Defending Priority> are 16-bit integer values. They are represented in network byte order. 4.10. Admission Priority Parameter The coding for the <Admission Priority> parameter is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 9 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Admis.Priority| (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The 'Admis.Priority' field3.9. Admission-Priority AVP The Admission-Priority AVP (AVP Code TBD) isa 8 bit unsigned integer in network byte order.of type Unsigned32. The admission control priority of the flow, in terms of access to network bandwidth in order to provide higher probability of call completion to selected flows. Higher values represent higher priority. A givenAdmission Priorityadmission priority is encoded in this information element using the same value as when encoded in theAdmissionAdmission- PriorityparameterAVP 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]. Inother words, a given value inside the Admission Priority information element defined inother words, a given value inside thepresent document,Admission-Priority AVP, inside the [I-D.ietf-nsis-qspec]Admission Priorityadmission priority parameter or inside the [I-D.ietf-tsvwg-emergency-rsvp]Admission Priorityadmission priority parameter, refers to the sameAdmission Priority. 4.11.admission priority. 3.10. ALRP AVP The Application-Level Resource Priority (ALRP)ParameterAVP is a grouped AVP consisting of two AVPs, the ALRP-Namespace and the ALRP-Priority AVP. A description of the semantic of the parameter values can be found in [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for parameter is as follows:0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 10 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ALRP Namespace |ALRPPriority | (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ALRP Namespace field::= < AVP Header: TBD > { ALRP-Namespace } { ALRP-Priority } 3.10.1. ALRP-Namespace AVP The ALRP-Namespace AVP (AVP Code TBD) isa 16 bits long unsigned integer in network byte order and the ALRP Priority fieldof type Unsigned32. 3.10.2. ALRP-Priority AVP The Path-Jitter-STAT4 AVP (AVP Code TBD) isan 8 bit long unsigned integer in network byte order containing the specific priority value.of type Unsigned32. [RFC4412] defines a resource priority header and established the initial registry; that registry was later extended by [I-D.ietf-tsvwg-emergency-rsvp].4.12. Excess3.11. Excess-Treatment AVP The Excess-Treatment AVP is a grouped AVP consisting of two AVPs, the TreatmentParameterand the Remark-Value AVP. The coding for the<Excess Treatment> parameterExcess-Treatment AVP is as follows:0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 11 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Excess Trtmnt | Remark Value | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Excess Treatment (8 bit unsigned integer value in network byte order): IndicatesExcess-Treatment ::= < AVP Header: TBD > { Excess-Treatment-Value } [ Remark-Value ] 3.11.1. Excess-Treatment-Value AVP The Excess-Treatment-Value AVP (AVP Code TBD) is of type Enumerated and indicates howthea QoS aware node should processout-of- profile traffic, that is, traffic not covered by the <Traffic> parameter. Allowedout-of-profile traffic. The following values areas follows:currently defined: 0: drop 1: shape 2: remark 3: no metering or policing is permitted The defaultexcesstreatment 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. Whenexcessthe treatment is set to 'drop', all marked traffic MUST be dropped by a QoS aware node. Whenexcessthe treatment is set to 'shape', it is expected thattheQoSDesired object carriesparameters conveyed as part of QoS-Desired are used to reshape the traffic (for example a TMODparameter. Excess traffic is to be shaped to this TMOD.parameter indicated as QoS desired). When the shaping causes unbounded queue growth at the shaper traffic can be dropped. Whenexcessthe treatment is set to 'remark', the excess treatment parameter MUST carry the remark value. For example, packets may be remarked to drop remarked to pertain to a particular QoS class. In the latter case, remarking relates to a DiffServ-type model, where packets arrive marked as belonging to a certain QoS class, and when they are identified as excess, they should then be remarked to a different QoS Class. The Remark-Value AVP carries the information used for re- marking. If 'no metering or policing is permitted' issignaled,indicated, the QoS aware node should accept theexcesstreatmentparameterset 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 Value3.11.2. Remark-Value AVP The Remark-Value AVP (AVP Code TBD) is of type Unsigned32 and contains the DSCP value the excess traffic should be remarked to. 3.11.3. PHB-Class AVP The PHB-Class AVP (AVP Code TBD) is of type OctetString and isan 8 bit unsigned integer value in network byte order. 4.13. PHB Class Parametertwo octets long. A description of the semantic of the parameter values can be found in [RFC3140]. The coding for the<PHB Class> parametervalues is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|M|r|r|r| 12 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ As prescribed in [RFC3140], the encoding for a single PHB is the recommended DSCP value for that PHB, left-justified in the 16 bit field, with bits 6 through 15 set to zero. The encoding for a set of PHBs is the numerically smallest of the set of encodings for the various PHBs in the set, with bit 14 set to 1. (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with bit 14 set to 1.) 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSCP |0 0 0 0 0 0 0 0 X 0| +---+---+---+---+---+---+---+---+ PHBs not defined by standards action, i.e., experimental or local use PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB identification code, assigned by the IANA, is placed left-justified in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PHD ID CODE |0 0 X 0| +---+---+---+---+---+---+---+---+ Bits 12 and 13 are reserved either for expansion of the PHB identification code, or for other use, at some point in the future. In both cases, when a single PHBID is used to identify a set of PHBs (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB Scheduling Class (i.e., use of PHBs from the set MUST NOT cause intra-microflow traffic reordering when different PHBs from the set are applied to traffic in the same microflow). The set of AF1x PHBs [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that do not constitute a PHB Scheduling Class can be identified by using more than one PHBID. The registries needed to use [RFC3140] already exist. Hence, no new registry needs to be created for this purpose.4.14. DSTE Class Type Parameter3.11.4. DSTE-Class-Type AVP The DSTE-Class-Type AVP (AVP Code TBD) is of type Unsigned32. A description of the semantic of the parameter values can be found in [RFC4124].The coding for the <DSTE Class Type> parameter is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 13 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |DSTE Cls. Type | (Reserved) | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ DSTE Class Type: IndicatesCurrently, theDSTE class type. Valuesvalues of alues currently allowed are 0, 1, 2, 3, 4, 5, 6, 7.A value of 255 (all 1's) means that the <DSTE Class Type> parameter3.11.5. Y.1541-QoS-Class AVP The Y.1541-QoS-Class AVP (AVP Code TBD) isnot used. 4.15. Y.1541 QoS Class Parameterof type Unsigned32. A description of the semantic of the parameter values can be found in [Y.1541].The coding forCurrently, the<Y.1541 QoS Class> parameter is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 14 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Y.1541 QoS Cls.| (Reserved) | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Y.1541 QoS Class: Indicatesallowed values of the Y.1541 QoSClass. Values currently allowedclass are 0, 1, 2, 3, 4, 5, 6, 7.A value of 255 (all 1's) means that the <Y.1541 QoS Class> parameter is not used.Class 0: Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-3. Real-time, highly interactive applications, sensitive to jitter. Application examples include VoIP, Video Teleconference. Class 1: Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-3. Real-time, interactive applications, sensitive to jitter. Application examples include VoIP, Video Teleconference. Class 2: Mean delay <= 100 ms, delay variation unspecified, loss ratio <= 10^-3. Highly interactive transaction data. Application examples include signaling. Class 3: Mean delay <= 400 ms, delay variation unspecified, loss ratio <= 10^-3. Interactive transaction data. Application examples include signaling. Class 4: Mean delay <= 1 sec, delay variation unspecified, loss ratio <= 10^-3. Low Loss Only applications. Application examples include short transactions, bulk data, video streaming. Class 5: Mean delay unspecified, delay variation unspecified, loss ratio unspecified. Unspecified applications. Application examples include traditional applications of default IP networks. Class 6: Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-5. Applications that are highly sensitive to loss, such as television transport, high-capacity TCP transfers, and TDM circuit emulation. Class 7: Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-5. Applications that are highly sensitive to loss, such as television transport, high-capacity TCP transfers, and TDM circuit emulation.5.4. Extensibility This document is designed with extensibility in mind given that different organizations and groups are used to define their own Quality of Service parameters. This document provides an initial QoS profile with common set of QoS parameters. Ideally, these parameters should be used whenever possible but there are cases where additional parameters might be needed, or where the parameters specified in this document are used with a different semantic. In this case it is advisable to define a new QoS profile that may consist of new parameters in addition to parameters defined in this document or an entirely different set of parameters. To enable the definition of new QoS profiles a 8 octet registry is defined field that is represented by a 4-octet vendor and 4-octet specifier field. A QoS profile groups together a bunch of QoS parameters for usage in a specific environment. The vendor field indicates the type as either standards-specified or vendor-specific. If the four octets of the vendor field are 0x00000000, then the value is standards-specified and the registry is maintained by IANA, and any other value represents a vendor-specific Object Identifier (OID). IANA created registry is split into two value ranges; one range uses the "Standards Action" and the second range uses "Specification Required" allocation policy. The latter range is meant to be used by organizations outside the IETF.6.5. IANA Considerations This section defines the registries and initial codepoint assignments, in accordance with BCP 26 RFC 2434[RFC2434].[RFC5226]. It also defines the procedural requirements to be followed by IANA in allocating new codepoints. IANA is requested to create the following registries listed in the subsections below.6.1.5.1. QoS Profile The QoS Profile refers to a 64 bit long field that is represented by a 4-octet vendor and 4-octet specifier field. The vendor field indicates the type as either standards-specified or vendor-specific. If the four octets of the vendor field are 0x00000000, then the value is standards-specified and the registry is maintained by IANA, and any other value represents a vendor-specific Object Identifier (OID). The specifier field indicates the actual QoS profile. The vendor field 0x00000000 is reserved to indicate that the values in the specifier field are maintained by IANA. This document requests IANA to create such a registry and to allocate the value zero (0) for the QoS profile defined in this document. For any other vendor field, the specifier field is maintained by the vendor. For the IANA maintained QoS profiles the following allocation policy is defined: 1 to 511: Standards Action 512 to 4095: Specification Required Standards action is required to depreciate, delete, or modify existing QoSprofile values in the range of 0-511 and a specification is required to depreciate, delete, or modify existing QoS profile values in the range of 512-4095. 6.2. Parameter ID The Parameter ID refers to a 12 bit long field. The following values are allocated by this specification. (0): <TMOD-1> (1): <TMOD-2> (2): <Path Latency> (3): <Path Jitter> (4): <Path PLR> (5): <Path PER> (6): <Slack Term> (7): <Preemption Priority> & <Defending Priority> (8): <Admission Priority> (9): <ALRP> (10): <Excess Treatment> (11): <PHB Class> (12): <DSTE Class Type> (13): <Y.1541 QoS Class> The allocation policies for furtherprofile valuesare as follows: 14-127: Standards Action 128-255: Private/Experimental Use 255-4095: Specification Required A standards track documentin the range of 0-511 and a specification is required to depreciate, delete, or modify existingParameter IDs. 6.3. Excess Treatment Parameter The Excess Treatment parameter refersQoS profile values in the range of 512-4095. 5.2. AVP Allocations This specification assigns the values TBD1 toan 8 bit long field.TBD2 from the AVP Code namespace defined in [RFC3588]. See Section 3 for the assignment of the namespace in this specification. 5.3. Excess-Treatment AVP The following values are allocated by this specification: Excess Treatment Value 0: drop Excess Treatment Value 1: shape Excess Treatment Value 2: remark Excess TreatmentValue3:Value 3: no metering or policing is permitted Excess Treatment Values 4-63: Standards Action Excess Treatment Value64-255:64-2^32-1: ReservedThe 8 bit Remark Value allocation policies are as follows: 0-63: Specification Required 64-127: Private/Experimental Use 128-255: Reserved 6.4. DSTE Class Type Parameter The DSTE Class Type parameter refers to an 8 bit long field.5.4. DSTE-Class-Type AVP The following values are allocated by this specification: DSTE Class Type Value 0: DSTE Class Type 0 DSTE Class Type Value 1: DSTE Class Type 1 DSTE Class Type Value 2: DSTE Class Type 2 DSTE Class Type Value 3: DSTE Class Type 3 DSTE Class Type Value 4: DSTE Class Type 4 DSTE Class Type Value 5: DSTE Class Type 5 DSTE Class Type Value 6: DSTE Class Type 6 DSTE Class Type Value 7: DSTE Class Type 7 DSTE Class Type Values 8-63: Standards Action DSTE Class Type Values64-255:64-2^32-1: Reserved6.5. Y.1541 QoS Class Parameter The Y.1541 QoS Class parameter refers to an 8 bit long field.5.5. Y.1541-QoS-Class AVP The following values are allocated by this specification: Y.1541 QoS Class Value 0: Y.1541 QoS Class 0 Y.1541 QoS Class Value 1: Y.1541 QoS Class 1 Y.1541 QoS Class Value 2: Y.1541 QoS Class 2 Y.1541 QoS Class Value 3: Y.1541 QoS Class 3 Y.1541 QoS Class Value 4: Y.1541 QoS Class 4 Y.1541 QoS Class Value 5: Y.1541 QoS Class 5 Y.1541 QoS Class Value 6: Y.1541 QoS Class 6 Y.1541 QoS Class Value 7: Y.1541 QoS Class 7 Y.1541 QoS Class Values 8-63: Standards Action Y.1541 QoS Class Values64-255:64-2^32-1: Reserved TheALRP Namespacevalues in the ALRP-Namespace andALRP Priority fieldALRP-Priority AV{ inside the ALRPParameterAVP take their values from the registry created by [RFC4412] and extended with [I-D.ietf-tsvwg-emergency-rsvp] No additional actions are required by IANA by this specification.7.6. Security Considerations This document does not raise any security concerns as it only defines QoS parameters.8.7. Acknowledgements The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec] authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the NSIS working group chairs (John Loughney and Martin Stiemerling) and the former Transport Area Directors (Allison Mankin, Jon Peterson) for their help. We would like to thank Francois Le Faucheur, John Loughney, Martin Stiemerling, Dave Oran, An Nguyen, Ken Carlberg, James Polk, Lars Eggert, and Magnus Westerlund for their help with resolving problems regarding the Admission Priority and the ALRP parameter.9.8. References9.1.8.1. Normative References [I-D.ietf-tsvwg-emergency-rsvp] Faucheur, F., Polk, J., and K. Carlberg, "Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services", draft-ietf-tsvwg-emergency-rsvp-08 (work in progress), May 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997. [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001. [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002.[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.[RFC3564] Le Faucheur, F.[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., andW. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering",J. Arkko, "Diameter Base Protocol", RFC3564, July3588, September 2003. [RFC4124] Le Faucheur, F., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005. [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006. [Y.1541] "Network Performance Objectives for IP-Based Services", , 2006. [Y.1571] "Admission Control Priority Levels in Next Generation Networks", , July 2006.9.2.8.2. Informative References [I-D.ietf-nsis-qspec] Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC Template", draft-ietf-nsis-qspec-20 (work in progress), April 2008.[RFC2434][RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002. [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC2434, October 1998.5226, May 2008. [Y.1540] "Internet Protocol Data Communication Service - IP Packet Transfer and Availability Performance Parameters", , December 2002. Authors' Addresses Jouni Korhonen (editor) TeliaSonera Teollisuuskatu 13 Sonera FIN-00051 Finland Email: jouni.korhonen@teliasonera.com Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 Email:Hannes.Tschofenig@nsn.comHannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.