--- 1/draft-ietf-dime-group-signaling-09.txt 2018-01-08 07:13:37.693355496 -0800 +++ 2/draft-ietf-dime-group-signaling-10.txt 2018-01-08 07:13:37.773357428 -0800 @@ -1,20 +1,20 @@ Diameter Maintenance and Extensions (DIME) M. Jones Internet-Draft Intended status: Standards Track M. Liebsch -Expires: March 19, 2018 +Expires: July 12, 2018 L. Morand - September 15, 2017 + January 8, 2018 Diameter Group Signaling - draft-ietf-dime-group-signaling-09.txt + draft-ietf-dime-group-signaling-10.txt Abstract In large network deployments, a single Diameter node can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter nodes to apply the same operation to a large group of Diameter sessions concurrently. The Diameter base protocol commands operate on a single session so these use cases could result in many thousands of command exchanges to enforce the same operation on each session in the group. In order to reduce @@ -31,25 +31,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -325,21 +325,21 @@ entry about the group assignment together with a session's state. A list of all known session groups should be locally maintained on each node, each group pointing to individual sessions being assigned to the group. A Diameter node MUST also keep a record about sessions, which have been assigned to a session group by itself. 4.2.1. Group assignment at session initiation To assign a session to a group at session initiation, a Diameter 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 contained in a separate Session-Group-Info AVP as specified in Section 7. The client may choose one or multiple session groups from a list of existing session groups. Alternatively, the client may decide to create a new group to which the session is assigned and identify itself in the portion of the Session-Group-Id AVP as per Section 7.3 @@ -363,35 +363,35 @@ resources for managing additional groups. When rejected, the session MUST NOT be assigned to any session 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 or multiple identified session groups when present in the Session- Group-Info AVP. In case one or multiple identified session groups 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 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. 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 one or multiple additional groups. In such a case, the server MUST add to the response the additional Session-Group-Info AVPs, each 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 MUST have the SESSION_GROUP_ALLOCATION_ACTION flag set in the Session-Group-Control-Vector AVP set. If the Diameter server rejects the client's request for a group 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 request (if any) while clearing the SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control-Vector AVP. The server MAY accept the client's request for the identified session but refuse the session's assignment to any session group. The server sends the response to the client indicating success in the result code. In such case the session is treated as single session without assignment to any session group by the Diameter nodes. If the Diameter server accepts the client's request for a group @@ -940,30 +940,29 @@ thorough review and comments on advanced versions of the WG document, which helped a lot to improve this specification. 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . - [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, - "Diameter Network Access Server Application", RFC 4005, - DOI 10.17487/RFC4005, August 2005, - . - [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, . + [RFC7155] Zorn, G., Ed., "Diameter Network Access Server + Application", RFC 7155, DOI 10.17487/RFC7155, April 2014, + . + Appendix A. Session Management -- Exemplary 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, representing the life cycle of Diameter sessions, and which MUST be observed by all Diameter implementations that make use of the authentication and/or authorization portion of a Diameter application. This section defines, as example, additional state transitions related to the processing of the group commands which may