< draft-jones-diameter-group-signaling-00.txt   draft-jones-diameter-group-signaling-01.txt >
DIME M. Jones DIME M. Jones
Internet-Draft Bridgewater Systems Internet-Draft Amdocs
Intended status: Informational October 24, 2011 Intended status: Informational March 7, 2012
Expires: April 26, 2012 Expires: September 8, 2012
Diameter Group Signaling Diameter Group Signaling
draft-jones-diameter-group-signaling-00.txt draft-jones-diameter-group-signaling-01.txt
Abstract Abstract
In large network deployments, a single Diameter peer can support over In large network deployments, a single Diameter peer can support over
a million concurrent Diameter sessions. Recent use cases have a million concurrent Diameter sessions. Recent use cases have
revealed the need for Diameter peers to apply the same operation to a revealed the need for Diameter peers to apply the same operation to a
large group of Diameter sessions concurrently. The Diameter base large group of Diameter sessions concurrently. The Diameter base
protocol commands operate on a single session so these use cases protocol commands operate on a single session so these use cases
could result in many thousands of command exchanges in order to could result in many thousands of command exchanges to enforce the
enforce the same operation on each session in the group. In order to same operation on each session in the group. In order to reduce
reduce signaling, it would be desirable to enable bulk operations on signaling, it would be desirable to enable bulk operations on all (or
all (or part of) the sessions managed by a Diameter peer using a part of) the sessions managed by a Diameter peer using a single or a
single or a few command exchanges. This document specifies the few command exchanges. This document specifies the Diameter protocol
Diameter protocol extensions to achieve this signaling optimization. extensions to achieve this signaling optimization.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 26, 2012. This Internet-Draft will expire on September 8, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Grouping User Sessions . . . . . . . . . . . . . . . . . . . . 5 3. Grouping User Sessions . . . . . . . . . . . . . . . . . . . . 5
3.1. Group assignment at session initiation . . . . . . . . . . 5 3.1. Group assignment at session initiation . . . . . . . . . . 5
3.2. Mid-session group assignment modifications . . . . . . . . 5 3.2. Mid-session group assignment modifications . . . . . . . . 5
3.2.1. Client-initiated group assignment changes . . . . . . 5 3.2.1. Client-initiated group assignment changes . . . . . . 5
3.2.2. Server-initiated group assignment changes . . . . . . 5 3.2.2. Server-initiated group assignment changes . . . . . . 5
4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6 3.3. Server Initiated Group Re-auth . . . . . . . . . . . . . . 6
4.1. Session Management . . . . . . . . . . . . . . . . . . . . 6 3.4. Session Group Termination . . . . . . . . . . . . . . . . 7
4.1.1. Authorization Session State Machine . . . . . . . . . 6 3.5. Aborting a Group of Sessions . . . . . . . . . . . . . . . 8
4.1.2. Server Initiated Group Re-auth . . . . . . . . . . . . 10 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 10
4.1.3. Session Group Termination . . . . . . . . . . . . . . 10 4.1. Session Management . . . . . . . . . . . . . . . . . . . . 10
4.1.4. Aborting a Group of Sessions . . . . . . . . . . . . . 10 4.1.1. Authorization Session State Machine . . . . . . . . . 10
4.2. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1. Group-Re-Auth-Request . . . . . . . . . . . . . . . . 10 4.2.1. Group-Re-Auth-Request . . . . . . . . . . . . . . . . 14
4.2.2. Group-Re-Auth-Answer . . . . . . . . . . . . . . . . . 10 4.2.2. Group-Re-Auth-Answer . . . . . . . . . . . . . . . . . 14
4.2.3. Group-Session-Termination-Request . . . . . . . . . . 11 4.2.3. Group-Session-Termination-Request . . . . . . . . . . 15
4.2.4. Group-Session-Termination-Answer . . . . . . . . . . . 12 4.2.4. Group-Session-Termination-Answer . . . . . . . . . . . 15
4.2.5. Group-Abort-Session-Request . . . . . . . . . . . . . 13 4.2.5. Group-Abort-Session-Request . . . . . . . . . . . . . 16
4.2.6. Group-Abort-Session-Answer . . . . . . . . . . . . . . 13 4.2.6. Group-Abort-Session-Answer . . . . . . . . . . . . . . 16
5. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . . 15 5.1. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . . 18
5.2. Session-Group-Action AVP . . . . . . . . . . . . . . . . . 15 5.2. Session-Group-Action AVP . . . . . . . . . . . . . . . . . 18
6. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 16 6. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 20
7.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
10. Normative References . . . . . . . . . . . . . . . . . . . . . 20 10. Normative References . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
In large network deployments, a single Diameter peer can support over In large network deployments, a single Diameter peer can support over
a million concurrent Diameter sessions. Recent use cases have a million concurrent Diameter sessions. Recent use cases have
revealed the need for Diameter peers to apply the same operation to a revealed the need for Diameter peers to apply the same operation to a
large group of Diameter sessions concurrently. For example, a policy large group of Diameter sessions concurrently. For example, a policy
decision point may need to modify the authorized quality of service decision point may need to modify the authorized quality of service
for all active users having the same type of subscription. The for all active users having the same type of subscription. The
Diameter base protocol commands operate on a single session so these Diameter base protocol commands operate on a single session so these
use cases could result in many thousands of command exchanges in use cases could result in many thousands of command exchanges to
order to enforce the same operation on each session in the group. In enforce the same operation on each session in the group. In order to
order to reduce signaling, it would be desirable to enable bulk reduce signaling, it would be desirable to enable bulk operations on
operations on all (or part of) the sessions managed by a Diameter all (or part of) the sessions managed by a Diameter peer using a
peer using a single or a few command exchanges. single or a few command exchanges.
This document describes a mechanism for grouping Diameter sessions This document describes a mechanism for grouping Diameter sessions
and performing re-authentication, re-authorization, termination and and performing re-authentication, re-authorization, termination and
abortion of groups of sessions. This document does not define a new abortion of groups of sessions. This document does not define a new
Diameter application. Instead it defines mechanisms, commands and Diameter application. Instead it defines mechanisms, commands and
AVPs that may be used by any Diameter application that requires AVPs that may be used by any Diameter application that requires
management of groups of sessions. management of groups of sessions.
2. Terminology 2. Terminology
skipping to change at page 5, line 17 skipping to change at page 5, line 17
Either Diameter peer may assign a session to a group. Diameter AAA Either Diameter peer may assign a session to a group. Diameter AAA
applications typically assign client and server roles to the Diameter applications typically assign client and server roles to the Diameter
peers. In this document, a Diameter client is a node at the edge of 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 the network that performs access control. A Diameter server is a
node that performs authentication and/or authorization of the user. node that performs authentication and/or authorization of the user.
3.1. Group assignment at session initiation 3.1. Group assignment at session initiation
To assign a session to a group at session initiation, a Diameter To assign a session to a group at session initiation, a Diameter
client sends a service specific auth request, e.g. NASREQ AAR client sends a service specific auth request, e.g. NASREQ AAR
[RFC4005], containing one or more client-assigned group identifiers. [RFC4005], containing zero or more client-assigned group identifiers.
Assuming the user is successfully authenticated and/or authorized, Assuming the user is successfully authenticated and/or authorized,
the Diameter server responds with service-specific auth response, the Diameter server responds with service-specific auth response,
e.g. NASREQ AAA [RFC4005], containing both the client-assigned group e.g. NASREQ AAA [RFC4005], containing both the client-assigned group
identifiers and the server-assigned group identifiers. identifiers and zero or more server-assigned group identifiers.
3.2. Mid-session group assignment modifications 3.2. Mid-session group assignment modifications
Either Diameter peer may modify the group membership of an active Either Diameter peer may modify the group membership of an active
Diameter session. A Diameter client MAY remove the group(s) assigned Diameter session. A Diameter client MAY remove the group(s) assigned
to the active session by the Diameter server and vice versa. to the active session by the Diameter server and vice versa.
Editor's Note: It is FFS whether this document should define a This document does not define a permission model that limits removal
default permission model limiting removal of a session from a group. of a session from a group by the same peer that added the session to
For example, the server MUST NOT remove a session from a group the group. However, applications which re-use the commands and
assigned by the client. methods defined in this document may impose their own permission
model. For example, an application could require that the server
MUST NOT remove a session from a group assigned by the client.
3.2.1. Client-initiated group assignment changes 3.2.1. Client-initiated group assignment changes
To update the assigned groups mid-session, a Diameter client sends a To update the assigned groups mid-session, a Diameter client sends a
service specific re-authorization request containing the updated list service specific re-authorization request containing the updated list
of group identifiers. Assuming the user is successfully of group identifiers. Assuming the user is successfully
authenticated and/or authorized, the Diameter server responds with a authenticated and/or authorized, the Diameter server responds with a
service-specific auth response containing the updated list of group service-specific auth response containing the updated list of group
identifiers received in the request. identifiers received in the request.
3.2.2. Server-initiated group assignment changes 3.2.2. Server-initiated group assignment changes
To update the assigned groups mid-session, a Diameter server sends a To update the assigned groups mid-session, a Diameter server sends a
Re-authorization Request (RAR) message requesting re-authorization Re-authorization Request (RAR) message requesting re-authorization
and the client responds with a Re-authorization Answer (RAA) message. and the client responds with a Re-authorization Answer (RAA) message.
The Diameter client sends a service specific re-authorization request The Diameter client sends a service specific re-authorization request
containing the current list of group identifiers and the Diameter containing the current list of group identifiers and the Diameter
server responds with a service-specific auth response containing the server responds with a service-specific auth response containing the
updated list of group identifiers. updated list of group identifiers.
3.3. Server Initiated Group Re-auth
This document defines a new Group-Re-Auth-Request/Answer (GRAR/
GRAA)command exchange which allows a server to initiate a re-
authentication and/or re-authorization of all services that are
assigned to one of the groups specified in the Session-Group-Id AVP
in the request.
An access device that receives a Group-Re-Auth-Request(GRAR) message
with Session-Group-Id equal to one of the group assigned to a
currently active session MUST initiate the type of re-auth specified
by the Re-Auth-Request-Type AVP in the manner specified by the
Session-Group-Action AVP if the service supports this particular
feature. Each Diameter application MUST state whether service-
initiated group re-authentication and/or re-authorization is
supported and which Session-Group-Action AVP values are supported for
re-authorization.
The Session-Group-Action AVP specifies whether the server requires a
re-authorization request per session, per group or for all groups.
For a Re-Auth-Request-Type value of AUTHORIZE_AUTHENTICATE, the
Session-Group-Action value MUST be PER_SESSION since re-
authentication MUST be performed per user session.
For Session-Group-Action values of PER_GROUP or ALL_GROUPS, the re-
authorization is accomplished with an application-specifc group re-
authorization command exchange. This command exchange as well as any
limitations on which aspects of the service can be modified during a
re-authorization MUST be defined by the Diameter application.
If the client is able to perform the requested re-authentication
and/or re-authentication for the sessions assigned to the group(s)
specified in the GRAR, it shall return a GRAA command with the
Result-Code AVP set to DIAMETER_SUCCESS and Session-Group-Id AVP(s)
indicating the groups for which the GRAR receiver has active sessions
assigned. If there are no sessions assigned to the group(s)
specified in the GRAR, the Result-Code is set to
DIAMETER_UNKNOWN_SESSION_ID. If the client is unable to perform the
requested re-authentication and/or re-authentication, the Result-Code
is set to DIAMETER_UNABLE_TO_COMPLY.
Diameter Diameter
Client Server
| |
(1)+-------------Svc-Specific-Auth-Request--------------->|
| Session-Id=ABC |
| |
(2)|<------------Svc-Specific-Auth-Answer-----------------+
| Session-Id=ABC; Session-Group-Id=XYZ |
| |
(3)+-------------Svc-Specific-Auth-Request--------------->|
| Session-Id=DEF |
| |
(4)|<------------Svc-Specific-Auth-Answer-----------------+
| Session-Id=DEF; Session-Group-Id=XYZ |
| |
(5)|<--------------Group-Re-Auth-Request------------------+
| Session-Group-Id=XYZ; Session-Group-Action=PER_GROUP |
| Re-Auth_Request-Type=AUTHORIZE_ONLY |
| |
(6)+---------------Group-Re-Auth-Answer------------------>|
| |
(7)+----------Svc-Specific-Group-Auth-Request------------>|
| Session-Group-Id=XYZ |
| |
(8)|<---------Svc-Specific-Group-Auth-Answer--------------+
| Updated Service Specific AVPs |
| |
Figure 1: Example: Group Re-authorization
In the example above, the Diameter server authorizes two sessions
(ABC and DEF) and assigns them to a group named XYZ (Session-Group-
Id=XYZ in steps 2 and 4). Some time later, an event occurs on the
Diameter server which requires it to change one or more of the
service parameters for the sessions assigned to group XYZ. The
Diameter server sends a Group-Re-Auth-Request (step 5) specifying the
impacted group (Session-Group-Id=XYZ) must be re-authorized (Re-Auth-
Request-Type=AUTHORIZE_ONLY) with a single re-authorize command per
group (Session-Group-Action=PER_GROUP). The Diameter client
acknowledges the request (step 6) and issues a service-specific group
authorization request to retrieve the updated service parameters
(step 7).
3.4. Session Group Termination
This document defines a new Group-Session-Termination-Request/Answer
(GSTR/GSTA) command exchange which allows a client to communicate to
the server the termination of all sessions that are assigned to one
of the groups specified in the Session-Group-Id AVP in the request.
The termination of a group of sessions could occur as a result of a
local action or in reponse to a request to abort one or more groups
of sessions.
FFS: When a client sends an GSTR to a server indicating termination
of a specific group, is it indicating termination of the sessions
that the server authorized and that are assigned to the specified
group? Or does imply termination of all sessions on the client that
are assigned to the specified group?
Upon receipt of the GSTR, the Diameter Server MUST release all
resources for the sessions assigned to the group(s) specified in the
Session-Group-Id AVP and return a GSTA with the Result-Code set to
DIAMETER_SUCCESS to acknowledge the successful termination. If there
are no sessions assigned to the group(s) specified in the GSTR, the
Result-Code is set to DIAMETER_UNKNOWN_SESSION_ID. If the server is
unable to perform the session termination, the Result-Code is set to
DIAMETER_UNABLE_TO_COMPLY.
3.5. Aborting a Group of Sessions
This document defines a new Group-Abort-Session-Request/Answer (GASR/
GASA)command exchange which allows a server to request the
termination of all sessions that are assigned to one of the groups
specified in the Session-Group-Id AVP in the request.
A client that receives an GASR with Session-Group-Id equal to a group
assigned to a currently active session MAY stop the session. Whether
the client stops the session or not is implementation- and/or
configuration-dependent. For example, a client may honor GASRs from
certain agents only. In any case, the client MUST respond with an
Group-Abort-Session-Answer, including a Result-Code AVP to indicate
what action it took.
If the client is able to perform the requested termination of the
sessions assigned to the group(s) specified in the GASR, it shall
return a GASA command with the Result-Code AVP set to
DIAMETER_SUCCESS and Session-Group-Id AVP(s) indicating the groups
for which the GASR receiver has active sessions assigned. If there
are no sessions assigned to the group(s) specified in the GASR, the
Result-Code is set to DIAMETER_UNKNOWN_SESSION_ID. If the client is
unable to perform the requested termination for any of the sessions,
the Result-Code is set to DIAMETER_UNABLE_TO_COMPLY.
When a client terminates a session upon receipt of a Group-Abort-
Session-Request, it MUST issue a session termination request to the
Diameter server that authorized the service. The Session-Group-
Action AVP specifies whether the server requires a single session
termination request per session (with STR message), per group (with
GSTR message) or for all groups (with GSTR message).
Diameter Diameter
Client Server
| |
(1)+-------------Svc-Specific-Auth-Request--------------->|
| Session-Id=ABC |
| |
(2)|<------------Svc-Specific-Auth-Answer-----------------+
| Session-Id=ABC; Session-Group-Id=XYZ |
| |
(3)+-------------Svc-Specific-Auth-Request--------------->|
| Session-Id=DEF |
| |
(4)|<------------Svc-Specific-Auth-Answer-----------------+
| Session-Id=DEF; Session-Group-Id=XYZ |
| |
(5)|<-----------Group-Abort-Session-Request---------------+
| Session-Group-Id=XYZ; Session-Group-Action=PER_GROUP |
| |
(6)+------------Group-Abort-Session-Answer--------------->|
| |
(7)+---------Group-Session-Termination-Request----------->|
| Session-Group-Id=XYZ |
| |
(8)|<---------Group-Session-Termination-Answer------------+
| |
Figure 2: Example: Aborting a Group of Sessions
In the example above, the Diameter server authorizes two sessions
(ABC and DEF) and assigns them to a group named XYZ (Session-Group-
Id=XYZ in steps 2 and 4). Some time later, an event occurs on the
Diameter server which requires it to abort the sessions assigned to
group XYZ. The Diameter server sends a Group-Abort-Session-Request
(step 5) specifying the sessions assigned to the impacted group
(Session-Group-Id=XYZ) are to be terminated and a single termination
command is to be sent per impacted group (Session-Group-
Action=PER_GROUP). The Diameter client acknowledges the request with
a GASA (step 6) and issues a GSTR (step 7) command to release all
resources for the sessions assigned to the group XYZ. The Diameter
server acknowledges the termination with a GGSTA (Step 8).
4. Protocol Description 4. Protocol Description
4.1. Session Management 4.1. Session Management
4.1.1. Authorization Session State Machine 4.1.1. Authorization Session State Machine
Section 8.1 in [RFC3588] defines a set of finite state machines, Section 8.1 in [RFC3588] defines a set of finite state machines,
representing the life cycle of Diameter sessions, and which MUST be representing the life cycle of Diameter sessions, and which MUST be
observed by all Diameter implementations that make use of the observed by all Diameter implementations that make use of the
authentication and/or authorization portion of a Diameter authentication and/or authorization portion of a Diameter
skipping to change at page 6, line 40 skipping to change at page 10, line 40
State Event Action New State State Event Action New State
--------------------------------------------------------------- ---------------------------------------------------------------
Idle Client or Device Requests Send Pending Idle Client or Device Requests Send Pending
access service access service
specific specific
auth req auth req
optionally optionally
including including
groups groups
Open BASR received with Send BASA Discon Open GASR received with Send GASA Discon
Session-Group-Action with Session-Group-Action with
= ALL_GROUPS, Result-Code = ALL_GROUPS, Result-Code
session is assigned to = SUCCESS, session is assigned to = SUCCESS,
received group(s) and Send BSTR. received group(s) and Send GSTR.
client will comply with client will comply with
request to end the session request to end the session
Open BASR received with Send BASA Discon Open GASR received with Send GASA Discon
Session-Group-Action with Session-Group-Action with
= PER_GROUPS, Result-Code = PER_GROUPS, Result-Code
session is assigned to = SUCCESS, session is assigned to = SUCCESS,
received group(s) and Send BSTR received group(s) and Send GSTR
client will comply with per group client will comply with per group
request to end the session request to end the session
Open BASR received with Send BASA Discon Open GASR received with Send GASA Discon
Session-Group-Action with Session-Group-Action with
= PER_SESSION, Result-Code = PER_SESSION, Result-Code
session is assigned to = SUCCESS, session is assigned to = SUCCESS,
received group(s) and Send STR received group(s) and Send STR
client will comply with per session client will comply with per session
request to end the session request to end the session
Open BASR received, Send BASA Open Open GASR received, Send GASA Open
client will not comply with with client will not comply with with
request to end all session Result-Code request to end all session Result-Code
in received group(s) != SUCCESS in received group(s) != SUCCESS
Discon BSTA Received Discon. Idle Discon GSTA Received Discon. Idle
user/device user/device
Open BRAR received with Send BRAA, Pending Open GRAR received with Send GRAA, Pending
Session-Group-Action Send Session-Group-Action Send
= ALL_GROUPS, service = ALL_GROUPS, service
session is assigned to specific session is assigned to specific
received group(s) and group received group(s) and group
client will perform re-auth req client will perform re-auth req
subsequent re-auth subsequent re-auth
Open BRAR received with Send BRAA, Pending Open GRAR received with Send GRAA, Pending
Session-Group-Action Send Session-Group-Action Send
= PER_GROUP, service = PER_GROUP, service
session is assigned to specific session is assigned to specific
received group(s) and group received group(s) and group
client will perform re-auth req client will perform re-auth req
subsequent re-auth per group subsequent re-auth per group
Open BRAR received with Send BRAA, Pending Open GRAR received with Send GRAA, Pending
Session-Group-Action Send Session-Group-Action Send
= PER_SESSION, service = PER_SESSION, service
session is assigned to specific session is assigned to specific
received group(s) and re-auth req received group(s) and re-auth req
client will perform per session client will perform per session
subsequent re-auth subsequent re-auth
Open BRAR received and client will Send BRAA Idle Open GRAR received and client will Send GRAA Idle
not perform subsequent with not perform subsequent with
re-auth Result-Code re-auth Result-Code
!= SUCCESS, != SUCCESS,
Discon. Discon.
user/device user/device
Pending Successful service-specific Provide Open Pending Successful service-specific Provide Open
group re-authorization answer service group re-authorization answer service
received. received.
skipping to change at page 9, line 18 skipping to change at page 13, line 18
Idle Service-specific authorization Send Open Idle Service-specific authorization Send Open
request received, and user successful request received, and user successful
is authorized service is authorized service
specific specific
answer answer
optionally optionally
including including
groups groups
Open Server wants to terminate Send BASR Discon Open Server wants to terminate Send GASR Discon
group(s) group(s)
Discon BASA received Cleanup Idle Discon GASA received Cleanup Idle
Any BSTR received Send BSTA, Idle Any GSTR received Send GSTA, Idle
Cleanup Cleanup
Open Server wants to reauth Send BRAR Pending Open Server wants to reauth Send GRAR Pending
group(s) group(s)
Pending BRAA received with Result-Code Update Open Pending GRAA received with Result-Code Update Open
= SUCCESS session(s) = SUCCESS session(s)
Pending BRAA received with Result-Code Cleanup Idle Pending GRAA received with Result-Code Cleanup Idle
!= SUCCESS session(s) != SUCCESS session(s)
Open Service-specific group Send Open Open Service-specific group Send Open
re-authoization request successful re-authoization request successful
received and user is service received and user is service
authorized specific authorized specific
group group
re-auth re-auth
answer answer
Open Service-specific group Send Idle Open Service-specific group Send Idle
re-authorization request failed re-authorization request failed
received and user is service received and user is service
not authorized specific not authorized specific
group group
re-auth re-auth
answer, answer,
cleanup cleanup
4.1.2. Server Initiated Group Re-auth
TODO: rules/restrictions governing group re-auth
4.1.3. Session Group Termination
TODO: rules/restrictions governing session group termination
4.1.4. Aborting a Group of Sessions
TODO: rules/restrictions governing aborting groups of session
4.2. Commands 4.2. Commands
This specification extends the existing RAR, RAA, STR, STA, ASR and This specification extends the existing RAR, RAA, STR, STA, ASR and
ASA command ABNFs. ASA command ABNFs.
4.2.1. Group-Re-Auth-Request 4.2.1. Group-Re-Auth-Request
The Group-Re-Auth-Request (GRAR), indicated by the Command-Code set 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 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 to the access device that is providing session service, to request
skipping to change at page 10, line 38 skipping to change at page 14, line 26
authorized. authorized.
<GRAR> ::= < Diameter Header: TBD, REQ, PXY > <GRAR> ::= < Diameter Header: TBD, REQ, PXY >
* { Session-Group-Id } * { Session-Group-Id }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
{ Destination-Host } { Destination-Host }
{ Auth-Application-Id } { Auth-Application-Id }
{ Re-Auth-Request-Type } { Re-Auth-Request-Type }
[ User-Name ]
[ Origin-State-Id ] [ Origin-State-Id ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ Route-Record ] * [ Route-Record ]
[ Session-Group-Action ] [ Session-Group-Action ]
* [ AVP ] * [ AVP ]
4.2.2. Group-Re-Auth-Answer 4.2.2. Group-Re-Auth-Answer
The Group-Re-Auth-Answer (GRAA), indicated by the Command-Code set to 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 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 GRAR. The Result-Code AVP MUST be present, and indicates the
disposition of the request. 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.
<GRAA> ::= < Diameter Header: TBD, PXY > <GRAA> ::= < Diameter Header: TBD, PXY >
* { Session-Group-Id } * { Session-Group-Id }
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
[ User-Name ]
[ Origin-State-Id ] [ Origin-State-Id ]
[ Error-Message ] [ Error-Message ]
[ Error-Reporting-Host ] [ Error-Reporting-Host ]
* [ Failed-AVP ] * [ Failed-AVP ]
* [ Redirect-Host ] * [ Redirect-Host ]
[ Redirect-Host-Usage ] [ Redirect-Host-Usage ]
[ Redirect-Host-Cache-Time ] [ Redirect-Host-Cache-Time ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ AVP ] * [ AVP ]
skipping to change at page 12, line 12 skipping to change at page 15, line 35
groups of authenticated and/or authorized sessions are being groups of authenticated and/or authorized sessions are being
terminated. terminated.
<GSTR> ::= < Diameter Header: TBD, REQ, PXY > <GSTR> ::= < Diameter Header: TBD, REQ, PXY >
* { Session-Group-Id } * { Session-Group-Id }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
{ Auth-Application-Id } { Auth-Application-Id }
{ Termination-Cause } { Termination-Cause }
[ User-Name ]
[ Destination-Host ] [ Destination-Host ]
* [ Class ] * [ Class ]
[ Origin-State-Id ] [ Origin-State-Id ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ Route-Record ] * [ Route-Record ]
* [ AVP ] * [ AVP ]
4.2.4. Group-Session-Termination-Answer 4.2.4. Group-Session-Termination-Answer
The Group-Session-Termination-Answer (GSTA), indicated by the The Group-Session-Termination-Answer (GSTA), indicated by the
Command-Code set to TBD and the message flags' 'R' bit clear, is sent 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 by the Diameter Server to acknowledge the notification that one or
more groups of session have been terminated. The Result-Code AVP more groups of session have been terminated. The Result-Code AVP
MUST be present, and MAY contain an indication that an error occurred MUST be present, and MAY contain an indication that an error occurred
while servicing the GSTR. 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.
<GSTA> ::= < Diameter Header: TBD, PXY > <GSTA> ::= < Diameter Header: TBD, PXY >
* { Session-Group-Id } * { Session-Group-Id }
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
[ User-Name ]
* [ Class ] * [ Class ]
[ Error-Message ] [ Error-Message ]
[ Error-Reporting-Host ] [ Error-Reporting-Host ]
* [ Failed-AVP ] * [ Failed-AVP ]
[ Origin-State-Id ] [ Origin-State-Id ]
* [ Redirect-Host ] * [ Redirect-Host ]
[ Redirect-Host-Usage ] [ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ] [ Redirect-Max-Cache-Time ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ AVP ] * [ AVP ]
skipping to change at page 13, line 20 skipping to change at page 16, line 36
request that the sessions identified by the Session-Group-Id be request that the sessions identified by the Session-Group-Id be
stopped. stopped.
<GASR> ::= < Diameter Header: TBD, REQ, PXY > <GASR> ::= < Diameter Header: TBD, REQ, PXY >
* { Session-Group-Id } * { Session-Group-Id }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
{ Destination-Realm } { Destination-Realm }
{ Destination-Host } { Destination-Host }
{ Auth-Application-Id } { Auth-Application-Id }
[ User-Name ]
[ Origin-State-Id ] [ Origin-State-Id ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ Route-Record ] * [ Route-Record ]
[ Group-Action ] [ Group-Action ]
* [ AVP ] * [ AVP ]
4.2.6. Group-Abort-Session-Answer 4.2.6. Group-Abort-Session-Answer
The Group-Abort-Session-Answer (GASA), indicated by the Command-Code 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 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 to the GASR. The Result-Code AVP MUST be present, and indicates the
disposition of the request. 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.
<GASA> ::= < Diameter Header: TBD, PXY > <GASA> ::= < Diameter Header: TBD, PXY >
* { Session-Group-Id } * { Session-Group-Id }
{ Result-Code } { Result-Code }
{ Origin-Host } { Origin-Host }
{ Origin-Realm } { Origin-Realm }
[ User-Name ]
[ Origin-State-Id ] [ Origin-State-Id ]
[ Error-Message ] [ Error-Message ]
[ Error-Reporting-Host ] [ Error-Reporting-Host ]
* [ Failed-AVP ] * [ Failed-AVP ]
* [ Redirect-Host ] * [ Redirect-Host ]
[ Redirect-Host-Usage ] [ Redirect-Host-Usage ]
[ Redirect-Max-Cache-Time ] [ Redirect-Max-Cache-Time ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ AVP ] * [ AVP ]
skipping to change at page 15, line 21 skipping to change at page 18, line 21
Attribute Name Code Value Type |MUST|MAY| NOT | NOT| Attribute Name Code Value Type |MUST|MAY| NOT | NOT|
+---------------------------------------+----+---+------+----+ +---------------------------------------+----+---+------+----+
|Session-Group-Id TBD OctetString | | P | | V | |Session-Group-Id TBD OctetString | | P | | V |
|Session-Group-Action TBD Enumerated | | P | | V | |Session-Group-Action TBD Enumerated | | P | | V |
+---------------------------------------+----+---+------+----+ +---------------------------------------+----+---+------+----+
AVPs for the Diameter Group Signaling AVPs for the Diameter Group Signaling
5.1. Session-Group-Id AVP 5.1. Session-Group-Id AVP
The Session-Group-Id AVP (AVP Code TBD) is of type OctetString and
identifies a group of sessions. This uniqueness scope of this AVP is
specified by the Diameter application which makes use of group
signaling commands.
5.2. Session-Group-Action AVP 5.2. Session-Group-Action AVP
The Session-Group-Action AVP (AVP Code TBD) is of type Enumerated and The Session-Group-Action AVP (AVP Code TBD) is of type Enumerated and
specifies how the peer SHOULD issue follow up exchanges in response specifies how the peer SHOULD issue follow up exchanges in response
to a command which impacts mulitple sessions. The following values to a command which impacts mulitple sessions. The following values
are supported: are supported:
ALL_GROUPS (0) ALL_GROUPS (0)
Follow up exchanges should be performed with a single message Follow up exchanges should be performed with a single message
exchange for all impacted groups. exchange for all impacted groups.
skipping to change at page 21, line 8 skipping to change at page 24, line 8
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005, "Diameter Network Access Server Application", RFC 4005,
August 2005. August 2005.
Author's Address Author's Address
Mark Jones Mark Jones
Bridgewater Systems Amdocs
Email: mark@azu.ca Email: mark@azu.ca
 End of changes. 40 change blocks. 
125 lines changed or deleted 254 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/