draft-ietf-dime-diameter-qos-11.txt   draft-ietf-dime-diameter-qos-12.txt 
Diameter Maintenance and D. Sun, Ed. Diameter Maintenance and D. Sun, Ed.
Extensions (DIME) Alcatel-Lucent Extensions (DIME) Alcatel-Lucent
Internet-Draft P. McCann Internet-Draft P. McCann
Intended status: Standards Track Motorola Labs Intended status: Standards Track Motorola Labs
Expires: February 6, 2010 H. Tschofenig Expires: April 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
August 5, 2009 October 22, 2009
Diameter Quality of Service Application Diameter Quality of Service Application
draft-ietf-dime-diameter-qos-11.txt draft-ietf-dime-diameter-qos-12.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 6, 2010. This Internet-Draft will expire on April 25, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 5, line 8 skipping to change at page 5, line 8
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
14.1. Normative References . . . . . . . . . . . . . . . . . . . 54 14.1. Normative References . . . . . . . . . . . . . . . . . . . 54
14.2. Informative References . . . . . . . . . . . . . . . . . . 54 14.2. Informative References . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
1. Introduction 1. Introduction
This document describes the framework, messages and procedures for This document describes the framework, messages and procedures for
the Diameter Quality of Service (QoS) Application. The Diameter QoS the Diameter[RFC3588] Quality of Service (QoS) Application. The
Application allows Network Elements (NEs) to interact with Diameter Diameter QoS Application allows Network Elements (NEs) to interact
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 parameters defined in the
documents "Quality of Service Attributes for Diameter" documents "Quality of Service Attributes for Diameter"
[I-D.ietf-dime-qos-attributes] and "Quality of Service Parameters for [I-D.ietf-dime-qos-attributes] and "Quality of Service Parameters for
Usage with the AAA Framework" [I-D.ietf-dime-qos-parameters], this Usage with the AAA Framework" [I-D.ietf-dime-qos-parameters], this
note depicts the basic call flow procedures used to establish, modify document depicts basic call flow procedures used to establish, modify
and terminate a Diameter QoS application session. and terminate a Diameter QoS application session.
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 AAA entities (clients, agents, servers) An infrastructure of Authentication, Authorization and Accounting
communicating via a AAA protocol over trusted, secure connections. (AAA) entities (clients, agents, servers) communicating via a AAA
It offers authentication, authorization and accounting services to protocol over trusted, secure connections. It offers
authentication, authorization and accounting services to
applications in flexible local and roaming scenarios. Diameter applications in flexible local and roaming scenarios. Diameter
[RFC3588] and RADIUS [RFC2865] are both widely deployed AAA and RADIUS [RFC2865] are both widely deployed AAA protocols.
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 (see below)
or directly with other Application Endpoints. Based on the result or directly with other Application Endpoints. Based on the result
of this signaling, the Endpoint may make a request for QoS from of this signaling, the Endpoint may make a request for QoS from
the network. For example, a SIP User Agent is one kind of the network. For example, a SIP User Agent is one kind of
Application Endpoint. Application Endpoint.
Application Server (AppS) Application Server (AppS)
skipping to change at page 6, line 48 skipping to change at page 6, line 48
particular application flow or aggregate. The Authorizing Entity particular application flow or aggregate. The Authorizing Entity
may be a standalone entity or may be integrated with an may be a standalone entity or may be integrated with an
Application Server and may be co-located with a subscriber Application Server and may be co-located with a subscriber
database. This entity corresponds to the Policy Decision Point database. This entity corresponds to the Policy Decision Point
(PDP) [RFC2753]. (PDP) [RFC2753].
Network Element (NE) Network Element (NE)
A QoS aware router that acts as a Diameter client for the QoS A QoS aware router that acts as a Diameter client for the QoS
application. This entity triggers the protocol interaction for application. This entity triggers the protocol interaction for
the Pull mode, and it is the recipient of QoS information in the the Pull mode, and it is the recipient of QoS information in the
Push mode. The Network Element corresponds to the Policy Push mode. The Diameter Client at an Network Element corresponds
Enforcement Point (PEP) [RFC2753]. to the Policy Enforcement Point (PEP) [RFC2753].
Pull Mode Pull Mode
In this mode, the QoS authorization process is invoked by the QoS In this mode, the QoS authorization process is invoked by the QoS
reservation request received from the Application Endpoint. The reservation request received from the Application Endpoint. The
Network Element then requests the QoS authorization decision from Network Element then requests the QoS authorization decision from
the Authorizing Entity. the Authorizing Entity.
Push Mode Push Mode
In this mode, the QoS authorization process is invoked by the In this mode, the QoS authorization process is invoked by the
request from Application Server or local policies in the request from Application Server or local policies in the
skipping to change at page 9, line 18 skipping to change at page 9, line 18
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 defined properly, the interface between the NEs and AAA cloud If the interface between the NEs and the AAA cloud is identical
would be identical whether the AE communicates with an AppS or not. regardless of whether the AE communicates with an AppS or not,
Routers are therefore insulated from the details of particular routers are insulated from the details of particular applications and
applications and need not know that Application Servers are involved need not know that Application Servers are involved. Also, the AAA
at all. Also, the AAA cloud would naturally encompass business cloud may also encompass business relationships such as those between
relationships such as those between network operators and third-party network operators and third-party application providers. This
application providers, enabling flexible intra- or inter-domain enables flexible intra- or inter-domain authorization, accounting,
authorization, accounting, and settlement. and settlement.
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 |
| +---------------++-----------------++---------------+ | | +---------------++-----------------++---------------+ |
skipping to change at page 10, line 36 skipping to change at page 10, line 36
+-------------+ * V +-------------+ * V
| | * V | | * V
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
. . * V . . * V
| | * ............................. | | * .............................
. . * . Traffic Control . . . * . Traffic Control .
| | * . +---------+. | | * . +---------+.
. . * . |Admission|. . . * . |Admission|.
| | * . | Control |. | | * . | Control |.
+----------+ +------------+ . +---------+. +----------+ +------------+ . +---------+.
<-.-| Input | | Outgoing |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-> <.->| Input | | Outgoing |<.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->
| Packet | | Interface | .+----------+ +---------+. | Packet | | Interface | .+----------+ +---------+.
===>|Processing|====| Selection |===.| Packet |====| Packet |.=> ===>|Processing|====| Selection |===.| Packet |====| Packet |.=>
| | |(Forwarding)| .|Classifier| Scheduler|. | | |(Forwarding)| .|Classifier| Scheduler|.
+----------+ +------------+ .+----------+ +---------+. +----------+ +------------+ .+----------+ +---------+.
............................. .............................
<.-.-> = signaling flow <.-.-> = signaling flow
=====> = data flow (sender --> receiver) =====> = data flow (sender --> receiver)
<<<>>> = control and configuration operations <<<>>> = control and configuration operations
****** = routing table manipulation ****** = routing table manipulation
skipping to change at page 13, line 5 skipping to change at page 13, line 5
Pull mode Pull mode
The QoS authorization process is triggered by the network The QoS authorization process is triggered by the network
signaling received from end-user equipment or by a local event in signaling received from end-user equipment or by a local event in
the NE according to pre-configured policies, and authorization the NE according to pre-configured policies, and authorization
decisions are produced upon the request of the NE. In order to decisions are produced upon the request of the NE. In order to
support the pull mode, the NE (i.e., Diameter client) will support the pull mode, the NE (i.e., Diameter client) will
initiate a Diameter authorization session to communicate with the initiate a Diameter authorization session to communicate with the
authorizing entity (i.e., Diameter server). authorizing entity (i.e., Diameter server).
For Category 1 and 2 Application Endpoints, Push mode is required. For Category 1 and 2 Application Endpoints, Push mode is REQUIRED.
For a Category 3 AppE, either Push mode or Pull mode MAY be used. For a Category 3 AppE, either Push mode or Pull mode MAY be used.
Push mode is applicable to certain networks, for example, Cable Push mode is applicable to certain networks, for example, Cable
network, DSL, Ethernet, and Diffserv-enabled IP/MPLS as defined by network, DSL, Ethernet, and Diffserv-enabled IP/MPLS. The Pull mode
other SDOs (e.g., ETSI TISPAN and ITU-T}. The Pull mode is more is more appropriate to IntServ-enabled IP networks or certain
appropriate to IntServ-enabled IP networks or certain wireless wireless networks such as the GPRS networks defined by 3GPP. Some
networks such as the GPRS networks defined by 3GPP. Some networks networks (for example, WiMAX) may require both Push and Pull modes.
(for example, WiMAX) may require both Push and Pull modes.
3.3. Authorization Schemes 3.3. Authorization Schemes
3.3.1. Pull Mode Schemes 3.3.1. Pull Mode Schemes
Three types of basic authorization schemes for Pull mode exist: one Three types of basic authorization schemes for Pull mode exist: one
type of two-party scheme and two types of three-party schemes. The type of two-party scheme and two types of three-party schemes. The
notation adopted here is in respect to the entity that performs the notation adopted here is in respect to the entity that performs the
QoS authorization (QoS Authz). The authentication of the QoS QoS authorization (QoS Authz). The authentication of the QoS
requesting entity might be done at the NE as part of the QoS requesting entity might be done at the NE as part of the QoS
skipping to change at page 13, line 35 skipping to change at page 13, line 34
layer or for network access authentication) or the AE might be layer or for network access authentication) or the AE might be
contacted with request for authentication and authorization of the contacted with request for authentication and authorization of the
QoS requesting entity. From the Diameter QoS application's point of QoS requesting entity. From the Diameter QoS application's point of
view these schemes differ in type of information that need to be view these schemes differ in type of information that need to be
carried. Here we focus on the 'Basic Three Party Scheme' (see carried. Here we focus on the 'Basic Three Party Scheme' (see
Figure 3) and the 'Token-based Three Party Scheme' (see Figure 4). Figure 3) and the 'Token-based Three Party Scheme' (see Figure 4).
In the 'Two Party Scheme', the QoS RRE is authenticated by the NE and In the 'Two Party Scheme', the QoS RRE is authenticated by the NE and
the authorization decision is made either locally at the NE itself or the authorization decision is made either locally at the NE itself or
offloaded to a trusted entity (most likely within the same offloaded to a trusted entity (most likely within the same
administrative domain). In the two-party case no Diameter QoS administrative domain). In the two-party case no Diameter QoS
protocol interaction is REQUIRED. protocol interaction is required.
+--------------+ +--------------+
| Authorizing |
| Entity | | Entity |
| authorizing | <......+ | authorizing | <......+
| resource | . | resource | .
| request | . | request | .
+------------+-+ . +------------+-+ .
--^----------|-- . . --^----------|-- . .
///// | | \\\\\ . ///// | | \\\\\ .
// | | \\ . // | | \\ .
| QoS | QoS AAA | QoS |. | QoS | QoS AAA | QoS |.
| authz| protocol |authz |. | authz| protocol |authz |.
skipping to change at page 14, line 32 skipping to change at page 14, line 33
| requesting | | performing | . | requesting | | performing | .
| resource |granted / rejected| QoS | <.....+ | resource |granted / rejected| QoS | <.....+
| |<-----------------| reservation | financial | |<-----------------| reservation | financial
+-------------+ +--------------+ settlement +-------------+ +--------------+ settlement
Figure 3: Three Party Scheme Figure 3: Three Party Scheme
In the 'Basic Three Party Scheme' a QoS reservation request that In the 'Basic Three Party Scheme' a QoS reservation request that
arrives at the NE is forwarded to the Authorizing Entity (e.g., in arrives at the NE is forwarded to the Authorizing Entity (e.g., in
the user's home network), where the authorization decision is made. the user's home network), where the authorization decision is made.
A business relationship, such as a roaming agreement, between the As shown, financial settlement - a business relationship, such as a
visited network and the home network ensures that the visited network roaming agreement, between the visited network and the home network
is compensated for the resources consumed by the user via the home ensures that the visited network is compensated for the resources
network. consumed by the user via the home network.
financial settlement financial settlement
...........................+ ...........................+
Authorization V ------- . Authorization V ------- .
Token Request +--------------+ / QoS AAA \ . Token Request +--------------+ / QoS AAA \ .
+-------------->| | / protocol \ . +-------------->| | / protocol \ .
| | Authorizing +--------------+ \ . | | Authorizing +--------------+ \ .
| | Entity | | | | . | | Entity | | | | .
| +------+ |<--+----+ | | . | +------+ |<--+----+ | | .
| | +--------------+ |QoS | |QoS |. | | +--------------+ |QoS | |QoS |.
skipping to change at page 15, line 46 skipping to change at page 15, line 46
interaction, for example using SIP [RFC3313], with the AE. As part interaction, for example using SIP [RFC3313], with the AE. As part
of this interaction, authentication and authorization at the of this interaction, authentication and authorization at the
application layer might take place. As a result of a successful application layer might take place. As a result of a successful
authorization decision, which might involve the user's home AAA authorization decision, which might involve the user's home AAA
server, an authorization token is generated by the AE (e.g., the SIP server, an authorization token is generated by the AE (e.g., the SIP
proxy and an entity trusted by the SIP proxy) and returned to the end proxy and an entity trusted by the SIP proxy) and returned to the end
host for inclusion into the QoS signaling protocol. The host for inclusion into the QoS signaling protocol. The
authorization token will be used by a NE that receives the QoS authorization token will be used by a NE that receives the QoS
signaling message to authorize the QoS request. Alternatively, the signaling message to authorize the QoS request. Alternatively, the
Diameter QoS application will be used to forward the authorization Diameter QoS application will be used to forward the authorization
token to the user's home network. The authorization token allows the token to the user's home network. The authorization token allows
authorization decision performed at the application layer can be that the authorization decision performed at the application layer
associated with a corresponding QoS signaling session. Note that the can be associated with a corresponding QoS signaling session. Note
authorization token might either refer to established state that the authorization token might either refer to established state
concerning the authorization decision or the token might itself carry concerning the authorization decision or the token might itself carry
the authorized parameters (protected by a digital signature or a the authorized parameters (protected by a digital signature or a
keyed message digest to prevent tampering). In the latter case the keyed message digest to prevent tampering). In the latter case the
authorization token may contain several pieces of information authorization token may contain several pieces of information
pertaining to the authorized application session, but at minimum it pertaining to the authorized application session, but at minimum it
should contain: should contain:
o An identifier for the AE (for example, an AppS) that issued the o An identifier for the AE (for example, an AppS) that issued the
authorization token authorization token
o An identifier referring to a specific application protocol session o An identifier referring to a specific application protocol session
for which the token was issued and for which the token was issued and
skipping to change at page 18, line 5 skipping to change at page 18, line 5
A QoS application must meet a number of requirements applicable to a A QoS application must meet a number of requirements applicable to a
diverse set of networking environments and services. It should be diverse set of networking environments and services. It should be
compatible with different deployment scenarios having specific QoS compatible with different deployment scenarios having specific QoS
signaling models and security issues. Satisfying the requirements signaling models and security issues. Satisfying the requirements
listed below while interworking with QoS signaling protocols, a listed below while interworking with QoS signaling protocols, a
Diameter QoS application should accommodate the capabilities of the Diameter QoS application should accommodate the capabilities of the
QoS signaling protocols rather than introducing functional QoS signaling protocols rather than introducing functional
requirements on them. A list of requirements for a QoS authorization requirements on them. A list of requirements for a QoS authorization
application is provided here: application is provided here:
Inter-domain support
In particular, users may roam outside their home network, leading
to a situation where the NE and AE are in different administrative
domains.
Identity-based Routing Identity-based Routing
The Diameter QoS application MUST route AAA requests to the The Diameter QoS application MUST route AAA requests to the
Authorizing Entity, based on the provided identity of the QoS Authorizing Entity, based on the provided identity of the QoS
requesting entity or the identity of the AE encoded in the requesting entity or the identity of the AE encoded in the
provided authorization token. provided authorization token.
Flexible Authentication Support Flexible Authentication Support
The Diameter QoS application MUST support a variety of different The Diameter QoS application MUST support a variety of different
authentication protocols for verification of authentication authentication protocols for verification of authentication
information present in QoS signaling messages. The support for information present in QoS signaling messages. The support for
skipping to change at page 28, line 43 skipping to change at page 28, line 43
parameters requires contacting the AE for re-authorization. parameters requires contacting the AE for re-authorization.
d. In addition to the authorized parameters of the flow and its QoS, d. In addition to the authorized parameters of the flow and its QoS,
the QAA message contains policy rules that determine the NEs the QAA message contains policy rules that determine the NEs
actions in case of change or request for change in authorized actions in case of change or request for change in authorized
parameters. parameters.
Provided options are not exhaustive. Elaborating on any of the Provided options are not exhaustive. Elaborating on any of the
listed approaches is deployment /solution specific and is not listed approaches is deployment /solution specific and is not
considered in the current document. considered in the current document.
In addition, the AE may use a RAR to perform re-authorization with In addition, the AE may use a RAR (Re-Authorization-Request) to
the authorized parameters directly when the re-authorization is perform re-authorization with the authorized parameters directly when
triggered by service request or local events/policy rules. the re-authorization is triggered by service request or local events/
policy rules.
4.3.1. Client-Side Initiated Re-Authorization 4.3.1. Client-Side Initiated Re-Authorization
The AE provides the duration of the authorization session as part of The AE provides the duration of the authorization session as part of
the QoS-Authorization-Answer message (QAA). At any time before the QoS-Authorization-Answer message (QAA). At any time before
expiration of this period, a new QoS-Authorization-Request message expiration of this period, a new QoS-Authorization-Request message
(QAR) MAY be sent to the AE. The transmission of the QAR MAY be (QAR) MAY be sent to the AE. The transmission of the QAR MAY be
triggered when the NE receives a QoS signaling message that requires triggered when the NE receives a QoS signaling message that requires
modification of the authorized parameters of an ongoing QoS session, modification of the authorized parameters of an ongoing QoS session,
or authorization lifetime expires. or authorization lifetime expires.
skipping to change at page 31, line 11 skipping to change at page 31, line 11
| | | | | |
Figure 9: Server-side Initiated QoS Re-Authorization Figure 9: Server-side Initiated QoS Re-Authorization
4.4. Session Termination 4.4. Session Termination
4.4.1. Client-Side Initiated Session Termination 4.4.1. Client-Side Initiated Session Termination
The authorization session for an installed QoS reservation state MAY The authorization session for an installed QoS reservation state MAY
be terminated by the Diameter client by sending a Session- be terminated by the Diameter client by sending a Session-
Termination-Request message (STR) to the Diameter server. This is a Termination-Request message (STR) to the Diameter server with a
Diameter base protocol function and it is defined in [RFC3588]. response Session-Termination-Acknowledgement message (STA). This is
a Diameter base protocol function and it is defined in [RFC3588].
Session termination can be caused by a QoS signaling messaging Session termination can be caused by a QoS signaling messaging
requesting deletion of the existing QoS reservation state or it can requesting deletion of the existing QoS reservation state or it can
be caused as a result of a soft-state expiration of the QoS be caused as a result of a soft-state expiration of the QoS
reservation state. reservation state.
Authorizing Authorizing
End-Host Network Element Entity End-Host Network Element Entity
requesting QoS ( Diameter ( Diameter requesting QoS ( Diameter ( Diameter
QoS Client) QoS Server) QoS Client) QoS Server)
| | | | | |
|==Data Flow==>X /Stop of the data flow/ | |==Data Flow==>X /Stop of the data flow/ |
| | | | | |
+---QoS-Reserve---->| | +---QoS-Reserve---->| |
| (Delete QoS +- - - - - STR - - - - - >| | (Delete QoS +- - - - - STR - - - - - >|
| reservation) | +--------+--------------+ | reservation) | +--------+--------------+
| | | Remove authorization | | | | Remove authorization |
|<--QoS-Response----+ | session state | | | | session state |
| | +--------+--------------+ | | +--------+--------------+
|< - - - - STA - - - - - -+ | |< - - - - STA - - - - - -+
+-------+--------+ | | +-------+--------+ |
|Delete QoS state| | |Delete QoS state|
+-------+--------+ QoS Responder | +-------+--------+ QoS Responder
| Node | | Node
+----------QoS-Reserve-----....--->| | +----------QoS-Reserve-----....--->|
| (Delete QoS | | | (Delete QoS |
| reservation) | | | reservation) |
|<---------QoS-Response----....----+ | |<---------QoS-Response----....----+
| | |<--QoS-Response----+ |
Figure 10: Client-Side Initiated Session Termination Figure 10: Client-Side Initiated Session Termination
4.4.2. Server-Side Initiated Session Termination 4.4.2. Server-Side Initiated Session Termination
At anytime during a session the AE MAY send an Abort-Session-Request At anytime during a session the AE MAY send an Abort-Session-Request
message (ASR) to the NE. This is a Diameter base protocol function message (ASR) to the NE. This is a Diameter base protocol function
and it is defined in [RFC3588]. Possible reasons for initiating the and it is defined in [RFC3588]. Possible reasons for initiating the
ASR message to the NE are insufficient credits or session termination ASR message to the NE are insufficient credits or session termination
at the application layer. The ASR message results in termination of at the application layer. The ASR message results in termination of
skipping to change at page 34, line 26 skipping to change at page 34, line 26
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
QoS, and the identity of the QoS requesting entity. In addition, QoS, and the identity of the QoS requesting entity. In addition,
depending on the deployment scenario, an authorization token and depending on the deployment scenario, an authorization token and
credentials of the QoS requesting entity SHOULD be included. credentials of the QoS requesting entity SHOULD be included.
The message format, presented in ABNF form [RFC4234], is defined as The message format is defined as follows:
follows:
<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 35, line 45
<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 36, line 45 skipping to change at page 37, line 12
The message format is defined as follows: The message format is defined as follows:
<Re-Auth-Request> ::= < Diameter Header: 258, REQ, PXY > <Re-Auth-Request> ::= < Diameter Header: 258, 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.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:
skipping to change at page 50, line 10 skipping to change at page 50, line 10
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. Therefore, sufficient QoS reservation at a third party entity. Therefore, sufficient
information needs to be made available to the Authorizing Entity to information needs to be made available to the Authorizing Entity to
can make such an authorization decision. Information may come from make such an authorization decision. Information may come from
various sources, including the application layer signaling, the various sources, including the application layer signaling, the
Diameter protocol (with its security mechanisms), from policy Diameter protocol (with its security mechanisms), from policy
information stored available with a AAA server and from a QoS information stored available with a AAA server and from a QoS
signaling protocol. 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.
skipping to change at page 56, line 14 skipping to change at page 56, line 14
Authors' Addresses Authors' Addresses
Dong Sun (editor) Dong Sun (editor)
Alcatel-Lucent Alcatel-Lucent
600 Mountain Ave 600 Mountain Ave
Murray Hill, NJ 07974 Murray Hill, NJ 07974
USA USA
Phone: +1 908 582 2617 Phone: +1 908 582 2617
Email: dongsun@alcatel-lucent.com Email: d.sun@alcatel-lucent.com
Peter J. McCann Peter J. McCann
Motorola Labs Motorola Labs
1301 E. Algonquin Rd 1301 E. Algonquin Rd
Schaumburg, IL 60196 Schaumburg, IL 60196
USA USA
Phone: +1 847 576 3440 Phone: +1 847 576 3440
Email: pete.mccann@motorola.com Email: pete.mccann@motorola.com
 End of changes. 30 change blocks. 
66 lines changed or deleted 64 lines changed or added

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