draft-ietf-dime-group-signaling-09.txt   draft-ietf-dime-group-signaling-10.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: March 19, 2018 Expires: July 12, 2018
L. Morand L. Morand
September 15, 2017 January 8, 2018
Diameter Group Signaling Diameter Group Signaling
draft-ietf-dime-group-signaling-09.txt draft-ietf-dime-group-signaling-10.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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 March 19, 2018. This Internet-Draft will expire on July 12, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 8, line 26 skipping to change at page 8, line 26
entry about the group assignment together with a session's state. A entry about the group assignment together with a session's state. A
list of all known session groups should be locally maintained on each list of all known session groups should be locally maintained on each
node, each group pointing to individual sessions being assigned to node, each group pointing to individual sessions being assigned to
the group. A Diameter node MUST also keep a record about sessions, the group. A Diameter node MUST also keep a record about sessions,
which have been assigned to a session group by itself. which have been assigned to a session group by itself.
4.2.1. Group assignment at session initiation 4.2.1. Group assignment at session initiation
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 request, e.g. NASREQ AA-Request client sends a service specific request, e.g. NASREQ AA-Request
[RFC4005], containing one or more session group identifiers. Each of [RFC7155], containing one or more session group identifiers. Each of
these groups MUST be identified by a unique Session-Group-Id these groups MUST be identified by a unique Session-Group-Id
contained in a separate Session-Group-Info AVP as specified in contained in a separate Session-Group-Info AVP as specified in
Section 7. Section 7.
The client may choose one or multiple session groups from a list of The client may choose one or multiple session groups from a list of
existing session groups. Alternatively, the client may decide to existing session groups. Alternatively, the client may decide to
create a new group to which the session is assigned and identify create a new group to which the session is assigned and identify
itself in the <DiameterIdentity> portion of the Session-Group-Id AVP itself in the <DiameterIdentity> portion of the Session-Group-Id AVP
as per Section 7.3 as per Section 7.3
skipping to change at page 9, line 15 skipping to change at page 9, line 15
resources for managing additional groups. When rejected, the session resources for managing additional groups. When rejected, the session
MUST NOT be assigned to any session group. MUST NOT be assigned to any session group.
If the Diameter server accepts the client's request for a group If the Diameter server accepts the client's request for a group
assignment, the server MUST assign the new session to each of the one assignment, the server MUST assign the new session to each of the one
or multiple identified session groups when present in the Session- or multiple identified session groups when present in the Session-
Group-Info AVP. In case one or multiple identified session groups Group-Info AVP. In case one or multiple identified session groups
are not already stored by the server, the server MUST store the new are not already stored by the server, the server MUST store the new
identified group(s) to its local list of known session groups. When identified group(s) to its local list of known session groups. When
sending the response to the client, e.g. a service-specific auth sending the response to the client, e.g. a service-specific auth
response as per NASREQ AA-Answer [RFC4005], the server MUST include response as per NASREQ AA-Answer [RFC7155], the server MUST include
all Session-Group-Info AVPs as received in the client's request. all Session-Group-Info AVPs as received in the client's request.
In addition to the one or multiple session groups identified in the In addition to the one or multiple session groups identified in the
client's request, the server may decide to assign the new session to client's request, the server may decide to assign the new session to
one or multiple additional groups. In such a case, the server MUST one or multiple additional groups. In such a case, the server MUST
add to the response the additional Session-Group-Info AVPs, each add to the response the additional Session-Group-Info AVPs, each
identifying a session group to which the new session is assigned by identifying a session group to which the new session is assigned by
the server. Each of the Session-Group-Info AVP added by the server the server. Each of the Session-Group-Info AVP added by the server
MUST have the SESSION_GROUP_ALLOCATION_ACTION flag set in the MUST have the SESSION_GROUP_ALLOCATION_ACTION flag set in the
Session-Group-Control-Vector AVP set. Session-Group-Control-Vector AVP set.
If the Diameter server rejects the client's request for a group If the Diameter server rejects the client's request for a group
assignment, the server sends the response to the client, e.g. a assignment, the server sends the response to the client, e.g. a
service-specific auth response as per NASREQ AA-Answer [RFC4005], and service-specific auth response as per NASREQ AA-Answer [RFC7155], and
MUST include all Session-Group-Info AVPs as received in the client's MUST include all Session-Group-Info AVPs as received in the client's
request (if any) while clearing the SESSION_GROUP_ALLOCATION_ACTION request (if any) while clearing the SESSION_GROUP_ALLOCATION_ACTION
flag of the Session-Group-Control-Vector AVP. The server MAY accept flag of the Session-Group-Control-Vector AVP. The server MAY accept
the client's request for the identified session but refuse the the client's request for the identified session but refuse the
session's assignment to any session group. The server sends the session's assignment to any session group. The server sends the
response to the client indicating success in the result code. In response to the client indicating success in the result code. In
such case the session is treated as single session without assignment such case the session is treated as single session without assignment
to any session group by the Diameter nodes. to any session group by the Diameter nodes.
If the Diameter server accepts the client's request for a group If the Diameter server accepts the client's request for a group
skipping to change at page 21, line 30 skipping to change at page 21, line 30
thorough review and comments on advanced versions of the WG document, thorough review and comments on advanced versions of the WG document,
which helped a lot to improve 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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005,
DOI 10.17487/RFC4005, August 2005,
<https://www.rfc-editor.org/info/rfc4005>.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733, Ed., "Diameter Base Protocol", RFC 6733,
DOI 10.17487/RFC6733, October 2012, DOI 10.17487/RFC6733, October 2012,
<https://www.rfc-editor.org/info/rfc6733>. <https://www.rfc-editor.org/info/rfc6733>.
[RFC7155] Zorn, G., Ed., "Diameter Network Access Server
Application", RFC 7155, DOI 10.17487/RFC7155, April 2014,
<https://www.rfc-editor.org/info/rfc7155>.
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
transitions related to the processing of the group commands which may transitions related to the processing of the group commands which may
 End of changes. 10 change blocks. 
13 lines changed or deleted 12 lines changed or added

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