draft-ietf-dime-group-signaling-07.txt		draft-ietf-dime-group-signaling-08.txt
	Diameter Maintenance and Extensions (DIME) M. Jones		Diameter Maintenance and Extensions (DIME) M. Jones
	Internet-Draft		Internet-Draft
	Intended status: Standards Track M. Liebsch		Intended status: Standards Track M. Liebsch
	Expires: August 21, 2017		Expires: September 14, 2017
	L. Morand		L. Morand
	February 17, 2017		March 13, 2017
	Diameter Group Signaling		Diameter Group Signaling
	draft-ietf-dime-group-signaling-07.txt		draft-ietf-dime-group-signaling-08.txt
	Abstract		Abstract
	In large network deployments, a single Diameter node can support over		In large network deployments, a single Diameter node can support over
	a million concurrent Diameter sessions. Recent use cases have		a million concurrent Diameter sessions. Recent use cases have
	revealed the need for Diameter nodes to apply the same operation to a		revealed the need for Diameter nodes to apply the same operation to a
	large group of Diameter sessions concurrently. The Diameter base		large group of Diameter sessions concurrently. The Diameter base
	protocol commands operate on a single session so these use cases		protocol commands operate on a single session so these use cases
	could result in many thousands of command exchanges to enforce the		could result in many thousands of command exchanges to enforce the
	same operation on each session in the group. In order to reduce		same operation on each session in the group. In order to reduce
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 21, 2017.		This Internet-Draft will expire on September 14, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 42 ¶		skipping to change at page 2, line 42 ¶
	4.4. Performing Group Operations . . . . . . . . . . . . . . . 13		4.4. Performing Group Operations . . . . . . . . . . . . . . . 13
	4.4.1. Sending Group Commands . . . . . . . . . . . . . . . 13		4.4.1. Sending Group Commands . . . . . . . . . . . . . . . 13
	4.4.2. Receiving Group Commands . . . . . . . . . . . . . . 14		4.4.2. Receiving Group Commands . . . . . . . . . . . . . . 14
	4.4.3. Error Handling for Group Commands . . . . . . . . . . 14		4.4.3. Error Handling for Group Commands . . . . . . . . . . 14
	4.4.4. Single-Session Fallback . . . . . . . . . . . . . . . 15		4.4.4. Single-Session Fallback . . . . . . . . . . . . . . . 15
	5. Operation with Proxy Agents . . . . . . . . . . . . . . . . . 15		5. Operation with Proxy Agents . . . . . . . . . . . . . . . . . 15
	6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 16		6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 16
	6.1. Formatting Example: Group Re-Auth-Request . . . . . . . . 16		6.1. Formatting Example: Group Re-Auth-Request . . . . . . . . 16
	7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 17		7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 17
	7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . 17		7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . 17
	7.2. Session-Group-Control-Vector AVP . . . . . . . . . . . . 17		7.2. Session-Group-Control-Vector AVP . . . . . . . . . . . . 18
	7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . 18		7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . 18
	7.4. Group-Response-Action AVP . . . . . . . . . . . . . . . . 18		7.4. Group-Response-Action AVP . . . . . . . . . . . . . . . . 19
	7.5. Session-Group-Capability-Vector AVP . . . . . . . . . . . 19		7.5. Session-Group-Capability-Vector AVP . . . . . . . . . . . 19
	8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 19		8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 19
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 19		9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 20
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 19		10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
	12. Normative References . . . . . . . . . . . . . . . . . . . . 21		12. Normative References . . . . . . . . . . . . . . . . . . . . 21
	Appendix A. Session Management -- Exemplary Session State		Appendix A. Session Management -- Exemplary Session State
	Machine . . . . . . . . . . . . . . . . . . . . . . 21		Machine . . . . . . . . . . . . . . . . . . . . . . 21
	A.1. Use of groups for the Authorization Session State Machine 21		A.1. Use of groups for the Authorization Session State Machine 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
	1. Introduction		1. Introduction
	In large network deployments, a single Diameter node can support over		In large network deployments, a single Diameter node can support over
	a million concurrent Diameter sessions. Recent use cases have		a million concurrent Diameter sessions. Recent use cases have
	revealed the need for Diameter nodes to apply the same operation to a		revealed the need for Diameter nodes to apply the same operation to a
	large group of Diameter sessions concurrently. For example, a policy		large group of Diameter sessions concurrently. For example, a policy
	decision point may need to modify the authorized quality of service		decision point may need to modify the authorized quality of service
	for all active users having the same type of subscription. The		for all active users having the same type of subscription. The
	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 15, line 5 ¶		skipping to change at page 15, line 5 ¶
	request. In such case, the sender of the request MUST fall back to		request. In such case, the sender of the request MUST fall back to
	single-session processing and the session groups, which have been		single-session processing and the session groups, which have been
	identified in the group command, MUST be deleted according to the		identified in the group command, MUST be deleted according to the
	procedure described in Section 4.3.		procedure described in Section 4.3.
	When a Diameter node receives a request to process a command for one		When a Diameter node receives a request to process a command for one
	or more session groups and the result of processing the command		or more session groups and the result of processing the command
	succeeds for some sessions identified in one or multiple session		succeeds for some sessions identified in one or multiple session
	groups, but fails for one or more sessions, the Result-Code AVP in		groups, but fails for one or more sessions, the Result-Code AVP in
	the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per		the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per
	Section 7.1.2 of [RFC6733]. In case of limited success, the		Section 7.1.2 of [RFC6733].
	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].		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 Section 7.5 of [RFC6733]. The sender of the request MUST fall
			back to single-session operation for each of the identified sessions,
			for which the group command failed. In addition, each of these
			sessions MUST be removed from all session groups to which the group
			command applied. To remove sessions from a session group, the
			Diameter client performs the procedure described in Section 4.2.2.
	4.4.4. Single-Session Fallback		4.4.4. Single-Session Fallback
	Either Diameter node can fall back to single session operation by		Either Diameter node can fall back to single session operation by
	ignoring and omitting the optional group session-specific AVPs.		ignoring and omitting the optional group session-specific AVPs.
	Fallback to single-session operation is performed by processing the		Fallback to single-session operation is performed by processing the
	Diameter command solely for the session identified in the mandatory		Diameter command solely for the session identified in the mandatory
	Session-Id AVP. In such case, the response to the group command MUST		Session-Id AVP. In such case, the response to the group command MUST
	NOT identify any group but identify solely the single session for		NOT identify any group but identify solely the single session for
	which the command has been processed.		which the command has been processed.
	5. Operation with Proxy Agents		5. Operation with Proxy Agents
	In case of a present stateful Proxy Agent between a Diameter client		In case of a present stateful Proxy Agent between a Diameter client
	and a Diameter server, this specification assumes that the Proxy		and a Diameter server, this specification assumes that the Proxy
	Agent is aware of session groups and session group handling. The		Agent is aware of session groups and session group handling. The
	Proxy MUST update and maintain consistency of its local session		Proxy MUST update and maintain consistency of its local session
	states as per the result of the group commands which are operated		states as per the result of the group commands which are operated
	between a Diameter client and a server. In such a case, the Proxy		between a Diameter client and a server. In such case, the Proxy
	Agent MUST act as a Diameter server in front of the Diameter client		Agent MUST act as a Diameter server in front of the Diameter client
	and MUST act as a Diameter client in front of the Diameter server.		and MUST act as a Diameter client in front of the Diameter server.
	Therefore, the client and server behaviors described in the section 4		Therefore, the client and server behavior described in Section 4
	applies respectively to the stateful Proxy Agent.		applies respectively to the stateful Proxy Agent.
	In case a stateful Proxy Agent manipulates session groups, it MUST		In case a stateful Proxy Agent manipulates session groups, it MUST
	maintain consistency of session groups between a client and a server.		maintain consistency of session groups between a client and a server.
	This applies to a deployment where the Proxy Agent utilizes session		This applies to a deployment where the Proxy Agent utilizes session
	grouping and performs group operations with, for example, a Diameter		grouping and performs group operations with, for example, a Diameter
	server, whereas the Diameter client is not aware of session groups.		server, whereas the Diameter client is not aware of session groups.
	In such case the Proxy Agent must reflect the states associated with		In such case the Proxy Agent must reflect the states associated with
	the session groups as individual session operations towards the		the session groups as individual session operations towards the
	client and ensure the client has a consistent view of each session.		client and ensure the client has a consistent view of each session.
	The same applies to a deployment where all nodes, the Diameter client		The same applies to a deployment where all nodes, the Diameter client
	and server, as well as the Proxy Agent are group-aware but the Proxy		and server, as well as the Proxy Agent are group-aware but the Proxy
	Agent manipulates groups, e.g. to adopt different administrative		Agent manipulates groups, e.g. to adopt different administrative
	policies that apply to the client's domain and the server's domain.		policies that apply to the client's domain and the server's domain.
	Stateless Proxy Agents do not maintain any session state (only		Stateless Proxy Agents do not maintain any session state (only
	transaction state are maintained). Consequently, the notion of		transaction state are maintained). Consequently, the notion of
	session group is transparent for any stateless Proxy Agent present		session group is transparent for any stateless Proxy Agent present
	between a Diameter client and a Diameter server handling session		between a Diameter client and a Diameter server handling session
	groups. Session group related AVPs being defined as optional AVP		groups. Session group related AVPs being defined as optional AVP
	should be ignored by stateless Proxy Agents and should not be removed		SHOULD be ignored by stateless Proxy Agents and SHOULD NOT be removed
	from the Diameter commands. If they are removed by the Proxy Agent		from the Diameter commands. If they are removed by the Proxy Agent
	for any reason, the Diameter client and Diameter server will discover		for any reason, the Diameter client and Diameter server will discover
	the absence the related session group AVPs and will fall back to		the absence the related session group AVPs and will fall back to
	single-session processing, as described in Section 4.		single-session processing, as described in Section 4.
	6. Commands Formatting		6. Commands Formatting
	This document does not specify new Diameter commands to enable group		This document does not specify new Diameter commands to enable group
	operations, but relies on command extensibility capability provided		operations, but relies on command extensibility capability provided
	by the Diameter Base protocol. This section provides the guidelines		by the Diameter Base protocol. This section provides the guidelines
	skipping to change at page 20, line 45 ¶		skipping to change at page 21, line 19 ¶
	provided by the Diameter based protocol.		provided by the Diameter based protocol.
	In some cases, a Diameter Proxy agent can act on behalf of a client		In some cases, a Diameter Proxy agent can act on behalf of a client
	or server. In such a case, the security requirements that normally		or server. In such a case, the security requirements that normally
	apply to a client (or a server) apply equally to the Proxy agent.		apply to a client (or a server) apply equally to the Proxy agent.
	11. Acknowledgments		11. Acknowledgments
	The authors of this document want to thank Ben Campbell and Eric		The authors of this document want to thank Ben Campbell and Eric
	McMurry for their valuable comments to early versions of this draft.		McMurry for their valuable comments to early versions of this draft.
	Furthermore, authors thank Steve Donovan for the thorough review and		Furthermore, authors thank Steve Donovan and Mark Bales for the
	comments on the adopted WG document, which helped a lot to improve		thorough review and comments on advanced versions of the WG document,
	this specification.		which helped a lot to improve this specification.
	12. Normative References		12. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[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,
End of changes. 13 change blocks.
	19 lines changed or deleted		26 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/