Diameter Quality-of-Service Application
Extracted elements (30)
Push and Pull modes are required because Category 1 and 2 endpoints cannot initiate network-level QoS signaling (they lack network-layer QoS capability), so the Authorizing Entity must proactively push authorization state to the NE; Pull mode is only applicable where the endpoint can send network QoS signaling (Category 3).
The Authorizing Entity may determine Push or Pull mode statically (via configured policy) or dynamically (based on information received from an application server such as IP addresses of media flows), allowing flexible deployment.
The NE-to-AAA interface is designed to be identical regardless of whether an Application Server is involved, insulating routers from application-specific details and enabling flexible intra- and inter-domain authorization and settlement through the AAA cloud.
The token-based three-party scheme is used in environments where a prior application-layer interaction (e.g., SIP) has already produced an authorization token; this token binds the application-layer authorization to the QoS signaling session and must contain an AE identifier, application session identifier, and a keyed message digest or digital signature.
Diameter QoS application nodes MAY advertise support by including Application-Id 9 in the Auth-Application-Id or Acct-Application-Id of CER/CEA; the value 0 (relay) SHOULD be used for base protocol commands STR/STA, ASR/ASA, and RAR/RAA within QoS sessions.
For Category 1 and Category 2 Application Endpoints, Push mode is REQUIRED. For a Category 3 AppE, either Push mode or Pull mode MAY be used.
If an RAR command is received by the NE without any parameters of the re-authorized QoS state, the NE MUST initiate a QoS re-authorization by sending a QoS-Authorization-Request (QAR) message towards the AE.
If the Diameter QoS application protocol interaction cannot be related to a prior authentication, the AE MUST authenticate the QoS reservation requesting entity as part of the Diameter QoS protocol interaction in order to authorize the QoS request.
It MUST be possible for the Diameter QoS application to push updates towards the NE(s) from Authorizing Entities (dynamic authorization).
The Diameter QoS application MUST allow the AE to gate (enable/disable) authorized application flows based on application state transitions (bearer gating).
The Diameter QoS application MUST allow the NE to report failures, such as loss of connectivity due to mobile node movement or other reasons for packet loss, to the Authorizing Entity.
The Diameter QoS application MUST exchange sufficient information between the AE and the enforcing entity to compute an authorization decision and execute it.
The Diameter QoS application MUST route AAA requests to the Authorizing Entity based on the identity of the QoS requesting entity or the identity of the AE encoded in the provided authorization token.
The Diameter QoS application MUST support a variety of different authentication protocols for verification of authentication information present in QoS signaling messages; support MAY be provided indirectly by tying signaling to a previous authentication exchange.
The QAR message MUST carry information for signaling session identification, AE identification, information about the requested QoS, and the identity of the QoS requesting entity; an authorization token and credentials SHOULD be included depending on deployment scenario.
The QIR message MUST carry information for signaling-session identification or flow identification, identity of the transport plane element, description of QoS parameters, flow state, and duration of authorization.
The supplemented Push mode states in Section 6.1 MUST be supported in any QoS application implementation that supports server-initiated Push mode.
The value of Application-Id 9 MUST be used in all QAR/QAA and QIR/QIA commands; the value zero (0) SHOULD be used as the Application-Id in all STR/STA, ASR/ASA, and RAR/RAA commands.
Bound-Auth-Session-Id AVP (AVP Code 580, type UTF8String, M bit mandatory, V bit must not be set): binds a QoS Diameter session to another existing Diameter authorization session.
QoS-Authorization-Answer (QAA): Command Code 326 with R bit cleared, sent in response to QAR; carries Result-Code, optional QoS-Resources, Session-Timeout, Authorization-Session-Lifetime, and Authorization-Grace-Period.
QoS-Authorization-Data AVP (AVP Code 579, type OctetString, M bit mandatory, V bit must not be set): carries authorization token credentials of the QoS requesting entity.
QoS-Authorization-Request (QAR): Command Code 326 with R bit set, sent by NEs to request QoS resource authorization; carries Session-Id, Auth-Application-Id, Origin-Host/Realm, Destination-Realm, Auth-Request-Type, optional QoS-Resources and QoS-Authorization-Data.
QoS-Install-Answer (QIA): Command Code 327 with R bit cleared, sent by NE in response to QIR to confirm the result of QoS reservation installation; carries Result-Code and optionally QoS-Resources.
QoS-Install-Request (QIR): Command Code 327 with R bit set, sent by the AE to install or update QoS parameters and flow state at the transport plane NE; carries QoS-Resources, authorization lifetime, and volume information.
Application ID value 9 is assigned to the Diameter QoS application; this value is used in the Auth-Application-Id or Acct-Application-Id AVPs during capability exchange and in all QAR/QAA/QIR/QIA commands.
Two new Diameter AVP codes are registered: QoS-Authorization-Data (579, OctetString) and Bound-Auth-Session-Id (580, UTF8String), both with the M bit set.
Two new Diameter Command Codes are registered: 326 for QoS-Authorization-Request/Answer (QAR/QAA) and 327 for QoS-Install-Request/Answer (QIR/QIA).
The Diameter QoS application relies on the Diameter base protocol's security mechanisms; when the QoS authorization cannot be tied to a prior authentication exchange, the Authorizing Entity MUST authenticate the QoS reservation requesting entity directly as part of the Diameter QoS protocol interaction to prevent unauthorized QoS resource allocation.
Client stateful Push mode state machine: Idle→Open (QIR initial request successfully processed, send QIA and reserve resources); Idle→Idle (QIR initial request not successfully processed, send QIA with Result-Code != SUCCESS).
Server stateful Push mode state machine: Idle→Pending (send initial QIR on application/local trigger); Pending→Idle (QIA with failed Result-Code); Pending→Open (QIA with SUCCESS); Pending→Discon (error processing QIA with SUCCESS, send ASR).