--- 1/draft-ietf-dime-group-signaling-07.txt 2017-03-13 15:13:33.522809703 -0700 +++ 2/draft-ietf-dime-group-signaling-08.txt 2017-03-13 15:13:33.578811029 -0700 @@ -1,20 +1,20 @@ Diameter Maintenance and Extensions (DIME) M. Jones Internet-Draft Intended status: Standards Track M. Liebsch -Expires: August 21, 2017 +Expires: September 14, 2017 L. Morand - February 17, 2017 + March 13, 2017 Diameter Group Signaling - draft-ietf-dime-group-signaling-07.txt + draft-ietf-dime-group-signaling-08.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 http://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 August 21, 2017. + This Internet-Draft will expire on September 14, 2017. Copyright Notice Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -75,34 +75,34 @@ 4.4. Performing Group Operations . . . . . . . . . . . . . . . 13 4.4.1. Sending Group Commands . . . . . . . . . . . . . . . 13 4.4.2. Receiving Group Commands . . . . . . . . . . . . . . 14 4.4.3. Error Handling for Group Commands . . . . . . . . . . 14 4.4.4. Single-Session Fallback . . . . . . . . . . . . . . . 15 5. Operation with Proxy Agents . . . . . . . . . . . . . . . . . 15 6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . 17 + 7.2. Session-Group-Control-Vector 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 8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 19 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 - 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 + 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 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 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 + 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 Diameter base protocol commands operate on a single session so these @@ -640,66 +640,73 @@ request. In such case, the sender of the request MUST fall back to single-session processing and the session groups, which have been identified in the group command, MUST be deleted according to the procedure described in Section 4.3. When a Diameter node receives a request to process a command for one or more session groups and the result of processing the command succeeds for some sessions identified in one or multiple session groups, but fails for one or more sessions, the Result-Code AVP in the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per - Section 7.1.2 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 Session 7.5 of [RFC6733]. + Section 7.1.2 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 Either Diameter node can fall back to single session operation by ignoring and omitting the optional group session-specific AVPs. Fallback to single-session operation is performed by processing the Diameter command solely for the session identified in the mandatory Session-Id AVP. In such case, the response to the group command MUST NOT identify any group but identify solely the single session for which the command has been processed. 5. Operation with Proxy Agents In case of a present stateful Proxy Agent between a Diameter client and a Diameter server, this specification assumes that the Proxy Agent is aware of session groups and session group handling. The Proxy MUST update and maintain consistency of its local session 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 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. In case a stateful Proxy Agent manipulates session groups, it MUST maintain consistency of session groups between a client and a server. This applies to a deployment where the Proxy Agent utilizes session grouping and performs group operations with, for example, a Diameter server, whereas the Diameter client is not aware of session groups. In such case the Proxy Agent must reflect the states associated with the session groups as individual session operations towards the client and ensure the client has a consistent view of each session. 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 Agent manipulates groups, e.g. to adopt different administrative policies that apply to the client's domain and the server's domain. Stateless Proxy Agents do not maintain any session state (only transaction state are maintained). Consequently, the notion of session group is transparent for any stateless Proxy Agent present between a Diameter client and a Diameter server handling session 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 for any reason, the Diameter client and Diameter server will discover the absence the related session group AVPs and will fall back to single-session processing, as described in Section 4. 6. Commands Formatting This document does not specify new Diameter commands to enable group operations, but relies on command extensibility capability provided by the Diameter Base protocol. This section provides the guidelines @@ -922,23 +929,23 @@ provided by the Diameter based protocol. 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 apply to a client (or a server) apply equally to the Proxy agent. 11. Acknowledgments The authors of this document want to thank Ben Campbell and Eric McMurry for their valuable comments to early versions of this draft. - Furthermore, authors thank Steve Donovan for the thorough review and - comments on the adopted WG document, which helped a lot to improve - this specification. + Furthermore, authors thank Steve Donovan and Mark Bales for the + 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,