Quality of Service Parameters for Usage with the AAA Framework

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.

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 .

The Traffic Model (TMOD) parameter is a container consisting of four sub-parameters: rate (r) bucket size (b) peak rate (p) 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.

<Path Latency>, <Path Jitter>, <Path PLR>, and <Path PER> are QoS parameters describing the desired path latency, path jitter and path bit 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 be the mean packet delay added by each such node. This delay results from speed-of-light propagation delay, from packet processing limitations, or both. The mean delay reflects the variable queuing delay that may be present. The purpose of this parameter is to provide a minimum path latency for use with services which provide estimates or bounds on additional path delay . The procedures for collecting path latency information are outside the scope of this document. The <Path Jitter> parameter refers to the accumulated jitter of the packet forwarding process associated with each QoS aware node along the path, where the jitter is defined to be the nominal jitter added by each such node. IP packet jitter, or delay variation, is defined in Section 3.4 of RFC 3393 , (Type-P-One-way-ipdv), and where the selection function includes the packet with minimum delay such that the distribution is equivalent to 2-point delay variation in . The suggested evaluation interval is 1 minute. This jitter results from packet processing limitations, and includes any variable queuing delay which may be present. The purpose of this parameter is to provide a nominal path jitter for use with services that provide estimates or bounds on additional path delay . The procedures for collecting path jitter information are outside the scope of this document. The <Path PLR> parameter refers to the accumulated packet loss rate (PLR) of the packet forwarding process associated with each QoS aware node along the path where the PLR is defined to be the PLR added by each such node. The <Path PER> parameter refers to the accumulated packet error rate (PER) of the packet forwarding process associated with each QoS aware node, where the PER is defined to be the PER added by each such node. The <Slack Term> parameter refers to the difference between desired delay and delay obtained by using bandwidth reservation, and which is used to reduce the resource reservation for a flow . 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 equal to the defending priority. <Admission Priority> and <RPH Priority> 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.

The <Excess Treatment> parameter describes how a QoS aware node will process excess traffic, that is, out-of-profile traffic. Excess traffic MAY be dropped, shaped and/or remarked.

Resource reservations might refer to a packet processing with a particular DiffServ per-hop behavior (PHB) or to a particular QoS class, e.g., Y.1541 QoS class or DiffServ-aware MPLS traffic engineering (DSTE) class type , .

Each QoS parameter is encoded in TLV format.

<TMOD-1> = <r> <b> <p> <m> , The above notation means that the 4 <TMOD-1> sub-parameters must be carried in the <TMOD-1> parameter. The coding for the <TMOD-1> parameter is as follows:

The <TMOD> parameters are represented by three floating point numbers in single-precision IEEE floating point format followed by one 32-bit integer in network byte order. The first floating point value is the rate (r), the second floating point value is the bucket size (b), the third floating point is the peak rate (p), and the first unsigned integer is the minimum policed unit (m). When r, b, and p terms are represented as IEEE floating point values, the sign bit MUST be zero (all values MUST be non-negative). Exponents less than 127 (i.e., 0) are prohibited. Exponents greater than 162 (i.e., positive 35) are discouraged, except for specifying a peak rate of infinity. Infinity is represented with an exponent of all ones (255) and a sign bit and mantissa of all zeroes.

A description of the semantic of the parameter values can be found in . The <TMOD-2> parameter may be needed in a DiffServ environment. The coding for the <TMOD-2> parameter is as follows:

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.

A description of the semantic of the parameter values can be found in ,. The coding for the <Path Latency> parameter is as follows:

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 along the path can range as high as (2**32)-2.

The coding for the <Path Jitter> parameter is as follows:

The Path Jitter is a set of four 32-bit integers in network byte order. The Path Jitter parameter is the combination of four statistics describing the Jitter distribution with a clamp of (2**32 - 1) on the maximum of each value. The jitter STATs are reported in units of one microsecond.

The coding for the <Path PLR> parameter is as follows:

The Path PLR is a single 32-bit single precision IEEE floating point number in network byte order. The PLRs are reported in units of 10^-11. A system with resolution less than one microsecond MUST set unused digits to zero. The total PLR added across all QoS aware nodes can range as high as 10^-1.

The coding for the <Path PLR> parameter is as follows:

The Path PER is a single 32-bit single precision IEEE floating point number in network byte order. The PERs are reported in units of 10^-11. A system with resolution less than one microsecond MUST set unused digits to zero. The total PER added across all QoS aware nodes can range as high as 10^-1.

A description of the semantic of the parameter values can be found in , . The coding for the <Path PLR> parameter is as follows:

The Slack Term parameter S is a 32-bit integer value in network byte order and is measured in microseconds. S is represented as a 32-bit integer. Its value can range from 0 to (2**32)-1 microseconds.

A description of the semantic of the parameter values can be found in . The coding for the <Preemption Priority> & <Defending Priority> sub-parameters is as follows:

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 , <Preemption Priority> & <Defending Priority> are 16-bit integer values. They are represented in network byte order.

A description of the semantic of the parameter values can be found in . The coding for the <Admission Priority> parameter is as follows:

The 'Admis.Priority' field is a 8 bit unsigned integer in network byte order. High priority flows, normal priority flows, and best-effort priority flows can have access to resources depending on their admission priority value as follows:

A reservation without an <Admission Priority> parameter (i.e., set to 255) MUST be treated as a reservation with an <Admission Priority> = 1.

A description of the semantic of the parameter values can be found in and in . The coding for parameter is as follows:

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. defines a resource priority header and established the initial registry; that registry was later extended by .

The coding for the <Excess Treatment> parameter is as follows:

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:

The default excess treatment in case that none is specified is that there are no guarantees to excess traffic, i.e., a QoS aware node can do what it finds suitable. When excess treatment is set to 'drop', all marked traffic MUST be dropped by a QoS aware node. When excess treatment is set to 'shape', it is expected that the QoS Desired object carries a TMOD parameter. Excess traffic is to be shaped to this TMOD. When the shaping causes unbounded queue growth at the shaper traffic can be dropped. When excess treatment is set to 'remark', the excess treatment parameter MUST carry the remark value. For example, packets may be remarked to drop remarked to pertain to a particular QoS class. In the latter case, remarking relates to a DiffServ-type model, where packets arrive marked as belonging to a certain QoS class, and when they are identified as excess, they should then be remarked to a different QoS Class. If 'no metering or policing is permitted' is signaled, the QoS aware node should accept the excess treatment parameter set by the sender with special care so that excess traffic should not cause a problem. To request the Null Meter is especially strong, and should be used with caution. The Remark Value is an 8 bit unsigned integer value in network byte order.

A description of the semantic of the parameter values can be found in . The coding for the <PHB Class> parameter is as follows:

As prescribed in , 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.)

PHBs not defined by standards action, i.e., experimental or local use PHBs as allowed by . 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 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 already exist. Hence, no new registry needs to be created for this purpose.

A description of the semantic of the parameter values can be found in . The coding for the <DSTE Class Type> parameter is as follows:

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.

A description of the semantic of the parameter values can be found in . The coding for the <Y.1541 QoS Class> parameter is as follows:

Y.1541 QoS Class: Indicates the Y.1541 QoS Class. Values currently allowed are 0, 1, 2, 3, 4, 5, 6, 7. A value of 255 (all 1's) means that the <Y.1541 QoS Class> parameter is not used. 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. 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. Mean delay <= 100 ms, delay variation unspecified, loss ratio <= 10^-3. Highly interactive transaction data. Application examples include signaling. Mean delay <= 400 ms, delay variation unspecified, loss ratio <= 10^-3. Interactive transaction data. Application examples include signaling. Mean delay <= 1 sec, delay variation unspecified, loss ratio <= 10^-3. Low Loss Only applications. Application examples include short transactions, bulk data, video streaming. Mean delay unspecified, delay variation unspecified, loss ratio unspecified. Unspecified applications. Application examples include traditional applications of default IP networks. 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. 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.

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, 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.

This section defines the registries and initial codepoint assignments, in accordance with BCP 26 RFC 2434 . 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.

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

The Parameter ID refers to a 12 bit long field. The following values are allocated by this specification.

(1): (2): (3): (4): (5): (6): (7): & (8): (9): (10): (11): (12): (13): ]]> The allocation policies for further values are as follows: 14-127: Standards Action 128-255: Private/Experimental Use 255-4095: Specification Required A standards track document is required to depreciate, delete, or modify existing Parameter IDs.

The Admission Priority parameter refers to a 8 bit long field. The following values are allocated by this specification: Admission Priority 0: best-effort priority flow Admission Priority 1: normal priority flow Admission Priority 2: high priority flow Admission Priority 3-63: Standards Action Admission Priority 64-255: Reserved

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 DSTE Class Type parameter refers to an 8 bit long field. The following values are allocated by this specification: DSTE Class Type Value 0: DSTE Class Type 0 DSTE Class Type Value 1: DSTE Class Type 1 DSTE Class Type Value 2: DSTE Class Type 2 DSTE Class Type Value 3: DSTE Class Type 3 DSTE Class Type Value 4: DSTE Class Type 4 DSTE Class Type Value 5: DSTE Class Type 5 DSTE Class Type Value 6: DSTE Class Type 6 DSTE Class Type Value 7: DSTE Class Type 7 DSTE Class Type Values 8-63: Standards Action DSTE Class Type Values 64-255: Reserved

The Y.1541 QoS Class parameter refers to an 8 bit long field. The following values are allocated by this specification: Y.1541 QoS Class Value 0: Y.1541 QoS Class 0 Y.1541 QoS Class Value 1: Y.1541 QoS Class 1 Y.1541 QoS Class Value 2: Y.1541 QoS Class 2 Y.1541 QoS Class Value 3: Y.1541 QoS Class 3 Y.1541 QoS Class Value 4: Y.1541 QoS Class 4 Y.1541 QoS Class Value 5: Y.1541 QoS Class 5 Y.1541 QoS Class Value 6: Y.1541 QoS Class 6 Y.1541 QoS Class Value 7: Y.1541 QoS Class 7 Y.1541 QoS Class Values 8-63: Standards Action Y.1541 QoS Class Values 64-255: Reserved

The ALRP Namespace and ALRP Priority field inside the ALRP Parameter take their values from the registry created by and extended with No additional actions are required by IANA by this specification.

This document does not raise any security concerns as it only defines QoS parameters.

The authors would like to thank the 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.