Diameter Group Signaling
Extracted elements (29)
Diameter nodes in large deployments can support over a million concurrent sessions. Rather than sending thousands of individual command exchanges to apply the same operation to each session, this specification enables bulk operations on session groups using a single or few command exchanges, dramatically reducing signaling overhead.
This document does not define new Diameter commands. Instead, it extends existing Command Code Formats (CCFs) with optional AVPs, preserving minimal impact to existing applications and enabling fallback to single-session operation when the peer does not support grouping.
If a Diameter node does not support session grouping, it can fall back to single-session operation by ignoring the optional group AVPs and processing the command solely for the session identified in the mandatory Session-Id AVP. The response MUST NOT include any group identifier.
Stateless Proxy Agents do not maintain session state, so session groups are transparent to them. Session-group-related AVPs are optional and should not be removed by stateless proxies; if they are removed, the client and server will detect the absence and fall back to single-session processing.
A stateful Proxy Agent MUST perform the same mechanisms as this specification to advertise session grouping capabilities toward both client and server, and MUST update and maintain consistency of its local session states based on the results of group commands.
Any Diameter node that has advertised support for session grouping and group operations MUST store and maintain the group assignment as part of each session's state, and MUST keep a record of sessions it has assigned to a session group.
Diameter nodes SHOULD NOT perform group operations with peer nodes unless the peer has advertised support for session grouping and group operations.
If a Diameter client sends a session initiation request with Session-Group-Info AVPs but the server response contains no Session-Group-Info AVP, the client MUST proceed as if the request was processed without group assignments and MUST NOT retry group assignment for this session.
If the Diameter client fails to add a session to one or more session groups as identified in Session-Group-Info AVPs received from the server, the client MUST terminate the session.
If the Diameter server accepts a client's group assignment request, the server MUST assign the new session to each identified group, MUST store any newly identified groups locally, and MUST include all received Session-Group-Info AVPs in its response.
When a group command partially succeeds, the Result-Code AVP SHOULD indicate DIAMETER_LIMITED_SUCCESS, and sessions for which the command failed MUST be identified by including their Session-Id in the Failed-AVP. The sender MUST fall back to single-session operation for those sessions and MUST remove them from all applicable session groups.
When a group command request identifies multiple groups and a session has been assigned to more than one of those groups, the receiver MUST process the associated command only once per session to avoid duplicate operations.
When a group command results in an error applying to all sessions in the identified groups, an associated protocol error MUST be returned, the sender MUST fall back to single-session processing, and the identified session groups MUST be deleted.
When a node receives at least one Session-Group-Capability-Vector AVP with the BASE_SESSION_GROUP_CAPABILITY flag set, it MUST cache this capability information for the lifetime of the routing table entry associated with the peer identity / Application Id pair.
When no external capability discovery mechanism is deployed, a Diameter node SHOULD append the Session-Group-Capability-Vector AVP to application messages to announce its grouping capability, and MUST set the BASE_SESSION_GROUP_CAPABILITY flag within that AVP.
A session can only be removed from a session group by the Diameter node (client or server) that originally assigned the session to that group. A session group can only be deleted by its owner. Diameter applications with implicit group support MAY define a more constrained permission model.
A session group is a named set of Diameter sessions to which commands can be applied in bulk. Sessions can belong to multiple groups simultaneously, and group membership is a session state that must be maintained by each Diameter node. Either the client or server may create, modify, or delete groups subject to ownership and permission rules.
A session group is explicitly deleted by appending a Session-Group-Info AVP with SESSION_GROUP_STATUS cleared and SESSION_GROUP_ALLOCATION_ACTION cleared, identifying the group to be deleted. A session group is also implicitly deleted when its last session is removed.
The Session-Group-Info AVP (AVP Code 671) is of type Grouped and contains a Session-Group-Control-Vector AVP and an optional Session-Group-Id AVP. It carries the group identifier and the action to be performed for the associated session or group.
IANA created two new registries: 'Session-Group-Control-Vector AVP Values (code 672)' with Specification Required assignment policy, seeded with SESSION_GROUP_ALLOCATION_ACTION and SESSION_GROUP_STATUS; and 'Session-Group-Capability-Vector AVP Values (code 675)' with Standards Action policy, seeded with BASE_SESSION_GROUP_CAPABILITY.
IANA registered five new AVP codes in the Diameter 'AVP Codes' registry: Session-Group-Info (671), Session-Group-Control-Vector (672), Session-Group-Id (673), Group-Response-Action (674), and Session-Group-Capability-Vector (675).
Group commands amplify the blast radius of a compromised Diameter node: an attacker controlling a client or server could launch denial-of-service attacks by terminating or modifying a large number of sessions using only a few group commands, versus many individual session commands in the base protocol.
The Session-Group-Info AVP (including Session-Group-Control-Vector and Session-Group-Id) must be treated as security-sensitive in the same manner as the Session-Id AVP. The absence of end-to-end security in Diameter means any intermediate agent can modify group-related information; trust in non-adjacent nodes cannot be assured without end-to-end security mechanisms.
The client stateful authorization state machine adds group-aware transitions: in Open state, receiving a GRAR triggers sending GRAA and a service-specific group re-auth request (entering Pending); receiving a GASR triggers GASA and GSTR (entering Discon); in Discon, receiving GSTA moves to Idle. The action taken on GRAR/GASR depends on the Group-Response-Action value (ALL_GROUPS, PER_GROUP, or PER_SESSION).
The server stateful authorization state machine adds group-aware transitions: in Open state, the server sends GASR to terminate groups (entering Discon) or sends GRAR to re-authenticate groups (entering Pending); GASA received in Discon triggers cleanup to Idle; any GSTR received causes GSTA and cleanup to Idle; successful GRAA in Pending updates sessions and returns to Open.
The Group-Response-Action AVP (AVP Code 674) is of type Unsigned32 and instructs the receiver how to issue follow-up exchanges: ALL_GROUPS (1) means a single message for all groups, PER_GROUP (2) means one message per group, and PER_SESSION (3) means one message per impacted session.
The Session-Group-Capability-Vector AVP (AVP Code 675) is of type Unsigned32 and contains a 32-bit capability flag field. The single defined flag BASE_SESSION_GROUP_CAPABILITY (0x00000001) indicates support for session grouping and group operations per this specification.
The Session-Group-Control-Vector AVP (AVP Code 672) is of type Unsigned32 and encodes a 32-bit flag field. Two flags are defined: SESSION_GROUP_ALLOCATION_ACTION (0x00000001), indicating assign (set) or remove (cleared), and SESSION_GROUP_STATUS (0x00000010), indicating group active (set) or deleted (cleared).
The Session-Group-Id AVP (AVP Code 673) is of type UTF8String and MUST be globally unique. It MUST begin with the DiameterIdentity of the owning node, followed by a ';' delimiter and an implementation-defined portion, mirroring the Session-Id AVP format from RFC 6733 Section 8.8.