--- 1/draft-ietf-dime-group-signaling-10.txt 2018-06-11 08:13:34.239831983 -0700 +++ 2/draft-ietf-dime-group-signaling-11.txt 2018-06-11 08:13:35.783868755 -0700 @@ -1,20 +1,20 @@ Diameter Maintenance and Extensions (DIME) M. Jones Internet-Draft Intended status: Standards Track M. Liebsch -Expires: July 12, 2018 +Expires: December 13, 2018 L. Morand - January 8, 2018 + June 11, 2018 Diameter Group Signaling - draft-ietf-dime-group-signaling-10.txt + draft-ietf-dime-group-signaling-11.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,21 +31,21 @@ 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 July 12, 2018. + This Internet-Draft will expire on December 13, 2018. Copyright Notice 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 @@ -82,26 +82,27 @@ 6.1. Formatting Example: Group Re-Auth-Request . . . . . . . . 16 7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 17 7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . 17 7.2. Session-Group-Control-Vector AVP . . . . . . . . . . . . 18 7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . 18 7.4. Group-Response-Action AVP . . . . . . . . . . . . . . . . 19 7.5. Session-Group-Capability-Vector AVP . . . . . . . . . . . 19 8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 20 + 9.2. New Registries . . . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 12. Normative References . . . . . . . . . . . . . . . . . . . . 21 Appendix A. Session Management -- Exemplary Session State - Machine . . . . . . . . . . . . . . . . . . . . . . 21 - A.1. Use of groups for the Authorization Session State Machine 21 + Machine . . . . . . . . . . . . . . . . . . . . . . 22 + A.1. Use of groups for the Authorization Session State Machine 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction 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. For example, a policy decision point may need to modify the authorized quality of service for all active users having the same type of subscription. The @@ -334,21 +335,26 @@ client sends a service specific request, e.g. NASREQ AA-Request [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 + as per Section 7.3. For all assignments of a session to an active + session group made by the client or the server, the + SESSION_GROUP_STATUS_IND flag in the Session-Group-Info AVP, which + identifies the session group, MUST be set. A set + SESSION_GROUP_STATUS_IND flag indicates that the identified session + group has just been created or is still active. The client MUST set the SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control-Vector AVP in each appended Session-Group-Info AVP to indicate that the session contained in the request should be assigned to the identified session group. The client may also indicate in the request that the server is responsible for the assignment of the session in one or multiple sessions owned by the server. In such a case, the client MUST include the Session-Group-Info AVP in the request including the @@ -581,34 +587,36 @@ the command applies, a Session-Group-Info AVP including the Session- Group-Id AVP to identify the associated session group. Both, the SESSION_GROUP_ALLOCATION_ACTION flag as well as the SESSION_GROUP_STATUS_IND flag MUST be set. 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 least one of the groups being identified in the appended Session- Group-Id AVPs. - The sender of the request MUST indicate to the receiver how follow up - message exchanges should be performed by appending a single instance - of the Group-Response-Action AVP. Even if the request includes - multiple instances of a Session-Group-Info AVP, the request MUST NOT - comprise more than a single instance of a Group-Response-Action AVP. - If the sender wants the receiver to perform follow up exchanges with - a single command for all impacted groups, the sender sets the value - of the Group-Response-Action AVP to ALL_GROUPS (1). If follow up - message exchanges should be performed on a per-group basis in case - multiple groups are identified in the group command, the value of the - Group-Response-Action AVP is set to PER_GROUP (2). A value set to - PER_SESSION (3) indicates to the receiver that all follow up - exchanges should be performed using a single message for each - impacted session. + The sender of the request MUST indicate to the receiver how multiple + resulting transactions associated with a group command are to be + treated by appending a single instance of a Group-Response-Action + AVP. When a server sends, as example, a Re-Authorization Request + (RAR) or a service-specific server-initiated request to the client, + it can indicate to the client whether to process the request, after + having sent the RAA to the server, with either sending a single RAR + message for all identified groups (server sets the Group-Response- + Action AVP to ALL_GROUPS (1)), or sending a single RAR message for + each identified group individually (server sets the Group-Response- + Action AVP to PER_GROUP (1)). The server may also request the client + to follow-up with a single RAR message per impacted session (server + sets the Group-Response-Action AVP to PER_SESSION). In such case, + the client sends only one RAR message for an impacted session in case + the session is included in more than one of the identified session + groups. If the sender sends a request including the Group-Response-Action AVP set to ALL_GROUPS (1) or PER_GROUP (2), it MUST expect some delay before receiving the corresponding answer(s) as the answer(s) will only be sent back when the request is processed for all the sessions or all the session of a session group. If the process of the request is delay-sensitive, the sender SHOULD NOT set the Group-Response- Action AVP to ALL_GROUPS (1) or PER_GROUP (2). If the answer can be sent before the complete process of the request for all the sessions or if the request timeout timer is high enough, the sender MAY set @@ -777,21 +785,21 @@ < Session-Group-Control-Vector > [ Session-Group-Id ] * [ AVP ] 7.2. Session-Group-Control-Vector AVP The Session-Group-Control-Vector AVP (AVP Code TBD2) is of type Unsigned32 and contains a 32-bit flags field to control the group assignment at session-group aware nodes. - The following capabilities are defined in this document: + The following control flags are defined in this document: SESSION_GROUP_ALLOCATION_ACTION (0x00000001) This flag indicates the action to be performed for the identified session. When this flag is set, it indicates that the identified Diameter session is to be assigned to the session group as identified by the Session-Group-Id AVP or the session's assignment to the session group identified in the Session-Group-Id AVP is still valid. When the flag is cleared, the identified Diameter session is to be removed from at least one session group. When @@ -826,33 +834,36 @@ recommended for a Session-Id, as defined in the section 8.8 of the [RFC6733]. The portion of the Session-Group-Id MUST identify the Diameter node, which owns the session group. 7.4. Group-Response-Action AVP The Group-Response-Action AVP (AVP Code TBD4) is of type Unsigned32 and contains a 32-bit address space representing values indicating how the node SHOULD issue follow up exchanges in response to a command which impacts multiple sessions. The following values are - defined by this application: + defined by this document: ALL_GROUPS (1) - Follow up exchanges should be performed with a single message - exchange for all impacted groups. + Follow up message exchanges associated with a group command should + be performed with a single message exchange for all impacted + groups. PER_GROUP (2) - Follow up exchanges should be performed with a message exchange - for each impacted group. + Follow up message exchanges associated with a group command should + be performed with a separate message exchange for each impacted + group. PER_SESSION (3) - Follow up exchanges should be performed with a message exchange - for each impacted session. + Follow up message exchanges associated with a group command should + be performed with a separate message exchange for each impacted + session. 7.5. Session-Group-Capability-Vector AVP The Session-Group-Capability-Vector AVP (AVP Code TBD5) is of type Unsigned32 and contains a 32-bit flags field to indicate capabilities in the context of session-group assignment and group operations. The following capabilities are defined in this document: BASE_SESSION_GROUP_CAPABILITY (0x00000001) @@ -883,20 +894,35 @@ o Session-Group-Control-Vector o Session-Group-Id o Group-Response-Action o Session-Group-Capability-Vector The AVPs are defined in Section 7. +9.2. New Registries + + This specification requires IANA to create two registries: + + o Session-Group-Control-Vector AVP registry for control bits with + two initial assignments, which are described in Section 7.2. The + future registration assignment policy is proposed to be + Specification Required. + + o Session-Group-Capability-Vector AVP with one initial assignment, + which is described in Section 7.5. The future registration + assignment policy is proposed to be Standards Action. + + The AVP names can be used as registry names. + 10. Security Considerations The security considerations of the Diameter protocol itself are discussed in [RFC6733]. Use of the AVPs defined in this document MUST take into consideration the security issues and requirements of the Diameter base protocol. In particular, the Session-Group-Info AVP (including the Session-group-Control-Vector and the Session- Group-Id AVPs) should be considered as a security-sensitive AVPs in the same manner than the Session-Id AVP in the Diameter base protocol [RFC6733].