< draft-ietf-dime-group-signaling-10.txt   draft-ietf-dime-group-signaling-11.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: July 12, 2018 Expires: December 13, 2018
L. Morand L. Morand
January 8, 2018 June 11, 2018
Diameter Group Signaling Diameter Group Signaling
draft-ietf-dime-group-signaling-10.txt draft-ietf-dime-group-signaling-11.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 July 12, 2018. This Internet-Draft will expire on December 13, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
skipping to change at page 2, line 49 skipping to change at page 2, line 49
6.1. Formatting Example: Group Re-Auth-Request . . . . . . . . 16 6.1. Formatting Example: Group Re-Auth-Request . . . . . . . . 16
7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 17 7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 17
7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . 17 7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . 17
7.2. Session-Group-Control-Vector AVP . . . . . . . . . . . . 18 7.2. Session-Group-Control-Vector AVP . . . . . . . . . . . . 18
7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . 18 7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . 18
7.4. Group-Response-Action AVP . . . . . . . . . . . . . . . . 19 7.4. Group-Response-Action AVP . . . . . . . . . . . . . . . . 19
7.5. Session-Group-Capability-Vector AVP . . . . . . . . . . . 19 7.5. Session-Group-Capability-Vector AVP . . . . . . . . . . . 19
8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 19 8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 20
9.2. New Registries . . . . . . . . . . . . . . . . . . . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
12. Normative References . . . . . . . . . . . . . . . . . . . . 21 12. Normative References . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Session Management -- Exemplary Session State Appendix A. Session Management -- Exemplary Session State
Machine . . . . . . . . . . . . . . . . . . . . . . 21 Machine . . . . . . . . . . . . . . . . . . . . . . 22
A.1. Use of groups for the Authorization Session State Machine 21 A.1. Use of groups for the Authorization Session State Machine 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
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. For example, a policy large group of Diameter sessions concurrently. For example, a policy
decision point may need to modify the authorized quality of service decision point may need to modify the authorized quality of service
for all active users having the same type of subscription. The for all active users having the same type of subscription. The
skipping to change at page 8, line 35 skipping to change at page 8, line 35
client sends a service specific request, e.g. NASREQ AA-Request client sends a service specific request, e.g. NASREQ AA-Request
[RFC7155], 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. 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 The client MUST set the SESSION_GROUP_ALLOCATION_ACTION flag of the
Session-Group-Control-Vector AVP in each appended Session-Group-Info Session-Group-Control-Vector AVP in each appended Session-Group-Info
AVP to indicate that the session contained in the request should be AVP to indicate that the session contained in the request should be
assigned to the identified session group. assigned to the identified session group.
The client may also indicate in the request that the server is The client may also indicate in the request that the server is
responsible for the assignment of the session in one or multiple responsible for the assignment of the session in one or multiple
sessions owned by the server. In such a case, the client MUST sessions owned by the server. In such a case, the client MUST
include the Session-Group-Info AVP in the request including the include the Session-Group-Info AVP in the request including the
skipping to change at page 13, line 42 skipping to change at page 13, line 46
the command applies, a Session-Group-Info AVP including the Session- the command applies, a Session-Group-Info AVP including the Session-
Group-Id AVP to identify the associated session group. Both, the Group-Id AVP to identify the associated session group. Both, the
SESSION_GROUP_ALLOCATION_ACTION flag as well as the SESSION_GROUP_ALLOCATION_ACTION flag as well as the
SESSION_GROUP_STATUS_IND flag MUST be set. SESSION_GROUP_STATUS_IND flag MUST be set.
If the CCF of the request mandates a Session-Id AVP, the Session-Id 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 AVP MUST identify one of the single sessions which is assigned to at
least one of the groups being identified in the appended Session- least one of the groups being identified in the appended Session-
Group-Id AVPs. Group-Id AVPs.
The sender of the request MUST indicate to the receiver how follow up The sender of the request MUST indicate to the receiver how multiple
message exchanges should be performed by appending a single instance resulting transactions associated with a group command are to be
of the Group-Response-Action AVP. Even if the request includes treated by appending a single instance of a Group-Response-Action
multiple instances of a Session-Group-Info AVP, the request MUST NOT AVP. When a server sends, as example, a Re-Authorization Request
comprise more than a single instance of a Group-Response-Action AVP. (RAR) or a service-specific server-initiated request to the client,
If the sender wants the receiver to perform follow up exchanges with it can indicate to the client whether to process the request, after
a single command for all impacted groups, the sender sets the value having sent the RAA to the server, with either sending a single RAR
of the Group-Response-Action AVP to ALL_GROUPS (1). If follow up message for all identified groups (server sets the Group-Response-
message exchanges should be performed on a per-group basis in case Action AVP to ALL_GROUPS (1)), or sending a single RAR message for
multiple groups are identified in the group command, the value of the each identified group individually (server sets the Group-Response-
Group-Response-Action AVP is set to PER_GROUP (2). A value set to Action AVP to PER_GROUP (1)). The server may also request the client
PER_SESSION (3) indicates to the receiver that all follow up to follow-up with a single RAR message per impacted session (server
exchanges should be performed using a single message for each sets the Group-Response-Action AVP to PER_SESSION). In such case,
impacted session. 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 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 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 before receiving the corresponding answer(s) as the answer(s) will
only be sent back when the request is processed for all the sessions 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 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- 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 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 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 or if the request timeout timer is high enough, the sender MAY set
skipping to change at page 18, line 11 skipping to change at page 18, line 11
< Session-Group-Control-Vector > < Session-Group-Control-Vector >
[ Session-Group-Id ] [ Session-Group-Id ]
* [ AVP ] * [ AVP ]
7.2. Session-Group-Control-Vector AVP 7.2. Session-Group-Control-Vector AVP
The Session-Group-Control-Vector AVP (AVP Code TBD2) is of type The Session-Group-Control-Vector AVP (AVP Code TBD2) is of type
Unsigned32 and contains a 32-bit flags field to control the group Unsigned32 and contains a 32-bit flags field to control the group
assignment at session-group aware nodes. 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) SESSION_GROUP_ALLOCATION_ACTION (0x00000001)
This flag indicates the action to be performed for the identified This flag indicates the action to be performed for the identified
session. When this flag is set, it indicates that the identified session. When this flag is set, it indicates that the identified
Diameter session is to be assigned to the session group as Diameter session is to be assigned to the session group as
identified by the Session-Group-Id AVP or the session's assignment identified by the Session-Group-Id AVP or the session's assignment
to the session group identified in the Session-Group-Id AVP is to the session group identified in the Session-Group-Id AVP is
still valid. When the flag is cleared, the identified Diameter still valid. When the flag is cleared, the identified Diameter
session is to be removed from at least one session group. When session is to be removed from at least one session group. When
skipping to change at page 19, line 11 skipping to change at page 19, line 11
recommended for a Session-Id, as defined in the section 8.8 of the recommended for a Session-Id, as defined in the section 8.8 of the
[RFC6733]. The <DiameterIdentity> portion of the Session-Group-Id [RFC6733]. The <DiameterIdentity> portion of the Session-Group-Id
MUST identify the Diameter node, which owns the session group. MUST identify the Diameter node, which owns the session group.
7.4. Group-Response-Action AVP 7.4. Group-Response-Action AVP
The Group-Response-Action AVP (AVP Code TBD4) is of type Unsigned32 The Group-Response-Action AVP (AVP Code TBD4) is of type Unsigned32
and contains a 32-bit address space representing values indicating and contains a 32-bit address space representing values indicating
how the node SHOULD issue follow up exchanges in response to a how the node SHOULD issue follow up exchanges in response to a
command which impacts multiple sessions. The following values are command which impacts multiple sessions. The following values are
defined by this application: defined by this document:
ALL_GROUPS (1) ALL_GROUPS (1)
Follow up exchanges should be performed with a single message Follow up message exchanges associated with a group command should
exchange for all impacted groups. be performed with a single message exchange for all impacted
groups.
PER_GROUP (2) PER_GROUP (2)
Follow up exchanges should be performed with a message exchange Follow up message exchanges associated with a group command should
for each impacted group. be performed with a separate message exchange for each impacted
group.
PER_SESSION (3) PER_SESSION (3)
Follow up exchanges should be performed with a message exchange Follow up message exchanges associated with a group command should
for each impacted session. be performed with a separate message exchange for each impacted
session.
7.5. Session-Group-Capability-Vector AVP 7.5. Session-Group-Capability-Vector AVP
The Session-Group-Capability-Vector AVP (AVP Code TBD5) is of type The Session-Group-Capability-Vector AVP (AVP Code TBD5) is of type
Unsigned32 and contains a 32-bit flags field to indicate capabilities Unsigned32 and contains a 32-bit flags field to indicate capabilities
in the context of session-group assignment and group operations. in the context of session-group assignment and group operations.
The following capabilities are defined in this document: The following capabilities are defined in this document:
BASE_SESSION_GROUP_CAPABILITY (0x00000001) BASE_SESSION_GROUP_CAPABILITY (0x00000001)
skipping to change at page 20, line 22 skipping to change at page 20, line 22
o Session-Group-Control-Vector o Session-Group-Control-Vector
o Session-Group-Id o Session-Group-Id
o Group-Response-Action o Group-Response-Action
o Session-Group-Capability-Vector o Session-Group-Capability-Vector
The AVPs are defined in Section 7. 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 10. Security Considerations
The security considerations of the Diameter protocol itself are The security considerations of the Diameter protocol itself are
discussed in [RFC6733]. Use of the AVPs defined in this document discussed in [RFC6733]. Use of the AVPs defined in this document
MUST take into consideration the security issues and requirements of MUST take into consideration the security issues and requirements of
the Diameter base protocol. In particular, the Session-Group-Info the Diameter base protocol. In particular, the Session-Group-Info
AVP (including the Session-group-Control-Vector and the Session- AVP (including the Session-group-Control-Vector and the Session-
Group-Id AVPs) should be considered as a security-sensitive AVPs in 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 the same manner than the Session-Id AVP in the Diameter base protocol
[RFC6733]. [RFC6733].
 End of changes. 14 change blocks. 
29 lines changed or deleted 55 lines changed or added

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