draft-ietf-dime-diameter-qos-10.txt   draft-ietf-dime-diameter-qos-11.txt 
Diameter Maintenance and D. Sun, Ed. Diameter Maintenance and D. Sun, Ed.
Extensions (DIME) Alcatel-Lucent Extensions (DIME) Alcatel-Lucent
Internet-Draft P. McCann Internet-Draft P. McCann
Intended status: Standards Track Motorola Labs Intended status: Standards Track Motorola Labs
Expires: February 3, 2010 H. Tschofenig Expires: February 6, 2010 H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
T. Tsou T. Tsou
Huawei Huawei
A. Doria A. Doria
Lulea University of Technology Lulea University of Technology
G. Zorn, Ed. G. Zorn, Ed.
Network Zen Network Zen
August 2, 2009 August 5, 2009
Diameter Quality of Service Application Diameter Quality of Service Application
draft-ietf-dime-diameter-qos-10.txt draft-ietf-dime-diameter-qos-11.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 41 skipping to change at page 1, line 41
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 February 3, 2010. This Internet-Draft will expire on February 6, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 35 skipping to change at page 3, line 35
3.3.2. Push Mode Schemes . . . . . . . . . . . . . . . . . . 16 3.3.2. Push Mode Schemes . . . . . . . . . . . . . . . . . . 16
3.4. QoS Application Requirements . . . . . . . . . . . . . . . 17 3.4. QoS Application Requirements . . . . . . . . . . . . . . . 17
4. QoS Application Session Establishment and Management . . . . . 21 4. QoS Application Session Establishment and Management . . . . . 21
4.1. Parties Involved . . . . . . . . . . . . . . . . . . . . . 21 4.1. Parties Involved . . . . . . . . . . . . . . . . . . . . . 21
4.2. Session Establishment . . . . . . . . . . . . . . . . . . 21 4.2. Session Establishment . . . . . . . . . . . . . . . . . . 21
4.2.1. Session Establishment for Pull Mode . . . . . . . . . 22 4.2.1. Session Establishment for Pull Mode . . . . . . . . . 22
4.2.2. Session Establishment for Push Mode . . . . . . . . . 24 4.2.2. Session Establishment for Push Mode . . . . . . . . . 24
4.2.3. Discovery and Selection of Peer Diameter QoS 4.2.3. Discovery and Selection of Peer Diameter QoS
Application Node . . . . . . . . . . . . . . . . . . . 27 Application Node . . . . . . . . . . . . . . . . . . . 27
4.3. Session Re-authorization . . . . . . . . . . . . . . . . . 28 4.3. Session Re-authorization . . . . . . . . . . . . . . . . . 28
4.3.1. Client-Side Initiated Re-Authorization . . . . . . . . 29 4.3.1. Client-Side Initiated Re-Authorization . . . . . . . . 28
4.3.2. Server-Side Initiated Re-Authorization . . . . . . . . 30 4.3.2. Server-Side Initiated Re-Authorization . . . . . . . . 29
4.4. Session Termination . . . . . . . . . . . . . . . . . . . 31 4.4. Session Termination . . . . . . . . . . . . . . . . . . . 31
4.4.1. Client-Side Initiated Session Termination . . . . . . 31 4.4.1. Client-Side Initiated Session Termination . . . . . . 31
4.4.2. Server-Side Initiated Session Termination . . . . . . 32 4.4.2. Server-Side Initiated Session Termination . . . . . . 31
5. QoS Application Messages . . . . . . . . . . . . . . . . . . . 34 5. QoS Application Messages . . . . . . . . . . . . . . . . . . . 33
5.1. QoS-Authorization Request (QAR) . . . . . . . . . . . . . 35 5.1. QoS-Authorization Request (QAR) . . . . . . . . . . . . . 34
5.2. QoS-Authorization Answer (QAA) . . . . . . . . . . . . . . 35 5.2. QoS-Authorization Answer (QAA) . . . . . . . . . . . . . . 34
5.3. QoS-Install Request (QIR) . . . . . . . . . . . . . . . . 36 5.3. QoS-Install Request (QIR) . . . . . . . . . . . . . . . . 35
5.4. QoS-Install Answer (QIA) . . . . . . . . . . . . . . . . . 37 5.4. QoS-Install Answer (QIA) . . . . . . . . . . . . . . . . . 36
5.5. Re-Auth-Request (RAR) . . . . . . . . . . . . . . . . . . 37 5.5. Re-Auth-Request (RAR) . . . . . . . . . . . . . . . . . . 36
5.6. Re-Auth-Answer (RAA) . . . . . . . . . . . . . . . . . . . 38 5.6. Re-Auth-Answer (RAA) . . . . . . . . . . . . . . . . . . . 37
6. QoS Application State Machine . . . . . . . . . . . . . . . . 39 6. QoS Application State Machine . . . . . . . . . . . . . . . . 38
6.1. Supplemented States for Push Mode . . . . . . . . . . . . 39 6.1. Supplemented States for Push Mode . . . . . . . . . . . . 38
7. QoS Application AVPs . . . . . . . . . . . . . . . . . . . . . 41 7. QoS Application AVPs . . . . . . . . . . . . . . . . . . . . . 40
7.1. Reused Base Protocol AVPs . . . . . . . . . . . . . . . . 41 7.1. Reused Base Protocol AVPs . . . . . . . . . . . . . . . . 40
7.2. QoS Application Defined AVPs . . . . . . . . . . . . . . . 41 7.2. QoS Application Defined AVPs . . . . . . . . . . . . . . . 40
8. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 43 8. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.1. Example Call Flow for Pull Mode . . . . . . . . . . . . . 44 9.1. Example Call Flow for Pull Mode . . . . . . . . . . . . . 43
9.2. Example Call Flow for Push Mode . . . . . . . . . . . . . 46 9.2. Example Call Flow for Push Mode . . . . . . . . . . . . . 45
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
10.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 49 10.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 48
10.2. AVP Specific Values . . . . . . . . . . . . . . . . . . . 49 10.2. AVP Specific Values . . . . . . . . . . . . . . . . . . . 48
10.3. AVP Flags . . . . . . . . . . . . . . . . . . . . . . . . 49 10.3. AVP Flags . . . . . . . . . . . . . . . . . . . . . . . . 48
10.4. Application IDs . . . . . . . . . . . . . . . . . . . . . 49 10.4. Application IDs . . . . . . . . . . . . . . . . . . . . . 48
10.5. Command Codes . . . . . . . . . . . . . . . . . . . . . . 50 10.5. Command Codes . . . . . . . . . . . . . . . . . . . . . . 49
11. Security Considerations . . . . . . . . . . . . . . . . . . . 51 11. Security Considerations . . . . . . . . . . . . . . . . . . . 50
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 54 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
14.1. Normative References . . . . . . . . . . . . . . . . . . . 55 14.1. Normative References . . . . . . . . . . . . . . . . . . . 54
14.2. Informative References . . . . . . . . . . . . . . . . . . 55 14.2. Informative References . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction 1. Introduction
This document describes the framework, messages and procedures for This document describes the framework, messages and procedures for
the Diameter Quality of Service (QoS) Application. The Diameter QoS the Diameter Quality of Service (QoS) Application. The Diameter QoS
Application allows Network Elements (NEs) to interact with Diameter Application allows Network Elements (NEs) to interact with Diameter
servers when allocating QoS resources in the network. servers when allocating QoS resources in the network.
Two modes of operation are defined. In the first, called "Pull" Two modes of operation are defined. In the first, called "Pull"
mode, the network element requests QoS authorization from the mode, the network element requests QoS authorization from the
skipping to change at page 13, line 22 skipping to change at page 13, line 22
networks such as the GPRS networks defined by 3GPP. Some networks networks such as the GPRS networks defined by 3GPP. Some networks
(for example, WiMAX) may require both Push and Pull modes. (for example, WiMAX) may require both Push and Pull modes.
3.3. Authorization Schemes 3.3. Authorization Schemes
3.3.1. Pull Mode Schemes 3.3.1. Pull Mode Schemes
Three types of basic authorization schemes for Pull mode exist: one Three types of basic authorization schemes for Pull mode exist: one
type of two-party scheme and two types of three-party schemes. The type of two-party scheme and two types of three-party schemes. The
notation adopted here is in respect to the entity that performs the notation adopted here is in respect to the entity that performs the
QoS authorization. The authentication of the QoS requesting entity QoS authorization (QoS Authz). The authentication of the QoS
might be done at the NE as part of the QoS signaling protocol, or by requesting entity might be done at the NE as part of the QoS
an off-path protocol run (on the application layer or for network signaling protocol, or by an off-path protocol (on the application
access authentication) or the AE might be contacted with request for layer or for network access authentication) or the AE might be
authentication and authorization of the QoS requesting entity. From contacted with request for authentication and authorization of the
the Diameter QoS application's point of view these schemes differ in QoS requesting entity. From the Diameter QoS application's point of
type of information that need to be carried. Here we focus on the view these schemes differ in type of information that need to be
'Basic Three Party Scheme' (see Figure 3) and the 'Token-based Three carried. Here we focus on the 'Basic Three Party Scheme' (see
Party Scheme' (see Figure 4). In the 'Two Party Scheme', the QoS RRE Figure 3) and the 'Token-based Three Party Scheme' (see Figure 4).
is authenticated by the NE and the authorization decision is made In the 'Two Party Scheme', the QoS RRE is authenticated by the NE and
either locally at the NE itself or offloaded to a trusted entity the authorization decision is made either locally at the NE itself or
(most likely within the same administrative domain). In the two- offloaded to a trusted entity (most likely within the same
party case no Diameter QoS protocol interaction is REQUIRED. administrative domain). In the two-party case no Diameter QoS
protocol interaction is REQUIRED.
+--------------+ +--------------+
| Entity | | Entity |
| authorizing | <......+ | authorizing | <......+
| resource | . | resource | .
| request | . | request | .
+------------+-+ . +------------+-+ .
--^----------|-- . . --^----------|-- . .
///// | | \\\\\ . ///// | | \\\\\ .
// | | \\ . // | | \\ .
skipping to change at page 23, line 35 skipping to change at page 23, line 35
| | Authz. session | | | Authz. session |
| | /Authz-time/ | QoS Responder | | /Authz-time/ | QoS Responder
| | | Node | | | Node
| +-------+---------+ | | +-------+---------+ |
| +----------QoS-Reserve---....--->| | +----------QoS-Reserve---....--->|
| | | | | |
| |<---------QoS-Response--....----| | |<---------QoS-Response--....----|
|<--QoS-Response----+ | |<--QoS-Response----+ |
| | | | | |
|=====================Data Flow==============....===>| |=====================Data Flow==============....===>|
| |
| +- - - - - QAR - - - - - >|
| |(START,QoS-Resources) |
| | |
| | +--------+--------------+
| | | Report for successful |
| | | QoS reservation |
| | |Update of reserved QoS |
| | | resources |
| | +--------+--------------+
| |< - - - - QAA - - - - - -+
| | |
Figure 6: Initial QoS Request Authorization for Pull Mode Figure 6: Initial QoS Request Authorization for Pull Mode
The Authorizing Entity keeps authorization session state and SHOULD The Authorizing Entity keeps authorization session state and SHOULD
save additional information for management of the session (e.g., save additional information for management of the session (e.g.,
Signaling-Session-Id, authentication data) as part of the session Signaling-Session-Id, authentication data) as part of the session
state information. state information.
The final result of the authorization request is provided in the The final result of the authorization request is provided in the
Result-Code AVP of the QAA message sent by the Authorizing Entity. Result-Code AVP of the QAA message sent by the Authorizing Entity.
skipping to change at page 26, line 40 skipping to change at page 26, line 40
| | +--------+--------------+ | | +--------+--------------+
| | | Report for successful | | | | Report for successful |
| | | QoS reservation | | | | QoS reservation |
| | |Update of reserved QoS | | | |Update of reserved QoS |
| | | resources | | | | resources |
| | +--------+--------------+ | | +--------+--------------+
| | QoS Responder | | QoS Responder
| | Node | | Node
| | | | | |
|=====================Data Flow==============....===>| |=====================Data Flow==============....===>|
| |
| (+- - - - - QAR - - - - - >|)
| (|(START,QoS-Resources) |)
| (|< - - - - QAA - - - - - -+)
| | |
Figure 7: Initial QoS Request Authorization for Push Mode Figure 7: Initial QoS Request Authorization for Push Mode
The AE keeps authorization session state and SHOULD save additional The AE keeps authorization session state and SHOULD save additional
information for management of the session (e.g., information for management of the session (e.g.,
Signaling-Session-Id, authentication data) as part of the session Signaling-Session-Id, authentication data) as part of the session
state information. state information.
The final result of the authorization decision is provided in the The final result of the authorization decision is provided in the
QoS-Resources AVP of the QIR message sent by the AE. The QoS QoS-Resources AVP of the QIR message sent by the AE. The QoS
skipping to change at page 27, line 31 skipping to change at page 27, line 26
Section 8. Section 8.
The indication of QoS reservation and activation of the data flow can The indication of QoS reservation and activation of the data flow can
be provided by the QoS-Install-Answer message immediately. In the be provided by the QoS-Install-Answer message immediately. In the
case of successful enforcement, the Result-Code (= DIAMETER_SUCCESS, case of successful enforcement, the Result-Code (= DIAMETER_SUCCESS,
(see Section 7.1)) information is provided in the QIA message. Note (see Section 7.1)) information is provided in the QIA message. Note
that the reserved QoS resources reported in the QIA message may be that the reserved QoS resources reported in the QIA message may be
different than those initially authorized with the QIR message, due different than those initially authorized with the QIR message, due
to the QoS signaling specific behavior (e.g., receiver-initiated to the QoS signaling specific behavior (e.g., receiver-initiated
reservations with One-Path-With-Advertisements) or specific process reservations with One-Path-With-Advertisements) or specific process
of QoS negotiation along the data path. When path coupled signaling of QoS negotiation along the data path. In the case Multiple AEs
is used for QoS reservation along the data path, QAR/QAA MAY be used control the same NE, the NE should make the selection on the
to update the results of QoS reservation and enforcement following authorization decision to be enforced based on the priority of the
the establishment of data flows. In the case Multiple AEs control request.
the same NE, the NE should make the selection on the authorization
decision to be enforced based on the priority of the request.
4.2.3. Discovery and Selection of Peer Diameter QoS Application Node 4.2.3. Discovery and Selection of Peer Diameter QoS Application Node
Discovery of Diameter QoS application nodes Discovery of Diameter QoS application nodes
The Diameter QoS application node may obtain information of its peer The Diameter QoS application node may obtain information of its peer
nodes (e.g., FQDN, IP address) through static configuration or nodes (e.g., FQDN, IP address) through static configuration or
dynamic discovery as described in [RFC3588]. In particular, the NE dynamic discovery as described in section 5.2 of [RFC3588]. In
shall perform the relevant operation for Pull mode; the AE shall particular, the NE shall perform the relevant operation for Pull
perform the relevant operations for Push mode. mode; the AE shall perform the relevant operations for Push mode.
Selection of peer Diameter QoS application node Selection of peer Diameter QoS application node
Upon receipt of a trigger to initiate a new Diameter QoS Upon receipt of a trigger to initiate a new Diameter QoS
authorization session, the Diameter QoS application node selects and authorization session, the Diameter QoS application node selects and
retrieves the location information of the peer node and based on some retrieves the location information of the peer node that is
index information provided by the RRE. For instance, it can be the associated with the affected user based on some index information
Authorization Entity's ID stored in the authorization token, the end- provided by the RRE. For instance, it can be the Authorization
user's identity (e.g., NAI [RFC4282]) or a globally routable IP Entity's ID stored in the authorization token, the end-user's
address. identity (e.g., NAI [RFC4282]) or a globally routable IP address.
4.3. Session Re-authorization 4.3. Session Re-authorization
Client and server-side initiated re-authorizations are considered in Client and server-side initiated re-authorizations are considered in
the design of the Diameter QoS application. Whether the re- the design of the Diameter QoS application. Whether the re-
authorization events are transparent for the resource requesting authorization events are transparent for the resource requesting
entity or result in specific actions in the QoS signaling protocol is entity or result in specific actions in the QoS signaling protocol is
outside the scope of the Diameter QoS application. It is directly outside the scope of the Diameter QoS application. It is directly
dependent on the capabilities of the QoS signaling protocol. dependent on the capabilities of the QoS signaling protocol.
skipping to change at page 29, line 28 skipping to change at page 29, line 21
QoS Client) QoS Server) QoS Client) QoS Server)
| | | | | |
|=====================Data Flow==========================> |=====================Data Flow==========================>
| | | | | |
| +-------+----------+ | | +-------+----------+ |
| |Authz-time/CC-Time| | | |Authz-time/CC-Time| |
| | expires | | | | expires | |
| +-------+----------+ | | +-------+----------+ |
| +- - - - - QAR - - - - - >| | +- - - - - QAR - - - - - >|
| |(QoS-Resources, | | |(QoS-Resources, |
| | QoS-Authz-Data,User-ID) | | | QoS-Authorization-Data,User-ID) |
| +--------+--------------+ | +--------+--------------+
NOTE: | | Authorize request | NOTE: | | Authorize request |
Re-authorization | | Update session data | Re-authorization | | Update session data |
is transparent to | |/Authz-time,Session-Id/| is transparent to | |/Authz-time,Session-Id/|
the End-Host | +--------+--------------+ the End-Host | +--------+--------------+
|< - - - - QAA - - - - - -+ |< - - - - QAA - - - - - -+
| |(Result-Code, | | |(Result-Code, |
| |QoS-Resources,Authz-time)| | |QoS-Resources,Authz-time)|
| +-------+---------+ | | +-------+---------+ |
| |Update QoS state | | | |Update QoS state | |
skipping to change at page 39, line 16 skipping to change at page 38, line 16
The QoS application defines its own state machine that is based on The QoS application defines its own state machine that is based on
the authorization state machine defined in Section 8.1 of the Base the authorization state machine defined in Section 8.1 of the Base
Protocol ([RFC3588]). The Qos state machine uses own messages as Protocol ([RFC3588]). The Qos state machine uses own messages as
defined in Section 5 and QoS AVPs as defined in Section 7. defined in Section 5 and QoS AVPs as defined in Section 7.
6.1. Supplemented States for Push Mode 6.1. Supplemented States for Push Mode
Using the Base Protocol state machine as a basis, the following Using the Base Protocol state machine as a basis, the following
states are supplemented to first 2 state machines in which the states are supplemented to first 2 state machines in which the
session state is maintained on the Server. Thses MUST be supported session state is maintained on the Server. These MUST be supported
in any QoS application implementations in support of server initiated in any QoS application implementations in support of server initiated
push mode (see (Section 4.2.2)). push mode (see (Section 4.2.2)).
The following states are supplemented to the state machine on the The following states are supplemented to the state machine on the
client when state is maintained on the client as defined in Section Server when state is maintained on the client as defined in Section
8.1 of the Base Protocol [RFC3588]: 8.1 of the Base Protocol [RFC3588]:
SERVER, STATEFUL SERVER, STATEFUL
State Event Action New State State Event Action New State
------------------------------------------------------------- -------------------------------------------------------------
Idle An application or local Send Pending Idle An application or local Send Pending
event triggers an initial QIR initial event triggers an initial QIR initial
QoS request to the server request QoS request to the server request
Pending Received QIA with a failed Cleanup Idle Pending Received QIA with a failed Cleanup Idle
skipping to change at page 42, line 21 skipping to change at page 41, line 21
|QoS-Authorization-Data TBD 7.2 OctetString| M | | V | |QoS-Authorization-Data TBD 7.2 OctetString| M | | V |
|Bound-Auth-Session-Id TBD 7.2 UTF8String | M | | V | |Bound-Auth-Session-Id TBD 7.2 UTF8String | M | | V |
+----------------------------------------------+----+--------+-----+ +----------------------------------------------+----+--------+-----+
|M - Mandatory bit. An AVP with "M" bit set and its value MUST be | |M - Mandatory bit. An AVP with "M" bit set and its value MUST be |
| supported and recognized by a Diameter entity in order the | | supported and recognized by a Diameter entity in order the |
| message, which carries this AVP, to be accepted. | | message, which carries this AVP, to be accepted. |
|V - Vendor specific bit that indicates whether the AVP belongs to | |V - Vendor specific bit that indicates whether the AVP belongs to |
| a address space. | | a address space. |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
QoS-Authz-Data QoS-Authorization-Data
The QoS-Authorization-Data AVP (AVP Code TBD) is of type The QoS-Authorization-Data AVP (AVP Code TBD) is of type
OctetString. It is a container that carries application session OctetString. It is a container that carries application session
or user specific data that has to be supplied to the AE as input or user specific data that has to be supplied to the AE as input
to the computation of the authorization decision. to the computation of the authorization decision.
Bound-Authentication-Session-Id Bound-Authentication-Session-Id
The Bound-Authentication-Session AVP (AVP Code TBD) is of type The Bound-Authentication-Session AVP (AVP Code TBD) is of type
UTF8String. It carries the id of the Diameter authentication UTF8String. It carries the id of the Diameter authentication
session that is used for the network access authentication (NASREQ session that is used for the network access authentication (NASREQ
authentication session). It is used to tie the QoS authorization authentication session). It is used to tie the QoS authorization
 End of changes. 16 change blocks. 
84 lines changed or deleted 66 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/