< draft-ietf-dime-group-signaling-06.txt   draft-ietf-dime-group-signaling-07.txt >
Diameter Maintenance and Extensions (DIME) M. Jones Diameter Maintenance and Extensions (DIME) M. Jones
Internet-Draft Internet-Draft
Intended status: Standards Track M. Liebsch Intended status: Standards Track M. Liebsch
Expires: September 22, 2016 Expires: August 21, 2017
L. Morand L. Morand
March 21, 2016 February 17, 2017
Diameter Group Signaling Diameter Group Signaling
draft-ietf-dime-group-signaling-06.txt draft-ietf-dime-group-signaling-07.txt
Abstract Abstract
In large network deployments, a single Diameter node can support over In large network deployments, a single Diameter node 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 nodes to apply the same operation to a revealed the need for Diameter nodes 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 to enforce the could result in many thousands of command exchanges to enforce the
same operation on each session in the group. In order to reduce same operation on each session in the group. In order to reduce
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 September 22, 2016. This Internet-Draft will expire on August 21, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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 29 skipping to change at page 2, line 29
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Building and Modifying Session Groups . . . . . . . . . . 4 3.1. Building and Modifying Session Groups . . . . . . . . . . 4
3.2. Issuing Group Commands . . . . . . . . . . . . . . . . . 4 3.2. Issuing Group Commands . . . . . . . . . . . . . . . . . 4
3.3. Permission Considerations . . . . . . . . . . . . . . . . 4 3.3. Permission Considerations . . . . . . . . . . . . . . . . 4
4. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 6
4.1. Session Grouping Capability Discovery . . . . . . . . . . 7 4.1. Session Grouping Capability Discovery . . . . . . . . . . 7
4.1.1. Explicit Capability Discovery . . . . . . . . . . . . 7 4.1.1. Explicit Capability Discovery . . . . . . . . . . . . 7
4.1.2. Implicit Capability Discovery . . . . . . . . . . . . 7 4.1.2. Implicit Capability Discovery . . . . . . . . . . . . 7
4.2. Session Grouping . . . . . . . . . . . . . . . . . . . . 7 4.2. Session Grouping . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Group assignment at session initiation . . . . . . . 8 4.2.1. Group assignment at session initiation . . . . . . . 8
4.2.2. Removing a session from a session group . . . . . . . 10 4.2.2. Removing a session from a session group . . . . . . . 11
4.2.3. Mid-session group assignment modifications . . . . . 11 4.2.3. Mid-session group assignment modifications . . . . . 12
4.3. Deleting a Session Group . . . . . . . . . . . . . . . . 12 4.3. Deleting a Session Group . . . . . . . . . . . . . . . . 13
4.4. Performing Group Operations . . . . . . . . . . . . . . . 12 4.4. Performing Group Operations . . . . . . . . . . . . . . . 13
4.4.1. Sending Group Commands . . . . . . . . . . . . . . . 12 4.4.1. Sending Group Commands . . . . . . . . . . . . . . . 13
4.4.2. Receiving Group Commands . . . . . . . . . . . . . . 13 4.4.2. Receiving Group Commands . . . . . . . . . . . . . . 14
4.4.3. Error Handling for Group Commands . . . . . . . . . . 14 4.4.3. Error Handling for Group Commands . . . . . . . . . . 14
4.4.4. Single-Session Fallback . . . . . . . . . . . . . . . 14 4.4.4. Single-Session Fallback . . . . . . . . . . . . . . . 15
5. Operation with Proxies Agents . . . . . . . . . . . . . . . . 14 5. Operation with Proxy Agents . . . . . . . . . . . . . . . . . 15
6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 15 6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 16
6.1. Formatting Example: Group Re-Auth-Request . . . . . . . . 15 6.1. Formatting Example: Group Re-Auth-Request . . . . . . . . 16
7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 16 7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 17
7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . 16 7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . 17
7.2. Session-Group-Control-Vector AVP . . . . . . . . . . . . 17 7.2. Session-Group-Control-Vector AVP . . . . . . . . . . . . 17
7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . 17 7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . 18
7.4. Group-Response-Action AVP . . . . . . . . . . . . . . . . 18 7.4. Group-Response-Action AVP . . . . . . . . . . . . . . . . 18
7.5. Session-Group-Capability-Vector AVP . . . . . . . . . . . 18 7.5. Session-Group-Capability-Vector AVP . . . . . . . . . . . 19
8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 18 8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
12. Normative References . . . . . . . . . . . . . . . . . . . . 20 12. Normative References . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Session Management -- Exemplary Session State Appendix A. Session Management -- Exemplary Session State
Machine . . . . . . . . . . . . . . . . . . . . . . 20 Machine . . . . . . . . . . . . . . . . . . . . . . 21
A.1. Use of groups for the Authorization Session State Machine 20 A.1. Use of groups for the Authorization Session State Machine 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
In large network deployments, a single Diameter node can support over In large network deployments, a single Diameter node 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 nodes to apply the same operation to a revealed the need for Diameter nodes 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
skipping to change at page 4, line 5 skipping to change at page 4, line 5
operations in case no external mechanism is available to discover a operations in case no external mechanism is available to discover a
Diameter peer's capability to support session grouping and session Diameter peer's capability to support session grouping and session
group operations group operations
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document uses terminology defined [RFC6733]. This document uses terminology defined in [RFC6733].
3. Protocol Overview 3. Protocol Overview
3.1. Building and Modifying Session Groups 3.1. Building and Modifying Session Groups
Client and Server can assign a new Diameter session to a group, e.g. Client and Server can assign a new Diameter session to a group, e.g.
in case the subscription profile of the associated user has similar in case the subscription profile of the associated user has similar
characteristics as the profile of other users whose Diameter session characteristics as the profile of other users whose Diameter session
has been assigned to one or multiple groups. A single command can be has been assigned to one or multiple groups. A single command can be
issued and applied to all sessions associated with such group(s), issued and applied to all sessions associated with such group(s),
skipping to change at page 5, line 27 skipping to change at page 5, line 27
terms of moving a session from one session group to a different terms of moving a session from one session group to a different
session group is permitted to any Diameter node. A Diameter node can session group is permitted to any Diameter node. A Diameter node can
delete a session group and its group identifier mid-session, delete a session group and its group identifier mid-session,
resulting in individual treatment of the sessions which have been resulting in individual treatment of the sessions which have been
previously assigned to the deleted group. Prerequisite for deletion previously assigned to the deleted group. Prerequisite for deletion
of a session group is that the Diameter node created the session of a session group is that the Diameter node created the session
beforehand, hence the node became the group owner. beforehand, hence the node became the group owner.
The enforcement of more constrained permissions is left to the The enforcement of more constrained permissions is left to the
specification of a particular group signaling enabled Diameter specification of a particular group signaling enabled Diameter
application and compliant implementations of such application must application and compliant implementations of such application MUST
enforce the associated permission model. Details about enforcing a enforce the associated permission model. Details about enforcing a
more constraint permission model are out of scope of this more constraint permission model are out of scope of this
specification. For example, a more constrained model could require specification. For example, a more constrained model could require
that a client MUST NOT remove a session from a group which is owned that a client MUST NOT remove a session from a group which is owned
by the server. by the server.
The following table depicts the permission considerations as per the The following table depicts the permission considerations as per the
present specification: present specification:
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
skipping to change at page 7, line 6 skipping to change at page 7, line 6
group. Here, overruling is to be understood as a node changing the group. Here, overruling is to be understood as a node changing the
group(s) assignment as per the node's request. Group signaling group(s) assignment as per the node's request. Group signaling
enabled applications may take such protocol support and associated enabled applications may take such protocol support and associated
protocol semantics into account in their specification. One protocol semantics into account in their specification. One
exception is adopted in this specification, which allows a Diameter exception is adopted in this specification, which allows a Diameter
server to reject a group assignment as per the client's request. server to reject a group assignment as per the client's request.
4. Protocol Description 4. Protocol Description
4.1. Session Grouping Capability Discovery 4.1. Session Grouping Capability Discovery
Diameter nodes should assign a session to a session group and perform Diameter nodes SHOULD assign a session to a session group and perform
session group operations with a node only after having ensured that session group operations with a node only after having ensured that
the node announced associated support beforehand. the node announced associated support beforehand.
4.1.1. Explicit Capability Discovery 4.1.1. Explicit Capability Discovery
New Diameter applications may consider support for Diameter session New Diameter applications may consider support for Diameter session
grouping and for performing group commands during the standardization grouping and for performing group commands during the standardization
process. Such applications provide intrinsic discovery for the process. Such applications provide intrinsic discovery for the
support of group commands and announce this capability through the support of group commands and announce this capability through the
assigned application ID. assigned application ID.
skipping to change at page 7, line 48 skipping to change at page 7, line 48
Vector AVP from a node with the BASE_SESSION_GROUP_CAPABILITY flag Vector AVP from a node with the BASE_SESSION_GROUP_CAPABILITY flag
set, the Diameter node maintains a log to remember the node's set, the Diameter node maintains a log to remember the node's
capability to support group commands. capability to support group commands.
4.2. Session Grouping 4.2. Session Grouping
This specification does not limit the number of session groups, to This specification does not limit the number of session groups, to
which a single session is assigned. It is left to the application to which a single session is assigned. It is left to the application to
determine the policy of session grouping. In case an application determine the policy of session grouping. In case an application
facilitates a session to belong to multiple session groups, the facilitates a session to belong to multiple session groups, the
application must maintain consistency of associated application application MUST maintain consistency of associated application
session states for these multiple session groups. session states for these multiple session groups.
Either Diameter node (client or server) can initiate the assignment Either Diameter node (client or server) can initiate the assignment
of a session to a single or multiple session groups. Modification of of a session to a single or multiple session groups. Modification of
a group by removing or adding a single or multiple user sessions can a group by removing or adding a single or multiple user sessions can
be initiated and performed mid-session by either Diameter node. be initiated and performed mid-session by either Diameter node.
Diameter AAA applications typically assign client and server roles to Diameter AAA applications typically assign client and server roles to
the Diameter nodes, which are referred to as relevant Diameter nodes the Diameter nodes, which are referred to as relevant Diameter nodes
to utilize session grouping and issue group commands. Section 5 to utilize session grouping and issue group commands. Section 5
describes particularities about session grouping and performing group describes particularities about session grouping and performing group
commands when relay agents or proxies are deployed. commands when relay agents or proxies are deployed.
Diameter nodes, which are group-aware, must store and maintain an Diameter nodes, which are group-aware, MUST store and maintain an
entry about the group assignment together with a session's state. A entry about the group assignment together with a session's state. A
list of all known session groups should be locally maintained on each list of all known session groups should be locally maintained on each
node, each group pointing to individual sessions being assigned to node, each group pointing to individual sessions being assigned to
the group. A Diameter node must also keep a record about sessions, the group. A Diameter node MUST also keep a record about sessions,
which have been assigned to a session group by itself. which have been assigned to a session group by itself.
4.2.1. Group assignment at session initiation 4.2.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 request, e.g. NASREQ AA-Request client sends a service specific request, e.g. NASREQ AA-Request
[RFC4005], containing one or more session group identifiers. Each of [RFC4005], containing one or more session group identifiers. Each of
these groups needs to be identified by a unique Session-Group-Id these groups MUST be identified by a unique Session-Group-Id
contained in a separate Session-Group-Info AVP as specified in contained in a separate Session-Group-Info AVP as specified in
Section 7. Section 7.
The client may choose one or multiple session groups from a list of The client may choose one or multiple session groups from a list of
existing session groups. Alternatively, the client may decide to existing session groups. Alternatively, the client may decide to
create a new group to which the session is assigned and identify create a new group to which the session is assigned and identify
itself in the <DiameterIdentity> portion of the Session-Group-Id AVP itself in the <DiameterIdentity> portion of the Session-Group-Id AVP
as per Section 7.3 as per Section 7.3
The client MUST set the SESSION_GROUP_ALLOCATION_ACTION flag of the The client MUST set the SESSION_GROUP_ALLOCATION_ACTION flag of the
Session-Group-Control-Vector AVP in each appended Session-Group-Info Session-Group-Control-Vector AVP in each appended Session-Group-Info
AVP to indicate that the session contained in the request should be AVP to indicate that the session contained in the request should be
assigned to the identified session group. assigned to the identified session group.
The client may also indicate in the request that the server is The client may also indicate in the request that the server is
responsible for the assignment of the session in one or multiple responsible for the assignment of the session in one or multiple
sessions owned by the server. In such a case, the client MUST sessions owned by the server. In such a case, the client MUST
includes in the request the Session-Group-Info AVP in the request include the Session-Group-Info AVP in the request including the
including the Session-Group-Control-Vector AVP with Session-Group-Control-Vector AVP with the
SESSION_GROUP_ALLOCATION_ACTION flag set but no Session-Group-Id AVP. SESSION_GROUP_ALLOCATION_ACTION flag set but no Session-Group-Id AVP.
If the Diameter server receives a command request from a Diameter If the Diameter server receives a command request from a Diameter
client and the command comprises at least one Session-Group-Info AVP client and the command comprises at least one Session-Group-Info AVP
having the SESSION_GROUP_ALLOCATION_ACTION flag set in the Session- having the SESSION_GROUP_ALLOCATION_ACTION flag in the Session-Group-
Group-Control-Vector AVP set, the server can accept or reject the Control-Vector AVP set, the server can accept or reject the request
request for group assignment. Reasons for rejection may be e.g. lack for group assignment. Reasons for rejection may be e.g. lack of
of resources for managing additional groups. When rejected, the resources for managing additional groups. When rejected, the session
session must not be assigned to any session group but be treated as MUST NOT be assigned to any session group.
single session.
If the Diameter server accepts the client's request for a group If the Diameter server accepts the client's request for a group
assignment, the server must assign the new session to each of the one assignment, the server MUST assign the new session to each of the one
or multiple identified session groups when present in the Session- or multiple identified session groups when present in the Session-
Group-Info AVP. In case one or multiple identified session groups Group-Info AVP. In case one or multiple identified session groups
are not already stored by the server, the server must store the new are not already stored by the server, the server MUST store the new
identified group(s) to its local list of known session groups. When identified group(s) to its local list of known session groups. When
sending the response to the client, e.g. a service-specific auth sending the response to the client, e.g. a service-specific auth
response as per NASREQ AA-Answer [RFC4005], the server must include response as per NASREQ AA-Answer [RFC4005], the server MUST include
all Session-Group-Info AVPs as received in the client's request. all Session-Group-Info AVPs as received in the client's request.
In addition to the one or multiple session groups identified in the In addition to the one or multiple session groups identified in the
client's request, the server may decide to assign the new session to client's request, the server may decide to assign the new session to
one or multiple additional groups. In such a case, the server adds one or multiple additional groups. In such a case, the server MUST
to the response the additional Session-Group-Info AVPs, each add to the response the additional Session-Group-Info AVPs, each
identifying a session group to which the new session is assigned by identifying a session group to which the new session is assigned by
the server. Each of the Session-Group-Info AVP added by the server the server. Each of the Session-Group-Info AVP added by the server
must have the SESSION_GROUP_ALLOCATION_ACTION flag set in the MUST have the SESSION_GROUP_ALLOCATION_ACTION flag set in the
Session-Group-Control-Vector AVP set. Session-Group-Control-Vector AVP set.
If the Diameter server rejects the client's request for a group If the Diameter server rejects the client's request for a group
assignment, the server sends the response to the client, e.g. a assignment, the server sends the response to the client, e.g. a
service-specific auth response as per NASREQ AA-Answer [RFC4005], and service-specific auth response as per NASREQ AA-Answer [RFC4005], and
must include all Session-Group-Info AVPs as received in the client's MUST include all Session-Group-Info AVPs as received in the client's
request (if any) while clearing the SESSION_GROUP_ALLOCATION_ACTION request (if any) while clearing the SESSION_GROUP_ALLOCATION_ACTION
flag of the Session-Group-Control-Vector AVP. flag of the Session-Group-Control-Vector AVP. The server MAY accept
the client's request for the identified session but refuse the
session's assignment to any session group. The server sends the
response to the client indicating success in the result code. In
such case the session is treated as single session without assignment
to any session group by the Diameter nodes.
If the Diameter server accepts the client's request for a group
assignment, but the assignment of the session to one or some of the
multiple identified session groups fails, the session group
assignment is treated as failure. In such case the session is
treated as single session without assignment to any session group by
the Diameter nodes. The server sends the response to the client and
MAY include as information to the client only those Session-Group-
Info AVPs for which the group assignment failed. The
SESSION_GROUP_ALLOCATION_ACTION flag of included Session-Group-Info
AVPs MUST be cleared.
If the Diameter server receives a command request from a Diameter If the Diameter server receives a command request from a Diameter
client and the command comprises one or multiple Session-Group-Info client and the command comprises one or multiple Session-Group-Info
AVPs and none of them including a Session-Group-Id AVP, the server AVPs and none of them includes a Session-Group-Id AVP, the server MAY
MAY decide to assign the session to one or multiple session groups. decide to assign the session to one or multiple session groups. For
For each session group, to which the server assigns the new session, each session group, to which the server assigns the new session, the
the server includes a Session-Group-Info AVP with the Session-Group- server includes a Session-Group-Info AVP with the Session-Group-Id
Id AVP identifying a session group in the response sent to the AVP identifying a session group in the response sent to the client.
client. Each of the Session-Group-Info AVPs included by the server Each of the Session-Group-Info AVPs included by the server MUST have
must have the SESSION_GROUP_ALLOCATION_ACTION flag of the Session- the SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-
Group-Control-Vector AVP set. Control-Vector AVP set.
If the Diameter server receives a command request from a Diameter If the Diameter server receives a command request from a Diameter
client and the command does not contain any Session-Group-Info AVP, client and the command does not contain any Session-Group-Info AVP,
the server MUST not assign the new session to any session group but the server MUST NOT assign the new session to any session group but
treat the request as for a single session. The server MUST return treat the request as for a single session. The server MUST NOT
any Session-Group-Info AVP in the command response. return any Session-Group-Info AVP in the command response.
If the Diameter client receives a response to its previously issued If the Diameter client receives a response to its previously issued
request from the server and the response comprises at least one request from the server and the response comprises at least one
Session-Group-Info AVP having the SESSION_GROUP_ALLOCATION_ACTION Session-Group-Info AVP having the SESSION_GROUP_ALLOCATION_ACTION
flag of the associated Session-Group-Control-Vector AVP set, the flag of the associated Session-Group-Control-Vector AVP set, the
client MUST add the new session to all session groups as identified client MUST add the new session to all session groups as identified
in the one or multiple Session-Group-Info AVPs. in the one or multiple Session-Group-Info AVPs. If the Diameter
client fails to add the session to one or more session groups as
identified in the one or multiple Session-Group-info AVPs, the client
MUST terminate the session. The client MAY send a subsequent request
for session initiation to the server without requesting the
assignment of the session to a session group
If the Diameter client receives a response to its previously issued If the Diameter client receives a response to its previously issued
request from the server and the one or more Session-Group-Info AVPs request from the server and the one or more Session-Group-Info AVPs
have the SESSION_GROUP_ALLOCATION_ACTION flag of the associated have the SESSION_GROUP_ALLOCATION_ACTION flag of the associated
Session-Group-Control-Vector AVP cleared, the client MUST terminate Session-Group-Control-Vector AVP cleared, the client MUST terminate
the assignment of the session to the one or multiple groups and the assignment of the session to the one or multiple groups. If the
continue to treat the session as single session without group response from the server indicates success in the result code but
assignment. solely the assignment of the session to a session group has been
rejected by the server, the client treats the session as single
session without group assignment.
A Diameter client, which sent a request for session initiation to a A Diameter client, which sent a request for session initiation to a
Diameter server and appended a single or multiple Session-Group-Id Diameter server and appended a single or multiple Session-Group-Id
AVPs but cannot find any Session-Group-Info AVP in the associated AVPs but cannot find any Session-Group-Info AVP in the associated
response from the Diameter server proceeds as if the request was response from the Diameter server proceeds as if the request was
processed for a single session. processed for a single session. When the Diameter client is
confident that the Diameter server supports session grouping and
group signaling, the Diameter client SHOULD NOT retry to request
group assignment for this session, but MAY try to request group
assignment for other new sessions.
4.2.2. Removing a session from a session group 4.2.2. Removing a session from a session group
When a Diameter client decides to remove a session from a particular When a Diameter client decides to remove a session from a particular
session group, the client sends a service-specific re-authorization session group, the client sends a service-specific re-authorization
request to the server and adds one Session-Group-Info AVP to the request to the server and adds one Session-Group-Info AVP to the
request for each session group, from which the client wants to remove request for each session group, from which the client wants to remove
the session. The session, which is to be removed from a group, is the session. The session, which is to be removed from a group, is
identified in the Session-Id AVP of the command request. The identified in the Session-Id AVP of the command request. The
SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control- SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control-
Vector AVP in each Session-Group-Info AVP must be cleared to indicate Vector AVP in each Session-Group-Info AVP MUST be cleared to indicate
removal of the session from the session group identified in the removal of the session from the session group identified in the
associated Session-Group-id AVP. associated Session-Group-id AVP.
When a Diameter client decides to remove a session from all session When a Diameter client decides to remove a session from all session
groups, to which the session has been previously assigned, the client groups, to which the session has been previously assigned, the client
sends a service-specific re-authorization request to the server and sends a service-specific re-authorization request to the server and
adds a single Session-Group-Info AVP to the request which has the adds a single Session-Group-Info AVP to the request which has the
SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id
AVP omitted. The session, which is to be removed from all groups, to AVP omitted. The session, which is to be removed from all groups, to
which the session has been previously assigned, is identified in the which the session has been previously assigned, is identified in the
Session-Id AVP of the command request. Session-Id AVP of the command request.
If the Diameter server receives a request from the client which has If the Diameter server receives a request from the client which has
at least one Session-Group-Info AVP appended with the at least one Session-Group-Info AVP appended with the
SESSION_GROUP_ALLOCATION_ACTION flag cleared, the server must remove SESSION_GROUP_ALLOCATION_ACTION flag cleared, the server MUST remove
the session from the session group identified in the associated the session from the session group identified in the associated
Session-Group-Id AVP. If the request comprises at least one Session- Session-Group-Id AVP. If the request comprises at least one Session-
Group-info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared Group-info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared
and no Session-Id AVP present, the server must remove the session and no Session-Id AVP present, the server MUST remove the session
from all session groups to which the session has been previously from all session groups to which the session has been previously
assigned. The server must include in its response to the requesting assigned. The server MUST include in its response to the requesting
client all Session-Group-Id AVPs as received in the request. client all Session-Group-Id AVPs as received in the request.
When the Diameter server decides to remove a session from one or When the Diameter server decides to remove a session from one or
multiple particular session groups or from all session groups to multiple particular session groups or from all session groups to
which the session has been assigned beforehand, the server sends a which the session has been assigned beforehand, the server sends a
Re-Authorization Request (RAR) or a service-specific server-initiated Re-Authorization Request (RAR) or a service-specific server-initiated
request to the client, indicating the session in the Session-Id AVP request to the client, indicating the session in the Session-Id AVP
of the request. The client sends a Re-Authorization Answer (RAA) or of the request. The client sends a Re-Authorization Answer (RAA) or
a service-specific answer to respond to the server's request. The a service-specific answer to respond to the server's request. The
client subsequently sends service-specific re-authorization request client subsequently sends service-specific re-authorization request
skipping to change at page 12, line 6 skipping to change at page 12, line 33
SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP
present, identifying the session group to which the session should be present, identifying the session group to which the session should be
assigned. With the same message, the client may send one or multiple assigned. With the same message, the client may send one or multiple
Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag
cleared and the Session-Group-Id AVP identifying the session group cleared and the Session-Group-Id AVP identifying the session group
from which the identified session is to be removed. To remove the from which the identified session is to be removed. To remove the
session from all previously assigned session groups, the client session from all previously assigned session groups, the client
includes at least one Session-Group-Info AVP with the includes at least one Session-Group-Info AVP with the
SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id
AVP present. When the server received the service-specific re- AVP present. When the server received the service-specific re-
authorization request, it must update its locally maintained view of authorization request, it MUST update its locally maintained view of
the session groups for the identified session according to the the session groups for the identified session according to the
appended Session-Group-Info AVPs. The server sends a service- appended Session-Group-Info AVPs. The server sends a service-
specific auth response to the client containing one or multiple specific auth response to the client containing one or multiple
Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag
set and the Session-Group-Id AVP identifying the new session group to set and the Session-Group-Id AVP identifying the new session group to
which the identified session has been assigned. which the identified session has been assigned.
When a Diameter server enforces an update to the assigned groups mid- When a Diameter server enforces an update to the assigned groups mid-
session, it sends a Re-Authorization Request (RAR) message to the session, it sends a Re-Authorization Request (RAR) message to the
client identifying the session, for which the session group lists are client identifying the session, for which the session group lists are
to be updated. The client responds with a Re-Authorization Answer to be updated. The client responds with a Re-Authorization Answer
(RAA) message. The client subsequently sends service-specific re- (RAA) message. The client subsequently sends a service-specific re-
authorization request containing one or multiple Session-Group-Info authorization request containing one or multiple Session-Group-Info
AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the
Session-Group-Id AVP identifying the session group to which the Session-Group-Id AVP identifying the session group to which the
session had been previously assigned. The server responds with a session had been previously assigned. The server responds with a
service-specific auth response and includes one or multiple Session- service-specific auth response and includes one or multiple Session-
Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set and Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set and
the Session-Group-Id AVP identifying the session group, to which the the Session-Group-Id AVP identifying the session group, to which the
identified session is to be assigned. With the same response identified session is to be assigned. With the same response
message, the server may send one or multiple Session-Group-Info AVPs message, the server may send one or multiple Session-Group-Info AVPs
with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the
Session-Group-Id AVP identifying the session groups from which the Session-Group-Id AVP identifying the session groups from which the
identified session is to be removed. When server wants to remove the identified session is to be removed. When server wants to remove the
session from all previously assigned session groups, it send at least session from all previously assigned session groups, it sends at
on Session-Group-Info AVP with the response having the least one Session-Group-Info AVP with the response having the
SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id
AVP present. AVP present.
4.3. Deleting a Session Group 4.3. Deleting a Session Group
To delete a session group and release the associated Session-Group-Id To delete a session group and release the associated Session-Group-Id
value, the owner of a session group appends a single Session-Group- value, the owner of a session group appends a single Session-Group-
Info AVP having the SESSION_GROUP_STATUS_IND flag cleared and the Info AVP having the SESSION_GROUP_STATUS_IND flag cleared and the
Session-Group-Id AVP identifying the session group, which is to be Session-Group-Id AVP identifying the session group, which is to be
deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated
skipping to change at page 13, line 8 skipping to change at page 13, line 35
4.4.1. Sending Group Commands 4.4.1. Sending Group Commands
Either Diameter node (client or server) can request the recipient of Either Diameter node (client or server) can request the recipient of
a request to process an associated command for all sessions being a request to process an associated command for all sessions being
assigned to one or multiple groups by identifying these groups in the assigned to one or multiple groups by identifying these groups in the
request. The sender of the request appends for each group, to which request. The sender of the request appends for each group, to which
the command applies, a Session-Group-Info AVP including the Session- the command applies, a Session-Group-Info AVP including the Session-
Group-Id AVP to identify the associated session group. Both, the Group-Id AVP to identify the associated session group. Both, the
SESSION_GROUP_ALLOCATION_ACTION flag as well as the SESSION_GROUP_ALLOCATION_ACTION flag as well as the
SESSION_GROUP_STATUS_IND flag must be set. SESSION_GROUP_STATUS_IND flag MUST be set.
If the CCF of the request mandates a Session-Id AVP, the Session-Id If the CCF of the request mandates a Session-Id AVP, the Session-Id
AVP MUST identify one of the single sessions which is assigned to at AVP MUST identify one of the single sessions which is assigned to at
least one of the groups being identified in the appended Session- least one of the groups being identified in the appended Session-
Group-Id AVPs. Group-Id AVPs.
The sender of the request MUST indicate to the receiver how follow up The sender of the request MUST indicate to the receiver how follow up
message exchanges should be performed by appending a single instance message exchanges should be performed by appending a single instance
of the Group-Response-Action AVP. Even if the request includes of the Group-Response-Action AVP. Even if the request includes
multiple instances of a Session-Group-Info AVP, the request MUST NOT multiple instances of a Session-Group-Info AVP, the request MUST NOT
skipping to change at page 13, line 31 skipping to change at page 14, line 10
a single command for all impacted groups, the sender sets the value a single command for all impacted groups, the sender sets the value
of the Group-Response-Action AVP to ALL_GROUPS (1). If follow up of the Group-Response-Action AVP to ALL_GROUPS (1). If follow up
message exchanges should be performed on a per-group basis in case message exchanges should be performed on a per-group basis in case
multiple groups are identified in the group command, the value of the multiple groups are identified in the group command, the value of the
Group-Response-Action AVP is set to PER_GROUP (2). A value set to Group-Response-Action AVP is set to PER_GROUP (2). A value set to
PER_SESSION (3) indicates to the receiver that all follow up PER_SESSION (3) indicates to the receiver that all follow up
exchanges should be performed using a single message for each exchanges should be performed using a single message for each
impacted session. impacted session.
If the sender sends a request including the Group-Response-Action AVP If the sender sends a request including the Group-Response-Action AVP
set to ALL_GROUPS (1) or PER_GROUP (2), it MUST expect some delays set to ALL_GROUPS (1) or PER_GROUP (2), it MUST expect some delay
before receiving the corresponding answer(s) as the answer(s) will before receiving the corresponding answer(s) as the answer(s) will
only be sent back when the request is processed for all the sessions only be sent back when the request is processed for all the sessions
or all the session of a session group. If the process of the request or all the session of a session group. If the process of the request
is delay-sensitive, the sender SHOULD NOT set the Group-Response- is delay-sensitive, the sender SHOULD NOT set the Group-Response-
Action AVP to ALL_GROUPS (1) or PER_GROUP (2). If the answer can be Action AVP to ALL_GROUPS (1) or PER_GROUP (2). If the answer can be
sent before the complete process of the request for all the sessions sent before the complete process of the request for all the sessions
or if the request timeout timer is high enough, the sender MAY set or if the request timeout timer is high enough, the sender MAY set
the Group-Response-Action AVP to ALL_GROUPS (1) or PER_GROUP (2). the Group-Response-Action AVP to ALL_GROUPS (1) or PER_GROUP (2).
If the sender wants the receiver of the request to process the If the sender wants the receiver of the request to process the
associated command solely for a single session does not append any associated command solely for a single session, the sender does not
group identifier, but identifies the relevant session in the Session- append any group identifier, but identifies the relevant session in
Id AVP. the Session-Id AVP.
4.4.2. Receiving Group Commands 4.4.2. Receiving Group Commands
A Diameter node receiving a request to process a command for a group A Diameter node receiving a request to process a command for a group
of sessions identifies the relevant groups according to the appended of sessions, identifies the relevant groups according to the appended
Session-Group-Id AVP in the Session-Group-Info AVP and processes the Session-Group-Id AVP in the Session-Group-Info AVP and processes the
group command according to the appended Group-Response-Action AVP . group command according to the appended Group-Response-Action AVP .
If the received request identifies multiple groups in multiple If the received request identifies multiple groups in multiple
appended Session-Group-Id AVPs, the receiver should process the appended Session-Group-Id AVPs, the receiver SHOULD process the
associated command for each of these groups. if a session has been associated command for each of these groups. If a session has been
assigned to more than one of the identified groups, the receiver must assigned to more than one of the identified groups, the receiver MUST
process the associated command only once per session. process the associated command only once per session.
The Diameter node receiving a request which requests performing the
command to at least on session group SHOULD perform follow up message
exchanges according to the value identified in the Session-Group-Info
AVP.
4.4.3. Error Handling for Group Commands 4.4.3. Error Handling for Group Commands
When a Diameter node receives a request to process a command for one When a Diameter node receives a request to process a command for one
or more session groups and the result of processing the command is an or more session groups and the result of processing the command is an
error that applies to all sessions in the identified groups, an error that applies to all sessions in the identified groups, an
associated protocol error must be returned to the source of the associated protocol error MUST be returned to the source of the
request. In such case, the sender of the request MUST fall back to request. In such case, the sender of the request MUST fall back to
single-session processing and the session groups, which have been single-session processing and the session groups, which have been
identified in the group command, MUST be deleted according to the identified in the group command, MUST be deleted according to the
procedure described in Section 4.3. procedure described in Section 4.3.
When a Diameter node receives a request to process a command for one When a Diameter node receives a request to process a command for one
or more session groups and the result of processing the command or more session groups and the result of processing the command
succeeds for some sessions identified in one or multiple session succeeds for some sessions identified in one or multiple session
groups, but fails for one or more sessions, the Result-Code AVP in groups, but fails for one or more sessions, the Result-Code AVP in
the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per
Section 7.1.2 of [RFC6733]. In case of limited success, the Section 7.1.2 of [RFC6733]. In case of limited success, the
sessions, for which the processing of the group command failed, MUST sessions, for which the processing of the group command failed, MUST
be identified using a Failed-AVP AVP as per Session 7.5 of [RFC6733]. be identified using a Failed-AVP AVP as per Session 7.5 of [RFC6733].
4.4.4. Single-Session Fallback 4.4.4. Single-Session Fallback
Either Diameter node can fall back to single session operation by Either Diameter node can fall back to single session operation by
ignoring and omitting the optional group session-specific AVPs. ignoring and omitting the optional group session-specific AVPs.
Fallback to single-session operation is performed by processing the Fallback to single-session operation is performed by processing the
Diameter command solely for the session identified in the mandatory Diameter command solely for the session identified in the mandatory
Session-Id AVP. The response to the group command must not identify Session-Id AVP. In such case, the response to the group command MUST
any group but identify solely the single session for which the NOT identify any group but identify solely the single session for
command has been processed. which the command has been processed.
5. Operation with Proxies Agents 5. Operation with Proxy Agents
In case of a present stateful Proxy Agent between a Diameter client In case of a present stateful Proxy Agent between a Diameter client
and a Diameter server, this specification assumes that the Proxy and a Diameter server, this specification assumes that the Proxy
Agent is aware of session groups and session group handling. The Agent is aware of session groups and session group handling. The
Proxy MUST update and maintain consistency of its local session Proxy MUST update and maintain consistency of its local session
states as per the result of the group commands which are operated states as per the result of the group commands which are operated
between a Diameter client and a server. between a Diameter client and a server. In such a case, the Proxy
Agent MUST act as a Diameter server in front of the Diameter client
and MUST act as a Diameter client in front of the Diameter server.
Therefore, the client and server behaviors described in the section 4
applies respectively to the stateful Proxy Agent.
In case a Proxy Agent manipulates session groups, it MUST maintain In case a stateful Proxy Agent manipulates session groups, it MUST
consistency of session groups between a client and a server. This maintain consistency of session groups between a client and a server.
applies to a deployment where the Proxy Agent utilizes session This applies to a deployment where the Proxy Agent utilizes session
grouping and performs group operations with, for example, a Diameter grouping and performs group operations with, for example, a Diameter
server, whereas the Diameter client is not aware of session groups. server, whereas the Diameter client is not aware of session groups.
In such case the Proxy Agent must reflect the states associated with In such case the Proxy Agent must reflect the states associated with
the session groups as individual session operations towards the the session groups as individual session operations towards the
client and ensure the client has a consistent view of each session. client and ensure the client has a consistent view of each session.
The same applies to a deployment where all nodes, the Diameter client The same applies to a deployment where all nodes, the Diameter client
and server, as well as the Proxy Agent are group-aware but the Proxy and server, as well as the Proxy Agent are group-aware but the Proxy
Agent manipulates groups, e.g. to adopt different administrative Agent manipulates groups, e.g. to adopt different administrative
policies that apply to the client's domain and the server's domain. policies that apply to the client's domain and the server's domain.
Stateless Proxy Agents do not maintain any session state (only
transaction state are maintained). Consequently, the notion of
session group is transparent for any stateless Proxy Agent present
between a Diameter client and a Diameter server handling session
groups. Session group related AVPs being defined as optional AVP
should be ignored by stateless Proxy Agents and should not be removed
from the Diameter commands. If they are removed by the Proxy Agent
for any reason, the Diameter client and Diameter server will discover
the absence the related session group AVPs and will fall back to
single-session processing, as described in Section 4.
6. Commands Formatting 6. Commands Formatting
This document does not specify new Diameter commands to enable group This document does not specify new Diameter commands to enable group
operations, but relies on command extensibility capability provided operations, but relies on command extensibility capability provided
by the Diameter Base protocol. This section provides the guidelines by the Diameter Base protocol. This section provides the guidelines
to extend the CCF of existing Diameter commands with optional AVPs to to extend the CCF of existing Diameter commands with optional AVPs to
enable the recipient of the command applying the command to all enable the recipient of the command applying the command to all
sessions associated with the identified group(s). sessions associated with the identified group(s).
6.1. Formatting Example: Group Re-Auth-Request 6.1. Formatting Example: Group Re-Auth-Request
 End of changes. 52 change blocks. 
95 lines changed or deleted 130 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/