idnits 2.17.1 draft-jones-diameter-group-signaling-01.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 412 has weird spacing: '...ly with wit...' == Line 451 has weird spacing: '... answer servi...' == Line 455 has weird spacing: '... answer user/...' -- The document date (March 7, 2012) is 4432 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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 DIME M. Jones 3 Internet-Draft Amdocs 4 Intended status: Informational March 7, 2012 5 Expires: September 8, 2012 7 Diameter Group Signaling 8 draft-jones-diameter-group-signaling-01.txt 10 Abstract 12 In large network deployments, a single Diameter peer can support over 13 a million concurrent Diameter sessions. Recent use cases have 14 revealed the need for Diameter peers to apply the same operation to a 15 large group of Diameter sessions concurrently. The Diameter base 16 protocol commands operate on a single session so these use cases 17 could result in many thousands of command exchanges to enforce the 18 same operation on each session in the group. In order to reduce 19 signaling, it would be desirable to enable bulk operations on all (or 20 part of) the sessions managed by a Diameter peer using a single or a 21 few command exchanges. This document specifies the Diameter protocol 22 extensions to achieve this signaling optimization. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 8, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Grouping User Sessions . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Group assignment at session initiation . . . . . . . . . . 5 62 3.2. Mid-session group assignment modifications . . . . . . . . 5 63 3.2.1. Client-initiated group assignment changes . . . . . . 5 64 3.2.2. Server-initiated group assignment changes . . . . . . 5 65 3.3. Server Initiated Group Re-auth . . . . . . . . . . . . . . 6 66 3.4. Session Group Termination . . . . . . . . . . . . . . . . 7 67 3.5. Aborting a Group of Sessions . . . . . . . . . . . . . . . 8 68 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 10 69 4.1. Session Management . . . . . . . . . . . . . . . . . . . . 10 70 4.1.1. Authorization Session State Machine . . . . . . . . . 10 71 4.2. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 4.2.1. Group-Re-Auth-Request . . . . . . . . . . . . . . . . 14 73 4.2.2. Group-Re-Auth-Answer . . . . . . . . . . . . . . . . . 14 74 4.2.3. Group-Session-Termination-Request . . . . . . . . . . 15 75 4.2.4. Group-Session-Termination-Answer . . . . . . . . . . . 15 76 4.2.5. Group-Abort-Session-Request . . . . . . . . . . . . . 16 77 4.2.6. Group-Abort-Session-Answer . . . . . . . . . . . . . . 16 78 5. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 5.1. Session-Group-Id AVP . . . . . . . . . . . . . . . . . . . 18 80 5.2. Session-Group-Action AVP . . . . . . . . . . . . . . . . . 18 81 6. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 19 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 83 7.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 20 84 7.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 20 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 86 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 87 10. Normative References . . . . . . . . . . . . . . . . . . . . . 23 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 90 1. Introduction 92 In large network deployments, a single Diameter peer can support over 93 a million concurrent Diameter sessions. Recent use cases have 94 revealed the need for Diameter peers to apply the same operation to a 95 large group of Diameter sessions concurrently. For example, a policy 96 decision point may need to modify the authorized quality of service 97 for all active users having the same type of subscription. The 98 Diameter base protocol commands operate on a single session so these 99 use cases could result in many thousands of command exchanges to 100 enforce the same operation on each session in the group. In order to 101 reduce signaling, it would be desirable to enable bulk operations on 102 all (or part of) the sessions managed by a Diameter peer using a 103 single or a few command exchanges. 105 This document describes a mechanism for grouping Diameter sessions 106 and performing re-authentication, re-authorization, termination and 107 abortion of groups of sessions. This document does not define a new 108 Diameter application. Instead it defines mechanisms, commands and 109 AVPs that may be used by any Diameter application that requires 110 management of groups of sessions. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 This document uses terminology defined [RFC3588]. 120 3. Grouping User Sessions 122 Either Diameter peer may assign a session to a group. Diameter AAA 123 applications typically assign client and server roles to the Diameter 124 peers. In this document, a Diameter client is a node at the edge of 125 the network that performs access control. A Diameter server is a 126 node that performs authentication and/or authorization of the user. 128 3.1. Group assignment at session initiation 130 To assign a session to a group at session initiation, a Diameter 131 client sends a service specific auth request, e.g. NASREQ AAR 132 [RFC4005], containing zero or more client-assigned group identifiers. 133 Assuming the user is successfully authenticated and/or authorized, 134 the Diameter server responds with service-specific auth response, 135 e.g. NASREQ AAA [RFC4005], containing both the client-assigned group 136 identifiers and zero or more server-assigned group identifiers. 138 3.2. Mid-session group assignment modifications 140 Either Diameter peer may modify the group membership of an active 141 Diameter session. A Diameter client MAY remove the group(s) assigned 142 to the active session by the Diameter server and vice versa. 144 This document does not define a permission model that limits removal 145 of a session from a group by the same peer that added the session to 146 the group. However, applications which re-use the commands and 147 methods defined in this document may impose their own permission 148 model. For example, an application could require that the server 149 MUST NOT remove a session from a group assigned by the client. 151 3.2.1. Client-initiated group assignment changes 153 To update the assigned groups mid-session, a Diameter client sends a 154 service specific re-authorization request containing the updated list 155 of group identifiers. Assuming the user is successfully 156 authenticated and/or authorized, the Diameter server responds with a 157 service-specific auth response containing the updated list of group 158 identifiers received in the request. 160 3.2.2. Server-initiated group assignment changes 162 To update the assigned groups mid-session, a Diameter server sends a 163 Re-authorization Request (RAR) message requesting re-authorization 164 and the client responds with a Re-authorization Answer (RAA) message. 165 The Diameter client sends a service specific re-authorization request 166 containing the current list of group identifiers and the Diameter 167 server responds with a service-specific auth response containing the 168 updated list of group identifiers. 170 3.3. Server Initiated Group Re-auth 172 This document defines a new Group-Re-Auth-Request/Answer (GRAR/ 173 GRAA)command exchange which allows a server to initiate a re- 174 authentication and/or re-authorization of all services that are 175 assigned to one of the groups specified in the Session-Group-Id AVP 176 in the request. 178 An access device that receives a Group-Re-Auth-Request(GRAR) message 179 with Session-Group-Id equal to one of the group assigned to a 180 currently active session MUST initiate the type of re-auth specified 181 by the Re-Auth-Request-Type AVP in the manner specified by the 182 Session-Group-Action AVP if the service supports this particular 183 feature. Each Diameter application MUST state whether service- 184 initiated group re-authentication and/or re-authorization is 185 supported and which Session-Group-Action AVP values are supported for 186 re-authorization. 188 The Session-Group-Action AVP specifies whether the server requires a 189 re-authorization request per session, per group or for all groups. 190 For a Re-Auth-Request-Type value of AUTHORIZE_AUTHENTICATE, the 191 Session-Group-Action value MUST be PER_SESSION since re- 192 authentication MUST be performed per user session. 194 For Session-Group-Action values of PER_GROUP or ALL_GROUPS, the re- 195 authorization is accomplished with an application-specifc group re- 196 authorization command exchange. This command exchange as well as any 197 limitations on which aspects of the service can be modified during a 198 re-authorization MUST be defined by the Diameter application. 200 If the client is able to perform the requested re-authentication 201 and/or re-authentication for the sessions assigned to the group(s) 202 specified in the GRAR, it shall return a GRAA command with the 203 Result-Code AVP set to DIAMETER_SUCCESS and Session-Group-Id AVP(s) 204 indicating the groups for which the GRAR receiver has active sessions 205 assigned. If there are no sessions assigned to the group(s) 206 specified in the GRAR, the Result-Code is set to 207 DIAMETER_UNKNOWN_SESSION_ID. If the client is unable to perform the 208 requested re-authentication and/or re-authentication, the Result-Code 209 is set to DIAMETER_UNABLE_TO_COMPLY. 211 Diameter Diameter 212 Client Server 213 | | 214 (1)+-------------Svc-Specific-Auth-Request--------------->| 215 | Session-Id=ABC | 216 | | 217 (2)|<------------Svc-Specific-Auth-Answer-----------------+ 218 | Session-Id=ABC; Session-Group-Id=XYZ | 219 | | 220 (3)+-------------Svc-Specific-Auth-Request--------------->| 221 | Session-Id=DEF | 222 | | 223 (4)|<------------Svc-Specific-Auth-Answer-----------------+ 224 | Session-Id=DEF; Session-Group-Id=XYZ | 225 | | 226 (5)|<--------------Group-Re-Auth-Request------------------+ 227 | Session-Group-Id=XYZ; Session-Group-Action=PER_GROUP | 228 | Re-Auth_Request-Type=AUTHORIZE_ONLY | 229 | | 230 (6)+---------------Group-Re-Auth-Answer------------------>| 231 | | 232 (7)+----------Svc-Specific-Group-Auth-Request------------>| 233 | Session-Group-Id=XYZ | 234 | | 235 (8)|<---------Svc-Specific-Group-Auth-Answer--------------+ 236 | Updated Service Specific AVPs | 237 | | 239 Figure 1: Example: Group Re-authorization 241 In the example above, the Diameter server authorizes two sessions 242 (ABC and DEF) and assigns them to a group named XYZ (Session-Group- 243 Id=XYZ in steps 2 and 4). Some time later, an event occurs on the 244 Diameter server which requires it to change one or more of the 245 service parameters for the sessions assigned to group XYZ. The 246 Diameter server sends a Group-Re-Auth-Request (step 5) specifying the 247 impacted group (Session-Group-Id=XYZ) must be re-authorized (Re-Auth- 248 Request-Type=AUTHORIZE_ONLY) with a single re-authorize command per 249 group (Session-Group-Action=PER_GROUP). The Diameter client 250 acknowledges the request (step 6) and issues a service-specific group 251 authorization request to retrieve the updated service parameters 252 (step 7). 254 3.4. Session Group Termination 256 This document defines a new Group-Session-Termination-Request/Answer 257 (GSTR/GSTA) command exchange which allows a client to communicate to 258 the server the termination of all sessions that are assigned to one 259 of the groups specified in the Session-Group-Id AVP in the request. 260 The termination of a group of sessions could occur as a result of a 261 local action or in reponse to a request to abort one or more groups 262 of sessions. 264 FFS: When a client sends an GSTR to a server indicating termination 265 of a specific group, is it indicating termination of the sessions 266 that the server authorized and that are assigned to the specified 267 group? Or does imply termination of all sessions on the client that 268 are assigned to the specified group? 270 Upon receipt of the GSTR, the Diameter Server MUST release all 271 resources for the sessions assigned to the group(s) specified in the 272 Session-Group-Id AVP and return a GSTA with the Result-Code set to 273 DIAMETER_SUCCESS to acknowledge the successful termination. If there 274 are no sessions assigned to the group(s) specified in the GSTR, the 275 Result-Code is set to DIAMETER_UNKNOWN_SESSION_ID. If the server is 276 unable to perform the session termination, the Result-Code is set to 277 DIAMETER_UNABLE_TO_COMPLY. 279 3.5. Aborting a Group of Sessions 281 This document defines a new Group-Abort-Session-Request/Answer (GASR/ 282 GASA)command exchange which allows a server to request the 283 termination of all sessions that are assigned to one of the groups 284 specified in the Session-Group-Id AVP in the request. 286 A client that receives an GASR with Session-Group-Id equal to a group 287 assigned to a currently active session MAY stop the session. Whether 288 the client stops the session or not is implementation- and/or 289 configuration-dependent. For example, a client may honor GASRs from 290 certain agents only. In any case, the client MUST respond with an 291 Group-Abort-Session-Answer, including a Result-Code AVP to indicate 292 what action it took. 294 If the client is able to perform the requested termination of the 295 sessions assigned to the group(s) specified in the GASR, it shall 296 return a GASA command with the Result-Code AVP set to 297 DIAMETER_SUCCESS and Session-Group-Id AVP(s) indicating the groups 298 for which the GASR receiver has active sessions assigned. If there 299 are no sessions assigned to the group(s) specified in the GASR, the 300 Result-Code is set to DIAMETER_UNKNOWN_SESSION_ID. If the client is 301 unable to perform the requested termination for any of the sessions, 302 the Result-Code is set to DIAMETER_UNABLE_TO_COMPLY. 304 When a client terminates a session upon receipt of a Group-Abort- 305 Session-Request, it MUST issue a session termination request to the 306 Diameter server that authorized the service. The Session-Group- 307 Action AVP specifies whether the server requires a single session 308 termination request per session (with STR message), per group (with 309 GSTR message) or for all groups (with GSTR message). 311 Diameter Diameter 312 Client Server 313 | | 314 (1)+-------------Svc-Specific-Auth-Request--------------->| 315 | Session-Id=ABC | 316 | | 317 (2)|<------------Svc-Specific-Auth-Answer-----------------+ 318 | Session-Id=ABC; Session-Group-Id=XYZ | 319 | | 320 (3)+-------------Svc-Specific-Auth-Request--------------->| 321 | Session-Id=DEF | 322 | | 323 (4)|<------------Svc-Specific-Auth-Answer-----------------+ 324 | Session-Id=DEF; Session-Group-Id=XYZ | 325 | | 326 (5)|<-----------Group-Abort-Session-Request---------------+ 327 | Session-Group-Id=XYZ; Session-Group-Action=PER_GROUP | 328 | | 329 (6)+------------Group-Abort-Session-Answer--------------->| 330 | | 331 (7)+---------Group-Session-Termination-Request----------->| 332 | Session-Group-Id=XYZ | 333 | | 334 (8)|<---------Group-Session-Termination-Answer------------+ 335 | | 337 Figure 2: Example: Aborting a Group of Sessions 339 In the example above, the Diameter server authorizes two sessions 340 (ABC and DEF) and assigns them to a group named XYZ (Session-Group- 341 Id=XYZ in steps 2 and 4). Some time later, an event occurs on the 342 Diameter server which requires it to abort the sessions assigned to 343 group XYZ. The Diameter server sends a Group-Abort-Session-Request 344 (step 5) specifying the sessions assigned to the impacted group 345 (Session-Group-Id=XYZ) are to be terminated and a single termination 346 command is to be sent per impacted group (Session-Group- 347 Action=PER_GROUP). The Diameter client acknowledges the request with 348 a GASA (step 6) and issues a GSTR (step 7) command to release all 349 resources for the sessions assigned to the group XYZ. The Diameter 350 server acknowledges the termination with a GGSTA (Step 8). 352 4. Protocol Description 354 4.1. Session Management 356 4.1.1. Authorization Session State Machine 358 Section 8.1 in [RFC3588] defines a set of finite state machines, 359 representing the life cycle of Diameter sessions, and which MUST be 360 observed by all Diameter implementations that make use of the 361 authentication and/or authorization portion of a Diameter 362 application. This section defines the additional state transitions 363 related to the processing of the new commands which may impact 364 multiple sessions. 366 The group membership is session state and therefore only those state 367 machines from [RFC3588] in which the server is maintaining session 368 state are relevant in this document. As in [RFC3588], the term 369 Service-Specific below refers to a message defined in a Diameter 370 application (e.g., Mobile IPv4, NASREQ). 372 The following state machine is observed by a client when state is 373 maintained on the server. State transitions which are unmodified 374 from [RFC3588] are not repeated here. 376 CLIENT, STATEFUL 377 State Event Action New State 378 --------------------------------------------------------------- 379 Idle Client or Device Requests Send Pending 380 access service 381 specific 382 auth req 383 optionally 384 including 385 groups 387 Open GASR received with Send GASA Discon 388 Session-Group-Action with 389 = ALL_GROUPS, Result-Code 390 session is assigned to = SUCCESS, 391 received group(s) and Send GSTR. 392 client will comply with 393 request to end the session 395 Open GASR received with Send GASA Discon 396 Session-Group-Action with 397 = PER_GROUPS, Result-Code 398 session is assigned to = SUCCESS, 399 received group(s) and Send GSTR 400 client will comply with per group 401 request to end the session 403 Open GASR received with Send GASA Discon 404 Session-Group-Action with 405 = PER_SESSION, Result-Code 406 session is assigned to = SUCCESS, 407 received group(s) and Send STR 408 client will comply with per session 409 request to end the session 411 Open GASR received, Send GASA Open 412 client will not comply with with 413 request to end all session Result-Code 414 in received group(s) != SUCCESS 416 Discon GSTA Received Discon. Idle 417 user/device 419 Open GRAR received with Send GRAA, Pending 420 Session-Group-Action Send 421 = ALL_GROUPS, service 422 session is assigned to specific 423 received group(s) and group 424 client will perform re-auth req 425 subsequent re-auth 427 Open GRAR received with Send GRAA, Pending 428 Session-Group-Action Send 429 = PER_GROUP, service 430 session is assigned to specific 431 received group(s) and group 432 client will perform re-auth req 433 subsequent re-auth per group 435 Open GRAR received with Send GRAA, Pending 436 Session-Group-Action Send 437 = PER_SESSION, service 438 session is assigned to specific 439 received group(s) and re-auth req 440 client will perform per session 441 subsequent re-auth 443 Open GRAR received and client will Send GRAA Idle 444 not perform subsequent with 445 re-auth Result-Code 446 != SUCCESS, 447 Discon. 448 user/device 450 Pending Successful service-specific Provide Open 451 group re-authorization answer service 452 received. 454 Pending Failed service-specific Discon. Idle 455 group re-authorization answer user/device 456 received. 458 The following state machine is observed by a server when it is 459 maintaining state for the session. State transitions which are 460 unmodified from [RFC3588] are not repeated here. 462 SERVER, STATEFUL 463 State Event Action New State 464 --------------------------------------------------------------- 466 Idle Service-specific authorization Send Open 467 request received, and user successful 468 is authorized service 469 specific 470 answer 471 optionally 472 including 473 groups 475 Open Server wants to terminate Send GASR Discon 476 group(s) 478 Discon GASA received Cleanup Idle 480 Any GSTR received Send GSTA, Idle 481 Cleanup 483 Open Server wants to reauth Send GRAR Pending 484 group(s) 486 Pending GRAA received with Result-Code Update Open 487 = SUCCESS session(s) 489 Pending GRAA received with Result-Code Cleanup Idle 490 != SUCCESS session(s) 492 Open Service-specific group Send Open 493 re-authoization request successful 494 received and user is service 495 authorized specific 496 group 497 re-auth 498 answer 500 Open Service-specific group Send Idle 501 re-authorization request failed 502 received and user is service 503 not authorized specific 504 group 505 re-auth 506 answer, 507 cleanup 509 4.2. Commands 511 This specification extends the existing RAR, RAA, STR, STA, ASR and 512 ASA command ABNFs. 514 4.2.1. Group-Re-Auth-Request 516 The Group-Re-Auth-Request (GRAR), indicated by the Command-Code set 517 to TBD and the message flags' 'R' bit set, may be sent by any server 518 to the access device that is providing session service, to request 519 that one or more groups of users be re-authenticated and/or re- 520 authorized. 522 ::= < Diameter Header: TBD, REQ, PXY > 523 * { Session-Group-Id } 524 { Origin-Host } 525 { Origin-Realm } 526 { Destination-Realm } 527 { Destination-Host } 528 { Auth-Application-Id } 529 { Re-Auth-Request-Type } 530 [ Origin-State-Id ] 531 * [ Proxy-Info ] 532 * [ Route-Record ] 533 [ Session-Group-Action ] 534 * [ AVP ] 536 4.2.2. Group-Re-Auth-Answer 538 The Group-Re-Auth-Answer (GRAA), indicated by the Command-Code set to 539 TBD and the message flags' 'R' bit clear, is sent in response to the 540 GRAR. The Result-Code AVP MUST be present, and indicates the 541 disposition of the request. 543 ::= < Diameter Header: TBD, PXY > 544 * { Session-Group-Id } 545 { Result-Code } 546 { Origin-Host } 547 { Origin-Realm } 548 [ Origin-State-Id ] 549 [ Error-Message ] 550 [ Error-Reporting-Host ] 551 * [ Failed-AVP ] 552 * [ Redirect-Host ] 553 [ Redirect-Host-Usage ] 554 [ Redirect-Host-Cache-Time ] 555 * [ Proxy-Info ] 556 * [ AVP ] 558 4.2.3. Group-Session-Termination-Request 560 The Group-Session-Termination-Request (GSTR), indicated by the 561 Command-Code set to TBD and the Command Flags' 'R' bit set, is sent 562 by the access device to inform the Diameter Server that one or more 563 groups of authenticated and/or authorized sessions are being 564 terminated. 566 ::= < Diameter Header: TBD, REQ, PXY > 567 * { Session-Group-Id } 568 { Origin-Host } 569 { Origin-Realm } 570 { Destination-Realm } 571 { Auth-Application-Id } 572 { Termination-Cause } 573 [ Destination-Host ] 574 * [ Class ] 575 [ Origin-State-Id ] 576 * [ Proxy-Info ] 577 * [ Route-Record ] 578 * [ AVP ] 580 4.2.4. Group-Session-Termination-Answer 582 The Group-Session-Termination-Answer (GSTA), indicated by the 583 Command-Code set to TBD and the message flags' 'R' bit clear, is sent 584 by the Diameter Server to acknowledge the notification that one or 585 more groups of session have been terminated. The Result-Code AVP 586 MUST be present, and MAY contain an indication that an error occurred 587 while servicing the GSTR. 589 ::= < Diameter Header: TBD, PXY > 590 * { Session-Group-Id } 591 { Result-Code } 592 { Origin-Host } 593 { Origin-Realm } 594 * [ Class ] 595 [ Error-Message ] 596 [ Error-Reporting-Host ] 597 * [ Failed-AVP ] 598 [ Origin-State-Id ] 599 * [ Redirect-Host ] 600 [ Redirect-Host-Usage ] 601 [ Redirect-Max-Cache-Time ] 602 * [ Proxy-Info ] 603 * [ AVP ] 605 4.2.5. Group-Abort-Session-Request 607 The Group-Abort-Session-Request (GASR), indicated by the Command-Code 608 set to TBD and the message flags' 'R' bit set, may be sent by any 609 server to the access device that is providing session service, to 610 request that the sessions identified by the Session-Group-Id be 611 stopped. 613 ::= < Diameter Header: TBD, REQ, PXY > 614 * { Session-Group-Id } 615 { Origin-Host } 616 { Origin-Realm } 617 { Destination-Realm } 618 { Destination-Host } 619 { Auth-Application-Id } 620 [ Origin-State-Id ] 621 * [ Proxy-Info ] 622 * [ Route-Record ] 623 [ Group-Action ] 624 * [ AVP ] 626 4.2.6. Group-Abort-Session-Answer 628 The Group-Abort-Session-Answer (GASA), indicated by the Command-Code 629 set to TBD and the message flags' 'R' bit clear, is sent in response 630 to the GASR. The Result-Code AVP MUST be present, and indicates the 631 disposition of the request. 633 ::= < Diameter Header: TBD, PXY > 634 * { Session-Group-Id } 635 { Result-Code } 636 { Origin-Host } 637 { Origin-Realm } 638 [ Origin-State-Id ] 639 [ Error-Message ] 640 [ Error-Reporting-Host ] 641 * [ Failed-AVP ] 642 * [ Redirect-Host ] 643 [ Redirect-Host-Usage ] 644 [ Redirect-Max-Cache-Time ] 645 * [ Proxy-Info ] 646 * [ AVP ] 648 5. AVPs 650 +--------------------+ 651 | AVP Flag rules | 652 +----+---+------+----+ 653 AVP | | |SHOULD|MUST| 654 Attribute Name Code Value Type |MUST|MAY| NOT | NOT| 655 +---------------------------------------+----+---+------+----+ 656 |Session-Group-Id TBD OctetString | | P | | V | 657 |Session-Group-Action TBD Enumerated | | P | | V | 658 +---------------------------------------+----+---+------+----+ 660 AVPs for the Diameter Group Signaling 662 5.1. Session-Group-Id AVP 664 The Session-Group-Id AVP (AVP Code TBD) is of type OctetString and 665 identifies a group of sessions. This uniqueness scope of this AVP is 666 specified by the Diameter application which makes use of group 667 signaling commands. 669 5.2. Session-Group-Action AVP 671 The Session-Group-Action AVP (AVP Code TBD) is of type Enumerated and 672 specifies how the peer SHOULD issue follow up exchanges in response 673 to a command which impacts mulitple sessions. The following values 674 are supported: 676 ALL_GROUPS (0) 677 Follow up exchanges should be performed with a single message 678 exchange for all impacted groups. 680 PER_GROUP (1) 681 Follow up exchanges should be performed with a message exchange 682 for each impacted group. 684 PER_SESSION (2) 685 Follow up exchanges should be performed with a message exchange 686 for each impacted session. 688 6. Result-Code AVP Values 690 This section defines new Result-Code [RFC3588] values that MUST be 691 supported by all Diameter implementations that conform to this 692 specification. 694 [Editor's Note: Group specific error values may need to be added 695 here.] 697 7. IANA Considerations 699 This section contains the namespaces that have either been created in 700 this specification or had their values assigned to existing 701 namespaces managed by IANA. 703 7.1. Command Codes 705 This specification requires IANA to register the following new 706 Commands from the Command Code namespace defined in [RFC3588]. 708 o Group-Re-Auth-Request/Answer 710 o Group-Session-Termination-Request/Answer 712 o Group-Abort-Session-Request/Answer 714 The commands are defined in Section 4.2. 716 7.2. AVP Codes 718 This specification requires IANA to register the following new AVPs 719 from the AVP Code namespace defined in [RFC3588]. 721 o Session-Group-Id 723 o Session-Group-Action 725 The AVPs are defined in Section 5. 727 8. Security Considerations 729 TODO 731 9. Acknowledgments 732 10. 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 Author's Address 746 Mark Jones 747 Amdocs 749 Email: mark@azu.ca