draft-ietf-dime-group-signaling-02.txt   draft-ietf-dime-group-signaling-03.txt 
Diameter Maintenance and M. Jones Diameter Maintenance and M. Jones
Extensions (DIME) M. Liebsch Extensions (DIME) M. Liebsch
Internet-Draft L. Morand Internet-Draft L. Morand
Intended status: Standards Track October 21, 2013 Intended status: Standards Track February 15, 2014
Expires: April 24, 2014 Expires: August 19, 2014
Diameter Group Signaling Diameter Group Signaling
draft-ietf-dime-group-signaling-02.txt draft-ietf-dime-group-signaling-03.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 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 41 skipping to change at page 1, line 41
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 24, 2014. This Internet-Draft will expire on August 19, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Building and Modifying Session Groups . . . . . . . . . . 5 3.1. Building and Modifying Session Groups . . . . . . . . . . 6
3.2. Issuing Group Commands . . . . . . . . . . . . . . . . . . 5 3.2. Issuing Group Commands . . . . . . . . . . . . . . . . . . 6
4. Grouping User Sessions . . . . . . . . . . . . . . . . . . . . 6 3.3. Permission Model . . . . . . . . . . . . . . . . . . . . . 7
4.1. Group assignment at session initiation . . . . . . . . . . 6 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8
4.2. Mid-session group assignment modifications . . . . . . . . 6 4.1. Session Grouping . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Client-initiated group assignment changes . . . . . . 7 4.1.1. Group assignment at session initiation . . . . . . . . 8
4.2.2. Server-initiated group assignment changes . . . . . . 7 4.1.2. Removing a session from a session group . . . . . . . 10
5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 4.1.3. Mid-session group assignment modifications . . . . . . 11
5.1. Session Grouping . . . . . . . . . . . . . . . . . . . . . 8 4.2. Session Grouping Capability Discovery . . . . . . . . . . 12
5.2. Session Grouping Capability Discovery . . . . . . . . . . 9 4.2.1. Implicit Capability Discovery . . . . . . . . . . . . 12
5.2.1. Implicit Capability Discovery . . . . . . . . . . . . 9 4.2.2. Explicit Capability Discovery . . . . . . . . . . . . 12
5.2.2. Explicit Capability Discovery . . . . . . . . . . . . 9 4.3. Releasing a Session Group Identifier . . . . . . . . . . . 12
5.3. Performing Group Operations . . . . . . . . . . . . . . . 10 4.4. Performing Group Operations . . . . . . . . . . . . . . . 13
5.3.1. Sending Group Commands . . . . . . . . . . . . . . . . 10 4.4.1. Sending Group Commands . . . . . . . . . . . . . . . . 13
5.3.2. Receiving Group Commands . . . . . . . . . . . . . . . 10 4.4.2. Receiving Group Commands . . . . . . . . . . . . . . . 13
5.3.3. Single-Session Fallback . . . . . . . . . . . . . . . 11 4.4.3. Error Handling for Group Commands . . . . . . . . . . 14
5.4. Session Management . . . . . . . . . . . . . . . . . . . . 11 4.4.4. Single-Session Fallback . . . . . . . . . . . . . . . 14
5.4.1. Authorization Session State Machine . . . . . . . . . 11 5. Operation with Proxies Agents . . . . . . . . . . . . . . . . 15
6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 15 6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 16
6.1. 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-Feature-Vector AVP . . . . . . . . . . . . . 16 7.2. Session-Group-Feature-Vector AVP . . . . . . . . . . . . . 17
7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . . 16 7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . . 18
7.4. Session-Group-Action AVP . . . . . . . . . . . . . . . . . 17 7.4. Session-Group-Action AVP . . . . . . . . . . . . . . . . . 18
8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 18 8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
12. Normative References . . . . . . . . . . . . . . . . . . . . . 22 12. Normative References . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Session Management -- Exemplary Session State
Machines . . . . . . . . . . . . . . . . . . . . . . 24
A.1. Authorization Session State Machine . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
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
skipping to change at page 4, line 11 skipping to change at page 5, line 11
o Implicit discovery of capability to support grouping and group o Implicit discovery of capability to support grouping and group
operations 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 [RFC3588]. This document uses terminology defined [RFC6733].
3. Use Cases 3. Protocol Overview
3.1. Building and Modifying Session Groups 3.1. Building and Modifying Session Groups
Client and Server can add a new Diameter session to a group, e.g. in Client and Server can add a new Diameter session to a group, e.g. in
case the subscription profile of the associated user has similar 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 added to one or multiple groups. Such similarities can be has been added to one or multiple groups. Such similarities can be
for example maximum bandwidth bounds of each user in the a group. for example maximum bandwidth bounds of each user in the a group.
These users may share resources of, e.g., an access multiplexer, These users may share resources of, e.g., an access multiplexer,
together with other users. Runtime adjustments in the granted together with other users. Runtime adjustments in the granted
skipping to change at page 6, line 5 skipping to change at page 7, line 5
reached, the policy decision point can issue a single Session reached, the policy decision point can issue a single Session
Termination Request (STR) to the policy enforcement point. The STR Termination Request (STR) to the policy enforcement point. The STR
command identifies the group of Diameter sessions which are to be command identifies the group of Diameter sessions which are to be
terminated. The policy enforcement point treats the STR as group terminated. The policy enforcement point treats the STR as group
command and initiates termination of all sessions in the group. command and initiates termination of all sessions in the group.
Subsequently, the policy enforcement point confirms successful Subsequently, the policy enforcement point confirms successful
termination of these sessions to the policy decision point by sending termination of these sessions to the policy decision point by sending
a single Session Termination Answer (STA) command which includes the a single Session Termination Answer (STA) command which includes the
identifier of the group. identifier of the group.
4. Grouping User Sessions 3.3. Permission Model
Either Diameter peer may assign a session to a group. Diameter AAA
applications typically assign client and server roles to the Diameter
peers.
4.1. Group assignment at session initiation
Assignment of a new session to a group is accomplished by the
Diameter server when requested by the Diameter client. Without being
explicitly requested by the client, the Diameter server can assign a
new session to a server-assigned group based on its own decision.
When a new session is to be assigned to a group by the Diameter
server, the server assigns a new session to at least one server-
assigned group. To complement server-assigned grouping, a Diameter
client can assign a session to a client-assigned group.
To assign a session to a group at session initiation, a Diameter
client sends a service specific request, e.g. NASREQ AAR [RFC4005],
containing one or more group identifiers. The Diameter client can
assign the session to a client-assigned group and identify the
associated group with an appended client-assigned group identifier.
The client can append multiple client-assigned group identifiers if
the client assigns the new session to more than one group. If the
Diameter client does not send a client-assigned group identifier, the
client may receive one or multiple server-assigned group identifiers
in the server's response, which identify the server-assigned groups
to which the new session has been assigned. The Diameter client can
explicitly request the Diameter server to perform grouping of the new
session.
Assuming the user has been successfully authenticated and/or
authorized, the Diameter server responds with service-specific auth
response, e.g. NASREQ AAA [RFC4005], containing both the client-
assigned group identifiers (if sent with the request) and one or more
server-assigned group identifiers.
Both peers, the Diameter client and the Diameter server, must keep a
list of all group identifiers which identify all client- and server-
assigned groups to which the session has been assigned.
4.2. Mid-session group assignment modifications
Either Diameter peer may modify the group membership of an active
Diameter session. A Diameter client MAY remove the group(s) assigned
to the active session by the Diameter server and vice versa.
This document does not define a permission model that limits removal A permission model in the context of this draft defines the
of a session from a group by the same peer that added the session to permission of Diameter nodes to build new session groups, to add/
the group. However, applications which re-use the commands and remove a session to/from a session group and to delete an existing
methods defined in this document may impose their own permission session group.
model. For example, an application could require that the server
MUST NOT remove a session from a group assigned by the client.
4.2.1. Client-initiated group assignment changes This specification follows the most flexible model where both, a
Diameter client and a Diameter server can build a new group and
assign a new identifier to that session group. When a Diameter node
decides to issue a new session group, e.g. to group all sessions
which share certain characteristics, the node must identify itself in
the DiameterIdentity element of the session group identifier
(Section 7.3) as owner of the group. The permission model as per
this specification solely constrains the permission to close a
session group and release the associated identifier to the group
owner.
To update the assigned groups mid-session, a Diameter client sends a Irrespective of the group ownership, as per this specification any
service specific re-authorization request containing the updated list Diameter node has the permission to add/remove a session to/from an
of group identifiers. Assuming the user is successfully existing session group. Also the modification of groups in terms of
authenticated and/or authorized, the Diameter server responds with a moving a session from one session group to a different session group
service-specific auth response containing the updated list of group is permitted to any Diameter node. The enforcement of a more
identifiers received in the request. constrained model is left to the application and implementation,
which must then ensure that relevant Diameter nodes have the same
view of the permission model, either through administrative
configuration or protocol-based capability discovery. Details about
enforcing a more constraint permission model are out of scope of this
specification. For example, a more constrained model could require
that a client MUST NOT remove a session from a group which is owned
by the server.
4.2.2. Server-initiated group assignment changes 4. Protocol Description
To update the assigned groups mid-session, a Diameter server sends a 4.1. Session Grouping
Re-authorization Request (RAR) message requesting re-authorization
and the client responds with a Re-authorization Answer (RAA) message.
The Diameter client sends a service specific re-authorization request
containing the current list of group identifiers and the Diameter
server responds with a service-specific auth response containing the
updated list of group identifiers.
5. Protocol Description Either Diameter peer can initiate assigning a session to a single or
multiple session groups. Modification of a group by removing or
adding a single or multiple user sessions can be initiated and
performed at runtime by either Diameter peer. Diameter AAA
applications typically assign client and server roles to the Diameter
peers, which are referred to as relevant Diameter peers to utilize
session grouping and issue group commands. Section 5 describes
particularities about session grouping and performing group commands
when relay agents or proxies are deployed.
5.1. Session Grouping Diameter peers, which are group-aware, must store and maintain a list
of all session groups to which at least one session, for which the
peer holds a state, is assigned. Along with the group's Session-Id,
a list of Diameter sessions, which are assigned to the group, must be
stored. This specification assumes that a session group is built and
handled between pairs of Diameter nodes. Clients and servers MUST
maintain Diameter state of individual sessions grouped in a session
group.
Either Diameter peer, a Diameter client or server, can initiate 4.1.1. Group assignment at session initiation
assigning a session to a single or multiple session groups according
to the procedure described in Section 4. Modification of a group by
removing or adding a single or multiple user sessions can be
initiated and performed at runtime by either Diameter peer.
A Diameter client as sender of a command for session initiation can To assign a session to a group at session initiation, a Diameter
determine one or multiple groups to which the new session should be client sends a service specific request, e.g. NASREQ AAR [RFC4005],
assigned. Each of these groups need to be identified by a unique containing one or more group identifiers. A Diameter client as
Session-Group-Id contained in a separate Session-Group-Info AVP as sender of a command for session initiation can determine one or
specified in Section 7. multiple groups to which the new session should be assigned. Each of
these groups need to be identified by a unique Session-Group-Id
contained in a separate Session-Group-Info AVP as specified in
Section 7.
In each appended Session-Group-Info AVP which carries a group The client may choose one or multiple sessions from a list of
identifier, the SESSION_GROUP_ALLOCATION_MODE flag of the Session- existing session groups, irrespective of the group ownership.
Group-Feature-Vector AVP MUST be: Alternatively, the client may decide to create a new group and
identify itself in the DiameterIdentity element of the
Group-Session-Id AVP as per Section 7.3
o set (1) to indicate that the carried group identifier is a server- The client MUST set the SESSION_GROUP_ALLOCATION_ACTION of the
assigned group; Session-Group-Feature-Vector AVP in each appended Session-Group-Info
AVP to indicate that the identified session should be added to the
identified session group.
o cleared (0) to indicate that the carried group identifier is a If the Diameter server receives a command request from a Diameter
client-assigned group. client and the command comprises at least one Session-Group-Info AVP
having the SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-
Feature-Vector AVP set, the server must add the new session to each
of the one or multiple identified session groups. In case one or
multiple identified session groups are not know to the server, the
server must add the one or multiple new groups to its locally
maintained list of session groups. When sending the response to the
client, e.g. a service-specific auth response as per NASREQ AAA
[RFC4005], the server must include all Session-Group-Info AVPs as
received in the client's request.
A Diameter client can explicitly request the Diameter server as In addition to the one or multiple session groups identified in the
recipient of the message to assign the new session to one or multiple client's request, the server may decide to add the new session to one
server-assigned groups by appending a Session-Group-Info AVP with no or multiple additional groups. In such case, the server add to the
Session-Group-Id AVP and the Session-Group-Feature-Vector AVP with response additional Session-Group-Info AVPs, each identifying a
the SESSION_GROUP_ALLOCATION_MODE flag set (1). session group, to which the server has assigned the new session.
Each of the Session-Group-Info AVP added by the server, the
SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Feature-
Vector AVP must be set.
If the Diameter server receives a Session-Group-Info AVP with no If the Diameter server receives a command for session initiation from
Session-Group-Id AVP and the Session-Group-Feature-Vector AVP with a Diameter client and the command comprises at least one Session-
the SESSION_GROUP_ALLOCATION_MODE flag set (1), the Diameter server Group-Info AVP, but the one or multiple Session-Group-Info AVP do not
SHOULD assign the new session to one or multiple server-assigned identify any session group to which the session should be assigned,
groups. The Diameter server identifies each of these server-assigned the server may assign the new session to one or multiple session
groups in a Session-Group-Id AVP contained in a Session-Group-Info groups. Each session group, to which the server assigns the new
AVP, which are appended to the response to the received command. session, must be identified in a separate Session-Group-Info AVP
Each of these Session-Group-Info AVPs must have the having the SESSION_GROUP_ALLOCATION_ACTION flag of the associated
SESSION_GROUP_ALLOCATION_MODE flag of the Session-Group-Feature- Session-Group-Vector AVP set.
Vector AVP set to indicate that the carried identifier is a server-
assigned group identifier.
If the Diameter server receives a Session-Group-Info AVP with a If the Diameter client receives a response to its previously issued
Session-Group-Id AVP and the Session-Group-Feature-Vector AVP with request from the server and the response comprises at least one
the SESSION_GROUP_ALLOCATION_MODE flag cleared (0), the server must Session-Group-Info AVP having the SESSION_GROUP_ALLOCATION_ACTION
store the one or multiple group identifiers and associate the new flag of the associated Session-Group-Feature-Vector AVP set, the
session with these client-assigned groups. The Diameter server may client must add the new session to all session groups as identified
still assign the new session to one or multiple server-assigned in the one or multiple Session-Group-Info AVPs.
groups. The Diameter server identifies each of these server-assigned
groups in a Session-Group-Id AVP contained in a Session-Group-Info
AVP, which are appended to the response to the received command, in
addition to the those related to the client-assigned groups received
in the request. Each of these Session-Group-Info AVPs must have the
SESSION_GROUP_ALLOCATION_MODE flag of the Session-Group-Feature-
Vector AVP set to indicate that this carried identifier is a server-
assigned group identifier.
A Diameter server receiving a command for session initiation which A Diameter server receiving a command for session initiation which
includes at least one Session-Group-Info AVP but the server does not includes at least one Session-Group-Info AVP but the server does not
understand the semantics of this optional AVP because it does not understand the semantics of this optional AVP because it does not
support group operations according to the specification in this support group operations according to the specification in this
document, MUST ignore the optional group operations specific AVPs and document, MUST ignore the optional group operations specific AVPs and
proceed with processing the command for a single session. proceed with processing the command for a single session.
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 with processing the response from the Diameter server proceeds with processing the
command for a single session. Furthermore, the client keeps a log to command for a single session. Furthermore, the client keeps a log to
remember that the server is not able to perform group operations. remember that the server is not able to perform group operations.
5.2. Session Grouping Capability Discovery 4.1.2. Removing a session from a session group
5.2.1. Implicit Capability Discovery When a Diameter client decides to remove a session from a particular
session group, the client sends a service-specific re-authorization
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
the session. The session, which is to be removed from a group, is
identified in the Session-Id AVP of the command request. The
SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Feature-
Vector AVP in each Session-Group-Info AVP must be cleared to indicate
removal of the session from the session group identified in the
associated Session-Group-id AVP.
When a Diameter client decides to remove a session from all session
groups, to which the session has been previously assigned, the client
sends a service-specific re-authorization request to the server and
adds a single Session-Group-Info AVP to the request which has the
SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id
AVP omitted. The session, which is to be removed from all groups, to
which the session has been previously assigned, is identified in the
Session-Id AVP of the command request.
If the Diameter server receives a request from the client which has
at least one Session-Group-Info AVP appended with the
SESSION_GROUP_ALLOCATION_ACTION flag cleared, the server must remove
the session from the session group identified in the associated
Session-Group-Id AVP. If the request comprises at least one Session-
Group-info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared
and no Session-Id AVP present, the server must remove the session
from all session groups to which the session has been previously
assigned. The server must include in its response to the requesting
client all Session-Group-Id AVPs as received in the request.
When the Diameter server decides to remove a session from one or
multiple particular session groups or from all session groups to
which the session has been assigned beforehand, the server sends a
Re-Authorization Request (RAR) to the client, indicating the session
in the requests Session-Id AVP. The client sends a Re-Authorization
Answer (RAA) to respond to the server's request. The client
subsequently sends service-specific re-authorization request
containing one or multiple Session-Group-Info AVPs, each indicating a
session group, to which the session had been previously assigned. To
indicate removal of the indicated session from one or multiple
session groups, the server sends a service-specific auth response to
the client, containing a list of Session-Group-Info AVPs with the
SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id
AVP identifying the session group, from which the session should be
removed. The server MAY include to the service-specific auth
response a list of Session-Group-Info AVPs with the
SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP
identifying session groups to which the session remains subscribed.
In case the server decides to remove the identified session from all
session groups, to which the session has been previously assigned,
the server includes in the service-specific auth response at least
one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION
flag cleared and Session-Group-Info AVP absent.
4.1.3. Mid-session group assignment modifications
Either Diameter peer can modify the group membership of an active
Diameter session, irrespective of the group ownership.
To update an assigned group mid-session, a Diameter client sends a
service-specific re-authorization request to the server, containing
one or multiple Session-Group-Info AVPs with the
SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP
present, identifying the session group to which the session should be
added. With the same message, the client may send one or multiple
Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag
cleared and the Session-Group-Id AVP identifying the session group
from which the identified session is to be removed. To remove the
session from all previously assigned session groups, the client
includes at least one Session-Group-Info AVP with the
SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id
AVP present. When the server received the service-specific re-
authorization request, it must update its locally maintained view of
the session groups for the identified session according to the
appended Session-Group-Info AVPs. The server sends a service-
specific auth response to the client containing one or multiple
Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag
set and the Session-Group-Id AVP identifying the new session group to
which the identified session has been added.
When a Diameter server enforces an update to the assigned groups mid-
session, it sends a Re-Authorization Request (RAR) message to the
client identifying the session, for which the session group lists are
to be updated. The client responds with a Re-Authorization Answer
(RAA) message. The client subsequently sends service-specific re-
authorization request containing one or multiple Session-Group-Info
AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the
Session-Group-Id AVP identifying the session group to which the
session had been previously assigned. The server responds with a
service-specific auth response and includes one or multiple Session-
Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set and
the Session-Group-Id AVP identifying the session group, to which the
identified session is to be added. With the same response message,
the server may send one or multiple Session-Group-Info AVPs with the
SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id
AVP identifying the session groups from which the identified session
is to be removed. When server wants to remove the session from all
previously assigned session groups, it send at least on Session-
Group-Info AVP with the response having the
SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id
AVP present.
4.2. Session Grouping Capability Discovery
4.2.1. Implicit Capability Discovery
By appending at least one Session-Group-Info AVP, the Diameter client By appending at least one Session-Group-Info AVP, the Diameter client
announces its capability to support group operations according to the announces its capability to support group operations according to the
specification in this document to the addressed Diameter server. If specification in this document to the addressed Diameter server. If
the Diameter client supports group operations, it MUST append at the Diameter client supports group operations, it MUST append at
least one Session-Group-Info AVP to announce its capability to least one Session-Group-Info AVP to announce its capability to
support group operations. support group operations.
A session-group aware Diameter server receiving a command for session A session-group aware Diameter server receiving a command for session
initiation which includes at least one Session-Group-Info AVP learns initiation which includes at least one Session-Group-Info AVP learns
about the sender's capability to support group operations. about the sender's capability to support group operations.
By appending at least one Session-Group-Id AVP, the Diameter server By appending at least one Session-Group-Id AVP, the Diameter server
announces its capability to support group operations according to the announces its capability to support group operations according to the
specification in this document to the addressed Diameter client. specification in this document to the addressed Diameter client.
5.2.2. Explicit Capability Discovery 4.2.2. 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 support for the support process. Such applications provide intrinsic support for the support
of group commands and announce this capability through the assigned of group commands and announce this capability through the assigned
application ID. application ID.
5.3. Performing Group Operations 4.3. Releasing a Session Group Identifier
5.3.1. Sending Group Commands To close a session group and release the associated Session-Group-Id
value, the owner of a session group appends a single Session-Group-
Info AVP having the SESSION_GROUP_STATUS_IND flag cleared and the
Session-Group-Id AVP identifying the session group, which is to be
closed. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated
Session-Group-Feature-Vector AVP MUST be cleared.
4.4. Performing Group Operations
4.4.1. Sending Group Commands
Either Diameter peer can request the recipient of a request to Either Diameter peer can request the recipient of a request to
process an associated command for all sessions being assigned to one process an associated command for all sessions being assigned to one
or multiple groups by identifying these groups in the request. The or multiple groups by identifying these groups in the request. The
sender of the request appends for each group, to which the command sender of the request appends for each group, to which the command
applies, a Session-Group-Info AVP including the Session-Group-Id AVP applies, a Session-Group-Info AVP including the Session-Group-Id AVP
and indicates in the SESSION_GROUP_ALLOCATION_MODE flag of the to identify the associated session group. Both, the
Session-Group-Feature-Vector AVP whether the identifier represents a SESSION_GROUP_ALLOCATION_ACTION flag as well as the
server- or a client-assigned group. If the CCF of the request SESSION_GROUP_STATUS_IND flag must be set.
mandates a Session-Id AVP, the Session-Id AVP MUST identify a single
session which is assigned to at least one of the groups being If the CCF of the request mandates a Session-Id AVP, the Session-Id
identified in the appended Session-Group-Id AVPs. AVP MUST identify a single session which is assigned to at least one
of the groups being identified in the appended Session-Group-Id AVPs.
The sender of the request can indicate to the receiver how follow up The sender of the request can indicate to the receiver how follow up
message exchanges should be performed by appending a Session-Group- message exchanges should be performed by appending a Session-Group-
Action AVP. If the sender wants the receiver to perform follow up Action AVP. If the sender wants the receiver to perform follow up
exchanges with a single command for all impacted groups, the sender exchanges with a single command for all impacted groups, the sender
sets the value of the Session-Group-Action AVP to ALL_GROUPS (1). If sets the value of the Session-Group-Action AVP to ALL_GROUPS (1). If
follow up message exchanges should be performed on a per-group basis follow up message exchanges should be performed on a per-group basis
in case multiple groups are identified in the group command, the in case multiple groups are identified in the group command, the
value of the Session-Group-Action AVP is set to PER_GROUP (2). A value of the Session-Group-Action AVP is set to PER_GROUP (2). A
value set to PER_SESSION (3) indicates to the receiver that all value set to PER_SESSION (3) indicates to the receiver that all
follow up exchanges should be performed using a single message for follow up exchanges should be performed using a single message for
each impacted session. each impacted session.
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 does not append any
group identifier, but identifies the relevant session in the group identifier, but identifies the relevant session in the
Session-Id AVP. Session-Id AVP.
5.3.2. Receiving Group Commands 4.4.2. Receiving Group Commands
A Diameter peer receiving a request to process a command for a group A Diameter peer 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. If the received Session-Group-Id AVP in the Session-Group-Info AVP. If the received
request identifies multiple groups in multiple appended Session- request identifies multiple groups in multiple appended Session-
Group-Id AVPs, the receiver should process the associated command for Group-Id AVPs, the receiver should process the associated command for
each of these groups. if a session has been assigned to more than one each of these groups. if a session has been assigned to more than one
of the identified groups, the receiver must process the associated of the identified groups, the receiver must process the associated
command only once per session. command only once per session.
The Diameter peer receiving a request which requests performing the The Diameter peer receiving a request which requests performing the
command to at least on session group SHOULD perform follow up message command to at least on session group SHOULD perform follow up message
exchanges according to the value identified in the Session-Group-Info exchanges according to the value identified in the Session-Group-Info
AVP. AVP.
5.3.3. Single-Session Fallback 4.4.3. Error Handling for Group Commands
When a Diameter peer receives a request to process a command for one
or more session groups and the result of processing the command is an
error that applies to all sessions in the identified groups, an
associated protocol error must be returned to the source of the
request. In such case, the sender of the request MUST fall back to
single-session processing and the session groups, which have been
identified in the group command, MUST be closed according to the
procedure described in Section 4.3.
When a Diameter peer receives a request to process a command for one
or more session groups and the result of processing the command
succeeds for some sessions identified in one or multiple session
groups, but fails for one or more sessions, the Result-Code AVP in
the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per
Section 7.1.2 of [RFC6733]. In case of limited success, the
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].
4.4.4. Single-Session Fallback
Either Diameter peer, a Diameter client or a Diameter server, can Either Diameter peer, a Diameter client or a Diameter server, can
fall back to single session operation by ignoring and omitting the fall back to single session operation by ignoring and omitting the
optional group session-specific AVPs. Fallback to single-session optional group session-specific AVPs. Fallback to single-session
operation is performed by processing the Diameter command solely for operation is performed by processing the Diameter command solely for
the session identified in the mandatory Session-Id AVP. The response the session identified in the mandatory Session-Id AVP. The response
to the group command must not identify any group but identify solely to the group command must not identify any group but identify solely
the single session for which the command has been processed. the single session for which the command has been processed.
5.4. Session Management 5. Operation with Proxies Agents
Editor's note: This document revision adopts the WG's current view on This specification assumes in case of a present stateful Proxy Agent
how Diameter commands can be formatted to enable group signaling. between a Diameter client and a Diameter server that the Proxy Agent
The required change in the formatting and protocol operation has not is aware of session groups and session group handling. The Proxy
yet been considered in this Section 5.4 , which still reflects the MUST reflect the state of each session associated with a session
formatting as per version 0 of this specification. The described group according to the result of a group command operated between a
session state machines still need revision to reflect the generalized Diameter client and a server.
formatting and the adopted protocol operation.
5.4.1. Authorization Session State Machine In case a Proxy Agent manipulates session groups, it MUST maintain
consistency of session groups between a client and a server. This
applies to deployment where the Proxy Agent utilizes session grouping
and performing group commands with, for example, a Diameter server,
whereas the Diameter client is not group-aware. The same applies to
deployment where all nodes, the Diameter client and server, as well
as the Proxy Agent are group-aware but the Proxy Agent manipulates
groups, e.g. to adopt different administrative policies that apply to
the client's domain and the server's domain.
Section 8.1 in [RFC3588] defines a set of finite state machines, 6. Commands Formatting
This document does not specify new Diameter commands to enable group
operations, but relies on command extensibility capability provided
by the Diameter Base protocol. This section provides the guidelines
to extend the CCF of existing Diameter commands with optional AVPs to
enable the recipient of the command to perform the command to all
sessions associated with the identified group(s).
6.1. Formatting Example: Group Re-Auth-Request
A request that one or more groups of users are re-authentication is
issued by appending one or multiple Session-Group-Id AVP(s) to the
Re-Auth-Request (RAR). The one or multiple Session-Group-Id AVP(s)
identify the associated group(s) for which the group re-
authentication has been requested. The recipient of the group
command initiates re-authentication for all users associated with the
identified group(s). Furthermore, the sender of the group re-
authentication request appends a Session-Group-Action AVP to provide
more information to the receiver of the command about how to
accomplish the group operation.
The value of the mandatory Session-Id AVP MUST identify a session
associated with a single user, which is assigned to at least one of
the groups being identified in the appended Session-Group-Id AVPs.
<RAR> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
{ Re-Auth-Request-Type }
[ User-Name ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ Session-Group-Id ]
[ Session-Group-Action ]
* [ AVP ]
7. Attribute-Value-Pairs (AVP)
+--------------------+
| AVP Flag rules |
+----+---+------+----+
AVP | | |SHOULD|MUST|
Attribute Name Code Value Type |MUST|MAY| NOT | NOT|
+-------------------------------------------------+----+---+------+----+
|Session-Group-Info TBD1 Grouped | | P | | V |
|Session-Group-Feature-Vector TBD2 Unsigned32 | | P | | V |
|Session-Group-Id TBD3 OctetString | | P | | V |
|Session-Group-Action TBD4 Unsigned32 | | P | | V |
+-------------------------------------------------+----+---+------+----+
AVPs for the Diameter Group Signaling
7.1. Session-Group-Info AVP
The Session-Group-Info AVP (AVP Code TBD1) is of type Grouped. It
contains the identifier of the session group as well as an indication
of the node responsible for session group identifier assignment.
Session-Group-Info ::= < AVP Header: TBD1 >
< Session-Group-Feature-Vector >
[ Session-Group-Id ]
* [ AVP ]
7.2. Session-Group-Feature-Vector AVP
The Session-Group-Feature-Vector AVP (AVP Code TBD2) is of type
Unsigned32 and contains a 32-bit flags field of capabilities
supported by the session-group aware node.
The following capabilities are defined in this document:
SESSION_GROUP_ALLOCATION_ACTION (0x00000001)
This flag indicates the action to be performed for the identified
session. When this flag is set, it indicates that the identified
Diameter session is to be added to the session group as identified
by the Session-Group-Id AVP or the session's assignement to the
session group identified in the Session-Group-Id AVP is still
valid. When the flag is cleared, the identified Diameter session
is to be removed from at least one session group. When the flag
is cleared and the Session-Group-Info AVP identifies a particular
session group in the associated Session-Group-Id AVP, the session
is to be removed solely from the identified session group. When
the flag is cleared and the Session-Group-Info AVP does not
identify a particular session group (Session-Group-Id AVP is
absent), the identified Diameter session is to be removed from all
session groups, to which it has been previously assigned.
SESSION_GROUP_STATUS_IND (0x00000010)
This flag indicates the status of the session group identified in
the associated Session-Group-Id AVP. The flag is set when the
identified session group has just been created or is still active.
If the flag is cleared, the identified session group is closed and
the associated Session-Group-Id is released. If the Session-
Group-Info AVP does not comprise a Session-Group-Id AVP, this flag
is meaningless and MUST be ignored by the receiver.
7.3. Session-Group-Id AVP
The Session-Group-Id AVP (AVP Code TBD3) is of type UTF8String and
identifies a group of Diameter sessions.
The Session-Group-Id MUST be globally and eternally unique, as it is
meant to uniquely identify a group of Diameter sessions without
reference to any other information.
The default format of the Session-Group-id MUST comply to the format
recommended for a Session-Id, as defined in the section 8.8 of the
[RFC6733]. The DiameterIdentity element of the Session-Group-Id MUST
identify the Diameter node, which owns the session group.
7.4. Session-Group-Action AVP
The Session-Group-Action AVP (AVP Code TBD4) is of type Unsigned32
and contains a 32-bit address space representing values indicating
how the peer SHOULD issue follow up exchanges in response to a
command which impacts mulitple sessions. The following values are
defined by this application:
ALL_GROUPS (1)
Follow up exchanges should be performed with a single message
exchange for all impacted groups.
PER_GROUP (2)
Follow up exchanges should be performed with a message exchange
for each impacted group.
PER_SESSION (3)
Follow up exchanges should be performed with a message exchange
for each impacted session.
8. Result-Code AVP Values
This document does not define new Result-Code [RFC6733] values for
existing applications, which are extended to support group commands.
Specification documents of new applications, which will have
intrinsic support for group commands, may specify new Result-Codes.
9. IANA Considerations
This section contains the namespaces that have either been created in
this specification or had their values assigned to existing
namespaces managed by IANA.
9.1. AVP Codes
This specification requires IANA to register the following new AVPs
from the AVP Code namespace defined in [RFC6733].
o Session-Group-Info
o Session-Group-Feature-Vector
o Session-Group-Id
o Session-Group-Action
The AVPs are defined in Section 7.
10. Security Considerations
TODO
11. Acknowledgments
The authors of this document want to thank Ben Campbell and Eric
McMurry for their valuable comments to early versions of this draft.
12. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005,
August 2005.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012.
Appendix A. Session Management -- Exemplary Session State Machines
A.1. Authorization Session State Machine
Section 8.1 in [RFC6733] 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
application. This section defines the additional state transitions application. This section defines the additional state transitions
related to the processing of the new commands which may impact related to the processing of the new commands which may impact
multiple sessions. multiple sessions.
The group membership is session state and therefore only those state The group membership is session state and therefore only those state
machines from [RFC3588] in which the server is maintaining session machines from [RFC6733] in which the server is maintaining session
state are relevant in this document. As in [RFC3588], the term state are relevant in this document. As in [RFC6733], the term
Service-Specific below refers to a message defined in a Diameter Service-Specific below refers to a message defined in a Diameter
application (e.g., Mobile IPv4, NASREQ). application (e.g., Mobile IPv4, NASREQ).
The following state machine is observed by a client when state is The following state machine is observed by a client when state is
maintained on the server. State transitions which are unmodified maintained on the server. State transitions which are unmodified
from [RFC3588] are not repeated here. from [RFC6733] are not repeated here.
A Diameter group command in the following tables is differentiated
from a single-session related command by a preceding 'G'. A Group
Re-Auth Request, which applies to one or multiple session groups, has
been exemplarily described in Section 6.1. Such Group RAR command is
denoted as 'GRAR' in the following table. The same notation applies
to other commands as per [RFC6733].
CLIENT, STATEFUL CLIENT, STATEFUL
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
skipping to change at page 13, line 38 skipping to change at page 26, line 20
Pending Successful service-specific Provide Open Pending Successful service-specific Provide Open
group re-authorization answer service group re-authorization answer service
received. received.
Pending Failed service-specific Discon. Idle Pending Failed service-specific Discon. Idle
group re-authorization answer user/device group re-authorization answer user/device
received. received.
The following state machine is observed by a server when it is The following state machine is observed by a server when it is
maintaining state for the session. State transitions which are maintaining state for the session. State transitions which are
unmodified from [RFC3588] are not repeated here. unmodified from [RFC6733] are not repeated here.
SERVER, STATEFUL SERVER, STATEFUL
State Event Action New State State Event Action New State
--------------------------------------------------------------- ---------------------------------------------------------------
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
skipping to change at page 15, line 5 skipping to change at page 28, line 5
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
6. Commands Formatting
This document does not specify new Diameter commands to enable group
operations, but relies on command extensibility capability provided
by the Diameter Base protocol. This section provides the guidelines
to extend the CCF of existing Diameter commands with optional AVPs to
enable the recipient of the command to perform the command to all
sessions associated with the identified group(s).
6.1. Group Re-Auth-Request
A request that one or more groups of users are re-authentication is
issues by appending one or multiple Session-Group-Id AVP(s) to the
Re-Auth-Request (RAR). The one or multiple Session-Group-Id AVP(s)
identify the associated group(s) for which the group re-
authentication has been requested. The recipient of the group
command initiates re-authentication for all users associated with the
identified group(s). Furthermore, the sender of the group re-
authentication request appends a Session-Group-Action AVP to provide
more information to the receiver of the command about how to
accomplish the group operation.
The value of the mandatory Session-Id AVP MUST identify a session
associated with a single user, which is assigned to at least one of
the groups being identified in the appended Session-Group-Id AVPs.
<RAR> ::= < Diameter Header: 258, REQ, PXY >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ Destination-Host }
{ Auth-Application-Id }
{ Re-Auth-Request-Type }
[ User-Name ]
[ Origin-State-Id ]
* [ Proxy-Info ]
* [ Route-Record ]
* [ Session-Group-Id ]
[ Session-Group-Action ]
* [ AVP ]
7. Attribute-Value-Pairs (AVP)
+--------------------+
| AVP Flag rules |
+----+---+------+----+
AVP | | |SHOULD|MUST|
Attribute Name Code Value Type |MUST|MAY| NOT | NOT|
+-------------------------------------------------+----+---+------+----+
|Session-Group-Info TBD1 Grouped | | P | | V |
|Session-Group-Feature-Vector TBD2 Unsigned32 | | P | | V |
|Session-Group-Id TBD3 OctetString | | P | | V |
|Session-Group-Action TBD4 Unsigned32 | | P | | V |
+-------------------------------------------------+----+---+------+----+
AVPs for the Diameter Group Signaling
7.1. Session-Group-Info AVP
The Session-Group-Info AVP (AVP Code TBD1) is of type Grouped. It
contains the identifier of the session group as well as an indication
of the node responsible for session group identifier assignment.
Session-Group-Info ::= < AVP Header: TBD1 >
< Session-Group-Feature-Vector >
[ Session-Group-Id ]
* [ AVP ]
7.2. Session-Group-Feature-Vector AVP
The Session-Group-Feature-Vector AVP (AVP Code TBD2) is of type
Unsigned32 and and contains a 32-bit flags field of capabilities
supported by the session-group aware node.
The following capabilities are defined in this document:
SESSION_GROUP_ALLOCATION_MODE (0x00000001)
This flag indicates the mode of allocation of session group
identifier. When this flag is set, it indicates that Diameter
server is responsible for the allocation of the session group
identifier. When this flag is not set, it indicates that the
session group identifier is allocated by the client.
7.3. Session-Group-Id AVP
The Session-Group-Id AVP (AVP Code TBD3) is of type UTF8String and
identifies a group of sessions.
The Session-Group-Id MUST be globally and eternally unique, as it is
meant to uniquely identify a group of Diameter sessions without
reference to any other information.
Unless stated otherwise, the default format of the Session-Group-id
SHOULD comply to the format recommended for a Session-Id, as defined
in the section 8.8 of the RFC6733 [RFC6733]. However, the exact
format of the Session-Group-Id MAY be specified by the Diameter
applications which make use of group signaling commands.
7.4. Session-Group-Action AVP
The Session-Group-Action AVP (AVP Code TBD4) is of type Unsigned32
and contains a 32-bit address space representing values indicating
how the peer SHOULD issue follow up exchanges in response to a
command which impacts mulitple sessions. The following values are
defined by this application:
ALL_GROUPS (1)
Follow up exchanges should be performed with a single message
exchange for all impacted groups.
PER_GROUP (2)
Follow up exchanges should be performed with a message exchange
for each impacted group.
PER_SESSION (3)
Follow up exchanges should be performed with a message exchange
for each impacted session.
8. Result-Code AVP Values
This document does not define new Result-Code [RFC3588] values for
existing applications, which are extended to support group commands.
Specification documents of new applications, which will have
intrinsic support for group commands, may specify new Result-Codes.
9. IANA Considerations
This section contains the namespaces that have either been created in
this specification or had their values assigned to existing
namespaces managed by IANA.
9.1. AVP Codes
This specification requires IANA to register the following new AVPs
from the AVP Code namespace defined in [RFC3588].
o Session-Group-Info
o Session-Group-Feature-Vector
o Session-Group-Id
o Session-Group-Action
The AVPs are defined in Section 7.
10. Security Considerations
TODO
11. Acknowledgments
12. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005,
August 2005.
Authors' Addresses Authors' Addresses
Mark Jones Mark Jones
Email: mark@azu.ca Email: mark@azu.ca
Marco Liebsch Marco Liebsch
Email: marco.liebsch@neclab.eu Email: marco.liebsch@neclab.eu
 End of changes. 39 change blocks. 
349 lines changed or deleted 511 lines changed or added

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