ETSI TS 183 017 V3.2.1 (2010-02)

Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Resource and Admission Control: DIAMETER protocol for session based policy set-up information exchange between the Application Function (AF) and the Service Policy Decision Function (SPDF); Protocol specification

RTS/TISPAN-03205-NGN-R3

General Information

• Status: Published
• Publication Date: 22-Feb-2010
• Technical Committee: TISPAN 3 - TISPAN Protocols
• Current Stage: 12 - Completion
• Due Date: 03-Mar-2010
• Completion Date: 23-Feb-2010

Standards Content (Sample)

Technical Specification
Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN);
Resource and Admission Control:
DIAMETER protocol for session based policy set-up
information exchange between the Application Function (AF)
and the Service Policy Decision Function (SPDF);
Protocol specification
2 ETSI TS 183 017 V3.2.1 (2010-02)

Reference
RTS/TISPAN-03205-NGN-R3
Keywords
interface, stage 3
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2010.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 183 017 V3.2.1 (2010-02)
Contents
Intellectual Property Rights . 5
Foreword . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 8
4 Gq' interface . 9
4.1 Overview . 9
4.2 Gq' reference model . 9
4.3 Functional elements and capabilities . 10
4.3.1 Service-based Policy Decision Function (SPDF) . 10
4.3.2 Application Function (AF) . 10
5 Procedures descriptions . 10
5.1 Procedures at the AF . 10
5.1.1 Initial reservation for a session . 10
5.1.2 Session modification . 11
5.1.3 Session termination . 13
5.2 Procedures at the SPDF . 13
5.2.1 Initial reservation for a session . 13
5.2.2 Session modification . 14
5.2.3 Session termination . 14
5.2.4 SPDF notifications . 14
5.3 IMS related P-CSCF procedures . 14
5.3.1 Provisioning of service information at the P-CSCF . 14
5.3.2 Enabling IP flows at the P-CSCF . 15
6 Use of the Diameter base protocol . 15
6.1 Securing Diameter messages . 15
6.2 Accounting functionality . 15
6.3 Use of sessions . 15
6.4 Transport protocol . 16
6.5 Routing considerations . 16
6.6 Advertising application support . 16
7 DIAMETER application. 16
7.1 Commands . 17
7.1.1 AA-Request (AAR) command . 17
7.1.2 AA-Answer (AAA) command . 17
7.1.3 Re-Auth-Request (RAR) command . 18
7.1.4 Re-Auth-Answer (RAA) command . 18
7.1.5 Session-Termination-Request (STR) command . 18
7.1.6 Session-Termination-Answer (STA) command . 19
7.1.7 Abort-Session-Request (ASR) command . 19
7.1.8 Abort-Session-Answer (ASA) command . 19
7.2 Experimental-Result-Code AVP values . 20
7.2.1 Experimental-Result-Code AVP values imported from TS 129 209 . 20
7.2.2 Experimental-Result-Code AVP values imported from ES 283 026 . 20
7.2.3 Experimental-Result-Code AVP values defined in the present document . 20
7.3 AVPs . 20
7.3.1 Binding-information AVP . 23
7.3.2 Binding-Input-List AVP . 23
ETSI
4 ETSI TS 183 017 V3.2.1 (2010-02)
7.3.3 Binding-Output-List AVP . 23
7.3.4 V6-Transport-address AVP . 23
7.3.5 V4-Transport-address AVP . 24
7.3.6 Port-number AVP . 24
7.3.7 Reservation-Class AVP . 24
7.3.8 Latching-indication AVP . 24
7.3.9 Reservation-priority AVP . 24
7.3.10 Globally-unique-address AVP . 25
7.3.11 Address-realm AVP . 25
7.3.12 Framed-IP-address AVP . 25
7.3.13 Framed-IPv6-prefix AVP . 25
7.3.14 Abort-cause AVP . 25
7.3.15 AF-application-identifier AVP . 25
7.3.16 AF-charging-identifier AVP . 26
7.3.17 Flow-description AVP . 26
7.3.18 Flow-grouping AVP . 26
7.3.19 Flow-number AVP . 27
7.3.20 Flows AVP. 27
7.3.21 Flow-status AVP . 27
7.3.22 Flow-usage AVP . 27
7.3.23 Specific-action AVP . 28
7.3.24 Max-requested-bandwidth-DL AVP . 28
7.3.25 Max-requested-bandwidth-UL AVP . 29
7.3.26 Media-component-description AVP . 29
7.3.27 Media-component-number AVP . 29
7.3.28 Media-sub-component AVP . 30
7.3.29 Media-type AVP . 30
7.3.30 RR-bandwidth AVP . 30
7.3.31 RS-bandwidth AVP . 30
7.3.32 SIP-forking-indication AVP . 31
7.3.33 Service-Class AVP . 31
7.3.34 Transport-Class AVP . 31
7.3.35 Overbooking-indicator . 31
7.3.36 Codec-Data AVP . 31
7.3.37 Authorization-Package-Id . 31
7.3.38 Media-Authorization-Context-Id . 31
7.3.39 Logical-Access-ID AVP . 31
7.4 Use of namespaces . 32
7.4.1 AVP codes . 32
7.4.2 Experimental-result-code AVP values . 32
7.4.3 Command code values . 32
7.4.4 Application-ID value . 32
Annex A (normative): Support for SIP forking . 33
A.1 Support for SIP forking . 33
A.1.1 Authorization of resources for early media for forked responses . 33
A.1.2 Updating the authorization information at the final answer . 33
Annex B (normative): QoS parameter mapping for IMS for unicast flows . 34
B.1 SDP to service information mapping in AF . 34
Annex C (normative): QoS parameter mapping for IMS for multicast flows . 38
C.1 SDP to service information mapping in AF for the IMS with multicast flows . 38
Annex D (informative): Bibliography . 41
Annex E (informative): Change history . 42
History . 43

ETSI
5 ETSI TS 183 017 V3.2.1 (2010-02)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet
converged Services and Protocols for Advanced Networking (TISPAN).
ETSI
6 ETSI TS 183 017 V3.2.1 (2010-02)
1 Scope
The present document provides the stage 3 specification of the Gq' interface. The functional requirements and the
stage 2 specifications of the Gq' interface are contained in ES 282 001 [1] and ES 282 003 [2]. The Gq' interface is the
interface between the Application Function (AF) and the Service Policy Decision Function (SPDF) and is used for
session based policy set-up information exchange between the SPDF and the AF.
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1] ETSI ES 282 001: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); NGN Functional Architecture".
[2] ETSI ES 282 003: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Resource and Admission Control Sub-System (RACS):
Functional Architecture".
[3] IETF RFC 3588: "Diameter Base Protocol".
[4] ETSI TS 129 209: "Universal Mobile Telecommunications System (UMTS); Policy control over
Gq interface (3GPP TS 29.209 Release 6)".
[5] IETF RFC 4005: "Diameter Network Access Server Application".
[6] ETSI TS 133 210: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); 3G security; Network Domain Security (NDS); IP network
layer security (3GPP TS 33.210)".
[7] ETSI ES 283 003: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); IP Multimedia Call Control Protocol based on Session
Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3
[3GPP TS 24.229 (Release 7), modified]".
ETSI
7 ETSI TS 183 017 V3.2.1 (2010-02)
[8] ETSI ES 283 018: "Telecommunications and Internet Converged Services and Protocols for
Advanced Networking (TISPAN); Resource and Admission Control: H.248 Profile for controlling
Border Gateway Functions (BGF) in the Resource and Admission Control Subsystem (RACS);
Protocol specification".
[9] IETF RFC 4566 (2006): "SDP: Session Description Protocol".
[10] IETF RFC 2960: "Stream Control Transmission Protocol".
[11] IETF RFC 3309: "Stream Control Transmission Protocol (SCTP) Checksum Change".
[12] ETSI TS 129 207: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Policy control over Go interface
(3GPP TS 29.207 Release 6)".
[13] ETSI ES 283 035: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Network Attachment Sub-System (NASS); e2 interface based
on the DIAMETER protocol".
[14] ETSI ES 283 026: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Resource and Admission Control; Protocol for QoS reservation
information exchange between the Service Policy Decision Function (SPDF) and the Access-
Resource and Admission Control Function (A-RACF) in the Resource and Protocol specification".
[15] ETSI ES 283 034: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Network Attachment Sub-System (NASS); e4 interface based
on the DIAMETER protocol".
[16] IETF RFC 3556: "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control
Protocol (RTCP) Bandwidth".
[17] IETF RFC 3388: "Grouping of Media Lines in the Session Description Protocol (SDP)".
[18] IETF RFC 3524: "Mapping of Media Streams to Resource Reservation Flows".
[19] ETSI TS 129 214: "Universal Mobile Telecommunications System (UMTS); LTE; Policy and
charging control over Rx reference point (3GPP TS 29.214 Release 7)".
[20] ETSI TS 183 063: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); IMS-based IPTV stage 3 specification".
[21] ETSI TS 183 048: "Telecommunications and Internet Converged Services and Protocols for
Advanced Networking (TISPAN); Resource and Admission Control System (RACS); Protocol
Signalling flows specification; RACS Stage 3".
[22] IETF RFC 3264: "An Offer/Answer Model with Session Description Protocol (SDP)".
2.2 Informative references
The following referenced documents are not essential to the use of the present document but they assist the user with
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including
any amendments) applies.
Not applicable.
ETSI
8 ETSI TS 183 017 V3.2.1 (2010-02)
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
Application Function (AF): element offering applications that require the control of IP bearer resources
NOTE: The AF is capable of communicating with the SPDF to transfer dynamic QoS-related application
information. One example of an AF is the P-CSCF of the IMS.
AF session: established by an application level signalling protocol offered by the AF that requires a session set-up with
explicit session description before the use of the service
NOTE: One example of an application session is an IMS session.
AF session signalling: used to control the AF session
NOTE: One example of AF session signalling is SIP/SDP.
Attribute-Value Pair (AVP): Information Element in a Diameter message
NOTE: See RFC 3588 [3].
hard-state reservation: type of reservation whereby the requested resources are reserved without time limit
NOTE: Hard-state reservations are terminated when the DIAMETER session is terminated.
soft-state reservation: type of reservation whereby the requested resources are reserved for a finite amount of time
NOTE: Soft-state reservations are terminated if the DIAMETER session is terminated.
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AAA AA-Answer
AAR AA-Request
AF Application Function
A-RACF Access-RACF
ASA Abort-Session-Answer
ASR Abort-Session-Request
AVP Attribute-Value Pair
BGF Border Gateway Function
CEA Capabilities-Exchange-Answer
CER Capabilities-Exchange-Request
GPRS General Packet Radio Service
IANA Internet Assigned Numbers Authority
IMS IP Multimedia Subsystem
IP Internet Protocol
IP-CAN IP Connectivity Access Network
IP-CAN IP-Connectivity Access Network
NAPT Network Address and Port Translation
NASREQ Network Access Server Application
P-CSCF Proxy - Call Session Control Function
PDF Policy Decision Function
QoS Quality of Service
RAA Re-Auth-Answer
RACF Resource and Admission Control Function
RACS Resource and Admission Control Subsystem
RAR Re-Auth-Request
ETSI
9 ETSI TS 183 017 V3.2.1 (2010-02)
RTCP Realtime Transport Control Protocol
RTP Realtime Transport Protocol
SCTP Stream Control Transport Protocol
SDI Session Description Information
SDP Session Description Protocol
SIP Session Initiation Protocol
SPDF Service-based Policy Decision Function
STA Session-Termination-Answer
STR Session-Termination-Request
UDP User Datagram Protocol
UE User Equipment
4 Gq' interface
4.1 Overview
The Gq' interface is used for the service-based policy set-up information exchange between the SPDF and the AF,
e.g. the P-CSCF. As defined in the stage 2 specification (ES 282 003 [2]), this information is used by the SPDF for the
Service Based Policy decisions.
The Gq' interface may be an intra- or inter-domain interface. One SPDF instance shall be able to serve more than one
AF instance and one given AF instance may interact with a number of SPDF instances, although on an AF session
basis, it shall interact with only a single SPDF instance.
4.2 Gq' reference model
The Gq' interface is defined between the AF and the SPDF. Within the present release, the Gq' interface is used for
requesting transport plane resources and admission control for fixed broadband access networks (e.g. xDSL).
NOTE: When supporting a GPRS IP-CAN, the AF will apply the procedures specified in TS 129 209 [4].
Scope of the present
Gq
specification AFAF
TS.129.209
Gq'
’
Rq PDF
SPSPDDFF
AA-- RARA CCFF
Ia
BGF
Figure 4.2.1: Gq' reference model
ETSI
10 ETSI TS 183 017 V3.2.1 (2010-02)
4.3 Functional elements and capabilities
4.3.1 Service-based Policy Decision Function (SPDF)
The SPDF is a functional element that coordinates the resource reservation requests received from the AF. The SPDF
makes policy decisions using policy rules and forwards the session and media related information obtained from the AF
to the A-RACF for admission control purposes. Additionally, based on information received on the Gq' interface and on
configuration data, the SPDF may request the instantiation of a border gateway function (BGF) via the Ia interface. The
functionality of the SPDF is further detailed in ES 282 003 [2].
4.3.2 Application Function (AF)
The AF is a functional element offering applications that request and use IP bearer resources. The AF shall use the Gq'
interface to exchange session and media related information with the SPDF. One example of an application function is
the P-CSCF of the IMS.
5 Procedures descriptions
5.1 Procedures at the AF
5.1.1 Initial reservation for a session
Upon receipt of an AF session signalling message initiating a new AF session, the AF shall request an authorization for
the session from the SPDF by sending the AA-Request message. This AA-Request message shall contain a new
Session-Id.
NOTE: As specified in RFC 3588 [3], the Session-Id is globally unique and is meant to uniquely identify a user
session without reference to any other information. The Session-Id begins with the sender's identity
encoded in the DiameterIdentity type.
The AA-Request message may contain an Authorization-Lifetime AVP as a hint of the maximum lifetime that it is
requesting. When requesting for Hard-state reservation, the AF shall not include an Authorization-Lifetime AVP.
The AF shall include the corresponding Media-Component-Description AVP(s) into the message if the SDI is already
available at the AF. The AF may include the Flow-Grouping AVP(s) to request a particular way for the IP flows
described within the service description to be distributed to IP-CAN bearers.
When providing a given Media-Component-Description AVP in the initial AA-Request, the AF may request the SPDF
to Commit the requested resources by setting the Flow-Status AVP to the value ENABLED, ENABLED-UPLINK or
ENABLED-DOWNLINK. Alternatively, the AF may perform this in two phases in using separate reserve and commit
operations. When using the two phases method, the Flow-Status AVP value of the initial AA-Request message shall be
set to DISABLED.
The AF may also include the AF-Charging-Identifier AVP into the message for the charging correlation purposes.
Based on local configuration data, the AF determines that address translation needs to occur on the user plane
(e.g. a BGF on the media path performs NAPT, IP version interworking or hosted NAPT procedures), upon receipt of
SDI pointing towards the endpoint served by the AF (e.g. for IMS, in case the P-CSCF receives an SDP offer sent by
the served UE), the AF shall include the Binding-Information AVP with the Input-List AVP. The Input-List AVP shall
be populated based on the received SDI as follows:
• for each IP-flow information within the received SDI, the AF shall set the V6-Transport-Address AVP or
V4-Transport-Address AVP with the corresponding IP address and port number.
If required (e.g. the received SDI is sent by a served endpoint with hosted-NAPT configuration), the AF may also
include the Latching-Indication AVP set to "LATCH".
ETSI
11 ETSI TS 183 017 V3.2.1 (2010-02)
For the purpose of access profile correlation in the A-RACF, the AF shall include within the AA-Request a correlation
identifier in the form:
• either of the User-Name AVP; and/or
• the Globally-Unique-Address AVP.
The above AVPs are defined in [13] and their contents are made available to the AF via the e2 interface.
The mapping of information element names defined in TS 129 214 [19] and Diameter AVPs used in the present
document is given in table 5.1.1.1.
Table 5.1.1.1: Mapping of information element names to Diameter AVPs
Information element name Mapping to Diameter AVP Cat.
Subscriber ID User-Name O
Globally Unique IP Address Globally-Unique-Address O
Requestor Name AF-Application-Identifier O
Service Class Service-Class O
Media Type Media-Type O
Reservation Class Reservation-Class O
Authorization package ID Authorization package ID O
Media_Authorization Context ID Media_Authorization Context O
ID
Transport Service Class Transport-Class O

The AF may specify the Reservation-Priority AVP at request level in the AA-Request in order to assign a priority to the
request. The AF may further specify the Reservation-Priority AVP in Media-Component-Description AVP(s) in order
to assign priority to individual media. If the Reservation-Priority AVP is not specified the requested priority is
DEFAULT (0).
The AF may specify one or more Media-Authorization-Context-Id AVP or Authorization-Package-Id AVP to specify
the authorization context of a media component or a session respectively. In the case of a multicast media reservation,
the derived authorization context stored in A-RACF may provide information on the multicast channels allowed or not
allowed during the session and their respective QoS requirements.
The AF may specify the Specific-Action AVP in the AA-Request with the events of which it wants to be informed.
The AF shall store the contents of the Output-List AVP received within the Binding-Information AVP contained in the
AA-Answer message for future use.
The behaviour when the AF does not receive the AA-Answer, or when it arrives after the internal timer waiting for it
has expired, or when it arrives with an indication different than DIAMETER_SUCCESS, is outside the scope of the
present document.
The AF may specify the Overbooing Indicator AVP in the AA-Request when it is known by the AF that the resources
required by the session may be used by more than one AF-session but not at a same time.
5.1.2 Session modification
During the AF session modification, the AF shall send an update for the session description information to the SPDF
based on the new SDI exchanged within the AF session signalling. The AF does this by sending the AA-Request
message with an existing Session-Id and Media-Component-Description AVP(s) containing the updated service
information.
ETSI
12 ETSI TS 183 017 V3.2.1 (2010-02)
The AF may request the SPDF to commit the requested resource modifications by setting the Flow-Status-AVP to the
value ENABLED, ENABLED-UPLINK or ENABLED-DOWNLINK. Alternatively, the AF may perform the
modification in two phases in using separate modification reserve and commit operations. When using the two phases
method, the Flow-Status-AVP value of the first AA-Request message for modifications shall be set to DISABLED. The
affected media flows shall not be stopped. Resources need to be reserved in a way that they allow either to commit the
updated media components or to roll back to the unmodified media components. In case the modification needs to be
reverted due to the received SDP answer, the AF shall request the SPDF to roll back to the unmodified reservation by
sending an AA-Request with the unmodified Media-Component-Description AVP(s), setting the Flow-Status-AVP
back to the values ENABLED, ENABLED-UPLINK or ENABLED-DOWNLINK. To commit the modification, the AF
shall send an AAR request with the updated Media-Component-Description AVP(s), setting the Flow-Status-AVP to
the values ENABLED, ENABLED-UPLINK or ENABLED-DOWNLINK.
When refreshing an existing session, the AF may issue an AA-Request without any Media-Component-Description
AVP. The AF may include the Flow-Grouping AVP(s) to request a particular way for the IP flows described within the
service description to be distributed to IP-CAN bearers.
The AF SHALL NOT use the RAA to modify the session service information. As an option, the AF MAY send an AAR
command following an RAA to update the session service information.
The AF may perform the following operations:
- Add a new IP flow within an existing media component - provide a new Media-Sub-Component AVP within
the corresponding Media-Component-Description AVP.
- Add a new IP flow within a new media component - provide a new Media-Component-Description AVP.
- Modify a media component - update the corresponding Media-Component-Description AVP (e.g. increase or
decrease the allocated bandwidth).
- Modify an existing IP flow within a media component - update the corresponding Media-Sub-Component
AVP.
- Modify the commit status - change the Flow-Status AVP of the corresponding Media-Component-Description
AVP and/or Media-Sub-Component to one of the values ENABLED-UPLINK (0),
ENABLED-DOWNLINK (1) or ENABLED (2), according to the direction in which the resources are to
be committed.
- Release a media component - provide the corresponding Media-Component-Description AVP with the
Flow-Status AVP set to the value REMOVED (4).
- Release an IP flow within a media component - provide the corresponding Media-Sub-Component AVP with
the Flow-Status AVP set to the value REMOVED (4).
- Refresh a soft-state reservation - provide an Authorization-Lifetime AVP in the AA-Request as a hint of the
maximum lifetime that it is requesting.
- Modify the media level authorization context - provide new Media-Authorization-Context-Id AVP(s). The
new Authorization-Context-Id AVP(s) replace any authorization context previously associated to the media
component.
- Modify the session level authorization context - provide new Authorization-Package-Id AVP(s). The new
Authorization-Package-Id AVP(s) replace any authorization context previously associated to session.
- In case overbooking is set when having a modification than no additional resources need to be reserved.
In case any of the Specific-Action AVP, the AF-Charging-Identifier AVP, the Flow-Grouping AVP, the Service-Class
AVP, the User-Name AVP, or the Globally-Unique-Address AVP was provided in an initial AA-Request, the provided
AVP(s) shall have the same value if provided also in a modifying AA-Request.
If present, the Reservation-Priority AVP associated with a reservation request or a media component shall not be
modified by the AF.
ETSI
13 ETSI TS 183 017 V3.2.1 (2010-02)
The AF may also, if updated SDI pointing towards the endpoint served by the AF is available with updated addressing
information pointing to the served endpoint, and that it determines that address translation needs to occur on the user
plane (e.g. BGF on the media path performs NAPT, IP version interworking or hosted NAPT procedures), the AF shall
include the Binding-Information AVP with the Input-List AVP set based on the received SDI. The Input-List AVP shall
contain addressing information for the entire set of IP flows (i.e. modified and non modified).
The AF shall store the contents of the Output-List AVP received within the Binding-Information AVP contained in the
AA-Answer message for future use.
If required (e.g. in cases where the served endpoint is behind a hosted-NAPT), and updated addressing information
pointing towards the served endpoint is available, the AF shall include the Latching-Indication AVP set to
"RELATCH".
The behaviour when the AF does not receive the AA-Answer, or when it arrives after the internal timer waiting for it
has expired, or when it arrives with an indication different than DIAMETER_SUCCESS, are outside the scope of the
present document.
5.1.3 Session termination
When the AF session is terminated, the AF shall terminate the Diameter session by sending a
Session-Termination-Request message to the SPDF.
5.2 Procedures at the SPDF
5.2.1 Initial reservation for a session
Upon receipt of an initial AA-Request, the SPDF determines based on local policy whether a BGF and/or an A-RACF
need to be involved in the AF session. If this is the case, the SPDF determines the address of the BGF and A-RACF
using local policy.
If the AA-Request contains the Media-Component-Description AVP(s), the SPDF shall trigger the Resource
Reservation procedure towards the A-RACF. If the AA-Request contains the User-Name AVP and/or the
Globally-Unique-IP-Address AVP, the SPDF uses this information as part of the resource reservation procedure
performed on the Rq interface.
Additionally, based on the contents of the AA-Request (e.g. the AA-Request may contain AVPs such as the
Reservation-Class AVP and/or Binding-Information AVP) and on local policy rules, the SPDF may request BGF
services.
The SPDF shall wait for the result of the above interaction(s) with the A-RACF and/or the BGF before returning, in a
single AA-Answer message, the result of those interactions to the AF. The contents of the AA-Answer shall be derived
as follows:
• If the resource reservation procedure succeeds and if the requested binding information was received via the Ia
interface, the AA-Answer message sent by the SPDF to the AF shall contain the Binding-Output-List AVP.
• If the resource reservation procedure fails (i.e. the SPDF receives a reservation failure notification via the Rq
interface), the SPDF shall return the Experimental-Result-Code AVP with the value
INSUFFICIENT_RESOURCES in the AA-Answer.
• If the resource reservation procedure succeeds but the SPDF did not succeed in getting a binding via the Ia
interface, the SPDF shall return the Experimental-Result-Code AVP with the value BINDING_FAILURE in
the AA-Answer.
• If the SPDF fails in finding an appropriate A-RACF or BGF instance needed to serve the resource reservation
request, the SPDF may return the Result-Code with the value UNABLE_TO_DELIVER in the AA-Answer.
Once the SPDF recognizes, based on the contents of an AA-Request and possibly on configuration data, that BGF
services are requested on the transport plane, the SPDF shall use the contents of the AA-Request in order to enforce any
service needed over the Ia interface. The detailed procedures are as specified in [8].
ETSI
14 ETSI TS 183 017 V3.2.1 (2010-02)
5.2.2 Session modification
The SPDF may receive the AA-Request message from the AF with modified service information. Based on the contents
of the AA-Request, the SPDF shall coordinate any required modifications to existing resource reservation over the Rq
interface and/or to existing BGF settings instantiated via the Ia interface. As described in clause 5.2.1, the SPDF shall
acknowledge the session modification by issuing an AA-Answer back to the AF only after all actions taken upon the Rq
and/or Ia interfaces are achieved.
Depending on the value of the Flow-Status AVP received from the AF, the SPDF may interpret the session modification
as a commitment of requested resources.
Once the SPDF recognizes, based on the contents of an AA-Request and possibly on configuration data, that BGF
functions are requested on the transport plane or that BGF functions are already in use and need to be configured, the
SPDF shall use the contents of the AA-Request in order to enforce any functions need
...