draft-ietf-dime-qos-attributes-02.txt | draft-ietf-dime-qos-attributes-03.txt | |||
---|---|---|---|---|
Diameter Maintenance and J. Korhonen, Ed. | Diameter Maintenance and J. Korhonen, Ed. | |||
Extensions (DIME) TeliaSonera | Extensions (DIME) TeliaSonera | |||
Internet-Draft H. Tschofenig | Internet-Draft H. Tschofenig | |||
Intended status: Standards Track Nokia Siemens Networks | Intended status: Standards Track Nokia Siemens Networks | |||
Expires: April 1, 2008 M. Arumaithurai | Expires: May 21, 2008 M. Arumaithurai | |||
University of Goettingen | University of Goettingen | |||
September 29, 2007 | M. Jones | |||
Bridgewater Systems | ||||
November 18, 2007 | ||||
Quality of Service Attributes for Diameter | Quality of Service Attributes for Diameter | |||
draft-ietf-dime-qos-attributes-02.txt | draft-ietf-dime-qos-attributes-03.txt | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of 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 | |||
skipping to change at page 1, line 37 | skipping to change at page 1, line 39 | |||
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 April 1, 2008. | This Internet-Draft will expire on May 21, 2008. | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2007). | |||
Abstract | Abstract | |||
This document extends the QoSFilterRule AVP functionality of the | This document extends the QoSFilterRule AVP functionality of the | |||
Diameter Base protocol and the functionality of the QoS-Filter-Rule | Diameter Base protocol and the functionality of the QoS-Filter-Rule | |||
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 is made available to the Diameter Network Access Server | information using the AVPs defined in this document is available to | |||
Application, the Diameter Credit Control Application and the Diameter | existing Diameter applications where permitted by the command ABNF | |||
Extensible Authentication Protocol (EAP) Application. Future | and to all new applications. | |||
Diameter applications can easily integrate Quality of Service support | ||||
in addition to packet filtering. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Commands, AVPs and Advertising Application Support . . . . . . 3 | 3. Diameter QoS Defined AVPs . . . . . . . . . . . . . . . . . . 3 | |||
3.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 3 | 3.1. QoS-Capability AVP . . . . . . . . . . . . . . . . . . . . 3 | |||
3.2. Diameter-EAP-Request (DER) . . . . . . . . . . . . . . . . 4 | 3.2. QoS-Profile-Template AVP . . . . . . . . . . . . . . . . . 4 | |||
3.3. Diameter-EAP-Answer (DEA) . . . . . . . . . . . . . . . . 4 | 3.3. QoS-Resources AVP . . . . . . . . . . . . . . . . . . . . 4 | |||
3.4. Credit-Control-Request (CCR) . . . . . . . . . . . . . . . 5 | 3.4. Extended-QoS-Filter-Rule AVP . . . . . . . . . . . . . . . 5 | |||
3.5. Credit-Control-Answer (CCA) . . . . . . . . . . . . . . . 6 | 3.5. QoS-Profile AVP . . . . . . . . . . . . . . . . . . . . . 5 | |||
3.6. AA-Request (AAR) . . . . . . . . . . . . . . . . . . . . . 7 | 3.6. QoS-Profile-ID AVP . . . . . . . . . . . . . . . . . . . . 5 | |||
3.7. AA-Answer (AAA) . . . . . . . . . . . . . . . . . . . . . 8 | 3.7. QoS-Semantics . . . . . . . . . . . . . . . . . . . . . . 5 | |||
4. Diameter QoS Defined AVPs . . . . . . . . . . . . . . . . . . 9 | 3.8. QoS-Parameters AVP . . . . . . . . . . . . . . . . . . . . 6 | |||
4.1. QoS-Capability AVP . . . . . . . . . . . . . . . . . . . . 9 | 3.9. QoS-Flow-State AVP . . . . . . . . . . . . . . . . . . . . 6 | |||
4.2. QoS-Profile AVP . . . . . . . . . . . . . . . . . . . . . 9 | 3.10. QoS-Flow-Direction AVP . . . . . . . . . . . . . . . . . . 6 | |||
4.3. QoS-Resources AVP . . . . . . . . . . . . . . . . . . . . 10 | 4. Semantics of QoS Parameters . . . . . . . . . . . . . . . . . 7 | |||
4.4. Extended-QoS-Filter-Rule AVP . . . . . . . . . . . . . . . 10 | 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
4.5. QoSBlob-Group AVP . . . . . . . . . . . . . . . . . . . . 11 | 5.1. Diameter EAP with QoS Information . . . . . . . . . . . . 8 | |||
4.6. QoS-ID AVP . . . . . . . . . . . . . . . . . . . . . . . . 11 | 5.2. Diameter NASREQ with QoS Information . . . . . . . . . . . 9 | |||
4.7. QoS-ObjectType . . . . . . . . . . . . . . . . . . . . . . 11 | 5.3. QoS Authorization . . . . . . . . . . . . . . . . . . . . 10 | |||
4.8. QoSBlob AVP . . . . . . . . . . . . . . . . . . . . . . . 11 | 5.4. Diameter Server Initiated Re-authorization of QoS . . . . 11 | |||
4.9. QoS-Flow-State AVP . . . . . . . . . . . . . . . . . . . . 12 | 5.5. Diameter Credit Control with QoS Information . . . . . . . 12 | |||
4.10. QoS-Flow-Direction AVP . . . . . . . . . . . . . . . . . . 12 | 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
5. Semantics of QoS Parameters . . . . . . . . . . . . . . . . . 12 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | |||
6.1. Diameter EAP with QoS Information . . . . . . . . . . . . 13 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
6.2. Diameter NASREQ with QoS Information . . . . . . . . . . . 14 | 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 | |||
6.3. QoS Authorization . . . . . . . . . . . . . . . . . . . . 15 | 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 | |||
6.4. Diameter Server Initiated Re-authorization of QoS . . . . 16 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
6.5. Diameter Credit Control with QoS Information . . . . . . . 17 | Intellectual Property and Copyright Statements . . . . . . . . . . 16 | |||
7. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 18 | ||||
7.1. DER and DEA Commands AVP Table . . . . . . . . . . . . . . 18 | ||||
7.2. CCR and CCA Commands AVP Table . . . . . . . . . . . . . . 18 | ||||
7.3. AAR and AAA Commands AVP Table . . . . . . . . . . . . . . 19 | ||||
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 | ||||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 | ||||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | ||||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 | ||||
11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 | ||||
11.2. Informative References . . . . . . . . . . . . . . . . . . 21 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 | ||||
Intellectual Property and Copyright Statements . . . . . . . . . . 23 | ||||
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 with the Diameter Base protocol, and | related AVPs that can be used in existing Diameter applications where | |||
the Diameter Credit Control Application, the Diameter Extensible | permitted by the command ABNF and in all new applications. The | |||
Authentication Protocol (EAP) Application and the Diameter Network | Extended-QoS-Filter-Rule AVP thereby replaces the QoSFilterRule, | |||
Access Server Application to convey Quality of Service information. | ||||
The Extended-QoS-Filter-Rule AVP thereby replaces the QoSFilterRule, | ||||
defined in RFC 3588 [RFC3588], and the QoS-Filter-Rule, defined in | defined in RFC 3588 [RFC3588], and the QoS-Filter-Rule, defined in | |||
RFC 4005 [RFC4005]. | RFC 4005 [RFC4005]. | |||
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. Commands, AVPs and Advertising Application Support | 3. Diameter QoS Defined AVPs | |||
3.1. Command Codes | ||||
This document re-uses the Diameter Base protocol [RFC3588], Diameter | ||||
Credit Control [RFC4006], Diameter NASREQ [RFC4005] and Diameter EAP | ||||
[RFC4072] application commands. The following commands are re-used | ||||
to carry QoS related AVPs: | ||||
Command-Name Abbrev. Code Reference | ||||
Diameter-EAP-Request DER 268 RFC 4072 | ||||
Diameter-EAP-Answer DEA 268 RFC 4072 | ||||
Credit-Control-Request CCR 272 RFC 4006 | ||||
Credit-Control-Answer CCA 272 RFC 4006 | ||||
AA-Request AAR 265 RFC 4005 | ||||
AA-Answer AAA 265 RFC 4005 | ||||
Figure 1: Command Codes | ||||
When the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), Session- | ||||
Termination-Request (STR), Session-Termination-Answer (STA), Abort- | ||||
Session-Request (ASR), Abort-Session-Answer (ASA), Accounting-Request | ||||
(ACR), and Accounting-Answer (ACA) commands are used together with | ||||
this specification they follow the rules in Diameter NASREQ | ||||
[RFC4005], Diameter EAP [RFC4072], Credit Control [RFC4006] and | ||||
Diameter Base Protocol [RFC3588]. The accounting commands use the | ||||
Application Identifier value of the respective application. | ||||
3.2. Diameter-EAP-Request (DER) | ||||
The Diameter-EAP-Request (DER) command [RFC4072], indicated by the | ||||
Command-Code field set to 268 and the 'R' bit set in the Command | ||||
Flags field, may be sent by the NAS to the Diameter server providing | ||||
network access authentication and authorization services. At the | ||||
same time as the network access authentication and authorization, the | ||||
NAS MAY request the Diameter server to authorize provisioning of QoS | ||||
resources. | ||||
The message format is the same as defined in [RFC4072] with an | ||||
addition of QoS specific AVPs. Figure 2 shows the DER message used | ||||
with the QoS specific AVPs: | ||||
<Diameter-EAP-Request> ::= < Diameter Header: 268, REQ, PXY > | ||||
< Session-Id > | ||||
{ Auth-Application-Id } | ||||
{ Origin-Host } | ||||
{ Origin-Realm } | ||||
{ Destination-Realm } | ||||
{ Auth-Request-Type } | ||||
[ Destination-Host ] | ||||
[ User-Name ] | ||||
[ QoS-Capability ] | ||||
* [ QoS-Resources ] | ||||
... | ||||
* [ AVP ] | ||||
Figure 2: Diameter EAP Request Command | ||||
3.3. Diameter-EAP-Answer (DEA) | ||||
The Diameter-EAP-Answer (DEA) message defined in [RFC4072], indicated | ||||
by the Command- Code field set to 268 and 'R' bit cleared in the | ||||
Command Flags field is sent in response to the Diameter-EAP-Request | ||||
message (DER). If the QoS service is successfully authorized and the | ||||
Diameter server was able to fulfill the QoS Authorization request (if | ||||
needed) then the response MAY include the QoS-Resources AVPs. | ||||
The message format is the same as defined in [RFC4072] with an | ||||
addition of QoS specific AVPs. Figure 3 shows the DEA message used | ||||
with the QoS specific AVPs: | ||||
<Diameter-EAP-Answer> ::= < Diameter Header: 268, PXY > | ||||
< Session-Id > | ||||
{ Auth-Application-Id } | ||||
{ Auth-Request-Type } | ||||
{ Result-Code } | ||||
{ Origin-Host } | ||||
{ Origin-Realm } | ||||
* [ QoS-Resources ] | ||||
[ Session-Timeout ] | ||||
[ User-Name ] | ||||
... | ||||
* [ AVP ] | ||||
Figure 3: Diameter EAP Answer Command | ||||
3.4. Credit-Control-Request (CCR) | ||||
The Credit-Control-Request (CCR) command [RFC4006], indicated by the | ||||
Command-Code field set to 272 and the 'R' bit set in the Command | ||||
Flags field, may be sent by the NAS to the Diameter-QoS server to | ||||
request QoS credit authorization for a given QoS provisioning | ||||
request. In that case the CCR command MAY also carry the QoS- | ||||
Resources AVPs. | ||||
The message format is the same as defined in [RFC4006] with an | ||||
addition of QoS specific AVPs. Figure 4 shows the CCR message used | ||||
with the QoS specific AVPs: | ||||
<Credit-Control-Request> ::= < Diameter Header: 272, REQ, PXY > | ||||
< Session-Id > | ||||
{ Auth-Application-Id } | ||||
{ Origin-Host } | ||||
{ Origin-Realm } | ||||
{ Destination-Realm } | ||||
{ Auth-Request-Type } | ||||
{ Service-Context-Id } | ||||
{ CC-Request-Type } | ||||
{ CC-Request-Number } | ||||
[ Destination-Host ] | ||||
[ User-Name ] | ||||
[ QoS-Capability ] | ||||
* [ QoS-Resources ] | ||||
... | ||||
* [ AVP ] | ||||
Figure 4: Credit Control Request Command | ||||
3.5. Credit-Control-Answer (CCA) | ||||
The Credit-Control-Answer (CCA) command [RFC4006], indicated by the | ||||
Command-Code field set to 272 and the 'R' bit set in the Command | ||||
Flags field is sent in response to the CC-Request (CCR) message to | ||||
acknowledge a CC-Request command. If the Diameter QoS server was | ||||
able to fulfill the QoS request (if needed) then the response MAY | ||||
include the QoS-Resources AVPs. | ||||
The message format is the same as defined in [RFC4006] with an | ||||
addition of QoS specific AVPs. Figure 5 shows the CCA message used | ||||
with the QoS specific AVPs: | ||||
<Credit-Control-Answer> ::= < Diameter Header: 272, PXY > | ||||
< Session-Id > | ||||
{ Result-Code } | ||||
{ Origin-Host } | ||||
{ Origin-Realm } | ||||
{ Auth-Application-Id } | ||||
{ CC-Request-Type } | ||||
{ CC-Request-Number } | ||||
[ User-Name ] | ||||
[ CC-Session-Failover ] | ||||
[ CC-Sub-Session-Id ] | ||||
[ Acct-Multi-Session-Id ] | ||||
[ Origin-State-Id ] | ||||
[ Event-Timestamp ] | ||||
* [ QoS-Resources ] | ||||
... | ||||
* [ AVP ] | ||||
Figure 5: Credit Control Answer Command | ||||
3.6. AA-Request (AAR) | ||||
The AA-Request (AAR) message, indicated by the Command-Code field set | ||||
to 265 and 'R' bit set in the Command Flags field, may be sent by the | ||||
NAS to the Diameter server providing network access configuration | ||||
services. At the same time as the network access authentication and | ||||
authorization, the NAS MAY request the Diameter server to authorize | ||||
provisioning of QoS resources. | ||||
The message format is the same as defined in [RFC4005] with an | ||||
addition of QoS specific AVPs. Figure 6 shows the AAR message used | ||||
with the QoS specific AVPs: | ||||
<AA-Request> ::= < Diameter Header: 265, REQ, PXY > | ||||
< Session-Id > | ||||
{ Auth-Application-Id } | ||||
{ Origin-Host } | ||||
{ Origin-Realm } | ||||
{ Destination-Realm } | ||||
{ Auth-Request-Type } | ||||
[ QoS-Capability ] | ||||
* [ QoS-Resources ] | ||||
[ Destination-Host ] | ||||
... | ||||
* [ AVP ] | ||||
Figure 6: AA Request Command | ||||
3.7. AA-Answer (AAA) | ||||
The AA-Answer (AAA) message, indicated by the Command-Code field set | ||||
to 265 and 'R' bit cleared in the Command Flags field is sent in | ||||
response to the AA-Request (AAR) message for confirmation of the | ||||
result of QoS provisioning. If the QoS service is successfully | ||||
authorized and the Diameter server was able to fulfill the QoS | ||||
provisioning request (if needed) then the response MAY include the | ||||
QoS-Resources AVPs. | ||||
The message format is the same as defined in [RFC4005] with an | ||||
addition of QoS specific AVPs. Figure 7 shows the AAA message used | ||||
with the QoS specific AVPs: | ||||
<AA-Answer> ::= < Diameter Header: 265, PXY > | ||||
< Session-Id > | ||||
{ Auth-Application-Id } | ||||
{ Auth-Request-Type } | ||||
{ Result-Code } | ||||
{ Origin-Host } | ||||
{ Origin-Realm } | ||||
* [ QoS-Resources ] | ||||
[ User-Name ] | ||||
[ Session-Timeout ] | ||||
... | ||||
* [ AVP ] | ||||
Figure 7: AA Answer Command | ||||
4. Diameter QoS Defined AVPs | ||||
The following table lists the Diameter AVPs used by this document, | The following table lists the Diameter AVPs used by this document, | |||
their AVP code values, types, possible flag values, and whether the | their AVP code values, types, possible flag values, and whether the | |||
AVP may be encrypted. | AVP may be encrypted. | |||
+------------------+ | +------------------+ | |||
| AVP Flag Rules | | | AVP Flag Rules | | |||
+-------------------------------------------------|----+---+----+----+ | +-------------------------------------------------|----+---+----+----+ | |||
| AVP Section |MUST|MAY|SHLD|MUST| | | AVP Section |MUST|MAY|SHLD|MUST| | |||
| Attribute Name Code Defined Data Type | | | NOT| NOT| | | Attribute Name Code Defined Data Type | | | NOT| NOT| | |||
+-------------------------------------------------+----+---+----+----+ | +-------------------------------------------------+----+---+----+----+ | |||
|QoS-Capability TBD 4.1 Grouped | |M,P| | V | | |QoS-Capability TBD 3.1 Grouped | |M,P| | V | | |||
|QoS-Profile TBD 4.2 Unsigned32 | |M,P| | V | | |QoS-Profile-Template TBD 3.2 Unsigned64 | |M,P| | V | | |||
|QoS-Resources TBD 4.3 Grouped | |M,P| | V | | |QoS-Resources TBD 3.3 Grouped | |M,P| | V | | |||
|Extended-QoS-Filter-Rule TBD 4.4 Grouped | |M,P| | V | | |Extended-QoS-Filter-Rule TBD 3.4 Grouped | |M,P| | V | | |||
|QoSBlob-Group TBD 4.5 Grouped | |M,P| | V | | |QoS-Profile TBD 3.5 Grouped | |M,P| | V | | |||
|QoS-ID TBD 4.6 Unsigned32 | |M,P| | V | | |QoS-Profile-ID TBD 3.6 Unsigned32 | |M,P| | V | | |||
|QoS-ObjectType TBD 4.7 Enumerated | |M,P| | V | | |QoS-Semantics TBD 3.7 Enumerated | |M,P| | V | | |||
|QoSBlob TBD 4.8 OctetString| |M,P| | V | | |QoS-Parameters TBD 3.8 OctetString| |M,P| | V | | |||
|QoS-Flow-State TBD 4.9 Enumerated | |M,P| | V | | |QoS-Flow-State TBD 3.9 Enumerated | |M,P| | V | | |||
|QoS-Flow-Direction TBD 4.10 Enumerated | |M,P| | V | | |QoS-Flow-Direction TBD 3.10 Enumerated | |M,P| | V | | |||
+-------------------------------------------------+----+---+----+----+ | +-------------------------------------------------+----+---+----+----+ | |||
4.1. QoS-Capability AVP | 3.1. QoS-Capability AVP | |||
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 profiles (and therefore the | a list of supported Quality of Service profile templates (and | |||
support of respective AVPs). | therefore the support of the respective parameter AVPs). | |||
QoS-Capability ::= < AVP Header: XXX > | QoS-Capability ::= < AVP Header: XXX > | |||
1* { QoS-Profile } | 1* { QoS-Profile-Template } | |||
* [ AVP ] | * [ AVP ] | |||
4.2. QoS-Profile AVP | 3.2. QoS-Profile-Template AVP | |||
The QoS-Profile AVP (AVP Code TBD) is of type Unsigned64 and contains | The QoS-Profile-Template AVP (AVP Code TBD) is of type Unsigned64 and | |||
the vendor and a specifier field. The 64-bit value in the QoS- | contains the vendor and a specifier field. The 64-bit value in the | |||
Profile AVP is structured as shown below. | QoS-Profile-Template AVP is structured as shown below. | |||
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 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Vendor | | | Vendor | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Specifier | | | Specifier | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Vendor Field: | Vendor Field: | |||
32 bits of IANA SMI Network Management Private Enterprise Code. | 32 bits of IANA SMI Network Management Private Enterprise Code. | |||
The Vendor-ID 0x00000000 is reserved for IANA registered QoS | The Vendor-ID 0x00000000 is reserved for IANA registered QoS | |||
profiles. | profiles. | |||
Specifier Field: | Specifier Field: | |||
32-bit unsigned integer, representing the defined profile value. | 32-bit unsigned integer, representing the defined profile value. | |||
An initial QoS profile is defined with vendor field set to 0x00000000 | An initial QoS profile template is defined with vendor field set to | |||
and the specifier field set to 0, as described in | 0x00000000 and the specifier field set to 0, as described in | |||
[I-D.ietf-dime-qos-parameters]. The registry for the QoS profiles is | [I-D.ietf-dime-qos-parameters]. The registry for the QoS profile | |||
created with the same document. | templates is created with the same document. | |||
4.3. QoS-Resources AVP | 3.3. QoS-Resources AVP | |||
The QoS-Resources AVP (AVP Code TBD) is of type Grouped and includes | The QoS-Resources AVP (AVP Code TBD) is of type Grouped and includes | |||
description of the Quality of Service resources. | a description of the Quality of Service resources for policing | |||
traffic flows. | ||||
QoS-Resources ::= < AVP Header: XXX > | QoS-Resources ::= < AVP Header: XXX > | |||
0* [ Extended-QoS-Filter-Rule ] | 0* [ Extended-QoS-Filter-Rule ] | |||
0* [ QoSBlob-Group ] | [ QoS-Profile ] | |||
[ QoS-Flow-State ] | [ QoS-Flow-State ] | |||
* [ AVP ] | * [ AVP ] | |||
4.4. Extended-QoS-Filter-Rule AVP | 3.4. Extended-QoS-Filter-Rule AVP | |||
TheExtended-QoS-Filter-Rule AVP (AVP Code TBD) is of type Grouped. | The Extended-QoS-Filter-Rule AVP (AVP Code TBD) is of type Grouped | |||
The QoS filter rule associated with the QoS-ID re-uses the RADIUS | and defines one or more traffic flows together with the QoS profile | |||
NAS-Traffic-Rule AVP [I-D.ietf-radext-filter-rules]. This AVP ties a | that should be applied to the flow(s) by the Resource Management | |||
specific filter to a QoS-ID that in turn refers to a specific | Function. This AVP re-uses the RADIUS NAS-Traffic-Rule AVP | |||
QoSBlob-Group. At least either one of the NAS-Traffic-Rule or the | [I-D.ietf-radext-filter-rules] to describe traffic flows. The | |||
QoS-Flow-Direction AVPs SHOULD be included. | Extended-QoS-Filter-Rule AVP ties a specific traffic filter to a QoS- | |||
Profile-ID that in turn refers to a specific set of QoS parameters. | ||||
At least either one of the NAS-Traffic-Rule or the QoS-Flow-Direction | ||||
AVPs SHOULD be included. | ||||
Extended-QoS-Filter-Rule ::= < AVP Header: XXX > | Extended-QoS-Filter-Rule ::= < AVP Header: XXX > | |||
{ QoS-ID } | [ QoS-Profile-ID ] | |||
[ NAS-Traffic-Rule ] | [ NAS-Traffic-Rule ] | |||
[ QoS-Flow-Direction ] | [ QoS-Flow-Direction ] | |||
* [ AVP ] | * [ AVP ] | |||
4.5. QoSBlob-Group AVP | 3.5. QoS-Profile AVP | |||
The QoSBlob-Group AVP (AVP Code TBD) is of type Grouped and ties the | The QoS-Profile AVP (AVP Code TBD) is of type Grouped and ties the | |||
QoS-ID AVP together to the QoSBlob AVP. All parameters followed by | QoS-Profile-ID AVP to a set of QoS-Parameters AVPs. All parameters | |||
the QoSBlob-Type AVP refer to the same QoS model/profile. | refer to the same QoS model/profile described by the QoS-Profile- | |||
Template AVP. | ||||
QoSBlob-Group ::= < AVP Header: XXX > | QoS-Profile ::= < AVP Header: XXX > | |||
{ QoS-ID } | [ QoS-Profile-ID ] | |||
{ QoS-ObjectType } | { QoS-Semantics } | |||
{ QoS-Profile } | { QoS-Profile-Template } | |||
0* [ QoSBlob ] | [ QoS-Parameters ] | |||
* [ AVP ] | * [ AVP ] | |||
It is possible to have predefined QoS profiles that contains very | 3.6. QoS-Profile-ID AVP | |||
specific QoS values and refer to it only using a specifically | ||||
assigned QoS-Profile AVP value. In this case including QoSBlob AVP | ||||
is not needed. | ||||
4.6. QoS-ID AVP | ||||
The QoS-ID AVP (AVP Code TBD) is of type Unsigned32 and references | The QoS-Profile-ID AVP (AVP Code TBD) is of type Unsigned32 and | |||
the QoSBlob. | references a set of QoS-Parameters AVPs. | |||
4.7. QoS-ObjectType | 3.7. QoS-Semantics | |||
The QoS-ObjectType AVP (AVP Code TBD) is of type Enumerated and | The QoS-Semantics AVP (AVP Code TBD) is of type Enumerated and | |||
provides the semantic for the content of the QoSBlob AVP. | provides the semantics for the content of the QoS-Profile 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 | |||
(3): Minimum-QoS | (3): Minimum-QoS | |||
(4): QoS-Authorized | (4): QoS-Authorized | |||
4.8. QoSBlob AVP | 3.8. QoS-Parameters AVP | |||
The QoSBlob AVP (AVP Code TBD) is of type OctetString and contains | The QoS-Parameters AVP (AVP Code TBD) is of type OctetString and | |||
Quality of Service parameters. These parameters are defined in a | contains Quality of Service parameters. These parameters are defined | |||
separate document, see [I-D.ietf-dime-qos-parameters]. | in a separate document, see [I-D.ietf-dime-qos-parameters]. | |||
4.9. QoS-Flow-State AVP | 3.9. QoS-Flow-State AVP | |||
The QoS-Flow-State AVP (AVP Code TBD) is of type Enumerated. It | The QoS-Flow-State AVP (AVP Code TBD) is of type Enumerated. It | |||
gives an indication as to how the flow has to be treated. The | gives an indication as to how the flow has to be treated. The | |||
Extended-QoS-Filter-Rule already provides an indicate whether a flow | Extended-QoS-Filter-Rule already provides an indicate whether a flow | |||
is permitted or denied. This optional AVP provides additional | is permitted or denied. This optional AVP provides additional | |||
information about the treatment. Currently, a single value is | information about the treatment. Currently, a single value is | |||
defined; further values are available via IANA registration. | defined; further values are available via IANA registration. | |||
Value | Name and Semantic | Value | Name and Semantic | |||
------+------------------------------------------------------------ | ------+------------------------------------------------------------ | |||
0 | QOS_FLOW_STATE_PENDING - The QoS reservation is kept | 0 | QOS_FLOW_STATE_PENDING - The QoS reservation is kept | |||
| pending. The QoS resources are not installed and subsequent | | pending. The QoS resources are not installed and subsequent | |||
| QoS signaling is necessary to active them. | | QoS signaling is necessary to active them. | |||
4.10. QoS-Flow-Direction AVP | 3.10. QoS-Flow-Direction AVP | |||
The QoS-Flow-Direction AVP (AVP Code TBD) is of type Enumerated. It | The QoS-Flow-Direction AVP (AVP Code TBD) is of type Enumerated. It | |||
gives an indication of the direction the provided QoS information | gives an indication of the direction the provided QoS information | |||
should be applied to. The QoS information can be applied to downlink | should be applied to. The QoS information can be applied to downlink | |||
flows or to uplink flows. The QoS-Flow-Direction AVP may be used in | flows or to uplink flows. The QoS-Flow-Direction AVP may be used in | |||
conjunction with the NAS-Traffic-Rule AVP. In a case conflicting | conjunction with the NAS-Traffic-Rule AVP. In a case conflicting | |||
definitions between the QoS-Flow-Direction and the NAS-Traffic-Rule, | definitions between the QoS-Flow-Direction and the NAS-Traffic-Rule, | |||
the QoS-Flow-Direction has precedence meaning the filter rules are | the QoS-Flow-Direction has precedence meaning the filter rules are | |||
applied only to the flows going to the direction indicated by the | applied only to the flows going to the direction indicated by the | |||
QoS-Flow-Direction AVP. In the absence of the QoS-Flow-Direction the | QoS-Flow-Direction AVP. In the absence of the QoS-Flow-Direction the | |||
default treatment is to both directions. Currently, three values are | default treatment is to both directions. | |||
defined; further values are available via IANA registration. | ||||
Value | Name and Semantic | Value | Name and Semantic | |||
------+------------------------------------------------------------ | ------+------------------------------------------------------------ | |||
0 | QOS_FLOW_DIRECTION_BOTH - The QoS information in applied to | 0 | QOS_FLOW_DIRECTION_BOTH - The QoS information in applied to | |||
| both downlink and uplink flows. This is also the default. | | both downlink and uplink flows. This is also the default. | |||
1 | QOS_FLOW_DIRECTION_DL - The QoS information in applied to | 1 | QOS_FLOW_DIRECTION_DL - The QoS information in applied to | |||
| downlink flows only. | | downlink flows only. | |||
2 | QOS_FLOW_DIRECTION_UL - The QoS information in applied to | 2 | QOS_FLOW_DIRECTION_UL - The QoS information in applied to | |||
| uplink flows only. | | uplink flows only. | |||
5. Semantics of QoS Parameters | 4. Semantics of QoS Parameters | |||
The QoS parameters carried in the QoS-Resources AVP may appear in | The QoS parameters carried in the QoS-Resources AVP may appear in | |||
different messages. The semantic of the QoS parameters depend on the | different messages. The semantic of the QoS parameters depend on the | |||
information provided in the Object Type defined in | information provided in the QoS-Semantics AVP which currently defines | |||
[I-D.ietf-dime-qos-parameters]. The Object Type currently lists 5 | 5 values, namely QoS-Desired (0), QoS-Available (1), QoS-Reserved | |||
values, namely QoS-Desired (0), QoS-Available (1), QoS-Reserved (2), | (2), Minimum-QoS (3), and QoS-Authorized (4). | |||
Minimum-QoS (3), and QoS-Authorized (4). | ||||
The semantics of the different Object Types are as follows: | The semantics of the different values are as follows: | |||
Object Type Direction Semantic | Object Type Direction Semantic | |||
---------------------------------------------------------------------- | ---------------------------------------------------------------------- | |||
QoS-Desired C->S Please authorize the indicated QoS | QoS-Desired C->S Please authorize the indicated QoS | |||
QoS-Desired C<-S NA | QoS-Desired C<-S NA | |||
QoS-Available C->S Adminission Control at router indicates | QoS-Available C->S Admission Control at router indicates | |||
that this QoS is available. (note 1) | that this QoS is available. (note 1) | |||
QoS-Available C<-S Indicated QoS is available. (note 2) | QoS-Available C<-S Indicated QoS is available. (note 2) | |||
QoS-Reserved C->S Used for reporting during accounting. | QoS-Reserved C->S Used for reporting during accounting. | |||
QoS-Reserved C<-S NA | QoS-Reserved C<-S NA | |||
Minimum-QoS C->S Indicates that the client is not interested | Minimum-QoS C->S Indicates that the client is not interested | |||
interested in authorizing QoS that is | interested in authorizing QoS that is | |||
lower than Min. QoS | lower than Min. QoS | |||
Minimum-QoS C<-S The client must not provide QoS guarantees | Minimum-QoS C<-S The client must not provide QoS guarantees | |||
lower than Min. QoS | lower than Min. QoS | |||
QoS-Authorized C->S NA | QoS-Authorized C->S NA | |||
skipping to change at page 13, line 38 | skipping to change at page 8, line 5 | |||
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. | |||
6. Examples | 5. 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. | Control applications message exchanges. The signalling flows for the | |||
Diameter QoS Application are described in | ||||
[I-D.ietf-dime-diameter-qos]. | ||||
6.1. Diameter EAP with QoS Information | 5.1. Diameter EAP with QoS Information | |||
Figure 18 shows a simple signaling flow where a NAS (Diameter Client) | Figure 11 shows a simple signaling flow where a NAS (Diameter Client) | |||
announces its QoS awareness and capabilities included into the DER | announces its QoS awareness and capabilities included into the DER | |||
message and as part of the access authentication procedure. Upon | message and as part of the access authentication procedure. Upon | |||
completion of the EAP exchange, the Diameter Server provides a pre- | completion of the EAP exchange, the Diameter Server provides a pre- | |||
provisioned QoS profile with the QoS-ObjectType in the QoSBlob-Group | provisioned QoS profile with the QoS-Semantics in the QoS-Profile AVP | |||
AVP set to "QoS-Authorized", to the NAS in the final DEA message. | set to "QoS-Authorized", to the NAS in the final DEA message. | |||
End Diameter Diameter | End Diameter Diameter | |||
Host Client server | Host Client server | |||
| | | | | | | | |||
| (initiate EAP) | | | | (initiate EAP) | | | |||
|<------------------------------>| | | |<------------------------------>| | | |||
| | Diameter-EAP-Request | | | | Diameter-EAP-Request | | |||
| | EAP-Payload(EAP Start) | | | | EAP-Payload(EAP Start) | | |||
| | QoS-Capability | | | | QoS-Capability | | |||
| |------------------------------->| | | |------------------------------->| | |||
skipping to change at page 14, line 43 | skipping to change at page 9, line 43 | |||
| | EAP-Payload(EAP Success) | | | | EAP-Payload(EAP Success) | | |||
| | [EAP-Master-Session-Key] | | | | [EAP-Master-Session-Key] | | |||
| | (authorization AVPs) | | | | (authorization AVPs) | | |||
| | QoS-Resources(QoS-Authorized) | | | | QoS-Resources(QoS-Authorized) | | |||
| |<-------------------------------| | | |<-------------------------------| | |||
| | | | | | | | |||
| EAP Success | | | | EAP Success | | | |||
|<-------------------------------| | | |<-------------------------------| | | |||
| | | | | | | | |||
Figure 18: Example of a Diameter EAP enhanced with QoS Information | Figure 11: Example of a Diameter EAP enhanced with QoS Information | |||
6.2. Diameter NASREQ with QoS Information | 5.2. Diameter NASREQ with QoS Information | |||
Figure 19 shows a similar pre-provisioned QoS signaling as in | Figure 12 shows a similar pre-provisioned QoS signaling as in | |||
Figure 18 but using the NASREQ application instead of EAP | Figure 11 but using the NASREQ application instead of EAP | |||
application. | application. | |||
End Diameter | End Diameter | |||
Host NAS Server | Host NAS Server | |||
| | | | | | | | |||
| Start Network | | | | Start Network | | | |||
| Attachment | | | | Attachment | | | |||
|<---------------->| | | |<---------------->| | | |||
| | | | | | | | |||
| |AA-Request | | | |AA-Request | | |||
skipping to change at page 15, line 45 | skipping to change at page 10, line 45 | |||
| | AA-Answer| | | | AA-Answer| | |||
| | Result-Code=DIAMETER_SUCCESS| | | | Result-Code=DIAMETER_SUCCESS| | |||
| | (authorization AVPs)| | | | (authorization AVPs)| | |||
| |QoS-Resources(QoS-Authorized) | | | |QoS-Resources(QoS-Authorized) | | |||
| |<-----------------------------+ | | |<-----------------------------+ | |||
| | | | | | | | |||
| Success | | | | Success | | | |||
|<-----------------+ | | |<-----------------+ | | |||
| | | | | | | | |||
Figure 19: Example of a Diameter NASREQ enhanced with QoS Information | Figure 12: Example of a Diameter NASREQ enhanced with QoS Information | |||
6.3. QoS Authorization | 5.3. QoS Authorization | |||
Figure 20 shows an example of authorization only QoS signaling as | Figure 13 shows an example of authorization only QoS signaling as | |||
part of the NASREQ message exchange. The NAS provides the Diameter | part of the NASREQ message exchange. The NAS provides the Diameter | |||
server with the "QoS-Desired" QoS-ObjectType AVP included in the QoS- | server with the "QoS-Desired" QoS-Semantics AVP included in the QoS- | |||
Resources AVP. The Diameter server then either authorizes the | Resources AVP. The Diameter server then either authorizes the | |||
indicated QoS or rejects the request and informs the NAS about the | indicated QoS or rejects the request and informs the NAS about the | |||
result. In this scenario the NAS does not need to include the QoS- | result. In this scenario the NAS does not need to include the QoS- | |||
Capability AVP in the AAR message as the QoS-Resources AVP implicitly | Capability AVP in the AAR message as the QoS-Resources AVP implicitly | |||
does the same and also the NAS is authorizing a specific QoS profile, | does the same and also the NAS is authorizing a specific QoS profile, | |||
not a pre-provisioned one. | not a pre-provisioned one. | |||
End Diameter | End Diameter | |||
Host NAS Server | Host NAS Server | |||
| | | | | | | | |||
skipping to change at page 16, line 33 | skipping to change at page 11, line 33 | |||
| | AA-Answer| | | | AA-Answer| | |||
| | NASREQ-Payload(Success)| | | | NASREQ-Payload(Success)| | |||
| | QoS-Resources(QoS-Authorized)| | | | QoS-Resources(QoS-Authorized)| | |||
| |<-----------------------------+ | | |<-----------------------------+ | |||
| Accept | | | | Accept | | | |||
|<-----------------+ | | |<-----------------+ | | |||
| | | | | | | | |||
| | | | | | | | |||
| | | | | | | | |||
Figure 20: Example of an Authorization-Only Message Flow | Figure 13: Example of an Authorization-Only Message Flow | |||
6.4. Diameter Server Initiated Re-authorization of QoS | 5.4. Diameter Server Initiated Re-authorization of QoS | |||
Figure 21 shows a message exchange for a Diameter server initiated | Figure 14 shows a message exchange for a Diameter server initiated | |||
QoS re-authorization procedure. The Diameter server sends the NAS a | QoS re-authorization procedure. The Diameter server sends the NAS a | |||
RAR message requesting re-authorization for an existing session and | RAR message requesting re-authorization for an existing session and | |||
the NAS acknowledges it with a RAA message. The NAS is aware of its | the NAS acknowledges it with a RAA message. The NAS is aware of its | |||
existing QoS profile and information for the ongoing session that the | existing QoS profile and information for the ongoing session that the | |||
Diameter server requested for re-authorization. Thus, the NAS must | Diameter server requested for re-authorization. Thus, the NAS must | |||
initiate re-authorization of the existing QoS profile. The re- | initiate re-authorization of the existing QoS profile. The re- | |||
authorization procedure is the same as in Figure 20. | authorization procedure is the same as in Figure 13. | |||
End Diameter | End Diameter | |||
Host NAS Server | Host NAS Server | |||
| | | | | | | | |||
| | | | | | | | |||
: : : | : : : | |||
: <<<Initial Messag Exchanges>>> : | : <<<Initial Message Exchanges>>> : | |||
: : : | : : : | |||
| | | | | | | | |||
| | RA-Request | | | | RA-Request | | |||
| |<-----------------------------+ | | |<-----------------------------+ | |||
| | | | | | | | |||
| |RA-Answer | | | |RA-Answer | | |||
| |Result-Code=DIAMETER_SUCCESS | | | |Result-Code=DIAMETER_SUCCESS | | |||
| +----------------------------->| | | +----------------------------->| | |||
| | | | | | | | |||
| | | | | | | | |||
skipping to change at page 17, line 34 | skipping to change at page 12, line 34 | |||
| |QoS-Resources(QoS-Desired) | | | |QoS-Resources(QoS-Desired) | | |||
| +----------------------------->| | | +----------------------------->| | |||
| | | | | | | | |||
| | AA-Answer| | | | AA-Answer| | |||
| | Result-Code=DIAMETER_SUCCESS| | | | Result-Code=DIAMETER_SUCCESS| | |||
| | (authorization AVPs)| | | | (authorization AVPs)| | |||
| | QoS-Resources(QoS-Authorized)| | | | QoS-Resources(QoS-Authorized)| | |||
| |<-----------------------------+ | | |<-----------------------------+ | |||
| | | | | | | | |||
Figure 21: Example of a Server-initiated Re-Authorization Procedure | Figure 14: Example of a Server-initiated Re-Authorization Procedure | |||
6.5. Diameter Credit Control with QoS Information | 5.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-ObjectType parameter in the QoS-Resources AVP | the "QoS-Desired" QoS-Semantics parameter in the QoS-Resources AVP | |||
that it sends to the Accounitng server. The server responds with a | that it sends to the Accounitng server. The server responds with a | |||
"QoS-Available" QoS-ObjectType parameter in the QoS-Resources 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,| | |||
| | QoS-Resources[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 | | | | |||
|<------------------------------------>| | | |<------------------------------------>| | | |||
| | | | | | | | | | |||
. . . . | . . . . | |||
. . . . | . . . . | |||
Figure 22: Example for a One-Time Diameter Credit Control Charging | Figure 15: Example for a One-Time Diameter Credit Control Charging | |||
Event | Event | |||
7. AVP Occurrence Tables | 6. Acknowledgments | |||
7.1. DER and DEA Commands AVP Table | ||||
The following table lists the Quality of Service specific AVPs | ||||
defined in this document that may be present in the DER and DEA | ||||
Commands, as defined in this document and in [RFC4072]. | ||||
+---------------+ | ||||
| Command-Code | | ||||
|-------+-------+ | ||||
Attribute Name | DER | DEA | | ||||
-------------------------------+-------+-------+ | ||||
QoS-Capability | 0-1 | 0 | | ||||
QoS-Resources | 0+ | 0+ | | ||||
+-------+-------+ | ||||
Figure 23: DER and DEA Commands AVP table | ||||
7.2. CCR and CCA Commands AVP Table | ||||
The following table lists the Quality of Service specific AVPs | ||||
defined in this document that may be present in the CCR and CCA | ||||
Commands, as defined in this document and in [RFC4006]. | ||||
+---------------+ | ||||
| Command-Code | | ||||
|-------+-------+ | ||||
Attribute Name | CCR | CCA | | ||||
-------------------------------+-------+-------+ | ||||
QoS-Capability | 0-1 | 0 | | ||||
QoS-Resources | 0+ | 0+ | | ||||
+-------+-------+ | ||||
Figure 24: CCR and CCA Commands AVP table | ||||
7.3. AAR and AAA Commands AVP Table | ||||
The following table lists the Quality of Service specific AVPs | ||||
defined in this document that may be present in the AAR and AAA | ||||
Commands, as defined in this document and in [RFC4005]. | ||||
+---------------+ | ||||
| Command-Code | | ||||
|-------+-------+ | ||||
Attribute Name | AAR | AAA | | ||||
-------------------------------+-------+-------+ | ||||
QoS-Capability | 0-1 | 0 | | ||||
QoS-Resources | 0+ | 0+ | | ||||
+-------+-------+ | ||||
Figure 25: AAR and AAA Commands AVP table | ||||
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, Avi Lior, | Jukka Manner, Cornelia Kappler, Xiaoming Fu, Frank Alfano, Avi Lior, | |||
Tolga Asveren, Mike Montemurro, Glen Zorn, Avri Doria, Dong Sun, Tina | Tolga Asveren, Mike Montemurro, Glen Zorn, Avri Doria, Dong Sun, Tina | |||
Tsou, Pete McCann, Georgios Karagiannis and Elwyn Davies for their | Tsou, Pete McCann, Georgios Karagiannis and Elwyn Davies for their | |||
comments. | comments. | |||
9. IANA Considerations | 7. IANA Considerations | |||
This specification requests IANA to assignment of new AVPs from the | This specification requests IANA to assignment of new AVPs from the | |||
AVP Code namespace defined in RFC 3588 [RFC3588]. Section 4 lists | AVP Code namespace defined in RFC 3588 [RFC3588]. Section 3 lists | |||
the newly defined AVPs. | the newly defined AVPs. | |||
IANA is requested to allocate a registry for the QoS-ObjectType. The | IANA is requested to allocate a registry for the QoS-Semantics. The | |||
following values are allocated by this specification. | following values are allocated by this specification. | |||
(0): QoS-Desired | (0): QoS-Desired | |||
(1): QoS-Available | (1): QoS-Available | |||
(2): QoS-Reserved | (2): QoS-Reserved | |||
(3): Minimum-QoS | (3): Minimum-QoS | |||
(4): QoS-Authorized | (4): QoS-Authorized | |||
A specification is required to add a new value to the registry. A | A specification is required to add a new value to the registry. A | |||
standards track document is required to depreciate, delete, or modify | standards track document is required to depreciate, delete, or modify | |||
skipping to change at page 20, line 26 | skipping to change at page 14, line 18 | |||
following values are allocated by this specification. | following values are allocated by this specification. | |||
Value | Name | Value | Name | |||
------+------------------------------------------------------------ | ------+------------------------------------------------------------ | |||
0 | QOS_FLOW_STATE_PENDING | 0 | QOS_FLOW_STATE_PENDING | |||
A specification is required to add a new value to the registry. A | A specification is required to add a new value to the registry. A | |||
standards track document is required to depreciate, delete, or modify | standards track document is required to depreciate, delete, or modify | |||
existing values. | existing values. | |||
IANA is requested to allocate a registry for the QoS-Flow-Direction. | 8. Security Considerations | |||
The following values are allocated by this specification. | ||||
Value | Name | ||||
------+------------------------------------------------------------ | ||||
0 | QOS_FLOW_DIRECTION_BOTH | ||||
1 | QOS_FLOW_DIRECTION_DL | ||||
2 | QOS_FLOW_DIRECTION_UL | ||||
A specification is required to add a new value to the registry. A | ||||
standards track document is required to depreciate, delete, or modify | ||||
existing values. | ||||
10. 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. | |||
11. References | 9. References | |||
11.1. Normative References | 9.1. Normative References | |||
[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 the AAA Framework", | |||
draft-ietf-dime-qos-parameters-00 (work in progress), | draft-ietf-dime-qos-parameters-01 (work in progress), | |||
June 2007. | September 2007. | |||
[I-D.ietf-radext-filter-rules] | [I-D.ietf-radext-filter-rules] | |||
Congdon, P., "RADIUS Attributes for Filtering and | Congdon, P., "RADIUS Attributes for Filtering and | |||
Redirection", draft-ietf-radext-filter-rules-03 (work in | Redirection", draft-ietf-radext-filter-rules-03 (work in | |||
progress), July 2007. | progress), July 2007. | |||
[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. | |||
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | ||||
Specifications: ABNF", RFC 2234, November 1997. | ||||
[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, | |||
August 2005. | August 2005. | |||
[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. | 9.2. Informative References | |||
Loughney, "Diameter Credit-Control Application", RFC 4006, | ||||
August 2005. | ||||
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible | ||||
Authentication Protocol (EAP) Application", RFC 4072, | ||||
August 2005. | ||||
11.2. Informative References | [I-D.ietf-dime-diameter-qos] | |||
Zorn, G., "Diameter Quality of Service Application", | ||||
draft-ietf-dime-diameter-qos-01 (work in progress), | ||||
July 2007. | ||||
Authors' Addresses | Authors' Addresses | |||
Jouni Korhonen (editor) | Jouni Korhonen (editor) | |||
TeliaSonera | TeliaSonera | |||
Teollisuuskatu 13 | Teollisuuskatu 13 | |||
Sonera FIN-00051 | Sonera FIN-00051 | |||
Finland | Finland | |||
Email: jouni.korhonen@teliasonera.com | Email: jouni.korhonen@teliasonera.com | |||
skipping to change at page 23, line 5 | skipping to change at page 15, line 36 | |||
Germany | Germany | |||
Email: Hannes.Tschofenig@nsn.com | Email: Hannes.Tschofenig@nsn.com | |||
URI: http://www.tschofenig.com | URI: http://www.tschofenig.com | |||
Mayutan Arumaithurai | Mayutan Arumaithurai | |||
University of Goettingen | University of Goettingen | |||
Email: mayutan.arumaithurai@gmail.com | Email: mayutan.arumaithurai@gmail.com | |||
Mark Jones | ||||
Bridgewater Systems | ||||
303 Terry Fox Drive | ||||
Ottawa, Ontario K2K 3J1 | ||||
Canada | ||||
Email: mark.jones@bridgewatersystems.com | ||||
Full Copyright Statement | Full Copyright Statement | |||
Copyright (C) The IETF Trust (2007). | Copyright (C) The IETF Trust (2007). | |||
This document is subject to the rights, licenses and restrictions | This document is subject to the rights, licenses and restrictions | |||
contained in BCP 78, and except as set forth therein, the authors | contained in BCP 78, and except as set forth therein, the authors | |||
retain all their rights. | retain all their rights. | |||
This document and the information contained herein are provided on an | This document and the information contained herein are provided on an | |||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |||
End of changes. 71 change blocks. | ||||
454 lines changed or deleted | 153 lines changed or added | |||
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |