Diameter Group Signaling

In large network deployments, a single Diameter peer can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter peers to apply the same operation to a large group of Diameter sessions concurrently. For example, a policy decision point may need to modify the authorized quality of service for all active users having the same type of subscription. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges in order to enforce the same operation on each session in the group. In order to reduce signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter peer using a single or a few command exchanges. This document describes a mechanism for grouping Diameter sessions and performing re-authentication, re-authorization, termination and abortion of groups of sessions. This document does not define a new Diameter application. Instead it defines mechanisms, commands and AVPs that may be used by any Diameter application that requires management of groups of sessions.

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 . This document uses terminology defined .

Either Diameter peer may assign a session to a group. Diameter AAA applications typically assign client and server roles to the Diameter peers. In this document, a Diameter client is a node at the edge of the network that performs access control. A Diameter server is a node that performs authentication and/or authorization of the user.

To assign a session to a group at session initiation, a Diameter client sends a service specific auth request, e.g. NASREQ AAR , containing one or more client-assigned group identifiers. Assuming the user is successfully authenticated and/or authorized, the Diameter server responds with service-specific auth response, e.g. NASREQ AAA , containing both the client-assigned group identifiers and the server-assigned group identifiers.

Either Diameter peer may modify the group membership of an active Diameter session. A Diameter client MAY remove the group(s) assigned to the active session by the Diameter server and vice versa. Editor's Note: It is FFS whether this document should define a default permission model limiting removal of a session from a group. For example, the server MUST NOT remove a session from a group assigned by the client.

To update the assigned groups mid-session, a Diameter client sends a service specific re-authorization request containing the updated list of group identifiers. Assuming the user is successfully authenticated and/or authorized, the Diameter server responds with a service-specific auth response containing the updated list of group identifiers received in the request.

To update the assigned groups mid-session, a Diameter server sends a Re-authorization Request (RAR) message requesting re-authorization and the client responds with a Re-authorization Answer (RAA) message. The Diameter client sends a service specific re-authorization request containing the current list of group identifiers and the Diameter server responds with a service-specific auth response containing the updated list of group identifiers.

Section 8.1 in defines a set of finite state machines, representing the life cycle of Diameter sessions, and which MUST be observed by all Diameter implementations that make use of the authentication and/or authorization portion of a Diameter application. This section defines the additional state transitions related to the processing of the new commands which may impact multiple sessions. The group membership is session state and therefore only those state machines from in which the server is maintaining session state are relevant in this document. As in , the term Service-Specific below refers to a message defined in a Diameter application (e.g., Mobile IPv4, NASREQ). The following state machine is observed by a client when state is maintained on the server. State transitions which are unmodified from are not repeated here.

The following state machine is observed by a server when it is maintaining state for the session. State transitions which are unmodified from are not repeated here.

TODO: rules/restrictions governing group re-auth

TODO: rules/restrictions governing session group termination

TODO: rules/restrictions governing aborting groups of session

This specification extends the existing RAR, RAA, STR, STA, ASR and ASA command ABNFs.

The Group-Re-Auth-Request (GRAR), indicated by the Command-Code set to TBD and the message flags' 'R' bit set, may be sent by any server to the access device that is providing session service, to request that one or more groups of users be re-authenticated and/or re-authorized.

::= < Diameter Header: TBD, REQ, PXY > * { Session-Group-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { Auth-Application-Id } { Re-Auth-Request-Type } [ User-Name ] [ Origin-State-Id ] * [ Proxy-Info ] * [ Route-Record ] [ Session-Group-Action ] * [ AVP ] ]]>

The Group-Re-Auth-Answer (GRAA), indicated by the Command-Code set to TBD and the message flags' 'R' bit clear, is sent in response to the GRAR. The Result-Code AVP MUST be present, and indicates the disposition of the request. [Editor's Note: Move these detailed behaviour requirements to earlier section?] A successful GRAA message MUST be followed by an application-specific authentication and/or authorization message. The Group-Action AVP in the Group-Re-Auth-Request indicates whether a single exchange, per-group or per-session is required. If the peer receiving the GRAR has no active sessions which are assigned to the groups listed in the Session-Group-Id AVPs, it MUST return a GRAA with the Result-Code set to TBD. The Session-Group-Id AVPs in the GRAA indicate the groups for which the GRAR receiver has active sessions assigned to those groups.

::= < Diameter Header: TBD, PXY > * { Session-Group-Id } { Result-Code } { Origin-Host } { Origin-Realm } [ User-Name ] [ Origin-State-Id ] [ Error-Message ] [ Error-Reporting-Host ] * [ Failed-AVP ] * [ Redirect-Host ] [ Redirect-Host-Usage ] [ Redirect-Host-Cache-Time ] * [ Proxy-Info ] * [ AVP ] ]]>

The Group-Session-Termination-Request (GSTR), indicated by the Command-Code set to TBD and the Command Flags' 'R' bit set, is sent by the access device to inform the Diameter Server that one or more groups of authenticated and/or authorized sessions are being terminated.

::= < Diameter Header: TBD, REQ, PXY > * { Session-Group-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Application-Id } { Termination-Cause } [ User-Name ] [ Destination-Host ] * [ Class ] [ Origin-State-Id ] * [ Proxy-Info ] * [ Route-Record ] * [ AVP ] ]]>

The Group-Session-Termination-Answer (GSTA), indicated by the Command-Code set to TBD and the message flags' 'R' bit clear, is sent by the Diameter Server to acknowledge the notification that one or more groups of session have been terminated. The Result-Code AVP MUST be present, and MAY contain an indication that an error occurred while servicing the GSTR. Upon sending or receipt of the GSTA, the Diameter Server MUST release all resources for all sessions belonging to the groups indicated by the Session-Group-Id AVP. Any intermediate server in the Proxy-Chain MAY also release any resources, if necessary.

::= < Diameter Header: TBD, PXY > * { Session-Group-Id } { Result-Code } { Origin-Host } { Origin-Realm } [ User-Name ] * [ Class ] [ Error-Message ] [ Error-Reporting-Host ] * [ Failed-AVP ] [ Origin-State-Id ] * [ Redirect-Host ] [ Redirect-Host-Usage ] [ Redirect-Max-Cache-Time ] * [ Proxy-Info ] * [ AVP ] ]]>

The Group-Abort-Session-Request (GASR), indicated by the Command-Code set to TBD and the message flags' 'R' bit set, may be sent by any server to the access device that is providing session service, to request that the sessions identified by the Session-Group-Id be stopped.

::= < Diameter Header: TBD, REQ, PXY > * { Session-Group-Id } { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { Auth-Application-Id } [ User-Name ] [ Origin-State-Id ] * [ Proxy-Info ] * [ Route-Record ] [ Group-Action ] * [ AVP ] ]]>

The Group-Abort-Session-Answer (GASA), indicated by the Command-Code set to TBD and the message flags' 'R' bit clear, is sent in response to the GASR. The Result-Code AVP MUST be present, and indicates the disposition of the request. If the sessions identified by Session-Group-Id in the GASR were successfully terminated, Result-Code is set to DIAMETER_SUCCESS. If the session is not currently active, Result-Code is set to DIAMETER_UNKNOWN_SESSION_ID. If the access device does not stop the session for any other reason, Result-Code is set to DIAMETER_UNABLE_TO_COMPLY. [Editor's Note: Move these detailed behaviour requirements to earlier section.] A successful GASA message MUST be followed by one or more STR or GSTR to the authorizing server. The Group-Action AVP in the Group-Abort-Session-Request indicates whether a GSTR per group of sessions, a GSTR per group or an STR per session is required. If the peer receiving the GASR has no active sessions which are assigned the groups listed in the Session-Group-Id AVPs, it MUST return a GASA with the Result-Code set to TBD. The Session-Group-Id AVPs in the GASA indicate the groups for which the GASR receiver has active sessions assigned to those groups.

The Session-Group-Action AVP (AVP Code TBD) is of type Enumerated and specifies how the peer SHOULD issue follow up exchanges in response to a command which impacts mulitple sessions. The following values are supported: Follow up exchanges should be performed with a single message exchange for all impacted groups. Follow up exchanges should be performed with a message exchange for each impacted group. Follow up exchanges should be performed with a message exchange for each impacted session.

This section defines new Result-Code values that MUST be supported by all Diameter implementations that conform to this specification. [Editor's Note: Group specific error values may need to be added here.]

This section contains the namespaces that have either been created in this specification or had their values assigned to existing namespaces managed by IANA.

This specification requires IANA to register the following new Commands from the Command Code namespace defined in . Group-Re-Auth-Request/Answer Group-Session-Termination-Request/Answer Group-Abort-Session-Request/Answer The commands are defined in .

This specification requires IANA to register the following new AVPs from the AVP Code namespace defined in . Session-Group-Id Session-Group-Action The AVPs are defined in .

TODO