draft-ietf-dime-qos-attributes-09.txt   draft-ietf-dime-qos-attributes-10.txt 
Diameter Maintenance and J. Korhonen Diameter Maintenance and J. Korhonen
Extensions (DIME) H. Tschofenig Extensions (DIME) H. Tschofenig
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Standards Track M. Arumaithurai Intended status: Standards Track M. Arumaithurai
Expires: June 21, 2009 University of Goettingen Expires: July 26, 2009 University of Goettingen
M. Jones, Ed. M. Jones, Ed.
A. Lior A. Lior
Bridgewater Systems Bridgewater Systems
December 18, 2008 January 22, 2009
Quality of Service Attributes for Diameter Quality of Service Attributes for Diameter
draft-ietf-dime-qos-attributes-09.txt draft-ietf-dime-qos-attributes-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 37 skipping to change at page 1, line 37
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 June 21, 2009. This Internet-Draft will expire on July 26, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2008 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. to this document.
Abstract Abstract
skipping to change at page 2, line 19 skipping to change at page 2, line 19
AVP defined in RFC 4005. The ability to convey Quality of Service AVP defined in RFC 4005. The ability to convey Quality of Service
information using the AVPs defined in this document is available to information using the AVPs defined in this document is available to
existing and future Diameter applications where permitted by the existing and future Diameter applications where permitted by the
command ABNF. command ABNF.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Rule Sets and Rules . . . . . . . . . . . . . . . . . . . . . 4 3. Rule Sets and Rules . . . . . . . . . . . . . . . . . . . . . 4
3.1. Rule-Set AVP . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. QoS-Resources AVP . . . . . . . . . . . . . . . . . . . . 4
3.2. Rule AVP . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Rule AVP . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Rule-Precedence AVP . . . . . . . . . . . . . . . . . . . 5
4.1. Traffic Classifiers . . . . . . . . . . . . . . . . . . . 5 4. Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. Classifier AVP . . . . . . . . . . . . . . . . . . . . 7 4.1. Traffic Classifiers . . . . . . . . . . . . . . . . . . . 6
4.1.2. Classifier-ID AVP . . . . . . . . . . . . . . . . . . 8 4.1.1. Classifier AVP . . . . . . . . . . . . . . . . . . . . 8
4.1.3. Protocol AVP . . . . . . . . . . . . . . . . . . . . . 8 4.1.2. Classifier-ID AVP . . . . . . . . . . . . . . . . . . 9
4.1.4. Direction AVP . . . . . . . . . . . . . . . . . . . . 8 4.1.3. Protocol AVP . . . . . . . . . . . . . . . . . . . . . 9
4.1.4. Direction AVP . . . . . . . . . . . . . . . . . . . . 9
4.1.5. From-Spec AVP . . . . . . . . . . . . . . . . . . . . 9 4.1.5. From-Spec AVP . . . . . . . . . . . . . . . . . . . . 9
4.1.6. To-Spec AVP . . . . . . . . . . . . . . . . . . . . . 10 4.1.6. To-Spec AVP . . . . . . . . . . . . . . . . . . . . . 10
4.1.7. Source and Destination AVPs . . . . . . . . . . . . . 11 4.1.7. Source and Destination AVPs . . . . . . . . . . . . . 11
4.1.8. Header Option AVPs . . . . . . . . . . . . . . . . . . 15 4.1.8. Header Option AVPs . . . . . . . . . . . . . . . . . . 15
4.2. Time Of Day AVPs . . . . . . . . . . . . . . . . . . . . . 21 4.2. Time Of Day AVPs . . . . . . . . . . . . . . . . . . . . . 21
4.2.1. Time-Of-Day-Condition AVP . . . . . . . . . . . . . . 21 4.2.1. Time-Of-Day-Condition AVP . . . . . . . . . . . . . . 22
4.2.2. Time-Of-Day-Start AVP . . . . . . . . . . . . . . . . 22 4.2.2. Time-Of-Day-Start AVP . . . . . . . . . . . . . . . . 22
4.2.3. Time-Of-Day-End AVP . . . . . . . . . . . . . . . . . 22 4.2.3. Time-Of-Day-End AVP . . . . . . . . . . . . . . . . . 22
4.2.4. Day-Of-Week-Mask AVP . . . . . . . . . . . . . . . . . 22 4.2.4. Day-Of-Week-Mask AVP . . . . . . . . . . . . . . . . . 22
4.2.5. Day-Of-Month-Mask AVP . . . . . . . . . . . . . . . . 23 4.2.5. Day-Of-Month-Mask AVP . . . . . . . . . . . . . . . . 23
4.2.6. Month-Of-Year-Mask AVP . . . . . . . . . . . . . . . . 23 4.2.6. Month-Of-Year-Mask AVP . . . . . . . . . . . . . . . . 23
4.2.7. Absolute-Start-Time AVP . . . . . . . . . . . . . . . 23 4.2.7. Absolute-Start-Time AVP . . . . . . . . . . . . . . . 24
4.2.8. Absolute-End-Time AVP . . . . . . . . . . . . . . . . 24 4.2.8. Absolute-End-Time AVP . . . . . . . . . . . . . . . . 24
4.2.9. Timezone-Flag AVP . . . . . . . . . . . . . . . . . . 24 4.2.9. Timezone-Flag AVP . . . . . . . . . . . . . . . . . . 24
4.2.10. Timezone-Offset AVP . . . . . . . . . . . . . . . . . 24 4.2.10. Timezone-Offset AVP . . . . . . . . . . . . . . . . . 24
5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.1. Action AVP . . . . . . . . . . . . . . . . . . . . . . . . 24 5.1. Action AVP . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2. Diameter QoS Defined AVPs . . . . . . . . . . . . . . . . 25 5.2. QoS-Profile-Id AVP . . . . . . . . . . . . . . . . . . . . 26
5.2.1. QoS-Profile-Id AVP . . . . . . . . . . . . . . . . . . 25 5.3. QoS-Profile-Template AVP . . . . . . . . . . . . . . . . . 26
5.2.2. QoS-Profile-Template AVP . . . . . . . . . . . . . . . 25 5.4. QoS-Semantics . . . . . . . . . . . . . . . . . . . . . . 26
5.2.3. QoS-Semantics . . . . . . . . . . . . . . . . . . . . 26 5.5. QoS-Parameters AVP . . . . . . . . . . . . . . . . . . . . 27
5.2.4. QoS-Parameters AVP . . . . . . . . . . . . . . . . . . 27 5.6. Excess-Treatment AVP . . . . . . . . . . . . . . . . . . . 27
5.2.5. Rule-Precedence AVP . . . . . . . . . . . . . . . . . 27 5.7. Excess-Treatment-Action . . . . . . . . . . . . . . . . . 28
5.2.6. Excess-Treatment AVP . . . . . . . . . . . . . . . . . 28
5.2.7. Excess-Treatment-Action . . . . . . . . . . . . . . . 28
6. QoS Capability Indication . . . . . . . . . . . . . . . . . . 29 6. QoS Capability Indication . . . . . . . . . . . . . . . . . . 29
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1. Diameter EAP with QoS Information . . . . . . . . . . . . 30 7.1. Diameter EAP with QoS Information . . . . . . . . . . . . 29
7.2. Diameter NASREQ with QoS Information . . . . . . . . . . . 31 7.2. Diameter NASREQ with QoS Information . . . . . . . . . . . 30
7.3. QoS Authorization . . . . . . . . . . . . . . . . . . . . 32 7.3. QoS Authorization . . . . . . . . . . . . . . . . . . . . 31
7.4. Diameter Server Initiated Re-authorization of QoS . . . . 33 7.4. Diameter Server Initiated Re-authorization of QoS . . . . 32
7.5. Diameter Credit Control with QoS Information . . . . . . . 34 7.5. Diameter Credit Control with QoS Information . . . . . . . 33
7.6. Classifier Examples . . . . . . . . . . . . . . . . . . . 35 7.6. Classifier Examples . . . . . . . . . . . . . . . . . . . 34
7.7. QoS Examples . . . . . . . . . . . . . . . . . . . . . . . 35
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 11. Security Considerations . . . . . . . . . . . . . . . . . . . 39
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
12.1. Normative References . . . . . . . . . . . . . . . . . . . 39 12.1. Normative References . . . . . . . . . . . . . . . . . . . 39
12.2. Informative References . . . . . . . . . . . . . . . . . . 40 12.2. Informative References . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
This document defines a number of Diameter Quality of Service (QoS) This document defines a number of Diameter Quality of Service (QoS)
related AVPs that can be used in existing and future Diameter related AVPs that can be used in existing and future Diameter
applications where permitted by the command ABNF. The Rule AVP applications where permitted by the ABNF of a command. The
thereby replaces the IPFilterRule AVP, defined in RFC 3588 [RFC3588], IPFilterRule AVP, defined in RFC 3588 [RFC3588], and the QoS-Filter-
and the QoS-Filter-Rule AVP, defined in RFC 4005 [RFC4005]. Rule AVP, defined in RFC 4005 [RFC4005], provide basic support for
classification and QoS already. The classification rule syntax is a
modified subset of FreeBSD ipfw packet filter implementation. The
QoS functionality provided by the IPFilterRule AVP was updated by the
QoS-Filter-Rule AVP. The Rule AVP offers an extended way of
expressing classification and QoS capabilities.
The structure of a rule in the entire rule set defined in this The structure of a rule in the entire rule set defined in this
document consist of a conditions part and corresponding actions. The document consist of a conditions part and corresponding actions. The
AVPs responsible for expressing a condition are defined in Section 4. AVPs responsible for expressing a condition are defined in Section 4.
Capabilities to match all or a subset of the data traffic is Capabilities to match all or a subset of the data traffic is
provided. Additionally, time-based conditions can be expressed based provided. Additionally, time-based conditions can be expressed based
on the functionality offered in Section 4.2. The action part of a on the functionality offered in Section 4.2. The action part of a
rule contains information for handling conflict resolution, such as a rule contains information for handling conflict resolution, such as a
priority value for each individual rule within a rule set, and priority value for each individual rule within a rule set, and
further description regarding QoS related actions. further description regarding QoS related actions.
2. Terminology 2. Terminology
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Rule Sets and Rules 3. Rule Sets and Rules
As mentioned in the introduction the top-level element is the Rule- As mentioned in the introduction the top-level element is the QoS-
Set AVP that encapsulates one or more Rule AVPs. Resources AVP that encapsulates one or more Rule AVPs.
3.1. Rule-Set AVP 3.1. QoS-Resources AVP
The Rule-Set AVP (AVP Code TBD) is of type Grouped and describes a The QoS-Resources AVP (AVP Code TBD) is of type Grouped and describes
list of policies.. a list of policies.
Rule-Set ::= < AVP Header: XXX > QoS-Resources ::= < AVP Header: XXX >
1*{ Rule } 1*{ Rule }
* [ AVP ] * [ AVP ]
3.2. Rule AVP 3.2. Rule AVP
TheRule AVP (AVP Code TBD) is of type Grouped and defines a specific TheRule AVP (AVP Code TBD) is of type Grouped and defines a specific
condition and action combination. The QoS related actions defined in condition and action combination.
this document therefore one or more traffic flows together with a set
of QoS parameters that should be applied to the flow(s) by the
Resource Management Function.
Rule ::= < AVP Header: XXX > Rule ::= < AVP Header: XXX >
[ Rule-Precedence ]
; Condition part of a Rule ; Condition part of a Rule
; ------------------------ ; ------------------------
[ Classifier ] [ Classifier ]
* [ Time-Of-Day-Condition ] * [ Time-Of-Day-Condition ]
; Action and Meta-Data ; Action and Meta-Data
; -------------------- ; --------------------
[ Action ] [ Action ]
[ Rule-Precedence ]
; Info about QoS related Actions ; Info about QoS related Actions
; ------------------------------ ; ------------------------------
[ QoS-Semantics ] [ QoS-Semantics ]
[ QoS-Profile-Template ] [ QoS-Profile-Template ]
[ QoS-Parameters ] [ QoS-Parameters ]
[ Excess-Treatment ] [ Excess-Treatment ]
; Extension Point ; Extension Point
skipping to change at page 5, line 41 skipping to change at page 5, line 46
If the QoS-Profile-Template AVP is not included in the Rule AVP then If the QoS-Profile-Template AVP is not included in the Rule AVP then
the default setting is assumed, namely a setting of the Vendor-Id AVP the default setting is assumed, namely a setting of the Vendor-Id AVP
to 0 (for IETF) and the QoS-Profile-Id AVP to zero (0) (for the to 0 (for IETF) and the QoS-Profile-Id AVP to zero (0) (for the
profile defined in [I-D.ietf-dime-qos-parameters]). Note that the profile defined in [I-D.ietf-dime-qos-parameters]). Note that the
content of the QoS-Parameters are defined in the respective content of the QoS-Parameters are defined in the respective
specification defining the QoS parameters. When the Vendor-Id AVP is specification defining the QoS parameters. When the Vendor-Id AVP is
set to 0 (for IETF) and the QoS-Profile-Id AVP is set to zero (0) set to 0 (for IETF) and the QoS-Profile-Id AVP is set to zero (0)
then the AVPs included in the QoS-Parameters AVP are the AVPs defined then the AVPs included in the QoS-Parameters AVP are the AVPs defined
in [I-D.ietf-dime-qos-parameters]. in [I-D.ietf-dime-qos-parameters].
3.3. Rule-Precedence AVP
The Rule-Precedence AVP (AVP Code TBD) is of type Unsigned32 and
specifies the execution order of the rules expressed in the QoS-
Resources AVP. Rules with equal precedence MAY be executed in
parallel if supported by the Resource Management Function. If the
Rule-Precedence AVP is absent from the Rule AVP, the rules SHOULD be
executed in the order in which they appear in the QoS-Resources AVP.
The lower the numerical value of Rule-Precedence AVP, the higher the
rule precedence.
4. Conditions 4. Conditions
This section describe the condition part of a rule. This section describes the condition part of a rule. Two condition
types are introduced by this document: packet classification
conditions represented by the Classifier AVP and time of day
conditions represented by the Time-Of-Day-Condition AVP.
If more than one instance of the Time-Of-Day-Condition AVP is present
in the Rule AVP, the current time at QoS rule evaluation MUST be
within at least one of the time windows specified in one of the Time-
Of-Day-Condition AVPs.
When the Time-Of-Day-Condition AVP and Classifier AVP are present in
the same Rule AVP, both the time of day and packet classification
conditions MUST match for the QoS specification action to be applied.
4.1. Traffic Classifiers 4.1. Traffic Classifiers
Classifiers are used in many applications to specify how to select a Classifiers are used in many applications to specify how to select a
subset of data packets for subsequent treatment as indicated in the subset of data packets for subsequent treatment as indicated in the
action part of a rule. For example in a QoS application, if a packet action part of a rule. For example in a QoS application, if a packet
matches a classifier then that packet will be treated in accordance matches a classifier then that packet will be treated in accordance
with a QoS specification associated with that classifier. Figure 1 with a QoS specification associated with that classifier. Figure 1
shows a typical deployment. shows a typical deployment.
skipping to change at page 7, line 7 skipping to change at page 7, line 50
In general a Classifier consists of the following: In general a Classifier consists of the following:
Identifier: Identifier:
The identifier uniquely identifies this classifier and may be used The identifier uniquely identifies this classifier and may be used
to reference the classifier from another structure. to reference the classifier from another structure.
From: From:
Specifies the rule for matching the source part of the packet. Specifies the rule for matching the protocol specific source
address(es) part of the packet.
To: To:
Specifies the rule for matching the destination part of the Specifies the rule for matching the protocol specific destination
packet. address(es) part of the packet.
Protocol: Protocol:
Specifies the matching protocol of the packet. Specifies the matching protocol of the packet.
Direction: Direction:
Specifies whether the classifier is to apply to packets flowing Specifies whether the classifier is to apply to packets flowing
from the Managed Terminal (IN) or to packets flowing to the from the Managed Terminal (IN) or to packets flowing to the
Managed Terminal (OUT), or packets flowing in both direction. Managed Terminal (OUT), or packets flowing in both direction.
Options: Options:
Associated with each protocol or layer, or various values specific Attributes or properties associated with each protocol or layer,
to the header of the protocol or layer. Options allow matching on or various values specific to the header of the protocol or layer.
those values. Options allow matching on those values.
Each protocol type will have a specific set of attributes that can be Each protocol type will have a specific set of attributes that can be
used to specify a classifier for that protocol. These attributes used to specify a classifier for that protocol. These attributes
will be grouped under a grouped AVP called a Classifier AVP. will be grouped under a grouped AVP called a Classifier AVP.
4.1.1. Classifier AVP 4.1.1. Classifier AVP
The Classifier AVP (AVP Code TBD) is a grouped AVP that consists of a The Classifier AVP (AVP Code TBD) is a grouped AVP that consists of a
set of attributes that specify how to match a packet. set of attributes that specify how to match a packet.
Classifier ::= < AVP Header: XXX > Classifier ::= < AVP Header: XXX >
{ Classifier-ID } { Classifier-ID }
{ Protocol } [ Protocol ]
{ Direction } [ Direction ]
* [ From-Spec ] * [ From-Spec ]
* [ To-Spec ] * [ To-Spec ]
* [ Diffserv-Code-Point ] * [ Diffserv-Code-Point ]
[ Fragmentation-Flag ] [ Fragmentation-Flag ]
* [ IP-Option ] * [ IP-Option ]
* [ TCP-Option ] * [ TCP-Option ]
[ TCP-Flags ] [ TCP-Flags ]
* [ ICMP-Type ] * [ ICMP-Type ]
* [ ETH-Option ] * [ ETH-Option ]
* [ AVP ] * [ AVP ]
skipping to change at page 8, line 32 skipping to change at page 9, line 17
The Classifier-ID AVP (AVP Code TBD) is of type OctetString and The Classifier-ID AVP (AVP Code TBD) is of type OctetString and
uniquely identifies the classifier. Each application will define the uniquely identifies the classifier. Each application will define the
uniqueness scope of this identifier, e.g. unique per terminal or uniqueness scope of this identifier, e.g. unique per terminal or
globally unique. Exactly one Classifier-ID AVP MUST be contained globally unique. Exactly one Classifier-ID AVP MUST be contained
within a Classifier AVP. within a Classifier AVP.
4.1.3. Protocol AVP 4.1.3. Protocol AVP
The Protocol AVP (AVP Code TBD) is of type Enumerated and specifies The Protocol AVP (AVP Code TBD) is of type Enumerated and specifies
the protocol being matched. The attributes included in the the protocol being matched. The attributes included in the
Classifier AVP must be consistent with the value of the Protocol AVP. Classifier AVP MUST be consistent with the value of the Protocol AVP.
Exactly one Protocol AVP MUST be contained within a Classifier AVP. Exactly zero or one Protocol AVP may be contained within a Classifier
The values for this AVP are managed by IANA under the Protocol AVP. If the Protocol AVP is omitted from the Classifier, then
Numbers registry [PROTOCOL]. comparison of the protocol of the packet is irrelevant. The values
for this AVP are managed by IANA under the Protocol Numbers registry
[PROTOCOL].
4.1.4. Direction AVP 4.1.4. Direction AVP
The Direction AVP (AVP Code TBD) is of type Enumerated that specifies The Direction AVP (AVP Code TBD) is of type Enumerated and specifies
in which direction to apply the Classifier. The values of the in which direction to apply the Classifier. The values of the
enumeration are: "IN","OUT","BOTH". In the "IN" and "BOTH" enumeration are: "IN","OUT","BOTH". In the "IN" and "BOTH"
directions, the From-Spec refers to the address of the Managed directions, the From-Spec refers to the address of the Managed
Terminal and the To-Spec refers to the unmanaged terminal. In the Terminal and the To-Spec refers to the unmanaged terminal. In the
"OUT" direction, the From-Spec refers to the Unmanaged Terminal "OUT" direction, the From-Spec refers to the Unmanaged Terminal
whereas the To-Spec refers to the Managed Terminal. whereas the To-Spec refers to the Managed Terminal. If the Direction
AVP is omitted, the Classifier matches packets flowing in both
direction.
Value | Name and Semantic Value | Name and Semantic
------+-------------------------------------------------- ------+--------------------------------------------------
0 | RESERVED 0 | IN - The classifier applies to flows from the
1 | IN - The classifier applies to flows from the
| Managed Terminal. | Managed Terminal.
2 | OUT - The classifier applies to flows to the 1 | OUT - The classifier applies to flows to the
| Managed Terminal. | Managed Terminal.
3 | BOTH - The classifier applies to flows both to 2 | BOTH - The classifier applies to flows both to
| and from the Managed Terminal. | and from the Managed Terminal.
4.1.5. From-Spec AVP 4.1.5. From-Spec AVP
The From-Spec AVP (AVP Code TBD) is a grouped AVP that specifies the The From-Spec AVP (AVP Code TBD) is a grouped AVP that specifies the
Source Specification used to match the packet. Zero or more of these Source Specification used to match the packet. Zero or more of these
AVPs may appear in the Classifier. If this AVP is absent from the AVPs may appear in the Classifier. If this AVP is absent from the
Classifier then all packets are matched regardless of the source Classifier then all packets are matched regardless of the source
address. If more than one instance of this AVP appears in the address. If more than one instance of this AVP appears in the
Classifier then the source of the packet can match any From-Spec AVP. Classifier then the source of the packet can match any From-Spec AVP.
The contents of this AVP are protocol specific. The contents of this AVP are protocol specific.
If more than one instance of the IP address AVPs (IP-Address, IP- If one instance (or multiple instances) of the IP address AVP (IP-
Address-Range, IP-Address-Mask, Use-Assigned-Address) appear in the Address, IP-Address-Range, IP-Address-Mask, Use-Assigned-Address)
From-Spec AVP then the source IP address of the packet must match one appear in the From-Spec AVP then the source IP address of the packet
of the addresses represented by these AVPs. MUST match one of the addresses represented by these AVPs.
If more that one instance of the layer 2 address AVPs (MAC-Address, If more that one instance of the layer 2 address AVPs (MAC-Address,
MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) appears in the MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) appears in the
From-Spec then the the source layer 2 address of the packet must From-Spec then the the source layer 2 address of the packet MUST
match one of the addresses represented in these AVPs. match one of the addresses represented in these AVPs.
If more that one instance of the port AVPs (Port, Port-Range) appears If more that one instance of the port AVPs (Port, Port-Range) appears
in the From-Spec AVP then the source port number must match one of in the From-Spec AVP then the source port number MUST match one of
the port numbers represented in these AVPs. the port numbers represented in these AVPs.
If the IP address, MAC address and port AVPs appear in the same From- If the IP address, MAC address and port AVPs appear in the same From-
Spec AVP then the source packet must match all the specifications, Spec AVP then the source packet MUST match all the specifications,
i.e. match the IP address AND MAC address AND port number. i.e. match the IP address AND MAC address AND port number.
From-Spec ::= < AVP Header: XXX > From-Spec ::= < AVP Header: XXX >
* [ IP-Address ] * [ IP-Address ]
* [ IP-Address-Range ] * [ IP-Address-Range ]
* [ IP-Address-Mask ] * [ IP-Address-Mask ]
* [ MAC-Address ] * [ MAC-Address ]
* [ MAC-Address-Mask] * [ MAC-Address-Mask]
* [ EUI64-Address ] * [ EUI64-Address ]
* [ EUI64-Address-Mask] * [ EUI64-Address-Mask]
skipping to change at page 10, line 29 skipping to change at page 10, line 49
4.1.6. To-Spec AVP 4.1.6. To-Spec AVP
The To-Spec AVP (AVP Code TBD) is a grouped AVP that specifies the The To-Spec AVP (AVP Code TBD) is a grouped AVP that specifies the
Destination Specification used to match the packet. Zero or more of Destination Specification used to match the packet. Zero or more of
these AVPs may appear in the Classifier. If this AVP is absent from these AVPs may appear in the Classifier. If this AVP is absent from
the Classifier then all packets are matched regardless of the the Classifier then all packets are matched regardless of the
destination address. If more than one instance of this AVP appears destination address. If more than one instance of this AVP appears
in the Classifier then the destination of the packet can match any in the Classifier then the destination of the packet can match any
To-Spec AVP. The contents of this AVP are protocol specific. To-Spec AVP. The contents of this AVP are protocol specific.
If more than one instance of the IP address AVPs (IP-Address, IP- If one instance (or multiple instances) of the IP address AVP (IP-
Address-Range, IP-Address-Mask, Use-Assigned-Address) appear in the Address, IP-Address-Range, IP-Address-Mask, Use-Assigned-Address)
To-Spec AVP then the destination IP address of the packet must match appear in the To-Spec AVP then the destination IP address of the
one of the addresses represented by these AVPs. packet MUST match one of the addresses represented by these AVPs.
If more that one instance of the layer 2 address AVPs (MAC-Address, If more that one instance of the layer 2 address AVPs (MAC-Address,
MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) appears in the MAC-Address-Mask, EUI64-Address, EUI64-Address-Mask) appears in the
To-Spec then the the destination layer 2 address of the packet must To-Spec then the the destination layer 2 address of the packet MUST
match one of the addresses represented in these AVPs. match one of the addresses represented in these AVPs.
If more that one instance of the port AVPs (Port, Port-Range) appears If more that one instance of the port AVPs (Port, Port-Range) appears
in the To-Spec AVP then the destination port number must match one of in the To-Spec AVP then the destination port number MUST match one of
the port numbers represented in these AVPs. the port numbers represented in these AVPs.
If the IP address, MAC address and port AVPs appear in the same To- If the IP address, MAC address and port AVPs appear in the same To-
Spec AVP then the destination packet must match all the Spec AVP then the destination packet MUST match all the
specifications, i.e. match the IP address AND MAC address AND port specifications, i.e. match the IP address AND MAC address AND port
number. number.
To-Spec ::= < AVP Header: XXX > To-Spec ::= < AVP Header: XXX >
* [ IP-Address ] * [ IP-Address ]
* [ IP-Address-Range ] * [ IP-Address-Range ]
* [ IP-Address-Mask ] * [ IP-Address-Mask ]
* [ MAC-Address ] * [ MAC-Address ]
* [ MAC-Address-Mask] * [ MAC-Address-Mask]
* [ EUI64-Address ] * [ EUI64-Address ]
* [ EUI64-Address-Mask] * [ EUI64-Address-Mask]
* [ Port ] * [ Port ]
* [ Port-Range ] * [ Port-Range ]
[ Negated ] [ Negated ]
[ Use-Assigned-Address ] [ Use-Assigned-Address ]
* [ AVP ] * [ AVP ]
4.1.7. Source and Destination AVPs 4.1.7. Source and Destination AVPs
For packet classification the contents of the From-Spec and To-Spec For packet classification the contents of the From-Spec and To-Spec
can contain the following AVPs. can contain the AVPs listed in the subsections below.
By combining several of these AVPs within a From-Spec or To-Spec AVP
and using more than one From-Spec or To-Spec AVP in the Classifier
AVP, one can express many different types of address pools.
4.1.7.1. Negated AVP 4.1.7.1. Negated AVP
The Negated AVP (AVP Code TBD) of type Enumerated containing the The Negated AVP (AVP Code TBD) of type Enumerated containing the
values of True or False. Exactly zero or one of these AVPs may values of True or False. Exactly zero or one of these AVPs may
appear in the From-Spec or To-Spec AVP. When set to True the meaning appear in the From-Spec or To-Spec AVP.
of the match in the To-Spec and From-Spec are negated, causing all
other addresses to be matched instead.
When set to False, or when the AVP is not included in the From-Spec When set to True the meaning of the match is inverted. Addresses
or To-Spec AVP then the meaning of the match is not inverted, causing other than those in the To-Spec and From-Spec are to be matched
only the addresses specified to be matched. instead. When set to False, or when the AVP is not included then the
address specified To-Spec and From-Spec AVP are to be matched.
Note that the negation does not impact the port comparisons. Note that the negation does not impact the port comparisons.
Value | Name Value | Name
------+-------- ------+--------
0 | False 0 | False
1 | True 1 | True
4.1.7.2. IP-Address AVP 4.1.7.2. IP-Address AVP
skipping to change at page 12, line 27 skipping to change at page 12, line 39
specified IP-Address-End address. specified IP-Address-End address.
If the IP-Address-End AVP is not included then the address range If the IP-Address-End AVP is not included then the address range
starts at the address specified by the IP-Address-Start AVP and starts at the address specified by the IP-Address-Start AVP and
includes all the remaining valid IP addresses. includes all the remaining valid IP addresses.
For the IP-Address-Range AVP to be valid, the IP-Address-Start AVP For the IP-Address-Range AVP to be valid, the IP-Address-Start AVP
MUST contain a value that is less than that of the IP-Address-End MUST contain a value that is less than that of the IP-Address-End
AVP. AVP.
If the IP-Address-Start AVP is empty then the semantic is equivalent
to not having the IP-Address-Start AVP included in the command.
4.1.7.4. IP-Address-Start AVP 4.1.7.4. IP-Address-Start AVP
The IP-Address-Start AVP (AVP Code TBD) is of type Address and The IP-Address-Start AVP (AVP Code TBD) is of type Address and
specifies the first IP address (IPv4 or IPv6) address of an IP specifies the first IP address (IPv4 or IPv6) address of an IP
address range. address range.
4.1.7.5. IP-Address-End AVP 4.1.7.5. IP-Address-End AVP
The IP-Address-End AVP (AVP Code TBD) is of type Address and The IP-Address-End AVP (AVP Code TBD) is of type Address and
specifies the last IP address (IPv4 or IPv6) address of an address specifies the last IP address (IPv4 or IPv6) address of an address
skipping to change at page 13, line 7 skipping to change at page 13, line 26
match all IP addresses from 1.2.3.0 up to and including 1.2.3.255. match all IP addresses from 1.2.3.0 up to and including 1.2.3.255.
The bit-width MUST be valid for the type of IP address. The bit-width MUST be valid for the type of IP address.
IP-Address-Mask ::= < AVP Header: XXX > IP-Address-Mask ::= < AVP Header: XXX >
{ IP-Address } { IP-Address }
{ IP-Bit-Mask-Width } { IP-Bit-Mask-Width }
* [ AVP ] * [ AVP ]
4.1.7.7. IP-Mask-Bit-Mask-Width AVP 4.1.7.7. IP-Mask-Bit-Mask-Width AVP
The IP-Bit-Mask-Width AVP (AVP Code TBD) is of type OctetString. The The IP-Bit-Mask-Width AVP (AVP Code TBD) is of type Unsigned32. The
value is a single octet and specifies the width of an IP address bit- value specifies the width of an IP address bit-mask.
mask.
4.1.7.8. MAC-Address AVP 4.1.7.8. MAC-Address AVP
The MAC-Address AVP (AVP Code TBD) is of type OctetString and The MAC-Address AVP (AVP Code TBD) is of type OctetString and
specifies a single layer 2 address in MAC-48 format. The value is a specifies a single layer 2 address in MAC-48 format. The value is a
6 octets encoding of the address as it would appear in the frame 6 octets encoding of the address as it would appear in the frame
header. header.
4.1.7.9. MAC-Address-Mask AVP 4.1.7.9. MAC-Address-Mask AVP
skipping to change at page 14, line 22 skipping to change at page 14, line 43
4.1.7.13. EUI64-Address-Mask-Pattern AVP 4.1.7.13. EUI64-Address-Mask-Pattern AVP
The EUI64-Address-Mask-Pattern AVP (AVP Code TBD) is of type The EUI64-Address-Mask-Pattern AVP (AVP Code TBD) is of type
OctetString. The value is a 8 octets specifying the bit positions of OctetString. The value is a 8 octets specifying the bit positions of
a EUI64 address, that are taken for matching. a EUI64 address, that are taken for matching.
4.1.7.14. Port AVP 4.1.7.14. Port AVP
The Port AVP (AVP Code TBD) is of type Integer32 in the range of 0 to The Port AVP (AVP Code TBD) is of type Integer32 in the range of 0 to
65535 and specifies the TCP or UDP port number to match. 65535 and specifies port numbers to match.
4.1.7.15. Port-Range AVP 4.1.7.15. Port-Range AVP
The Port-Range AVP (AVP Code TBD) is of type Grouped and specifies an The Port-Range AVP (AVP Code TBD) is of type Grouped and specifies an
inclusive range of ports. inclusive range of ports.
Port-Range ::= < AVP Header: XXX > Port-Range ::= < AVP Header: XXX >
[ Port-Start ] [ Port-Start ]
[ Port-End ] [ Port-End ]
* [ AVP ] * [ AVP ]
If the Port-Start AVP is omitted then port 0 is assumed. If the If the Port-Start AVP is omitted then port 0 is assumed. If the
Port-End AVP is omitted then port 65535 is assumed. Port-End AVP is omitted then port 65535 is assumed.
If the Port-Start AVP is empty then this is equivalent to not
carrying a Port-Start AVP in the command.
4.1.7.16. Port-Start AVP 4.1.7.16. Port-Start AVP
The Port-Start AVP (AVP Code TBD) is of type Integer32 and specifies The Port-Start AVP (AVP Code TBD) is of type Integer32 and specifies
the first port number of an IP port range. the first port number of an IP port range.
4.1.7.17. Port-End AVP 4.1.7.17. Port-End AVP
The Port-End AVP (AVP Code TBD) is of type Integer32 and specifies The Port-End AVP (AVP Code TBD) is of type Integer32 and specifies
the last port number of an IP port range. the last port number of an IP port range.
skipping to change at page 15, line 33 skipping to change at page 16, line 12
the IP header. The values are managed by IANA under the the IP header. The values are managed by IANA under the
Differentiated Services Field Codepoints registry [DSCP]. Differentiated Services Field Codepoints registry [DSCP].
4.1.8.2. Fragmentation-Flag AVP 4.1.8.2. Fragmentation-Flag AVP
The Fragmentation-Flag AVP (AVP Code TBD) is of type Enumerated and The Fragmentation-Flag AVP (AVP Code TBD) is of type Enumerated and
specifies the packet fragmentation flags to match in the IP header. specifies the packet fragmentation flags to match in the IP header.
Value | Name and Semantic Value | Name and Semantic
------+------------------------------------------------------------ ------+------------------------------------------------------------
0 | RESERVED 0 | Don't Fragment (DF)
1 | Don't Fragment (DF) 1 | More Fragments (MF)
2 | More Fragments (MF)
4.1.8.3. IP-Option AVP 4.1.8.3. IP-Option AVP
The IP-Option AVP (AVP Code TBD) is of type Grouped and specifies an The IP-Option AVP (AVP Code TBD) is of type Grouped and specifies an
IP header option that must be matched. IP header option that must be matched.
IP-Option ::= < AVP Header: XXX > IP-Option ::= < AVP Header: XXX >
{ IP-Option-Type } { IP-Option-Type }
* [ IP-Option-Value ] * [ IP-Option-Value ]
[ Negated ] [ Negated ]
skipping to change at page 17, line 20 skipping to change at page 17, line 42
4.1.8.9. TCP-Flags AVP 4.1.8.9. TCP-Flags AVP
The TCP-Flags AVP (AVP Code TBD) is of type Grouped and specifies a The TCP-Flags AVP (AVP Code TBD) is of type Grouped and specifies a
set of TCP control flags that must be matched. set of TCP control flags that must be matched.
TCP-Flags ::= < AVP Header: XXX > TCP-Flags ::= < AVP Header: XXX >
1* { TCP-Flag-Type } 1* { TCP-Flag-Type }
[ Negated ] [ Negated ]
* [ AVP ] * [ AVP ]
If the Negated AVP is not present, the TCP-Flag-Type AVPs specifies If the Negated AVP is not present or present but set to False, the
which flags MUST be set. If the Negated AVP is present, the TCP- TCP-Flag-Type AVPs specifies which flags MUST be set. If the Negated
Flag-Type AVPs specifies which flags MUST be cleared. AVP is set to True, the TCP-Flag-Type AVPs specifies which flags MUST
be cleared.
4.1.8.10. TCP-Flag-Type AVP 4.1.8.10. TCP-Flag-Type AVP
The TCP-Flag-Type AVP (AVP Code TBD) is of type Enumerated and The TCP-Flag-Type AVP (AVP Code TBD) is of type Enumerated and
specifies a TCP control flag type that must be matched. specifies a TCP control flag type that must be matched.
Value | Name and Semantic Value | Name and Semantic
------+------------------------------------------------------------ ------+-------------------------------------------
0 | RESERVED 0 | CWR - Congestion Window Reduced.
1 | CWR - Congestion Window Reduced. 1 | ECE - ECN-Echo. TCP peer is ECN capable.
2 | ECE - ECN-Echo. TCP peer is ECN capable. 2 | URG - URGent pointer field is significant.
3 | URG - URGent pointer field is significant. 3 | ACK - ACKnowledgment field is significant.
4 | ACK - ACKnowledgment field is significant. 4 | PSH - Push function.
5 | PSH - Push function. 5 | RST - Reset the connection.
6 | RST - Reset the connection. 6 | SYN - Synchronize sequence numbers.
7 | SYN - Synchronize sequence numbers. 7 | FIN - No more data from sender.
8 | FIN - No more data from sender.
4.1.8.11. ICMP-Type 4.1.8.11. ICMP-Type
The ICMP-Type AVP (AVP Code TBD) is of type Grouped and specifies a The ICMP-Type AVP (AVP Code TBD) is of type Grouped and specifies a
ICMP message type that must be matched. ICMP message type that must be matched.
ICMP-Type ::= < AVP Header: XXX > ICMP-Type ::= < AVP Header: XXX >
{ ICMP-Type-Number } { ICMP-Type-Number }
* [ ICMP-Code ] * [ ICMP-Code ]
[ Negated ] [ Negated ]
* [ AVP ] * [ AVP ]
If the ICMP-Code AVP is present, the value MUST match that in the If the ICMP-Code AVP is present, the value MUST match that in the
ICMP header. If the ICMP-Code AVP is absent, the ICMP type MUST be ICMP header. If the ICMP-Code AVP is absent, the ICMP type MUST be
present in the ICMP header but the code is wild carded. present in the ICMP header but the code is wild carded.
The Negated AVP is used in conjunction which the ICMP-Code AVPs to The Negated AVP is used in conjunction with the ICMP-Code AVPs to
specify ICMP codes which do not match specific values. The Negated specify ICMP codes that do not match specific values. The Negated
AVP is used without the ICMP-Code AVP to specify ICMP headers which AVP is used without the ICMP-Code AVP to specify ICMP headers which
do not contain the ICMP type. do not contain the ICMP type. As such, the Negated AVP feature
applies to ICMP-Code AVP if the ICMP-Code AVP is present. If the
ICMP-Code AVP is absent, the Negated AVP feature applies to the ICMP-
Type-Number.
4.1.8.12. ICMP-Type-Number AVP 4.1.8.12. ICMP-Type-Number AVP
The ICMP-Type-Number AVP (AVP Code TBD) is of type Enumerated and the The ICMP-Type-Number AVP (AVP Code TBD) is of type Enumerated and the
values are managed by IANA under the ICMP Type Numbers registry values are managed by IANA under the ICMP Type Numbers registry
[ICMPTYPE]. [ICMPTYPE].
4.1.8.13. ICMP-Code AVP 4.1.8.13. ICMP-Code AVP
The ICMP-Code AVP (AVP Code TBD) is of type Enumerated and the values The ICMP-Code AVP (AVP Code TBD) is of type Enumerated and the values
skipping to change at page 21, line 44 skipping to change at page 22, line 21
[ Time-Of-Day-Start ] [ Time-Of-Day-Start ]
[ Time-Of-Day-End ] [ Time-Of-Day-End ]
[ Day-Of-Week-Mask ] [ Day-Of-Week-Mask ]
[ Day-Of-Month-Mask ] [ Day-Of-Month-Mask ]
[ Month-Of-Year-Mask ] [ Month-Of-Year-Mask ]
[ Absolute-Start-Time ] [ Absolute-Start-Time ]
[ Absolute-End-Time ] [ Absolute-End-Time ]
[ Timezone-Flag ] [ Timezone-Flag ]
* [ AVP ] * [ AVP ]
If more than one instance of this AVP is present in the Rule AVP, the
current time at QoS rule evaluation MUST be within at least one of
the time windows specified in one of the Time-Of-Day-Condition AVPs.
When the Time-Of-Day-Condition AVP and Classifier AVP are present in
the same Rule AVP, both the time of day and packet classification
conditions MUST match for the QoS specification to be applied.
For example, a time window for 9am to 5pm (local time) from Monday to For example, a time window for 9am to 5pm (local time) from Monday to
Friday would be expressed as: Friday would be expressed as:
Time-Of-Day-Condition = { Time-Of-Day-Condition = {
Time-Of-Day-Start = 32400; Time-Of-Day-Start = 32400;
Time-Of-Day-End = 61200; Time-Of-Day-End = 61200;
Day-Of-Week-Mask = Day-Of-Week-Mask =
( MONDAY | TUESDAY | WEDNESDAY | THURSDAY | FRIDAY ); ( MONDAY | TUESDAY | WEDNESDAY | THURSDAY | FRIDAY );
Timezone-Flag = LOCAL; Timezone-Flag = LOCAL;
} }
skipping to change at page 24, line 24 skipping to change at page 24, line 38
The Timezone-Flag AVP (AVP Code TBD) is of type Enumerated and The Timezone-Flag AVP (AVP Code TBD) is of type Enumerated and
indicates whether the time windows are specified in UTC, local time indicates whether the time windows are specified in UTC, local time
at the managed terminal or as an offset from UTC. If this AVP is at the managed terminal or as an offset from UTC. If this AVP is
absent from the Time-Of-Day-Condition AVP, the time windows are in absent from the Time-Of-Day-Condition AVP, the time windows are in
UTC. UTC.
This document defines the following values: This document defines the following values:
Value | Name and Semantic Value | Name and Semantic
------+-------------------------------------------------- ------+--------------------------------------------------
0 | RESERVED 0 | UTC - The time windows are expressed in UTC.
1 | UTC - The time windows are expressed in UTC. 1 | LOCAL - The time windows are expressed in local
2 | LOCAL - The time windows are expressed in local
| time at the Managed Terminal. | time at the Managed Terminal.
3 | OFFSET - The time windows are expressed as an 2 | OFFSET - The time windows are expressed as an
| offset from UTC (see Timezone-Offset AVP). | offset from UTC (see Timezone-Offset AVP).
4.2.10. Timezone-Offset AVP 4.2.10. Timezone-Offset AVP
The Timezone-Offset AVP (AVP Code TBD) is of type Integer32. The The Timezone-Offset AVP (AVP Code TBD) is of type Integer32. The
value of this AVP MUST be in the range from -43200 to 43200. It value of this AVP MUST be in the range from -43200 to 43200. It
specifies the offset in seconds from UTC that was used to express specifies the offset in seconds from UTC that was used to express
Time-Of-Day-Start, Time-Of-Day-End, Day-Of-Week-Mask, Day-Of-Month- Time-Of-Day-Start, Time-Of-Day-End, Day-Of-Week-Mask, Day-Of-Month-
Mask and Month-Of-Year-Mask AVPs. This AVP MUST be present if the Mask and Month-Of-Year-Mask AVPs. This AVP MUST be present if the
Timezone-Flag AVP is set to OFFSET. Timezone-Flag AVP is set to OFFSET.
skipping to change at page 25, line 7 skipping to change at page 25, line 19
specified as extensions. specified as extensions.
5.1. Action AVP 5.1. Action AVP
The Action AVP (AVP Code TBD) is of type Enumerated and lists the The Action AVP (AVP Code TBD) is of type Enumerated and lists the
actions that are associated with the condition part of a rule. The actions that are associated with the condition part of a rule. The
following actions are defined in this document: following actions are defined in this document:
0: drop 0: drop
1: shape 1: shape
2: police
2: mark 2: mark
drop: drop:
All traffic that is met by the condition part of a rule MUST be All traffic that is met by the condition part of a rule MUST be
dropped. dropped. This action implements firewalling functionality.
shape: shape:
When the action is set to 'shape', it is expected that the QoS- [RFC2475] describes shaping as "the process of delaying packets
Parameters AVP carries QoS information to indicate how to shape within a traffic stream to cause it to conform to some defined
the traffic indicated in the condition part of the rule. traffic profile.". When the action is set to 'shape', it is
expected that the QoS-Parameters AVP carries QoS information to
indicate how to shape the traffic indicated in the condition part
of the rule.
police:
[RFC2475] describes policing as " the process of discarding
packets (by a dropper) within a traffic stream in accordance with
the state of a corresponding meter enforcing a traffic profile.".
When the action is set to 'police', it is expected that the QoS-
Parameters AVP carries QoS information to describe traffic
conforming to a traffic profile. Excess traffic is dropped.
Hence, there is no need to include the Excess-Treatement AVP with
the Excess-Treatment-Action AVP set to 'drop' as this
functionality is implied.
mark: mark:
xref target="RFC2475"/> describes marking as " the process of
setting the DS codepoint in a packet based on defined rules;".
When the action is set to 'mark', it is expected that the QoS- When the action is set to 'mark', it is expected that the QoS-
Parameters AVP carries information about the QoS class. Parameters AVP carries information about the DiffServ marking.
Further action values can be registered, as described in Further action values can be registered, as described in
Section 10.4. Section 10.4.
5.2. Diameter QoS Defined AVPs 5.2. QoS-Profile-Id AVP
5.2.1. QoS-Profile-Id AVP
The QoS-Profile-Id AVP (AVP Code TBD) is of type Unsigned32 and The QoS-Profile-Id AVP (AVP Code TBD) is of type Unsigned32 and
contains a QoS profile template identifier. An initial QoS profile contains a QoS profile template identifier. An initial QoS profile
template is defined with value of 0 and can be found in template is defined with value of 0 and can be found in
[I-D.ietf-dime-qos-parameters]. The registry for the QoS profile [I-D.ietf-dime-qos-parameters]. The registry for the QoS profile
templates is created with the same document. templates is created with the same document.
5.2.2. QoS-Profile-Template AVP 5.3. QoS-Profile-Template AVP
The QoS-Profile-Template AVP (AVP Code TBD) is of type Grouped and The QoS-Profile-Template AVP (AVP Code TBD) is of type Grouped and
defines the namespace of the QoS profile (indicated in the Vendor-ID defines the namespace of the QoS profile (indicated in the Vendor-ID
AVP) followed by the specific value for the profile. AVP) followed by the specific value for the profile.
The Vendor-Id AVP contains a 32 bit IANA SMI Network Management The Vendor-Id AVP contains a 32 bit IANA SMI Network Management
Private Enterprise Code and the QoS-Profile-Id AVP contains the Private Enterprise Code and the QoS-Profile-Id AVP contains the
template identifier assigned by the vendor. The vendor identifier of template identifier assigned by the vendor. The vendor identifier of
zero (0) is used for the IETF. zero (0) is used for the IETF.
QoS-Profile-Template ::= < AVP Header: XXX > QoS-Profile-Template ::= < AVP Header: XXX >
{ Vendor-Id } { Vendor-Id }
{ QoS-Profile-Id } { QoS-Profile-Id }
* [ AVP ] * [ AVP ]
5.2.3. QoS-Semantics 5.4. QoS-Semantics
The QoS-Semantics AVP (AVP Code TBD) is of type Enumerated and The QoS-Semantics AVP (AVP Code TBD) is of type Enumerated and
provides the semantics for the QoS-Profile-Template and QoS- provides the semantics for the QoS-Profile-Template and QoS-
Parameters AVPs in the Rule AVP. Parameters AVPs in the Rule AVP.
This document defines the following values: This document defines the following values:
(0): QoS-Desired (0): QoS-Desired
(1): QoS-Available (1): QoS-Available
(2): QoS-Reserved (2): QoS-Reserved
skipping to change at page 27, line 36 skipping to change at page 27, line 36
NA: Not applicable to this document; NA: Not applicable to this document;
no semantic defined in this specification no semantic defined in this specification
Notes: Notes:
(1) QoS-Available is only useful in relationship with QoS-Desired (1) QoS-Available is only useful in relationship with QoS-Desired
(and optionally with Minimum-QoS). (and optionally with Minimum-QoS).
(2) QoS-Available is only useful when the AAA server performs (2) QoS-Available is only useful when the AAA server performs
admission control and knows about the resources in the network. admission control and knows about the resources in the network.
5.2.4. QoS-Parameters AVP 5.5. QoS-Parameters AVP
The QoS-Parameters AVP (AVP Code TBD) is of type grouped and contains The QoS-Parameters AVP (AVP Code TBD) is of type grouped and contains
Quality of Service parameters. These parameters are defined in Quality of Service parameters. These parameters are defined in
separate documents and depend on the indicated QoS profile template separate documents and depend on the indicated QoS profile template
of the QoS-Profile-Template AVP. For an initial QoS parameter of the QoS-Profile-Template AVP. For an initial QoS parameter
specification see [I-D.ietf-dime-qos-parameters]. specification see [I-D.ietf-dime-qos-parameters].
QoS-Parameters ::= < AVP Header: XXX > QoS-Parameters ::= < AVP Header: XXX >
* [ AVP ] * [ AVP ]
5.2.5. Rule-Precedence AVP 5.6. Excess-Treatment AVP
The Rule-Precedence AVP (AVP Code TBD) is of type Unsigned32 and
specifies the execution order of the rules expressed in the Rule-Set
AVP. Rules with equal precedence MAY be executed in parallel if
supported by the Resource Management Function. If the Rule-
Precedence AVP is absent from the Rule AVP, the rules SHOULD be
executed in the order in which they appear in the Rule-Set AVP. The
lower the numerical value of Rule-Precedence AVP, the higher the rule
precedence.
5.2.6. Excess-Treatment AVP
The Excess-Treatment AVP (AVP Code TBD) is of type grouped and The Excess-Treatment AVP (AVP Code TBD) is of type grouped and
indicates how out-of- profile traffic, that is, traffic not covered indicates how out-of-profile traffic, i.e. traffic not covered by the
by the original QoS-Profile-Template and QoS-Parameters AVPs. The original QoS-Profile-Template and QoS-Parameters AVPs, is treated.
additional QoS-Profile-Template and QoS-Parameters AVPs carried
The additional QoS-Profile-Template and QoS-Parameters AVPs carried
inside the Excess-Treatment AVP provide information about the QoS inside the Excess-Treatment AVP provide information about the QoS
treatment of the excess traffic. treatment of the excess traffic. In case the Excess-Treatment AVP is
absent then the treatment of the out-of-profile traffic is left to
the discretion of the node performing QoS treatment.
Excess-Treatment ::= < AVP Header: XXX > Excess-Treatment ::= < AVP Header: XXX >
{ Excess-Treatment-Action } { Excess-Treatment-Action }
[ QoS-Profile-Template ] [ QoS-Profile-Template ]
[ QoS-Parameters ] [ QoS-Parameters ]
* [ AVP ] * [ AVP ]
5.2.7. Excess-Treatment-Action 5.7. Excess-Treatment-Action
The Excess-Treatment-Action AVP (AVP Code TBD) is of type Enumerated The Excess-Treatment-Action AVP (AVP Code TBD) is of type Enumerated
and lists the actions about how the out-of-traffic regarding a and lists the actions about how the out-of-traffic regarding a
specific QoS profile is treated. specific QoS profile is treated.
0: drop 0: drop
1: shape 1: shape
2: remark 2: mark
3: no metering or policing is permitted
drop: drop:
When excess treatment action is set to 'drop', all marked traffic When excess treatment action is set to 'drop', excess traffic is
MUST be dropped by a QoS aware node. dropped.
shape: shape:
When excess treatment action is set to 'shape', it is expected When excess treatment action is set to 'shape', it is expected
that the QoS-Parameters AVP carries QoS information to what QoS that the QoS-Parameters AVP carries information on how to shape
parameter to re-shape the traffic. An example would be to use the the excess traffic. For example, the TMOD AVP, defined in
TMOD parameter defined in [I-D.ietf-dime-qos-parameters] and the [I-D.ietf-dime-qos-parameters], carried inside the QoS-Parameters
excess traffic is then to be shaped to this TMOD. When the AVP of the Excess-Treatment AVP indicates how to shape the excess
shaping causes unbounded queue growth at the shaper traffic can be traffic. Note that shaping might cause unbounded queue growth at
dropped. the shaper and consequently traffic may still get dropped.
remark:
When excess treatment action is set to 'remark', it is expected
that the QoS-Parameters AVP carries information about the QoS
class. 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.
no metering or policing is permitted: mark:
If 'no metering or policing is permitted' is signaled, the QoS When excess treatment action is set to 'mark', it is expected that
aware node should accept the excess treatment parameter set by the the QoS-Parameters AVP carries information about the QoS class.
sender with special care so that excess traffic should not cause a For example, excess traffic may need to get marked differently to
problem. To request the Null Meter [RFC3290] is especially the traffic conformant to the traffic profile.
strong, and should be used with caution.
When the Excess-Treatment AVP is omitted then excess treatment is When the Excess-Treatment AVP is omitted then excess treatment is
essentially unspecified and there are no guaranted behavior with essentially unspecified and there are no guaranted behavior with
regard to excess traffic, i.e., a QoS aware node can do what it finds regard to excess traffic, i.e., a QoS aware node can do what it finds
suitable. suitable.
Further values can be registered, as described in Section 10.3. Further values can be registered, as described in Section 10.3.
6. QoS Capability Indication 6. QoS Capability Indication
The QoS-Capability AVP (AVP Code TBD) is of type Grouped and contains The QoS-Capability AVP (AVP Code TBD) is of type Grouped and contains
a list of supported Quality of Service profile templates (and a list of supported Quality of Service profile templates (and
therefore the support of the respective parameter AVPs). therefore the support of the respective parameter AVPs).
The QoS-Capability AVP may be used for a simple announcement of the The QoS-Capability AVP may be used for a simple announcement of the
QoS capabilities and QoS profiles supported by a peer. It may also QoS capabilities and QoS profiles supported by a peer. It may also
be used to negotiate a mutually supported set of QoS capabilities and be used to negotiate a mutually supported set of QoS capabilities and
QoS profiles between two peers. QoS profiles between two peers. In such a case, handling of failed
negotiations is application and/or deployment specific.
QoS-Capability ::= < AVP Header: XXX > QoS-Capability ::= < AVP Header: XXX >
* [ QoS-Profile-Template ] 1*{ QoS-Profile-Template }
* [ AVP ] * [ AVP ]
The QoS-Profile-Template AVP is defined in Section 5.2.2. The QoS-Profile-Template AVP is defined in Section 5.3.
7. Examples 7. Examples
This section shows a number of signaling flows where QoS negotiation This section shows a number of signaling flows where QoS negotiation
and authorization is part of the conventional NASREQ, EAP or Credit and authorization is part of the conventional NASREQ, EAP or Credit
Control applications message exchanges. The signalling flows for the Control applications message exchanges. The signalling flows for the
Diameter QoS Application are described in Diameter QoS Application are described in
[I-D.ietf-dime-diameter-qos]. [I-D.ietf-dime-diameter-qos].
7.1. Diameter EAP with QoS Information 7.1. Diameter EAP with QoS Information
skipping to change at page 31, line 36 skipping to change at page 30, line 36
|------------------------------>| | |------------------------------>| |
| | Diameter-EAP-Request | | | Diameter-EAP-Request |
| | EAP-Payload(EAP Response #N) | | | EAP-Payload(EAP Response #N) |
| |------------------------------->| | |------------------------------->|
| | | | | |
| | Diameter-EAP-Answer | | | Diameter-EAP-Answer |
| | Result-Code=DIAMETER_SUCCESS | | | Result-Code=DIAMETER_SUCCESS |
| | EAP-Payload(EAP Success) | | | EAP-Payload(EAP Success) |
| | [EAP-Master-Session-Key] | | | [EAP-Master-Session-Key] |
| | (authorization AVPs) | | | (authorization AVPs) |
| | Rule-Set(QoS-Authorized) | | | QoS-Resources(QoS-Authorized) |
| |<-------------------------------| | |<-------------------------------|
| | | | | |
| EAP Success | | | EAP Success | |
|<------------------------------| | |<------------------------------| |
| | | | | |
Figure 2: Example of a Diameter EAP enhanced with QoS Information Figure 2: Example of a Diameter EAP enhanced with QoS Information
7.2. Diameter NASREQ with QoS Information 7.2. Diameter NASREQ with QoS Information
skipping to change at page 32, line 38 skipping to change at page 31, line 38
| Response #N | | | Response #N | |
+----------------->| | +----------------->| |
| | | | | |
| |AA-Request | | |AA-Request |
| |NASREQ-Payload ( Response #N )| | |NASREQ-Payload ( Response #N )|
| +----------------------------->| | +----------------------------->|
| | | | | |
| | AA-Answer| | | AA-Answer|
| | Result-Code=DIAMETER_SUCCESS| | | Result-Code=DIAMETER_SUCCESS|
| | (authorization AVPs)| | | (authorization AVPs)|
| | Rule-Set(QoS-Authorized) | | | QoS-Resources(QoS-Authorized)|
| |<-----------------------------+ | |<-----------------------------+
| | | | | |
| Success | | | Success | |
|<-----------------+ | |<-----------------+ |
| | | | | |
Figure 3: Example of a Diameter NASREQ enhanced with QoS Information Figure 3: Example of a Diameter NASREQ enhanced with QoS Information
7.3. QoS Authorization 7.3. QoS Authorization
Figure 4 shows an example of authorization only QoS signaling as part Figure 4 shows an example of authorization only QoS signaling as part
of the NASREQ message exchange. The NAS provides the Diameter server of the NASREQ message exchange. The NAS provides the Diameter server
with the "QoS-Desired" QoS-Semantics AVP included in the Rule-Set with the "QoS-Desired" QoS-Semantics AVP included in the QoS-
AVP. The Diameter server then either authorizes the indicated QoS or Resources AVP. The Diameter server then either authorizes the
rejects the request and informs the NAS about the result. In this indicated QoS or rejects the request and informs the NAS about the
scenario the NAS does not need to include the QoS-Capability AVP in result. In this scenario the NAS does not need to include the QoS-
the AAR message as the Rule-Set AVP implicitly does the same and also Capability AVP in the AAR message as the QoS-Resources AVP implicitly
the NAS is authorizing a specific QoS profile, not a pre-provisioned does the same and also the NAS is authorizing a specific QoS profile,
one. not a pre-provisioned one.
End Diameter End Diameter
Host NAS Server Host NAS Server
| | | | | |
| | | | | |
| QoS Request | | | QoS Request | |
+----------------->| | +----------------->| |
| | | | | |
| |AA-Request | | |AA-Request |
| |Auth-Request-Type=AUTHORIZE_ONLY | |Auth-Request-Type=AUTHORIZE_ONLY
| |NASREQ-Payload | | |NASREQ-Payload |
| |Rule-Set(QoS-Desired) | | |QoS-Resources(QoS-Desired) |
| +----------------------------->| | +----------------------------->|
| | | | | |
| | AA-Answer| | | AA-Answer|
| | NASREQ-Payload(Success)| | | NASREQ-Payload(Success)|
| | Rule-Set(QoS-Authorized)| | | QoS-Resources(QoS-Authorized)|
| |<-----------------------------+ | |<-----------------------------+
| Accept | | | Accept | |
|<-----------------+ | |<-----------------+ |
| | | | | |
| | | | | |
| | | | | |
Figure 4: Example of an Authorization-Only Message Flow Figure 4: Example of an Authorization-Only Message Flow
7.4. Diameter Server Initiated Re-authorization of QoS 7.4. Diameter Server Initiated Re-authorization of QoS
skipping to change at page 34, line 24 skipping to change at page 33, line 24
| |<-----------------------------+ | |<-----------------------------+
| | | | | |
| |RA-Answer | | |RA-Answer |
| |Result-Code=DIAMETER_SUCCESS | | |Result-Code=DIAMETER_SUCCESS |
| +----------------------------->| | +----------------------------->|
| | | | | |
| | | | | |
| |AA-Request | | |AA-Request |
| |NASREQ-Payload | | |NASREQ-Payload |
| |Auth-Request-Type=AUTHORIZE_ONLY | |Auth-Request-Type=AUTHORIZE_ONLY
| |Rule-Set(QoS-Desired) | | |QoS-Resources(QoS-Desired) |
| +----------------------------->| | +----------------------------->|
| | | | | |
| | AA-Answer| | | AA-Answer|
| | Result-Code=DIAMETER_SUCCESS| | | Result-Code=DIAMETER_SUCCESS|
| | (authorization AVPs)| | | (authorization AVPs)|
| | Rule-Set(QoS-Authorized) | | | QoS-Resources(QoS-Authorized)|
| |<-----------------------------+ | |<-----------------------------+
| | | | | |
Figure 5: Example of a Server-initiated Re-Authorization Procedure Figure 5: Example of a Server-initiated Re-Authorization Procedure
7.5. Diameter Credit Control with QoS Information 7.5. Diameter Credit Control with QoS Information
In this case the User is charged as soon as the Service Element (CC In this case the User is charged as soon as the Service Element (CC
client) receives the service request. In this case the client uses client) receives the service request. In this case the client uses
the "QoS-Desired" QoS-Semantics parameter in the Rule-Set AVP that it the "QoS-Desired" QoS-Semantics parameter in the QoS-Resources AVP
sends to the Accounitng server. The server responds with a "QoS- that it sends to the Accounitng server. The server responds with a
Available" QoS-Semantics parameter in the Rule-Set AVP "QoS-Available" QoS-Semantics parameter in the QoS-Resources AVP
Service Element Service Element
End User (CC Client) B CC Server End User (CC Client) B CC Server
| | | | | | | |
|(1) Service Request | | | |(1) Service Request | | |
|-------------------->| | | |-------------------->| | |
| |(2) CCR (event, DIRECT_DEBITING,| | |(2) CCR (event, DIRECT_DEBITING,|
| | Rule-Set[QoS-desired]) | | | QoS-Resources[QoS-desired]) |
| |-------------------------------->| | |-------------------------------->|
| |(3) CCA (Granted-Units, QoS- | | |(3) CCA (Granted-Units, QoS- |
| | Resources[QoS-Authorized]) | | | Resources[QoS-Authorized]) |
| |<--------------------------------| | |<--------------------------------|
|(4) Service Delivery | | | |(4) Service Delivery | | |
|<--------------------| | | |<--------------------| | |
|(5) Begin service | | | |(5) Begin service | | |
|<------------------------------------>| | |<------------------------------------>| |
| | | | | | | |
. . . . . . . .
skipping to change at page 36, line 29 skipping to change at page 35, line 29
} }
Port = 5060; Port = 5060;
Port = 3478; Port = 3478;
Port-Range = { Port-Range = {
Port-Start = 16348; Port-Start = 16348;
Port-End = 32768; Port-End = 32768;
} }
} }
} }
7.7. QoS Examples
The following high level description aims to illustrate the
interworking between the Diameter QoS AVPs defined in this document
and the QoS parameters defined in [I-D.ietf-dime-qos-parameters].
Consider the following example where a rule should be installed that
limits traffic to 1 Mbit/sec and where out-of-profile traffic shall
be dropped.The Classifers are ignored in this example.
This would require the Action AVP to be set to 'police' (which also
implies the Excess-Treatment-Action AVP to be set to 'drop' and
explicitly including the Excess-Treatment-Action AVP is not
necessary). The QoS-Parameters AVP carries the Bandwidth AVP
indicating the 1 Mbit/sec limit.
In a second, more complex scenario, we consider traffic marking with
DiffServ. In-profile traffic (of 5 Mbits/sec in our example) shall
be associated with a particular PHB-Class "X". Out-of-profile
traffic shall belong to a different PHB-Class, in our example "Y".
This configuration would require the Action AVP to be set to 'mark'.
The QoS-Parameters AVPs for the traffic conforming of the profile
contains two AVPs, namely the TMOD-1 AVP and the PHB-Class AVP. The
TMOD-1 AVP describes the traffic characteristics, namely 5 Mbit/sec,
and the PHB-Class AVP is set to class "X". Then, the Excess-
Treatment AVP has to be included with the Excess-Treatment-Action AVP
set to 'mark' and the QoS-Parameters AVP to carry another PHB-Class
AVP indicating PHB-Class AVP setting to class "Y".
8. Acknowledgments 8. Acknowledgments
We would like to thank Victor Fajardo, Tseno Tsenov, Robert Hancock, We would like to thank Victor Fajardo, Tseno Tsenov, Robert Hancock,
Jukka Manner, Cornelia Kappler, Xiaoming Fu, Frank Alfano, Tolga Jukka Manner, Cornelia Kappler, Xiaoming Fu, Frank Alfano, Tolga
Asveren, Mike Montemurro, Glen Zorn, Avri Doria, Dong Sun, Tina Tsou, Asveren, Mike Montemurro, Glen Zorn, Avri Doria, Dong Sun, Tina Tsou,
Pete McCann, Georgios Karagiannis, Elwyn Davies, Max Riegel and Yong Pete McCann, Georgios Karagiannis, Elwyn Davies, Max Riegel and Yong
Li for their comments. Li for their comments. We thank Victor Fajardo for his job as PROTO
document shepherd.
9. Contributors 9. Contributors
Max Riegel contributed the VLAN sections. Max Riegel contributed the VLAN sections.
10. IANA Considerations 10. IANA Considerations
10.1. AVP Codes 10.1. AVP Codes
IANA is requested to allocate AVP codes for the following AVPs that IANA is requested to allocate AVP codes for the following AVPs that
are defined in this document. are defined in this document.
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| AVP Section | | AVP Section |
| Attribute Name Code Defined Data Type | | Attribute Name Code Defined Data Type |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
|Rule-Set TBD 3.1 Grouped | |QoS-Resources TBD 3.1 Grouped |
|Rule TBD 3.2 Grouped | |Rule TBD 3.2 Grouped |
|Classifier TBD 4.1.1 Grouped | |Classifier TBD 4.1.1 Grouped |
|Classifier-ID TBD 4.1.2 OctetString | |Classifier-ID TBD 4.1.2 OctetString |
|Protocol TBD 4.1.3 Enumerated | |Protocol TBD 4.1.3 Enumerated |
|Direction TBD 4.1.4 Enumerated | |Direction TBD 4.1.4 Enumerated |
|From-Spec TBD 4.1.5 Grouped | |From-Spec TBD 4.1.5 Grouped |
|To-Spec TBD 4.1.6 Grouped | |To-Spec TBD 4.1.6 Grouped |
|Negated TBD 4.1.7.1 Enumerated | |Negated TBD 4.1.7.1 Enumerated |
|IP-Address TBD 4.1.7.2 Address | |IP-Address TBD 4.1.7.2 Address |
|IP-Address-Range TBD 4.1.7.3 Grouped | |IP-Address-Range TBD 4.1.7.3 Grouped |
|IP-Address-Start TBD 4.1.7.4 Address | |IP-Address-Start TBD 4.1.7.4 Address |
|IP-Address-End TBD 4.1.7.5 Address | |IP-Address-End TBD 4.1.7.5 Address |
|IP-Address-Mask TBD 4.1.7.6 Grouped | |IP-Address-Mask TBD 4.1.7.6 Grouped |
|IP-Mask-Bit-Mask-Width TBD 4.1.7.7 OctetString | |IP-Mask-Bit-Mask-Width TBD 4.1.7.7 Unsigned32 |
|MAC-Address TBD 4.1.7.8 OctetString | |MAC-Address TBD 4.1.7.8 OctetString |
|MAC-Address-Mask TBD 4.1.7.9 Grouped | |MAC-Address-Mask TBD 4.1.7.9 Grouped |
|MAC-Address-Mask-Pattern TBD 4.1.7.10 OctetString | |MAC-Address-Mask-Pattern TBD 4.1.7.10 OctetString |
|EUI64-Address TBD 4.1.7.11 OctetString | |EUI64-Address TBD 4.1.7.11 OctetString |
|EUI64-Address-Mask TBD 4.1.7.12 Grouped | |EUI64-Address-Mask TBD 4.1.7.12 Grouped |
|EUI64-Address-Mask-Pattern TBD 4.1.7.13 OctetString | |EUI64-Address-Mask-Pattern TBD 4.1.7.13 OctetString |
|Port TBD 4.1.7.14 Integer32 | |Port TBD 4.1.7.14 Integer32 |
|Port-Range TBD 4.1.7.15 Grouped | |Port-Range TBD 4.1.7.15 Grouped |
|Port-Start TBD 4.1.7.16 Integer32 | |Port-Start TBD 4.1.7.16 Integer32 |
|Port-End TBD 4.1.7.17 Integer32 | |Port-End TBD 4.1.7.17 Integer32 |
skipping to change at page 38, line 12 skipping to change at page 37, line 44
|ETH-SAP TBD 4.1.8.17 OctetString | |ETH-SAP TBD 4.1.8.17 OctetString |
|VLAN-ID-Range TBD 4.1.8.18 Grouped | |VLAN-ID-Range TBD 4.1.8.18 Grouped |
|S-VID-Start TBD 4.1.8.19 Unsigned32 | |S-VID-Start TBD 4.1.8.19 Unsigned32 |
|S-VID-End TBD 4.1.8.20 Unsigned32 | |S-VID-End TBD 4.1.8.20 Unsigned32 |
|C-VID-Start TBD 4.1.8.21 Unsigned32 | |C-VID-Start TBD 4.1.8.21 Unsigned32 |
|C-VID-End TBD 4.1.8.22 Unsigned32 | |C-VID-End TBD 4.1.8.22 Unsigned32 |
|ETH-Priority-Range TBD 4.1.8.23 Grouped | |ETH-Priority-Range TBD 4.1.8.23 Grouped |
|ETH-Low-Priority TBD 4.1.8.24 Unsigned32 | |ETH-Low-Priority TBD 4.1.8.24 Unsigned32 |
|ETH-High-Priority TBD 4.1.8.25 Unsigned32 | |ETH-High-Priority TBD 4.1.8.25 Unsigned32 |
|Time-Of-Day-Condition TBD 4.2.1 Grouped | |Time-Of-Day-Condition TBD 4.2.1 Grouped |
|Time-Of-Day-Start TBD 4.2.2 Grouped | |Time-Of-Day-Start TBD 4.2.2 Unsigned32 |
|Time-Of-Day-End TBD 4.2.3 Unsigned32 | |Time-Of-Day-End TBD 4.2.3 Unsigned32 |
|Day-Of-Week-Mask TBD 4.2.4 Unsigned32 | |Day-Of-Week-Mask TBD 4.2.4 Unsigned32 |
|Day-Of-Month-Mask TBD 4.2.5 Unsigned32 | |Day-Of-Month-Mask TBD 4.2.5 Unsigned32 |
|Month-Of-Year-Mask TBD 4.2.6 Unsigned32 | |Month-Of-Year-Mask TBD 4.2.6 Unsigned32 |
|Absolute-Start-Time TBD 4.2.7 Time | |Absolute-Start-Time TBD 4.2.7 Time |
|Absolute-End-Time TBD 4.2.8 Time | |Absolute-End-Time TBD 4.2.8 Time |
|Timezone-Flag TBD 4.2.9 Enumerated | |Timezone-Flag TBD 4.2.9 Enumerated |
|Timezone-Offset TBD 4.2.10 Integer32 | |Timezone-Offset TBD 4.2.10 Integer32 |
|Action TBD 5.1 Grouped | |Action TBD 5.1 Grouped |
|QoS-Profile-Id TBD 5.2.1 Unsigned32 | |QoS-Profile-Id TBD 5.2.1 Unsigned32 |
|QoS-Profile-Template TBD 5.2.2 Grouped | |QoS-Profile-Template TBD 5.2.2 Grouped |
|QoS-Semantics TBD 5.2.3 Enumerated | |QoS-Semantics TBD 5.2.3 Enumerated |
|QoS-Parameters TBD 5.2.4 OctetString | |QoS-Parameters TBD 5.2.4 Grouped |
|Rule-Precedence TBD 5.2.5 Unsigned32 | |Rule-Precedence TBD 5.2.5 Unsigned32 |
|Excess-Treatment TBD 5.2.6 Grouped | |Excess-Treatment TBD 5.2.6 Grouped |
|Excess-Treatment-Action TBD 5.2.7 Unsigned32 | |Excess-Treatment-Action TBD 5.2.7 Unsigned32 |
|QoS-Capability TBD 6 Grouped | |QoS-Capability TBD 6 Grouped |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
10.2. QoS-Semantics IANA Registry 10.2. QoS-Semantics IANA Registry
IANA is also requested to allocate a registry for the QoS-Semantics IANA is also requested to allocate a registry for the QoS-Semantics
AVP. The following values are allocated by this specification. AVP. The following values are allocated by this specification.
skipping to change at page 39, line 7 skipping to change at page 38, line 37
A specification is required to add a new value to the registry. A specification is required to add a new value to the registry.
10.3. Excess Treatment Action 10.3. Excess Treatment Action
IANA is also requested to allocate a registry for the Excess- IANA is also requested to allocate a registry for the Excess-
Treatment-Action AVP. The following values are allocated by this Treatment-Action AVP. The following values are allocated by this
specification: specification:
(0): drop (0): drop
(1): shape (1): shape
(2): remark (2): mark
(3): no metering or policing is permitted
A specification is required to add a new value to the registry. A specification is required to add a new value to the registry.
10.4. Action 10.4. Action
IANA is also requested to allocate a registry for the Action AVP. IANA is also requested to allocate a registry for the Action AVP.
The following values are allocated by this specification: The following values are allocated by this specification:
(0): drop 0: drop
(1): shape 1: shape
(2): mark 2: police
2: mark
A specification is required to add a new value to the registry. A specification is required to add a new value to the registry.
11. Security Considerations 11. Security Considerations
This document describes the extension of Diameter for conveying This document describes the extension of Diameter for conveying
Quality of Service information. The security considerations of the Quality of Service information. The security considerations of the
Diameter protocol itself have been discussed in RFC 3588 [RFC3588]. Diameter protocol itself have been discussed in RFC 3588 [RFC3588].
Use of the AVPs defined in this document MUST take into consideration Use of the AVPs defined in this document MUST take into consideration
the security issues and requirements of the Diameter Base protocol. the security issues and requirements of the Diameter Base protocol.
skipping to change at page 40, line 34 skipping to change at page 40, line 18
[TCPOPTIONS] [TCPOPTIONS]
IANA, "TCP Option Numbers", IANA, "TCP Option Numbers",
http://www.iana.org/assignments/tcp-parameters. http://www.iana.org/assignments/tcp-parameters.
12.2. Informative References 12.2. Informative References
[I-D.ietf-dime-diameter-qos] [I-D.ietf-dime-diameter-qos]
Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A.,
and G. Zorn, "Diameter Quality of Service Application", and G. Zorn, "Diameter Quality of Service Application",
draft-ietf-dime-diameter-qos-06 (work in progress), draft-ietf-dime-diameter-qos-07 (work in progress),
July 2008. December 2008.
[I-D.ietf-dime-qos-parameters] [I-D.ietf-dime-qos-parameters]
Korhonen, J. and H. Tschofenig, "Quality of Service Korhonen, J. and H. Tschofenig, "Quality of Service
Parameters for Usage with the AAA Framework", Parameters for Usage with Diameter",
draft-ietf-dime-qos-parameters-07 (work in progress), draft-ietf-dime-qos-parameters-08 (work in progress),
November 2008. December 2008.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An [RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
Informal Management Model for Diffserv Routers", RFC 3290, Informal Management Model for Diffserv Routers", RFC 3290,
May 2002. May 2002.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005, "Diameter Network Access Server Application", RFC 4005,
 End of changes. 95 change blocks. 
215 lines changed or deleted 268 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/