idnits 2.17.1 draft-ietf-dime-group-signaling-00.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 413 has weird spacing: '...ly with wit...' == Line 452 has weird spacing: '... answer servi...' == Line 456 has weird spacing: '... answer user/...' -- The document date (June 22, 2012) is 4320 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 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4005 (Obsoleted by RFC 7155) Summary: 2 errors (**), 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 M. Jones 3 (DIME) June 22, 2012 4 Internet-Draft 5 Intended status: Standards Track 6 Expires: December 24, 2012 8 Diameter Group Signaling 9 draft-ietf-dime-group-signaling-00.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 December 24, 2012. 42 Copyright Notice 44 Copyright (c) 2012 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. Grouping User Sessions . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Group assignment at session initiation . . . . . . . . . . 5 63 3.2. Mid-session group assignment modifications . . . . . . . . 5 64 3.2.1. Client-initiated group assignment changes . . . . . . 5 65 3.2.2. Server-initiated group assignment changes . . . . . . 5 66 3.3. Server Initiated Group Re-auth . . . . . . . . . . . . . . 6 67 3.4. Session Group Termination . . . . . . . . . . . . . . . . 7 68 3.5. Aborting a Group of Sessions . . . . . . . . . . . . . . . 8 69 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 10 70 4.1. Session Management . . . . . . . . . . . . . . . . . . . . 10 71 4.1.1. Authorization Session State Machine . . . . . . . . . 10 72 4.2. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 4.2.1. Group-Re-Auth-Request . . . . . . . . . . . . . . . . 14 74 4.2.2. Group-Re-Auth-Answer . . . . . . . . . . . . . . . . . 14 75 4.2.3. Group-Session-Termination-Request . . . . . . . . . . 15 76 4.2.4. Group-Session-Termination-Answer . . . . . . . . . . . 15 77 4.2.5. Group-Abort-Session-Request . . . . . . . . . . . . . 16 78 4.2.6. Group-Abort-Session-Answer . . . . . . . . . . . . . . 16 79 5. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 5.1. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . . 18 81 5.2. Session-Group-Action AVP . . . . . . . . . . . . . . . . . 18 82 6. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 19 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 84 7.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 20 85 7.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 20 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 87 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 88 10. Normative References . . . . . . . . . . . . . . . . . . . . . 23 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 91 1. Introduction 93 In large network deployments, a single Diameter peer can support over 94 a million concurrent Diameter sessions. Recent use cases have 95 revealed the need for Diameter peers to apply the same operation to a 96 large group of Diameter sessions concurrently. For example, a policy 97 decision point may need to modify the authorized quality of service 98 for all active users having the same type of subscription. The 99 Diameter base protocol commands operate on a single session so these 100 use cases could result in many thousands of command exchanges to 101 enforce the same operation on each session in the group. In order to 102 reduce signaling, it would be desirable to enable bulk operations on 103 all (or part of) the sessions managed by a Diameter peer using a 104 single or a few command exchanges. 106 This document describes a mechanism for grouping Diameter sessions 107 and performing re-authentication, re-authorization, termination and 108 abortion of groups of sessions. This document does not define a new 109 Diameter application. Instead it defines mechanisms, commands and 110 AVPs that may be used by any Diameter application that requires 111 management of groups of sessions. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119]. 119 This document uses terminology defined [RFC3588]. 121 3. Grouping User Sessions 123 Either Diameter peer may assign a session to a group. Diameter AAA 124 applications typically assign client and server roles to the Diameter 125 peers. In this document, a Diameter client is a node at the edge of 126 the network that performs access control. A Diameter server is a 127 node that performs authentication and/or authorization of the user. 129 3.1. Group assignment at session initiation 131 To assign a session to a group at session initiation, a Diameter 132 client sends a service specific auth request, e.g. NASREQ AAR 133 [RFC4005], containing zero or more client-assigned group identifiers. 134 Assuming the user is successfully authenticated and/or authorized, 135 the Diameter server responds with service-specific auth response, 136 e.g. NASREQ AAA [RFC4005], containing both the client-assigned group 137 identifiers and zero or more server-assigned group identifiers. 139 3.2. Mid-session group assignment modifications 141 Either Diameter peer may modify the group membership of an active 142 Diameter session. A Diameter client MAY remove the group(s) assigned 143 to the active session by the Diameter server and vice versa. 145 This document does not define a permission model that limits removal 146 of a session from a group by the same peer that added the session to 147 the group. However, applications which re-use the commands and 148 methods defined in this document may impose their own permission 149 model. For example, an application could require that the server 150 MUST NOT remove a session from a group assigned by the client. 152 3.2.1. Client-initiated group assignment changes 154 To update the assigned groups mid-session, a Diameter client sends a 155 service specific re-authorization request containing the updated list 156 of group identifiers. Assuming the user is successfully 157 authenticated and/or authorized, the Diameter server responds with a 158 service-specific auth response containing the updated list of group 159 identifiers received in the request. 161 3.2.2. Server-initiated group assignment changes 163 To update the assigned groups mid-session, a Diameter server sends a 164 Re-authorization Request (RAR) message requesting re-authorization 165 and the client responds with a Re-authorization Answer (RAA) message. 166 The Diameter client sends a service specific re-authorization request 167 containing the current list of group identifiers and the Diameter 168 server responds with a service-specific auth response containing the 169 updated list of group identifiers. 171 3.3. Server Initiated Group Re-auth 173 This document defines a new Group-Re-Auth-Request/Answer (GRAR/ 174 GRAA)command exchange which allows a server to initiate a re- 175 authentication and/or re-authorization of all services that are 176 assigned to one of the groups specified in the Session-Group-Id AVP 177 in the request. 179 An access device that receives a Group-Re-Auth-Request(GRAR) message 180 with Session-Group-Id equal to one of the group assigned to a 181 currently active session MUST initiate the type of re-auth specified 182 by the Re-Auth-Request-Type AVP in the manner specified by the 183 Session-Group-Action AVP if the service supports this particular 184 feature. Each Diameter application MUST state whether service- 185 initiated group re-authentication and/or re-authorization is 186 supported and which Session-Group-Action AVP values are supported for 187 re-authorization. 189 The Session-Group-Action AVP specifies whether the server requires a 190 re-authorization request per session, per group or for all groups. 191 For a Re-Auth-Request-Type value of AUTHORIZE_AUTHENTICATE, the 192 Session-Group-Action value MUST be PER_SESSION since re- 193 authentication MUST be performed per user session. 195 For Session-Group-Action values of PER_GROUP or ALL_GROUPS, the re- 196 authorization is accomplished with an application-specifc group re- 197 authorization command exchange. This command exchange as well as any 198 limitations on which aspects of the service can be modified during a 199 re-authorization MUST be defined by the Diameter application. 201 If the client is able to perform the requested re-authentication 202 and/or re-authentication for the sessions assigned to the group(s) 203 specified in the GRAR, it shall return a GRAA command with the 204 Result-Code AVP set to DIAMETER_SUCCESS and Session-Group-Id AVP(s) 205 indicating the groups for which the GRAR receiver has active sessions 206 assigned. If there are no sessions assigned to the group(s) 207 specified in the GRAR, the Result-Code is set to 208 DIAMETER_UNKNOWN_SESSION_ID. If the client is unable to perform the 209 requested re-authentication and/or re-authentication, the Result-Code 210 is set to DIAMETER_UNABLE_TO_COMPLY. 212 Diameter Diameter 213 Client Server 214 | | 215 (1)+-------------Svc-Specific-Auth-Request--------------->| 216 | Session-Id=ABC | 217 | | 218 (2)|<------------Svc-Specific-Auth-Answer-----------------+ 219 | Session-Id=ABC; Session-Group-Id=XYZ | 220 | | 221 (3)+-------------Svc-Specific-Auth-Request--------------->| 222 | Session-Id=DEF | 223 | | 224 (4)|<------------Svc-Specific-Auth-Answer-----------------+ 225 | Session-Id=DEF; Session-Group-Id=XYZ | 226 | | 227 (5)|<--------------Group-Re-Auth-Request------------------+ 228 | Session-Group-Id=XYZ; Session-Group-Action=PER_GROUP | 229 | Re-Auth_Request-Type=AUTHORIZE_ONLY | 230 | | 231 (6)+---------------Group-Re-Auth-Answer------------------>| 232 | | 233 (7)+----------Svc-Specific-Group-Auth-Request------------>| 234 | Session-Group-Id=XYZ | 235 | | 236 (8)|<---------Svc-Specific-Group-Auth-Answer--------------+ 237 | Updated Service Specific AVPs | 238 | | 240 Figure 1: Example: Group Re-authorization 242 In the example above, the Diameter server authorizes two sessions 243 (ABC and DEF) and assigns them to a group named XYZ (Session-Group- 244 Id=XYZ in steps 2 and 4). Some time later, an event occurs on the 245 Diameter server which requires it to change one or more of the 246 service parameters for the sessions assigned to group XYZ. The 247 Diameter server sends a Group-Re-Auth-Request (step 5) specifying the 248 impacted group (Session-Group-Id=XYZ) must be re-authorized (Re-Auth- 249 Request-Type=AUTHORIZE_ONLY) with a single re-authorize command per 250 group (Session-Group-Action=PER_GROUP). The Diameter client 251 acknowledges the request (step 6) and issues a service-specific group 252 authorization request to retrieve the updated service parameters 253 (step 7). 255 3.4. Session Group Termination 257 This document defines a new Group-Session-Termination-Request/Answer 258 (GSTR/GSTA) command exchange which allows a client to communicate to 259 the server the termination of all sessions that are assigned to one 260 of the groups specified in the Session-Group-Id AVP in the request. 261 The termination of a group of sessions could occur as a result of a 262 local action or in reponse to a request to abort one or more groups 263 of sessions. 265 FFS: When a client sends an GSTR to a server indicating termination 266 of a specific group, is it indicating termination of the sessions 267 that the server authorized and that are assigned to the specified 268 group? Or does imply termination of all sessions on the client that 269 are assigned to the specified group? 271 Upon receipt of the GSTR, the Diameter Server MUST release all 272 resources for the sessions assigned to the group(s) specified in the 273 Session-Group-Id AVP and return a GSTA with the Result-Code set to 274 DIAMETER_SUCCESS to acknowledge the successful termination. If there 275 are no sessions assigned to the group(s) specified in the GSTR, the 276 Result-Code is set to DIAMETER_UNKNOWN_SESSION_ID. If the server is 277 unable to perform the session termination, the Result-Code is set to 278 DIAMETER_UNABLE_TO_COMPLY. 280 3.5. Aborting a Group of Sessions 282 This document defines a new Group-Abort-Session-Request/Answer (GASR/ 283 GASA)command exchange which allows a server to request the 284 termination of all sessions that are assigned to one of the groups 285 specified in the Session-Group-Id AVP in the request. 287 A client that receives an GASR with Session-Group-Id equal to a group 288 assigned to a currently active session MAY stop the session. Whether 289 the client stops the session or not is implementation- and/or 290 configuration-dependent. For example, a client may honor GASRs from 291 certain agents only. In any case, the client MUST respond with an 292 Group-Abort-Session-Answer, including a Result-Code AVP to indicate 293 what action it took. 295 If the client is able to perform the requested termination of the 296 sessions assigned to the group(s) specified in the GASR, it shall 297 return a GASA command with the Result-Code AVP set to 298 DIAMETER_SUCCESS and Session-Group-Id AVP(s) indicating the groups 299 for which the GASR receiver has active sessions assigned. If there 300 are no sessions assigned to the group(s) specified in the GASR, the 301 Result-Code is set to DIAMETER_UNKNOWN_SESSION_ID. If the client is 302 unable to perform the requested termination for any of the sessions, 303 the Result-Code is set to DIAMETER_UNABLE_TO_COMPLY. 305 When a client terminates a session upon receipt of a Group-Abort- 306 Session-Request, it MUST issue a session termination request to the 307 Diameter server that authorized the service. The Session-Group- 308 Action AVP specifies whether the server requires a single session 309 termination request per session (with STR message), per group (with 310 GSTR message) or for all groups (with GSTR message). 312 Diameter Diameter 313 Client Server 314 | | 315 (1)+-------------Svc-Specific-Auth-Request--------------->| 316 | Session-Id=ABC | 317 | | 318 (2)|<------------Svc-Specific-Auth-Answer-----------------+ 319 | Session-Id=ABC; Session-Group-Id=XYZ | 320 | | 321 (3)+-------------Svc-Specific-Auth-Request--------------->| 322 | Session-Id=DEF | 323 | | 324 (4)|<------------Svc-Specific-Auth-Answer-----------------+ 325 | Session-Id=DEF; Session-Group-Id=XYZ | 326 | | 327 (5)|<-----------Group-Abort-Session-Request---------------+ 328 | Session-Group-Id=XYZ; Session-Group-Action=PER_GROUP | 329 | | 330 (6)+------------Group-Abort-Session-Answer--------------->| 331 | | 332 (7)+---------Group-Session-Termination-Request----------->| 333 | Session-Group-Id=XYZ | 334 | | 335 (8)|<---------Group-Session-Termination-Answer------------+ 336 | | 338 Figure 2: Example: Aborting a Group of Sessions 340 In the example above, the Diameter server authorizes two sessions 341 (ABC and DEF) and assigns them to a group named XYZ (Session-Group- 342 Id=XYZ in steps 2 and 4). Some time later, an event occurs on the 343 Diameter server which requires it to abort the sessions assigned to 344 group XYZ. The Diameter server sends a Group-Abort-Session-Request 345 (step 5) specifying the sessions assigned to the impacted group 346 (Session-Group-Id=XYZ) are to be terminated and a single termination 347 command is to be sent per impacted group (Session-Group- 348 Action=PER_GROUP). The Diameter client acknowledges the request with 349 a GASA (step 6) and issues a GSTR (step 7) command to release all 350 resources for the sessions assigned to the group XYZ. The Diameter 351 server acknowledges the termination with a GGSTA (Step 8). 353 4. Protocol Description 355 4.1. Session Management 357 4.1.1. Authorization Session State Machine 359 Section 8.1 in [RFC3588] defines a set of finite state machines, 360 representing the life cycle of Diameter sessions, and which MUST be 361 observed by all Diameter implementations that make use of the 362 authentication and/or authorization portion of a Diameter 363 application. This section defines the additional state transitions 364 related to the processing of the new commands which may impact 365 multiple sessions. 367 The group membership is session state and therefore only those state 368 machines from [RFC3588] in which the server is maintaining session 369 state are relevant in this document. As in [RFC3588], the term 370 Service-Specific below refers to a message defined in a Diameter 371 application (e.g., Mobile IPv4, NASREQ). 373 The following state machine is observed by a client when state is 374 maintained on the server. State transitions which are unmodified 375 from [RFC3588] are not repeated here. 377 CLIENT, STATEFUL 378 State Event Action New State 379 --------------------------------------------------------------- 380 Idle Client or Device Requests Send Pending 381 access service 382 specific 383 auth req 384 optionally 385 including 386 groups 388 Open GASR received with Send GASA Discon 389 Session-Group-Action with 390 = ALL_GROUPS, Result-Code 391 session is assigned to = SUCCESS, 392 received group(s) and Send GSTR. 393 client will comply with 394 request to end the session 396 Open GASR received with Send GASA Discon 397 Session-Group-Action with 398 = PER_GROUPS, Result-Code 399 session is assigned to = SUCCESS, 400 received group(s) and Send GSTR 401 client will comply with per group 402 request to end the session 404 Open GASR received with Send GASA Discon 405 Session-Group-Action with 406 = PER_SESSION, Result-Code 407 session is assigned to = SUCCESS, 408 received group(s) and Send STR 409 client will comply with per session 410 request to end the session 412 Open GASR received, Send GASA Open 413 client will not comply with with 414 request to end all session Result-Code 415 in received group(s) != SUCCESS 417 Discon GSTA Received Discon. Idle 418 user/device 420 Open GRAR received with Send GRAA, Pending 421 Session-Group-Action Send 422 = ALL_GROUPS, service 423 session is assigned to specific 424 received group(s) and group 425 client will perform re-auth req 426 subsequent re-auth 428 Open GRAR received with Send GRAA, Pending 429 Session-Group-Action Send 430 = PER_GROUP, service 431 session is assigned to specific 432 received group(s) and group 433 client will perform re-auth req 434 subsequent re-auth per group 436 Open GRAR received with Send GRAA, Pending 437 Session-Group-Action Send 438 = PER_SESSION, service 439 session is assigned to specific 440 received group(s) and re-auth req 441 client will perform per session 442 subsequent re-auth 444 Open GRAR received and client will Send GRAA Idle 445 not perform subsequent with 446 re-auth Result-Code 447 != SUCCESS, 448 Discon. 449 user/device 451 Pending Successful service-specific Provide Open 452 group re-authorization answer service 453 received. 455 Pending Failed service-specific Discon. Idle 456 group re-authorization answer user/device 457 received. 459 The following state machine is observed by a server when it is 460 maintaining state for the session. State transitions which are 461 unmodified from [RFC3588] are not repeated here. 463 SERVER, STATEFUL 464 State Event Action New State 465 --------------------------------------------------------------- 467 Idle Service-specific authorization Send Open 468 request received, and user successful 469 is authorized service 470 specific 471 answer 472 optionally 473 including 474 groups 476 Open Server wants to terminate Send GASR Discon 477 group(s) 479 Discon GASA received Cleanup Idle 481 Any GSTR received Send GSTA, Idle 482 Cleanup 484 Open Server wants to reauth Send GRAR Pending 485 group(s) 487 Pending GRAA received with Result-Code Update Open 488 = SUCCESS session(s) 490 Pending GRAA received with Result-Code Cleanup Idle 491 != SUCCESS session(s) 493 Open Service-specific group Send Open 494 re-authoization request successful 495 received and user is service 496 authorized specific 497 group 498 re-auth 499 answer 501 Open Service-specific group Send Idle 502 re-authorization request failed 503 received and user is service 504 not authorized specific 505 group 506 re-auth 507 answer, 508 cleanup 510 4.2. Commands 512 Editor's Note: The content of this section does not represent working 513 group consensus but rather the views of the draft author prior to 514 (and post) adoption. Alternative methods for manipulating groups of 515 sessions are being considered by the working group and this section 516 may be heavily modified or removed in subsequent versions. 518 This specification extends the existing RAR, RAA, STR, STA, ASR and 519 ASA command ABNFs. 521 4.2.1. Group-Re-Auth-Request 523 The Group-Re-Auth-Request (GRAR), indicated by the Command-Code set 524 to TBD and the message flags' 'R' bit set, may be sent by any server 525 to the access device that is providing session service, to request 526 that one or more groups of users be re-authenticated and/or re- 527 authorized. 529 ::= < Diameter Header: TBD, REQ, PXY > 530 * { Session-Group-Id } 531 { Origin-Host } 532 { Origin-Realm } 533 { Destination-Realm } 534 { Destination-Host } 535 { Auth-Application-Id } 536 { Re-Auth-Request-Type } 537 [ Origin-State-Id ] 538 * [ Proxy-Info ] 539 * [ Route-Record ] 540 [ Session-Group-Action ] 541 * [ AVP ] 543 4.2.2. Group-Re-Auth-Answer 545 The Group-Re-Auth-Answer (GRAA), indicated by the Command-Code set to 546 TBD and the message flags' 'R' bit clear, is sent in response to the 547 GRAR. The Result-Code AVP MUST be present, and indicates the 548 disposition of the request. 550 ::= < Diameter Header: TBD, PXY > 551 * { Session-Group-Id } 552 { Result-Code } 553 { Origin-Host } 554 { Origin-Realm } 555 [ Origin-State-Id ] 556 [ Error-Message ] 557 [ Error-Reporting-Host ] 558 * [ Failed-AVP ] 559 * [ Redirect-Host ] 560 [ Redirect-Host-Usage ] 561 [ Redirect-Host-Cache-Time ] 562 * [ Proxy-Info ] 563 * [ AVP ] 565 4.2.3. Group-Session-Termination-Request 567 The Group-Session-Termination-Request (GSTR), indicated by the 568 Command-Code set to TBD and the Command Flags' 'R' bit set, is sent 569 by the access device to inform the Diameter Server that one or more 570 groups of authenticated and/or authorized sessions are being 571 terminated. 573 ::= < Diameter Header: TBD, REQ, PXY > 574 * { Session-Group-Id } 575 { Origin-Host } 576 { Origin-Realm } 577 { Destination-Realm } 578 { Auth-Application-Id } 579 { Termination-Cause } 580 [ Destination-Host ] 581 * [ Class ] 582 [ Origin-State-Id ] 583 * [ Proxy-Info ] 584 * [ Route-Record ] 585 * [ AVP ] 587 4.2.4. Group-Session-Termination-Answer 589 The Group-Session-Termination-Answer (GSTA), indicated by the 590 Command-Code set to TBD and the message flags' 'R' bit clear, is sent 591 by the Diameter Server to acknowledge the notification that one or 592 more groups of session have been terminated. The Result-Code AVP 593 MUST be present, and MAY contain an indication that an error occurred 594 while servicing the GSTR. 596 ::= < Diameter Header: TBD, PXY > 597 * { Session-Group-Id } 598 { Result-Code } 599 { Origin-Host } 600 { Origin-Realm } 601 * [ Class ] 602 [ Error-Message ] 603 [ Error-Reporting-Host ] 604 * [ Failed-AVP ] 605 [ Origin-State-Id ] 606 * [ Redirect-Host ] 607 [ Redirect-Host-Usage ] 608 [ Redirect-Max-Cache-Time ] 609 * [ Proxy-Info ] 610 * [ AVP ] 612 4.2.5. Group-Abort-Session-Request 614 The Group-Abort-Session-Request (GASR), indicated by the Command-Code 615 set to TBD and the message flags' 'R' bit set, may be sent by any 616 server to the access device that is providing session service, to 617 request that the sessions identified by the Session-Group-Id be 618 stopped. 620 ::= < Diameter Header: TBD, REQ, PXY > 621 * { Session-Group-Id } 622 { Origin-Host } 623 { Origin-Realm } 624 { Destination-Realm } 625 { Destination-Host } 626 { Auth-Application-Id } 627 [ Origin-State-Id ] 628 * [ Proxy-Info ] 629 * [ Route-Record ] 630 [ Group-Action ] 631 * [ AVP ] 633 4.2.6. Group-Abort-Session-Answer 635 The Group-Abort-Session-Answer (GASA), indicated by the Command-Code 636 set to TBD and the message flags' 'R' bit clear, is sent in response 637 to the GASR. The Result-Code AVP MUST be present, and indicates the 638 disposition of the request. 640 ::= < Diameter Header: TBD, PXY > 641 * { Session-Group-Id } 642 { Result-Code } 643 { Origin-Host } 644 { Origin-Realm } 645 [ Origin-State-Id ] 646 [ Error-Message ] 647 [ Error-Reporting-Host ] 648 * [ Failed-AVP ] 649 * [ Redirect-Host ] 650 [ Redirect-Host-Usage ] 651 [ Redirect-Max-Cache-Time ] 652 * [ Proxy-Info ] 653 * [ AVP ] 655 5. AVPs 657 +--------------------+ 658 | AVP Flag rules | 659 +----+---+------+----+ 660 AVP | | |SHOULD|MUST| 661 Attribute Name Code Value Type |MUST|MAY| NOT | NOT| 662 +---------------------------------------+----+---+------+----+ 663 |Session-Group-Id TBD OctetString | | P | | V | 664 |Session-Group-Action TBD Enumerated | | P | | V | 665 +---------------------------------------+----+---+------+----+ 667 AVPs for the Diameter Group Signaling 669 5.1. Session-Group-Id AVP 671 The Session-Group-Id AVP (AVP Code TBD) is of type OctetString and 672 identifies a group of sessions. This uniqueness scope of this AVP is 673 specified by the Diameter application which makes use of group 674 signaling commands. 676 5.2. Session-Group-Action AVP 678 The Session-Group-Action AVP (AVP Code TBD) is of type Enumerated and 679 specifies how the peer SHOULD issue follow up exchanges in response 680 to a command which impacts mulitple sessions. The following values 681 are supported: 683 ALL_GROUPS (0) 684 Follow up exchanges should be performed with a single message 685 exchange for all impacted groups. 687 PER_GROUP (1) 688 Follow up exchanges should be performed with a message exchange 689 for each impacted group. 691 PER_SESSION (2) 692 Follow up exchanges should be performed with a message exchange 693 for each impacted session. 695 6. Result-Code AVP Values 697 This section defines new Result-Code [RFC3588] values that MUST be 698 supported by all Diameter implementations that conform to this 699 specification. 701 [Editor's Note: Group specific error values may need to be added 702 here.] 704 7. IANA Considerations 706 This section contains the namespaces that have either been created in 707 this specification or had their values assigned to existing 708 namespaces managed by IANA. 710 7.1. Command Codes 712 This specification requires IANA to register the following new 713 Commands from the Command Code namespace defined in [RFC3588]. 715 o Group-Re-Auth-Request/Answer 717 o Group-Session-Termination-Request/Answer 719 o Group-Abort-Session-Request/Answer 721 The commands are defined in Section 4.2. 723 7.2. AVP Codes 725 This specification requires IANA to register the following new AVPs 726 from the AVP Code namespace defined in [RFC3588]. 728 o Session-Group-Id 730 o Session-Group-Action 732 The AVPs are defined in Section 5. 734 8. Security Considerations 736 TODO 738 9. Acknowledgments 739 10. Normative References 741 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 742 Requirement Levels", BCP 14, RFC 2119, March 1997. 744 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 745 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 747 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 748 "Diameter Network Access Server Application", RFC 4005, 749 August 2005. 751 Author's Address 753 Mark Jones 755 Email: mark@azu.ca