One document matched: draft-ietf-dime-diameter-qos-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="no"?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<!DOCTYPE rfc PUBLIC "-//IETF//DTD RFC 2629//EN"
"http://xml.resource.org/authoring/rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2234.xml">
<!ENTITY RFC3588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml">
<!ENTITY RFC4006 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4006.xml">
<!ENTITY RFC4005 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4005.xml">
<!ENTITY I-D.ietf-dime-qos-attributes SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dime-qos-attributes.xml">
<!ENTITY I-D.ietf-nsis-qos-nslp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nsis-qos-nslp.xml">
<!ENTITY RFC4566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY RFC2749 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2749.xml">
<!ENTITY RFC2210 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2210.xml">
<!ENTITY RFC2753 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2753.xml">
<!ENTITY RFC4027 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4027.xml">
<!ENTITY RFC2865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY RFC3521 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3521.xml">
<!ENTITY RFC3313 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3313.xml">
<!ENTITY I-D.ietf-nsis-ntlp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-nsis-ntlp.xml">
<!ENTITY RFC3520 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3520.xml">
<!ENTITY RFC2486 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2486.xml">
]>
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="no"?>
<?rfc compact="no" ?>
<?rfc subcompact="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc category="std" docName="draft-ietf-dime-diameter-qos-02.txt"
ipr="full3978">
<front>
<title abbrev="Protocol for Diameter QoS Application">Protocol for
Diameter Quality of Service Application</title>
<author fullname="Glen Zorn" initials="G.W." role="editor" surname="Zorn">
<organization> </organization>
<address>
<postal>
<street> </street>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone> </phone>
<email>glenzorn@comcast.net</email>
</address>
</author>
<author fullname="Peter J. McCann" initials="P." surname="McCann">
<organization abbrev="Motorola Labs">Motorola Labs</organization>
<address>
<postal>
<street>1301 E. Algonquin Rd</street>
<city>Schaumburg</city>
<region>IL</region>
<code>60196</code>
<country>USA</country>
</postal>
<phone>+1 847 576 3440</phone>
<email>pete.mccann@motorola.com</email>
</address>
</author>
<author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Otto-Hahn-Ring 6</street>
<city>Munich</city>
<region>Bavaria</region>
<code>81739</code>
<country>Germany</country>
</postal>
<email>Hannes.Tschofenig@nsn.com</email>
<uri>http://www.tschofenig.com</uri>
</address>
</author>
<author fullname="Tina Tsou" initials="T." surname="Tsou">
<organization abbrev="Huawei">Huawei</organization>
<address>
<postal>
<street></street>
<city>Shenzhen</city>
<region></region>
<code></code>
<country>P.R.C</country>
</postal>
<email>tena@huawei.com</email>
</address>
</author>
<author fullname="Avri Doria" initials="A." surname="Doria">
<organization abbrev="Lulea University of Technology">Lulea University
of Technology</organization>
<address>
<postal>
<street>Arbetsvetenskap</street>
<city>Lulea</city>
<region></region>
<code>SE-97187</code>
<country>Sweden</country>
</postal>
<email>avri@ltu.se</email>
</address>
</author>
<author fullname="Dong Sun" initials="D." surname="Sun">
<organization>Bell Labs/Alcatel-Lucent</organization>
<address>
<postal>
<street>101 Crawfords Corner Rd</street>
<city>Holmdel</city>
<region>NJ</region>
<code>07733</code>
<country>USA</country>
</postal>
<email>dongsun@alcatel-lucent.com</email>
</address>
</author>
<date year="2007" />
<area>Operations and Management Area</area>
<keyword>AAA, QoS, VoIP, SIP</keyword>
<abstract>
<t>This document describes the messages and procedures for the Diameter
QoS application. The 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.</t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="introduction" title="Introduction">
<t>This document describes the messages and procedures for the Diameter
QoS Application. The QoS Application allows network elements to interact
with Diameter servers when allocating QoS resources in the network.</t>
<t>In particular, two modes of operation are defined. In the first,
called "Pull Mode", the network element queries the Diameter
infrastructure for authorization based on some trigger (such as a QoS
signaling protocol) that arrives along the data path to be used for the
session. In the second, called "Push Mode", a Diameter server
pro-actively sends a command to the network element(s) to install QoS
authorization state. This could be triggered, for instance, by off-path
signaling such as SIP-based call control.</t>
<t>A set of command codes pertinent to this QoS application are
specified that allows a single Diameter application to support both Pull
and Push modes based on the requirements of network technologies,
deployment scenarios and end-host's capabilities. In conjunction with
parameters defined in other Diameter QoS documents, this document
depicts basic call flow procedures to establish, modify and terminate a
Diameter QoS application session.</t>
</section>
<!-- ====================================================================== -->
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 <xref
target="RFC2119"></xref>.</t>
<t>In addition to the terms defined in other relevant Diameter QoS
documents (e.g., diameter-qos-framework), the following terms are used in
this document:</t>
<t><list style="hanging">
<t hangText="Diameter QoS Application Server"><vspace
blankLines="1" /> A Diameter QoS application server is a logical
Diameter node that supports the protocol interaction for QoS
authorization. The Diameter QoS server resides in the authorizing
entity and is able to respond to a Diameter session received from a
Diameter QoS client, or initiate a Diameter session to a Diameter
QoS client triggered by application signaling or local
events.<vspace blankLines="1" /></t>
<t hangText="Diameter QoS Application Client"><vspace
blankLines="1" /> A Diameter QoS application client is a logical
Diameter node that supports the protocol interaction for QoS
enforcement. The Diameter QoS client resides in the network element
and is able to initiate a Diameter session triggered by a QoS
signaling or other events, or respond to a Diameter session
initiated by a Diameter QoS server.<vspace blankLines="1" /></t>
<t hangText="Resource Requesting Entity"><vspace blankLines="1" /> A
resource requesting entity is a logical entity that supports the
protocol interaction for QoS resources. The resource requesting
entity resides in the end-host and is able to communicate with peer
logicial entities in Authorizing Entity or Network element to
trigger the QoS authorization process.<vspace blankLines="1" /></t>
</list></t>
</section>
<!-- ====================================================================== -->
<section title="Diameter QoS Authorization Session Establishment and Management">
<section title="Parties involved">
<t>Authorization models supported by this application include three
parties: <list style="symbols">
<t>Resource requesting entity</t>
<t>Network Elements (Diameter QoS application (DQA) client)</t>
<t>Authorizing Entity (Diameter QoS application (DQA) server)</t>
</list></t>
<t>Note that the QoS resource requesting entity is only indirectly
involved in the message exchange. This entity provides the trigger to
initiate the Diameter QoS protocol interaction by transmitting QoS
signaling messages. The Diameter QoS application is only executed
between the Network Element (i.e., DQA client) and the Authorizing
Entity (i.e., DQA server).</t>
<t>The QoS resource requesting entity may communicate with the
Authorizing Entity using application layer signaling for negotiation
of service parameters. As part of this application layer protocol
interaction, for example using SIP, authentication and authorization
might take place. This message exchange is, however, outside the scope
of this document. The protocol communication between the QoS resource
requesting entity and the QoS Network Element might be accomplished
using the NSIS protocol suite, RSVP or a link layer signaling
protocol. A description of these protocols is also outside the scope
of this document and a tight coupling with these protocols is not
desirable since this applications aims to be generic.</t>
</section>
<section title="Diameter QoS Authorization Session Establishment">
<t>The Pull and Push modes use a different set of command codes for
session establishment. For other operations, such as session
modification and termination, they use the same set of command
codes.</t>
<t>The Pull mode or Push mode operation is invoked based on the
trigger of QoS Authorization session. When a QAR with a new session ID
is received, the Authorizing Entity operates in the pull mode; when
other triggers are received, the Authorizing Entity operates in the
push mode. Similarly, when a QIR with new session ID is received, the
Network Element operates in the push mode; when other triggers are
recevied, the Network Element operation in the pull mode.</t>
<section title="QoS authorization session establishment for pull mode">
<t>A request for a QoS reservation or local events received by a
Network Element can trigger the initiation of a Diameter QoS
authorization session. The Network Element generates a
QoS-Authorization-Request (QAR) message in which it maps required
objects from the QoS signaling message to Diameter payload
objects.</t>
<t><xref target="fig-initial-qos-request-pull"></xref> shows the
protocol interaction between a resource requesting entity, a Network
Element and the Authorizing Entity.</t>
<t>The Authorizing Entity's identity, information about the
application session and/or identity and credentials of the QoS
resource requesting entity, requested QoS parameters, signaling
session identifier and/or QoS enabled data flows identifiers MAY be
encapsulated into respective Diameter AVPs and included into the
Diameter message sent to the Authorizing Entity. The QAR is sent to
a Diameter server that can either be the home server of the QoS
requesting entity or an application server.</t>
<figure>
<artwork><![CDATA[
+----------------------------------+-------------------------------+
| QoS specific Input Data | Diameter QoS AVPs |
+----------------------------------+-------------------------------+
| Authorizing entity ID (e.g., | Destination-Host |
| taken from authorization token | Destination-Realm |
| or derived based on Network | |
| Access ID (NAI) [RFC2486] | |
| of the QoS requesting entity) | |
+----------------------------------+-------------------------------+
| Authorization Token | QoS-Authz-Data |
| Credentials of | User-Name |
| the QoS requesting entity | |
+----------------------------------+-------------------------------+
| QoS parameters | QoS-Resources |
+----------------------------------+-------------------------------+
]]></artwork>
</figure>
<t></t>
<t>Authorization processing starts at the Diameter QoS server when
it receives the QAR. Based on the information in the
QoS-Authentication-Data, User-Name and QoS-Resources AVPs the server
determines the authorized QoS resources and flow state
(enabled/disabled) from locally available information (e.g., policy
information that may be previously established as part of an
application layer signaling exchange, or the user's subscription
profile). The QoS-Resources AVP is defined in <xref target="I-D.ietf-dime-qos-attributes"/>.
The authorization decision is then reflected in the
response returned to the Diameter client with the
QoS-Authorization-Answer message (QAA).</t>
<t><figure anchor="fig-initial-qos-request-pull"
title="Initial QoS Request Authorization for pull">
<artwork><![CDATA[
Authorizing
End-Host Network Element Entity
requesting QoS ( Diameter ( Diameter
QoS Client) QoS Server)
| | |
+---QoS-Reserve---->| |
| +- - - - - QAR - - - - - >|
| |(QoS-Resources,Cost, |
| | QoS-Auth-Data,User-ID)|
| | +--------+--------------+
| | | Authorize request |
| | | Keep session data |
| | |/Authz-time,Session-Id/|
| | +--------+--------------+
| |< - - - - QAA - - - - - -+
| |(Result-Code,CC-Time,Cost|
| |QoS-Resources,Authz-time)|
| +-------+---------+
| |Install QoS state|
| | + |
| | Authz. session |
| | /Authz-time, | QoS Responder
| | CC-Time,Cost/ | Node
| +-------+---------+ |
| +----------QoS-Reserve---....--->|
| | |
| |<---------QoS-Response--....----|
|<--QoS-Response----+ |
| | |
|=====================Data Flow==============....===>|
| |
| +- - - - - ACR - - - - - >|
| |(START,QoS-Resources,Cost|
| |CC-Time,Acc-Multisess-id)|
| | +--------+--------------+
| | | Report for successful |
| | | QoS reservation |
| | |Update of reserved QoS |
| | | resources |
| | +--------+--------------+
| |< - - - - ACA - - - - - -+
| | |
]]></artwork>
</figure></t>
<t>The Authorizing Entity keeps authorization session state and
SHOULD save additional information for management of the session
(e.g., Acc-Multi-Session-Id, Signaling-Session-Id, authentication
data) as part of the session state information. A
Signaling-session-Id (if present) SHOULD be used together with the
generated Acc-Multi-Session-Id AVP (see <xref
target="accounting-avps"></xref>) for binding the authorization and
the accounting session information in case of end host mobility
(i.e., to correlate the Diameter sessions that are initiated for the
same signaling session from different QoS NE).</t>
<t>The final result of the authorization request is provided in the
Result-Code AVP of the QAA message sent by the Authorizing Entity.
In case of successful authorization (i.e., Result-Code =
DIAMETER_LIMITED_SUCCESS, (see <xref
target="diameter-base-avps"></xref>)), information about the
authorized QoS resources and the status of the authorized flow
(enabled/disabled) is provided in the QoS-Resources AVP of the QAA
message. The QoS information provided via the QAA is installed by
the QoS Traffic Control function of the Network Element. The value
DIAMETER_LIMITED_SUCCESS indicates that the Authorizing entity
expects confirmation via an accounting message for successful QoS
resource reservation and for final reserved QoS resources (see
below).</t>
<t>One important piece of information returned from the Authorizing
Entity is the authorization lifetime (carried inside the QAA). The
authorization lifetime allows the Network Element to determine how
long the authorization decision is valid for this particular QoS
reservation. A number of factors may influence the authorized
session duration, such as the user's subscription plan or currently
available credits at the user's account (see <xref
target="accounting"></xref>). The authorization duration is
time-based as specified in <xref target="RFC3588"></xref>. For an
extension of the authorization period, a new
QoS-Authorization-Request/Answer message exchange SHOULD be
initiated. Further aspects of QoS authorization session maintenance
is discussed in <xref target="re-authz"></xref>, <xref
target="session-termination"></xref> and <xref
target="accounting"></xref>.</t>
<t>The indication of a successful QoS reservation and activation of
the data flow is provided by the transmission of an Accounting
Request (ACR) message, which reports the parameters of the
established QoS state: reserved resources, duration of the
reservation, identification of the QoS enabled flow/QoS signaling
session and accounting parameters. The Diameter QoS server
acknowledges the reserved QoS resources with the Accounting Answer
(ACA) message where the Result-Code is set to 'DIAMETER_SUCCESS'.
Note that the reserved QoS resources reported in the ACR message MAY
be different than those initially authorized with the QAA message,
due to the QoS signaling specific behavior (e.g., receiver-initiated
reservations with One-Path-With-Advertisements) or specific process
of QoS negotiation along the data path.</t>
</section>
<section title="QoS authorization session establishment for push mode">
<t>The Diameter QoS server in the Authorizing Entity initiates a
Diameter QoS authorization session upon the request for QoS
reservation triggered by application layer signaling or by local
events, and generates a QoS-Install-Request (QIR) message to
Diameter QoS client in the NE in which it maps required objects to
Diameter payload objects.</t>
<t><xref target="fig-initial-qos-request-push"></xref> shows the
protocol interaction between the Authorizing Entity, a Network
Element and a resource requesting entity.</t>
<t>The Network Element's identity, information about the application
session and/or identity and credentials of the QoS resource
requesting entity, requested QoS parameters, signaling session
identifier and/or QoS enabled data flows identifiers MAY be
encapsulated into respective Diameter AVPs and included into the
Diameter message sent from a Diameter QoS server in the Authorizing
Entity to a Diameter QoS client in the NE. This requires that the
Authorizing Entity has knowledge of specific information for
allocating and identifying the Network Element that should be
contacted and the data flow for which the QoS reservation should be
established. This information can be statically configured or
dynamically discovered, see section 3.2.3 for details.</t>
<figure>
<artwork><![CDATA[
+----------------------------------+-------------------------------+
| QoS specific Input Data | Diameter QoS AVPs |
+----------------------------------+-------------------------------+
| Network Element ID (e.g., from | Destination-Host |
| static configuration | Destination-Realm |
| or dynamically discovered, see | |
| section 3.2.3 for details) | |
+----------------------------------+-------------------------------+
| Authorization Token | QoS-Authz-Data |
| Credentials of | User-Name |
| the QoS requesting entity | |
+----------------------------------+-------------------------------+
| QoS parameters | QoS-Resources |
+----------------------------------+-------------------------------+
]]></artwork>
</figure>
<t></t>
<t>Authorization processing starts at the Diameter QoS server when
it receives the request from a resource requesting entity through
application server (e.g. SIP Invite) or the trigger by local events
(e.g. pre-configured timer). Based on the received information the
server determines the authorized QoS resources and flow state
(enabled/disabled) from locally available information (e.g., policy
information that may be previously established as part of an
application layer signaling exchange, or the user's subscription
profile). The authorization decision is then reflected in the
QoS-Install-Request message (QIR) to the Diameter QoS client.</t>
<t><figure anchor="fig-initial-qos-request-push"
title="Initial QoS Request Authorization for push">
<artwork><![CDATA[
Authorizing
End-Host Network Element Entity
requesting QoS ( Diameter ( Diameter
QoS Client) QoS Server)
| | |
| | |<-- Trigger --
| | +--------+--------------+
| | | Authorize request |
| | | Keep session data |
| | |/Authz-time,Session-Id/|
| | +--------+--------------+
| | |
| |<-- - -- - QIR - - - - - -+
| |(Initial Request,Decision |
| |(QoS-Resources,Authz-time)|
| +-------+---------+
| |Install QoS state|
| | + |
| | Authz. session |
| | /Authz-time, |
| | CC-Time,Cost/ |
| +-------+---------+
| + - - - - QIA - - - - - ->|
| | (Result-Code, |
| | QoS-Resources) |
| | +--------+--------------+
| | | Report for successful |
| | | QoS reservation |
| | |Update of reserved QoS |
| | | resources |
| | +--------+--------------+
| | QoS Responder
| | Node
| | |
|=====================Data Flow==============....===>|
| |
| +- - - - - ACR - - - - - >|
| |(START,QoS-Resources,Cost|
| |CC-Time,Acc-Multisess-id)|
| |< - - - - ACA - - - - - -+
| | |
]]></artwork>
</figure></t>
<t>The Authorizing Entity keeps authorization session state and
SHOULD save additional information for management of the session
(e.g., Acc-Multi-Session-Id, Signaling-Session-Id, authentication
data) as part of the session state information. A
Signaling-session-Id (if present) SHOULD be used together with the
generated Acc-Multi-Session-Id AVP (see <xref
target="accounting-avps"></xref>) for binding the authorization and
the accounting session information in case of end host mobility
(i.e., to correlate the Diameter sessions that are initiated for the
same signaling session from different QoS NE).</t>
<t>The final result of the authorization decision is provided in the
QoS-Resources AVP of the QIR message sent by the Authorizing Entity.
The QoS information provided via the QIR is installed by the QoS
Traffic Control function of the Network Element. In the case of
successful enforcement, the Result-Code (= DIAMETER_SUCCESS, (see
<xref target="diameter-base-avps"></xref>)) information is provided
in the QIA message.</t>
<t>One important piece of information from the Authorizing Entity is
the authorization lifetime (carried inside the QIR). The
authorization lifetime allows the Network Element to determine how
long the authorization decision is valid for this particular QoS
reservation. A number of factors may influence the authorized
session duration, such as the user's subscription plan or currently
available credits at the user's account (see <xref
target="accounting"></xref>). The authorization duration is
time-based as specified in <xref target="RFC3588"></xref>. For an
extension of the authorization period, a new
QoS-Install-Request/Answer message or
QoS-Authorization-Request/Answer message exchange SHOULD be
initiated. Further aspects of QoS authorization session maintenance
is discussed in <xref target="re-authz"></xref>, <xref
target="session-termination"></xref> and <xref
target="accounting"></xref>.</t>
<t>The indication of a successful QoS reservation and activation of
the data flow, is provided by the QoS-Install-Answer message. Note
that the reserved QoS resources reported in the QIA message MAY be
different than those initially authorized with the QIR message, due
to the QoS signaling specific behavior (e.g., receiver-initiated
reservations with One-Path-With-Advertisements) or specific process
of QoS negotiation along the data path.</t>
<t>In case of xxx = Acounting_Info in the QIR, it indicates the
confirmation to an accounting server for successful QoS resource
reservation and for final reserved QoS resources (see below). An ACR
message reports the parameters of the established QoS state:
reserved resources, duration of the reservation, identification of
the QoS enabled flow/QoS signaling session and accounting parameters
to accounting server. The accounting server acknowledges the
reserved QoS resources with the Accounting Answer (ACA) message
where the Result-Code is set to 'DIAMETER_SUCCESS'.</t>
</section>
<section title="Discovery and selection of peer Diameter QoS application node">
<t>The Diameter QoS application node may obtain the location
information of its peer nodes (i.e. FQDN or IP address) through
static configuration or dynamic discovery as described in <xref
target="RFC3588"></xref>. In particular, the Network Element shall
perform the relevant operation for Pull mode; the Authorizing Entity
shall perform the relevant operations for Push mode.</t>
<t>Upon receipt of a trigger to initiate a new Diameter QoS
authorization session, the Diameter QoS application node selects and
retrieves the location information of the peer node and based on
some index information provided by the resource requesting entity.
For instance, it can be the Authorization Entity's ID stored in the
authorization token, the end-host's identity (e.g. NAI <xref
target="RFC2486"></xref>) or globally routable IP address.</t>
</section>
</section>
<section anchor="re-authz"
title="QoS authorization session re-authorization">
<t>Client and server-side initiated re-authorizations are considered
in the design of the Diameter QoS application. Whether the
re-authorization events are transparent for the resource requesting
entity or result in specific actions in the QoS signaling protocol is
outside the scope of the Diameter QoS application. It is directly
dependent on the capabilities of the QoS signaling protocol.</t>
<t>There are a number of options for policy rules according to which
the NE (AAA client) contacts the Authorizing Entity for
re-authorization. These rules depend on the semantics and contents of
the QAA message sent by the Authorizing Entity:</t>
<t><list style="letters">
<t>The QAA message contains the authorized parameters of the flow
and its QoS and sets their limits (presumably upper). With these
parameters the Authorizing Entity specifies the services that the
NE can provide and will be financially compensated for. Therefore,
any change or request for change of the parameters of the flow and
its QoS that do not conform to the authorized limits requires
contacting the Authorizing Entity for authorization.</t>
<t>The QAA message contains authorized parameters of the flow and
its QoS. The rules that determine whether parameters’
changes require re-authorization are agreed out of band, based on
a Service Level Agreement (SLA) between the domains of the NE and
the Authorizing Entity.</t>
<t>The QAA message contains the authorized parameters of the flow
and its QoS. Any change or request for change of these parameters
requires contacting the Authorizing entity for
re-authorization.</t>
<t>In addition to the authorized parameters of the flow and its
QoS, the QAA message contains policy rules that determine the NEs
actions in case of change or request for change in authorized
parameters.</t>
</list></t>
<t>Provided options are not exhaustive. Elaborating on any of the
listed approaches is deployment /solution specific and is not
considered in the current document.</t>
<t>In addition, the Authorizing Entity may use RAR to perform
re-authorization with the authorized parameters directly when the
re-authorization is triggered by service request or local
events/policy rules.</t>
<section title="Client-Side Initiated Re-Authorization">
<t>The Authorizing Entity provides the duration of the authorization
session as part of the QoS-Authorization-Answer message (QAA). At
any time before expiration of this period, a new
QoS-Authorization-Request message (QAR) MAY be sent to the
Authorizing Entity. The transmission of the QAR MAY be triggered
when the Network Element receives a QoS signaling message that
requires modification of the authorized parameters of an ongoing QoS
session, when authorization lifetime expires or by an accounting
event, see <xref target="accounting"></xref> and <xref
target="fig-qos-request-re-authz"></xref>).</t>
<t><figure anchor="fig-qos-request-re-authz"
title="Client-side initiated QoS re-authorization">
<artwork><![CDATA[
Authorizing
End-Host Network Element Entity
requesting QoS ( Diameter ( Diameter
QoS Client) QoS Server)
| | |
|=====================Data Flow==========================>
| | |
| +-------+----------+ |
| |Authz-time/CC-Time| |
| | expires | |
| +-------+----------+ |
| +- - - - - QAR - - - - - >|
| |(QoS-Resources,Cost, |
| | QoS-Authz-Data,User-ID)|
| +--------+--------------+
NOTE: | | Authorize request |
Re-authorization | | Update session data |
is transparent to | |/Authz-time,Session-Id/|
the End-Host | +--------+--------------+
|< - - - - QAA - - - - - -+
| |(Result-Code,CC-Time,Cost|
| |QoS-Resources,Authz-time)|
| +-------+---------+ |
| |Update QoS state | |
| | + | |
| | Authz. session | |
| | /Authz-time, | |
| | CC-Time,Cost/ | |
| +-------+---------+ |
| | |
| +- - - - - ACR - - - - - >|
| |(INTRM,QoS-Resources,Cost|
| |CC-Time,Acc-Multisess-id)|
| | +--------+--------------+
| | |Update of QoS resources|
| | |/CC-Time,Cost/ used |
| | +--------+--------------+
| |< - - - - ACA - - - - - -+
| | |
|=====================Data Flow==========================>
| |
]]></artwork>
</figure></t>
</section>
<section title="Server-Side Initiated Re-Authorization">
<t>The Authorizing Entity MAY initiate a QoS re-authorization by
issuing a Re-Auth-Request message (RAR) as defined in the Diameter
base protocol <xref target="RFC3588"></xref>, which may include the
parameters of the re-authorized QoS state: reserved resources,
duration of the reservation, identification of the QoS enabled
flow/QoS signaling session for re-installation of the resource state
by the QoS Traffic Control function of the Network Element.</t>
<t>A Network Element that receives such a RAR message with
Session-Id matching a currently active QoS session acknowledges the
request by sending the Re-Auth-Answer (RAA) message towards the
Authorizing entity.</t>
<t>If RAR does not include any parameters of the re-authorized QoS
state, the Network Element MUST initiate a QoS re-authorization by
sending a QoS-Authorization-Request (QAR) message towards the
Authorizing entity.</t>
<t><figure anchor="fig-qos-re-auth-server-side"
title="Server-side Initiated QoS re-authorization">
<artwork><![CDATA[
Authorizing
End-Host Network Element Entity
requesting QoS ( Diameter ( Diameter
QoS Client) QoS Server)
| | |
| | |<-- Trigger --
| | +--------+--------------+
| | | Authorize request |
| | | Keep session data |
| | |/Authz-time,Session-Id/|
| | +--------+--------------+
| | |
| |<-- - -- - RAR - - - - - -+
| |(Request,Decision |
| |(QoS-Resources,Authz-time)|
| +-------+---------+
| |Install QoS state|
| | + |
| | Authz. session |
| | /Authz-time, |
| | CC-Time,Cost/ |
| +-------+---------+
| + - - - - RAA - - - - - ->|
| | (Result-Code, |
| | QoS-Resources) |
| | +--------+--------------+
| | | Report for successful |
| | | QoS reservation |
| | |Update of reserved QoS |
| | | resources |
| | +--------+--------------+
| | |
| +- - - - - ACR - - - - - >|
| |(INTRM,QoS-Resources,Cost|
| |CC-Time,Acc-Multisess-id)|
| | +--------+--------------+
| | |Update of QoS resources|
| | |/CC-Time,Cost/ used |
| | +--------+--------------+
| |< - - - - ACA - - - - - -+
| | |
]]></artwork>
</figure></t>
</section>
</section>
<section anchor="session-termination" title="Session Termination">
<section title="Client-Side Initiated Session Termination">
<t>The authorization session for an installed QoS reservation state
MAY be terminated by the Diameter client by sending a
Session-Termination-Request message (STR) to the Diameter server.
This is a Diameter base protocol function and it is defined in <xref
target="RFC3588"></xref>. Session termination can be caused by a QoS
signaling messaging requesting deletion of the existing QoS
reservation state or it can be caused as a result of a soft-state
expiration of the QoS reservation state. After a successful
termination of the authorization session, final accounting messages
MUST be exchanged (see <xref
target="fig-client-termination"></xref>). It should be noted that
the two sessions (authorization and accounting) have independent
management by the Diameter base protocol, which allows for
finalizing the accounting session after the end of the authorization
session.</t>
<t><figure anchor="fig-client-termination"
title="Client-Side Initiated Session Termination">
<artwork><![CDATA[
Authorizing
End-Host Network Element Entity
requesting QoS ( Diameter ( Diameter
QoS Client) QoS Server)
| | |
|==Data Flow==>X /Stop of the data flow/ |
| | |
+---QoS-Reserve---->| |
| (Delete QoS +- - - - - STR - - - - - >|
| reservation) | +--------+--------------+
| | | Remove authorization |
|<--QoS-Response----+ | session state |
| | +--------+--------------+
|< - - - - STA - - - - - -+
+-------+--------+ |
|Delete QoS state|
| Report final |
| accounting data| QoS Responder
+-------+--------+ Node
+----------QoS-Reserve-----....--->|
| (Delete QoS |
| reservation)
|
+- - - - - ACR - - - - - >|
|(FINAL,QoS-Resources,Cost|
|CC-Time,Acc-Multisess-id)|
| +--------+--------------+
| | Report for successful |
| | end of QoS session |
| +--------+--------------+
|< - - - - ACA - - - - - -+
|
| QoS Responder
| Node
|<---------QoS-Response----....----+
| |
]]></artwork>
</figure></t>
</section>
<section title="Server-Side Initiated Session Termination">
<t>At anytime during a session the Authorizing Entity MAY send an
Abort- Session-Request message (ASR) to the Network Element. This is
a Diameter base protocol function and it is defined in <xref
target="RFC3588"></xref>. Possible reasons for initiating the ASR
message to the Network Element are insufficient credits or session
termination at the application layer. The ASR message results in
termination of the authorized session, release of the reserved
resources at the Network Element and transmission of an appropriate
QoS signaling message indicating a notification to other Network
Elements aware of the signaling session. A final accounting message
exchange MUST be triggered as a result of this ASR message exchange
(see <xref target="fig-server-termination"></xref>).</t>
<t><figure anchor="fig-server-termination"
title="Server-Side Initiated Session Termination">
<artwork><![CDATA[
Authorizing
End-Host Network Element Entity
requesting QoS ( Diameter ( Diameter
QoS Client) QoS Server)
| | |
|=====================Data Flow==========================>
| |
| |< - - - - ASR - - - - - -+
| | |
|====Data Flow=====>X | QoS Responder
| | | Node
|<--QoS-Notify------+----------QoS-Reserve-----....--->|
| | (Delete QoS | |
| reservation) |
+-------+--------+ |
|Delete QoS state| |
| Report final | |
| accounting data| |
+-------+--------+ |
+- - - - - ASA - - - - - >|
| +--------+--------------+
| | Remove authorization |
| | session state |
| +--------+--------------+
+- - - - - ACR - - - - - >|
|(FINAL,QoS-Resources,Cost|
|CC-Time,Acc-Multisess-id)|
| +--------+--------------+
| | Report for successful |
| | end of QoS session |
| +--------+--------------+
|< - - - - ACA - - - - - -+
| QoS Responder
| Node
|<---------QoS-Response----....----+
| |
]]></artwork>
</figure></t>
</section>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="accounting" title="Accounting">
<t>The Diameter QoS application provides accounting for usage of
reserved QoS resources. Diameter QoS accounting has built-in support for
online, duration based accounting. This accounting is based on the
notion that the Diameter QoS clients are in the best position to
determine the cost of those resources.</t>
<t>In the Diameter QoS application, the router MAY send a
Cost-Information AVP (see <xref target="RFC4006"></xref>) in the QAR. If
the Cost-Information AVP includes a Cost-Unit AVP (see <xref
target="RFC4006"></xref>) then the Cost-Unit SHOULD be "minute". The
Cost-Information AVPs represent the cost to allocate the resources
requested in the QoS-Resources AVP included in the same QAR message. The
QAR MAY optionally contain a Tariff-Time-Change AVP (see <xref
target="RFC4006"></xref>) which is the time at which the cost will
change, a second Cost-Information AVP, which is the cost of the reserved
resources after the tariff time change, and a second Tariff-Time-Change,
which is the time at which the tariff would change again. Either all
three or none of these AVPs MUST be present in the QAR.</t>
<t>The Resource Authorizing Entity returns a CC-Time AVP (see <xref
target="RFC4006"></xref>) in the QAA message which is the total
authorized gate-on time for the service. If the QAR included two
Tariff-Time-Change AVPs, the current time plus the CC-Time AVP returned
in the QAA MUST NOT exceed the second Tariff-Time-Change AVP from the
QAR. Based on information in the Cost-Information AVPs, the Resource
Authorizing Entity can use the CC-Time AVP to guarantee that the total
cost of the session will not exceed a certain threshold, which allows,
for example, support of prepaid users.</t>
<t>Each ACR message contains a triplet of QoS-Resources AVP,
Cost-Information AVP, and CC-Time AVP. This represents the total time
consumed at the given cost for the given resources. Note that an ACR
message MUST be sent separately for each interval defined by the
Tariff-Time-Change AVPs and the expiration of the CC-Time returned in
the QAA (see <xref target="fig-qos-request-re-authz"></xref>).</t>
<t>The Network Element starts an accounting session by sending an
Accounting-Request message (ACR) after successful QoS reservation and
activation of the data flow (see <xref
target="fig-initial-qos-request-pull"></xref>). After every successful
re-authorization procedure the Network element MUST initiate an interim
accounting message exchange (see <xref
target="fig-qos-request-re-authz"></xref>). After successful session
termination the Network element MUST initiate a final exchange of
accounting messages for terminating of the accounting session and
reporting final records for the usage of the QoS resources reserved (see
<xref target="fig-client-termination"></xref>).</t>
</section>
<!-- ====================================================================== -->
<section title="Diameter QoS Authorization Application Messages">
<t>The Diameter QoS Application requires the definition of new mandatory
AVPs and Command-codes (see Section 3 of <xref
target="RFC3588"></xref>). Four new Diameter messages are defined along
with Command-Codes whose values MUST be supported by all Diameter
implementations that conform to this specification.</t>
<t><figure>
<artwork><![CDATA[
Command-Name Abbrev. Code Reference
QoS-Authz-Request QAR [TBD] Section 5.1
QoS-Authz-Answer QAA [TBD] Section 5.2
QoS-Install-Request QIR [TBD] Section 5.3
QoS-Install-Answer QIA [TBD] Section 5.4
]]></artwork>
</figure></t>
<t>In addition, the following Diameter Base protocol messages are used
in the Diameter QoS application:</t>
<t><figure>
<artwork><![CDATA[
Command-Name Abbrev. Code Reference
Accounting-Request ACR 271 RFC 3588
Accounting-Request ACR 271 RFC 3588
Accounting-Answer ACA 271 RFC 3588
Re-Auth-Request RAR 258 RFC 3588
Re-Auth-Answer RAA 258 RFC 3588
Abort-Session-Request ASR 274 RFC 3588
Abort-Session-Answer ASA 274 RFC 3588
Session-Term-Request STR 275 RFC 3588
Session-Term-Answer STA 275 RFC 3588
]]></artwork>
</figure></t>
<t>Diameter nodes conforming to this specification MAY advertise support
by including the value of TBD in the Auth-Application-Id or the
Acct-Application-Id AVP of the Capabilities-Exchange-Request and
Capabilities-Exchange-Answer commands, see <xref
target="RFC3588"></xref>.</t>
<t>The value of TBD MUST be used as the Application-Id in all QAR/QAA
and QIR/QIA commands.</t>
<t>The value of TBD MUST be used as the Application-Id in all ACR/ACA
commands, because this application defines new, mandatory AVPs for
accounting.</t>
<t>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
defined in the Diameter base protocol and no additional mandatory AVPs
for those commands are defined in this document.</t>
<section title="QoS-Authorization Request (QAR)">
<t>The QoS-Authorization-Request message (QAR) indicated by the
Command- Code field (see Section 3 of <xref target="RFC3588"></xref>)
set to TBD and 'R' bit set in the Command Flags field is used by
Network elements to request quality of service related resource
authorization for a given flow.</t>
<t>The QAR message MUST carry information for signaling session
identification, Authorizing Entity identification, information about
the requested QoS, and the identity of the QoS requesting entity. In
addition, depending on the deployment scenario, an authorization token
and credentials of the QoS requesting entity SHOULD be included.</t>
<t>The message format, presented in ABNF form <xref
target="RFC2234"></xref>, is defined as follows:</t>
<t><figure>
<artwork><![CDATA[
<QoS-Request> ::= < Diameter Header: XXX, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
[ User-Name ]
* [ QoS-Resources ]
[ QoS-Authz-Data ]
[ Cost-Information ]
[ Acc-Multisession-Id ]
[ Bound-Auth-Session-Id ]
* [ AVP ]
]]></artwork>
</figure></t>
</section>
<section title="QoS-Authorization Answer (QAA)">
<t>The QoS-Authorization-Answer message (QAA), indicated by the
Command- Code field set to TBD and 'R' bit cleared in the Command
Flags field is sent in response to the QoS-Authorization-Request
message (QAR). If the QoS authorization request is successfully
authorized, the response will include the AVPs to allow authorization
of the QoS resources as well as accounting and transport plane gating
information.</t>
<t>The message format is defined as follows:</t>
<t><figure>
<artwork><![CDATA[
<QoS-Answer> ::= < Diameter Header: XXX, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Auth-Request-Type }
{ Result-Code }
{ Origin-Host }
{ Origin-Realm }
* [ QoS-Resources ]
[ CC-Time ]
[ Acc-Multisession-Id ]
[ Session-Timeout ]
[ Authz-Session-Lifetime ]
[ Authz-Grace-Period ]
* [ AVP ]
]]></artwork>
</figure></t>
</section>
<section title="QoS-Install Request (QIR)">
<t>The QoS-Install Request message (QIR), indicated by the
Command-Code field set to TDB and 'R' bit set in the Command Flags
field is used by Authorizing entity to install or update the QoS
parameters and the flow state of an authorized flow at the transport
plane element.</t>
<t>The message MUST carry information for signaling session
identification or identification of the flow to which the provided QoS
rules apply, identity of the transport plane element, description of
provided QoS parameters, flow state and duration of the provided
authorization.</t>
<t>The message format is defined as follows:</t>
<t><figure>
<artwork><![CDATA[
<QoS-Install-Request> ::= < Diameter Header: XXX, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
* [ QoS-Resources ]
[ Session-Timeout ]
[ Authz-Session-Lifetime ]
[ Authz-Grace-Period ]
[ Authz-Session-Volume ]
* [ AVP ]
]]></artwork>
</figure></t>
</section>
<section title="QoS-Install Answer (QIA)">
<t>The QoS-Install Answer message (QIA), indicated by the Command-Code
field set to TBD and 'R' bit cleared in the Command Flags field is
sent in response to the QoS-Install Request message (QIR) for
confirmation of the result of the installation of the provided QoS
reservation instructions.</t>
<t>The message format is defined as follows:</t>
<t><figure>
<artwork><![CDATA[
<QoS-Install-Answer> ::= < Diameter Header: XXX, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Result-Code }
* [ QoS-Resources ]
* [ AVP ]
]]></artwork>
</figure></t>
</section>
<section title="Re-Auth-Request (RAR)">
<t>The Re-Auth-Request message (RAR), indicated by the Command-Code
field set to 258 and the 'R' bit set in the Command Flags field, is
sent by the Authorizing Entity to the Network Element in order to
initiate the QoS re-authorization from DQA server side. </t>
<t>If the RAR command is received by the Network Element without any
parameters of the re-authorized QoS state, the Network Element MUST
initiate a QoS re-authorization by sending a QoS-Authorization-Request
(QAR) message towards the Authorizing entity.</t>
<t>The message format is defined as follows:</t>
<t><figure>
<artwork><![CDATA[
<Re-Auth-Request> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Auth-Request-Type }
[ Destination-Host ]
* [ QoS-Resources ]
[ Session-Timeout ]
[ Authz-Session-Lifetime ]
[ Authz-Grace-Period ]
[ Authz-Session-Volume ]
* [ AVP ]
]]></artwork>
</figure></t>
</section>
<section title="Re-Auth-Answer (RAA)">
<t>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 sent by the Network Element to the Authorizing Entity in response
to the RAR command..</t>
<t>The message format is defined as follows:</t>
<t><figure>
<artwork><![CDATA[
<Re-Auth-Answer> ::= < Diameter Header: 258, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Result-Code }
* [ QoS-Resources ]
* [ AVP ]
]]></artwork>
</figure></t>
</section>
<section title="Accounting Request (ACR)">
<t>The Accounting Request message (ACR), indicated by the Command-Code
field set to 271 and 'R' bit set in the Command Flags field is used by
Network Element to report parameters of the authorized and established
QoS reservation.</t>
<t>The message MUST carry accounting information authorized QoS
resources and its usage, e.g., QoS-Resources, CC-Time, CC-Cost,
Acc-Multi-Session-Id.</t>
<t>The message format is defined as follows:</t>
<t><figure>
<artwork><![CDATA[
<Accounting-Request> ::= < Diameter Header: XXX, REQ, PXY >
< Session-Id >
{ Acct-Application-Id }
{ Destination-Realm }
[ Destination-Host ]
[ Accounting-Record-Type ]
[ Accounting-Record-Number ]
* [ QoS-Resources ]
[ Cost-Information ]
[ CC-Time ]
[ Acc-Multi-Session-Id ]
* [ AVP ]
]]></artwork>
</figure></t>
</section>
<section title="Accounting Answer (ACA)">
<t>The Accounting Answer message (ACA), indicated by the Command-Code
field set to 271 and 'R' bit cleared in the Command Flags field is
sent in response to the Accounting Request message (ACR) as an
acknowledgment of the ACR message and MAY carry additional management
information for the accounting session, e.g. Acc-Interim-Interval
AVP.</t>
<t>The message format is defined as follows:</t>
<t><figure>
<artwork><![CDATA[
<Accounting-Answer> ::= < Diameter Header: XXX, PXY >
< Session-Id >
{ Acct-Application-Id }
[ Result-Code ]
[ Accounting-Record-Type ]
[ Accounting-Record-Number ]
[ Acc-Multi-Session-Id ]
* [ AVP ]
]]></artwork>
</figure></t>
</section>
</section>
<!-- ====================================================================== -->
<section title="Diameter QoS Authorization Application AVPs">
<t>Each of the AVPs identified in the QoS-Authorization-Request/Answer
and QoS-Install-Request/Answer messages and the assignment of their
value(s) is given in this section.</t>
<section anchor="diameter-base-avps" title="Diameter Base Protocol AVPs">
<t>The Diameter QoS application uses a number of session management
AVPs, defined in the Base Protocol (<xref
target="RFC3588"></xref>).</t>
<t><figure>
<artwork><![CDATA[
Attribute Name AVP Code Reference [RFC3588]
Origin-Host 264 Section 6.3
Origin-Realm 296 Section 6.4
Destination-Host 293 Section 6.5
Destination-Realm 283 Section 6.6
Auth-Application-Id 258 Section 6.8
Result-Code 268 Section 7.1
Auth-Request-Type 274 Section 8.7
Session-Id 263 Section 8.8
Authz-Lifetime 291 Section 8.9
Authz-Grace-Period 276 Section 8.10
Session-Timeout 27 Section 8.13
User-Name 1 Section 8.14
]]></artwork>
</figure></t>
<t>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 QoS application is TBD.</t>
<!--
<t>
Some of the listed AVPs require definition and assignment of additional values which is described here:
</t>
<t>
<list style="hanging">
<t hangText="Auth-Application-Id AVP">
<vspace blankLines="1"/> 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 QoS application is TBD (TBD).
<vspace blankLines="1"/>
</t>
<t hangText="Result-Code AVP">
<vspace blankLines="1"/> The Result-Code AVP indicates if a particular request was completed
successfully. Definition of QoS authorization specific Result-Code values is for further study.
(TBD)
<vspace blankLines="1"/>
</t>
</list>
</t>
-->
</section>
<section anchor="credit-control-avps"
title="Credit Control Application AVPs">
<t>The Diameter QoS application provides accounting for usage of
reserved QoS resources. Diameter QoS accounting has built-in support
for online, duration based accounting. For this purpose it re-uses a
number of AVPs defined in Diameter Credit Control application. <xref
target="RFC4006"></xref>.</t>
<t><figure>
<artwork><![CDATA[
Attribute Name AVP Code Reference [RFC4006]
Cost-Information AVP 423 Section 8.7
Unit-Value AVP 445 Section 8.8
Currency-Code AVP 425 Section 8.11
Cost-Unit AVP 424 Section 8.12
CC-Time AVP 420 Section 8.21
Tariff-Time-Change AVP 451 Section 6.20
]]></artwork>
</figure></t>
<t>Usage of the listed AVPs is described in <xref
target="accounting"></xref></t>
<t>Diameter QoS application is designed to independently provide
credit control over the controlled QoS resources. However, deployment
scenarios, where Diameter QoS application is collocated with Diameter
Credit Control application, are not excluded. In such scenarios the
credit control over the QoS resources might be managed by the Credit
control application. Possible interworking approach might be a usage
of Credit-Control AVP (AVP Code 426) with a newly defined value. It
will indicate to the Diameter QoS entities that the credit control
over the QoS resources would be handled in separate session by Credit
Control application. An active cooperation of both applications would
be required but it is not elaborated further in this document.</t>
<!-- <t>
<list style="hanging">
<t hangText="CC-Correlation-Id AVP">
<vspace blankLines="1"/>
The CC-Correlation-ID AVP (AVP code TBD) is of type OcterString and contains
information to correlate accounting data generated for different components
of the service, e.g. transport and application level.
</t>
</list>
</t>
-->
</section>
<!-- ====================================================================== -->
<!-- <section title="Authentication/Authorization AVPs">
<t>
Authentication and authorization is essential for the Diameter QoS application. Flexibility is
desired for deployment into infrastructures with different security features and usage
of authentication and authorization applications such as <xref target="RFC4027"/>
and <xref target="RFC4005"/>.
Multiple methods specified in these applications MIGHT be reused. Alternatively autonomous
and QoS-specific authentication methods may be supported depending on the features of the
QoS signaling protocols. Therefore, a number of AVPs of related Diameter applications can
be used.
</t>
<t>
The three party general approach (see <xref target="fig-three-party-approach"/>) utilizes
an EAP based authentication and session key exchange which requires the support of
AVPs defined in the Diameter-EAP application <xref target="I-D.ietf-aaa-eap"/>.
The details of the required attributes for authentication and authorization is for
further study.
</t>
</section>
-->
<!-- ====================================================================== -->
<section anchor="accounting-avps" title="Accounting AVPs">
<t>The Diameter QoS application uses Diameter Accounting and
accounting AVPs as defined in Section 9 of <xref
target="RFC3588"></xref>. Additional description of the usage of some
of them in the QoS authorization context is provided:</t>
<t><figure>
<artwork><![CDATA[
Attribute Name AVP Code Reference [RFC3588]
Acct-Application-Id 259 Section 6.9
Accounting-Record-Type 480 Section 9.8.1
Accounting-Interim-Interval 85 Section 9.8.2
Accounting-Record-Number 485 Section 9.8.3
Accounting-Realtime-Required 483 Section 9.8.7
Acc-Multi-Session-ID 50 Section 9.8.5
]]></artwork>
</figure></t>
<t>The following AVPs need further explanation:</t>
<t><list style="hanging">
<t hangText="Acct-Application-Id AVP"><vspace blankLines="1" />
The Acct-Application-Id AVP (AVP Code 259)is assigned by IANA to
Diameter applications. The value of the Acct-Application-Id for
the Diameter QoS application is TBD (TBD). <vspace
blankLines="1" /></t>
<t hangText="Acc-Multisession-ID"><vspace blankLines="1" />
Acc-Multi-Session-ID AVP (AVP Code 50) SHOULD be used to link
multiple accounting sessions together, allowing the correlation of
accounting information. This AVP MAY be returned by the Diameter
server in a QoS-Authorization-Answer message (QAA), and MUST be
used in all accounting messages for the given session.</t>
</list></t>
</section>
<!-- ====================================================================== -->
<section anchor="qos-new-avps"
title="Diameter QoS Application Defined AVPs">
<t>This document reuses the AVPs defined in Section 4 of <xref
target="I-D.ietf-dime-qos-attributes"></xref>.</t>
<t>This section lists the AVPs that are introduced specifically for
the Diameter QoS application. The followig new AVPs are defined:
Bound-Auth-Session-Id and the QoS-Authz-Data AVP.</t>
<t>The following table describes the Diameter AVPs newly defined in
this document for usage with the QoS Application, their AVP code
values, types, possible flag values, and whether the AVP may be
encrypted.</t>
<t><figure>
<artwork><![CDATA[
+-------------------+
| AVP Flag rules |
+----------------------------------------------|----+---+----+-----+
| AVP Section | | |SHLD| MUST|
| Attribute Name Code Defined Data Type |MUST|MAY| NOT| NOT|
+----------------------------------------------+----+---+----+-----+
|QoS-Authz-Data TBD 6.4 Grouped | M | P | | V |
|Bound-Auth-Session-Id TBD 6.4 UTF8String | M | P | | V |
+----------------------------------------------+----+---+----+-----+
|M - Mandatory bit. An AVP with "M" bit set and its value MUST be |
| supported and recognized by a Diameter entity in order the |
| message, which carries this AVP, to be accepted. |
|P - Indicates the need for encryption for end-to-end security. |
|V - Vendor specific bit that indicates whether the AVP belongs to |
| a address space. |
+------------------------------------------------------------------+
]]></artwork>
</figure></t>
<t></t>
<t><list style="hanging">
<t hangText="QoS-Authz-Data"><vspace blankLines="1" /> The
QoS-Authz-Data AVP (AVP Code TBD) is of type OctetString. It is a
container that carries application session or user specific data
that has to be supplied to the Authorizing entity as input to the
computation of the authorization decision. <vspace
blankLines="1" /></t>
<t hangText="Bound-Authentication-Session-Id"><vspace
blankLines="1" /> The Bound-Authentication-Session AVP (AVP Code
TBD) is of type UTF8String. It carries the id of the Diameter
authentication session that is used for the network access
authentication (NASREQ authentication session). It is used to tie
the QoS authorization request to a prior authentication of the end
host done by a co-located application for network access
authentication (Diameter NASREQ) at the QoS NE. <vspace
blankLines="1" /></t>
</list></t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="examples" title="Examples">
<section anchor="example_pull" title="Example call flow for pull mode">
<t>This section presents an example of the interaction between the end
host and Diameter QoS application entities using Pull mode. The
application layer signaling is, in this example, provided using SIP.
Signaling for a QoS resource reservation is done using the QoS NSLP.
The authorization of the QoS reservation request is done by the
Diameter QoS application (DQA).<figure anchor="fig-example-pull"
title="QoS Authorization Example - Pull Mode">
<artwork><![CDATA[
End-Host SIP Server Correspondent
requesting QoS (DQA Server) Node
| | |
..|....Application layer 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-Authz-Data ++------------+ |
| >===========>QoS-Resources, |Authorize | |
| |Cost-Info) |QoS resources| |
| | ++------------+ |
| | QAA | |
| <- - - - -<<AAA>>- - - -+ |
| |(Result-Code, | |
| |QoS-Resources, | |
| |CC-Time, | |
| |Authz-Lifetime) | |
| +---------+--------+ | |
| |Install QoS state1| | |
| |+ Authz. session | | |
| +---------+--------+ | |
| |QoS NSLP Reserve |
| +---------------..............--------->
| | |
| | QoS NSLP Response|
|QoS NSLP Response <---------------..............---------+
<------------------+ |
| | QoS NSLP Query|
|QoS NSLP Query <---------------..............---------+
<------------------+ |
|QoS NSLP Reserve | |
+------------------> QAR | |
| +- - - - -<<AAA>>- - - -> |
| | +---+---------+ |
| | |Authorize | |
| | |QoS resources| |
| | QAA +---+---------+ |
| <- - - - -<<AAA>>- - - -+ |
| +---------+--------+ | |
| |Install QoS state2| |
| |+ Authz. session | |
| +---------+--------+ |
| | QoS NSLP Reserve |
| +---------------..............--------->
| | QoS NSLP Response|
|QoS NSLP Response <---------------..............---------+
<------------------+ |
| | |
/------------------+--Data Flow---------------------------\
\------------------+--------------------------------------/
| | |
.-.-.-.-. SIP signaling
--------- QoS NSLP signaling
- - - - - Diameter QoS Application messages
========= Mapping of objects between QoS and AAA protocol
]]></artwork>
</figure></t>
<t>The communication starts with SIP signaling between the two end
points and the SIP server for negotiation and authorization of the
requested service and its parameters (see <xref
target="fig-example-pull"></xref>). As a part of the process, the SIP
server verifies whether the user at Host A is authorized to use the
requested service (and potentially the ability to be charged for the
service usage). Negotiated session parameters are provided to the end
host.</t>
<t>Subsequently, Host A initiates a QoS signaling message towards Host
B. It sends a QoS NSLP Reserve message, in which it includes
description of the required QoS (QSPEC object) and authorization data
for negotiated service session (part of the POLICY_DATA object).
Authorization data includes, as a minimum, the identity of the
authorizing entity (e.g., the SIP server) and an identifier of the
application service session for which QoS resources are requested.</t>
<t>A QoS NSLP Reserve message is intercepted and processed by the
first QoS aware Network Element. The NE uses the Diameter QoS
application to request authorization for the received QoS reservation
request. The identity of the Authorizing Entity (in this case the SIP
server that is co-located with a Diameter server) is put into the
Destination-Host AVP, any additional session authorization data is
encapsulated into the QoS-Authz-Data AVP and the description of the
QoS resources is included into QoS-Resources AVP. In addition, the NE
rates the requested QoS resources and announces the charging rate into
the Cost-Information AVP. These AVPs are included into a QoS
Authorization Request message, which is sent to the Authorizing
entity.</t>
<t>A Diameter QAR message will be routed through the AAA network to
the Authorizing Entity. The Authorizing Entity verifies the requested
QoS against the QoS resources negotiated for the service session and
replies with QoS-Authorization answer (QAA) message. It carries the
authorization result (Result-Code AVP) and the description of the
authorized QoS parameters (QoS-Resources AVP), as well as duration of
the authorization session (Authorization-Lifetime AVP) and duration of
the time (CC-Time) for which the end-user should be charged with the
rate announced in the QAR message. The NE interacts with the traffic
control function and installs the authorized QoS resources and
forwards the QoS NSLP Reserve message further along the data path.</t>
</section>
<section anchor="example_push" title="Example call flow for push mode">
<t>This section presents an example of the interaction between the
end-host and Diameter QoS application entities using Push Mode. The
application layer signaling is, in this example, provided using SIP.
Signaling for a QoS resource reservation is done using the QoS NSLP.
The authorization of the QoS reservation request is done by the
Diameter QoS application (DQA).<figure anchor="fig-example-push"
title="QoS Authorization Example - Push Mode">
<artwork><![CDATA[
End-Host NE SIP Server Correspondent
requesting QoS (DQA Client) (DQA Server) Node
| | | |
..|....Application layer SIP signaling..........|..............|..
. | Invite(SDP offer)| | | .
. +.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.> | .
. | 100 Trying | | | .
. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+ | .
. |.............................................|..............| .
| | +---------+-------------+|
| | | Authorize request ||
| | | Keep session data ||
| | |/Authz-time,Session-Id/||
| | +---------+-------------+|
| | | |
| |<-- - -- - QIR - -- - -- -+ |
| |(Initial Request,Decision | |
| |(QoS-Resources,Authz-time)| |
| +-------+---------+ | |
| |Install QoS state| | |
| | + | | |
| | Authz. session | | |
| | /Authz-time, | | |
| | CC-Time,Cost/ | | |
| +-------+---------+ | |
| + - - -- - QIA - - - - - ->| |
| | (Result-Code, | |
| | QoS-Resources) | |
| | +----------+------------+ |
| | | Report for successful | |
| | | QoS reservation | |
| | |Update of reserved QoS | |
| | | resources | |
| | +----------+------------+ |
. | | | Invite (SDP) | .
. | | +-.-.-.....-.-.> .
. | 180 (Ringing) | | .
. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.<.-.-.-.-.-.-.-+ .
. | | | 200 OK (SDP)| .
. | | <-.-.-.....-.-.+ .
| | +--------+-----------+ |
| | |re-Authorize session| |
| | | parameters | |
| | +--------+-----------+ |
| <- - - - - - RAR - - - - - + |
| +---------+--------+ | |
| |Activate QoS state| | |
| +---------+--------+ | |
| +- - - - - - RAA - - - - - > |
. | 200 (SDP answer) | | | .
. <.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.+ | .
| | |
/------------------+-----Data Flow---------------------------\
\------------------+-----------------------------------------/
| | |
.-.-.-.-. SIP signaling
- - - - - Diameter QoS Application messages
]]></artwork>
</figure></t>
<t>The communication starts with SIP signaling between the two end
points and the SIP server for negotiation and authorization of the
requested service and its parameters (see <xref
target="fig-example-push"></xref>). As a part of the process, the SIP
server verifies whether the user at Host A is authorized to use the
requested service (and potentially the ability to be charged for the
service usage). The DQA server is triggered to 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.</t>
<t>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 IP address (In this case a DQA server is co-located with a SIP
server and a DQA client is co-located with a Network element). The
identity of Network Element is put into the Destination-Host AVP, the
description of the QoS resources is included into QoS-Resources AVP,
as well as duration of the authorization session
(Authorization-Lifetime AVP) and duration of the time (CC-Time) for
which the end-user should be charged with the rate announced in the
QIR message. The NE interacts with the traffic control function and
reserves the authorized QoS resources accordingly.</t>
<t>With successful QoS authorization, the SDP offer in SIP Invite is
forwared to Host B. Host B sends back a 18x (ringing) message 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 accepted
session parameters (i.e. SDP answer).</t>
<t>The DQA server may verifies the accepted QoS against the
pre-authorized QoS resources, and sends a Diameter RAR message to the
DQA client in the network element for activating the installed
policies and commit the resource allocation. With successful QoS
enforcement, the 200 OK is forwarded towards Host A.</t>
<t>Note that the examples above show a sender-initiated reservation
from the End-Host towards the corresponding node and a
receiver-initiated reservation from the correspondent node towards the
End-Host.</t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="iana" title="IANA Considerations">
<t>TBD</t>
</section>
<!-- ====================================================================== -->
<section anchor="security" title="Security Considerations">
<t>TBD</t>
</section>
<!-- ====================================================================== -->
<section title="Acknowledgements">
<t>The authors would like to thank John Loughney and Allison Mankin for
their input to this document. In September 2005 Robert Hancock, Jukka
Manner, Cornelia Kappler, Xiaoming Fu, Georgios Karagiannis and Elwyn
Davies provided a detailed review. Robert also provided us with good
feedback earlier in 2005. Jerry Ash provided us review comments late
2005/early 2006. Rajith R provided some inputs to the document early
2007</t>
<t>[Editor's Note: Acknowledgements need to be updated.]</t>
</section>
<!-- ====================================================================== -->
<section anchor="contributors" title="Contributors">
<t>The authors would like to thank Tseno Tsenov (tseno.tsenov@gmail.com)
and Frank Alfano (falfano@lucent.com) for starting the Diameter Quality
of Service work within the IETF, for your significant draft
contributions and for being the driving force for the first few draft
versions.</t>
<t>[Editor's Note: A bit of history needs to be included here.]</t>
</section>
<!-- ====================================================================== -->
<section anchor="open-issue" title="Open Issues">
<t>Open issues related to this draft are listed at the issue tracker
available at: http://www.tschofenig.com:8080/diameter-qos/</t>
</section>
</middle>
<!-- ====================================================================== -->
<back>
<references title="Normative References">
&RFC2119;
&RFC2234;
&RFC3588;
&RFC4006;
&RFC4005;
&I-D.ietf-dime-qos-attributes;
</references>
<references title="Informative References">
&I-D.ietf-nsis-qos-nslp;
&RFC4566;
&RFC2749;
&RFC2210;
&RFC2753;
&RFC4027;
&RFC2865;
&RFC3521;
&RFC3313;
&I-D.ietf-nsis-ntlp;
&RFC3520;
&RFC2486;
</references>
<!-- ====================================================================== -->
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 14:40:32 |