idnits 2.17.1 draft-ietf-dime-group-signaling-02.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 483 has weird spacing: '...ly with wit...' == Line 522 has weird spacing: '... answer servi...' == Line 526 has weird spacing: '... answer user/...' -- The document date (October 21, 2013) is 3837 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) == Missing Reference: 'RFC6733' is mentioned on line 675, but not defined ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) Summary: 2 errors (**), 0 flaws (~~), 5 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 October 21, 2013 6 Expires: April 24, 2014 8 Diameter Group Signaling 9 draft-ietf-dime-group-signaling-02.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 April 24, 2014. 42 Copyright Notice 44 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Building and Modifying Session Groups . . . . . . . . . . 5 63 3.2. Issuing Group Commands . . . . . . . . . . . . . . . . . . 5 64 4. Grouping User Sessions . . . . . . . . . . . . . . . . . . . . 6 65 4.1. Group assignment at session initiation . . . . . . . . . . 6 66 4.2. Mid-session group assignment modifications . . . . . . . . 6 67 4.2.1. Client-initiated group assignment changes . . . . . . 7 68 4.2.2. Server-initiated group assignment changes . . . . . . 7 69 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 8 70 5.1. Session Grouping . . . . . . . . . . . . . . . . . . . . . 8 71 5.2. Session Grouping Capability Discovery . . . . . . . . . . 9 72 5.2.1. Implicit Capability Discovery . . . . . . . . . . . . 9 73 5.2.2. Explicit Capability Discovery . . . . . . . . . . . . 9 74 5.3. Performing Group Operations . . . . . . . . . . . . . . . 10 75 5.3.1. Sending Group Commands . . . . . . . . . . . . . . . . 10 76 5.3.2. Receiving Group Commands . . . . . . . . . . . . . . . 10 77 5.3.3. Single-Session Fallback . . . . . . . . . . . . . . . 11 78 5.4. Session Management . . . . . . . . . . . . . . . . . . . . 11 79 5.4.1. Authorization Session State Machine . . . . . . . . . 11 80 6. Commands Formatting . . . . . . . . . . . . . . . . . . . . . 15 81 6.1. Group Re-Auth-Request . . . . . . . . . . . . . . . . . . 15 82 7. Attribute-Value-Pairs (AVP) . . . . . . . . . . . . . . . . . 16 83 7.1. Session-Group-Info AVP . . . . . . . . . . . . . . . . . . 16 84 7.2. Session-Group-Feature-Vector AVP . . . . . . . . . . . . . 16 85 7.3. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . . 16 86 7.4. Session-Group-Action AVP . . . . . . . . . . . . . . . . . 17 87 8. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 18 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 89 9.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 19 90 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 91 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 92 12. Normative References . . . . . . . . . . . . . . . . . . . . . 22 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 95 1. Introduction 97 In large network deployments, a single Diameter peer can support over 98 a million concurrent Diameter sessions. Recent use cases have 99 revealed the need for Diameter peers to apply the same operation to a 100 large group of Diameter sessions concurrently. For example, a policy 101 decision point may need to modify the authorized quality of service 102 for all active users having the same type of subscription. The 103 Diameter base protocol commands operate on a single session so these 104 use cases could result in many thousands of command exchanges to 105 enforce the same operation on each session in the group. In order to 106 reduce signaling, it would be desirable to enable bulk operations on 107 all (or part of) the sessions managed by a Diameter peer using a 108 single or a few command exchanges. 110 This document describes mechanisms for grouping Diameter sessions and 111 applying Diameter commands, such as performing re-authentication, re- 112 authorization, termination and abortion of sessions to a group of 113 sessions. This document does not define a new Diameter application. 114 Instead it defines mechanisms, commands and AVPs that may be used by 115 any Diameter application that requires management of groups of 116 sessions. 118 These mechanisms take the following design goals and features into 119 account: 121 o Minimal impact to existing applications 123 o Extension of existing commands' CCF with optional AVPs to enable 124 grouping and group operations 126 o Fallback to single session operation 128 o Implicit discovery of capability to support grouping and group 129 operations 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 This document uses terminology defined [RFC3588]. 139 3. Use Cases 141 3.1. Building and Modifying Session Groups 143 Client and Server can add a new Diameter session to a group, e.g. in 144 case the subscription profile of the associated user has similar 145 characteristics as the profile of other users whose Diameter session 146 has been added to one or multiple groups. Such similarities can be 147 for example maximum bandwidth bounds of each user in the a group. 148 These users may share resources of, e.g., an access multiplexer, 149 together with other users. Runtime adjustments in the granted 150 bandwidth bounds or other Quality of Service related attributes can 151 be accomplished for the whole group by identifying the group in the 152 Diameter group command. 154 In case a user's subscription profile changes during runtime, either 155 node, a Diameter Server or Diameter client, may decide to remove this 156 user's Diameter session from the session group. The user's Diameter 157 session can be assigned to a different group, whose adjusted profile 158 matches the one of the different group. Both groups, the user's 159 previous group and its new group, will be modified mid-session. 161 In case of mobile users, a change in the node implementing the 162 Diameter client can happen, which has impact to a group of sessions a 163 particular pair of Diameter client and server has in common. Due to 164 mobility, the mobile user's session may get transferred to a new 165 Diameter client during runtime without mandating from-scratch 166 authorization. Such scenario necessitates mid-session modification. 168 3.2. Issuing Group Commands 170 A policy decision point may decide to terminate a group of sessions, 171 e.g. based on previous agreement for temporary authorization to 172 access a system. All Diameter sessions of associated users with such 173 temporarily granted access will be added to a single Diameter session 174 group. After the time limit for the temporary authorization has been 175 reached, the policy decision point can issue a single Session 176 Termination Request (STR) to the policy enforcement point. The STR 177 command identifies the group of Diameter sessions which are to be 178 terminated. The policy enforcement point treats the STR as group 179 command and initiates termination of all sessions in the group. 180 Subsequently, the policy enforcement point confirms successful 181 termination of these sessions to the policy decision point by sending 182 a single Session Termination Answer (STA) command which includes the 183 identifier of the group. 185 4. Grouping User Sessions 187 Either Diameter peer may assign a session to a group. Diameter AAA 188 applications typically assign client and server roles to the Diameter 189 peers. 191 4.1. Group assignment at session initiation 193 Assignment of a new session to a group is accomplished by the 194 Diameter server when requested by the Diameter client. Without being 195 explicitly requested by the client, the Diameter server can assign a 196 new session to a server-assigned group based on its own decision. 197 When a new session is to be assigned to a group by the Diameter 198 server, the server assigns a new session to at least one server- 199 assigned group. To complement server-assigned grouping, a Diameter 200 client can assign a session to a client-assigned group. 202 To assign a session to a group at session initiation, a Diameter 203 client sends a service specific request, e.g. NASREQ AAR [RFC4005], 204 containing one or more group identifiers. The Diameter client can 205 assign the session to a client-assigned group and identify the 206 associated group with an appended client-assigned group identifier. 207 The client can append multiple client-assigned group identifiers if 208 the client assigns the new session to more than one group. If the 209 Diameter client does not send a client-assigned group identifier, the 210 client may receive one or multiple server-assigned group identifiers 211 in the server's response, which identify the server-assigned groups 212 to which the new session has been assigned. The Diameter client can 213 explicitly request the Diameter server to perform grouping of the new 214 session. 216 Assuming the user has been successfully authenticated and/or 217 authorized, the Diameter server responds with service-specific auth 218 response, e.g. NASREQ AAA [RFC4005], containing both the client- 219 assigned group identifiers (if sent with the request) and one or more 220 server-assigned group identifiers. 222 Both peers, the Diameter client and the Diameter server, must keep a 223 list of all group identifiers which identify all client- and server- 224 assigned groups to which the session has been assigned. 226 4.2. Mid-session group assignment modifications 228 Either Diameter peer may modify the group membership of an active 229 Diameter session. A Diameter client MAY remove the group(s) assigned 230 to the active session by the Diameter server and vice versa. 232 This document does not define a permission model that limits removal 233 of a session from a group by the same peer that added the session to 234 the group. However, applications which re-use the commands and 235 methods defined in this document may impose their own permission 236 model. For example, an application could require that the server 237 MUST NOT remove a session from a group assigned by the client. 239 4.2.1. Client-initiated group assignment changes 241 To update the assigned groups mid-session, a Diameter client sends a 242 service specific re-authorization request containing the updated list 243 of group identifiers. Assuming the user is successfully 244 authenticated and/or authorized, the Diameter server responds with a 245 service-specific auth response containing the updated list of group 246 identifiers received in the request. 248 4.2.2. Server-initiated group assignment changes 250 To update the assigned groups mid-session, a Diameter server sends a 251 Re-authorization Request (RAR) message requesting re-authorization 252 and the client responds with a Re-authorization Answer (RAA) message. 253 The Diameter client sends a service specific re-authorization request 254 containing the current list of group identifiers and the Diameter 255 server responds with a service-specific auth response containing the 256 updated list of group identifiers. 258 5. Protocol Description 260 5.1. Session Grouping 262 Either Diameter peer, a Diameter client or server, can initiate 263 assigning a session to a single or multiple session groups according 264 to the procedure described in Section 4. Modification of a group by 265 removing or adding a single or multiple user sessions can be 266 initiated and performed at runtime by either Diameter peer. 268 A Diameter client as sender of a command for session initiation can 269 determine one or multiple groups to which the new session should be 270 assigned. Each of these groups need to be identified by a unique 271 Session-Group-Id contained in a separate Session-Group-Info AVP as 272 specified in Section 7. 274 In each appended Session-Group-Info AVP which carries a group 275 identifier, the SESSION_GROUP_ALLOCATION_MODE flag of the Session- 276 Group-Feature-Vector AVP MUST be: 278 o set (1) to indicate that the carried group identifier is a server- 279 assigned group; 281 o cleared (0) to indicate that the carried group identifier is a 282 client-assigned group. 284 A Diameter client can explicitly request the Diameter server as 285 recipient of the message to assign the new session to one or multiple 286 server-assigned groups by appending a Session-Group-Info AVP with no 287 Session-Group-Id AVP and the Session-Group-Feature-Vector AVP with 288 the SESSION_GROUP_ALLOCATION_MODE flag set (1). 290 If the Diameter server receives a Session-Group-Info AVP with no 291 Session-Group-Id AVP and the Session-Group-Feature-Vector AVP with 292 the SESSION_GROUP_ALLOCATION_MODE flag set (1), the Diameter server 293 SHOULD assign the new session to one or multiple server-assigned 294 groups. The Diameter server identifies each of these server-assigned 295 groups in a Session-Group-Id AVP contained in a Session-Group-Info 296 AVP, which are appended to the response to the received command. 297 Each of these Session-Group-Info AVPs must have the 298 SESSION_GROUP_ALLOCATION_MODE flag of the Session-Group-Feature- 299 Vector AVP set to indicate that the carried identifier is a server- 300 assigned group identifier. 302 If the Diameter server receives a Session-Group-Info AVP with a 303 Session-Group-Id AVP and the Session-Group-Feature-Vector AVP with 304 the SESSION_GROUP_ALLOCATION_MODE flag cleared (0), the server must 305 store the one or multiple group identifiers and associate the new 306 session with these client-assigned groups. The Diameter server may 307 still assign the new session to one or multiple server-assigned 308 groups. The Diameter server identifies each of these server-assigned 309 groups in a Session-Group-Id AVP contained in a Session-Group-Info 310 AVP, which are appended to the response to the received command, in 311 addition to the those related to the client-assigned groups received 312 in the request. Each of these Session-Group-Info AVPs must have the 313 SESSION_GROUP_ALLOCATION_MODE flag of the Session-Group-Feature- 314 Vector AVP set to indicate that this carried identifier is a server- 315 assigned group identifier. 317 A Diameter server receiving a command for session initiation which 318 includes at least one Session-Group-Info AVP but the server does not 319 understand the semantics of this optional AVP because it does not 320 support group operations according to the specification in this 321 document, MUST ignore the optional group operations specific AVPs and 322 proceed with processing the command for a single session. 324 A Diameter client, which sent a request for session initiation to a 325 Diameter server and appended a single or multiple Session-Group-Id 326 AVPs but cannot find any Session-Group-Info AVP in the associated 327 response from the Diameter server proceeds with processing the 328 command for a single session. Furthermore, the client keeps a log to 329 remember that the server is not able to perform group operations. 331 5.2. Session Grouping Capability Discovery 333 5.2.1. Implicit Capability Discovery 335 By appending at least one Session-Group-Info AVP, the Diameter client 336 announces its capability to support group operations according to the 337 specification in this document to the addressed Diameter server. If 338 the Diameter client supports group operations, it MUST append at 339 least one Session-Group-Info AVP to announce its capability to 340 support group operations. 342 A session-group aware Diameter server receiving a command for session 343 initiation which includes at least one Session-Group-Info AVP learns 344 about the sender's capability to support group operations. 346 By appending at least one Session-Group-Id AVP, the Diameter server 347 announces its capability to support group operations according to the 348 specification in this document to the addressed Diameter client. 350 5.2.2. Explicit Capability Discovery 352 New Diameter applications may consider support for Diameter session 353 grouping and for performing group commands during the standardization 354 process. Such applications provide intrinsic support for the support 355 of group commands and announce this capability through the assigned 356 application ID. 358 5.3. Performing Group Operations 360 5.3.1. Sending Group Commands 362 Either Diameter peer can request the recipient of a request to 363 process an associated command for all sessions being assigned to one 364 or multiple groups by identifying these groups in the request. The 365 sender of the request appends for each group, to which the command 366 applies, a Session-Group-Info AVP including the Session-Group-Id AVP 367 and indicates in the SESSION_GROUP_ALLOCATION_MODE flag of the 368 Session-Group-Feature-Vector AVP whether the identifier represents a 369 server- or a client-assigned group. If the CCF of the request 370 mandates a Session-Id AVP, the Session-Id AVP MUST identify a single 371 session which is assigned to at least one of the groups being 372 identified in the appended Session-Group-Id AVPs. 374 The sender of the request can indicate to the receiver how follow up 375 message exchanges should be performed by appending a Session-Group- 376 Action AVP. If the sender wants the receiver to perform follow up 377 exchanges with a single command for all impacted groups, the sender 378 sets the value of the Session-Group-Action AVP to ALL_GROUPS (1). If 379 follow up message exchanges should be performed on a per-group basis 380 in case multiple groups are identified in the group command, the 381 value of the Session-Group-Action AVP is set to PER_GROUP (2). A 382 value set to PER_SESSION (3) indicates to the receiver that all 383 follow up exchanges should be performed using a single message for 384 each impacted session. 386 If the sender wants the receiver of the request to process the 387 associated command solely for a single session does not append any 388 group identifier, but identifies the relevant session in the 389 Session-Id AVP. 391 5.3.2. Receiving Group Commands 393 A Diameter peer receiving a request to process a command for a group 394 of sessions identifies the relevant groups according to the appended 395 Session-Group-Id AVP in the Session-Group-Info AVP. If the received 396 request identifies multiple groups in multiple appended Session- 397 Group-Id AVPs, the receiver should process the associated command for 398 each of these groups. if a session has been assigned to more than one 399 of the identified groups, the receiver must process the associated 400 command only once per session. 402 The Diameter peer receiving a request which requests performing the 403 command to at least on session group SHOULD perform follow up message 404 exchanges according to the value identified in the Session-Group-Info 405 AVP. 407 5.3.3. Single-Session Fallback 409 Either Diameter peer, a Diameter client or a Diameter server, can 410 fall back to single session operation by ignoring and omitting the 411 optional group session-specific AVPs. Fallback to single-session 412 operation is performed by processing the Diameter command solely for 413 the session identified in the mandatory Session-Id AVP. The response 414 to the group command must not identify any group but identify solely 415 the single session for which the command has been processed. 417 5.4. Session Management 419 Editor's note: This document revision adopts the WG's current view on 420 how Diameter commands can be formatted to enable group signaling. 421 The required change in the formatting and protocol operation has not 422 yet been considered in this Section 5.4 , which still reflects the 423 formatting as per version 0 of this specification. The described 424 session state machines still need revision to reflect the generalized 425 formatting and the adopted protocol operation. 427 5.4.1. Authorization Session State Machine 429 Section 8.1 in [RFC3588] defines a set of finite state machines, 430 representing the life cycle of Diameter sessions, and which MUST be 431 observed by all Diameter implementations that make use of the 432 authentication and/or authorization portion of a Diameter 433 application. This section defines the additional state transitions 434 related to the processing of the new commands which may impact 435 multiple sessions. 437 The group membership is session state and therefore only those state 438 machines from [RFC3588] in which the server is maintaining session 439 state are relevant in this document. As in [RFC3588], the term 440 Service-Specific below refers to a message defined in a Diameter 441 application (e.g., Mobile IPv4, NASREQ). 443 The following state machine is observed by a client when state is 444 maintained on the server. State transitions which are unmodified 445 from [RFC3588] are not repeated here. 447 CLIENT, STATEFUL 448 State Event Action New State 449 --------------------------------------------------------------- 450 Idle Client or Device Requests Send Pending 451 access service 452 specific 453 auth req 454 optionally 455 including 456 groups 458 Open GASR received with Send GASA Discon 459 Session-Group-Action with 460 = ALL_GROUPS, Result-Code 461 session is assigned to = SUCCESS, 462 received group(s) and Send GSTR. 463 client will comply with 464 request to end the session 466 Open GASR received with Send GASA Discon 467 Session-Group-Action with 468 = PER_GROUPS, Result-Code 469 session is assigned to = SUCCESS, 470 received group(s) and Send GSTR 471 client will comply with per group 472 request to end the session 474 Open GASR received with Send GASA Discon 475 Session-Group-Action with 476 = PER_SESSION, Result-Code 477 session is assigned to = SUCCESS, 478 received group(s) and Send STR 479 client will comply with per session 480 request to end the session 482 Open GASR received, Send GASA Open 483 client will not comply with with 484 request to end all session Result-Code 485 in received group(s) != SUCCESS 487 Discon GSTA Received Discon. Idle 488 user/device 490 Open GRAR received with Send GRAA, Pending 491 Session-Group-Action Send 492 = ALL_GROUPS, service 493 session is assigned to specific 494 received group(s) and group 495 client will perform re-auth req 496 subsequent re-auth 498 Open GRAR received with Send GRAA, Pending 499 Session-Group-Action Send 500 = PER_GROUP, service 501 session is assigned to specific 502 received group(s) and group 503 client will perform re-auth req 504 subsequent re-auth per group 506 Open GRAR received with Send GRAA, Pending 507 Session-Group-Action Send 508 = PER_SESSION, service 509 session is assigned to specific 510 received group(s) and re-auth req 511 client will perform per session 512 subsequent re-auth 514 Open GRAR received and client will Send GRAA Idle 515 not perform subsequent with 516 re-auth Result-Code 517 != SUCCESS, 518 Discon. 519 user/device 521 Pending Successful service-specific Provide Open 522 group re-authorization answer service 523 received. 525 Pending Failed service-specific Discon. Idle 526 group re-authorization answer user/device 527 received. 529 The following state machine is observed by a server when it is 530 maintaining state for the session. State transitions which are 531 unmodified from [RFC3588] are not repeated here. 533 SERVER, STATEFUL 534 State Event Action New State 535 --------------------------------------------------------------- 537 Idle Service-specific authorization Send Open 538 request received, and user successful 539 is authorized service 540 specific 541 answer 542 optionally 543 including 544 groups 546 Open Server wants to terminate Send GASR Discon 547 group(s) 549 Discon GASA received Cleanup Idle 551 Any GSTR received Send GSTA, Idle 552 Cleanup 554 Open Server wants to reauth Send GRAR Pending 555 group(s) 557 Pending GRAA received with Result-Code Update Open 558 = SUCCESS session(s) 560 Pending GRAA received with Result-Code Cleanup Idle 561 != SUCCESS session(s) 563 Open Service-specific group Send Open 564 re-authoization request successful 565 received and user is service 566 authorized specific 567 group 568 re-auth 569 answer 571 Open Service-specific group Send Idle 572 re-authorization request failed 573 received and user is service 574 not authorized specific 575 group 576 re-auth 577 answer, 578 cleanup 580 6. Commands Formatting 582 This document does not specify new Diameter commands to enable group 583 operations, but relies on command extensibility capability provided 584 by the Diameter Base protocol. This section provides the guidelines 585 to extend the CCF of existing Diameter commands with optional AVPs to 586 enable the recipient of the command to perform the command to all 587 sessions associated with the identified group(s). 589 6.1. Group Re-Auth-Request 591 A request that one or more groups of users are re-authentication is 592 issues by appending one or multiple Session-Group-Id AVP(s) to the 593 Re-Auth-Request (RAR). The one or multiple Session-Group-Id AVP(s) 594 identify the associated group(s) for which the group re- 595 authentication has been requested. The recipient of the group 596 command initiates re-authentication for all users associated with the 597 identified group(s). Furthermore, the sender of the group re- 598 authentication request appends a Session-Group-Action AVP to provide 599 more information to the receiver of the command about how to 600 accomplish the group operation. 602 The value of the mandatory Session-Id AVP MUST identify a session 603 associated with a single user, which is assigned to at least one of 604 the groups being identified in the appended Session-Group-Id AVPs. 606 ::= < Diameter Header: 258, REQ, PXY > 607 < Session-Id > 608 { Origin-Host } 609 { Origin-Realm } 610 { Destination-Realm } 611 { Destination-Host } 612 { Auth-Application-Id } 613 { Re-Auth-Request-Type } 614 [ User-Name ] 615 [ Origin-State-Id ] 616 * [ Proxy-Info ] 617 * [ Route-Record ] 618 * [ Session-Group-Id ] 619 [ Session-Group-Action ] 620 * [ AVP ] 622 7. Attribute-Value-Pairs (AVP) 624 +--------------------+ 625 | AVP Flag rules | 626 +----+---+------+----+ 627 AVP | | |SHOULD|MUST| 628 Attribute Name Code Value Type |MUST|MAY| NOT | NOT| 629 +-------------------------------------------------+----+---+------+----+ 630 |Session-Group-Info TBD1 Grouped | | P | | V | 631 |Session-Group-Feature-Vector TBD2 Unsigned32 | | P | | V | 632 |Session-Group-Id TBD3 OctetString | | P | | V | 633 |Session-Group-Action TBD4 Unsigned32 | | P | | V | 634 +-------------------------------------------------+----+---+------+----+ 636 AVPs for the Diameter Group Signaling 638 7.1. Session-Group-Info AVP 640 The Session-Group-Info AVP (AVP Code TBD1) is of type Grouped. It 641 contains the identifier of the session group as well as an indication 642 of the node responsible for session group identifier assignment. 643 Session-Group-Info ::= < AVP Header: TBD1 > 644 < Session-Group-Feature-Vector > 645 [ Session-Group-Id ] 646 * [ AVP ] 648 7.2. Session-Group-Feature-Vector AVP 650 The Session-Group-Feature-Vector AVP (AVP Code TBD2) is of type 651 Unsigned32 and and contains a 32-bit flags field of capabilities 652 supported by the session-group aware node. 654 The following capabilities are defined in this document: 656 SESSION_GROUP_ALLOCATION_MODE (0x00000001) 658 This flag indicates the mode of allocation of session group 659 identifier. When this flag is set, it indicates that Diameter 660 server is responsible for the allocation of the session group 661 identifier. When this flag is not set, it indicates that the 662 session group identifier is allocated by the client. 664 7.3. Session-Group-Id AVP 666 The Session-Group-Id AVP (AVP Code TBD3) is of type UTF8String and 667 identifies a group of sessions. 669 The Session-Group-Id MUST be globally and eternally unique, as it is 670 meant to uniquely identify a group of Diameter sessions without 671 reference to any other information. 673 Unless stated otherwise, the default format of the Session-Group-id 674 SHOULD comply to the format recommended for a Session-Id, as defined 675 in the section 8.8 of the RFC6733 [RFC6733]. However, the exact 676 format of the Session-Group-Id MAY be specified by the Diameter 677 applications which make use of group signaling commands. 679 7.4. Session-Group-Action AVP 681 The Session-Group-Action AVP (AVP Code TBD4) is of type Unsigned32 682 and contains a 32-bit address space representing values indicating 683 how the peer SHOULD issue follow up exchanges in response to a 684 command which impacts mulitple sessions. The following values are 685 defined by this application: 687 ALL_GROUPS (1) 688 Follow up exchanges should be performed with a single message 689 exchange for all impacted groups. 691 PER_GROUP (2) 692 Follow up exchanges should be performed with a message exchange 693 for each impacted group. 695 PER_SESSION (3) 696 Follow up exchanges should be performed with a message exchange 697 for each impacted session. 699 8. Result-Code AVP Values 701 This document does not define new Result-Code [RFC3588] values for 702 existing applications, which are extended to support group commands. 703 Specification documents of new applications, which will have 704 intrinsic support for group commands, may specify new Result-Codes. 706 9. IANA Considerations 708 This section contains the namespaces that have either been created in 709 this specification or had their values assigned to existing 710 namespaces managed by IANA. 712 9.1. AVP Codes 714 This specification requires IANA to register the following new AVPs 715 from the AVP Code namespace defined in [RFC3588]. 717 o Session-Group-Info 719 o Session-Group-Feature-Vector 721 o Session-Group-Id 723 o Session-Group-Action 725 The AVPs are defined in Section 7. 727 10. Security Considerations 729 TODO 731 11. Acknowledgments 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 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 738 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 740 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 741 "Diameter Network Access Server Application", RFC 4005, 742 August 2005. 744 Authors' Addresses 746 Mark Jones 748 Email: mark@azu.ca 750 Marco Liebsch 752 Email: marco.liebsch@neclab.eu 754 Lionel Morand 756 Email: lionel.morand@orange.com