draft-ietf-dime-qos-parameters-09.txt   draft-ietf-dime-qos-parameters-10.txt 
Diameter Maintenance and J. Korhonen, Ed. Diameter Maintenance and J. Korhonen, Ed.
Extensions (DIME) H. Tschofenig Extensions (DIME) H. Tschofenig
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Standards Track E. Davies Intended status: Standards Track E. Davies
Expires: July 26, 2009 Folly Consulting Expires: September 10, 2009 Folly Consulting
January 22, 2009 March 9, 2009
Quality of Service Parameters for Usage with Diameter Quality of Service Parameters for Usage with Diameter
draft-ietf-dime-qos-parameters-09.txt draft-ietf-dime-qos-parameters-10.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 26, 2009. This Internet-Draft will expire on September 10, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
This document defines a number of Quality of Service (QoS) parameters This document defines a number of Quality of Service (QoS) parameters
that can be reused for conveying QoS information within Diameter. that can be reused for conveying QoS information within Diameter.
The defined QoS information includes data traffic parameters for The defined QoS information includes data traffic parameters for
describing a token bucket filter, bandwidth, defending and preemption describing a token bucket filter, a bandwidth parameter, and a per-
priority, admission priority, application-level resource priority, hop behavior class object.
per-hop behavior class, and DiffServ-aware Multiprotocol Label
Switching (MPLS) traffic engineering.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4 2. Terminology and Abbreviations . . . . . . . . . . . . . . . . 4
3. QoS Parameter Encoding . . . . . . . . . . . . . . . . . . . . 4 3. QoS Parameter Encoding . . . . . . . . . . . . . . . . . . . . 4
3.1. TMOD-1 AVP . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. TMOD-1 AVP . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. TMOD-Rate AVP . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Token-Rate AVP . . . . . . . . . . . . . . . . . . . . 4
3.1.2. TMOD-Size AVP . . . . . . . . . . . . . . . . . . . . 4 3.1.2. Bucket-Depth AVP . . . . . . . . . . . . . . . . . . . 4
3.1.3. Peak-Data-Rate AVP . . . . . . . . . . . . . . . . . . 4 3.1.3. Peak-Traffic-Rate AVP . . . . . . . . . . . . . . . . 4
3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 4 3.1.4. Minimum-Policed-Unit AVP . . . . . . . . . . . . . . . 4
3.1.5. Maximum-Packet-Size AVP . . . . . . . . . . . . . . . 5
3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. TMOD-2 AVP . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Bandwidth AVP . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Bandwidth AVP . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Priority AVP . . . . . . . . . . . . . . . . . . . . . . . 5 3.4. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 5
3.4.1. Preemption-Priority AVP . . . . . . . . . . . . . . . 5 3.4.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 5
3.4.2. Defending-Priority AVP . . . . . . . . . . . . . . . . 5 3.4.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 6
3.5. Admission-Priority AVP . . . . . . . . . . . . . . . . . . 5 3.4.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 6
3.6. ALRP AVP . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 6
3.6.1. ALRP-Namespace AVP . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
3.6.2. ALRP-Priority AVP . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
3.7. PHB-Class AVP . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
3.7.1. Case 1: Single PHB . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.7.2. Case 2: Set of PHBs . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9
3.7.3. Case 3: Experimental or Local Use PHBs . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
3.8. DSTE-Class-Type AVP . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This document defines a number of Quality of Service (QoS) parameters This document defines a number of Quality of Service (QoS) parameters
that can be reused for conveying QoS information within the Diameter that can be reused for conveying QoS information within the Diameter
protocol. protocol [RFC3588]. It defines an initial QoS profile containing a
set of Diameter encoded Attribute Value Pairs (AVPs) described using
This document defines an initial QoS profile containing a set of QoS a modified version of the Augmented Backus-Naur Form (ABNF), see
AVPs. [RFC3588]. The datatypes are also taken from [RFC3588].
The traffic model (TMOD) AVPs are containers consisting of four AVPs The traffic model (TMOD) AVPs are containers consisting of four AVPs
and is a way to describe the traffic source. and is a way to describe the traffic source.
o rate (r) o token rate (r)
o bucket size (b) o bucket depth (b)
o peak rate (p) o peak traffic rate (p)
o minimum policed unit (m) o minimum policed unit (m)
o maximum packet size (M)
The encoding of <TMOD-1> and <TMOD-2> can be found in Section 3.1 and The encoding of the <TMOD-1> and the <TMOD-2> AVP can be found in
Section 3.2 and the semantic is described in [RFC2210] and in Section 3.1 and Section 3.2. The semantics of these two AVPs are
[RFC2215]. <TMOD-2> is, for example, needed by some DiffServ described in Section 3.1 of [RFC2210] and in Section 3.6 of
applications. It is typically assumed that DiffServ EF traffic is [RFC2215].
shaped at the ingress by a single rate token bucket. Therefore, a
single TMOD parameter is sufficient to signal DiffServ EF traffic.
However, for DiffServ AF traffic two sets of token bucket parameters
are needed, one token bucket for the average traffic and one token
bucket for the burst traffic. [RFC2697] defines a Single Rate Three
Color Marker (srTCM), which meters a traffic stream and marks its
packets according to three traffic parameters, Committed Information
Rate (CIR), Committed Burst Size (CBS), and Excess Burst Size (EBS),
to be either green, yellow, or red. A packet is marked green if it
does not exceed the CBS, yellow if it does exceed the CBS, but not
the EBS, and red otherwise. [RFC2697] defines specific procedures
using two token buckets that run at the same rate. Therefore, two
TMOD AVPs are sufficient to distinguish among three levels of drop
precedence. An example is also described in the appendix of
[RFC2597].
The <Preemption-Priority> AVP refers to the priority of a new flow
compared with the <Defending-Priority> AVP of previously admitted
flows. Once a flow is admitted, the preemption priority becomes
irrelevant. The <Defending-Priority> AVP is used to compare with the
preemption priority of new flows. For any specific flow, its
preemption priority is always less than or equal to the defending
priority.
The <Admission-Priority> AVP and <ALRP> AVP provide an essential way The <TMOD-2> AVP is, for example, needed by some DiffServ
to differentiate flows for emergency services, ETS, E911, etc., and applications.
assign them a higher admission priority than normal priority flows It is typically assumed that DiffServ EF traffic is shaped at the
and best-effort priority flows. ingress by a single rate token bucket. Therefore, a single TMOD
parameter is sufficient to signal DiffServ EF traffic. However,
for DiffServ AF traffic two sets of token bucket parameters are
needed, one token bucket for the average traffic and one token
bucket for the burst traffic. [RFC2697] defines a Single Rate
Three Color Marker (srTCM), which meters a traffic stream and
marks its packets according to three traffic parameters, Committed
Information Rate (CIR), Committed Burst Size (CBS), and Excess
Burst Size (EBS), to be either green, yellow, or red. A packet is
marked green if it does not exceed the CBS, yellow if it does
exceed the CBS, but not the EBS, and red otherwise. [RFC2697]
defines specific procedures using two token buckets that run at
the same rate. Therefore, two TMOD AVPs are sufficient to
distinguish among three levels of drop precedence. An example is
also described in the appendix of [RFC2597].
Resource reservations might refer to a packet processing with a Resource reservations might refer to a packet processing with a
particular DiffServ per-hop behavior (PHB) [RFC2475] (using the <PHB- particular DiffServ per-hop behavior (PHB) (using the <PHB-Class>
Class> AVP) or to a particular QoS class, e.g., a DiffServ-aware MPLS AVP). A generic description of the DiffServ architecture can be
traffic engineering (DSTE) class type, as described in [RFC3564] and found in [RFC2475] and the Differentiated Services Field is described
in [RFC4124], using the <DSTE-Class-Type> AVP. in Section 3 of [RFC2474]. Updated terminology can be found in
[RFC3260]. Standardized Per-Hop Behavior is, for example, described
in [RFC2597] (Assured Forwarding Per-Hop Behavior) and in [RFC3246]
(An Expedited Forwarding Per-Hop Behavior).
The above-mentioned parameters are intended to support basic
integrated and differentiated services functionality in the network.
Additional parameters can be defined and standardized if required to
support specific services in future.
2. Terminology and Abbreviations 2. Terminology and Abbreviations
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
3. QoS Parameter Encoding 3. QoS Parameter Encoding
3.1. TMOD-1 AVP 3.1. TMOD-1 AVP
The TMOD-1 AVP is obtained from [RFC2210] and [RFC2215]. The The TMOD-1 AVP is obtained from [RFC2210] and [RFC2215]. The
structure of the AVP is as follows: structure of the AVP is as follows:
TMOD-1 ::= < AVP Header: TBD > TMOD-1 ::= < AVP Header: TBD >
{ TMOD-Rate } { Token-Rate }
{ TMOD-Size } { Bucket-Depth }
{ Peak-Data-Rate } { Peak-Traffic-Rate }
{ Minimum-Policed-Unit } { Minimum-Policed-Unit }
{ Maximum-Packet-Size }
3.1.1. TMOD-Rate AVP 3.1.1. Token-Rate AVP
The TMOD-Rate AVP (AVP Code TBD) is of type Float32 and contains the The Token-Rate AVP (AVP Code TBD) is of type Float32.
rate (r).
3.1.2. TMOD-Size AVP 3.1.2. Bucket-Depth AVP
The TMOD-Size AVP (AVP Code TBD) is of type Float32 and contains the The Bucket-Depth AVP (AVP Code TBD) is of type Float32.
bucket size (b).
3.1.3. Peak-Data-Rate AVP 3.1.3. Peak-Traffic-Rate AVP
The Peak-Data-Rate AVP (AVP Code TBD) is of type Float32 and contains The Peak-Traffic-Rate AVP (AVP Code TBD) is of type Float32.
the peak rate (p).
3.1.4. Minimum-Policed-Unit AVP 3.1.4. Minimum-Policed-Unit AVP
The Minimum-Policed-Unit AVP (AVP Code TBD) is of type Unsigned32 and The Minimum-Policed-Unit AVP (AVP Code TBD) is of type Unsigned32.
contains the minimum policed unit (m).
3.1.5. Maximum-Packet-Size AVP
The Maximum-Packet-Size AVP (AVP Code TBD) is of type Unsigned32.
3.2. TMOD-2 AVP 3.2. TMOD-2 AVP
A description of the semantic of the parameter values can be found in A description of the semantic of the parameter values can be found in
[RFC2215]. The TMOD-2 AVP is useful in a DiffServ environment. The [RFC2215]. The coding for the TMOD-2 AVP is as follows:
coding for the TMOD-2 AVP is as follows:
TMOD-2 ::= < AVP Header: TBD > TMOD-2 ::= < AVP Header: TBD >
{ TMOD-Rate } { Token-Rate }
{ TMOD-Size } { Bucket-Depth }
{ Peak-Data-Rate } { Peak-Traffic-Rate }
{ Minimum-Policed-Unit } { Minimum-Policed-Unit }
{ Maximum-Packet-Size }
3.3. Bandwidth AVP 3.3. Bandwidth AVP
The Bandwidth AVP (AVP Code TBD) is of type Float32 and is measured The Bandwidth AVP (AVP Code TBD) is of type Float32 and is measured
in bytes of IP datagrams per second. in octets of IP datagrams per second.
3.4. Priority AVP
The Priority AVP is a grouped AVP consisting of two AVPs, the
Preemption-Priority and the Defending-Priority AVP. A description of
the semantic can be found in [RFC3181].
Priority ::= < AVP Header: TBD >
{ Preemption-Priority }
{ Defending-Priority }
3.4.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.
3.4.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.
3.5. Admission-Priority AVP
The Admission-Priority AVP (AVP Code TBD) is 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 given admission priority is encoded in this information
element using the same value as when encoded in the Admission-
Priority AVP defined in Section 3.1 of
[I-D.ietf-tsvwg-emergency-rsvp] (Admission Priority parameter).
3.6. ALRP AVP
The Application-Level Resource Priority (ALRP) AVP is a grouped AVP
consisting of two AVPs, the ALRP-Namespace and the ALRP-Priority AVP.
A description of the semantic of the parameter values can be found in
[RFC4412] and in [I-D.ietf-tsvwg-emergency-rsvp]. The coding for
parameter is as follows:
ALRP ::= < AVP Header: TBD >
{ ALRP-Namespace }
{ ALRP-Priority }
3.6.1. ALRP-Namespace AVP
The ALRP-Namespace AVP (AVP Code TBD) is of type Unsigned32.
3.6.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.7. PHB-Class AVP 3.4. PHB-Class AVP
The PHB-Class AVP (AVP Code TBD) is of type Unsigned32. The PHB-Class AVP (AVP Code TBD) is of type Unsigned32.
A description of the semantic of the parameter values can be found in A description of the semantic of the parameter values can be found in
[RFC3140]. The registries needed for usage with [RFC3140] already [RFC3140]. The registries needed for usage with [RFC3140] already
exist and hence no new registry needs to be created by this document. exist and hence no new registry needs to be created by this document.
The encoding requires three cases need to be differentiated. All The encoding requires three cases need to be differentiated. All
bits indicated as "reserved" MUST be set to zero (0). bits indicated as "reserved" MUST be set to zero (0).
3.7.1. Case 1: Single PHB 3.4.1. Case 1: Single PHB
As prescribed in [RFC3140], the encoding for a single PHB is the As prescribed in [RFC3140], the encoding for a single PHB is the
recommended DSCP value for that PHB, left-justified in the 16 bit recommended DSCP value for that PHB, left-justified in the 16 bit
field, with bits 6 through 15 set to zero. field, with bits 6 through 15 set to zero.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) | | DSCP |0 0 0 0 0 0 0 0 0 0| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.7.2. Case 2: Set of PHBs 3.4.2. Case 2: Set of PHBs
The encoding for a set of PHBs is the numerically smallest of the set The encoding for a set of PHBs is the numerically smallest of the set
of encodings for the various PHBs in the set, with bit 14 set to 1. of encodings for the various PHBs in the set, with bit 14 set to 1.
(Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with
bit 14 set to 1.) bit 14 set to 1.)
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP |0 0 0 0 0 0 0 0 1 0| (Reserved) | | DSCP |0 0 0 0 0 0 0 0 1 0| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.7.3. Case 3: Experimental or Local Use PHBs 3.4.3. Case 3: Experimental or Local Use PHBs
PHBs not defined by standards action, i.e., experimental or local use 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 PHBs as allowed by [RFC2474]. In this case an arbitrary 12 bit PHB
identification code, assigned by the IANA, is placed left-justified 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 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. 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 Bits 12 and 13 are reserved either for expansion of the PHB
identification code, or for other use, at some point in the future. identification code, or for other use, at some point in the future.
skipping to change at page 8, line 5 skipping to change at page 6, line 44
[RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that [RFC2597] is an example of a PHB Scheduling Class. Sets of PHBs that
do not constitute a PHB Scheduling Class can be identified by using do not constitute a PHB Scheduling Class can be identified by using
more than one PHBID. more than one PHBID.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHD ID CODE |0 0 1 0| (Reserved) | | PHD ID CODE |0 0 1 0| (Reserved) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8. 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].
Currently, the values of alues currently allowed are 1, 2, 3, 4, 5,
6, 7. The value of zero (0) is marked as reserved in [RFC4124].
Furthermore, the CLASSTYPE attribute in [RFC4124] is 32 bits in
length with 29 bits reserved.
4. Extensibility 4. Extensibility
This document is designed with extensibility in mind given that This document is designed with extensibility in mind given that
different organizations and groups are used to define their own different organizations and groups are used to defining their own
Quality of Service parameters. This document provides an initial QoS Quality of Service parameters. This document provides an initial QoS
profile with common set of parameters. Ideally, these parameters profile with common set of parameters. Ideally, these parameters
should be used whenever possible but there are cases where additional should be used whenever possible but there are cases where additional
parameters might be needed, or where the parameters specified in this parameters might be needed, or where the parameters specified in this
document are used with a different semantic. In that case it is document are used with a different semantic. In that case it is
advisable to define a new QoS profile that may consist of new advisable to define a new QoS profile that may consist of new
parameters in addition to parameters defined in this document or an parameters in addition to parameters defined in this document or an
entirely different set of parameters. Finally, it is also possible entirely different set of parameters. Finally, it is also possible
to register a specific QoS profile that defines a specific set of QoS to register a specific QoS profile that defines a specific set of QoS
values rather than parameters that need to be filled with values in values rather than parameters that need to be filled with values in
order to be used. order to be used.
To enable the definition of new QoS profiles a 8 octet registry is To enable the definition of new QoS profiles a 8 octet registry is
defined field that is represented by a 4-octet vendor and 4-octet defined field that is represented by a 4-octet vendor and 4-octet
specifier field. The vendor field indicates the type as either specifier field. The vendor field contains an Enterprise Number as
standards-specified or vendor-specific. If the four octets of the defined in [RFC2578] taken from the values maintained in the IANA
vendor field are 0x00000000, then the value is standards-specified Enterprise Numbers registry. If the four octets of the vendor field
and the registry is maintained by IANA as Enterprise Numbers defined are 0x00000000 (reserved value for IANA), then the value in the
in [RFC2578], and any other value represents a vendor-specific Object specifier field MUST be registered with IANA (see Section 5.2). If
Identifier (OID). IANA created registry is split into two value the vendor field is other than 0x00000000, the value of the specifier
ranges; one range uses the "Standards Action" and the second range field represents a vendor-specific value, where allocation is the
uses "Specification Required" allocation policy. The latter range is responsibility of the enterprise indicated in the vendor field.
meant to be used by organizations outside the IETF.
5. IANA Considerations 5. IANA Considerations
5.1. AVP Codes 5.1. AVP Codes
IANA is requested to allocate AVP codes for the following AVPs that IANA is requested to allocate AVP codes in the IETF IANA controlled
are defined in this document. namespace registry specified in Section 11.1.1 of [RFC3588] for the
following AVPs that are defined in this document.
+------------------------------------------------------------------+ +------------------------------------------------------------------+
| AVP Section | | AVP Section |
|AVP Name Code Defined Data Type | |AVP Name Code Defined Data Type |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
|TMOD-1 TBD 3.1 Grouped | |TMOD-1 TBD 3.1 Grouped |
|TMOD-Rate TBD 3.1.1 Float32 | |Token-Rate TBD 3.1.1 Float32 |
|TMOD-Size TBD 3.1.2 Float32 | |Bucket-Depth TBD 3.1.2 Float32 |
|Peak-Data-Rate TBD 3.1.3 Float32 | |Peak-Traffic-Rate TBD 3.1.3 Float32 |
|Minimum-Policed-Unit TBD 3.1.4 Unsigned32 | |Minimum-Policed-Unit TBD 3.1.4 Unsigned32 |
|Maximum-Packet-Size TBD 3.1.5 Unsigned32 |
|TMOD-2 TBD 3.2 Grouped | |TMOD-2 TBD 3.2 Grouped |
|Bandwidth TBD 3.3 Float32 | |Bandwidth TBD 3.3 Float32 |
|Priority TBD 3.4 Grouped |
|Preemption-Priority TBD 3.4.1 Unsigned32 |
|Defending-Priority TBD 3.4.2 Unsigned32 |
|Admission-Priority TBD 3.5 Unsigned32 |
|ALRP TBD 3.6 Grouped |
|ALRP-Namespace TBD 3.6.1 Unsigned32 |
|ALRP-Priority TBD 3.6.2 Unsigned32 |
|PHB-Class TBD 3.7 Unsigned32 | |PHB-Class TBD 3.7 Unsigned32 |
|DSTE-Class-Type TBD 3.8 Unsigned32 |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
5.2. QoS Profile 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 The QoS Profile refers to a 64 bit long field that is represented by
a 4-octet vendor and 4-octet specifier field. The vendor field a 4-octet vendor and 4-octet specifier field. The vendor field
indicates the type as either standards-specified or vendor-specific. indicates the type as either standards-specified or vendor-specific.
If the four octets of the vendor field are 0x00000000, then the value
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 If the four octets of the vendor field are 0x00000000, then the value
field 0x00000000 is reserved to indicate that the values in the is standards-specified and a registry will be created to maintain the
specifier field are maintained by IANA. This document requests IANA QoS profile specifier values. The specifier field indicates the
to create such a registry and to allocate the value zero (0) for the actual QoS profile. Depending on the value requested, the action
QoS profile defined in this document. needed to request a new value is:
0 to 511: Standards Action
512 to 32767: Specification Required
32768 to 4294967295: Reserved
For any other vendor field, the specifier field is maintained by the Standards action is required to add, depreciate, delete, or modify
vendor. QoS profile values in the range of 0-511 and a specification is
required to add, depreciate, delete, or modify existing QoS profile
values in the range of 512-32767.
For the IANA maintained QoS profiles the following allocation policy This document requests IANA to create such a registry and to allocate
is defined: the value zero (0) for the QoS profile defined in this document.
0 to 511: Standards Action
512 to 4095: Specification Required
Standards action is required to depreciate, delete, or modify Alternative vendor-specific QoS profiles can be created and
existing QoS profile values in the range of 0-511 and a specification identified with a Enterprise Number taken from the IANA registry
is required to depreciate, delete, or modify existing QoS profile created by [RFC2578] in the vendor field combined with a vendor-
values in the range of 512-4095. specific value in the specifier field. Allocation of the specifier
values is the responsibility of the vendor.
6. Security Considerations 6. Security Considerations
This document does not raise any security concerns as it only defines This document does not raise any security concerns as it only defines
QoS parameters and does not yet describe how they are exchanged in a QoS parameters and does not yet describe how they are exchanged in a
AAA protocol. Security considerations are described in documents AAA protocol. Security considerations are described in documents
using this specification. using this specification.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank the NSIS QSPEC [I-D.ietf-nsis-qspec] The authors would like to thank the NSIS working group members
authors (Cornelia Kappler, Jerry Ash, Attila Bader, Dave Oran), the Cornelia Kappler, Jerry Ash, Attila Bader, and Dave Oran, the former
NSIS working group chairs (John Loughney and Martin Stiemerling) and NSIS working group chairs (John Loughney and Martin Stiemerling) and
the former Transport Area Directors (Allison Mankin, Jon Peterson) the former Transport Area Directors (Allison Mankin, Jon Peterson)
for their help. The authors of this document are thankful for the for their help.
suggestions and input received from the NSIS QSPEC
[I-D.ietf-nsis-qspec] authors.
We would like to thank Ken Carlberg, Lars Eggert, Jan Engelhardt, We would like to thank Ken Carlberg, Lars Eggert, Jan Engelhardt,
Francois Le Faucheur, John Loughney, An Nguyen, Dave Oran, James Francois Le Faucheur, John Loughney, An Nguyen, Dave Oran, James
Polk, Martin Stiemerling, and Magnus Westerlund for their help with Polk, Martin Dolly, Martin Stiemerling, and Magnus Westerlund for
resolving problems regarding the Admission Priority and the ALRP their feedback regarding some of the parameters in this documents.
parameter.
Jerry Ash, Al Morton, Mayutan Arumaithurai and Xiaoming Fu provided Jerry Ash, Al Morton, Mayutan Arumaithurai and Xiaoming Fu provided
help with the semantic of some QSPEC parameters. help with the semantic of some QSPEC parameters.
We would like to thank Dan Romascanu for his detailed Area Director We would like to thank Dan Romascanu for his detailed Area Director
review comments and Scott Bradner for his Transport Area Directorate review comments and Scott Bradner for his Transport Area Directorate
review. review. Chris Newman and Pasi Eronen provided feedback during the
IESG review.
8. References 8. References
8.1. Normative References 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997. Services", RFC 2210, September 1997.
[RFC2215] Shenker, S. and J. Wroclawski, "General Characterization [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements", Parameters for Integrated Service Network Elements",
RFC 2215, September 1997. RFC 2215, September 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998. December 1998.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management Information Schoenwaelder, Ed., "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 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, [RFC3140] Black, D., Brim, S., Carpenter, B., and F. Le Faucheur,
"Per Hop Behavior Identification Codes", RFC 3140, "Per Hop Behavior Identification Codes", RFC 3140,
June 2001. June 2001.
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
RFC 3181, October 2001. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4124] Le Faucheur, F., "Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering", RFC 4124,
June 2005.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)",
RFC 4412, February 2006.
8.2. Informative References 8.2. Informative References
[I-D.ietf-nsis-qspec]
Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC
Template", draft-ietf-nsis-qspec-21 (work in progress),
November 2008.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998. Services", RFC 2475, December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color [RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, September 1999. Marker", RFC 2697, September 1999.
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
Informal Management Model for Diffserv Routers", RFC 3290, J., Courtney, W., Davari, S., Firoiu, V., and D.
May 2002. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 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 [RFC3260] Grossman, D., "New Terminology and Clarifications for
IANA Considerations Section in RFCs", BCP 26, RFC 5226, Diffserv", RFC 3260, April 2002.
May 2008.
Authors' Addresses Authors' Addresses
Jouni Korhonen (editor) Jouni Korhonen (editor)
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Email: jouni.korhonen@nsn.com Email: jouni.korhonen@nsn.com
 End of changes. 56 change blocks. 
260 lines changed or deleted 146 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/