draft-ietf-dime-diameter-qos-13.txt   draft-ietf-dime-diameter-qos-14.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: April 29, 2010 H. Tschofenig Expires: August 25, 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
October 26, 2009 February 21, 2010
Diameter Quality of Service Application Diameter Quality of Service Application
draft-ietf-dime-diameter-qos-13.txt draft-ietf-dime-diameter-qos-14.txt
Abstract
This document describes the framework, messages and procedures for
the Diameter Quality of Service (QoS) application. The Diameter QoS
application allows network elements to interact with Diameter servers
when allocating QoS resources in the network. In particular, two
modes of operation, namely "Pull" and "Push", are defined.
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 49
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 29, 2010. This Internet-Draft will expire on August 25, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 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
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document describes the framework, messages and procedures for described in the BSD License.
the Diameter Quality of Service (QoS) application. The Diameter QoS
application allows network elements to interact with Diameter servers
when allocating QoS resources in the network. In particular, two
modes of operation -- Pull and Push -- are defined.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Network Element Functional Model . . . . . . . . . . . . . 9 3.1. Network Element Functional Model . . . . . . . . . . . . . 8
3.2. Implications of Endpoint QoS Capabilities . . . . . . . . 11 3.2. Implications of Endpoint QoS Capabilities . . . . . . . . 10
3.2.1. Endpoint Categories . . . . . . . . . . . . . . . . . 11 3.2.1. Endpoint Categories . . . . . . . . . . . . . . . . . 10
3.2.2. Interaction Modes Between the Authorizing Entity 3.2.2. Interaction Modes Between the Authorizing Entity
and Network Element . . . . . . . . . . . . . . . . . 11 and Network Element . . . . . . . . . . . . . . . . . 10
3.3. Authorization Schemes . . . . . . . . . . . . . . . . . . 13 3.3. Authorization Schemes . . . . . . . . . . . . . . . . . . 12
3.3.1. Pull Mode Schemes . . . . . . . . . . . . . . . . . . 13 3.3.1. Pull Mode Schemes . . . . . . . . . . . . . . . . . . 12
3.3.2. Push Mode Schemes . . . . . . . . . . . . . . . . . . 16 3.3.2. Push Mode Schemes . . . . . . . . . . . . . . . . . . 15
3.4. QoS Application Requirements . . . . . . . . . . . . . . . 17 3.4. QoS Application Requirements . . . . . . . . . . . . . . . 16
4. QoS Application Session Establishment and Management . . . . . 21 4. QoS Application Session Establishment and Management . . . . . 20
4.1. Parties Involved . . . . . . . . . . . . . . . . . . . . . 21 4.1. Parties Involved . . . . . . . . . . . . . . . . . . . . . 20
4.2. Session Establishment . . . . . . . . . . . . . . . . . . 21 4.2. Session Establishment . . . . . . . . . . . . . . . . . . 20
4.2.1. Session Establishment for Pull Mode . . . . . . . . . 22 4.2.1. Session Establishment for Pull Mode . . . . . . . . . 21
4.2.2. Session Establishment for Push Mode . . . . . . . . . 24 4.2.2. Session Establishment for Push Mode . . . . . . . . . 23
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 . . . . . . . . . . . . . . . . . . . 26
4.3. Session Re-authorization . . . . . . . . . . . . . . . . . 28 4.3. Session Re-authorization . . . . . . . . . . . . . . . . . 26
4.3.1. Client-Side Initiated Re-Authorization . . . . . . . . 28 4.3.1. Client-Side Initiated Re-Authorization . . . . . . . . 27
4.3.2. Server-Side Initiated Re-Authorization . . . . . . . . 29 4.3.2. Server-Side Initiated Re-Authorization . . . . . . . . 28
4.4. Session Termination . . . . . . . . . . . . . . . . . . . 31 4.4. Session Termination . . . . . . . . . . . . . . . . . . . 29
4.4.1. Client-Side Initiated Session Termination . . . . . . 31 4.4.1. Client-Side Initiated Session Termination . . . . . . 29
4.4.2. Server-Side Initiated Session Termination . . . . . . 31 4.4.2. Server-Side Initiated Session Termination . . . . . . 30
5. QoS Application Messages . . . . . . . . . . . . . . . . . . . 33 5. QoS Application Messages . . . . . . . . . . . . . . . . . . . 32
5.1. QoS-Authorization Request (QAR) . . . . . . . . . . . . . 34 5.1. QoS-Authorization Request (QAR) . . . . . . . . . . . . . 33
5.2. QoS-Authorization Answer (QAA) . . . . . . . . . . . . . . 34 5.2. QoS-Authorization Answer (QAA) . . . . . . . . . . . . . . 33
5.3. QoS-Install Request (QIR) . . . . . . . . . . . . . . . . 35 5.3. QoS-Install Request (QIR) . . . . . . . . . . . . . . . . 34
5.4. QoS-Install Answer (QIA) . . . . . . . . . . . . . . . . . 36 5.4. QoS-Install Answer (QIA) . . . . . . . . . . . . . . . . . 35
5.5. Re-Auth-Request (RAR) . . . . . . . . . . . . . . . . . . 36 5.5. Re-Auth-Request (RAR) . . . . . . . . . . . . . . . . . . 35
5.6. Re-Auth-Answer (RAA) . . . . . . . . . . . . . . . . . . . 37 5.6. Re-Auth-Answer (RAA) . . . . . . . . . . . . . . . . . . . 36
6. QoS Application State Machine . . . . . . . . . . . . . . . . 38 6. QoS Application State Machine . . . . . . . . . . . . . . . . 37
6.1. Supplemented States for Push Mode . . . . . . . . . . . . 38 6.1. Supplemented States for Push Mode . . . . . . . . . . . . 37
7. QoS Application AVPs . . . . . . . . . . . . . . . . . . . . . 40 7. QoS Application AVPs . . . . . . . . . . . . . . . . . . . . . 39
7.1. Reused Base Protocol AVPs . . . . . . . . . . . . . . . . 40 7.1. Reused Base Protocol AVPs . . . . . . . . . . . . . . . . 39
7.2. QoS Application Defined AVPs . . . . . . . . . . . . . . . 40 7.2. QoS Application Defined AVPs . . . . . . . . . . . . . . . 39
8. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 42 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 9.1. Example Call Flow for Pull Mode . . . . . . . . . . . . . 42
9.1. Example Call Flow for Pull Mode . . . . . . . . . . . . . 43 9.2. Example Call Flow for Push Mode . . . . . . . . . . . . . 44
9.2. Example Call Flow for Push Mode . . . . . . . . . . . . . 45 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 10.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 47
10.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 48 10.2. Application IDs . . . . . . . . . . . . . . . . . . . . . 47
10.2. AVP Specific Values . . . . . . . . . . . . . . . . . . . 48 10.3. Command Codes . . . . . . . . . . . . . . . . . . . . . . 47
10.3. AVP Flags . . . . . . . . . . . . . . . . . . . . . . . . 48 11. Security Considerations . . . . . . . . . . . . . . . . . . . 48
10.4. Application IDs . . . . . . . . . . . . . . . . . . . . . 48 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
10.5. Command Codes . . . . . . . . . . . . . . . . . . . . . . 49 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 51
11. Security Considerations . . . . . . . . . . . . . . . . . . . 50 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 14.1. Normative References . . . . . . . . . . . . . . . . . . . 52
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53 14.2. Informative References . . . . . . . . . . . . . . . . . . 52
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
14.1. Normative References . . . . . . . . . . . . . . . . . . . 54
14.2. Informative References . . . . . . . . . . . . . . . . . . 54
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[RFC3588] Quality of Service (QoS) Application. The the Diameter [RFC3588] Quality of Service (QoS) application. The
Diameter QoS Application allows Network Elements (NEs) to interact Diameter QoS application allows Network Elements (NEs) to interact
with Diameter servers when allocating QoS resources in the network. with Diameter 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
Diameter server based on some trigger (such as a QoS signaling Diameter server based on some trigger (such as a QoS signaling
protocol) that arrives along the data path. In the second, called protocol) that arrives along the data path. In the second, called
"Push" mode, the Diameter server pro-actively sends a command to the "Push" mode, the Diameter server pro-actively sends a command to the
network element(s) to install QoS authorization state. This could be network element(s) to install QoS authorization state. This could be
triggered, for instance, by off-path signaling such as Session triggered, for instance, by off-path signaling, such as Session
Initiation Protocol (SIP) [RFC3261] call control. Initiation Protocol (SIP) [RFC3261] call control.
A set of command codes is specified that allows a single Diameter QoS A set of command codes is specified that allows a single Diameter QoS
application server to support both Pull and Push modes based on the application server to support both Pull and Push modes based on the
requirements of network technologies, deployment scenarios and end- requirements of network technologies, deployment scenarios and end-
host capabilities. In conjunction with parameters defined in the host capabilities. In conjunction with Diameter AVPs defined in
documents "Quality of Service Attributes for Diameter" [I-D.ietf-dime-qos-attributes] and in [RFC5624], this document
[I-D.ietf-dime-qos-attributes] and "Quality of Service Parameters for depicts basic call flow procedures used to establish, modify and
Usage with the AAA Framework" [I-D.ietf-dime-qos-parameters], this terminate a Diameter QoS application session.
document depicts basic call flow procedures used to establish, modify
and terminate a Diameter QoS application session. This document defines a number of Diameter-encoded Attribute Value
Pairs (AVPs), which are described using a modified version of the
Augmented Backus-Naur Form (ABNF), see [RFC3588].
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].
The following terms are used in this document: The following terms are used in this document:
AAA Cloud AAA Cloud
An infrastructure of Authentication, Authorization and Accounting An infrastructure of Authentication, Authorization and Accounting
(AAA) entities (clients, agents, servers) communicating via a AAA (AAA) entities (clients, agents, servers) communicating via a AAA
protocol over trusted, secure connections. It offers protocol over trusted, secure connections. It offers
authentication, authorization and accounting services to authentication, authorization and accounting services to
applications in flexible local and roaming scenarios. Diameter applications in local and roaming scenarios. Diameter and RADIUS
and RADIUS [RFC2865] are both widely deployed AAA protocols. [RFC2865] are both widely deployed AAA protocols.
Application Endpoint (AppE) Application Endpoint (AppE)
An Application Endpoint is an entity in an end-user device that An Application Endpoint is an entity in an end-user device that
exchanges signaling messages with Application Servers (see below) exchanges signaling messages with Application Servers or directly
or directly with other Application Endpoints. Based on the result with other Application Endpoints. Based on the result of this
of this signaling, the Endpoint may make a request for QoS from signaling, the Endpoint may make a request for QoS from the
the network. For example, a SIP User Agent is one kind of network. For example, a SIP User Agent is one kind of Application
Application Endpoint. Endpoint.
Application Server (AppS) Application Server (AppS)
An Application Server is an entity that exchanges signaling An Application Server is an entity that exchanges signaling
messages with an Application Endpoint (see above). It may be a messages with an Application Endpoint (see above). It may be a
source of authorization for QoS-enhanced application flows. For source of authorization for QoS-enhanced application flows. For
example, a SIP server is one kind of Application Server. example, a SIP server is one kind of Application Server.
Authorizing Entity (AE) Authorizing Entity (AE)
The Authorizing Entity is a Diameter server that supports the QoS The Authorizing Entity is a Diameter server that supports the QoS
application. It is responsible for authorizing QoS requests for a application. It is responsible for authorizing QoS requests for a
skipping to change at page 8, line 48 skipping to change at page 7, line 48
clarity. clarity.
In some deployment scenarios, NEs may request authorization through In some deployment scenarios, NEs may request authorization through
the AAA cloud based on an incoming QoS reservation request. The NE the AAA cloud based on an incoming QoS reservation request. The NE
will route the request to a designated AE. The AE will return the will route the request to a designated AE. The AE will return the
result of the authorization decision. In other deployment scenarios, result of the authorization decision. In other deployment scenarios,
the authorization will be initiated upon dynamic application state, the authorization will be initiated upon dynamic application state,
so that the request must be authenticated and authorized based on so that the request must be authenticated and authorized based on
information from one or more AppSs. After receiving the information from one or more AppSs. After receiving the
authorization request from the AppS or the NE, the AE decides the authorization request from the AppS or the NE, the AE decides the
appropriate mode (i.e. Push or Pull). The usage Push or Pull mode appropriate mode (i.e., Push or Pull). The usage Push or Pull mode
can be determined by the authorizing entity either statically or can be determined by the authorizing entity either statically or
dynamically. Static determination might be based on a configurable dynamically. Static determination might be based on a configurable
defined policy in the authorizing entity, while dynamic determination defined policy in the authorizing entity, while dynamic determination
might be based on information received from an application server. might be based on information received from an application server.
For Push mode, the authorizing entity needs to identify the For Push mode, the authorizing entity needs to identify the
appropriate NE(s) to which QoS authorization information needs to be appropriate NE(s) to which QoS authorization information needs to be
pushed. It might determine this based on information received from pushed. It might determine this based on information received from
the AppS, such as the IP addresses of media flows. the AppS, such as the IP addresses of media flows.
In some deployment scenarios, there is a mapping between access In some deployment scenarios, there is a mapping between access
network type and the service logic (e.g. selection of the Push or network type and the service logic (e.g., selection of the Push or
Pull mode, and other differentiated handling of the resource Pull mode, and other differentiated handling of the resource
admission and control). The access network type might be derived admission and control). The access network type might be derived
from the authorization request from the AppS or the NE, and in this from the authorization request from the AppS or the NE, and in this
case, the authorizing entity can identify the corresponding service case, the authorizing entity can identify the corresponding service
logic based on the mapping. logic based on the mapping.
If the interface between the NEs and the AAA cloud is identical If the interface between the NEs and the AAA cloud is identical
regardless of whether the AE communicates with an AppS or not, regardless of whether the AE communicates with an AppS or not,
routers are insulated from the details of particular applications and routers are insulated from the details of particular applications and
need not know that Application Servers are involved. Also, the AAA need not know that Application Servers are involved. Also, the AAA
skipping to change at page 10, line 10 skipping to change at page 9, line 10
3.1. Network Element Functional Model 3.1. Network Element Functional Model
Figure 2 depicts a logical operational model of resource management Figure 2 depicts a logical operational model of resource management
in a router. in a router.
+-------------------------------------------------------+ +-------------------------------------------------------+
| DIAMETER Client | | DIAMETER Client |
| Functionality | | Functionality |
| +---------------++-----------------++---------------+ | | +---------------++-----------------++---------------+ |
| | User || QoS Application || Accounting | | | | User || QoS Application || Accounting | |
| | Authentication|| Client || Client (e.g. | | | | Authentication|| Client || Client (e.g., | |
| | Client || (Authorization ||for QoS Traffic| | | | Client || (Authorization ||for QoS Traffic| |
| +---------------+| of QoS Requests)|+---------------+ | | +---------------+| of QoS Requests)|+---------------+ |
| +-----------------+ | | +-----------------+ |
+-------------------------------------------------------+ +-------------------------------------------------------+
^ ^
v v
+--------------+ +----------+ +--------------+ +----------+
|QoS Signaling | | Resource | |QoS Signaling | | Resource |
|Msg Processing|<<<<<>>>>>>>|Management| |Msg Processing|<<<<<>>>>>>>|Management|
+--------------+ +----------+ +--------------+ +----------+
skipping to change at page 16, line 40 skipping to change at page 15, line 40
will match the port numbers advertised in the earlier application will match the port numbers advertised in the earlier application
layer protocol interaction, to identify the right piece of policy layer protocol interaction, to identify the right piece of policy
information to be sent to the NE performing the QoS reservation in information to be sent to the NE performing the QoS reservation in
the QoS Authorization. response. the QoS Authorization. response.
3.3.2. Push Mode Schemes 3.3.2. Push Mode Schemes
The push mode can be further divided into two types: endpoint- The push mode can be further divided into two types: endpoint-
initiated and network-initiated. In the former case, the initiated and network-initiated. In the former case, the
authorization process is triggered by AppS in response to an explicit authorization process is triggered by AppS in response to an explicit
QoS request from an endpoint through application signaling, e.g. QoS request from an endpoint through application signaling, e.g.,
SIP; in the latter case, the authorization process is triggered by SIP; in the latter case, the authorization process is triggered by
the AppS without an explicit QoS request from an endpoint. the AppS without an explicit QoS request from an endpoint.
In the endpoint-initiated scheme, the QoS RRE (i.e., the AppE) In the endpoint-initiated scheme, the QoS RRE (i.e., the AppE)
determines the required application level QoS and sends a QoS request determines the required application level QoS and sends a QoS request
through an application signaling message. The AppS will extract through an application signaling message. The AppS will extract
application-level QoS information and trigger the authorization application-level QoS information and trigger the authorization
process to the AE. In the network-initiated scheme, the AE and/or process to the AE. In the network-initiated scheme, the AE and/or
AppS should derive and determine the QoS requirements according to AppS should derive and determine the QoS requirements according to
application attribute, subscription and endpoint's capability when application attribute, subscription and endpoint's capability when
skipping to change at page 19, line 21 skipping to change at page 18, line 21
such as loss of connectivity due to movement of a mobile node or such as loss of connectivity due to movement of a mobile node or
other reasons for packet loss, to the authorizing entity. other reasons for packet loss, to the authorizing entity.
Accounting Correlation Accounting Correlation
The Diameter QoS application MAY support the exchange of The Diameter QoS application MAY support the exchange of
sufficient information to allow for correlation between accounting sufficient information to allow for correlation between accounting
records generated by the NEs and accounting records generated by records generated by the NEs and accounting records generated by
an AppS. an AppS.
Interaction with other AAA Applications Interaction with other AAA Applications
Interaction with other AAA applications such as Diameter Network Interaction with other AAA applications, such as the Diameter
Access (NASREQ) application [RFC4005] is REQUIRED for exchange of Network Access (NASREQ) application [RFC4005], may be required for
authorization, authentication and accounting information. exchange of authorization, authentication and accounting
information.
In deployment scenarios where authentication of the QoS reservation In deployment scenarios where authentication of the QoS reservation
requesting entity (e.g., the user) is done by means outside the requesting entity (e.g., the user) is done by means outside the
Diameter QoS application protocol interaction, the AE is contacted Diameter QoS application protocol interaction, the AE is contacted
only with a request for QoS authorization. Authentication might have only with a request for QoS authorization. Authentication might have
taken place already via the interaction with the Diameter NASREQ taken place already via the interaction with the Diameter NASREQ
application or as part of the QoS signaling protocol (e.g., Transport application or as part of the QoS signaling protocol (e.g., Transport
Layer Security (TLS) [RFC5246] in the General Internet Signaling Layer Security (TLS) [RFC5246] in the General Internet Signaling
Transport (GIST) protocol [I-D.ietf-nsis-ntlp]). Transport (GIST) protocol [I-D.ietf-nsis-ntlp]).
skipping to change at page 21, line 47 skipping to change at page 20, line 47
The selection of Pull mode or Push mode operation is based on the The selection of Pull mode or Push mode operation is based on the
trigger of the QoS Authorization session. When a QoS-Authorization- trigger of the QoS Authorization session. When a QoS-Authorization-
Request (QAR, see Section 5.1) message with a new session ID is Request (QAR, see Section 5.1) message with a new session ID is
received, the AE operates in the Pull mode; when other triggers are received, the AE operates in the Pull mode; when other triggers are
received, the AE operates in the Push mode. Similarly, when a QoS- received, the AE operates in the Push mode. Similarly, when a QoS-
Install-Request (QIR, see Section 5.3} with a new session ID is Install-Request (QIR, see Section 5.3} with a new session ID is
received, the NE operates in the Push mode; when other triggers are received, the NE operates in the Push mode; when other triggers are
received, the NE operation in the Pull mode. received, the NE operation in the Pull mode.
The QoS authorization session is typically established per subscriber The QoS authorization session is typically established per subscriber
base (i.e.all requests with the same user ID), but it is also base (i.e., all requests with the same user ID), but it is also
possible to be established on per node or per request base. The possible to be established on per node or per request base. The
concurrent sessions between an NE and an AE are identified by concurrent sessions between an NE and an AE are identified by
different Session-ID. different Session-ID.
4.2.1. Session Establishment for Pull Mode 4.2.1. Session Establishment for Pull Mode
A request for a QoS reservation or local events received by a NE can A request for a QoS reservation or local events received by a NE can
trigger the initiation of a Diameter QoS authorization session. The trigger the initiation of a Diameter QoS authorization session. The
NE converts the required objects from the QoS signaling message to NE converts the required objects from the QoS signaling message to
Diameter AVPs and generates a QAR message. Diameter AVPs and generates a QAR message.
skipping to change at page 22, line 35 skipping to change at page 21, line 35
+------------------------------------------+------------------------+ +------------------------------------------+------------------------+
| Authorizing entity ID (e.g., | Destination-Host | | Authorizing entity ID (e.g., | Destination-Host |
| Destination-Host taken from | Destination-Realm | | Destination-Host taken from | Destination-Realm |
| authorization token, Destination-Realm | | | authorization token, Destination-Realm | |
| or derived from the NAI of the QoS | | | or derived from the NAI of the QoS | |
| requesting entity) | | | requesting entity) | |
| | | | | |
| Authorization Token Credentials of the | QoS-Authorization-Data | | Authorization Token Credentials of the | QoS-Authorization-Data |
| QoS requesting entity | User-Name | | QoS requesting entity | User-Name |
| | | | | |
| QoS parameters | QoS-Resources | | QoS-Resources (including QoS parameters) | |
+------------------------------------------+------------------------+ +------------------------------------------+------------------------+
Table 1: Mapping Input Data to QoS AVPs--Pull Mode Table 1: Mapping Input Data to QoS AVPs--Pull Mode
Authorization processing starts at the Diameter QoS server when it Authorization processing starts at the Diameter QoS server when it
receives the QAR. Based on the information in the QoS- receives the QAR. Based on the information in the QoS-
Authentication-Data, User-Name and QoS-Resources AVPs the server Authentication-Data, User-Name and QoS-Resources AVPs the server
determines the authorized QoS resources and flow state (enabled/ determines the authorized QoS resources and flow state (enabled/
disabled) from locally available information (e.g., policy disabled) from locally available information (e.g., policy
information that may be previously established as part of an information that may be previously established as part of an
skipping to change at page 24, line 13 skipping to change at page 23, line 13
via another QAR message for successful QoS resource reservation and via another QAR message for successful QoS resource reservation and
for final reserved QoS resources (see below). for final reserved QoS resources (see below).
One important piece of information returned from the Authorizing One important piece of information returned from the Authorizing
Entity is the authorization lifetime (carried inside the QAA). The Entity is the authorization lifetime (carried inside the QAA). The
authorization lifetime allows the NE to determine how long the authorization lifetime allows the NE to determine how long the
authorization decision is valid for this particular QoS reservation. authorization decision is valid for this particular QoS reservation.
A number of factors may influence the authorized session duration, A number of factors may influence the authorized session duration,
such as the user's subscription plan or currently available credits such as the user's subscription plan or currently available credits
at the user's account (see Section 8). The authorization duration is at the user's account (see Section 8). The authorization duration is
time-based as specified in [RFC3588]. For an extension of the time-based, as specified in [RFC3588]. For an extension of the
authorization period, a new QoS-Authorization-Request/Answer message authorization period, a new QoS-Authorization-Request/Answer message
exchange SHOULD be initiated. Further aspects of QoS authorization exchange SHOULD be initiated. Further aspects of QoS authorization
session maintenance is discussed in Section 4.3, Section 4.4 and session maintenance is discussed in Section 4.3, Section 4.4 and
Section 8. Section 8.
The indication of a successful QoS reservation and activation of the The indication of a successful QoS reservation and activation of the
data flow is provided by the transmission of a QAR message, which data flow is provided by the transmission of a QAR message, which
reports the parameters of the established QoS state: reserved reports the parameters of the established QoS state: reserved
resources, duration of the reservation, and identification of the QoS resources, duration of the reservation, and identification of the QoS
enabled flow/QoS signaling session. The Diameter QoS server enabled flow/QoS signaling session. The Diameter QoS server
skipping to change at page 25, line 16 skipping to change at page 24, line 16
+-----------------------------------------+-------------------------+ +-----------------------------------------+-------------------------+
| QoS-specific Input Data | Diameter AVPs | | QoS-specific Input Data | Diameter AVPs |
+-----------------------------------------+-------------------------+ +-----------------------------------------+-------------------------+
| Network Element ID | Destination-Host | | Network Element ID | Destination-Host |
| | Destination-Realm | | | Destination-Realm |
| | | | | |
| Authorization Token Credentials of the | QoS-Authorization-Data | | Authorization Token Credentials of the | QoS-Authorization-Data |
| QoS requesting entity | User-Name | | QoS requesting entity | User-Name |
| | | | | |
| QoS parameters | QoS-Resources | | QoS-Resources (including QoS | |
| parameters) | |
+-----------------------------------------+-------------------------+ +-----------------------------------------+-------------------------+
Table 2: Mapping Input Data to QoS AVPs--Push Mode Table 2: Mapping Input Data to QoS AVPs--Push Mode
Authorization processing starts at the Diameter QoS server when it Authorization processing starts at the Diameter QoS server when it
receives a request from a RRE through an AppS (e.g., SIP Invite) or receives a request from a RRE through an AppS (e.g., SIP Invite) or
is triggered by a local event (e.g., pre-configured timer). Based on is triggered by a local event (e.g., pre-configured timer). Based on
the received information the server determines the authorized QoS the received information the server determines the authorized QoS
resources and flow state (enabled/disabled) from locally available resources and flow state (enabled/disabled) from locally available
information (e.g., policy information that may be previously information (e.g., policy information that may be previously
skipping to change at page 27, line 15 skipping to change at page 26, line 15
One important piece of information from the AE is the authorization One important piece of information from the AE is the authorization
lifetime (carried inside the QIR). The authorization lifetime allows lifetime (carried inside the QIR). The authorization lifetime allows
the NE to determine how long the authorization decision is valid for the NE to determine how long the authorization decision is valid for
this particular QoS reservation. A number of factors may influence this particular QoS reservation. A number of factors may influence
the authorized session duration, such as the user's subscription plan the authorized session duration, such as the user's subscription plan
or currently available credits at the user's account (see Section 8). or currently available credits at the user's account (see Section 8).
The authorization duration is time-based as specified in [RFC3588]. The authorization duration is time-based as specified in [RFC3588].
For an extension of the authorization period, a new QoS-Install- For an extension of the authorization period, a new QoS-Install-
Request/Answer message or QoS-Authorization-Request/Answer message Request/Answer message or QoS-Authorization-Request/Answer message
exchange SHOULD be initiated. Further aspects of QoS authorization exchange SHOULD be initiated. Further aspects of QoS authorization
session maintenance is discussed in Section 4.3, Section 4.4 and session maintenance are discussed in Section 4.3, Section 4.4 and
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. In the case Multiple AEs of QoS negotiation along the data path. In the case Multiple AEs
control the same NE, the NE should make the selection on the control the same NE, the NE should make the selection on the
authorization decision to be enforced based on the priority of the authorization decision to be enforced based on the priority of the
request. 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
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 section 5.2 of [RFC3588]. In dynamic discovery as described in Section 5.2 of [RFC3588]. In
particular, the NE shall perform the relevant operation for Pull particular, the NE shall perform the relevant operation for Pull
mode; the AE shall 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
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 that is retrieves the location information of the peer node that is
associated with the affected user based on some index information associated with the affected user based on some index information
provided by the RRE. For instance, it can be the Authorization provided by the RRE. For instance, it can be the Authorization
Entity's ID stored in the authorization token, the end-user's Entity's ID stored in the authorization token, the end-user's
identity (e.g., NAI [RFC4282]) or a globally routable IP address. identity (e.g., NAI [RFC4282]) or a globally routable IP address.
4.3. Session Re-authorization 4.3. Session Re-authorization
skipping to change at page 33, line 7 skipping to change at page 32, line 7
| +--------+--------------+ | +--------+--------------+
| QoS Responder | QoS Responder
| Node | Node
|<---------QoS-Response----....----+ |<---------QoS-Response----....----+
| | | |
Figure 11: Server-Side Initiated Session Termination Figure 11: Server-Side Initiated Session Termination
5. QoS Application Messages 5. QoS Application Messages
The Diameter QoS Application requires the definition of new mandatory The Diameter QoS application requires the definition of new mandatory
AVPs and Command-codes (see Section 3 of [RFC3588]). Four new AVPs and Command-codes (see Section 3 of [RFC3588]). Four new
Diameter messages are defined along with Command-Codes whose values Diameter messages are defined along with Command-Codes whose values
MUST be supported by all Diameter implementations that conform to MUST be supported by all Diameter implementations that conform to
this specification. this specification.
+---------------------------+---------+--------+-------------+ +---------------------------+---------+--------+-------------+
| Command Name | Abbrev. | Code | Reference | | Command Name | Abbrev. | Code | Reference |
+---------------------------+---------+--------+-------------+ +---------------------------+---------+--------+-------------+
| QoS-Authorization-Request | QAR | [TBD1] | Section 5.1 | | QoS-Authorization-Request | QAR | [TBD1] | Section 5.1 |
| | | | | | | | | |
skipping to change at page 33, line 49 skipping to change at page 32, line 49
| Abort-Session-Answer | ASA | 274 | [RFC3588] | | Abort-Session-Answer | ASA | 274 | [RFC3588] |
| | | | | | | | | |
| Session-Term-Request | STR | 275 | [RFC3588] | | Session-Term-Request | STR | 275 | [RFC3588] |
| | | | | | | | | |
| Session-Term-Answer | STA | 275 | [RFC3588] | | Session-Term-Answer | STA | 275 | [RFC3588] |
+-----------------------+---------+------+-----------+ +-----------------------+---------+------+-----------+
Table 4: Diameter Base Commands Table 4: Diameter Base Commands
Diameter nodes conforming to this specification MAY advertise support Diameter nodes conforming to this specification MAY advertise support
for the Diameter QoS Application by including the value of [TBD5] in for the Diameter QoS application by including the value of [TBD5] in
the Auth-Application-Id or the Acct-Application-Id AVP of the the Auth-Application-Id or the Acct-Application-Id AVP of the
Capabilities-Exchange-Request and Capabilities-Exchange-Answer Capabilities-Exchange-Request and Capabilities-Exchange-Answer
commands, see [RFC3588]. commands, see [RFC3588].
The value of {TBD5] MUST be used as the Application-Id in all QAR/QAA The value of {TBD5] MUST be used as the Application-Id in all QAR/QAA
and QIR/QIA commands. and QIR/QIA commands.
The value of zero (0) SHOULD be used as the Application-Id in all The value of zero (0) SHOULD be used as the Application-Id in all
STR/STA, ASR/ASA, and RAR/RAA commands, because these commands are STR/STA, ASR/ASA, and RAR/RAA commands.
defined in the Diameter base protocol and no additional mandatory
AVPs for those commands are defined in this document.
5.1. QoS-Authorization Request (QAR) 5.1. QoS-Authorization Request (QAR)
The QoS-Authorization-Request message (QAR) indicated by the Command- The QoS-Authorization-Request message (QAR) indicated by the Command-
Code field (see Section 3 of [RFC3588]) set to [TBD1] and 'R' bit set Code field (see Section 3 of [RFC3588]) set to [TBD1] and 'R' bit set
in the Command Flags field is used by NEs to request quality of in the Command Flags field is used by NEs to request quality of
service related resource authorization for a given flow. service related resource authorization for a given flow.
The QAR message MUST carry information for signaling session The QAR message MUST carry information for signaling session
identification, AE identification, information about the requested identification, AE identification, information about the requested
skipping to change at page 34, line 38 skipping to change at page 33, line 36
<QoS-Request> ::= < Diameter Header: [TBD1], REQ, PXY > <QoS-Request> ::= < Diameter Header: [TBD1], REQ, PXY >
< Session-Id > < Session-Id >
{ Auth-Application-Id } { Auth-Application-Id }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
{ Auth-Request-Type } { Auth-Request-Type }
[ Destination-Host ] [ Destination-Host ]
[ User-Name ] [ User-Name ]
* [ QoS-Resources ] * [ QoS-Resources ]
[ QoS-Semantics ]
[ QoS-Authorization-Data ] [ QoS-Authorization-Data ]
[ Bound-Auth-Session-Id ] [ Bound-Auth-Session-Id ]
* [ AVP ] * [ AVP ]
5.2. QoS-Authorization Answer (QAA) 5.2. QoS-Authorization Answer (QAA)
The QoS-Authorization-Answer message (QAA), indicated by the Command- The QoS-Authorization-Answer message (QAA), indicated by the Command-
Code field set to [TBD2] and 'R' bit cleared in the Command Flags Code field set to [TBD2] and 'R' bit cleared in the Command Flags
field is sent in response to the QoS-Authorization-Request message field is sent in response to the QoS-Authorization-Request message
(QAR). If the QoS authorization request is successfully authorized, (QAR). If the QoS authorization request is successfully authorized,
skipping to change at page 35, line 45 skipping to change at page 34, line 43
<QoS-Install-Request> ::= < Diameter Header: [TBD3], REQ, PXY > <QoS-Install-Request> ::= < Diameter Header: [TBD3], REQ, PXY >
< Session-Id > < Session-Id >
{ Auth-Application-Id } { Auth-Application-Id }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
{ Auth-Request-Type } { Auth-Request-Type }
[ Destination-Host ] [ Destination-Host ]
* [ QoS-Resources ] * [ QoS-Resources ]
[ QoS-Semantics ]
[ Session-Timeout ] [ Session-Timeout ]
[ Authorization-Session-Lifetime ] [ Authorization-Session-Lifetime ]
[ Authorization-Grace-Period ] [ Authorization-Grace-Period ]
[ Authorization-Session-Volume ] [ Authorization-Session-Volume ]
* [ AVP ] * [ AVP ]
5.4. QoS-Install Answer (QIA) 5.4. QoS-Install Answer (QIA)
The QoS-Install Answer message (QIA), indicated by the Command-Code The QoS-Install Answer message (QIA), indicated by the Command-Code
field set to [TBD4] and 'R' bit cleared in the Command Flags field is field set to [TBD4] and 'R' bit cleared in the Command Flags field is
skipping to change at page 37, line 5 skipping to change at page 36, line 5
sent by the AE to the NE in order to initiate the QoS re- sent by the AE to the NE in order to initiate the QoS re-
authorization from DQA server side. authorization from DQA server side.
If the RAR command is received by the NE without any parameters of If the RAR command is received by the NE without any parameters of
the re-authorized QoS state, the NE MUST initiate a QoS re- the re-authorized QoS state, the NE MUST initiate a QoS re-
authorization by sending a QoS-Authorization-Request (QAR) message authorization by sending a QoS-Authorization-Request (QAR) message
towards the AE. towards the AE.
The message format is defined as follows: The message format is defined as follows:
<Re-Auth-Request> ::= < Diameter Header: 258, REQ, PXY > <RAR> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id > < Session-Id >
{ Auth-Application-Id } { Origin-Host }
{ Origin-Host } { Origin-Realm }
{ Origin-Realm } { Destination-Realm }
{ Destination-Realm } { Destination-Host }
{ Auth-Request-Type } { Auth-Application-Id }
{ Destination-Host } { Re-Auth-Request-Type }
* [ QoS-Resources ] [ User-Name ]
[ QoS-Semantics ] [ Origin-State-Id ]
[ Session-Timeout ] * [ Proxy-Info ]
[ Authorization-Session-Lifetime ] * [ Route-Record ]
[ Authorization-Grace-Period ] * [ QoS-Resources ]
[ Authorization-Session-Volume ] [ Session-Timeout ]
* [ AVP ] [ Authorization-Session-Lifetime ]
[ Authorization-Grace-Period ]
[ Authorization-Session-Volume ]
* [ AVP ]
5.6. Re-Auth-Answer (RAA) 5.6. Re-Auth-Answer (RAA)
The Re-Auth-Answer message (RAA), indicated by the Command-Code field The Re-Auth-Answer message (RAA), indicated by the Command-Code field
set to 258 and the 'R' bit cleared in the Command Flags field, is set to 258 and the 'R' bit cleared in the Command Flags field, is
sent by the NE to the AE in response to the RAR command. sent by the NE to the AE in response to the RAR command.
The message format is defined as follows: The message format is defined as follows:
<Re-Auth-Answer> ::= < Diameter Header: 258, PXY > <RAA> ::= < Diameter Header: 258, PXY >
< Session-Id > < Session-Id >
{ Auth-Application-Id } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Result-Code } [ User-Name ]
* [ QoS-Resources ] [ Origin-State-Id ]
* [ AVP ] [ Error-Message ]
[ Error-Reporting-Host ]
* [ Failed-AVP ]
* [ Redirect-Host ]
[ Redirect-Host-Usage ]
[ Redirect-Host-Cache-Time ]
* [ Proxy-Info ]
* [ QoS-Resources ]
* [ AVP ]
6. QoS Application State Machine 6. QoS Application State Machine
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
skipping to change at page 40, line 17 skipping to change at page 39, line 17
Each of the AVPs identified in the QoS-Authorization-Request/Answer Each of the AVPs identified in the QoS-Authorization-Request/Answer
and QoS-Install-Request/Answer messages and the assignment of their and QoS-Install-Request/Answer messages and the assignment of their
value(s) is given in this section. value(s) is given in this section.
7.1. Reused Base Protocol AVPs 7.1. Reused Base Protocol AVPs
The QoS application uses a number of session management AVPs, defined The QoS application uses a number of session management AVPs, defined
in the Base Protocol ([RFC3588]). in the Base Protocol ([RFC3588]).
Attribute Name AVP Code Reference [RFC3588] Attribute Name AVP Code Reference [RFC3588]
Origin-Host 264 Section 6.3 Origin-Host 264 Section 6.3
Origin-Realm 296 Section 6.4 Origin-Realm 296 Section 6.4
Destination-Host 293 Section 6.5 Destination-Host 293 Section 6.5
Destination-Realm 283 Section 6.6 Destination-Realm 283 Section 6.6
Auth-Application-Id 258 Section 6.8 Auth-Application-Id 258 Section 6.8
Result-Code 268 Section 7.1 Result-Code 268 Section 7.1
Auth-Request-Type 274 Section 8.7 Auth-Request-Type 274 Section 8.7
Session-Id 263 Section 8.8 Session-Id 263 Section 8.8
Authorization-Lifetime 291 Section 8.9 Authorization-Lifetime 291 Section 8.9
Authorization-Grace-Period 276 Section 8.10 Authorization-Grace-Period 276 Section 8.10
Session-Timeout 27 Section 8.13 Session-Timeout 27 Section 8.13
User-Name 1 Section 8.14 User-Name 1 Section 8.14
The Auth-Application-Id AVP (AVP Code 258) is assigned by IANA to The Auth-Application-Id AVP (AVP Code 258) is assigned by IANA to
Diameter applications. The value of the Auth-Application-Id for the Diameter applications. The value of the Auth-Application-Id for the
Diameter QoS application is TBD. Diameter QoS application is TBD.
7.2. QoS Application Defined AVPs 7.2. QoS Application Defined AVPs
This document reuses the AVPs defined in Section 4 of This document reuses the AVPs defined in Section 4 of
[I-D.ietf-dime-qos-attributes]. [I-D.ietf-dime-qos-attributes].
skipping to change at page 45, line 36 skipping to change at page 44, line 36
AE verifies the requested QoS against the QoS resources negotiated AE verifies the requested QoS against the QoS resources negotiated
for the service session and replies with QoS-Authorization answer for the service session and replies with QoS-Authorization answer
(QAA) message. It carries the authorization result (Result-Code AVP) (QAA) message. It carries the authorization result (Result-Code AVP)
and the description of the authorized QoS parameters (QoS-Resources and the description of the authorized QoS parameters (QoS-Resources
AVP), as well as duration of the authorization session AVP), as well as duration of the authorization session
(Authorization-Lifetime AVP). (Authorization-Lifetime AVP).
The NE interacts with the traffic control function and installs the The NE interacts with the traffic control function and installs the
authorized QoS resources and forwards the QoS NSLP Reserve message authorized QoS resources and forwards the QoS NSLP Reserve message
further along the data path. Moreover, the NE may serve as a further along the data path. Moreover, the NE may serve as a
signaling proxy and process the QoS signaling (e.g. initiation or signaling proxy and process the QoS signaling (e.g., initiation or
termination of QoS signaling) based on the QoS decision received from termination of QoS signaling) based on the QoS decision received from
the authorizing entity. the authorizing entity.
9.2. Example Call Flow for Push Mode 9.2. Example Call Flow for Push Mode
This section presents an example of the interaction between the end- This section presents an example of the interaction between the end-
host and Diameter QoS application entities using Push mode. The host and Diameter QoS application entities using Push mode. The
application layer signaling is, in this example, provided using SIP. application layer signaling is, in this example, provided using SIP.
Signaling for a QoS resource reservation is done using the QoS NSLP. Signaling for a QoS resource reservation is done using the QoS NSLP.
The authorization of the QoS reservation request is done by the The authorization of the QoS reservation request is done by the
skipping to change at page 47, line 34 skipping to change at page 46, line 34
The DQA server may obtain the info of peer DQA client from pre- The DQA server may obtain the info of peer DQA client from pre-
configured information or query the DNS based on Host A's identity or configured information or query the DNS based on Host A's identity or
IP address (In this case a DQA server is co-located with a SIP server IP address (In this case a DQA server is co-located with a SIP server
and a DQA client is co-located with a NE). The identity of Network and a DQA client is co-located with a NE). The identity of Network
Element is put into the Destination-Host AVP, the description of the Element is put into the Destination-Host AVP, the description of the
QoS resources is included into QoS-Resources AVP, as well as duration QoS resources is included into QoS-Resources AVP, as well as duration
of the authorization session (Authorization-Lifetime AVP). The NE of the authorization session (Authorization-Lifetime AVP). The NE
interacts with the traffic control function and reserves the interacts with the traffic control function and reserves the
authorized QoS resources accordingly, for instance, the NE may serve authorized QoS resources accordingly, for instance, the NE may serve
as a signaling proxy and process the QoS signaling (e.g. initiation as a signaling proxy and process the QoS signaling (e.g., initiation
or termination of QoS signaling) based on the QoS decision received or termination of QoS signaling) based on the QoS decision received
from the authorizing entity. from the authorizing entity.
With successful QoS authorization, the SDP offer in SIP Invite is With successful QoS authorization, the SDP offer in SIP Invite is
forwarded to Host B. Host B sends back a 18x (ringing) message forwarded to Host B. Host B sends back a 18x (ringing) message
towards Host A and processes the SDP. Once Host B accepts the call, towards Host A and processes the SDP. Once Host B accepts the call,
it sends back a 200 OK, in which it includes description of the it sends back a 200 OK, in which it includes description of the
accepted session parameters (i.e. SDP answer). accepted session parameters (i.e., SDP answer).
The DQA server may verify the accepted QoS against the pre-authorized The DQA server may verify the accepted QoS against the pre-authorized
QoS resources, and sends a Diameter RAR message to the DQA client in QoS resources, and sends a Diameter RAR message to the DQA client in
the NE for activating the installed policies and commit the resource the NE for activating the installed policies and commit the resource
allocation. With successful QoS enforcement, the 200 OK is forwarded allocation. With successful QoS enforcement, the 200 OK is forwarded
towards Host A. towards Host A.
Note that the examples above show a sender-initiated reservation from Note that the examples above show a sender-initiated reservation from
the end host towards the corresponding node and a receiver-initiated the end host towards the corresponding node and a receiver-initiated
reservation from the correspondent node towards the end host. reservation from the correspondent node towards the end host.
10. IANA Considerations 10. IANA Considerations
This section contains the namespaces that have either been created in This section contains the namespaces that have either been created in
this specification or had their values assigned to existing this specification or had their values assigned to existing
namespaces managed by IANA. namespaces managed by IANA.
10.1. AVP Codes 10.1. AVP Codes
IANA is requested to allocate two AVP codes to the following: IANA is requested to allocate two AVP codes to the registry defined
in [RFC3588]:
Registry: Registry:
AVP Code Attribute Name Reference AVP Code AVP Name Reference
----------------------------------------------------------- -----------------------------------------------------------
to be assigned QoS-Authorization-Data Section 7.2 to be assigned QoS-Authorization-Data Section 7.2
to be assigned Bound-Auth-Session-Id Section 7.2 to be assigned Bound-Auth-Session-Id Section 7.2
10.2. AVP Specific Values 10.2. Application IDs
IANA is requested to allocate the following sub-registry values.
Sub-registry: Auth-Application-Id AVP Values (code 258)
Registry:
AVP Values Attribute Name Reference
------------- -------------------------------------------
to be assigned DIAMETER-QOS-NOSUPPORT Section 5
to be assigned DIAMETER-QOS-SUPPORT Section 5
Sub-registry: Acct-Application-Id AVP Values (code 259)
Registry:
AVP Values Attribute Name Reference
------------- -------------------------------------------
to be assigned DIAMETER-QOS-NOSUPPORT Section 5
to be assigned DIAMETER-QOS-SUPPORT Section 5
10.3. AVP Flags
There are no new AVP flags defined for either the QoS-Authorization-
Data AVP or the Bound-Ath-Session-ID AVP.
10.4. Application IDs
IANA is requested to allocate the following application ID using the IANA is requested to allocate the following application ID from the
next value from the 7-16777215 range. registry defined in [RFC3588] (using the next available value from
the 7-16777215 range).
Registry: Registry:
ID values Name Reference ID values Name Reference
----------------------------------------------------------- -----------------------------------------------------------
to be assigned Diameter QoS application Section 5 to be assigned Diameter QoS application Section 5
10.5. Command Codes 10.3. Command Codes
IANA is requested to allocate command code values for the following IANA is requested to allocate command code values from the registry
from the range 289-299. defined in [RFC3588].
Registry: Registry:
Code Value Name Reference Code Value Name Reference
----------------------------------------------------------- -----------------------------------------------------------
TBD QoS-Authorization-Request (QAR) Section 5.1 TBD QoS-Authorization-Request (QAR) Section 5.1
TBD QoS-Authorization-Answer (QAA) Section 5.2 TBD QoS-Authorization-Answer (QAA) Section 5.2
TBD QoS-Install-Request (QIR) Section 5.3 TBD QoS-Install-Request (QIR) Section 5.3
TBD QoS-Install-Answer (QIA) Section 5.4 TBD QoS-Install-Answer (QIA) Section 5.4
11. Security Considerations 11. Security Considerations
This document describes a mechanism for performing authorization of a This document describes a mechanism for performing authorization of a
QoS reservation at a third party entity. The Authorizing Entity QoS reservation at a third party entity. The Authorizing Entity
skipping to change at page 52, line 13 skipping to change at page 50, line 13
are application specific and part of the overal implementation. are application specific and part of the overal implementation.
12. Acknowledgements 12. Acknowledgements
The authors would like to thank John Loughney and Allison Mankin for The authors would like to thank John Loughney and Allison Mankin for
their input to this document. In September 2005 Robert Hancock, their input to this document. In September 2005 Robert Hancock,
Jukka Manner, Cornelia Kappler, Xiaoming Fu, Georgios Karagiannis and Jukka Manner, Cornelia Kappler, Xiaoming Fu, Georgios Karagiannis and
Elwyn Davies provided a detailed review. Robert also provided us Elwyn Davies provided a detailed review. Robert also provided us
with good feedback earlier in 2005. Jerry Ash provided us review with good feedback earlier in 2005. Jerry Ash provided us review
comments late 2005/early 2006. Rajith R provided some inputs to the comments late 2005/early 2006. Rajith R provided some inputs to the
document early 2007 document early 2007.
We would also like to thanks Alexey Melnikov, Adrian Farrel, and
Robert Sparks for their IESG reviews.
13. Contributors 13. Contributors
The authors would like to thank Tseno Tsenov and Frank Alfano for The authors would like to thank Tseno Tsenov and Frank Alfano for
starting the Diameter Quality of Service work within the IETF, for starting the Diameter Quality of Service work within the IETF, for
your significant draft contributions and for being the driving force your significant draft contributions and for being the driving force
for the first few draft versions. for the first few draft versions.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-dime-qos-attributes] [I-D.ietf-dime-qos-attributes]
Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M., Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, M.,
and A. Lior, "Quality of Service Attributes for Diameter", and A. Lior, "Traffic Classification and Quality of
draft-ietf-dime-qos-attributes-14 (work in progress), Service Attributes for Diameter",
October 2009. draft-ietf-dime-qos-attributes-15 (work in progress),
December 2009.
[I-D.ietf-dime-qos-parameters]
Korhonen, J., Tschofenig, H., and E. Davies, "Quality of
Service Parameters for Usage with Diameter",
draft-ietf-dime-qos-parameters-11 (work in progress),
May 2009.
[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.
[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.
[RFC5624] Korhonen, J., Tschofenig, H., and E. Davies, "Quality of
Service Parameters for Usage with Diameter", RFC 5624,
August 2009.
14.2. Informative References 14.2. Informative References
[I-D.ietf-nsis-ntlp] [I-D.ietf-nsis-ntlp]
Schulzrinne, H. and M. Stiemerling, "GIST: General Schulzrinne, H. and M. Stiemerling, "GIST: General
Internet Signalling Transport", draft-ietf-nsis-ntlp-20 Internet Signalling Transport", draft-ietf-nsis-ntlp-20
(work in progress), June 2009. (work in progress), June 2009.
[I-D.ietf-nsis-qos-nslp] [I-D.ietf-nsis-qos-nslp]
Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Manner, J., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18
(work in progress), February 2008. (work in progress), January 2010.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load [RFC2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997. Network Element Service", RFC 2211, September 1997.
[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification
of Guaranteed Quality of Service", RFC 2212, of Guaranteed Quality of Service", RFC 2212,
 End of changes. 50 change blocks. 
193 lines changed or deleted 182 lines changed or added

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