idnits 2.17.1 draft-ietf-dime-group-signaling-03.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 808 has weird spacing: '...ly with wit...' == Line 847 has weird spacing: '... answer servi...' == Line 851 has weird spacing: '... answer user/...' -- The document date (February 15, 2014) is 3720 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 M. Jones 3 Extensions (DIME) M. Liebsch 4 Internet-Draft L. Morand 5 Intended status: Standards Track February 15, 2014 6 Expires: August 19, 2014 8 Diameter Group Signaling 9 draft-ietf-dime-group-signaling-03.txt 11 Abstract 13 In large network deployments, a single Diameter peer can support over 14 a million concurrent Diameter sessions. Recent use cases have 15 revealed the need for Diameter peers to apply the same operation to a 16 large group of Diameter sessions concurrently. The Diameter base 17 protocol commands operate on a single session so these use cases 18 could result in many thousands of command exchanges to enforce the 19 same operation on each session in the group. In order to reduce 20 signaling, it would be desirable to enable bulk operations on all (or 21 part of) the sessions managed by a Diameter peer using a single or a 22 few command exchanges. This document specifies the Diameter protocol 23 extensions to achieve this signaling optimization. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 19, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. Building and Modifying Session Groups . . . . . . . . . . 6 63 3.2. Issuing Group Commands . . . . . . . . . . . . . . . . . . 6 64 3.3. Permission Model . . . . . . . . . . . . . . . . . . . . . 7 65 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 66 4.1. Session Grouping . . . . . . . . . . . . . . . . . . . . . 8 67 4.1.1. Group assignment at session initiation . . . . . . . . 8 68 4.1.2. Removing a session from a session group . . . . . . . 10 69 4.1.3. Mid-session group assignment modifications . . . . . . 11 70 4.2. Session Grouping Capability Discovery . . . . . . . . . . 12 71 4.2.1. Implicit Capability Discovery . . . . . . . . . . . . 12 72 4.2.2. Explicit Capability Discovery . . . . . . . . . . . . 12 73 4.3. Releasing a Session Group Identifier . . . . . . . . . . . 12 74 4.4. Performing Group Operations . . . . . . . . . . . . . . . 13 75 4.4.1. Sending Group Commands . . . . . . . . . . . . . . . . 13 76 4.4.2. Receiving Group Commands . . . . . . . . . . . . . . . 13 77 4.4.3. Error Handling for Group Commands . . . . . . . . . . 14 78 4.4.4. Single-Session Fallback . . . . . . . . . . . . . . . 14 79 5. Operation with Proxies Agents . . . . . . . . . . . . . . . . 15 80 6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 16 81 6.1. Formatting Example: Group Re-Auth-Request . . . . . . . . 16 82 7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 17 83 7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . . 17 84 7.2. Session-Group-Feature-Vector AVP . . . . . . . . . . . . . 17 85 7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . . 18 86 7.4. Session-Group-Action AVP . . . . . . . . . . . . . . . . . 18 87 8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 19 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 89 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 20 90 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 91 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 92 12. Normative References . . . . . . . . . . . . . . . . . . . . . 23 93 Appendix A. Session Management -- Exemplary Session State 94 Machines . . . . . . . . . . . . . . . . . . . . . . 24 95 A.1. Authorization Session State Machine . . . . . . . . . . . 24 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 99 1. Introduction 101 In large network deployments, a single Diameter peer can support over 102 a million concurrent Diameter sessions. Recent use cases have 103 revealed the need for Diameter peers to apply the same operation to a 104 large group of Diameter sessions concurrently. For example, a policy 105 decision point may need to modify the authorized quality of service 106 for all active users having the same type of subscription. The 107 Diameter base protocol commands operate on a single session so these 108 use cases could result in many thousands of command exchanges to 109 enforce the same operation on each session in the group. In order to 110 reduce signaling, it would be desirable to enable bulk operations on 111 all (or part of) the sessions managed by a Diameter peer using a 112 single or a few command exchanges. 114 This document describes mechanisms for grouping Diameter sessions and 115 applying Diameter commands, such as performing re-authentication, re- 116 authorization, termination and abortion of sessions to a group of 117 sessions. This document does not define a new Diameter application. 118 Instead it defines mechanisms, commands and AVPs that may be used by 119 any Diameter application that requires management of groups of 120 sessions. 122 These mechanisms take the following design goals and features into 123 account: 125 o Minimal impact to existing applications 127 o Extension of existing commands' CCF with optional AVPs to enable 128 grouping and group operations 130 o Fallback to single session operation 132 o Implicit discovery of capability to support grouping and group 133 operations 135 2. Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119 [RFC2119]. 141 This document uses terminology defined [RFC6733]. 143 3. Protocol Overview 145 3.1. Building and Modifying Session Groups 147 Client and Server can add a new Diameter session to a group, e.g. in 148 case the subscription profile of the associated user has similar 149 characteristics as the profile of other users whose Diameter session 150 has been added to one or multiple groups. Such similarities can be 151 for example maximum bandwidth bounds of each user in the a group. 152 These users may share resources of, e.g., an access multiplexer, 153 together with other users. Runtime adjustments in the granted 154 bandwidth bounds or other Quality of Service related attributes can 155 be accomplished for the whole group by identifying the group in the 156 Diameter group command. 158 In case a user's subscription profile changes during runtime, either 159 node, a Diameter Server or Diameter client, may decide to remove this 160 user's Diameter session from the session group. The user's Diameter 161 session can be assigned to a different group, whose adjusted profile 162 matches the one of the different group. Both groups, the user's 163 previous group and its new group, will be modified mid-session. 165 In case of mobile users, a change in the node implementing the 166 Diameter client can happen, which has impact to a group of sessions a 167 particular pair of Diameter client and server has in common. Due to 168 mobility, the mobile user's session may get transferred to a new 169 Diameter client during runtime without mandating from-scratch 170 authorization. Such scenario necessitates mid-session modification. 172 3.2. Issuing Group Commands 174 A policy decision point may decide to terminate a group of sessions, 175 e.g. based on previous agreement for temporary authorization to 176 access a system. All Diameter sessions of associated users with such 177 temporarily granted access will be added to a single Diameter session 178 group. After the time limit for the temporary authorization has been 179 reached, the policy decision point can issue a single Session 180 Termination Request (STR) to the policy enforcement point. The STR 181 command identifies the group of Diameter sessions which are to be 182 terminated. The policy enforcement point treats the STR as group 183 command and initiates termination of all sessions in the group. 184 Subsequently, the policy enforcement point confirms successful 185 termination of these sessions to the policy decision point by sending 186 a single Session Termination Answer (STA) command which includes the 187 identifier of the group. 189 3.3. Permission Model 191 A permission model in the context of this draft defines the 192 permission of Diameter nodes to build new session groups, to add/ 193 remove a session to/from a session group and to delete an existing 194 session group. 196 This specification follows the most flexible model where both, a 197 Diameter client and a Diameter server can build a new group and 198 assign a new identifier to that session group. When a Diameter node 199 decides to issue a new session group, e.g. to group all sessions 200 which share certain characteristics, the node must identify itself in 201 the DiameterIdentity element of the session group identifier 202 (Section 7.3) as owner of the group. The permission model as per 203 this specification solely constrains the permission to close a 204 session group and release the associated identifier to the group 205 owner. 207 Irrespective of the group ownership, as per this specification any 208 Diameter node has the permission to add/remove a session to/from an 209 existing session group. Also the modification of groups in terms of 210 moving a session from one session group to a different session group 211 is permitted to any Diameter node. The enforcement of a more 212 constrained model is left to the application and implementation, 213 which must then ensure that relevant Diameter nodes have the same 214 view of the permission model, either through administrative 215 configuration or protocol-based capability discovery. Details about 216 enforcing a 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 4. Protocol Description 223 4.1. Session Grouping 225 Either Diameter peer can initiate assigning a session to a single or 226 multiple session groups. Modification of a group by removing or 227 adding a single or multiple user sessions can be initiated and 228 performed at runtime by either Diameter peer. Diameter AAA 229 applications typically assign client and server roles to the Diameter 230 peers, which are referred to as relevant Diameter peers to utilize 231 session grouping and issue group commands. Section 5 describes 232 particularities about session grouping and performing group commands 233 when relay agents or proxies are deployed. 235 Diameter peers, which are group-aware, must store and maintain a list 236 of all session groups to which at least one session, for which the 237 peer holds a state, is assigned. Along with the group's Session-Id, 238 a list of Diameter sessions, which are assigned to the group, must be 239 stored. This specification assumes that a session group is built and 240 handled between pairs of Diameter nodes. Clients and servers MUST 241 maintain Diameter state of individual sessions grouped in a session 242 group. 244 4.1.1. Group assignment at session initiation 246 To assign a session to a group at session initiation, a Diameter 247 client sends a service specific request, e.g. NASREQ AAR [RFC4005], 248 containing one or more group identifiers. A Diameter client as 249 sender of a command for session initiation can determine one or 250 multiple groups to which the new session should be assigned. Each of 251 these groups need to be identified by a unique Session-Group-Id 252 contained in a separate Session-Group-Info AVP as specified in 253 Section 7. 255 The client may choose one or multiple sessions from a list of 256 existing session groups, irrespective of the group ownership. 257 Alternatively, the client may decide to create a new group and 258 identify itself in the DiameterIdentity element of the 259 Group-Session-Id AVP as per Section 7.3 261 The client MUST set the SESSION_GROUP_ALLOCATION_ACTION of the 262 Session-Group-Feature-Vector AVP in each appended Session-Group-Info 263 AVP to indicate that the identified session should be added to the 264 identified session group. 266 If the Diameter server receives a command request from a Diameter 267 client and the command comprises at least one Session-Group-Info AVP 268 having the SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group- 269 Feature-Vector AVP set, the server must add the new session to each 270 of the one or multiple identified session groups. In case one or 271 multiple identified session groups are not know to the server, the 272 server must add the one or multiple new groups to its locally 273 maintained list of session groups. When sending the response to the 274 client, e.g. a service-specific auth response as per NASREQ AAA 275 [RFC4005], the server must include all Session-Group-Info AVPs as 276 received in the client's request. 278 In addition to the one or multiple session groups identified in the 279 client's request, the server may decide to add the new session to one 280 or multiple additional groups. In such case, the server add to the 281 response additional Session-Group-Info AVPs, each identifying a 282 session group, to which the server has assigned the new session. 283 Each of the Session-Group-Info AVP added by the server, the 284 SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Feature- 285 Vector AVP must be set. 287 If the Diameter server receives a command for session initiation from 288 a Diameter client and the command comprises at least one Session- 289 Group-Info AVP, but the one or multiple Session-Group-Info AVP do not 290 identify any session group to which the session should be assigned, 291 the server may assign the new session to one or multiple session 292 groups. Each session group, to which the server assigns the new 293 session, must be identified in a separate Session-Group-Info AVP 294 having the SESSION_GROUP_ALLOCATION_ACTION flag of the associated 295 Session-Group-Vector AVP set. 297 If the Diameter client receives a response to its previously issued 298 request from the server and the response comprises at least one 299 Session-Group-Info AVP having the SESSION_GROUP_ALLOCATION_ACTION 300 flag of the associated Session-Group-Feature-Vector AVP set, the 301 client must add the new session to all session groups as identified 302 in the one or multiple Session-Group-Info AVPs. 304 A Diameter server receiving a command for session initiation which 305 includes at least one Session-Group-Info AVP but the server does not 306 understand the semantics of this optional AVP because it does not 307 support group operations according to the specification in this 308 document, MUST ignore the optional group operations specific AVPs and 309 proceed with processing the command for a single session. 311 A Diameter client, which sent a request for session initiation to a 312 Diameter server and appended a single or multiple Session-Group-Id 313 AVPs but cannot find any Session-Group-Info AVP in the associated 314 response from the Diameter server proceeds with processing the 315 command for a single session. Furthermore, the client keeps a log to 316 remember that the server is not able to perform group operations. 318 4.1.2. Removing a session from a session group 320 When a Diameter client decides to remove a session from a particular 321 session group, the client sends a service-specific re-authorization 322 request to the server and adds one Session-Group-Info AVP to the 323 request for each session group, from which the client wants to remove 324 the session. The session, which is to be removed from a group, is 325 identified in the Session-Id AVP of the command request. The 326 SESSION_GROUP_ALLOCATION_ACTION flag of the Session-Group-Feature- 327 Vector AVP in each Session-Group-Info AVP must be cleared to indicate 328 removal of the session from the session group identified in the 329 associated Session-Group-id AVP. 331 When a Diameter client decides to remove a session from all session 332 groups, to which the session has been previously assigned, the client 333 sends a service-specific re-authorization request to the server and 334 adds a single Session-Group-Info AVP to the request which has the 335 SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id 336 AVP omitted. The session, which is to be removed from all groups, to 337 which the session has been previously assigned, is identified in the 338 Session-Id AVP of the command request. 340 If the Diameter server receives a request from the client which has 341 at least one Session-Group-Info AVP appended with the 342 SESSION_GROUP_ALLOCATION_ACTION flag cleared, the server must remove 343 the session from the session group identified in the associated 344 Session-Group-Id AVP. If the request comprises at least one Session- 345 Group-info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag cleared 346 and no Session-Id AVP present, the server must remove the session 347 from all session groups to which the session has been previously 348 assigned. The server must include in its response to the requesting 349 client all Session-Group-Id AVPs as received in the request. 351 When the Diameter server decides to remove a session from one or 352 multiple particular session groups or from all session groups to 353 which the session has been assigned beforehand, the server sends a 354 Re-Authorization Request (RAR) to the client, indicating the session 355 in the requests Session-Id AVP. The client sends a Re-Authorization 356 Answer (RAA) to respond to the server's request. The client 357 subsequently sends service-specific re-authorization request 358 containing one or multiple Session-Group-Info AVPs, each indicating a 359 session group, to which the session had been previously assigned. To 360 indicate removal of the indicated session from one or multiple 361 session groups, the server sends a service-specific auth response to 362 the client, containing a list of Session-Group-Info AVPs with the 363 SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id 364 AVP identifying the session group, from which the session should be 365 removed. The server MAY include to the service-specific auth 366 response a list of Session-Group-Info AVPs with the 367 SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP 368 identifying session groups to which the session remains subscribed. 369 In case the server decides to remove the identified session from all 370 session groups, to which the session has been previously assigned, 371 the server includes in the service-specific auth response at least 372 one Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION 373 flag cleared and Session-Group-Info AVP absent. 375 4.1.3. Mid-session group assignment modifications 377 Either Diameter peer can modify the group membership of an active 378 Diameter session, irrespective of the group ownership. 380 To update an assigned group mid-session, a Diameter client sends a 381 service-specific re-authorization request to the server, containing 382 one or multiple Session-Group-Info AVPs with the 383 SESSION_GROUP_ALLOCATION_ACTION flag set and the Session-Group-Id AVP 384 present, identifying the session group to which the session should be 385 added. With the same message, the client may send one or multiple 386 Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag 387 cleared and the Session-Group-Id AVP identifying the session group 388 from which the identified session is to be removed. To remove the 389 session from all previously assigned session groups, the client 390 includes at least one Session-Group-Info AVP with the 391 SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id 392 AVP present. When the server received the service-specific re- 393 authorization request, it must update its locally maintained view of 394 the session groups for the identified session according to the 395 appended Session-Group-Info AVPs. The server sends a service- 396 specific auth response to the client containing one or multiple 397 Session-Group-Info AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag 398 set and the Session-Group-Id AVP identifying the new session group to 399 which the identified session has been added. 401 When a Diameter server enforces an update to the assigned groups mid- 402 session, it sends a Re-Authorization Request (RAR) message to the 403 client identifying the session, for which the session group lists are 404 to be updated. The client responds with a Re-Authorization Answer 405 (RAA) message. The client subsequently sends service-specific re- 406 authorization request containing one or multiple Session-Group-Info 407 AVPs with the SESSION_GROUP_ALLOCATION_ACTION flag set and the 408 Session-Group-Id AVP identifying the session group to which the 409 session had been previously assigned. The server responds with a 410 service-specific auth response and includes one or multiple Session- 411 Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag set and 412 the Session-Group-Id AVP identifying the session group, to which the 413 identified session is to be added. With the same response message, 414 the server may send one or multiple Session-Group-Info AVPs with the 415 SESSION_GROUP_ALLOCATION_ACTION flag cleared and the Session-Group-Id 416 AVP identifying the session groups from which the identified session 417 is to be removed. When server wants to remove the session from all 418 previously assigned session groups, it send at least on Session- 419 Group-Info AVP with the response having the 420 SESSION_GROUP_ALLOCATION_ACTION flag cleared and no Session-Group-Id 421 AVP present. 423 4.2. Session Grouping Capability Discovery 425 4.2.1. Implicit Capability Discovery 427 By appending at least one Session-Group-Info AVP, the Diameter client 428 announces its capability to support group operations according to the 429 specification in this document to the addressed Diameter server. If 430 the Diameter client supports group operations, it MUST append at 431 least one Session-Group-Info AVP to announce its capability to 432 support group operations. 434 A session-group aware Diameter server receiving a command for session 435 initiation which includes at least one Session-Group-Info AVP learns 436 about the sender's capability to support group operations. 438 By appending at least one Session-Group-Id AVP, the Diameter server 439 announces its capability to support group operations according to the 440 specification in this document to the addressed Diameter client. 442 4.2.2. Explicit Capability Discovery 444 New Diameter applications may consider support for Diameter session 445 grouping and for performing group commands during the standardization 446 process. Such applications provide intrinsic support for the support 447 of group commands and announce this capability through the assigned 448 application ID. 450 4.3. Releasing a Session Group Identifier 452 To close a session group and release the associated Session-Group-Id 453 value, the owner of a session group appends a single Session-Group- 454 Info AVP having the SESSION_GROUP_STATUS_IND flag cleared and the 455 Session-Group-Id AVP identifying the session group, which is to be 456 closed. The SESSION_GROUP_ALLOCATION_ACTION flag of the associated 457 Session-Group-Feature-Vector AVP MUST be cleared. 459 4.4. Performing Group Operations 461 4.4.1. Sending Group Commands 463 Either Diameter peer can request the recipient of a request to 464 process an associated command for all sessions being assigned to one 465 or multiple groups by identifying these groups in the request. The 466 sender of the request appends for each group, to which the command 467 applies, a Session-Group-Info AVP including the Session-Group-Id AVP 468 to identify the associated session group. Both, the 469 SESSION_GROUP_ALLOCATION_ACTION flag as well as the 470 SESSION_GROUP_STATUS_IND flag must be set. 472 If the CCF of the request mandates a Session-Id AVP, the Session-Id 473 AVP MUST identify a single session which is assigned to at least one 474 of the groups being identified in the appended Session-Group-Id AVPs. 476 The sender of the request can indicate to the receiver how follow up 477 message exchanges should be performed by appending a Session-Group- 478 Action AVP. If the sender wants the receiver to perform follow up 479 exchanges with a single command for all impacted groups, the sender 480 sets the value of the Session-Group-Action AVP to ALL_GROUPS (1). If 481 follow up message exchanges should be performed on a per-group basis 482 in case multiple groups are identified in the group command, the 483 value of the Session-Group-Action AVP is set to PER_GROUP (2). A 484 value set to PER_SESSION (3) indicates to the receiver that all 485 follow up exchanges should be performed using a single message for 486 each impacted session. 488 If the sender wants the receiver of the request to process the 489 associated command solely for a single session does not append any 490 group identifier, but identifies the relevant session in the 491 Session-Id AVP. 493 4.4.2. Receiving Group Commands 495 A Diameter peer receiving a request to process a command for a group 496 of sessions identifies the relevant groups according to the appended 497 Session-Group-Id AVP in the Session-Group-Info AVP. If the received 498 request identifies multiple groups in multiple appended Session- 499 Group-Id AVPs, the receiver should process the associated command for 500 each of these groups. if a session has been assigned to more than one 501 of the identified groups, the receiver must process the associated 502 command only once per session. 504 The Diameter peer receiving a request which requests performing the 505 command to at least on session group SHOULD perform follow up message 506 exchanges according to the value identified in the Session-Group-Info 507 AVP. 509 4.4.3. Error Handling for Group Commands 511 When a Diameter peer receives a request to process a command for one 512 or more session groups and the result of processing the command is an 513 error that applies to all sessions in the identified groups, an 514 associated protocol error must be returned to the source of the 515 request. In such case, the sender of the request MUST fall back to 516 single-session processing and the session groups, which have been 517 identified in the group command, MUST be closed according to the 518 procedure described in Section 4.3. 520 When a Diameter peer receives a request to process a command for one 521 or more session groups and the result of processing the command 522 succeeds for some sessions identified in one or multiple session 523 groups, but fails for one or more sessions, the Result-Code AVP in 524 the response message SHOULD indicate DIAMETER_LIMITED_SUCCESS as per 525 Section 7.1.2 of [RFC6733]. In case of limited success, the 526 sessions, for which the processing of the group command failed, MUST 527 be identified using a Failed-AVP AVP as per Session 7.5 of [RFC6733]. 529 4.4.4. Single-Session Fallback 531 Either Diameter peer, a Diameter client or a Diameter server, can 532 fall back to single session operation by ignoring and omitting the 533 optional group session-specific AVPs. Fallback to single-session 534 operation is performed by processing the Diameter command solely for 535 the session identified in the mandatory Session-Id AVP. The response 536 to the group command must not identify any group but identify solely 537 the single session for which the command has been processed. 539 5. Operation with Proxies Agents 541 This specification assumes in case of a present stateful Proxy Agent 542 between a Diameter client and a Diameter server that the Proxy Agent 543 is aware of session groups and session group handling. The Proxy 544 MUST reflect the state of each session associated with a session 545 group according to the result of a group command operated between a 546 Diameter client and a server. 548 In case a Proxy Agent manipulates session groups, it MUST maintain 549 consistency of session groups between a client and a server. This 550 applies to deployment where the Proxy Agent utilizes session grouping 551 and performing group commands with, for example, a Diameter server, 552 whereas the Diameter client is not group-aware. The same applies to 553 deployment where all nodes, the Diameter client and server, as well 554 as the Proxy Agent are group-aware but the Proxy Agent manipulates 555 groups, e.g. to adopt different administrative policies that apply to 556 the client's domain and the server's domain. 558 6. Commands Formatting 560 This document does not specify new Diameter commands to enable group 561 operations, but relies on command extensibility capability provided 562 by the Diameter Base protocol. This section provides the guidelines 563 to extend the CCF of existing Diameter commands with optional AVPs to 564 enable the recipient of the command to perform the command to all 565 sessions associated with the identified group(s). 567 6.1. Formatting Example: Group Re-Auth-Request 569 A request that one or more groups of users are re-authentication is 570 issued by appending one or multiple Session-Group-Id AVP(s) to the 571 Re-Auth-Request (RAR). The one or multiple Session-Group-Id AVP(s) 572 identify the associated group(s) for which the group re- 573 authentication has been requested. The recipient of the group 574 command initiates re-authentication for all users associated with the 575 identified group(s). Furthermore, the sender of the group re- 576 authentication request appends a Session-Group-Action AVP to provide 577 more information to the receiver of the command about how to 578 accomplish the group operation. 580 The value of the mandatory Session-Id AVP MUST identify a session 581 associated with a single user, which is assigned to at least one of 582 the groups being identified in the appended Session-Group-Id AVPs. 584 ::= < Diameter Header: 258, REQ, PXY > 585 < Session-Id > 586 { Origin-Host } 587 { Origin-Realm } 588 { Destination-Realm } 589 { Destination-Host } 590 { Auth-Application-Id } 591 { Re-Auth-Request-Type } 592 [ User-Name ] 593 [ Origin-State-Id ] 594 * [ Proxy-Info ] 595 * [ Route-Record ] 596 * [ Session-Group-Id ] 597 [ Session-Group-Action ] 598 * [ AVP ] 600 7. Attribute-Value-Pairs (AVP) 602 +--------------------+ 603 | AVP Flag rules | 604 +----+---+------+----+ 605 AVP | | |SHOULD|MUST| 606 Attribute Name Code Value Type |MUST|MAY| NOT | NOT| 607 +-------------------------------------------------+----+---+------+----+ 608 |Session-Group-Info TBD1 Grouped | | P | | V | 609 |Session-Group-Feature-Vector TBD2 Unsigned32 | | P | | V | 610 |Session-Group-Id TBD3 OctetString | | P | | V | 611 |Session-Group-Action TBD4 Unsigned32 | | P | | V | 612 +-------------------------------------------------+----+---+------+----+ 614 AVPs for the Diameter Group Signaling 616 7.1. Session-Group-Info AVP 618 The Session-Group-Info AVP (AVP Code TBD1) is of type Grouped. It 619 contains the identifier of the session group as well as an indication 620 of the node responsible for session group identifier assignment. 621 Session-Group-Info ::= < AVP Header: TBD1 > 622 < Session-Group-Feature-Vector > 623 [ Session-Group-Id ] 624 * [ AVP ] 626 7.2. Session-Group-Feature-Vector AVP 628 The Session-Group-Feature-Vector AVP (AVP Code TBD2) is of type 629 Unsigned32 and contains a 32-bit flags field of capabilities 630 supported by the session-group aware node. 632 The following capabilities are defined in this document: 634 SESSION_GROUP_ALLOCATION_ACTION (0x00000001) 636 This flag indicates the action to be performed for the identified 637 session. When this flag is set, it indicates that the identified 638 Diameter session is to be added to the session group as identified 639 by the Session-Group-Id AVP or the session's assignement to the 640 session group identified in the Session-Group-Id AVP is still 641 valid. When the flag is cleared, the identified Diameter session 642 is to be removed from at least one session group. When the flag 643 is cleared and the Session-Group-Info AVP identifies a particular 644 session group in the associated Session-Group-Id AVP, the session 645 is to be removed solely from the identified session group. When 646 the flag is cleared and the Session-Group-Info AVP does not 647 identify a particular session group (Session-Group-Id AVP is 648 absent), the identified Diameter session is to be removed from all 649 session groups, to which it has been previously assigned. 651 SESSION_GROUP_STATUS_IND (0x00000010) 653 This flag indicates the status of the session group identified in 654 the associated Session-Group-Id AVP. The flag is set when the 655 identified session group has just been created or is still active. 656 If the flag is cleared, the identified session group is closed and 657 the associated Session-Group-Id is released. If the Session- 658 Group-Info AVP does not comprise a Session-Group-Id AVP, this flag 659 is meaningless and MUST be ignored by the receiver. 661 7.3. Session-Group-Id AVP 663 The Session-Group-Id AVP (AVP Code TBD3) is of type UTF8String and 664 identifies a group of Diameter sessions. 666 The Session-Group-Id MUST be globally and eternally unique, as it is 667 meant to uniquely identify a group of Diameter sessions without 668 reference to any other information. 670 The default format of the Session-Group-id MUST comply to the format 671 recommended for a Session-Id, as defined in the section 8.8 of the 672 [RFC6733]. The DiameterIdentity element of the Session-Group-Id MUST 673 identify the Diameter node, which owns the session group. 675 7.4. Session-Group-Action AVP 677 The Session-Group-Action AVP (AVP Code TBD4) is of type Unsigned32 678 and contains a 32-bit address space representing values indicating 679 how the peer SHOULD issue follow up exchanges in response to a 680 command which impacts mulitple sessions. The following values are 681 defined by this application: 683 ALL_GROUPS (1) 684 Follow up exchanges should be performed with a single message 685 exchange for all impacted groups. 687 PER_GROUP (2) 688 Follow up exchanges should be performed with a message exchange 689 for each impacted group. 691 PER_SESSION (3) 692 Follow up exchanges should be performed with a message exchange 693 for each impacted session. 695 8. Result-Code AVP Values 697 This document does not define new Result-Code [RFC6733] values for 698 existing applications, which are extended to support group commands. 699 Specification documents of new applications, which will have 700 intrinsic support for group commands, may specify new Result-Codes. 702 9. IANA Considerations 704 This section contains the namespaces that have either been created in 705 this specification or had their values assigned to existing 706 namespaces managed by IANA. 708 9.1. AVP Codes 710 This specification requires IANA to register the following new AVPs 711 from the AVP Code namespace defined in [RFC6733]. 713 o Session-Group-Info 715 o Session-Group-Feature-Vector 717 o Session-Group-Id 719 o Session-Group-Action 721 The AVPs are defined in Section 7. 723 10. Security Considerations 725 TODO 727 11. Acknowledgments 729 The authors of this document want to thank Ben Campbell and Eric 730 McMurry for their valuable comments to early versions of this draft. 732 12. Normative References 734 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 735 Requirement Levels", BCP 14, RFC 2119, March 1997. 737 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 738 "Diameter Network Access Server Application", RFC 4005, 739 August 2005. 741 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 742 "Diameter Base Protocol", RFC 6733, October 2012. 744 Appendix A. Session Management -- Exemplary Session State Machines 746 A.1. Authorization Session State Machine 748 Section 8.1 in [RFC6733] defines a set of finite state machines, 749 representing the life cycle of Diameter sessions, and which MUST be 750 observed by all Diameter implementations that make use of the 751 authentication and/or authorization portion of a Diameter 752 application. This section defines the additional state transitions 753 related to the processing of the new commands which may impact 754 multiple sessions. 756 The group membership is session state and therefore only those state 757 machines from [RFC6733] in which the server is maintaining session 758 state are relevant in this document. As in [RFC6733], the term 759 Service-Specific below refers to a message defined in a Diameter 760 application (e.g., Mobile IPv4, NASREQ). 762 The following state machine is observed by a client when state is 763 maintained on the server. State transitions which are unmodified 764 from [RFC6733] are not repeated here. 766 A Diameter group command in the following tables is differentiated 767 from a single-session related command by a preceding 'G'. A Group 768 Re-Auth Request, which applies to one or multiple session groups, has 769 been exemplarily described in Section 6.1. Such Group RAR command is 770 denoted as 'GRAR' in the following table. The same notation applies 771 to other commands as per [RFC6733]. 773 CLIENT, STATEFUL 774 State Event Action New State 775 --------------------------------------------------------------- 776 Idle Client or Device Requests Send Pending 777 access service 778 specific 779 auth req 780 optionally 781 including 782 groups 784 Open GASR received with Send GASA Discon 785 Session-Group-Action with 786 = ALL_GROUPS, Result-Code 787 session is assigned to = SUCCESS, 788 received group(s) and Send GSTR. 789 client will comply with 790 request to end the session 792 Open GASR received with Send GASA Discon 793 Session-Group-Action with 794 = PER_GROUPS, Result-Code 795 session is assigned to = SUCCESS, 796 received group(s) and Send GSTR 797 client will comply with per group 798 request to end the session 799 Open GASR received with Send GASA Discon 800 Session-Group-Action with 801 = PER_SESSION, Result-Code 802 session is assigned to = SUCCESS, 803 received group(s) and Send STR 804 client will comply with per session 805 request to end the session 807 Open GASR received, Send GASA Open 808 client will not comply with with 809 request to end all session Result-Code 810 in received group(s) != SUCCESS 812 Discon GSTA Received Discon. Idle 813 user/device 815 Open GRAR received with Send GRAA, Pending 816 Session-Group-Action Send 817 = ALL_GROUPS, service 818 session is assigned to specific 819 received group(s) and group 820 client will perform re-auth req 821 subsequent re-auth 823 Open GRAR received with Send GRAA, Pending 824 Session-Group-Action Send 825 = PER_GROUP, service 826 session is assigned to specific 827 received group(s) and group 828 client will perform re-auth req 829 subsequent re-auth per group 831 Open GRAR received with Send GRAA, Pending 832 Session-Group-Action Send 833 = PER_SESSION, service 834 session is assigned to specific 835 received group(s) and re-auth req 836 client will perform per session 837 subsequent re-auth 839 Open GRAR received and client will Send GRAA Idle 840 not perform subsequent with 841 re-auth Result-Code 842 != SUCCESS, 843 Discon. 844 user/device 846 Pending Successful service-specific Provide Open 847 group re-authorization answer service 848 received. 850 Pending Failed service-specific Discon. Idle 851 group re-authorization answer user/device 852 received. 854 The following state machine is observed by a server when it is 855 maintaining state for the session. State transitions which are 856 unmodified from [RFC6733] are not repeated here. 858 SERVER, STATEFUL 859 State Event Action New State 860 --------------------------------------------------------------- 862 Idle Service-specific authorization Send Open 863 request received, and user successful 864 is authorized service 865 specific 866 answer 867 optionally 868 including 869 groups 871 Open Server wants to terminate Send GASR Discon 872 group(s) 874 Discon GASA received Cleanup Idle 876 Any GSTR received Send GSTA, Idle 877 Cleanup 879 Open Server wants to reauth Send GRAR Pending 880 group(s) 882 Pending GRAA received with Result-Code Update Open 883 = SUCCESS session(s) 885 Pending GRAA received with Result-Code Cleanup Idle 886 != SUCCESS session(s) 888 Open Service-specific group Send Open 889 re-authoization request successful 890 received and user is service 891 authorized specific 892 group 893 re-auth 894 answer 896 Open Service-specific group Send Idle 897 re-authorization request failed 898 received and user is service 899 not authorized specific 900 group 901 re-auth 902 answer, 903 cleanup 905 Authors' Addresses 907 Mark Jones 909 Email: mark@azu.ca 911 Marco Liebsch 913 Email: marco.liebsch@neclab.eu 915 Lionel Morand 917 Email: lionel.morand@orange.com