Diameter Maintenance and J. Korhonen, Ed. Extensions (DIME)TeliaSonera Internet-DraftH. Tschofenig Internet-Draft Nokia Siemens Networks Intended status: Standards TrackNokia Siemens NetworksDecember 18, 2008 Expires:May 5,June 21, 2009November 1, 2008Quality of Service Parameters for Usage withthe AAA Framework draft-ietf-dime-qos-parameters-07.txtDiameter draft-ietf-dime-qos-parameters-08.txt Status of this MemoBy submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or sheThis Internet-Draft isaware have been or will be disclosed, and any of which he or she becomes aware will be disclosed,submitted to IETF inaccordancefull conformance withSection 6the provisions of BCP 78 and 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 onMay 5,June 21, 2009. Copyright Notice Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information withinRADIUS andDiameter. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology and Abbreviations . . . . . . . . . . . . . . . .34 3. QoS ParameterOverview . .Encoding . . . . . . . . . . . . . . . . . . . .34 3.1.Traffic Model Parameter . . . . . . . . . . . .TMOD-1 AVP . . . . .3 3.2. Constraints Parameters. . . . . . . . . . . . . . . . . .3 3.3. Traffic Handling Directives. 4 3.1.1. TMOD-Rate AVP . . . . . . . . . . . . . .5 3.4. Traffic Classifiers. . . . . . 4 3.1.2. TMOD-Size AVP . . . . . . . . . . . . .5 4. Parameter Encoding. . . . . . . 4 3.1.3. Peak-Data-Rate AVP . . . . . . . . . . . . . . .5 4.1. Parameter Header. . . 4 3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 4 3.2. TMOD-2 AVP . . .5 4.2. TMOD-1 Parameter. . . . . . . . . . . . . . . . . . . . . 54.3. TMOD-2 Parameter . . . . . . . . . . . . . . . .3.3. Priority AVP . . . . .6 4.4. Path Latency Parameter. . . . . . . . . . . . . . . . . .7 4.5. Path Jitter Parameter5 3.3.1. Preemption-Priority AVP . . . . . . . . . . . . . . . 5 3.3.2. Defending-Priority AVP . . .7 4.6. Path PLR Parameter. . . . . . . . . . . . . 5 3.4. Admission-Priority AVP . . . . . . .8 4.7. Path PER Parameter. . . . . . . . . . . 5 3.5. ALRP AVP . . . . . . . . .8 4.8. Slack Term Parameter. . . . . . . . . . . . . . . . 6 3.5.1. ALRP-Namespace AVP . . .8 4.9. Preemption Priority amp; Defending Priority Parameters. .9 4.10. Admission Priority Parameter. . . . . . . . . . . . . 6 3.5.2. ALRP-Priority AVP . .9 4.11. Application-Level Resource Priority (ALRP) Parameter. . .10 4.12. Excess Treatment Parameter. . . . . . . . . . . . . 6 3.6. PHB-Class AVP . . .11 4.13. PHB Class Parameter. . . . . . . . . . . . . . . . . . .12 4.13.1.6 3.6.1. Case 1: Single PHB . . . . . . . . . . . . . . . . .12 4.13.2.. 6 3.6.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . .12 4.13.3.7 3.6.3. Case 3: Experimental or Local Use PHBs . . . . . . .13 4.14. DSTE Class Type Parameter. 7 3.7. DSTE-Class-Type AVP . . . . . . . . . . . . . . .13 4.15. Y.1541 QoS Class Parameter. . . . 7 4. Extensibility . . . . . . . . . . . .14 5. Extensibility. . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . .14 6. IANA Considerations. . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . .15 6.1. QoS Profile. . . . . . . 10 7. Acknowledgements . . . . . . . . . . . . . . . .15 6.2. Parameter ID. . . . . . .. . . . . . . . . . . . . . . . 15 6.3. Excess Treatment Parameter . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . .10 8. References . . . . . . . . . . . . . . . . . . .17 9. References . . . . . . . . . . . . . . .. . . . . . .. . . . 17 9.1.10 8.1. Normative References . . . . . . . . . . . . . . . . . . .17 9.2.10 8.2. Informative References . . . . . . . . . . . . . . . . . .1811 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .19 Intellectual Property and Copyright Statements . . . . . . . . . . 2012 1. Introduction This document defines a number of Quality of Service (QoS) parameters that can be reused for conveying QoS information withinRADIUS and Diameter. The payloads used to carry these QoS parameters are opaque for the AAA client and the AAA server itself and interpreted bytherespective 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 thisDiameter protocol. This documentare to be interpreted as described in RFC2119 [RFC2119]. 3. Parameter Overview 3.1. Traffic Model Parameterdefines an initial QoS profile containing a set of QoS AVPs. TheTraffic Modeltraffic model (TMOD)parameter is a containerAVPs are containers consisting of foursub-parameters:AVPs and is a way to describe the traffic source. o rate (r) o bucket size (b) o peak rate (p) o minimum policed unit (m)All four sub-parameters MUSTThe encoding of <TMOD-1> and <TMOD-2> can beincludedfound in Section 3.1 and Section 3.2 and theTMOD parameter. The TMOD parametersemantic isa mathematically complete way to describe the traffic source. If,described in [RFC2210] and in [RFC2215]. <TMOD-2> is, for example,TMODneeded by some DiffServ applications. I t isset to specify bandwidth only, then set r = peaktypically assumed that DiffServ EF traffic is shaped at the ingress by a single rate= p, b = large, m = large. As another example iftoken bucket. Therefore, a single TMOD parameter issetsufficient to signal DiffServ EF traffic. However, forTCP traffic, then set r = average rate, b = large, p = large. 3.2. Constraints Parameters <Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> are QoSDiffServ AF traffic two sets of token bucket parametersdescribingare needed, one token bucket for thedesired path latency, path jitteraverage traffic andpath error rate respectively. The <Path Latency> 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 beone token bucket for themean 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 provideburst traffic. [RFC2697] defines aminimum path latency for use with servicesSingle Rate Three Color Marker (srTCM), whichprovide estimates or bounds on additional path delay [RFC2212]. The procedures for collecting path latency information are outside the scope of this document. The <Path Jitter> parameter refersmeters a traffic stream and marks its packets according tothe accumulated jitter of the packet forwarding process associated with each QoS aware node along the path, where the jitter is definedthree traffic parameters, Committed Information Rate (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS), to bethe nominal jitter added by each such node. IP packet jitter,either green, yellow, ordelay variation,red. A packet isdefined in Section 3.4 of RFC 3393 [RFC3393], (Type-P-One-way-ipdv), and wheremarked green if it does not exceed theselection function includesCBS, yellow if it does exceed thepacket with minimum delay suchCBS, but not the EBS, and red otherwise. [RFC2697] defines specific procedures using two token buckets that run at thedistribution is equivalentsame rate. Therefore, two TMOD AVPs are sufficient to2-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 purposedistinguish among three levels ofthis parameterdrop precedence. An example isto 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 outsidealso described in thescopeappendix ofthis document.[RFC2597]. The<Path PLR> parameter<Preemption-Priority> AVP refers to theaccumulated packet loss rate (PLR)priority ofthe packet forwarding process associateda new flow compared witheach QoS aware node along the path wherethepath PLR<Defending-Priority> AVP of previously admitted flows. Once a flow isdefined to beadmitted, thePLR added by each such node.preemption priority becomes irrelevant. The<Path PER> parameter refers<Defending-Priority> AVP is used tothe accumulated packet error rate (PER) of the packet forwarding process associatedcompare witheach QoS aware node, wherethepath PERpreemption priority of new flows. For any specific flow, its preemption priority isdefined to be the PER added by each such node. The <Slack Term> parameter refers to the difference between desired delay and delay obtained by using bandwidth reservation, and which is used to reduce the resource reservation for a flow [RFC2212]. The <Preemption Priority> parameter refers to the priority of the new flow compared with the <Defending Priority> of previously admitted flows. Once a flow is admitted, the preemption priority becomes irrelevant. The <Defending Priority> 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 equalalways less than or equal to the defending priority.<Admission Priority>The <Admission-Priority> AVP and<RPH Priority><ALRP> AVP provide an essential way to differentiate flows for emergency services, ETS, E911, etc., and assign them a higher admission priority than normal priority flows and best-effort priority flows.3.3. Traffic Handling Directives The <Excess Treatment> parameter describes how a QoS aware node will process excess traffic, that is, out-of-profile traffic. Dopping, shaping or remarking are possible actions. 3.4. Traffic ClassifiersResource reservations might refer to a packet processing with a particular DiffServ per-hop behavior (PHB) [RFC2475] (using the <PHB- Class> AVP) or to a particular QoS class, e.g.,Y.1541 QoS class ora DiffServ-aware MPLS traffic engineering (DSTE) classtype [RFC3564], [RFC4124]. 4. Parameter Encoding 4.1. Parameter Header Each QoS parameter is encodedtype, as described 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 indicates the subsequent parameter MUST be interpreted. If the M flag is set[RFC3564] and in [RFC4124], using theparameter is not understood then it leads to an error. If the M flag is not set<DSTE-Class-Type> AVP. 2. Terminology andthen not understood then it can be ignored.Abbreviations Ther bitskey words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document arereserved. Parameter ID: Assignedtoeach individual QoS parameter Length: Indicates the length of the subsequent databe interpreted as described in32-bit words. 4.2. TMOD-1RFC2119 [RFC2119]. 3. QoS Parameter<TMOD-1> = <r> <b> <p> <m> [RFC2210] , [RFC2215]Encoding 3.1. TMOD-1 AVP Theabove notation means that the 4 <TMOD-1> sub-parameters must be carried in the <TMOD-1> parameter.TMOD-1 AVP is obtained from [RFC2210] and [RFC2215]. Thecoding forstructure of the<TMOD-1> 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| 1 |r|r|r|r| 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TMOD Rate-1 [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TMOD Size-1 [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Data Rate-1 [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Policed Unit-1 [m] (32-bit unsigned integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The <TMOD> parameters are represented by three floating point numbers in single-precision IEEE floating point format followed by one 32-bit integer in network byte order. The first floating point valueTMOD-1 ::= < AVP Header: TBD > { TMOD-Rate } { TMOD-Size } { Peak-Data-Rate } { Minimum-Policed-Unit } 3.1.1. TMOD-Rate AVP The TMOD-Rate AVP (AVP Code TBD) is of type Float32 and contains the rate(r), the second floating point value(r). 3.1.2. TMOD-Size AVP The TMOD-Size AVP (AVP Code TBD) is of type Float32 and contains the bucket size(b), the third floating point(b). 3.1.3. Peak-Data-Rate AVP The Peak-Data-Rate AVP (AVP Code TBD) is of type Float32 and contains the peak rate(p), and the first unsigned integer(p). 3.1.4. Minimum-Policed-Unit AVP The Minimum-Policed-Unit AVP (AVP Code TBD) is of type Unsigned32 and contains the minimum policed unit (m).When r, b, and p terms are represented as IEEE floating point values, the sign bit MUST be zero (all values MUST be non-negative). Exponents less than 127 (i.e., 0) are prohibited. Exponents greater than 162 (i.e., positive 35) are discouraged, except for specifying a peak rate of infinity. Infinity is represented with an exponent of all ones (255) and a sign bit and mantissa of all zeroes. 4.3.3.2. TMOD-2ParameterAVP A description of the semantic of the parameter values can be found in [RFC2215]. The<TMOD-2> parameter may be neededTMOD-2 AVP is useful in a DiffServ environment. The coding for the<TMOD-2> 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| 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. InfinityTMOD-2 ::= < AVP Header: TBD > { TMOD-Rate } { TMOD-Size } { Peak-Data-Rate } { Minimum-Policed-Unit } 3.3. Priority AVP The Priority AVP isrepresented with an exponent of all ones (255) andasign bit and mantissagrouped AVP consisting ofall zeroes. 4.4. Path Latency Parametertwo AVPs, the Preemption-Priority and the Defending-Priority AVP. A description of the semanticof the parameter valuescan be found in[RFC2210],[RFC2215]. The coding for the <Path Latency> parameter[RFC3181]. Priority ::= < AVP Header: TBD > { Preemption-Priority } { Defending-Priority } 3.3.1. Preemption-Priority AVP The Preemption-Priority AVP (AVP Code TBD) isas 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. 4.5. Path Jitter Parameter The coding for the <Path Jitter> 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| 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 Jitter is a set of four 32-bit integers in network byte order. The Path Jitter parameter is the combination of four statistics describing the Jitter distribution with a clamp of (2**32 - 1) on the maximum of each value. The jitter STATs are reported in units of one microsecond. 4.6. Path PLR Parameter 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| 5 |r|r|r|r| 1 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | Path Packet Loss Ratio (32-bit floating point) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Path PLR is a single 32-bit single precision IEEE floating point 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. 4.7. Path PER Parameter The coding for the <Path PER> 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| 6 |r|r|r|r| 1 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | Path Packet Error Ratio (32-bit floating point) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Path PER is a single 32-bit single precision IEEE floating point 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. 4.8. Slack Term Parameter A description of the semantic of the parameter values can be found in [RFC2212], [RFC2215]. The coding for the <Slack Term> 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Slack Term parameter S is a 32-bit integer value in network byte order and is measured in microseconds. S is represented as a 32-bit integer. 4.9. Preemption Priority amp; Defending Priority Parameters A description of the semantic of the parameter values can be found in [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 | Defending Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Preemption Priority: The priority of the new flow compared with the defending priority of previously admitted flows. Higher values represent higher priority. 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. 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' 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 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 information element defined in the present document, inside the [I-D.ietf-nsis-qspec] Admission Priority parameter or inside the [I-D.ietf-tsvwg-emergency-rsvp] Admission Priority parameter, refers to the same Admission Priority. 4.11. Application-Level Resource Priority (ALRP) Parameter 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 | (Reserved) | ALRP Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The ALRP Namespace field is a 16 bits long unsigned integer in network byte order and the ALRP Priority field is an 8 bit long unsigned integer in network byte order containing the specific priority value. [RFC4412] defines a resource priority header and established the initial registry; the encoding of the values in that registry was later extended by [I-D.ietf-tsvwg-emergency-rsvp]. 4.12. Excess Treatment Parameter The coding for the <Excess Treatment> parameter is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 11 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Excess Trtmnt | Remark Value | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Excess Treatment (8 bit unsigned integer value in network byte order): Indicates how the QoS aware node should process out-of- profile traffic, that is, traffic not covered by the <Traffic> parameter. Allowed values are as follows: 0: drop 1: shape 2: remark 3: no metering or policing is permitted Further values can be registered as described in Section 6.3. The default excess treatment in case that none is specified is that there are no guarantees to excess traffic, i.e., a QoS aware node can do whatof type Unsigned32 and itfinds suitable. When excess treatmentindicates the priority of the new flow compared with the defending priority of previously admitted flows. Higher values represent higher priority. 3.3.2. Defending-Priority AVP The Defending-Priority AVP (AVP Code TBD) isset to 'drop', all marked traffic MUST be dropped byof type Unsigned32. Once aQoS aware node. When excess treatment is set to 'shape', itflow isexpected thatadmitted, theQoS Desired object carries a TMOD parameter. Excess trafficpreemption priority becomes irrelevant. Instead, its defending priority is used tobe shaped to this TMOD. When the shaping causes unbounded queue growth atcompare with theshaper traffic can be dropped. When excess treatmentpreemption priority of new flows. 3.4. Admission-Priority AVP The Admission-Priority AVP (AVP Code TBD) isset to 'remark', the excess treatment parameter MUST carryof type Unsigned32. The admission control priority of theremark value. For example, packets may be remarkedflow, in terms of access todrop remarkednetwork bandwidth in order topertainprovide higher probability of call completion toa particular QoS class. Inselected flows. Higher values represent higher priority. A given admission priority is encoded in this information element using thelatter case, remarking relates to a DiffServ-type model, where packets arrive markedsame value asbelonging to a certain QoS class, andwhenthey are identified as excess, they should then be remarked to a different QoS Class. If 'no metering or policing is permitted'encoded in the Admission- Priority AVP defined in Section 3.1 of [I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter). 3.5. ALRP AVP The Application-Level Resource Priority (ALRP) AVP issignaled,a grouped AVP consisting of two AVPs, theQoS aware node should acceptALRP-Namespace and theexcess treatment parameter set byALRP-Priority AVP. A description of thesender with special care so that excess traffic should not cause a problem. To requestsemantic of theNull Meter [RFC3290] is especially strong, and shouldparameter values can beused with caution.found in [RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. TheRemark Valuecoding for parameter is as follows: ALRP ::= < AVP Header: TBD > { ALRP-Namespace } { ALRP-Priority } 3.5.1. ALRP-Namespace AVP The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32. 3.5.2. ALRP-Priority AVP The ALRP-Priority AVP (AVP Code TBD) is 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]. 3.6. PHB-Class AVP The PHB-Class AVP (AVP Code TBD) isan 8 bit unsigned integer value in network byte order. 4.13. PHB Class Parameterof type Unsigned32. A description of the semantic of the parameter values can be found in [RFC3140]. The registries needed for usage with [RFC3140] already exist and hence no new registry needs to be created by this document. Thecoding for the <PHB Class> parameter is as follows andencoding requires threedifferentcases need to be differentiated.The header format is shown in the subsequent figure below and is used by all three cases defined in the subsequent sub-sections. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 12 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.13.1.All bits indicated as "reserved" MUST be set to zero (0). 3.6.1. Case 1: Single PHB 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. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) |+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 4.13.2.+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.6.2. Case 2: Set of PHBs 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 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSCP |0 0 0 0 0 0 0 0 1 0| (Reserved) |+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 4.13.3.+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.6.3. Case 3: Experimental or Local Use PHBs 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. 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. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PHD ID CODE |0 0 10| (Reserved) | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 4.14. DSTE Class Type Parameter A description of the semantic of the parameter values can be found in [RFC4124]. The coding for the <DSTE Class Type> parameter is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|r|r|r| 13 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |DSTE Cls. Type | (Reserved) | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ DSTE Class Type: Indicates the DSTE class type. Values currently allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means that the <DSTE Class Type> parameter is not used. 4.15. Y.1541 QoS Class Parameter A description of the semantic of the parameter values can be found in [Y.1541]. The coding for 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.|0| (Reserved) |+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Y.1541 QoS Class: Indicates+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.7. DSTE-Class-Type AVP The DSTE-Class-Type AVP (AVP Code TBD) is of type Unsigned32. A description of theY.1541 QoS Class. Valuessemantic of the parameter values can be found in [RFC4124]. Currently, the values of alues currently allowed are0,1, 2, 3, 4, 5, 6, 7.AThe value of255 (all 1's) means thatzero (0) is marked as reserved in [RFC4124]. Furthermore, the<Y.1541 QoS Class> parameterCLASSTYPE attribute in [RFC4124] isnot used. 5.32 bits in length with 29 bits reserved. 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 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. 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 as Enterprise Numbers defined in [RFC2578], 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 ConsiderationsThis section defines the registries and initial codepoint assignments, in accordance with BCP 26 RFC 5226 [RFC5226]. It also defines the procedural requirements to be followed by IANA in allocating new codepoints.5.1. AVP Codes IANA is requested tocreateallocate AVP codes for the followingregistries listedAVPs that are defined inthe subsections below. 6.1.this document. +------------------------------------------------------------------+ | AVP Section | |AVP Name Code Defined Data Type | +------------------------------------------------------------------+ |TMOD-1 TBD 3.1 Grouped | |TMOD-Rate TBD 3.1.1 Float32 | |TMOD-Size TBD 3.1.2 Float32 | |Peak-Data-Rate TBD 3.1.3 Float32 | |Minimum-Policed-Unit TBD 3.1.4 Unsigned32 | |TMOD-2 TBD 3.2 Grouped | |Priority TBD 3.3 Grouped | |Preemption-Priority TBD 3.3.1 Unsigned32 | |Defending-Priority TBD 3.3.2 Unsigned32 | |Admission-Priority TBD 3.4 Unsigned32 | |ALRP TBD 3.5 Grouped | |ALRP-Namespace TBD 3.5.1 Unsigned32 | |ALRP-Priority TBD 3.5.2 Unsigned32 | |PHB-Class TBD 3.6 Unsigned32 | |DSTE-Class-Type TBD 3.7 Unsigned32 | +------------------------------------------------------------------+ 5.2. QoS Profile IANA is requested to create the following registry. The QoS Profile refers to a 64 bit long field that is represented by 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:10 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.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 further values are as follows: 14-127: Standards Action 128-255: Private/Experimental Use 255-4095: Specification Required A standards track document is required to depreciate, delete, or modify existing Parameter IDs. 6.3. Excess Treatment Parameter The Excess Treatment parameter refers to an 8 bit long field. The following values are allocated by this specification: Excess Treatment Value 0: drop Excess Treatment Value 1: shape Excess Treatment Value 2: remark Excess Treatment Value3: no metering or policing is permitted Excess Treatment Values 4-63: Standards Action Excess Treatment Value 64-255: Reserved The 8 bit Remark Value allocation policies are as follows: 0-63: Specification Required 64-127: Private/Experimental Use 128-255: Reserved The ALRP Namespace and ALRP Priority field inside the ALRP Parameter take their values from the registry created by [RFC4412] and extended with [I-D.ietf-tsvwg-emergency-rsvp] No additional actions are required by IANA by this specification. 7.6. Security Considerations This document does not raise any security concerns as it only defines QoSparameters. 8.parameters and does not yet describe how they are exchanged in a AAA protocol. Security considerations are described in documents using this specification. 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. This document re-uses content from the NSIS QSPEC [I-D.ietf-nsis-qspec] specification. We would like to thank Ken Carlberg, Lars Eggert, Jan Engelhardt, Francois Le Faucheur, John Loughney,Martin Stiemerling, Dave Oran,An Nguyen,Ken Carlberg,Dave Oran, James Polk,Lars Eggert,Martin Stiemerling, and Magnus Westerlund for their help with resolving problems regarding the Admission Priority and the ALRP parameter. Elwyn Davies provided a detailed review of the specification. Elwyn helped to investigate what QoS mechanisms are deployed in networks today. Jerry Ash, Al Morton, Mayutan Arumaithurai and Xiaoming Fu provided help with the semantic of some QSPEC parameters. We would like to thank Dan Romascanu for his detailed Area Director reviewcomments. 9.comments and Scott Bradner for his Transport Area Directorate review. 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-09 (work in progress), October 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. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [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.[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002.[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of 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] "ITU-T Recommendation Y.1541, Network Performance Objectives for IP-Based Services", , 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-20draft-ietf-nsis-qspec-21 (work in progress),AprilNovember 2008. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color Marker", RFC 2697, September 1999. [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002. [RFC3564] Le Faucheur, F. and W. Lai, "Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering", RFC 3564, July 2003. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.[Y.1540] "ITU-T Recommendation 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-00051Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Email:jouni.korhonen@teliasonera.comjouni.korhonen@nsn.com Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland Phone: +358 (50) 4871445 Email: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.atFull 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.