< draft-ietf-dime-group-signaling-01.txt   draft-ietf-dime-group-signaling-02.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 July 15, 2013 Intended status: Standards Track October 21, 2013
Expires: January 16, 2014 Expires: April 24, 2014
Diameter Group Signaling Diameter Group Signaling
draft-ietf-dime-group-signaling-01.txt draft-ietf-dime-group-signaling-02.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 January 16, 2014. This Internet-Draft will expire on April 24, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Grouping User Sessions . . . . . . . . . . . . . . . . . . . . 5 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Group assignment at session initiation . . . . . . . . . . 5 3.1. Building and Modifying Session Groups . . . . . . . . . . 5
3.2. Mid-session group assignment modifications . . . . . . . . 5 3.2. Issuing Group Commands . . . . . . . . . . . . . . . . . . 5
3.2.1. Client-initiated group assignment changes . . . . . . 6 4. Grouping User Sessions . . . . . . . . . . . . . . . . . . . . 6
3.2.2. Server-initiated group assignment changes . . . . . . 6 4.1. Group assignment at session initiation . . . . . . . . . . 6
4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 7 4.2. Mid-session group assignment modifications . . . . . . . . 6
4.1. Session Grouping and implicit Capability Discovery . . . . 7 4.2.1. Client-initiated group assignment changes . . . . . . 7
4.2. Performing Group Operations . . . . . . . . . . . . . . . 8 4.2.2. Server-initiated group assignment changes . . . . . . 7
4.2.1. Sending Group Commands . . . . . . . . . . . . . . . . 8 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Receiving Group Commands . . . . . . . . . . . . . . . 8 5.1. Session Grouping . . . . . . . . . . . . . . . . . . . . . 8
4.2.3. Single-Session Fallback . . . . . . . . . . . . . . . 9 5.2. Session Grouping Capability Discovery . . . . . . . . . . 9
4.3. Session Management . . . . . . . . . . . . . . . . . . . . 9 5.2.1. Implicit Capability Discovery . . . . . . . . . . . . 9
4.3.1. Authorization Session State Machine . . . . . . . . . 9 5.2.2. Explicit Capability Discovery . . . . . . . . . . . . 9
5. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 13 5.3. Performing Group Operations . . . . . . . . . . . . . . . 10
5.1. Group Re-Auth-Request . . . . . . . . . . . . . . . . . . 13 5.3.1. Sending Group Commands . . . . . . . . . . . . . . . . 10
6. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 14 5.3.2. Receiving Group Commands . . . . . . . . . . . . . . . 10
6.1. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . . 14 5.3.3. Single-Session Fallback . . . . . . . . . . . . . . . 11
6.2. Session-Group-Action AVP . . . . . . . . . . . . . . . . . 14 5.4. Session Management . . . . . . . . . . . . . . . . . . . . 11
7. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 15 5.4.1. Authorization Session State Machine . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 15
8.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. Group Re-Auth-Request . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . . 16
11. Normative References . . . . . . . . . . . . . . . . . . . . . 19 7.2. Session-Group-Feature-Vector AVP . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . . 16
7.4. Session-Group-Action AVP . . . . . . . . . . . . . . . . . 17
8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
12. Normative References . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
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 5, line 5 skipping to change at page 5, line 5
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 [RFC3588].
3. Grouping User Sessions 3. Use Cases
3.1. Building and Modifying Session Groups
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
characteristics as the profile of other users whose Diameter session
has been added to one or multiple groups. Such similarities can be
for example maximum bandwidth bounds of each user in the a group.
These users may share resources of, e.g., an access multiplexer,
together with other users. Runtime adjustments in the granted
bandwidth bounds or other Quality of Service related attributes can
be accomplished for the whole group by identifying the group in the
Diameter group command.
In case a user's subscription profile changes during runtime, either
node, a Diameter Server or Diameter client, may decide to remove this
user's Diameter session from the session group. The user's Diameter
session can be assigned to a different group, whose adjusted profile
matches the one of the different group. Both groups, the user's
previous group and its new group, will be modified mid-session.
In case of mobile users, a change in the node implementing the
Diameter client can happen, which has impact to a group of sessions a
particular pair of Diameter client and server has in common. Due to
mobility, the mobile user's session may get transferred to a new
Diameter client during runtime without mandating from-scratch
authorization. Such scenario necessitates mid-session modification.
3.2. Issuing Group Commands
A policy decision point may decide to terminate a group of sessions,
e.g. based on previous agreement for temporary authorization to
access a system. All Diameter sessions of associated users with such
temporarily granted access will be added to a single Diameter session
group. After the time limit for the temporary authorization has been
reached, the policy decision point can issue a single Session
Termination Request (STR) to the policy enforcement point. The STR
command identifies the group of Diameter sessions which are to be
terminated. The policy enforcement point treats the STR as group
command and initiates termination of all sessions in the group.
Subsequently, the policy enforcement point confirms successful
termination of these sessions to the policy decision point by sending
a single Session Termination Answer (STA) command which includes the
identifier of the group.
4. Grouping User Sessions
Either Diameter peer may assign a session to a group. Diameter AAA Either Diameter peer may assign a session to a group. Diameter AAA
applications typically assign client and server roles to the Diameter applications typically assign client and server roles to the Diameter
peers. peers.
3.1. Group assignment at session initiation 4.1. Group assignment at session initiation
Assignment of a new session to a group is accomplished by the Assignment of a new session to a group is accomplished by the
Diameter server when requested by the Diameter client. Without being Diameter server when requested by the Diameter client. Without being
explicitly requested by the client, the Diameter server can assign a explicitly requested by the client, the Diameter server can assign a
new session to a server-assigned group based on its own decision. 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 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- server, the server assigns a new session to at least one server-
assigned group. To complement server-assigned grouping, a Diameter assigned group. To complement server-assigned grouping, a Diameter
client can assign a session to a client-assigned group. client can assign a session to a client-assigned group.
skipping to change at page 5, line 46 skipping to change at page 6, line 46
Assuming the user has been successfully authenticated and/or Assuming the user has been successfully authenticated and/or
authorized, the Diameter server responds with service-specific auth authorized, the Diameter server responds with service-specific auth
response, e.g. NASREQ AAA [RFC4005], containing both the client- response, e.g. NASREQ AAA [RFC4005], containing both the client-
assigned group identifiers (if sent with the request) and one or more assigned group identifiers (if sent with the request) and one or more
server-assigned group identifiers. server-assigned group identifiers.
Both peers, the Diameter client and the Diameter server, must keep a Both peers, the Diameter client and the Diameter server, must keep a
list of all group identifiers which identify all client- and server- list of all group identifiers which identify all client- and server-
assigned groups to which the session has been assigned. assigned groups to which the session has been assigned.
3.2. Mid-session group assignment modifications 4.2. Mid-session group assignment modifications
Either Diameter peer may modify the group membership of an active Either Diameter peer may modify the group membership of an active
Diameter session. A Diameter client MAY remove the group(s) assigned Diameter session. A Diameter client MAY remove the group(s) assigned
to the active session by the Diameter server and vice versa. to the active session by the Diameter server and vice versa.
This document does not define a permission model that limits removal This document does not define a permission model that limits removal
of a session from a group by the same peer that added the session to of a session from a group by the same peer that added the session to
the group. However, applications which re-use the commands and the group. However, applications which re-use the commands and
methods defined in this document may impose their own permission methods defined in this document may impose their own permission
model. For example, an application could require that the server model. For example, an application could require that the server
MUST NOT remove a session from a group assigned by the client. MUST NOT remove a session from a group assigned by the client.
3.2.1. Client-initiated group assignment changes 4.2.1. Client-initiated group assignment changes
To update the assigned groups mid-session, a Diameter client sends a To update the assigned groups mid-session, a Diameter client sends a
service specific re-authorization request containing the updated list service specific re-authorization request containing the updated list
of group identifiers. Assuming the user is successfully of group identifiers. Assuming the user is successfully
authenticated and/or authorized, the Diameter server responds with a authenticated and/or authorized, the Diameter server responds with a
service-specific auth response containing the updated list of group service-specific auth response containing the updated list of group
identifiers received in the request. identifiers received in the request.
3.2.2. Server-initiated group assignment changes 4.2.2. Server-initiated group assignment changes
To update the assigned groups mid-session, a Diameter server sends a To update the assigned groups mid-session, a Diameter server sends a
Re-authorization Request (RAR) message requesting re-authorization Re-authorization Request (RAR) message requesting re-authorization
and the client responds with a Re-authorization Answer (RAA) message. and the client responds with a Re-authorization Answer (RAA) message.
The Diameter client sends a service specific re-authorization request The Diameter client sends a service specific re-authorization request
containing the current list of group identifiers and the Diameter containing the current list of group identifiers and the Diameter
server responds with a service-specific auth response containing the server responds with a service-specific auth response containing the
updated list of group identifiers. updated list of group identifiers.
4. Protocol Description 5. Protocol Description
4.1. Session Grouping and implicit Capability Discovery 5.1. Session Grouping
Either Diameter peer, a Diameter client or server, can initiate Either Diameter peer, a Diameter client or server, can initiate
assigning a session to a single or multiple session groups according assigning a session to a single or multiple session groups according
to the procedure described in Section 3. Modification of a group by to the procedure described in Section 4. Modification of a group by
removing or adding a single or multiple user sessions can be removing or adding a single or multiple user sessions can be
initiated and performed at runtime by either Diameter peer. initiated and performed at runtime by either Diameter peer.
A Diameter client as sender of a command for session initiation can A Diameter client as sender of a command for session initiation can
determine one or multiple groups to which the new session should be determine one or multiple groups to which the new session should be
assigned. Each of these groups need to be identified in a separate assigned. Each of these groups need to be identified by a unique
Session-Group-Id AVP as specified in Section 6. In each appended Session-Group-Id contained in a separate Session-Group-Info AVP as
Session-Group-Id AVP which carries a client-assigned group specified in Section 7.
identifier, a flag must indicate that the carried group identifier is
not a server-assigned but a client-assigned one. If the Diameter
client does not determine the group to which the new session should
be assigned, the client can set a flag in an appended
Session-Group-Id AVP to explicitly request the Diameter server as
recipient of the message to assign the new session to one or multiple
groups.
By appending at least one Session-Group-Id AVP, the Diameter client In each appended Session-Group-Info AVP which carries a group
announces its capability to support group operations according to the identifier, the SESSION_GROUP_ALLOCATION_MODE flag of the Session-
specification in this document to the addressed Diameter server. If Group-Feature-Vector AVP MUST be:
the Diameter client supports group operations, it MUST append at
least one Session-Group-Id AVP to announce its capability to support
group operations.
A Diameter server receiving a command for session initiation which o set (1) to indicate that the carried group identifier is a server-
includes at least one Session-Group-Id AVP learns about the sender's assigned group;
capability to support group operations. If a flag in the appended
Session-Group-Id AVPs identifies a client-assigned group, the server
must store the one or multiple identifiers and associate the new
session with these groups.
If a flag in a received Session-Group-Id AVP indicates that the o cleared (0) to indicate that the carried group identifier is a
Diameter client explicitly requests the Diameter server to assign the client-assigned group.
new session to a server-assigned group, the Diameter server should
assign the new session to one or multiple groups. The Diameter
server identifies each of these server-assigned groups in a Session-
Group-Id AVP, which are appended to the response to the received
command. Each of these Session-Group-Id AVPs must indicate in a flag
that the carried identifier is a server-assigned group identifier.
If a flag in a received Session-Group-Id AVP indicates that the A Diameter client can explicitly request the Diameter server as
Diameter client does not explicitly request the Diameter server to recipient of the message to assign the new session to one or multiple
assign the new session to a server-assigned group, the Diameter server-assigned groups by appending a Session-Group-Info AVP with no
server may assign the new session to one or multiple groups. The Session-Group-Id AVP and the Session-Group-Feature-Vector AVP with
Diameter server identifies each of these server-assigned groups in a the SESSION_GROUP_ALLOCATION_MODE flag set (1).
Session-Group-Id AVP, which are appended to the response to the
received command. Each of these Session-Group-Id AVPs must indicate
in a flag that the carried identifier is a server-assigned group
identifier.
By appending at least one Session-Group-Id AVP, the Diameter server If the Diameter server receives a Session-Group-Info AVP with no
announces its capability to support group operations according to the Session-Group-Id AVP and the Session-Group-Feature-Vector AVP with
specification in this document to the addressed Diameter client. the SESSION_GROUP_ALLOCATION_MODE flag set (1), the Diameter server
SHOULD assign the new session to one or multiple server-assigned
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.
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 the carried identifier is a server-
assigned group identifier.
If the Diameter server receives a Session-Group-Info AVP with a
Session-Group-Id AVP and the Session-Group-Feature-Vector AVP with
the SESSION_GROUP_ALLOCATION_MODE flag cleared (0), the server must
store the one or multiple group identifiers and associate the new
session with these client-assigned groups. The Diameter server may
still assign the new session to one or multiple server-assigned
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-Id 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-Id 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.
4.2. Performing Group Operations 5.2. Session Grouping Capability Discovery
4.2.1. Sending Group Commands 5.2.1. Implicit Capability Discovery
By appending at least one Session-Group-Info AVP, the Diameter client
announces its capability to support group operations according to the
specification in this document to the addressed Diameter server. If
the Diameter client supports group operations, it MUST append at
least one Session-Group-Info AVP to announce its capability to
support group operations.
A session-group aware Diameter server receiving a command for session
initiation which includes at least one Session-Group-Info AVP learns
about the sender's capability to support group operations.
By appending at least one Session-Group-Id AVP, the Diameter server
announces its capability to support group operations according to the
specification in this document to the addressed Diameter client.
5.2.2. Explicit Capability Discovery
New Diameter applications may consider support for Diameter session
grouping and for performing group commands during the standardization
process. Such applications provide intrinsic support for the support
of group commands and announce this capability through the assigned
application ID.
5.3. Performing Group Operations
5.3.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-Id AVP and indicates in a flag whether the applies, a Session-Group-Info AVP including the Session-Group-Id AVP
identifier represents a server- or a client-assigned group. If the and indicates in the SESSION_GROUP_ALLOCATION_MODE flag of the
CCF of the request mandates a Session-Id AVP, the Session-Id AVP MUST Session-Group-Feature-Vector AVP whether the identifier represents a
identify a single session which is assigned to at least one of the server- or a client-assigned group. If the CCF of the request
groups being identified in the appended Session-Group-Id AVPs. If mandates a Session-Id AVP, the Session-Id AVP MUST identify a single
the sender wants the receiver of the request to process the 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
message exchanges should be performed by appending a Session-Group-
Action AVP. If the sender wants the receiver to perform follow up
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
follow up message exchanges should be performed on a per-group basis
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 set to PER_SESSION (3) indicates to the receiver that all
follow up exchanges should be performed using a single message for
each impacted session.
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.
4.2.2. Receiving Group Commands 5.3.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. If the received request identifies multiple Session-Group-Id AVP in the Session-Group-Info AVP. If the received
groups in multiple appended Session-Group-Id AVPs, the receiver request identifies multiple groups in multiple appended Session-
should process the associated command for each of these groups. if a Group-Id AVPs, the receiver should process the associated command for
session has been assigned to more than one of the identified groups, each of these groups. if a session has been assigned to more than one
the receiver must process the associated command only once per of the identified groups, the receiver must process the associated
session. command only once per session.
4.2.3. Single-Session Fallback The Diameter peer 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.
5.3.3. 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 and 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.
4.3. Session Management 5.4. Session Management
Editor's note: This first document revision adopts the WG's current Editor's note: This document revision adopts the WG's current view on
view on how Diameter commands can be formatted to enable group how Diameter commands can be formatted to enable group signaling.
signaling. The required change in the formatting and protocol The required change in the formatting and protocol operation has not
operation has not yet been considered in this Section 4.3 , which yet been considered in this Section 5.4 , which still reflects the
still reflects the formatting as per version 0 of this specification. formatting as per version 0 of this specification. The described
The described session state machines still need revision to reflect session state machines still need revision to reflect the generalized
the generalized formatting and the adopted protocol operation. formatting and the adopted protocol operation.
4.3.1. Authorization Session State Machine 5.4.1. Authorization Session State Machine
Section 8.1 in [RFC3588] defines a set of finite state machines, Section 8.1 in [RFC3588] defines a set of finite state machines,
representing the life cycle of Diameter sessions, and which MUST be representing the life cycle of Diameter sessions, and which MUST be
observed by all Diameter implementations that make use of the observed by all Diameter implementations that make use of the
authentication and/or authorization portion of a Diameter authentication and/or authorization portion of a Diameter
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
skipping to change at page 13, line 5 skipping to change at page 15, 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
5. 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 to perform the command to all enable the recipient of the command to perform the command to all
sessions associated with the identified group(s). sessions associated with the identified group(s).
5.1. Group Re-Auth-Request 6.1. Group Re-Auth-Request
A request that one or more groups of users are re-authentication is 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 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) Re-Auth-Request (RAR). The one or multiple Session-Group-Id AVP(s)
identify the associated group(s) for which the group re- identify the associated group(s) for which the group re-
authentication has been requested. The recipient of the group authentication has been requested. The recipient of the group
command initiates re-authentication for all users associated with the command initiates re-authentication for all users associated with the
identified group(s). Furthermore, the sender of the group re- identified group(s). Furthermore, the sender of the group re-
authentication request appends a Session-Group-Action AVP to provide authentication request appends a Session-Group-Action AVP to provide
more information to the receiver of the command about how to more information to the receiver of the command about how to
skipping to change at page 14, line 5 skipping to change at page 16, line 5
{ Auth-Application-Id } { Auth-Application-Id }
{ Re-Auth-Request-Type } { Re-Auth-Request-Type }
[ User-Name ] [ User-Name ]
[ Origin-State-Id ] [ Origin-State-Id ]
* [ Proxy-Info ] * [ Proxy-Info ]
* [ Route-Record ] * [ Route-Record ]
* [ Session-Group-Id ] * [ Session-Group-Id ]
[ Session-Group-Action ] [ Session-Group-Action ]
* [ AVP ] * [ AVP ]
6. Attribute-Value-Pairs (AVP) 7. Attribute-Value-Pairs (AVP)
+--------------------+ +--------------------+
| AVP Flag rules | | AVP Flag rules |
+----+---+------+----+ +----+---+------+----+
AVP | | |SHOULD|MUST| AVP | | |SHOULD|MUST|
Attribute Name Code Value Type |MUST|MAY| NOT | NOT| Attribute Name Code Value Type |MUST|MAY| NOT | NOT|
+---------------------------------------+----+---+------+----+ +-------------------------------------------------+----+---+------+----+
|Session-Group-Id TBD OctetString | | P | | V | |Session-Group-Info TBD1 Grouped | | P | | V |
|Session-Group-Action TBD Enumerated | | 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 AVPs for the Diameter Group Signaling
6.1. Session-Group-Id AVP 7.1. Session-Group-Info AVP
The Session-Group-Id AVP (AVP Code TBD) is of type OctetString and The Session-Group-Info AVP (AVP Code TBD1) is of type Grouped. It
identifies a group of sessions. This uniqueness scope of this AVP is contains the identifier of the session group as well as an indication
specified by the Diameter application which makes use of group of the node responsible for session group identifier assignment.
signaling commands. Session-Group-Info ::= < AVP Header: TBD1 >
< Session-Group-Feature-Vector >
[ Session-Group-Id ]
* [ AVP ]
6.2. Session-Group-Action AVP 7.2. Session-Group-Feature-Vector AVP
The Session-Group-Action AVP (AVP Code TBD) is of type Enumerated and The Session-Group-Feature-Vector AVP (AVP Code TBD2) is of type
specifies how the peer SHOULD issue follow up exchanges in response Unsigned32 and and contains a 32-bit flags field of capabilities
to a command which impacts mulitple sessions. The following values supported by the session-group aware node.
are supported:
ALL_GROUPS (0) 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 Follow up exchanges should be performed with a single message
exchange for all impacted groups. exchange for all impacted groups.
PER_GROUP (1) PER_GROUP (2)
Follow up exchanges should be performed with a message exchange Follow up exchanges should be performed with a message exchange
for each impacted group. for each impacted group.
PER_SESSION (2) PER_SESSION (3)
Follow up exchanges should be performed with a message exchange Follow up exchanges should be performed with a message exchange
for each impacted session. for each impacted session.
7. Result-Code AVP Values 8. Result-Code AVP Values
This section defines new Result-Code [RFC3588] values that MUST be
supported by all Diameter implementations that conform to this
specification.
[Editor's Note: Group specific error values may need to be added This document does not define new Result-Code [RFC3588] values for
here.] 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.
8. IANA Considerations 9. IANA Considerations
This section contains the namespaces that have either been created in This section contains the namespaces that have either been created in
this specification or had their values assigned to existing this specification or had their values assigned to existing
namespaces managed by IANA. namespaces managed by IANA.
8.1. AVP Codes 9.1. AVP Codes
This specification requires IANA to register the following new AVPs This specification requires IANA to register the following new AVPs
from the AVP Code namespace defined in [RFC3588]. from the AVP Code namespace defined in [RFC3588].
o Session-Group-Info
o Session-Group-Feature-Vector
o Session-Group-Id o Session-Group-Id
o Session-Group-Action o Session-Group-Action
The AVPs are defined in Section 6. The AVPs are defined in Section 7.
9. Security Considerations 10. Security Considerations
TODO TODO
10. Acknowledgments 11. Acknowledgments
11. Normative References 12. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005, "Diameter Network Access Server Application", RFC 4005,
August 2005. August 2005.
 End of changes. 49 change blocks. 
145 lines changed or deleted 284 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/