draft-ietf-dime-diameter-qos-14.txt   draft-ietf-dime-diameter-qos-15.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: August 25, 2010 H. Tschofenig Expires: September 8, 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
February 21, 2010 March 7, 2010
Diameter Quality of Service Application Diameter Quality of Service Application
draft-ietf-dime-diameter-qos-14.txt draft-ietf-dime-diameter-qos-15.txt
Abstract Abstract
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 to interact with Diameter servers application allows network elements to interact with Diameter servers
when allocating QoS resources in the network. In particular, two when allocating QoS resources in the network. In particular, two
modes of operation, namely "Pull" and "Push", are defined. modes of operation, namely "Pull" and "Push", are defined.
Status of this Memo Status of this Memo
skipping to change at page 1, line 49 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 August 25, 2010. This Internet-Draft will expire on September 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 13 skipping to change at page 3, line 13
5.4. QoS-Install Answer (QIA) . . . . . . . . . . . . . . . . . 35 5.4. QoS-Install Answer (QIA) . . . . . . . . . . . . . . . . . 35
5.5. Re-Auth-Request (RAR) . . . . . . . . . . . . . . . . . . 35 5.5. Re-Auth-Request (RAR) . . . . . . . . . . . . . . . . . . 35
5.6. Re-Auth-Answer (RAA) . . . . . . . . . . . . . . . . . . . 36 5.6. Re-Auth-Answer (RAA) . . . . . . . . . . . . . . . . . . . 36
6. QoS Application State Machine . . . . . . . . . . . . . . . . 37 6. QoS Application State Machine . . . . . . . . . . . . . . . . 37
6.1. Supplemented States for Push Mode . . . . . . . . . . . . 37 6.1. Supplemented States for Push Mode . . . . . . . . . . . . 37
7. QoS Application AVPs . . . . . . . . . . . . . . . . . . . . . 39 7. QoS Application AVPs . . . . . . . . . . . . . . . . . . . . . 39
7.1. Reused Base Protocol AVPs . . . . . . . . . . . . . . . . 39 7.1. Reused Base Protocol AVPs . . . . . . . . . . . . . . . . 39
7.2. QoS Application Defined AVPs . . . . . . . . . . . . . . . 39 7.2. QoS Application Defined AVPs . . . . . . . . . . . . . . . 39
8. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 41 8. Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9.1. Example Call Flow for Pull Mode . . . . . . . . . . . . . 42 9.1. Example Call Flow for Pull Mode (Success Case) . . . . . . 42
9.2. Example Call Flow for Push Mode . . . . . . . . . . . . . 44 9.2. Example Call Flow for Pull Mode (Failure Case) . . . . . . 44
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 9.3. Example Call Flow for Push Mode . . . . . . . . . . . . . 47
10.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 47 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50
10.2. Application IDs . . . . . . . . . . . . . . . . . . . . . 47 10.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 50
10.3. Command Codes . . . . . . . . . . . . . . . . . . . . . . 47 10.2. Application IDs . . . . . . . . . . . . . . . . . . . . . 50
11. Security Considerations . . . . . . . . . . . . . . . . . . . 48 10.3. Command Codes . . . . . . . . . . . . . . . . . . . . . . 50
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 11. Security Considerations . . . . . . . . . . . . . . . . . . . 51
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 51 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 53
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 54
14.1. Normative References . . . . . . . . . . . . . . . . . . . 52 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
14.2. Informative References . . . . . . . . . . . . . . . . . . 52 14.1. Normative References . . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 14.2. Informative References . . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57
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
skipping to change at page 42, line 7 skipping to change at page 42, line 7
the QoS resources reserved. It should be noted that the two sessions the QoS resources reserved. It should be noted that the two sessions
(authorization and accounting) have independent management by the (authorization and accounting) have independent management by the
Diameter base protocol, which allows for finalizing the accounting Diameter base protocol, which allows for finalizing the accounting
session after the end of the authorization session. session after the end of the authorization session.
The detailed QoS accounting procedures are out of scope in this The detailed QoS accounting procedures are out of scope in this
document. document.
9. Examples 9. Examples
9.1. Example Call Flow for Pull Mode 9.1. Example Call Flow for Pull Mode (Success Case)
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 Pull mode. The host and Diameter QoS application entities using Pull 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
Diameter QoS application (DQA). Diameter QoS application (DQA).
End-Host SIP Server Correspondent End-Host SIP Proxy Correspondent
requesting QoS (DQA Server) Node requesting QoS (DQA Server) Node
| | | | | |
..|....Application layer SIP signaling.......|..............|.. ..|....Application layer SIP signaling.......|..............|..
. | Invite (SDP) | | . . | Invite (SDP) | | .
. +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> | . . +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> | .
. | 100 Trying | | . . | 100 Trying | | .
. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ Invite (SDP)| . . <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ Invite (SDP)| .
. | +-.-.-.....-.-.> . . | +-.-.-.....-.-.> .
. | | 180 SDP' | . . | | 180 SDP' | .
skipping to change at page 43, line 47 skipping to change at page 43, line 47
| | | | | |
.-.-.-.-. SIP signaling .-.-.-.-. SIP signaling
--------- QoS NSLP signaling --------- QoS NSLP signaling
- - - - - Diameter QoS Application messages - - - - - Diameter QoS Application messages
========= Mapping of objects between QoS and AAA protocol ========= Mapping of objects between QoS and AAA protocol
Figure 12: QoS Authorization Example - Pull Mode Figure 12: QoS Authorization Example - Pull Mode
The communication starts with SIP signaling between the two end The communication starts with SIP signaling between the two end
points and the SIP server for negotiation and authorization of the points and the SIP proxy for negotiation and authorization of the
requested service and its parameters (see Figure 12). As a part of requested service and its parameters (see Figure 12). As a part of
the process, the SIP server verifies whether the user at Host A is the process, the SIP proxy verifies whether the user at Host A is
authorized to use the requested service (and potentially the ability authorized to use the requested service (and potentially the ability
to be charged for the service usage). Negotiated session parameters to be charged for the service usage). Negotiated session parameters
are provided to the end host. are provided to the end host.
Subsequently, Host A initiates a QoS signaling message towards Host Subsequently, Host A initiates a QoS signaling message towards Host
B. It sends a QoS NSLP Reserve message, in which it includes B. It sends a QoS NSLP Reserve message, in which it includes
description of the required QoS (QSPEC object) and authorization data description of the required QoS (QSPEC object) and authorization data
for negotiated service session (part of the POLICY_DATA object). for negotiated service session (part of the POLICY_DATA object).
Authorization data includes, as a minimum, the identity of the AE Authorization data includes, as a minimum, the identity of the AE
(e.g., the SIP server) and an identifier of the application service (e.g., the SIP proxy) and an identifier of the application service
session for which QoS resources are requested. session for which QoS resources are requested.
A QoS NSLP Reserve message is intercepted and processed by the first A QoS NSLP Reserve message is intercepted and processed by the first
QoS aware Network Element. The NE uses the Diameter QoS application QoS aware Network Element. The NE uses the Diameter QoS application
to request authorization for the received QoS reservation request. to request authorization for the received QoS reservation request.
The identity of the AE (in this case the SIP server that is co- The identity of the AE (in this case the SIP server that is co-
located with a Diameter server) is put into the Destination-Host AVP, located with a Diameter server) is put into the Destination-Host AVP,
any additional session authorization data is encapsulated into the any additional session authorization data is encapsulated into the
QoS-Authorization-Data AVP and the description of the QoS resources QoS-Authorization-Data AVP and the description of the QoS resources
is included into QoS-Resources AVP. These AVPs are included into a is included into QoS-Resources AVP. These AVPs are included into a
skipping to change at page 44, line 40 skipping to change at page 44, line 40
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 Pull Mode (Failure Case)
This section presents an example of the interaction between the end- This section illustrates the example shown Section 9.2 that fails due
to an authorization failure. Failures can occur in various steps
throughout the protocol execution and in this example we assume that
the Diameter QAR request processed by the Diameter server leads to an
unsuccessful result. The QAA message reponds, in this example, with
a permanent error "DIAMETER_AUTHORIZATION_REJECTED" (5003)set in the
Result-Code AVP. When the NE receives this response it discontinues
the QoS reservation signaling downstream and provides an error
message back to the end host that initiated the QoS signaling
request. The QoS NSLP RESPONSE signaling message would in this case
carry a INFO_SPEC object indicating the permanent failure as
"Authorization failure" (0x02).
End-Host SIP Proxy Correspondent
requesting QoS (DQA Server) Node
| | |
..|...................SIP Signaling..........|..............|..
. | Invite (SDP) | | .
. +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> | .
. | 100 Trying | | .
. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ Invite (SDP)| .
. | +-.-.-.....-.-.> .
. | | 180 SDP' | .
. | <-.-.-.....-.-.+ .
. | +--------+--------+ | .
. | |Authorize session| | .
. | | parameters | | .
. | 180 (Session parameters) +--------+--------+ | .
. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-+ | .
..|..........................................|... ..........|..
| | |
| +------------+ | |
| | NE | | |
| |(DQA Client)| | |
| +------+-----+ | |
| | | |
|QoS NSLP Reserve | | |
+------------------> QAR | |
| (POLICY_DATA>v +- - - - -<<AAA>>- - - -> |
| QSPEC) v >===>(Destination-Host, | |
| v >=======>QoS-Authorization-Data++------------+ |
| >===========>QoS-Resources) |Authorize | |
| | |QoS resources| |
| | ++------------+ |
| | QAA | |
| <- - - - -<<AAA>>- - - -+ |
| |(Result-Code = 5003) | |
| | | |
|QoS NSLP Response | | |
|(with error 0x02) | | |
<------------------+ | |
| | | |
| | | |
.-.-.-.-. SIP signaling
--------- QoS NSLP signaling
- - - - - Diameter QoS Application messages
========= Mapping of objects between QoS and AAA protocol
Figure 13: QoS Authorization Example - Pull Mode (Failure Case)
9.3. Example Call Flow for Push Mode
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
Diameter QoS application (DQA). Diameter QoS application (DQA).
End-Host NE SIP Server Correspondent End-Host NE SIP Proxy Correspondent
requesting QoS (DQA Client) (DQA Server) Node requesting QoS (DQA Client) (DQA Server) Node
| | | | | | | |
..|....Application layer SIP signaling..........|..............|.. ..|..................|...SIP Signaling..........|..............|..
. | Invite(SDP offer)| | | . . | Invite(SDP Offer)| | | .
. +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.> | . . +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+-.-.-.-.-.-.->| .
. | 100 Trying | | | . . | | | 180 | .
. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+ | . . |<-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+-.-.-.-.-.-.-.| .
. |.............................................|..............| . ..|.............................................|..............|..
| | +---------+-------------+| | | +---------+-------------+|
| | | Authorize request || | | | Authorize Request ||
| | | Keep session data || | | | Keep Session Data ||
| | |/Authz-time,Session-Id/|| | | |/Authz-time,Session-Id/||
| | +---------+-------------+| | | +---------+-------------+|
| | | | | | | |
| |<-- - -- - QIR - -- - -- -+ | | |<-- - -- - QIR - -- - -- -+ |
| |(Initial Request,Decision | | | |(Initial Request,Decision | |
| |(QoS-Resources,Authz-time)| | | |(QoS-Resources,Authz-time)| |
| +-------+---------+ | | | +-------+---------+ | |
| |Install QoS state| | | | |Install QoS State| | |
| | + | | | | | + | | |
| | Authz. session | | | | | Authz. Session | | |
| | /Authz-time/ | | | | | /Authz-time/ | | |
| +-------+---------+ | | | +-------+---------+ | |
| + - - -- - QIA - - - - - ->| | | + - - -- - QIA - - - - - ->| |
| | (Result-Code, | | | | (Result-Code, | |
| | QoS-Resources) | | | | QoS-Resources) | |
| | +----------+------------+ | | | +----------+------------+ |
| | | Report for successful | | | | | Successful | |
| | | QoS reservation | | | | | QoS Reservation | |
| | |Update of reserved QoS | |
| | | resources | |
| | +----------+------------+ | | | +----------+------------+ |
. | | | Invite (SDP) | . ..|.............................................|..............|..
. | | +-.-.-.....-.-.> . . | | | | .
. | 180 (Ringing) | | .
. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.<.-.-.-.-.-.-.-+ .
. | | | 200 OK (SDP)| . . | | | 200 OK (SDP)| .
. | | <-.-.-.....-.-.+ . . | | <-.-.-.....-.-.+ .
| | +--------+-----------+ | . | | +--------+-----------+ | .
| | |re-Authorize session| |
| | | parameters | | . | | | Activate Session | | .
| | +--------+-----------+ | . | | | Parameters | | .
. | | +--------+-----------+ | .
. | 200 (SDP) | | | .
. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+ | .
..|.............................................|..............|..
| <- - - - - - RAR - - - - - + | | <- - - - - - RAR - - - - - + |
| +---------+--------+ | | | +---------+--------+ | |
| |Activate QoS state| | | | |Activate QoS State| | |
| +---------+--------+ | | | +---------+--------+ | |
| +- - - - - - RAA - - - - - > | | +- - - - - - RAA - - - - - > |
. | 200 (SDP answer) | | | .
. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+ | .
| | | | | |
/------------------+-----Data Flow---------------------------\ /------------------+-----Data Flow---------------------------\
\------------------+-----------------------------------------/ \------------------+-----------------------------------------/
| | | | | |
.-.-.-.-. SIP signaling .-.-.-.-. SIP signaling
- - - - - Diameter QoS Application messages - - - - - Diameter QoS Application messages
Figure 13: QoS Authorization Example - Push Mode Figure 14: QoS Authorization Example - Push Mode
The communication starts with SIP signaling between the two end The communication starts with SIP signaling between the two end
points and the SIP server for negotiation and authorization of the points and the SIP proxy for negotiation and authorization of the
requested service and its parameters (see Figure 13). As a part of requested service and its parameters (see Figure 14). As a part of
the process, the SIP server verifies whether the user at Host A is the process, the SIP proxy verifies whether the user at Host A is
authorized to use the requested service (and potentially the ability authorized to use the requested service (and potentially the ability
to be charged for the service usage). The DQA server is triggered to to be charged for the service usage).
authorize the QoS request based on session parameters (i.e., SDP
offer), initiate a Diameter QoS authorization session and install
authorized QoS state to the Network Element via QIR message.
The DQA server may obtain the info of peer DQA client from pre- A few implementation choices exist regarding the decision about when
configured information or query the DNS based on Host A's identity or to initiate the QoS reservation.
IP address (In this case a DQA server is co-located with a SIP server [I-D.ietf-mmusic-media-path-middleboxes] discusses this aspect with a
and a DQA client is co-located with a NE). The identity of Network focus on firewalling. In the example above the DQA server is
Element is put into the Destination-Host AVP, the description of the triggered to authorize the QoS request based on session parameters
QoS resources is included into QoS-Resources AVP, as well as duration from the SDP payload. It will use a QIR message to do so. For this
of the authorization session (Authorization-Lifetime AVP). The NE example message flow we assume a two-stage commit, i.e. the SIP proxy
interacts with the traffic control function and reserves the interacts with the NE twice. First, it only prepares the QoS
authorized QoS resources accordingly, for instance, the NE may serve reservation and then with the arrival of the 200 OK the QoS
as a signaling proxy and process the QoS signaling (e.g., initiation reservation is activated.
or termination of QoS signaling) based on the QoS decision received
from the authorizing entity.
With successful QoS authorization, the SDP offer in SIP Invite is This example does not describe how the DQA server learns which DQA
forwarded to Host B. Host B sends back a 18x (ringing) message client to contact. We assume pre-configuration in this example. In
towards Host A and processes the SDP. Once Host B accepts the call, any case, the address of DQA client is put into the Destination-Host
it sends back a 200 OK, in which it includes description of the AVP, the description of the QoS resources is included into QoS-
accepted session parameters (i.e., SDP answer). Resources AVP, and the duration of the authorization session is
carried in the Authorization-Lifetime AVP.
The DQA server may verify the accepted QoS against the pre-authorized When the DQA client receives the QIR it interacts with the traffic
QoS resources, and sends a Diameter RAR message to the DQA client in control function and reserves the authorized QoS resources
the NE for activating the installed policies and commit the resource accordingly. At this point in time the QoS reservation is not yet
allocation. With successful QoS enforcement, the 200 OK is forwarded activated.
towards Host A.
Note that the examples above show a sender-initiated reservation from When a 200 OK is returned the DQA server may verify the accepted QoS
the end host towards the corresponding node and a receiver-initiated against the pre-authorized QoS resources, and sends a Diameter RAR
reservation from the correspondent node towards the end host. message to the DQA client in the NE for activating the installed
policies and commit the resource allocation.
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 registry defined IANA is requested to allocate two AVP codes to the registry defined
skipping to change at page 48, line 9 skipping to change at page 51, line 9
----------------------------------------------------------- -----------------------------------------------------------
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
needs sufficient information to make such an authorization decision. needs sufficient information to make such an authorization decision
Information may come from various sources, including the application and this information may come from various sources, including the
layer signaling, the Diameter protocol (with its security application layer signaling, the Diameter protocol (with its security
mechanisms), from policy information stored available with a AAA mechanisms), from policy information stored available with a AAA
server and from a QoS signaling protocol. server and from a QoS signaling protocol.
Below there is a discussion about considerations for the Diameter QoS Below there is a discussion about considerations for the Diameter QoS
interaction between an Authorizing Entity and a Network Element. interaction between an Authorizing Entity and a Network Element.
Security between the Authorizing Entity and the Network Element has a Security between the Authorizing Entity and the Network Element has a
number of components: authentication, authorization, integrity and number of components: authentication, authorization, integrity and
confidentiality. confidentiality.
Authentication refers to confirming the identity of an originator for Authentication refers to confirming the identity of an originator for
skipping to change at page 52, line 32 skipping to change at page 55, line 32
[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 [RFC5624] Korhonen, J., Tschofenig, H., and E. Davies, "Quality of
Service Parameters for Usage with Diameter", RFC 5624, Service Parameters for Usage with Diameter", RFC 5624,
August 2009. August 2009.
14.2. Informative References 14.2. Informative References
[I-D.ietf-mmusic-media-path-middleboxes]
Stucker, B. and H. Tschofenig, "Analysis of Middlebox
Interactions for Signaling Protocol Communication along
the Media Path",
draft-ietf-mmusic-media-path-middleboxes-02 (work in
progress), March 2009.
[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-18 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18
(work in progress), January 2010. (work in progress), January 2010.
 End of changes. 32 change blocks. 
87 lines changed or deleted 153 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/