idnits 2.17.1 draft-ietf-dime-group-signaling-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 863 has weird spacing: '...ly with wit...' == Line 902 has weird spacing: '... answer servi...' == Line 906 has weird spacing: '... answer user/...' -- The document date (July 4, 2014) is 3583 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Diameter Maintenance and Extensions (DIME) M. Jones 3 Internet-Draft 4 Intended status: Standards Track M. Liebsch 5 Expires: January 5, 2015 6 L. Morand 8 July 4, 2014 10 Diameter Group Signaling 11 draft-ietf-dime-group-signaling-04.txt 13 Abstract 15 In large network deployments, a single Diameter peer can support over 16 a million concurrent Diameter sessions. Recent use cases have 17 revealed the need for Diameter peers to apply the same operation to a 18 large group of Diameter sessions concurrently. The Diameter base 19 protocol commands operate on a single session so these use cases 20 could result in many thousands of command exchanges to enforce the 21 same operation on each session in the group. In order to reduce 22 signaling, it would be desirable to enable bulk operations on all (or 23 part of) the sessions managed by a Diameter peer using a single or a 24 few command exchanges. This document specifies the Diameter protocol 25 extensions to achieve this signaling optimization. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 5, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 64 3.1. Building and Modifying Session Groups . . . . . . . . . . 4 65 3.2. Issuing Group Commands . . . . . . . . . . . . . . . . . 4 66 3.3. Permission Considerations . . . . . . . . . . . . . . . . 4 67 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 68 4.1. Session Grouping . . . . . . . . . . . . . . . . . . . . 6 69 4.1.1. Group assignment at session initiation . . . . . . . 7 70 4.1.2. Removing a session from a session group . . . . . . . 8 71 4.1.3. Mid-session group assignment modifications . . . . . 9 72 4.2. Session Grouping Capability Discovery . . . . . . . . . . 10 73 4.2.1. Explicit Capability Discovery . . . . . . . . . . . . 10 74 4.2.2. Implicit Capability Discovery . . . . . . . . . . . . 11 75 4.3. Deleting a Session Group . . . . . . . . . . . . . . . . 11 76 4.4. Performing Group Operations . . . . . . . . . . . . . . . 11 77 4.4.1. Sending Group Commands . . . . . . . . . . . . . . . 11 78 4.4.2. Receiving Group Commands . . . . . . . . . . . . . . 12 79 4.4.3. Error Handling for Group Commands . . . . . . . . . . 12 80 4.4.4. Single-Session Fallback . . . . . . . . . . . . . . . 13 81 5. Operation with Proxies Agents . . . . . . . . . . . . . . . . 13 82 6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 13 83 6.1. Formatting Example: Group Re-Auth-Request . . . . . . . . 14 84 7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 14 85 7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . 15 86 7.2. Session-Group-Control-Vector AVP . . . . . . . . . . . . 15 87 7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . 16 88 7.4. Group-Response-Action AVP . . . . . . . . . . . . . . . . 16 89 7.5. Session-Group-Capability-Vector AVP . . . . . . . . . . . 17 90 8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 17 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 92 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 17 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 94 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 95 12. Normative References . . . . . . . . . . . . . . . . . . . . 18 96 Appendix A. Session Management -- Exemplary Session State 97 Machines . . . . . . . . . . . . . . . . . . . . . . 18 98 A.1. Authorization Session State Machine . . . . . . . . . . . 18 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 101 1. Introduction 103 In large network deployments, a single Diameter peer can support over 104 a million concurrent Diameter sessions. Recent use cases have 105 revealed the need for Diameter peers to apply the same operation to a 106 large group of Diameter sessions concurrently. For example, a policy 107 decision point may need to modify the authorized quality of service 108 for all active users having the same type of subscription. The 109 Diameter base protocol commands operate on a single session so these 110 use cases could result in many thousands of command exchanges to 111 enforce the same operation on each session in the group. In order to 112 reduce signaling, it would be desirable to enable bulk operations on 113 all (or part of) the sessions managed by a Diameter peer using a 114 single or a few command exchanges. 116 This document describes mechanisms for grouping Diameter sessions and 117 applying Diameter commands, such as performing re-authentication, re- 118 authorization, termination and abortion of sessions to a group of 119 sessions. This document does not define a new Diameter application. 120 Instead it defines mechanisms, commands and AVPs that may be used by 121 any Diameter application that requires management of groups of 122 sessions. 124 These mechanisms take the following design goals and features into 125 account: 127 o Minimal impact to existing applications 129 o Extension of existing commands' Command Code Format (CCF) with 130 optional AVPs to enable grouping and group operations 132 o Fallback to single session operation 134 o Implicit discovery of capability to support grouping and group 135 operations in case no external mechanism is available to discover a 136 Diameter peer's capability to support session grouping and session 137 group operations. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 This document uses terminology defined [RFC6733]. 147 3. Protocol Overview 149 3.1. Building and Modifying Session Groups 151 Client and Server can assign a new Diameter session to a group, e.g. 152 in case the subscription profile of the associated user has similar 153 characteristics as the profile of other users whose Diameter session 154 has been assigned to one or multiple groups. A single command can be 155 issued and applied to all sessions associated with such group(s), 156 e.g. to adjust common profile or policy settings. 158 The assignment of a Diameter session to a group can be changed mid- 159 session. For example, if a user's subscription profile changes mid- 160 session, a Diameter peer may remove the session from its current 161 group and assign the session to a different group that is more 162 appropriate for the new subscription profile. 164 In case of mobile users, the user's session may get transferred to a 165 new Diameter client during handover and assigned to a different 166 group, which is maintained at the new Diameter client, mid-session. 168 A session group, which has sessions assigned, can be deleted, e.g. 169 due to a change in multiple users' subscription profile so that the 170 group's assigned sessions do not share certain characteristics 171 anymore. Deletion of such group requires subsequent individual 172 treatment of each of the assigned sessions. A peer may decide to 173 assign some of these sessions to any other existing or new group. 175 3.2. Issuing Group Commands 177 Changes in the network condition may result in the Diameter server's 178 decision to close all sessions in a given group. The server issues a 179 single Session Termination Request (STR) command , identifying the 180 group of sessions which are to be terminated. The Diameter client 181 treats the STR as group command and initiates termination of all 182 sessions associated with the identified group. Subsequently, the 183 client confirms successful termination of these sessions to the 184 server by sending a single Session Termination Answer (STA) command, 185 which includes the identifier of the group. 187 3.3. Permission Considerations 189 Permission considerations in the context of this draft apply to the 190 permission of Diameter nodes to build new session groups, to assign/ 191 remove a session to/from a session group and to delete an existing 192 session group. 194 This specification follows the most flexible model where both, a 195 Diameter client and a Diameter server can create a new group and 196 assign a new identifier to that session group. When a Diameter node 197 decides to create a new session group, e.g. to group all sessions 198 which share certain characteristics, the node builds a session group 199 identifier according to the rules described in Section 7.3) and 200 becomes the owner of the group. This specification does not 201 constrain the permission to add or remove a session to/from a session 202 group to the group owner, instead each peer can add a session to any 203 known group or remove a session from a group. A session group is 204 deleted and its identifier released after the last session has been 205 removed from the session group. Also the modification of groups in 206 terms of moving a session from one session group to a different 207 session group is permitted to any Diameter node. A Diameter peer can 208 delete a session group and its group identifier mid-session, 209 resulting in individual treatment of the sessions which have been 210 previously assigned to the deleted group. 212 The enforcement of more constrained permissions is left to the 213 specification of a particular group signaling enabled Diameter 214 application and compliant implementations of such application must 215 enforce the associated permission model. Details about enforcing a 216 more constraint permission model are out of scope of this 217 specification. For example, a more constrained model could require 218 that a client MUST NOT remove a session from a group which is owned 219 by the server. 221 The following table depicts the permission considerations as per the 222 present specification: 224 +-------------------------------------------------+--------+--------+ 225 | Operation | Server | Client | 226 +-------------------------------------------------+--------+--------+ 227 | Create a new Session Group (peer becomes | X | X | 228 | the group owner) | | | 229 +-------------------------------------------------+--------+--------+ 230 | Assign a Session to an owned Session Group | X | X | 231 +-------------------------------------------------+--------+--------+ 232 | Assign a Session to a non-owned Session Group | X | X | 233 +-------------------------------------------------+--------+--------+ 234 | Remove a Session from an owned Session Group | X | X | 235 +-------------------------------------------------+-----------------+ 236 | Remove a Session from a non-owned Session Group | X | X | 237 +-------------------------------------------------+--------+--------+ 238 | Remove a Session from a Session Group where the | X | X | 239 | peer created the assignment | | | 240 +-------------------------------------------------+--------+--------+ 241 | Remove a Session from a Session Group where the | | | 242 | peer did not create the assignment | | | 243 +-------------------------------------------------+--------+--------+ 244 | Overrule a peer's group assignment *) | | | 245 +-------------------------------------------------+--------+--------+ 246 | Delete a Session Group owned by the peer | X | X | 247 +-------------------------------------------------+--------+--------+ 248 | Delete a Session Group not owned by the peer | | | 249 +-------------------------------------------------+--------+--------+ 251 Default Permission as per this Specification 253 *) Editors' note: The protocol specification in this document does 254 not consider overruling a peer's assignment of a session to a session 255 group. Group signaling enabled applications may take such protocol 256 support and associated protocol semantics into account in their 257 specification. 259 4. Protocol Description 261 4.1. Session Grouping 263 Either Diameter peer can initiate the assignment of a session to a 264 single or multiple session groups. Modification of a group by 265 removing or adding a single or multiple user sessions can be 266 initiated and performed mid-session by either Diameter peer. 267 Diameter AAA applications typically assign client and server roles to 268 the Diameter peers, which are referred to as relevant Diameter peers 269 to utilize session grouping and issue group commands. Section 5 270 describes particularities about session grouping and performing group 271 commands when relay agents or proxies are deployed. 273 Diameter peers, which are group-aware, must store and maintain an 274 entry about the group assignment together with a session's state. A 275 list of all known session groups should be locally maintained on each 276 peer, each group pointing to individual sessions being assigned to 277 the group. A peer must also keep a record about sessions, which have 278 been assigned to a session group by that peer. 280 4.1.1. Group assignment at session initiation 282 To assign a session to a group at session initiation, a Diameter 283 client sends a service specific request, e.g. NASREQ AAR [RFC4005], 284 containing one or more group identifiers. Each of these groups need 285 to be identified by a unique Session-Group-Id contained in a separate 286 Session-Group-Info AVP as specified in Section 7. 288 The client may choose one or multiple sessions from a list of 289 existing session groups. Alternatively, the client may decide to 290 create a new group and identify itself in the DiameterIdentity 291 element of the Group-Session-Id AVP as per Section 7.3 293 The client MUST set the SESSION_GROUP_ALLOCATION_ACTION of the 294 Session-Group-Control-Vector AVP in each appended Session-Group-Info 295 AVP to indicate that the identified session should be assigned to the 296 identified session group. 298 If the Diameter server receives a command request from a Diameter 299 client and the command comprises at least one Session-Group-Info AVP 300 having the SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group- 301 Control-Vector AVP set, the server must assign the new session to 302 each of the one or multiple identified session groups. In case one 303 or multiple identified session groups are not know to the server, the 304 server must add the one or multiple new groups to its local list of 305 known session groups. When sending the response to the client, e.g. 306 a service-specific auth response as per NASREQ AAA [RFC4005], the 307 server must include all Session-Group-Info AVPs as received in the 308 client's request. 310 In addition to the one or multiple session groups identified in the 311 client's request, the server may decide to assign the new session to 312 one or multiple additional groups. In such case, the server adds to 313 the response additional Session-Group-Info AVPs, each identifying a 314 session group, to which the server has assigned the new session. 315 Each of the Session-Group-Info AVP added by the server must have the 316 SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control- 317 Vector AVP set. 319 If the Diameter client receives a response to its previously issued 320 request from the server and the response comprises at least one 321 Session-Group-Info AVP having the SESSION_GROUP_ALLOCATION_ACTION 322 flag of the associated Session-Group-Control-Vector AVP set, the 323 client must add the new session to all session groups as identified 324 in the one or multiple Session-Group-Info AVPs. 326 A Diameter server receiving a command for session initiation which 327 includes at least one Session-Group-Info AVP but the server does not 328 understand the semantics of this optional AVP because it does not 329 support group operations according to the specification in this 330 document, MUST ignore the optional group operations specific AVPs and 331 proceed with processing the command for a single session. 333 A Diameter client, which sent a request for session initiation to a 334 Diameter server and appended a single or multiple Session-Group-Id 335 AVPs but cannot find any Session-Group-Info AVP in the associated 336 response from the Diameter server proceeds with processing the 337 command for a single session. Furthermore, the client keeps a log to 338 remember that the server is not able to perform group operations. 340 4.1.2. Removing a session from a session group 342 When a Diameter client decides to remove a session from a particular 343 session group, the client sends a service-specific re-authorization 344 request to the server and adds one Session-Group-Info AVP to the 345 request for each session group, from which the client wants to remove 346 the session. The session, which is to be removed from a group, is 347 identified in the Session-Id AVP of the command request. The 348 SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Control- 349 Vector AVP in each Session-Group-Info AVP must be cleared to indicate 350 removal of the session from the session group identified in the 351 associated Session-Group-id AVP. 353 When a Diameter client decides to remove a session from all session 354 groups, to which the session has been previously assigned, the client 355 sends a service-specific re-authorization request to the server and 356 adds a single Session-Group-Info AVP to the request which has the 357 SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id 358 AVP omitted. The session, which is to be removed from all groups, to 359 which the session has been previously assigned, is identified in the 360 Session-Id AVP of the command request. 362 If the Diameter server receives a request from the client which has 363 at least one Session-Group-Info AVP appended with the 364 SESSION_GROUP_ALLOCATION_ACTION flag cleared, the server must remove 365 the session from the session group identified in the associated 366 Session-Group-Id AVP. If the request comprises at least one Session- 367 Group-info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared 368 and no Session-Id AVP present, the server must remove the session 369 from all session groups to which the session has been previously 370 assigned. The server must include in its response to the requesting 371 client all Session-Group-Id AVPs as received in the request. 373 When the Diameter server decides to remove a session from one or 374 multiple particular session groups or from all session groups to 375 which the session has been assigned beforehand, the server sends a 376 Re-Authorization Request (RAR) to the client, indicating the session 377 in the requests Session-Id AVP. The client sends a Re-Authorization 378 Answer (RAA) to respond to the server's request. The client 379 subsequently sends service-specific re-authorization request 380 containing one or multiple Session-Group-Info AVPs, each indicating a 381 session group, to which the session had been previously assigned. To 382 indicate removal of the indicated session from one or multiple 383 session groups, the server sends a service-specific auth response to 384 the client, containing a list of Session-Group-Info AVPs with the 385 SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id 386 AVP identifying the session group, from which the session should be 387 removed. The server MAY include to the service-specific auth 388 response a list of Session-Group-Info AVPs with the 389 SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP 390 identifying session groups to which the session remains subscribed. 391 In case the server decides to remove the identified session from all 392 session groups, to which the session has been previously assigned, 393 the server includes in the service-specific auth response at least 394 one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION 395 flag cleared and Session-Group-Id AVP absent. 397 4.1.3. Mid-session group assignment modifications 399 Either Diameter peer can modify the group membership of an active 400 Diameter session according to the specified permission 401 considerations. 403 To update an assigned group mid-session, a Diameter client sends a 404 service-specific re-authorization request to the server, containing 405 one or multiple Session-Group-Info AVPs with the 406 SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP 407 present, identifying the session group to which the session should be 408 assigned. With the same message, the client may send one or multiple 409 Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag 410 cleared and the Session-Group-Id AVP identifying the session group 411 from which the identified session is to be removed. To remove the 412 session from all previously assigned session groups, the client 413 includes at least one Session-Group-Info AVP with the 414 SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id 415 AVP present. When the server received the service-specific re- 416 authorization request, it must update its locally maintained view of 417 the session groups for the identified session according to the 418 appended Session-Group-Info AVPs. The server sends a service- 419 specific auth response to the client containing one or multiple 420 Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag 421 set and the Session-Group-Id AVP identifying the new session group to 422 which the identified session has been assigned. 424 When a Diameter server enforces an update to the assigned groups mid- 425 session, it sends a Re-Authorization Request (RAR) message to the 426 client identifying the session, for which the session group lists are 427 to be updated. The client responds with a Re-Authorization Answer 428 (RAA) message. The client subsequently sends service-specific re- 429 authorization request containing one or multiple Session-Group-Info 430 AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the 431 Session-Group-Id AVP identifying the session group to which the 432 session had been previously assigned. The server responds with a 433 service-specific auth response and includes one or multiple Session- 434 Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set and 435 the Session-Group-Id AVP identifying the session group, to which the 436 identified session is to be assigned. With the same response 437 message, the server may send one or multiple Session-Group-Info AVPs 438 with the SESSION_GROUP_ALLOCATION_ACTION flag cleared and the 439 Session-Group-Id AVP identifying the session groups from which the 440 identified session is to be removed. When server wants to remove the 441 session from all previously assigned session groups, it send at least 442 on Session-Group-Info AVP with the response having the 443 SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id 444 AVP present. 446 4.2. Session Grouping Capability Discovery 448 Diameter nodes should assign a session to a session group and perform 449 session group operations with a peer only after having ensured that 450 the peer announced associated support beforehand. 452 4.2.1. Explicit Capability Discovery 454 New Diameter applications may consider support for Diameter session 455 grouping and for performing group commands during the standardization 456 process. Such applications provide intrinsic discovery for the 457 support of group commands and announce this capability through the 458 assigned application ID. 460 System- and deployment-specific means for capability exchange can be 461 used to announce peers' support for session grouping and session 462 group operations. In such case, the optional Session-Group- 463 Capability-Vector AVP, as described in Section 4.2.2 can be omitted 464 in Diameter messages being exchanged between peers. 466 4.2.2. Implicit Capability Discovery 468 If no explicit mechanism for capability discovery is deployed to 469 enable Diameter nodes to learn about peers' capability to support 470 session grouping and group commands, Diameter peers SHOULD append the 471 Session-Group-Capability-Vector AVP to any Diameter messages 472 exchanged with its peers to announce its capability to support 473 session grouping and session group operations. Implementations 474 following this specification set the BASE_SESSION_GROUP_CAPABILITY 475 flag of the Session-Group-Capability-Vector AVP. 477 When a Diameter node receives at least one Session-Group-Capability- 478 Vector AVP from a peer with the BASE_SESSION_GROUP_CAPABILITY flag 479 set, the Diameter node maintains a log to remember the peer's 480 capability to support group commands. 482 4.3. Deleting a Session Group 484 To delete a session group and release the associated Session-Group-Id 485 value, the owner of a session group appends a single Session-Group- 486 Info AVP having the SESSION_GROUP_STATUS_IND flag cleared and the 487 Session-Group-Id AVP identifying the session group, which is to be 488 deleted. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated 489 Session-Group-Control-Vector AVP MUST be cleared. 491 4.4. Performing Group Operations 493 4.4.1. Sending Group Commands 495 Either Diameter peer can request the recipient of a request to 496 process an associated command for all sessions being assigned to one 497 or multiple groups by identifying these groups in the request. The 498 sender of the request appends for each group, to which the command 499 applies, a Session-Group-Info AVP including the Session-Group-Id AVP 500 to identify the associated session group. Both, the 501 SESSION_GROUP_ALLOCATION_ACTION flag as well as the 502 SESSION_GROUP_STATUS_IND flag must be set. 504 If the CCF of the request mandates a Session-Id AVP, the Session-Id 505 AVP MUST identify a single session which is assigned to at least one 506 of the groups being identified in the appended Session-Group-Id AVPs. 508 The sender of the request MUST indicate to the receiver how follow up 509 message exchanges should be performed by appending a single instance 510 of the Group-Response-Action AVP. Even if the request includes 511 multiple instances of a Session-Group-Info AVP, the request MUST NOT 512 comprise more than a single instance of a Group-Response-Action AVP. 513 If the sender wants the receiver to perform follow up exchanges with 514 a single command for all impacted groups, the sender sets the value 515 of the Group-Response-Action AVP to ALL_GROUPS (1). If follow up 516 message exchanges should be performed on a per-group basis in case 517 multiple groups are identified in the group command, the value of the 518 Group-Response-Action AVP is set to PER_GROUP (2). A value set to 519 PER_SESSION (3) indicates to the receiver that all follow up 520 exchanges should be performed using a single message for each 521 impacted session. 523 If the sender wants the receiver of the request to process the 524 associated command solely for a single session does not append any 525 group identifier, but identifies the relevant session in the Session- 526 Id AVP. 528 4.4.2. Receiving Group Commands 530 A Diameter peer receiving a request to process a command for a group 531 of sessions identifies the relevant groups according to the appended 532 Session-Group-Id AVP in the Session-Group-Info AVP and processes the 533 group command according to the appended Group-Response-Action AVP . 534 If the received request identifies multiple groups in multiple 535 appended Session-Group-Id AVPs, the receiver should process the 536 associated command for each of these groups. if a session has been 537 assigned to more than one of the identified groups, the receiver must 538 process the associated command only once per session. 540 The Diameter peer receiving a request which requests performing the 541 command to at least on session group SHOULD perform follow up message 542 exchanges according to the value identified in the Session-Group-Info 543 AVP. 545 4.4.3. Error Handling for Group Commands 547 When a Diameter peer receives a request to process a command for one 548 or more session groups and the result of processing the command is an 549 error that applies to all sessions in the identified groups, an 550 associated protocol error must be returned to the source of the 551 request. In such case, the sender of the request MUST fall back to 552 single-session processing and the session groups, which have been 553 identified in the group command, MUST be deleted according to the 554 procedure described in Section 4.3. 556 When a Diameter peer receives a request to process a command for one 557 or more session groups and the result of processing the command 558 succeeds for some sessions identified in one or multiple session 559 groups, but fails for one or more sessions, the Result-Code AVP in 560 the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per 561 Section 7.1.2 of [RFC6733]. In case of limited success, the 562 sessions, for which the processing of the group command failed, MUST 563 be identified using a Failed-AVP AVP as per Session 7.5 of [RFC6733]. 565 4.4.4. Single-Session Fallback 567 Either Diameter peer, a Diameter client or a Diameter server, can 568 fall back to single session operation by ignoring and omitting the 569 optional group session-specific AVPs. Fallback to single-session 570 operation is performed by processing the Diameter command solely for 571 the session identified in the mandatory Session-Id AVP. The response 572 to the group command must not identify any group but identify solely 573 the single session for which the command has been processed. 575 5. Operation with Proxies Agents 577 This specification assumes in case of a present stateful Proxy Agent 578 between a Diameter client and a Diameter server that the Proxy Agent 579 is aware of session groups and session group handling. The Proxy 580 MUST reflect the state of each session associated with a session 581 group according to the result of a group command operated between a 582 Diameter client and a server. 584 In case a Proxy Agent manipulates session groups, it MUST maintain 585 consistency of session groups between a client and a server. This 586 applies to deployment where the Proxy Agent utilizes session grouping 587 and performing group commands with, for example, a Diameter server, 588 whereas the Diameter client is not group-aware. The same applies to 589 deployment where all nodes, the Diameter client and server, as well 590 as the Proxy Agent are group-aware but the Proxy Agent manipulates 591 groups, e.g. to adopt different administrative policies that apply to 592 the client's domain and the server's domain. 594 6. Commands Formatting 596 This document does not specify new Diameter commands to enable group 597 operations, but relies on command extensibility capability provided 598 by the Diameter Base protocol. This section provides the guidelines 599 to extend the CCF of existing Diameter commands with optional AVPs to 600 enable the recipient of the command to perform the command to all 601 sessions associated with the identified group(s). 603 6.1. Formatting Example: Group Re-Auth-Request 605 A request that one or more groups of users are re-authentication is 606 issued by appending one or multiple Session-Group-Id AVP(s) to the 607 Re-Auth-Request (RAR) and a single instance of a Group-Response- 608 Action AVP. The one or multiple Session-Group-Id AVP(s) identify the 609 associated group(s) for which the group re-authentication has been 610 requested. The Group-Response-Action AVP identifies the expected 611 means to perform and respond to the group command. The recipient of 612 the group command initiates re-authentication for all users 613 associated with the identified group(s). Furthermore, the sender of 614 the group re-authentication request appends a Group-Response-Action 615 AVP to provide more information to the receiver of the command about 616 how to accomplish the group operation. 618 The value of the mandatory Session-Id AVP MUST identify a session 619 associated with a single user, which is assigned to at least one of 620 the groups being identified in the appended Session-Group-Id AVPs. 622 ::= < Diameter Header: 258, REQ, PXY > 623 < Session-Id > 624 { Origin-Host } 625 { Origin-Realm } 626 { Destination-Realm } 627 { Destination-Host } 628 { Auth-Application-Id } 629 { Re-Auth-Request-Type } 630 [ User-Name ] 631 [ Origin-State-Id ] 632 * [ Proxy-Info ] 633 * [ Route-Record ] 634 [ Session-Group-Capability-Vector ] 635 * [ Session-Group-Info ] 636 [ Group-Response-Action ] 637 * [ AVP ] 639 7. Attribute-Value-Pairs (AVP) 640 +--------------------+ 641 | AVP Flag rules | 642 +----+---+------+----+ 643 AVP | | |SHOULD|MUST| 644 Attribute Name Code Value Type |MUST|MAY| NOT | NOT| 645 +-------------------------------------------------+----+---+------+----+ 646 |Session-Group-Info TBD1 Grouped | | P | | V | 647 |Session-Group-Control-Vector TBD2 Unsigned32 | | P | | V | 648 |Session-Group-Id TBD3 OctetString | | P | | V | 649 |Group-Response-Action TBD4 Unsigned32 | | P | | V | 650 |Session-Group-Capability-Vector TBD5 Unsigned32 | | P | | V | 651 +-------------------------------------------------+----+---+------+----+ 653 AVPs for the Diameter Group Signaling 655 7.1. Session-Group-Info AVP 657 The Session-Group-Info AVP (AVP Code TBD1) is of type Grouped. It 658 contains the identifier of the session group as well as an indication 659 of the node responsible for session group identifier assignment. 661 Session-Group-Info ::= < AVP Header: TBD1 > 662 < Session-Group-Control-Vector > 663 [ Session-Group-Id ] 664 * [ AVP ] 666 7.2. Session-Group-Control-Vector AVP 668 The Session-Group-Control-Vector AVP (AVP Code TBD2) is of type 669 Unsigned32 and contains a 32-bit flags field to control the group 670 assignment at session-group aware nodes. 672 The following capabilities are defined in this document: 674 SESSION_GROUP_ALLOCATION_ACTION (0x00000001) 676 This flag indicates the action to be performed for the identified 677 session. When this flag is set, it indicates that the identified 678 Diameter session is to be assigned to the session group as 679 identified by the Session-Group-Id AVP or the session's assignment 680 to the session group identified in the Session-Group-Id AVP is 681 still valid. When the flag is cleared, the identified Diameter 682 session is to be removed from at least one session group. When 683 the flag is cleared and the Session-Group-Info AVP identifies a 684 particular session group in the associated Session-Group-Id AVP, 685 the session is to be removed solely from the identified session 686 group. When the flag is cleared and the Session-Group-Info AVP 687 does not identify a particular session group (Session-Group-Id AVP 688 is absent), the identified Diameter session is to be removed from 689 all session groups, to which it has been previously assigned. 691 SESSION_GROUP_STATUS_IND (0x00000010) 693 This flag indicates the status of the session group identified in 694 the associated Session-Group-Id AVP. The flag is set when the 695 identified session group has just been created or is still active. 696 If the flag is cleared, the identified session group is deleted 697 and the associated Session-Group-Id is released. If the Session- 698 Group-Info AVP does not comprise a Session-Group-Id AVP, this flag 699 is meaningless and MUST be ignored by the receiver. 701 7.3. Session-Group-Id AVP 703 The Session-Group-Id AVP (AVP Code TBD3) is of type UTF8String and 704 identifies a group of Diameter sessions. 706 The Session-Group-Id MUST be globally and eternally unique, as it is 707 meant to uniquely identify a group of Diameter sessions without 708 reference to any other information. 710 The default format of the Session-Group-id MUST comply to the format 711 recommended for a Session-Id, as defined in the section 8.8 of the 712 [RFC6733]. The DiameterIdentity element of the Session-Group-Id MUST 713 identify the Diameter node, which owns the session group. 715 7.4. Group-Response-Action AVP 717 The Group-Response-Action AVP (AVP Code TBD4) is of type Unsigned32 718 and contains a 32-bit address space representing values indicating 719 how the peer SHOULD issue follow up exchanges in response to a 720 command which impacts multiple sessions. The following values are 721 defined by this application: 723 ALL_GROUPS (1) 724 Follow up exchanges should be performed with a single message 725 exchange for all impacted groups. 727 PER_GROUP (2) 728 Follow up exchanges should be performed with a message exchange 729 for each impacted group. 731 PER_SESSION (3) 732 Follow up exchanges should be performed with a message exchange 733 for each impacted session. 735 7.5. Session-Group-Capability-Vector AVP 737 The Session-Group-Capability-Vector AVP (AVP Code TBD5) is of type 738 Unsigned32 and contains a 32-bit flags field to indicate capabilities 739 in the context of session-group assignment and group operations. 741 The following capabilities are defined in this document: 743 BASE_SESSION_GROUP_CAPABILITY (0x00000001) 745 This flag indicates the capability to support session grouping and 746 session group operations according to this specification. 748 8. Result-Code AVP Values 750 This document does not define new Result-Code [RFC6733] values for 751 existing applications, which are extended to support group commands. 752 Specification documents of new applications, which will have 753 intrinsic support for group commands, may specify new Result-Codes. 755 9. IANA Considerations 757 This section contains the namespaces that have either been created in 758 this specification or had their values assigned to existing 759 namespaces managed by IANA. 761 9.1. AVP Codes 763 This specification requires IANA to register the following new AVPs 764 from the AVP Code namespace defined in [RFC6733]. 766 o Session-Group-Info 768 o Session-Group-Control-Vector 770 o Session-Group-Id 772 o Group-Response-Action 774 o Session-Group-Capability-Vector 776 The AVPs are defined in Section 7. 778 10. Security Considerations 780 TODO 782 11. Acknowledgments 784 The authors of this document want to thank Ben Campbell and Eric 785 McMurry for their valuable comments to early versions of this draft. 787 12. Normative References 789 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 790 Requirement Levels", BCP 14, RFC 2119, March 1997. 792 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 793 "Diameter Network Access Server Application", RFC 4005, 794 August 2005. 796 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 797 "Diameter Base Protocol", RFC 6733, October 2012. 799 Appendix A. Session Management -- Exemplary Session State Machines 801 A.1. Authorization Session State Machine 803 Section 8.1 in [RFC6733] defines a set of finite state machines, 804 representing the life cycle of Diameter sessions, and which MUST be 805 observed by all Diameter implementations that make use of the 806 authentication and/or authorization portion of a Diameter 807 application. This section defines the additional state transitions 808 related to the processing of the new commands which may impact 809 multiple sessions. 811 The group membership is session state and therefore only those state 812 machines from [RFC6733] in which the server is maintaining session 813 state are relevant in this document. As in [RFC6733], the term 814 Service-Specific below refers to a message defined in a Diameter 815 application (e.g., Mobile IPv4, NASREQ). 817 The following state machine is observed by a client when state is 818 maintained on the server. State transitions which are unmodified 819 from [RFC6733] are not repeated here. 821 A Diameter group command in the following tables is differentiated 822 from a single-session related command by a preceding 'G'. A Group 823 Re-Auth Request, which applies to one or multiple session groups, has 824 been exemplarily described in Section 6.1. Such Group RAR command is 825 denoted as 'GRAR' in the following table. The same notation applies 826 to other commands as per [RFC6733]. 828 CLIENT, STATEFUL 829 State Event Action New State 830 --------------------------------------------------------------- 831 Idle Client or Device Requests Send Pending 832 access service 833 specific 834 auth req 835 optionally 836 including 837 groups 839 Open GASR received with Send GASA Discon 840 Group-Response-Action with 841 = ALL_GROUPS, Result-Code 842 session is assigned to = SUCCESS, 843 received group(s) and Send GSTR. 844 client will comply with 845 request to end the session 847 Open GASR received with Send GASA Discon 848 Group-Response-Action with 849 = PER_GROUPS, Result-Code 850 session is assigned to = SUCCESS, 851 received group(s) and Send GSTR 852 client will comply with per group 853 request to end the session 854 Open GASR received with Send GASA Discon 855 Group-Response-Action with 856 = PER_SESSION, Result-Code 857 session is assigned to = SUCCESS, 858 received group(s) and Send STR 859 client will comply with per session 860 request to end the session 862 Open GASR received, Send GASA Open 863 client will not comply with with 864 request to end all session Result-Code 865 in received group(s) != SUCCESS 867 Discon GSTA Received Discon. Idle 868 user/device 870 Open GRAR received with Send GRAA, Pending 871 Group-Response-Action Send 872 = ALL_GROUPS, service 873 session is assigned to specific 874 received group(s) and group 875 client will perform re-auth req 876 subsequent re-auth 878 Open GRAR received with Send GRAA, Pending 879 Group-Response-Action Send 880 = PER_GROUP, service 881 session is assigned to specific 882 received group(s) and group 883 client will perform re-auth req 884 subsequent re-auth per group 886 Open GRAR received with Send GRAA, Pending 887 Group-Response-Action Send 888 = PER_SESSION, service 889 session is assigned to specific 890 received group(s) and re-auth req 891 client will perform per session 892 subsequent re-auth 894 Open GRAR received and client will Send GRAA Idle 895 not perform subsequent with 896 re-auth Result-Code 897 != SUCCESS, 898 Discon. 899 user/device 901 Pending Successful service-specific Provide Open 902 group re-authorization answer service 903 received. 905 Pending Failed service-specific Discon. Idle 906 group re-authorization answer user/device 907 received. 909 The following state machine is observed by a server when it is 910 maintaining state for the session. State transitions which are 911 unmodified from [RFC6733] are not repeated here. 913 SERVER, STATEFUL 914 State Event Action New State 915 --------------------------------------------------------------- 917 Idle Service-specific authorization Send Open 918 request received, and user successful 919 is authorized service 920 specific 921 answer 922 optionally 923 including 924 groups 926 Open Server wants to terminate Send GASR Discon 927 group(s) 929 Discon GASA received Cleanup Idle 931 Any GSTR received Send GSTA, Idle 932 Cleanup 934 Open Server wants to reauth Send GRAR Pending 935 group(s) 937 Pending GRAA received with Result-Code Update Open 938 = SUCCESS session(s) 940 Pending GRAA received with Result-Code Cleanup Idle 941 != SUCCESS session(s) 943 Open Service-specific group Send Open 944 re-authoization request successful 945 received and user is service 946 authorized specific 947 group 948 re-auth 949 answer 951 Open Service-specific group Send Idle 952 re-authorization request failed 953 received and user is service 954 not authorized specific 955 group 956 re-auth 957 answer, 958 cleanup 960 Authors' Addresses 962 Mark Jones 964 Email: mark@azu.ca 966 Marco Liebsch 968 Email: marco.liebsch@neclab.eu 970 Lionel Morand 972 Email: lionel.morand@orange.com