Diameter Maintenance and M. Jones Extensions (DIME) M. Liebsch Internet-Draft L. Morand Intended status: Standards Track October 21, 2013 Expires: April 24, 2014 Diameter Group Signaling draft-ietf-dime-group-signaling-02.txt Abstract In large network deployments, a single Diameter peer can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter peers 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 signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter peer using a single or a few command exchanges. This document specifies the Diameter protocol extensions to achieve this signaling optimization. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 April 24, 2014. Copyright Notice Copyright (c) 2013 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 Jones, et al. Expires April 24, 2014 [Page 1] Internet-Draft Diameter Group Signaling October 2013 (http://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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Building and Modifying Session Groups . . . . . . . . . . 5 3.2. Issuing Group Commands . . . . . . . . . . . . . . . . . . 5 4. Grouping User Sessions . . . . . . . . . . . . . . . . . . . . 6 4.1. Group assignment at session initiation . . . . . . . . . . 6 4.2. Mid-session group assignment modifications . . . . . . . . 6 4.2.1. Client-initiated group assignment changes . . . . . . 7 4.2.2. Server-initiated group assignment changes . . . . . . 7 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 5.1. Session Grouping . . . . . . . . . . . . . . . . . . . . . 8 5.2. Session Grouping Capability Discovery . . . . . . . . . . 9 5.2.1. Implicit Capability Discovery . . . . . . . . . . . . 9 5.2.2. Explicit Capability Discovery . . . . . . . . . . . . 9 5.3. Performing Group Operations . . . . . . . . . . . . . . . 10 5.3.1. Sending Group Commands . . . . . . . . . . . . . . . . 10 5.3.2. Receiving Group Commands . . . . . . . . . . . . . . . 10 5.3.3. Single-Session Fallback . . . . . . . . . . . . . . . 11 5.4. Session Management . . . . . . . . . . . . . . . . . . . . 11 5.4.1. Authorization Session State Machine . . . . . . . . . 11 6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 15 6.1. Group Re-Auth-Request . . . . . . . . . . . . . . . . . . 15 7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 16 7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . . 16 7.2. Session-Group-Feature-Vector AVP . . . . . . . . . . . . . 16 7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . . 16 7.4. Session-Group-Action AVP . . . . . . . . . . . . . . . . . 17 8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 18 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 12. Normative References . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Jones, et al. Expires April 24, 2014 [Page 2] Internet-Draft Diameter Group Signaling October 2013 1. Introduction In large network deployments, a single Diameter peer can support over a million concurrent Diameter sessions. Recent use cases have revealed the need for Diameter peers 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 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 signaling, it would be desirable to enable bulk operations on all (or part of) the sessions managed by a Diameter peer using a single or a few command exchanges. This document describes mechanisms for grouping Diameter sessions and applying Diameter commands, such as performing re-authentication, re- authorization, termination and abortion of sessions to a group of sessions. This document does not define a new Diameter application. Instead it defines mechanisms, commands and AVPs that may be used by any Diameter application that requires management of groups of sessions. These mechanisms take the following design goals and features into account: o Minimal impact to existing applications o Extension of existing commands' CCF with optional AVPs to enable grouping and group operations o Fallback to single session operation o Implicit discovery of capability to support grouping and group operations Jones, et al. Expires April 24, 2014 [Page 3] Internet-Draft Diameter Group Signaling October 2013 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document uses terminology defined [RFC3588]. Jones, et al. Expires April 24, 2014 [Page 4] Internet-Draft Diameter Group Signaling October 2013 3. Use Cases 3.1. Building and Modifying Session Groups Client and Server can add a new Diameter session to a group, e.g. in case the subscription profile of the associated user has similar characteristics as the profile of other users whose Diameter session has been added to one or multiple groups. Such similarities can be for example maximum bandwidth bounds of each user in the a group. These users may share resources of, e.g., an access multiplexer, together with other users. Runtime adjustments in the granted bandwidth bounds or other Quality of Service related attributes can be accomplished for the whole group by identifying the group in the Diameter group command. In case a user's subscription profile changes during runtime, either node, a Diameter Server or Diameter client, may decide to remove this user's Diameter session from the session group. The user's Diameter session can be assigned to a different group, whose adjusted profile matches the one of the different group. Both groups, the user's previous group and its new group, will be modified mid-session. In case of mobile users, a change in the node implementing the Diameter client can happen, which has impact to a group of sessions a particular pair of Diameter client and server has in common. Due to mobility, the mobile user's session may get transferred to a new Diameter client during runtime without mandating from-scratch authorization. Such scenario necessitates mid-session modification. 3.2. Issuing Group Commands A policy decision point may decide to terminate a group of sessions, e.g. based on previous agreement for temporary authorization to access a system. All Diameter sessions of associated users with such temporarily granted access will be added to a single Diameter session group. After the time limit for the temporary authorization has been reached, the policy decision point can issue a single Session Termination Request (STR) to the policy enforcement point. The STR command identifies the group of Diameter sessions which are to be terminated. The policy enforcement point treats the STR as group command and initiates termination of all sessions in the group. Subsequently, the policy enforcement point confirms successful termination of these sessions to the policy decision point by sending a single Session Termination Answer (STA) command which includes the identifier of the group. Jones, et al. Expires April 24, 2014 [Page 5] Internet-Draft Diameter Group Signaling October 2013 4. Grouping User Sessions Either Diameter peer may assign a session to a group. Diameter AAA applications typically assign client and server roles to the Diameter peers. 4.1. Group assignment at session initiation Assignment of a new session to a group is accomplished by the Diameter server when requested by the Diameter client. Without being explicitly requested by the client, the Diameter server can assign a new session to a server-assigned group based on its own decision. When a new session is to be assigned to a group by the Diameter server, the server assigns a new session to at least one server- assigned group. To complement server-assigned grouping, a Diameter client can assign a session to a client-assigned group. To assign a session to a group at session initiation, a Diameter client sends a service specific request, e.g. NASREQ AAR [RFC4005], containing one or more group identifiers. The Diameter client can assign the session to a client-assigned group and identify the associated group with an appended client-assigned group identifier. The client can append multiple client-assigned group identifiers if the client assigns the new session to more than one group. If the Diameter client does not send a client-assigned group identifier, the client may receive one or multiple server-assigned group identifiers in the server's response, which identify the server-assigned groups to which the new session has been assigned. The Diameter client can explicitly request the Diameter server to perform grouping of the new session. Assuming the user has been successfully authenticated and/or authorized, the Diameter server responds with service-specific auth response, e.g. NASREQ AAA [RFC4005], containing both the client- assigned group identifiers (if sent with the request) and one or more server-assigned group identifiers. Both peers, the Diameter client and the Diameter server, must keep a list of all group identifiers which identify all client- and server- assigned groups to which the session has been assigned. 4.2. Mid-session group assignment modifications Either Diameter peer may modify the group membership of an active Diameter session. A Diameter client MAY remove the group(s) assigned to the active session by the Diameter server and vice versa. This document does not define a permission model that limits removal Jones, et al. Expires April 24, 2014 [Page 6] Internet-Draft Diameter Group Signaling October 2013 of a session from a group by the same peer that added the session to the group. However, applications which re-use the commands and methods defined in this document may impose their own permission model. For example, an application could require that the server MUST NOT remove a session from a group assigned by the client. 4.2.1. Client-initiated group assignment changes To update the assigned groups mid-session, a Diameter client sends a service specific re-authorization request containing the updated list of group identifiers. Assuming the user is successfully authenticated and/or authorized, the Diameter server responds with a service-specific auth response containing the updated list of group identifiers received in the request. 4.2.2. Server-initiated group assignment changes To update the assigned groups mid-session, a Diameter server sends a Re-authorization Request (RAR) message requesting re-authorization and the client responds with a Re-authorization Answer (RAA) message. The Diameter client sends a service specific re-authorization request containing the current list of group identifiers and the Diameter server responds with a service-specific auth response containing the updated list of group identifiers. Jones, et al. Expires April 24, 2014 [Page 7] Internet-Draft Diameter Group Signaling October 2013 5. Protocol Description 5.1. Session Grouping Either Diameter peer, a Diameter client or server, can initiate assigning a session to a single or multiple session groups according to the procedure described in Section 4. Modification of a group by removing or adding a single or multiple user sessions can be initiated and performed at runtime by either Diameter peer. A Diameter client as sender of a command for session initiation can determine one or multiple groups to which the new session should be assigned. Each of these groups need to be identified by a unique Session-Group-Id contained in a separate Session-Group-Info AVP as specified in Section 7. In each appended Session-Group-Info AVP which carries a group identifier, the SESSION_GROUP_ALLOCATION_MODE flag of the Session- Group-Feature-Vector AVP MUST be: o set (1) to indicate that the carried group identifier is a server- assigned group; o cleared (0) to indicate that the carried group identifier is a client-assigned group. A Diameter client can explicitly request the Diameter server as recipient of the message to assign the new session to one or multiple server-assigned groups by appending a Session-Group-Info AVP with no Session-Group-Id AVP and the Session-Group-Feature-Vector AVP with the SESSION_GROUP_ALLOCATION_MODE flag set (1). If the Diameter server receives a Session-Group-Info AVP with no Session-Group-Id AVP and the Session-Group-Feature-Vector AVP with the SESSION_GROUP_ALLOCATION_MODE flag set (1), the Diameter server SHOULD assign the new session to one or multiple server-assigned groups. The Diameter server identifies each of these server-assigned groups in a Session-Group-Id AVP contained in a Session-Group-Info AVP, which are appended to the response to the received command. Each of these Session-Group-Info AVPs must have the SESSION_GROUP_ALLOCATION_MODE flag of the Session-Group-Feature- Vector AVP set to indicate that the carried identifier is a server- assigned group identifier. If the Diameter server receives a Session-Group-Info AVP with a Session-Group-Id AVP and the Session-Group-Feature-Vector AVP with the SESSION_GROUP_ALLOCATION_MODE flag cleared (0), the server must store the one or multiple group identifiers and associate the new Jones, et al. Expires April 24, 2014 [Page 8] Internet-Draft Diameter Group Signaling October 2013 session with these client-assigned groups. The Diameter server may still assign the new session to one or multiple server-assigned groups. The Diameter server identifies each of these server-assigned groups in a Session-Group-Id AVP contained in a Session-Group-Info AVP, which are appended to the response to the received command, in addition to the those related to the client-assigned groups received in the request. Each of these Session-Group-Info AVPs must have the SESSION_GROUP_ALLOCATION_MODE flag of the Session-Group-Feature- Vector AVP set to indicate that this carried identifier is a server- assigned group identifier. A Diameter server receiving a command for session initiation which includes at least one Session-Group-Info AVP but the server does not understand the semantics of this optional AVP because it does not support group operations according to the specification in this document, MUST ignore the optional group operations specific AVPs and proceed with processing the command for a single session. A Diameter client, which sent a request for session initiation to a Diameter server and appended a single or multiple Session-Group-Id AVPs but cannot find any Session-Group-Info AVP in the associated response from the Diameter server proceeds with processing the command for a single session. Furthermore, the client keeps a log to remember that the server is not able to perform group operations. 5.2. Session Grouping Capability Discovery 5.2.1. Implicit Capability Discovery By appending at least one Session-Group-Info AVP, the Diameter client announces its capability to support group operations according to the specification in this document to the addressed Diameter server. If the Diameter client supports group operations, it MUST append at least one Session-Group-Info AVP to announce its capability to support group operations. A session-group aware Diameter server receiving a command for session initiation which includes at least one Session-Group-Info AVP learns about the sender's capability to support group operations. By appending at least one Session-Group-Id AVP, the Diameter server announces its capability to support group operations according to the specification in this document to the addressed Diameter client. 5.2.2. Explicit Capability Discovery New Diameter applications may consider support for Diameter session grouping and for performing group commands during the standardization Jones, et al. Expires April 24, 2014 [Page 9] Internet-Draft Diameter Group Signaling October 2013 process. Such applications provide intrinsic support for the support of group commands and announce this capability through the assigned application ID. 5.3. Performing Group Operations 5.3.1. Sending Group Commands Either Diameter peer can request the recipient of a request to process an associated command for all sessions being assigned to one or multiple groups by identifying these groups in the request. The sender of the request appends for each group, to which the command applies, a Session-Group-Info AVP including the Session-Group-Id AVP and indicates in the SESSION_GROUP_ALLOCATION_MODE flag of the Session-Group-Feature-Vector AVP whether the identifier represents a server- or a client-assigned group. If the CCF of the request mandates a Session-Id AVP, the Session-Id AVP MUST identify a single session which is assigned to at least one of the groups being identified in the appended Session-Group-Id AVPs. The sender of the request can indicate to the receiver how follow up message exchanges should be performed by appending a Session-Group- 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 Session-Group-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 Session-Group-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. If the sender wants the receiver of the request to process the associated command solely for a single session does not append any group identifier, but identifies the relevant session in the Session-Id AVP. 5.3.2. Receiving Group Commands A Diameter peer receiving a request to process a command for a group of sessions identifies the relevant groups according to the appended Session-Group-Id AVP in the Session-Group-Info AVP. If the received request identifies multiple groups in multiple appended Session- Group-Id AVPs, the receiver should process the associated command for each of these groups. if a session has been assigned to more than one of the identified groups, the receiver must process the associated command only once per session. Jones, et al. Expires April 24, 2014 [Page 10] Internet-Draft Diameter Group Signaling October 2013 The Diameter peer receiving a request which requests performing the command to at least on session group SHOULD perform follow up message exchanges according to the value identified in the Session-Group-Info AVP. 5.3.3. Single-Session Fallback Either Diameter peer, a Diameter client or a Diameter server, 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. 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.4. Session Management Editor's note: This document revision adopts the WG's current view on how Diameter commands can be formatted to enable group signaling. The required change in the formatting and protocol operation has not yet been considered in this Section 5.4 , which still reflects the formatting as per version 0 of this specification. The described session state machines still need revision to reflect the generalized formatting and the adopted protocol operation. 5.4.1. Authorization Session State Machine Section 8.1 in [RFC3588] 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 the additional state transitions related to the processing of the new commands which may impact multiple sessions. The group membership is session state and therefore only those state machines from [RFC3588] in which the server is maintaining session state are relevant in this document. As in [RFC3588], the term Service-Specific below refers to a message defined in a Diameter application (e.g., Mobile IPv4, NASREQ). The following state machine is observed by a client when state is maintained on the server. State transitions which are unmodified from [RFC3588] are not repeated here. CLIENT, STATEFUL State Event Action New State Jones, et al. Expires April 24, 2014 [Page 11] Internet-Draft Diameter Group Signaling October 2013 --------------------------------------------------------------- Idle Client or Device Requests Send Pending access service specific auth req optionally including groups Open GASR received with Send GASA Discon Session-Group-Action with = ALL_GROUPS, Result-Code session is assigned to = SUCCESS, received group(s) and Send GSTR. client will comply with request to end the session Open GASR received with Send GASA Discon Session-Group-Action with = PER_GROUPS, Result-Code session is assigned to = SUCCESS, received group(s) and Send GSTR client will comply with per group request to end the session Open GASR received with Send GASA Discon Session-Group-Action with = PER_SESSION, Result-Code session is assigned to = SUCCESS, received group(s) and Send STR client will comply with per session request to end the session Open GASR received, Send GASA Open client will not comply with with request to end all session Result-Code in received group(s) != SUCCESS Discon GSTA Received Discon. Idle user/device Open GRAR received with Send GRAA, Pending Session-Group-Action Send = ALL_GROUPS, service session is assigned to specific received group(s) and group client will perform re-auth req subsequent re-auth Jones, et al. Expires April 24, 2014 [Page 12] Internet-Draft Diameter Group Signaling October 2013 Open GRAR received with Send GRAA, Pending Session-Group-Action Send = PER_GROUP, service session is assigned to specific received group(s) and group client will perform re-auth req subsequent re-auth per group Open GRAR received with Send GRAA, Pending Session-Group-Action Send = PER_SESSION, service session is assigned to specific received group(s) and re-auth req client will perform per session subsequent re-auth Open GRAR received and client will Send GRAA Idle not perform subsequent with re-auth Result-Code != SUCCESS, Discon. user/device Pending Successful service-specific Provide Open group re-authorization answer service received. Pending Failed service-specific Discon. Idle group re-authorization answer user/device received. The following state machine is observed by a server when it is maintaining state for the session. State transitions which are unmodified from [RFC3588] are not repeated here. Jones, et al. Expires April 24, 2014 [Page 13] Internet-Draft Diameter Group Signaling October 2013 SERVER, STATEFUL State Event Action New State --------------------------------------------------------------- Idle Service-specific authorization Send Open request received, and user successful is authorized service specific answer optionally including groups Open Server wants to terminate Send GASR Discon group(s) Discon GASA received Cleanup Idle Any GSTR received Send GSTA, Idle Cleanup Open Server wants to reauth Send GRAR Pending group(s) Pending GRAA received with Result-Code Update Open = SUCCESS session(s) Pending GRAA received with Result-Code Cleanup Idle != SUCCESS session(s) Open Service-specific group Send Open re-authoization request successful received and user is service authorized specific group re-auth answer Open Service-specific group Send Idle re-authorization request failed received and user is service not authorized specific group re-auth answer, cleanup Jones, et al. Expires April 24, 2014 [Page 14] Internet-Draft Diameter Group Signaling October 2013 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 to extend the CCF of existing Diameter commands with optional AVPs to enable the recipient of the command to perform the command to all sessions associated with the identified group(s). 6.1. Group Re-Auth-Request A request that one or more groups of users are re-authentication is issues by appending one or multiple Session-Group-Id AVP(s) to the Re-Auth-Request (RAR). The one or multiple Session-Group-Id AVP(s) identify the associated group(s) for which the group re- authentication has been requested. The recipient of the group command initiates re-authentication for all users associated with the identified group(s). Furthermore, the sender of the group re- authentication request appends a Session-Group-Action AVP to provide more information to the receiver of the command about how to accomplish the group operation. The value of the mandatory Session-Id AVP MUST identify a session associated with a single user, which is assigned to at least one of the groups being identified in the appended Session-Group-Id AVPs. ::= < Diameter Header: 258, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Destination-Host } { Auth-Application-Id } { Re-Auth-Request-Type } [ User-Name ] [ Origin-State-Id ] * [ Proxy-Info ] * [ Route-Record ] * [ Session-Group-Id ] [ Session-Group-Action ] * [ AVP ] Jones, et al. Expires April 24, 2014 [Page 15] Internet-Draft Diameter Group Signaling October 2013 7. Attribute-Value-Pairs (AVP) +--------------------+ | AVP Flag rules | +----+---+------+----+ AVP | | |SHOULD|MUST| Attribute Name Code Value Type |MUST|MAY| NOT | NOT| +-------------------------------------------------+----+---+------+----+ |Session-Group-Info TBD1 Grouped | | P | | V | |Session-Group-Feature-Vector TBD2 Unsigned32 | | P | | V | |Session-Group-Id TBD3 OctetString | | P | | V | |Session-Group-Action TBD4 Unsigned32 | | P | | V | +-------------------------------------------------+----+---+------+----+ AVPs for the Diameter Group Signaling 7.1. Session-Group-Info AVP The Session-Group-Info AVP (AVP Code TBD1) is of type Grouped. It contains the identifier of the session group as well as an indication of the node responsible for session group identifier assignment. Session-Group-Info ::= < AVP Header: TBD1 > < Session-Group-Feature-Vector > [ Session-Group-Id ] * [ AVP ] 7.2. Session-Group-Feature-Vector AVP The Session-Group-Feature-Vector AVP (AVP Code TBD2) is of type Unsigned32 and and contains a 32-bit flags field of capabilities supported by the session-group aware node. The following capabilities are defined in this document: SESSION_GROUP_ALLOCATION_MODE (0x00000001) This flag indicates the mode of allocation of session group identifier. When this flag is set, it indicates that Diameter server is responsible for the allocation of the session group identifier. When this flag is not set, it indicates that the session group identifier is allocated by the client. 7.3. Session-Group-Id AVP The Session-Group-Id AVP (AVP Code TBD3) is of type UTF8String and identifies a group of sessions. Jones, et al. Expires April 24, 2014 [Page 16] Internet-Draft Diameter Group Signaling October 2013 The Session-Group-Id MUST be globally and eternally unique, as it is meant to uniquely identify a group of Diameter sessions without reference to any other information. Unless stated otherwise, the default format of the Session-Group-id SHOULD comply to the format recommended for a Session-Id, as defined in the section 8.8 of the RFC6733 [RFC6733]. However, the exact format of the Session-Group-Id MAY be specified by the Diameter applications which make use of group signaling commands. 7.4. Session-Group-Action AVP The Session-Group-Action AVP (AVP Code TBD4) is of type Unsigned32 and contains a 32-bit address space representing values indicating how the peer SHOULD issue follow up exchanges in response to a command which impacts mulitple sessions. The following values are defined by this application: ALL_GROUPS (1) Follow up exchanges 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. PER_SESSION (3) Follow up exchanges should be performed with a message exchange for each impacted session. Jones, et al. Expires April 24, 2014 [Page 17] Internet-Draft Diameter Group Signaling October 2013 8. Result-Code AVP Values This document does not define new Result-Code [RFC3588] values for existing applications, which are extended to support group commands. Specification documents of new applications, which will have intrinsic support for group commands, may specify new Result-Codes. Jones, et al. Expires April 24, 2014 [Page 18] Internet-Draft Diameter Group Signaling October 2013 9. IANA Considerations This section contains the namespaces that have either been created in this specification or had their values assigned to existing namespaces managed by IANA. 9.1. AVP Codes This specification requires IANA to register the following new AVPs from the AVP Code namespace defined in [RFC3588]. o Session-Group-Info o Session-Group-Feature-Vector o Session-Group-Id o Session-Group-Action The AVPs are defined in Section 7. Jones, et al. Expires April 24, 2014 [Page 19] Internet-Draft Diameter Group Signaling October 2013 10. Security Considerations TODO Jones, et al. Expires April 24, 2014 [Page 20] Internet-Draft Diameter Group Signaling October 2013 11. Acknowledgments Jones, et al. Expires April 24, 2014 [Page 21] Internet-Draft Diameter Group Signaling October 2013 12. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005. Jones, et al. Expires April 24, 2014 [Page 22] Internet-Draft Diameter Group Signaling October 2013 Authors' Addresses Mark Jones Email: mark@azu.ca Marco Liebsch Email: marco.liebsch@neclab.eu Lionel Morand Email: lionel.morand@orange.com Jones, et al. Expires April 24, 2014 [Page 23]