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/