draft-ietf-dime-group-signaling-05.txt   draft-ietf-dime-group-signaling-06.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: January 7, 2016 Expires: September 22, 2016
L. Morand L. Morand
July 6, 2015 March 21, 2016
Diameter Group Signaling Diameter Group Signaling
draft-ietf-dime-group-signaling-05.txt draft-ietf-dime-group-signaling-06.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 January 7, 2016. This Internet-Draft will expire on September 22, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 3, line 6 skipping to change at page 3, line 6
7.5. Session-Group-Capability-Vector AVP . . . . . . . . . . . 18 7.5. Session-Group-Capability-Vector AVP . . . . . . . . . . . 18
8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 18 8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
12. Normative References . . . . . . . . . . . . . . . . . . . . 20 12. Normative References . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Session Management -- Exemplary Session State Appendix A. Session Management -- Exemplary Session State
Machine . . . . . . . . . . . . . . . . . . . . . . 20 Machine . . . . . . . . . . . . . . . . . . . . . . 20
A.1. Use of groups for the Authorization Session State Machine 20 A.1. Use of groups for the Authorization Session State Machine 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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 3, line 44 skipping to change at page 3, line 44
o Minimal impact to existing applications o Minimal impact to existing applications
o Extension of existing commands' Command Code Format (CCF) with o Extension of existing commands' Command Code Format (CCF) with
optional AVPs to enable grouping and group operations optional AVPs to enable grouping and group operations
o Fallback to single session operation o Fallback to single session operation
o Implicit discovery of capability to support grouping and group o Implicit discovery of capability to support grouping and group
operations in case no external mechanism is available to discover a operations in case no external mechanism is available to discover a
Diameter peer's capability to support session grouping and session Diameter peer's capability to support session grouping and session
group operations. 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 [RFC6733]. This document uses terminology defined [RFC6733].
3. Protocol Overview 3. Protocol Overview
skipping to change at page 5, line 10 skipping to change at page 5, line 10
Permission considerations in the context of this draft apply to the Permission considerations in the context of this draft apply to the
permission of Diameter nodes to build new session groups, to assign/ permission of Diameter nodes to build new session groups, to assign/
remove a session to/from a session group and to delete an existing remove a session to/from a session group and to delete an existing
session group. session group.
This specification follows the most flexible model where both, a This specification follows the most flexible model where both, a
Diameter client and a Diameter server can create a new group and Diameter client and a Diameter server can create a new group and
assign a new identifier to that session group. When a Diameter node assign a new identifier to that session group. When a Diameter node
decides to create a new session group, e.g. to group all sessions decides to create a new session group, e.g. to group all sessions
which share certain characteristics, the node builds a session group which share certain characteristics, the node builds a session group
identifier according to the rules described in Section 7.3) and identifier according to the rules described in Section 7.3 and
becomes the owner of the group. This specification does not becomes the owner of the group. This specification does not
constrain the permission to add or remove a session to/from a session constrain the permission to add or remove a session to/from a session
group to the group owner, instead each node can add a session to any group to the group owner, instead each node can add a session to any
known group or remove a session from a group. A session group is known group or remove a session from a group. A session group is
deleted and its identifier released after the last session has been deleted and its identifier released after the last session has been
removed from the session group. Also the modification of groups in removed from the session group. Also the modification of groups in
terms of moving a session from one session group to a different terms of moving a session from one session group to a different
session group is permitted to any Diameter node. A Diameter node can session group is permitted to any Diameter node. A Diameter node can
delete a session group and its group identifier mid-session, delete a session group and its group identifier mid-session,
resulting in individual treatment of the sessions which have been resulting in individual treatment of the sessions which have been
skipping to change at page 6, line 43 skipping to change at page 6, line 43
+-------------------------------------------------+--------+--------+ +-------------------------------------------------+--------+--------+
Default Permission as per this Specification Default Permission as per this Specification
*) Editors' note: The protocol specification in this document does *) Editors' note: The protocol specification in this document does
not consider overruling a node's assignment of a session to a session not consider overruling a node's assignment of a session to a session
group. Here, overruling is to be understood as a node changing the group. Here, overruling is to be understood as a node changing the
group(s) assignment as per the node's request. Group signaling group(s) assignment as per the node's request. Group signaling
enabled applications may take such protocol support and associated enabled applications may take such protocol support and associated
protocol semantics into account in their specification. One protocol semantics into account in their specification. One
exception is adopted in this specifcation, which allows a Diameter exception is adopted in this specification, which allows a Diameter
server to reject a group assignment as per the client's request. server to reject a group assignment as per the client's request.
4. Protocol Description 4. Protocol Description
4.1. Session Grouping Capability Discovery 4.1. Session Grouping Capability Discovery
Diameter nodes should assign a session to a session group and perform Diameter nodes should assign a session to a session group and perform
session group operations with a node only after having ensured that session group operations with a node only after having ensured that
the node announced associated support beforehand. the node announced associated support beforehand.
4.1.1. Explicit Capability Discovery 4.1.1. Explicit Capability Discovery
skipping to change at page 11, line 13 skipping to change at page 11, line 13
Session-Group-Id AVP. If the request comprises at least one Session- Session-Group-Id AVP. If the request comprises at least one Session-
Group-info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared Group-info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared
and no Session-Id AVP present, the server must remove the session and no Session-Id AVP present, the server must remove the session
from all session groups to which the session has been previously from all session groups to which the session has been previously
assigned. The server must include in its response to the requesting assigned. The server must include in its response to the requesting
client all Session-Group-Id AVPs as received in the request. client all Session-Group-Id AVPs as received in the request.
When the Diameter server decides to remove a session from one or When the Diameter server decides to remove a session from one or
multiple particular session groups or from all session groups to multiple particular session groups or from all session groups to
which the session has been assigned beforehand, the server sends a which the session has been assigned beforehand, the server sends a
Re-Authorization Request (RAR) or a service-specific server-intiated Re-Authorization Request (RAR) or a service-specific server-initiated
request to the client, indicating the session in the Session-Id AVP request to the client, indicating the session in the Session-Id AVP
of the request. The client sends a Re-Authorization Answer (RAA) or of the request. The client sends a Re-Authorization Answer (RAA) or
a service-specific answer to respond to the server's request. The a service-specific answer to respond to the server's request. The
client subsequently sends service-specific re-authorization request client subsequently sends service-specific re-authorization request
containing one or multiple Session-Group-Info AVPs, each indicating a containing one or multiple Session-Group-Info AVPs, each indicating a
session group, to which the session had been previously assigned. To session group, to which the session had been previously assigned. To
indicate removal of the indicated session from one or multiple indicate removal of the indicated session from one or multiple
session groups, the server sends a service-specific auth response to session groups, the server sends a service-specific auth response to
the client, containing a list of Session-Group-Info AVPs with the the client, containing a list of Session-Group-Info AVPs with the
SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id
skipping to change at page 12, line 49 skipping to change at page 12, line 49
value, the owner of a session group appends a single Session-Group- value, the owner of a session group appends a single Session-Group-
Info AVP having the SESSION_GROUP_STATUS_IND flag cleared and the Info AVP having the SESSION_GROUP_STATUS_IND flag cleared and the
Session-Group-Id AVP identifying the session group, which is to be Session-Group-Id AVP identifying the session group, which is to be
deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated
Session-Group-Control-Vector AVP MUST be cleared. Session-Group-Control-Vector AVP MUST be cleared.
4.4. Performing Group Operations 4.4. Performing Group Operations
4.4.1. Sending Group Commands 4.4.1. Sending Group Commands
Either Diameter node (lient or server) can request the recipient of a Either Diameter node (client or server) can request the recipient of
request to process an associated command for all sessions being a request to process an associated command for all sessions being
assigned to one or multiple groups by identifying these groups in the assigned to one or multiple groups by identifying these groups in the
request. The sender of the request appends for each group, to which request. The sender of the request appends for each group, to which
the command applies, a Session-Group-Info AVP including the Session- the command applies, a Session-Group-Info AVP including the Session-
Group-Id AVP to identify the associated session group. Both, the Group-Id AVP to identify the associated session group. Both, the
SESSION_GROUP_ALLOCATION_ACTION flag as well as the SESSION_GROUP_ALLOCATION_ACTION flag as well as the
SESSION_GROUP_STATUS_IND flag must be set. SESSION_GROUP_STATUS_IND flag must be set.
If the CCF of the request mandates a Session-Id AVP, the Session-Id If the CCF of the request mandates a Session-Id AVP, the Session-Id
AVP MUST identify one of the single sessions which is assigned to at AVP MUST identify one of the single sessions which is assigned to at
least one of the groups being identified in the appended Session- least one of the groups being identified in the appended Session-
skipping to change at page 20, line 26 skipping to change at page 20, line 26
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 for the thorough review and
comments on the adopted WG document, which helped a lot to improve comments on the adopted WG document, which helped a lot to improve
this specification. 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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<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,
August 2005. DOI 10.17487/RFC4005, August 2005,
<http://www.rfc-editor.org/info/rfc4005>.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012. Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012,
<http://www.rfc-editor.org/info/rfc6733>.
Appendix A. Session Management -- Exemplary Session State Machine Appendix A. Session Management -- Exemplary Session State Machine
A.1. Use of groups for the Authorization Session State Machine A.1. Use of groups for the Authorization Session State Machine
Section 8.1 in [RFC6733] defines a set of finite state machines, 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, as example, additional state application. This section defines, as example, additional state
 End of changes. 14 change blocks. 
16 lines changed or deleted 21 lines changed or added

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