ETSI TS 183 071 V3.1.1 (2010-02)
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Resource and Admission Control Sub-System (RACS); Rr interface based on the DIAMETER protocol
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Resource and Admission Control Sub-System (RACS); Rr interface based on the DIAMETER protocol
DTS/TISPAN-03196-NGN-R3
General Information
Standards Content (Sample)
Technical Specification
Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN);
Resource and Admission Control Sub-System (RACS);
Rr interface based on the DIAMETER protocol
2 ETSI TS 183 071 V3.1.1 (2010-02)
Reference
DTS/TISPAN-03196-NGN-R3
Keywords
interface, network, system
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
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 071 V3.1.1 (2010-02)
Contents
Intellectual Property Rights . 6
Foreword . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 8
3 Definitions and abbreviations . 8
3.1 Definitions . 8
3.2 Abbreviations . 8
4 Overview . . 10
5 Procedure descriptions . 10
5.1 General . 10
5.1.1 Information elements . 10
5.2 Procedures on the Rr interface . 11
5.2.1 Resource control procedures for Request Model . 11
5.2.1.1 Procedures at the Top-tier x-RACF . 12
5.2.1.1.1 Resource Reservation Session Establishment and Initial Resource Reservation . 12
5.2.1.1.2 Resource Modification and Release for Media Flows . 13
5.2.1.1.3 Termination and Release of the Resources for a Resource Reservation Session. 14
5.2.1.1.4 Event notification . 14
5.2.1.2 Procedures at the lower-tier x-RACF . 15
5.2.1.2.1 Initial Resource Reservation . 15
5.2.1.2.2 Resource Modification and Release for Media Flows . 16
5.2.1.2.3 Termination and Release of the Resources for a Resource Reservation Session. 17
5.2.1.2.4 Event Notification . 17
5.2.2 Procedures for Delegated Model . 17
5.2.2.1 Delegation Push triggered by the delegating x-RACF . 17
5.2.2.1.1 Procedures at the delegating x-RACF . 17
5.2.2.1.2 Procedures at the delegated x-RACF . 18
5.2.2.2 Delegation Negotiation triggered by the delegated x-RACF . 18
5.2.2.2.1 Procedures at the delegated x-RACF . 18
5.2.2.2.2 Procedures at the delegating x-RACF . 18
5.2.2.3 Delegation Negotiation triggered by the delegating x-RACF . 19
5.2.2.3.1 Procedures at the delegating x-RACF . 20
5.2.2.3.2 Procedures at the delegated x-RACF . 20
5.2.2.4 Delegation Query triggered by the delegating x-RACF . 21
5.2.2.4.1 Procedures at the delegating x-RACF . 21
5.2.2.4.2 Procedures at the delegated x-RACF . 21
5.2.2.5 Delegation Query triggered by the delegated x-RACF . 22
5.2.2.5.1 Procedures at the delegated x-RACF . 22
5.2.2.5.2 Procedures at the delegating x-RACF . 22
5.2.2.6 Event Notification triggered the delegating x-RACF . 23
5.2.2.7 Event Notification at the delegated x-RACF . 23
6 DIAMETER application for Request Model . 23
6.1 Use of the Diameter base protocol . 23
6.1.1 Securing Diameter Messages . 23
6.1.2 Accounting functionality . 23
6.1.3 Use of sessions . 24
6.1.4 Transport protocol . 24
6.1.5 Routing considerations . 24
6.1.6 Advertising Application Support . 24
6.2 Commands . 24
6.2.1 AA-Request (AAR) Command . 24
ETSI
4 ETSI TS 183 071 V3.1.1 (2010-02)
6.2.2 AA-Answer (AAA) Command . 25
6.2.3 Re-Auth-Request (RAR) Command . 25
6.2.4 Re-Auth-Answer (RAA) Command . 25
6.2.5 Session-Termination-Request (STR) Command . 26
6.2.6 Session-Termination-Answer (STA) Command . 26
6.2.7 Abort-Session-Request (ASR) Command . 26
6.2.8 Abort-Session-Answer (ASA) Command . 27
6.3 Experimental-Result-Code AVP values . 27
6.3.1 Experimental-Result-Code AVP values imported from TS 129 209 . 27
6.3.2 Experimental-Result-Code AVP values imported from TS 183 026 . 27
6.4 Use of namespaces . 28
6.4.1 AVP codes . 28
6.4.2 Experimental-Result-Code AVP values . 28
6.4.3 Command Code values . 28
6.4.4 Application-ID value . 28
6.5 AVPs . 28
6.5.1 Abort-Cause AVP . 30
6.5.2 AF-Application-Identifier AVP . 30
6.5.3 AF-Charging-Identifier AVP . 30
6.5.4 Flow-Description AVP . 30
6.5.5 Flow-Number AVP . 31
6.5.6 Flows AVP. 31
6.5.7 Flow-Status AVP . 31
6.5.8 Flow-Usage AVP . 31
6.5.9 Specific-Action AVP . 32
6.5.10 Max-Requested-Bandwidth-DL AVP . 32
6.5.11 Max-Requested-Bandwidth-UL AVP . 32
6.5.12 Media-Component-Description AVP . 32
6.5.13 Media-Component-Number AVP . 33
6.5.14 Media-Sub-Component AVP . 33
6.5.15 Media-Type AVP . 33
6.5.16 Reservation-Class AVP . 34
6.5.17 Globally-Unique-Address AVP . 34
6.5.18 Address-Realm AVP. 34
6.5.19 Logical-Access-ID AVP . 34
6.5.20 Session-Bundle-Id AVP . 34
6.5.21 Transport-Class AVP . 34
7 DIAMETER application for Delegated Model . 34
7.1 Use of the Diameter base protocol . 34
7.1.1 Securing Diameter messages . 34
7.1.2 Accounting functionality . 35
7.1.3 Use of sessions . 35
7.1.4 Transport protocol . 35
7.1.5 Routing considerations . 35
7.1.6 Advertising application support . 35
7.2 Commands . 36
7.2.1 User-Data-Request command . 36
7.2.2 User-Data-Answer command. 36
7.2.3 Push-Notification-Request command . 37
7.2.4 Push-Notification-Answer command . 37
7.2.5 Re-Auth-Request (RAR) Command . 38
7.2.6 Re-Auth-Answer (RAA) command . 38
7.2.7 CC-Request (CCR) command. 38
7.2.8 CC-Answer (CCA) Command . 39
7.3 Experimental-Result-Code AVP values . 39
7.3.1 Experimental-Result-Code AVP values imported from ES 283 034 . 39
7.3.2 Experimental-Result-Code AVP values defined in the present document . 39
7.4 Use of namespaces . 39
7.4.1 AVP codes . 40
7.4.2 Experimental-Result-Code AVP values . 40
7.4.3 Command Code values . 40
ETSI
5 ETSI TS 183 071 V3.1.1 (2010-02)
7.4.4 Application-ID value . 40
7.5 AVPs . 40
7.5.1 Network-Resource-Id AVP . 41
7.5.2 Preferred-Delegated-Bandwidth-UL AVP . 42
7.5.3 Preferred-Delegated-Bandwidth-DL AVP . 42
7.5.4 Required-Delegated-Bandwidth-UL AVP . 42
7.5.5 Required-Delegated-Bandwidth-DL AVP . 42
7.5.6 Granted-Delegated-Bandwidth-UL AVP . 42
7.5.7 Granted-Delegated-Bandwidth-DL AVP . 42
7.5.8 Total-Bandwidth-UL AVP . 42
7.5.9 Total-Bandwidth-DL AVP . 42
7.5.10 Reservation-priority AVP . 42
7.5.11 Authorization-Package-Id AVP . 43
7.5.12 Abort-Cause AVP . 43
7.5.13 Flow-Description AVP . 43
7.5.14 Specific-Action AVP . 44
7.5.15 Globally-Unique-Address AVP . 44
7.5.16 Address-Realm AVP. 44
7.5.17 Logical-Access-ID AVP . 44
7.5.18 Framed-IP-Address AVP . 44
7.5.19 Framed-IPv6-Prefix AVP . 45
History . 46
ETSI
6 ETSI TS 183 071 V3.1.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
7 ETSI TS 183 071 V3.1.1 (2010-02)
1 Scope
The present document defines a specification applicable to the Rr interface between Generic Resource Admission
Control Function (x-RACF) instances, based on the Diameter protocol. Other alternative protocols which may also be
used for this interface such as ANCP are not specified in the present document.
Whenever it is possible the present document specifies the requirements for this protocol by reference to specifications
produced by the IETF within the scope of Diameter. Where this is not possible, extensions to Diameter are defined
within the present document.
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 (V3.y.z): "Telecommunications and Internet converged Services and Protocols
for Advanced Networking (TISPAN); NGN Functional Architecture".
[2] ETSI ES 282 003 (V3.y.z): "Telecommunications and Internet converged Services and Protocols
for Advanced Networking (TISPAN); Resource and Admission Control Sub-System (RACS):
Functional Architecture".
[3] ETSI ES 282 004 (V3.y.z): "Telecommunications and Internet converged Services and Protocols
for Advanced Networking (TISPAN); NGN Functional Architecture; Network Attachment Sub-
System (NASS)".
[4] ETSI ES 283 034 (V2.y.z): "Telecommunications and Internet converged Services and Protocols
for Advanced Networking (TISPAN); Network Attachment Sub-System (NASS); e4 interface
based on the DIAMETER protocol".
[5] ETSI TS 183 017 (V3.y.z): "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".
[6] IETF RFC 4006: "Diameter Credit-Control Application".
ETSI
8 ETSI TS 183 071 V3.1.1 (2010-02)
[7] ETSI TS 129 209: "Universal Mobile Telecommunications System (UMTS); Policy control over
Gq interface (3GPP TS 29.209)".
[8] IETF RFC 3588: "Diameter Base Protocol".
[9] IETF RFC 4005: "Diameter Network Access Server Application".
[10] ETSI TS 183 026 (V3.y.z): "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".
[11] ETSI TS 133 210: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); LTE; 3G security; Network Domain Security (NDS); IP
network layer security (3GPP TS 33.210 )".
[12] IETF RFC 4960: "Stream Control Transmission Protocol".
[13] ETSI TS 129 207: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Policy control over Go interface (3GPP TS 29.207)".
[14] IETF RFC 3554: "On the Use of Stream Control Transmission Protocol (SCTP) with IPSec".
[15] ETSI TS 129 329: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); LTE; Sh interface based on the Diameter protocol; Protocol
details (3GPP TS 29.329)".
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.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
delegated x-RACF: x-RACF instance which works in the Rr delegated Model and performs admission control for the
resources delegated by the delegating x-RACF
delegating x-RACF: x-RACF instance which works in the Rr delegated Model and delegates a bulk of resources to
another x-RACF instance for admission control
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AAA AA-Answer
AAR AA-Request
ABNF Augmented Backus–Naur Form
AF Application Function
ANCP Access Node Control Protocol
ASA Abort-Session-Answer
ASR Abort-Session-Request
ETSI
9 ETSI TS 183 071 V3.1.1 (2010-02)
ATM Asynchronous Transfer Mode
AVP Attribute-Value Pair
CCA CC-Answer
CCR CC-Request
CEA Capabilities-Exchange-Answer
CER Capabilities-Exchange-Request
DHCP Dynamic Host Configuration Protocol
FQDN Fully Qualified Domain Name
IANA Internet Assigned Numbers Authority
ID IDentifier
IETF Internet Engineering Task Force
IP Internet Protocol
IPSec IP Security
NASREQ Network Access Server Application
NASS Network Attachment Sub-System
PNA Push-Notification-Answer
PNR Push-Notification-Request
QoS Quality of Service
RAA Re-Auth-Answer
RACS Resource and Admission Control Sub-System
RAR Re-Auth-Request
RCEF Resource Control Enforcement Function
RFC Request For Comments
Rr reference point Rr
RTCP Realtime Transport Control Protocol
SCTP Stream Control Transport Protocol
SDI Session Description Information
SPDF Service-based Policy Decision Function
STA Session-Termination-Answer
STR Session-Termination-Request
TISPAN Telecommunications and Internet converged Services and Protocols for Advanced Networking
UDA User-Data-Answer
UDR User-Data-Request
UE User Equipment
VC Virtual Channel
VP Virtual Path
x-RACF Generic Resource Admission Control Function
ETSI
10 ETSI TS 183 071 V3.1.1 (2010-02)
4 Overview
The present document specifies the Diameter protocol for the RACS Rr interface. The Rr interface is used for QoS
resource reservation between x-RACF instances of RACS within a single administrative domain. The functional
requirements and the stage 2 specifications of the Rr interface are contained in ES 282 001 [1] and ES 282 003 [2].
AFAF
GqGq ’’
RfRf
RACSRACS
RdRd’’, , RiRi ’’
e4e4
NANASSSS
RqRq
SPDFSPDF
RrRr
xx -- RARACFCF
ReRe IIaa
RCEFRCEF BGBGFF
BTBTFF
TrTrananspspoorrtt PProrocesscessiinngg FuFunnccttiiononss
Figure 4.1: Rr interface
5 Procedure descriptions
5.1 General
5.1.1 Information elements
The following clauses describe the realization of the functional procedures defined in the RACS (ES 282 003 [2]) using
Diameter commands described in clauses 6 and 7. This involves describing a mapping between the Information
Elements defined in the RACS specification (ES 282 003 [2]) and Diameter AVPs.
In the tables that describe this mapping, each Information Element is marked as (M) Mandatory, (C) Conditional or (O)
Optional:
• A mandatory Information Element (marked as (M) in the table) shall always be present in the command. If this
Information Element is absent, an application error occurs at the receiver and an answer message shall be sent
back to the originator of the request with the Result-Code set to DIAMETER_MISSING_AVP. This message
shall also include a Failed-AVP AVP containing the missing Information Element i.e. the corresponding
Diameter AVP defined by the AVP Code and the other fields set as expected for this Information Element.
• A conditional Information Element (marked as (C) in the table) shall be present in the command if certain
conditions are fulfilled:
- If the receiver detects that those conditions are fulfilled and the Information Element is absent, an
application error occurs and an answer message shall be sent back to the originator of the request with
the Result-Code set to DIAMETER_MISSING_AVP. This message shall also include a Failed-AVP
AVP containing the missing Information Element i.e. the corresponding Diameter AVP defined by the
AVP Code and the other fields set as expected for this Information Element. If multiple Information
Elements are missing, all corresponding AVP codes shall be included in the Failed-AVP AVP.
ETSI
11 ETSI TS 183 071 V3.1.1 (2010-02)
- If those conditions are not fulfilled, the Information Element shall be absent. If however this Information
Element appears in the message, it shall not cause an application error and it may be ignored by the
receiver if this is not explicitly defined as an error case. Otherwise, an application error occurs at the
receiver and an answer message with the Result-Code set to DIAMETER_AVP_NOT_ALLOWED shall
be sent back to the originator of the request. A Failed-AVP AVP containing a copy of the corresponding
Diameter AVP shall be included in this message.
• An optional Information Element (marked as (O) in the table) may be present or absent in the command, at the
discretion of the application at the sending entity. Absence or presence of this Information Element shall not
cause an application error and may be ignored by the receiver.
5.2 Procedures on the Rr interface
5.2.1 Resource control procedures for Request Model
The resource control process supports the following operations:
1) Resource Reservation: the resources are admitted by the requested entity (e.g. lower-tier x-RACF). In relation
to the enforcement operations performed in the co-located RCEF, it can be divided into the following
categories:
- Reservation only: the resources are reserved but not allocated.
- Commit only: the pre-reserved resources are allocated.
- Reservation and commit: the resources are reserved and allocated.
2) Resource Modification: the pre-reserved/committed resources are updated upon the request of the originating
entity (e.g. top-tier x-RACF).
3) Resource Release: the pre-reserved/committed resources are terminated upon the request of the originating
entity.
4) Event notification: a specific action is requested when a pre-defined event occurs (e.g. reservation expiration).
The Flow-Status AVP is used to define the action to be taken for each AA-Request made by the top-tier x-RACF to the
lower-tier x-RACF. The rules for interpreting the Flow-Status AVP are the following:
• Resource Reservation: can be invoked by any of the following status:
- Reservation only: New Media-Description-Component AVP(s) and optionally Media-Sub-Component
AVP(s) with Flow-Status AVP(s) set to DISABLED (3).
- Commit only: Media-Description-Component AVP(s) and optionally Media-Sub-Component AVP(s) of
existing reservations with Flow-Status AVP(s) set to ENABLED-UPLINK (0),
ENABLED-DOWNLINK (1) or ENABLED (2).
- ReservationAndCommit: New Media-Component-Description AVP(s) and optionally
Media-Sub-Component AVP(s). Flow-Status AVP(s) set to ENABLED-UPLINK (0),
ENABLED-DOWNLINK (1) or ENABLED (2).
NOTE: For the purpose of the resource admission and reservation, any of above status triggers the procedure. The
distinction of above flow status is only meaningful in the case the lower-tier x-RACF needs to control the
enforcement operations (e.g. Opening the gate) in the co-located RCEF.
• Resource Modification: Updated Media-Description-Component AVP(s) and Media-Sub-Component AVP(s).
Flow-Status AVP not modified, unless the state needs to be modified (e.g. for committing a resource
reservation, or for releasing a resource reservation).
• Resource Release: Media-Description-Component AVP(s) and optionally Media-Sub-Component AVP(s) of
existing reservations with Flow-Status AVP(s) set to REMOVED (4).
ETSI
12 ETSI TS 183 071 V3.1.1 (2010-02)
These resource control operations are described in the following clauses. During the operations Diameter AVPs are
passed between the top-tier x-RACF and the lower-tier x-RACF.
5.2.1.1 Procedures at the Top-tier x-RACF
5.2.1.1.1 Resource Reservation Session Establishment and Initial Resource Reservation
Upon the receipt of a new request from the SPDF, the top-tier x-RACF sends an initial request to the lower-tier x-RACF
for initiating a resource reservation session. The AA-Request issued to request an initial reservation contains a new
Session-Id assigned by the top-tier x-RACF. As specified in RFC 3588 [8], the Session-Id is globally unique and is
meant to uniquely identify a resource session without reference to any other information. The Session-Id begins with
the sender's identity encoded in the DiameterIdentity type.
This AA-Request message contains one or more Media-Component-Description Attribute-Value Pair(s) (AVP(s)). Each
Media-Component-Description AVP describes the set of flows of a particular media type (i.e. it may contain one or
more Media-Sub-Component AVP(s) and requirements for the flows).
The top-tier x-RACF may forward an AF-Charging-Identifier AVP from the SPDF in the message for charging
correlation purposes between AF and RACS.
The resource admission and reservation operation that shall be performed by the lower-tier x-RACF for each individual
media and flow is triggered by the following value of the Flow-Status AVP, as indicated in table 5.1:
• Reservation; the value of the Flow-Status AVP shall be set to DISABLED (3).
• ReservationAndCommit; the value of the Flow-Status AVP shall be set to ENABLED-UPLINK (0),
ENABLED-DOWNLINK (1) or ENABLED (2).
• The Flow-Status AVP shall be specified in the Media-Component-Description AVP and in the
Media-Sub-Component AVP(s). The Flow-Status AVP shall be set to the same value in both these AVPs.
Table 5.1: Initial Reservation operations
Message Flow-Status AVP at the level of
Meaning
Type
Media Sub-Media
AAR New Media, New flow, Reserve Resources for all the flows in the request. The media(s)
DISABLED DISABLED and flow(s) descriptions MUST be new ones.
AAR [New Media, New flow, Reserve Resources. In addition, instruct the co-located RCEF to
ENABLE*] ENABLE* commit resources for some of the flows. The media(s) and
flow(s) descriptions MUST be new ones (see note).
NOTE: The control of committing resources in the co-located RCEF is an implementation choice and out of
scope in the present document.
As specified in clause 8.9 of RFC 3588 [8], the top-tier x-RACF may specify the Authorization-Lifetime AVP in the
AA-Request to request a maximum lifetime for a session. To request a hard-state session the top-tier x-RACF shall omit
the Authorization-Lifetime AVP in the AA-Request. To request a soft-state session the top-tier x-RACF shall specify
this AVP in the AA-Request.
The AA-Answer may contain the Authorization-Lifetime AVP. The AA-Answer may contain the Auth-Grace-Period
AVP in addition to the Authorization-Lifetime AVP. The Authorization-Lifetime AVP specifies the maximum number
of seconds before the Session must be refreshed by the top-tier x-RACF. The Auth-Grace-Period AVP contains the
number of seconds the lower-tier x-RACF will wait for a Refresh following the expiration of the Authorization-
Lifetime AVP.
Whether the Authorization-Lifetime AVP and Auth-Grace-Period need to be included in the AA-Answer is a local
decision of the lower-tier x-RACF. This means that the top-tier x-RACF may be offered a soft-state reservation
although it asked for hard-state or a hard-state reservation although it asked for soft-state. Should the top-tier x-RACF
not accept what is offered by the lower-tier x-RACF it must explicitly release the resources through issuing another
AAR command.
The top-tier x-RACF may specify, in the Specific-Action AVP of the AA-Request through which the initial reservation
request is made, the events of which it wants to be informed. The supported events are listed in clause 6.5.9.
ETSI
13 ETSI TS 183 071 V3.1.1 (2010-02)
The behaviour when the top-tier x-RACF does not receive an 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.
5.2.1.1.2 Resource Modification and Release for Media Flows
The top-tier x-RACF may modify an existing session by sending an AA-Request to the lower-tier x-RACF with zero or
more updated Media-Component-Description AVP(s) and optional Media-Sub-Component AVP(s). The Session-Id
shall be an existing one and refer to the session that is to be modified. The top-tier x-RACF may perform the following
operations:
• Add a new flow within a media component by providing a new Media-Sub-Component AVP within the
corresponding Media-Component-Description AVP.
• Add a new flow within a new media component by providing a new Media-Component-Description AVP.
• Modify a media component by updating the corresponding Media-Component-Description AVP (e.g. increase
or decrease the allocated bandwidth).
• Modify a flow within a media component by updating the corresponding Media-Sub-Component AVP.
• Modify a media flow state from Reserved to Committed by providing a Flow-Status AVP of the corresponding
Media-Component-Description AVP and/or Media-Sub-Component AVP(s). The Flow-Status AVP shall be
set to one of the values ENABLED-UPLINK, ENABLED-DOWNLINK or ENABLED, according to the
direction in which the resources are to be committed. This operation requires that the media and flows are in
the Reserved state prior to the AA-Request.
• Release a media component by providing the corresponding Media-Component-Description AVP with the
Flow-Status AVP set to the value REMOVED.
• Release a flow within a media by providing the corresponding Media-Sub-Component AVP with the
Flow-Status AVP set to the value REMOVED.
• Refresh a soft-state session by providing an AA-Request message containing the Session-Id of the session that
is to be refreshed. The AA-Request may contain the Authorization-Lifetime AVP to request a maximum
lifetime of the refreshed session. If this AVP is not included, the refresh message requests the lifetime to be
extended by a default value. The AA-Request may contain Media-Component-Description AVP(s) and
Media-Sub-Component AVP(s) (e.g. to modify media, flows and/or commit status).
The Flow-Status AVP in the Media-Sub-Component AVP shall always be the same as the Flow-Status AVP in the
Media-Component-Description AVP containing the Media-Sub-Component AVP.
The top-tier x-RACF SHALL NOT use the RAA to modify the session service information. As an option, the top-tier
x-RACF MAY send an AAR command following an RAA to update the session service information after the local
RACF responds with the RAR.
ETSI
14 ETSI TS 183 071 V3.1.1 (2010-02)
Table 5.2: Modification operations
Flow-Status AVP at the level of
Message Type Meaning
Media Sub-Media
AAR Existing Media Existing Flow, Unchanged Modify a media. In addition, modify a flow
Flow-Status according to the new parameters specified in
the Media-Sub-Component AVP. The Media
and Flow must exist (see notes 1, 2 and 5).
AAR Existing Media New flow. Same Flow-Status Modify a media. In addition, add a new flow
AVP as in the media. in a media. The Flow must be new (see
(see note 3) notes 3 and 5).
AAR Existing
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...