draft-ietf-dime-group-signaling-00.txt		draft-ietf-dime-group-signaling-01.txt
	Diameter Maintenance and Extensions M. Jones		Diameter Maintenance and M. Jones
	(DIME) June 22, 2012		Extensions (DIME) M. Liebsch
	Internet-Draft		Internet-Draft L. Morand
	Intended status: Standards Track		Intended status: Standards Track July 15, 2013
	Expires: December 24, 2012		Expires: January 16, 2014
	Diameter Group Signaling		Diameter Group Signaling
	draft-ietf-dime-group-signaling-00.txt		draft-ietf-dime-group-signaling-01.txt
	Abstract		Abstract
	In large network deployments, a single Diameter peer can support over		In large network deployments, a single Diameter peer can support over
	a million concurrent Diameter sessions. Recent use cases have		a million concurrent Diameter sessions. Recent use cases have
	revealed the need for Diameter peers to apply the same operation to a		revealed the need for Diameter peers to apply the same operation to a
	large group of Diameter sessions concurrently. The Diameter base		large group of Diameter sessions concurrently. The Diameter base
	protocol commands operate on a single session so these use cases		protocol commands operate on a single session so these use cases
	could result in many thousands of command exchanges 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 December 24, 2012.		This Internet-Draft will expire on January 16, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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. Grouping User Sessions . . . . . . . . . . . . . . . . . . . . 5
	3.1. Group assignment at session initiation . . . . . . . . . . 5		3.1. Group assignment at session initiation . . . . . . . . . . 5
	3.2. Mid-session group assignment modifications . . . . . . . . 5		3.2. Mid-session group assignment modifications . . . . . . . . 5
	3.2.1. Client-initiated group assignment changes . . . . . . 5		3.2.1. Client-initiated group assignment changes . . . . . . 6
	3.2.2. Server-initiated group assignment changes . . . . . . 5		3.2.2. Server-initiated group assignment changes . . . . . . 6
	3.3. Server Initiated Group Re-auth . . . . . . . . . . . . . . 6		4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 7
	3.4. Session Group Termination . . . . . . . . . . . . . . . . 7		4.1. Session Grouping and implicit Capability Discovery . . . . 7
	3.5. Aborting a Group of Sessions . . . . . . . . . . . . . . . 8		4.2. Performing Group Operations . . . . . . . . . . . . . . . 8
	4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 10		4.2.1. Sending Group Commands . . . . . . . . . . . . . . . . 8
	4.1. Session Management . . . . . . . . . . . . . . . . . . . . 10		4.2.2. Receiving Group Commands . . . . . . . . . . . . . . . 8
	4.1.1. Authorization Session State Machine . . . . . . . . . 10		4.2.3. Single-Session Fallback . . . . . . . . . . . . . . . 9
	4.2. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 14		4.3. Session Management . . . . . . . . . . . . . . . . . . . . 9
	4.2.1. Group-Re-Auth-Request . . . . . . . . . . . . . . . . 14		4.3.1. Authorization Session State Machine . . . . . . . . . 9
	4.2.2. Group-Re-Auth-Answer . . . . . . . . . . . . . . . . . 14		5. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 13
	4.2.3. Group-Session-Termination-Request . . . . . . . . . . 15		5.1. Group Re-Auth-Request . . . . . . . . . . . . . . . . . . 13
	4.2.4. Group-Session-Termination-Answer . . . . . . . . . . . 15		6. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 14
	4.2.5. Group-Abort-Session-Request . . . . . . . . . . . . . 16		6.1. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . . 14
	4.2.6. Group-Abort-Session-Answer . . . . . . . . . . . . . . 16		6.2. Session-Group-Action AVP . . . . . . . . . . . . . . . . . 14
	5. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		7. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 15
	5.1. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . . 18		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	5.2. Session-Group-Action AVP . . . . . . . . . . . . . . . . . 18		8.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 16
	6. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 19		9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
	7.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 20		11. Normative References . . . . . . . . . . . . . . . . . . . . . 19
	7.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
	10. Normative References . . . . . . . . . . . . . . . . . . . . . 23
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	In large network deployments, a single Diameter peer can support over		In large network deployments, a single Diameter peer can support over
	a million concurrent Diameter sessions. Recent use cases have		a million concurrent Diameter sessions. Recent use cases have
	revealed the need for Diameter peers to apply the same operation to a		revealed the need for Diameter peers to apply the same operation to a
	large group of Diameter sessions concurrently. For example, a policy		large group of Diameter sessions concurrently. For example, a policy
	decision point may need to modify the authorized quality of service		decision point may need to modify the authorized quality of service
	for all active users having the same type of subscription. The		for all active users having the same type of subscription. The
	Diameter base protocol commands operate on a single session so these		Diameter base protocol commands operate on a single session so these
	use cases could result in many thousands of command exchanges to		use cases could result in many thousands of command exchanges to
	enforce the same operation on each session in the group. In order to		enforce the same operation on each session in the group. In order to
	reduce signaling, it would be desirable to enable bulk operations on		reduce signaling, it would be desirable to enable bulk operations on
	all (or part of) the sessions managed by a Diameter peer using a		all (or part of) the sessions managed by a Diameter peer using a
	single or a few command exchanges.		single or a few command exchanges.
	This document describes a mechanism for grouping Diameter sessions		This document describes mechanisms for grouping Diameter sessions and
	and performing re-authentication, re-authorization, termination and		applying Diameter commands, such as performing re-authentication, re-
	abortion of groups of sessions. This document does not define a new		authorization, termination and abortion of sessions to a group of
	Diameter application. Instead it defines mechanisms, commands and		sessions. This document does not define a new Diameter application.
	AVPs that may be used by any Diameter application that requires		Instead it defines mechanisms, commands and AVPs that may be used by
	management of groups of sessions.		any Diameter application that requires management of groups of
			sessions.
			These mechanisms take the following design goals and features into
			account:
			o Minimal impact to existing applications
			o Extension of existing commands' CCF with optional AVPs to enable
			grouping and group operations
			o Fallback to single session operation
			o Implicit discovery of capability to support grouping and group
			operations
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	This document uses terminology defined [RFC3588].		This document uses terminology defined [RFC3588].
	3. Grouping User Sessions		3. 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. In this document, a Diameter client is a node at the edge of		peers.
	the network that performs access control. A Diameter server is a
	node that performs authentication and/or authorization of the user.
	3.1. Group assignment at session initiation		3.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		To assign a session to a group at session initiation, a Diameter
	client sends a service specific auth request, e.g. NASREQ AAR		client sends a service specific request, e.g. NASREQ AAR [RFC4005],
	[RFC4005], containing zero or more client-assigned group identifiers.		containing one or more group identifiers. The Diameter client can
	Assuming the user is successfully authenticated and/or authorized,		assign the session to a client-assigned group and identify the
	the Diameter server responds with service-specific auth response,		associated group with an appended client-assigned group identifier.
	e.g. NASREQ AAA [RFC4005], containing both the client-assigned group		The client can append multiple client-assigned group identifiers if
	identifiers and zero or more server-assigned group identifiers.		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.
	3.2. Mid-session group assignment modifications		3.2. Mid-session group assignment modifications
	Either Diameter peer may modify the group membership of an active		Either Diameter peer may modify the group membership of an active
	Diameter session. A Diameter client MAY remove the group(s) assigned		Diameter session. A Diameter client MAY remove the group(s) assigned
	to the active session by the Diameter server and vice versa.		to the active session by the Diameter server and vice versa.
	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
	skipping to change at page 6, line 6		skipping to change at page 7, line 5
	3.2.2. Server-initiated group assignment changes		3.2.2. Server-initiated group assignment changes
	To update the assigned groups mid-session, a Diameter server sends a		To update the assigned groups mid-session, a Diameter server sends a
	Re-authorization Request (RAR) message requesting re-authorization		Re-authorization Request (RAR) message requesting re-authorization
	and the client responds with a Re-authorization Answer (RAA) message.		and the client responds with a Re-authorization Answer (RAA) message.
	The Diameter client sends a service specific re-authorization request		The Diameter client sends a service specific re-authorization request
	containing the current list of group identifiers and the Diameter		containing the current list of group identifiers and the Diameter
	server responds with a service-specific auth response containing the		server responds with a service-specific auth response containing the
	updated list of group identifiers.		updated list of group identifiers.
	3.3. Server Initiated Group Re-auth		4. Protocol Description
	This document defines a new Group-Re-Auth-Request/Answer (GRAR/
	GRAA)command exchange which allows a server to initiate a re-
	authentication and/or re-authorization of all services that are
	assigned to one of the groups specified in the Session-Group-Id AVP
	in the request.
	An access device that receives a Group-Re-Auth-Request(GRAR) message
	with Session-Group-Id equal to one of the group assigned to a
	currently active session MUST initiate the type of re-auth specified
	by the Re-Auth-Request-Type AVP in the manner specified by the
	Session-Group-Action AVP if the service supports this particular
	feature. Each Diameter application MUST state whether service-
	initiated group re-authentication and/or re-authorization is
	supported and which Session-Group-Action AVP values are supported for
	re-authorization.
	The Session-Group-Action AVP specifies whether the server requires a
	re-authorization request per session, per group or for all groups.
	For a Re-Auth-Request-Type value of AUTHORIZE_AUTHENTICATE, the
	Session-Group-Action value MUST be PER_SESSION since re-
	authentication MUST be performed per user session.
	For Session-Group-Action values of PER_GROUP or ALL_GROUPS, the re-		4.1. Session Grouping and implicit Capability Discovery
	authorization is accomplished with an application-specifc group re-
	authorization command exchange. This command exchange as well as any
	limitations on which aspects of the service can be modified during a
	re-authorization MUST be defined by the Diameter application.
	If the client is able to perform the requested re-authentication		Either Diameter peer, a Diameter client or server, can initiate
	and/or re-authentication for the sessions assigned to the group(s)		assigning a session to a single or multiple session groups according
	specified in the GRAR, it shall return a GRAA command with the		to the procedure described in Section 3. Modification of a group by
	Result-Code AVP set to DIAMETER_SUCCESS and Session-Group-Id AVP(s)		removing or adding a single or multiple user sessions can be
	indicating the groups for which the GRAR receiver has active sessions		initiated and performed at runtime by either Diameter peer.
	assigned. If there are no sessions assigned to the group(s)
	specified in the GRAR, the Result-Code is set to
	DIAMETER_UNKNOWN_SESSION_ID. If the client is unable to perform the
	requested re-authentication and/or re-authentication, the Result-Code
	is set to DIAMETER_UNABLE_TO_COMPLY.
	Diameter Diameter		A Diameter client as sender of a command for session initiation can
	Client Server		determine one or multiple groups to which the new session should be
	| |		assigned. Each of these groups need to be identified in a separate
	(1)+-------------Svc-Specific-Auth-Request--------------->|		Session-Group-Id AVP as specified in Section 6. In each appended
	| Session-Id=ABC |		Session-Group-Id AVP which carries a client-assigned group
	| |		identifier, a flag must indicate that the carried group identifier is
	(2)|<------------Svc-Specific-Auth-Answer-----------------+		not a server-assigned but a client-assigned one. If the Diameter
	| Session-Id=ABC; Session-Group-Id=XYZ |		client does not determine the group to which the new session should
	| |		be assigned, the client can set a flag in an appended
	(3)+-------------Svc-Specific-Auth-Request--------------->|		Session-Group-Id AVP to explicitly request the Diameter server as
	| Session-Id=DEF |		recipient of the message to assign the new session to one or multiple
	| |		groups.
	(4)|<------------Svc-Specific-Auth-Answer-----------------+
	| Session-Id=DEF; Session-Group-Id=XYZ |
	| |
	(5)|<--------------Group-Re-Auth-Request------------------+
	| Session-Group-Id=XYZ; Session-Group-Action=PER_GROUP |
	| Re-Auth_Request-Type=AUTHORIZE_ONLY |
	| |
	(6)+---------------Group-Re-Auth-Answer------------------>|
	| |
	(7)+----------Svc-Specific-Group-Auth-Request------------>|
	| Session-Group-Id=XYZ |
	| |
	(8)|<---------Svc-Specific-Group-Auth-Answer--------------+
	| Updated Service Specific AVPs |
	| |
	Figure 1: Example: Group Re-authorization		By appending at least one Session-Group-Id 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-Id AVP to announce its capability to support
			group operations.
	In the example above, the Diameter server authorizes two sessions		A Diameter server receiving a command for session initiation which
	(ABC and DEF) and assigns them to a group named XYZ (Session-Group-		includes at least one Session-Group-Id AVP learns about the sender's
	Id=XYZ in steps 2 and 4). Some time later, an event occurs on the		capability to support group operations. If a flag in the appended
	Diameter server which requires it to change one or more of the		Session-Group-Id AVPs identifies a client-assigned group, the server
	service parameters for the sessions assigned to group XYZ. The		must store the one or multiple identifiers and associate the new
	Diameter server sends a Group-Re-Auth-Request (step 5) specifying the		session with these groups.
	impacted group (Session-Group-Id=XYZ) must be re-authorized (Re-Auth-
	Request-Type=AUTHORIZE_ONLY) with a single re-authorize command per
	group (Session-Group-Action=PER_GROUP). The Diameter client
	acknowledges the request (step 6) and issues a service-specific group
	authorization request to retrieve the updated service parameters
	(step 7).
	3.4. Session Group Termination		If a flag in a received Session-Group-Id AVP indicates that the
			Diameter client explicitly requests the Diameter server to assign the
			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.
	This document defines a new Group-Session-Termination-Request/Answer		If a flag in a received Session-Group-Id AVP indicates that the
	(GSTR/GSTA) command exchange which allows a client to communicate to		Diameter client does not explicitly request the Diameter server to
	the server the termination of all sessions that are assigned to one		assign the new session to a server-assigned group, the Diameter
	of the groups specified in the Session-Group-Id AVP in the request.		server may assign the new session to one or multiple groups. The
	The termination of a group of sessions could occur as a result of a		Diameter server identifies each of these server-assigned groups in a
	local action or in reponse to a request to abort one or more groups		Session-Group-Id AVP, which are appended to the response to the
	of sessions.		received command. Each of these Session-Group-Id AVPs must indicate
			in a flag that the carried identifier is a server-assigned group
			identifier.
	FFS: When a client sends an GSTR to a server indicating termination		By appending at least one Session-Group-Id AVP, the Diameter server
	of a specific group, is it indicating termination of the sessions		announces its capability to support group operations according to the
	that the server authorized and that are assigned to the specified		specification in this document to the addressed Diameter client.
	group? Or does imply termination of all sessions on the client that
	are assigned to the specified group?
	Upon receipt of the GSTR, the Diameter Server MUST release all		A Diameter server receiving a command for session initiation which
	resources for the sessions assigned to the group(s) specified in the		includes at least one Session-Group-Id AVP but the server does not
	Session-Group-Id AVP and return a GSTA with the Result-Code set to		understand the semantics of this optional AVP because it does not
	DIAMETER_SUCCESS to acknowledge the successful termination. If there		support group operations according to the specification in this
	are no sessions assigned to the group(s) specified in the GSTR, the		document, MUST ignore the optional group operations specific AVPs and
	Result-Code is set to DIAMETER_UNKNOWN_SESSION_ID. If the server is		proceed with processing the command for a single session.
	unable to perform the session termination, the Result-Code is set to
	DIAMETER_UNABLE_TO_COMPLY.
	3.5. Aborting a Group of Sessions		A Diameter client, which sent a request for session initiation to a
			Diameter server and appended a single or multiple Session-Group-Id
			AVPs but cannot find any Session-Group-Id AVP in the associated
			response from the Diameter server proceeds with processing the
			command for a single session. Furthermore, the client keeps a log to
			remember that the server is not able to perform group operations.
	This document defines a new Group-Abort-Session-Request/Answer (GASR/		4.2. Performing Group Operations
	GASA)command exchange which allows a server to request the
	termination of all sessions that are assigned to one of the groups
	specified in the Session-Group-Id AVP in the request.
	A client that receives an GASR with Session-Group-Id equal to a group		4.2.1. Sending Group Commands
	assigned to a currently active session MAY stop the session. Whether
	the client stops the session or not is implementation- and/or
	configuration-dependent. For example, a client may honor GASRs from
	certain agents only. In any case, the client MUST respond with an
	Group-Abort-Session-Answer, including a Result-Code AVP to indicate
	what action it took.
	If the client is able to perform the requested termination of the		Either Diameter peer can request the recipient of a request to
	sessions assigned to the group(s) specified in the GASR, it shall		process an associated command for all sessions being assigned to one
	return a GASA command with the Result-Code AVP set to		or multiple groups by identifying these groups in the request. The
	DIAMETER_SUCCESS and Session-Group-Id AVP(s) indicating the groups		sender of the request appends for each group, to which the command
	for which the GASR receiver has active sessions assigned. If there		applies, a Session-Group-Id AVP and indicates in a flag whether the
	are no sessions assigned to the group(s) specified in the GASR, the		identifier represents a server- or a client-assigned group. If the
	Result-Code is set to DIAMETER_UNKNOWN_SESSION_ID. If the client is		CCF of the request mandates a Session-Id AVP, the Session-Id AVP MUST
	unable to perform the requested termination for any of the sessions,		identify a single session which is assigned to at least one of the
	the Result-Code is set to DIAMETER_UNABLE_TO_COMPLY.		groups being identified in the appended Session-Group-Id AVPs. If
			the sender wants the receiver of the request to process the
			associated command solely for a single session does not append any
			group identifier, but identifies the relevant session in the
			Session-Id AVP.
	When a client terminates a session upon receipt of a Group-Abort-		4.2.2. Receiving Group Commands
	Session-Request, it MUST issue a session termination request to the
	Diameter server that authorized the service. The Session-Group-
	Action AVP specifies whether the server requires a single session
	termination request per session (with STR message), per group (with
	GSTR message) or for all groups (with GSTR message).
	Diameter Diameter		A Diameter peer receiving a request to process a command for a group
	Client Server		of sessions identifies the relevant groups according to the appended
	| |		Session-Group-Id AVP. If the received request identifies multiple
	(1)+-------------Svc-Specific-Auth-Request--------------->|		groups in multiple appended Session-Group-Id AVPs, the receiver
	| Session-Id=ABC |		should process the associated command for each of these groups. if a
	| |		session has been assigned to more than one of the identified groups,
	(2)|<------------Svc-Specific-Auth-Answer-----------------+		the receiver must process the associated command only once per
	| Session-Id=ABC; Session-Group-Id=XYZ |		session.
	| |
	(3)+-------------Svc-Specific-Auth-Request--------------->|
	| Session-Id=DEF |
	| |
	(4)|<------------Svc-Specific-Auth-Answer-----------------+
	| Session-Id=DEF; Session-Group-Id=XYZ |
	| |
	(5)|<-----------Group-Abort-Session-Request---------------+
	| Session-Group-Id=XYZ; Session-Group-Action=PER_GROUP |
	| |
	(6)+------------Group-Abort-Session-Answer--------------->|
	| |
	(7)+---------Group-Session-Termination-Request----------->|
	| Session-Group-Id=XYZ |
	| |
	(8)|<---------Group-Session-Termination-Answer------------+
	| |
	Figure 2: Example: Aborting a Group of Sessions		4.2.3. Single-Session Fallback
	In the example above, the Diameter server authorizes two sessions		Either Diameter peer, a Diameter client or a Diameter server, can
	(ABC and DEF) and assigns them to a group named XYZ (Session-Group-		fall back to single session operation by ignoring and omitting the
	Id=XYZ in steps 2 and 4). Some time later, an event occurs on the		optional and group session-specific AVPs. Fallback to single-session
	Diameter server which requires it to abort the sessions assigned to		operation is performed by processing the Diameter command solely for
	group XYZ. The Diameter server sends a Group-Abort-Session-Request		the session identified in the mandatory Session-Id AVP. The response
	(step 5) specifying the sessions assigned to the impacted group		to the group command must not identify any group but identify solely
	(Session-Group-Id=XYZ) are to be terminated and a single termination		the single session for which the command has been processed.
	command is to be sent per impacted group (Session-Group-
	Action=PER_GROUP). The Diameter client acknowledges the request with
	a GASA (step 6) and issues a GSTR (step 7) command to release all
	resources for the sessions assigned to the group XYZ. The Diameter
	server acknowledges the termination with a GGSTA (Step 8).
	4. Protocol Description		4.3. Session Management
	4.1. Session Management		Editor's note: This first document revision adopts the WG's current
			view on how Diameter commands can be formatted to enable group
			signaling. The required change in the formatting and protocol
			operation has not yet been considered in this Section 4.3 , which
			still reflects the formatting as per version 0 of this specification.
			The described session state machines still need revision to reflect
			the generalized formatting and the adopted protocol operation.
	4.1.1. Authorization Session State Machine		4.3.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 14, line 5		skipping to change at page 13, 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
	4.2. Commands		5. Commands Formatting
	Editor's Note: The content of this section does not represent working
	group consensus but rather the views of the draft author prior to
	(and post) adoption. Alternative methods for manipulating groups of
	sessions are being considered by the working group and this section
	may be heavily modified or removed in subsequent versions.
	This specification extends the existing RAR, RAA, STR, STA, ASR and
	ASA command ABNFs.
	4.2.1. Group-Re-Auth-Request
	The Group-Re-Auth-Request (GRAR), indicated by the Command-Code set
	to TBD and the message flags' 'R' bit set, may be sent by any server
	to the access device that is providing session service, to request
	that one or more groups of users be re-authenticated and/or re-
	authorized.
	<GRAR> ::= < Diameter Header: TBD, REQ, PXY >
	* { Session-Group-Id }
	{ Origin-Host }
	{ Origin-Realm }
	{ Destination-Realm }
	{ Destination-Host }
	{ Auth-Application-Id }
	{ Re-Auth-Request-Type }
	[ Origin-State-Id ]
	* [ Proxy-Info ]
	* [ Route-Record ]
	[ Session-Group-Action ]
	* [ AVP ]
	4.2.2. Group-Re-Auth-Answer
	The Group-Re-Auth-Answer (GRAA), indicated by the Command-Code set to
	TBD and the message flags' 'R' bit clear, is sent in response to the
	GRAR. The Result-Code AVP MUST be present, and indicates the
	disposition of the request.
	<GRAA> ::= < Diameter Header: TBD, PXY >
	* { Session-Group-Id }
	{ Result-Code }
	{ Origin-Host }
	{ Origin-Realm }
	[ Origin-State-Id ]
	[ Error-Message ]
	[ Error-Reporting-Host ]
	* [ Failed-AVP ]
	* [ Redirect-Host ]
	[ Redirect-Host-Usage ]
	[ Redirect-Host-Cache-Time ]
	* [ Proxy-Info ]
	* [ AVP ]
	4.2.3. Group-Session-Termination-Request
	The Group-Session-Termination-Request (GSTR), indicated by the
	Command-Code set to TBD and the Command Flags' 'R' bit set, is sent
	by the access device to inform the Diameter Server that one or more
	groups of authenticated and/or authorized sessions are being
	terminated.
	<GSTR> ::= < Diameter Header: TBD, REQ, PXY >
	* { Session-Group-Id }
	{ Origin-Host }
	{ Origin-Realm }
	{ Destination-Realm }
	{ Auth-Application-Id }
	{ Termination-Cause }
	[ Destination-Host ]
	* [ Class ]
	[ Origin-State-Id ]
	* [ Proxy-Info ]
	* [ Route-Record ]
	* [ AVP ]
	4.2.4. Group-Session-Termination-Answer
	The Group-Session-Termination-Answer (GSTA), indicated by the
	Command-Code set to TBD and the message flags' 'R' bit clear, is sent
	by the Diameter Server to acknowledge the notification that one or
	more groups of session have been terminated. The Result-Code AVP
	MUST be present, and MAY contain an indication that an error occurred
	while servicing the GSTR.
	<GSTA> ::= < Diameter Header: TBD, PXY >
	* { Session-Group-Id }
	{ Result-Code }
	{ Origin-Host }
	{ Origin-Realm }
	* [ Class ]
	[ Error-Message ]
	[ Error-Reporting-Host ]
	* [ Failed-AVP ]
	[ Origin-State-Id ]
	* [ Redirect-Host ]
	[ Redirect-Host-Usage ]
	[ Redirect-Max-Cache-Time ]
	* [ Proxy-Info ]
	* [ AVP ]
	4.2.5. Group-Abort-Session-Request
	The Group-Abort-Session-Request (GASR), indicated by the Command-Code		This document does not specify new Diameter commands to enable group
	set to TBD and the message flags' 'R' bit set, may be sent by any		operations, but relies on command extensibility capability provided
	server to the access device that is providing session service, to		by the Diameter Base protocol. This section provides the guidelines
	request that the sessions identified by the Session-Group-Id be		to extend the CCF of existing Diameter commands with optional AVPs to
	stopped.		enable the recipient of the command to perform the command to all
			sessions associated with the identified group(s).
	<GASR> ::= < Diameter Header: TBD, REQ, PXY >		5.1. Group Re-Auth-Request
	* { Session-Group-Id }
	{ Origin-Host }
	{ Origin-Realm }
	{ Destination-Realm }
	{ Destination-Host }
	{ Auth-Application-Id }
	[ Origin-State-Id ]
	* [ Proxy-Info ]
	* [ Route-Record ]
	[ Group-Action ]
	* [ AVP ]
	4.2.6. Group-Abort-Session-Answer		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 Group-Abort-Session-Answer (GASA), indicated by the Command-Code		The value of the mandatory Session-Id AVP MUST identify a session
	set to TBD and the message flags' 'R' bit clear, is sent in response		associated with a single user, which is assigned to at least one of
	to the GASR. The Result-Code AVP MUST be present, and indicates the		the groups being identified in the appended Session-Group-Id AVPs.
	disposition of the request.
	<GASA> ::= < Diameter Header: TBD, PXY >		<RAR> ::= < Diameter Header: 258, REQ, PXY >
	* { Session-Group-Id }		< Session-Id >
	{ Result-Code }		{ Origin-Host }
	{ Origin-Host }		{ Origin-Realm }
	{ Origin-Realm }		{ Destination-Realm }
	[ Origin-State-Id ]		{ Destination-Host }
	[ Error-Message ]		{ Auth-Application-Id }
	[ Error-Reporting-Host ]		{ Re-Auth-Request-Type }
	* [ Failed-AVP ]		[ User-Name ]
	* [ Redirect-Host ]		[ Origin-State-Id ]
	[ Redirect-Host-Usage ]		* [ Proxy-Info ]
	[ Redirect-Max-Cache-Time ]		* [ Route-Record ]
	* [ Proxy-Info ]		* [ Session-Group-Id ]
	* [ AVP ]		[ Session-Group-Action ]
			* [ AVP ]
	5. AVPs		6. 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-Id TBD OctetString | | P | | V |
	|Session-Group-Action TBD Enumerated | | P | | V |		|Session-Group-Action TBD Enumerated | | P | | V |
	+---------------------------------------+----+---+------+----+		+---------------------------------------+----+---+------+----+
	AVPs for the Diameter Group Signaling		AVPs for the Diameter Group Signaling
	5.1. Session-Group-Id AVP		6.1. Session-Group-Id AVP
	The Session-Group-Id AVP (AVP Code TBD) is of type OctetString and		The Session-Group-Id AVP (AVP Code TBD) is of type OctetString and
	identifies a group of sessions. This uniqueness scope of this AVP is		identifies a group of sessions. This uniqueness scope of this AVP is
	specified by the Diameter application which makes use of group		specified by the Diameter application which makes use of group
	signaling commands.		signaling commands.
	5.2. Session-Group-Action AVP		6.2. Session-Group-Action AVP
	The Session-Group-Action AVP (AVP Code TBD) is of type Enumerated and		The Session-Group-Action AVP (AVP Code TBD) is of type Enumerated and
	specifies how the peer SHOULD issue follow up exchanges in response		specifies how the peer SHOULD issue follow up exchanges in response
	to a command which impacts mulitple sessions. The following values		to a command which impacts mulitple sessions. The following values
	are supported:		are supported:
	ALL_GROUPS (0)		ALL_GROUPS (0)
	Follow up exchanges should be performed with a single message		Follow up exchanges should be performed with a single message
	exchange for all impacted groups.		exchange for all impacted groups.
	PER_GROUP (1)		PER_GROUP (1)
	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 (2)
	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.
	6. Result-Code AVP Values		7. Result-Code AVP Values
	This section defines new Result-Code [RFC3588] values that MUST be		This section defines new Result-Code [RFC3588] values that MUST be
	supported by all Diameter implementations that conform to this		supported by all Diameter implementations that conform to this
	specification.		specification.
	[Editor's Note: Group specific error values may need to be added		[Editor's Note: Group specific error values may need to be added
	here.]		here.]
	7. IANA Considerations		8. 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.
	7.1. Command Codes		8.1. AVP Codes
	This specification requires IANA to register the following new
	Commands from the Command Code namespace defined in [RFC3588].
	o Group-Re-Auth-Request/Answer
	o Group-Session-Termination-Request/Answer
	o Group-Abort-Session-Request/Answer
	The commands are defined in Section 4.2.
	7.2. 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-Id		o Session-Group-Id
	o Session-Group-Action		o Session-Group-Action
	The AVPs are defined in Section 5.		The AVPs are defined in Section 6.
	8. Security Considerations		9. Security Considerations
	TODO		TODO
	9. Acknowledgments		10. Acknowledgments
	10. Normative References		11. 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.
	Author's Address		Authors' Addresses
	Mark Jones		Mark Jones
	Email: mark@azu.ca		Email: mark@azu.ca
			Marco Liebsch
			Email: marco.liebsch@neclab.eu
			Lionel Morand
			Email: lionel.morand@orange.com
End of changes. 47 change blocks.
	379 lines changed or deleted		233 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/