idnits 2.17.00 (12 Aug 2021) /tmp/idnits42927/draft-fajardo-dime-dcc-test-suite-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 618. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1, 2007) is 5437 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 4006 (Obsoleted by RFC 8506) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DIME Working Group A. McNamee 3 Internet-Draft Openet-Telecom 4 Expires: January 2, 2008 H. Tschofenig 5 Nokia Siemens Networks 6 V. Fajardo 7 TARI 8 J. Bournelle 9 France Telecom R&D 10 July 1, 2007 12 Diameter Credit Control Interoperability Test Suite 13 draft-fajardo-dime-dcc-test-suite-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 2, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 This document describes a collection of test cases to be used for 47 Diameter Credit Control application interoperability testing. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Diameter Credit Control Test Suite . . . . . . . . . . . . . . 3 54 3.1. Required . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3.1.1. Session Based Credit Control First Interrogation . . . 5 56 3.1.2. Session Based Credit Control Intermediate 57 Interrogation . . . . . . . . . . . . . . . . . . . . 6 58 3.1.3. Session Based Credit Control Final Interrogation . . . 7 59 3.1.4. Sub Sessions . . . . . . . . . . . . . . . . . . . . . 7 60 3.1.5. Session Based Credit Control Failure Procedures . . . 8 61 3.1.6. Service Price Enquiry . . . . . . . . . . . . . . . . 8 62 3.1.7. Balance Check . . . . . . . . . . . . . . . . . . . . 8 63 3.1.8. Direct Debiting . . . . . . . . . . . . . . . . . . . 9 64 3.1.9. Refunds . . . . . . . . . . . . . . . . . . . . . . . 9 65 3.1.10. Event Based Credit Control Failure Procedures . . . . 10 66 3.2. Optional . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 3.2.1. Tariff Time Support . . . . . . . . . . . . . . . . . 10 68 3.2.2. Graceful Service Termination . . . . . . . . . . . . . 10 69 3.2.3. Validity Time . . . . . . . . . . . . . . . . . . . . 11 70 3.2.4. Server Initiated Credit Reauthorization . . . . . . . 11 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 6. Normative References . . . . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 75 Intellectual Property and Copyright Statements . . . . . . . . . . 14 77 1. Introduction 79 The document is a companion document to the Diameter Base Protocol 80 Interoperability Test Suite. This document is meant to aid in the 81 identifying the functional test cases of a Diameter Credit Control 82 implementation. The Diameter Credit Control interoperability test 83 suites are categorized by required and optional functionality. The 84 required functionality is the baseline capability that an 85 implementation must support to allow basic interoperability for that 86 category. Optional functionality covers features that not all 87 implementations support or may wish to test. 89 At its current state, this document provides only a collection of 90 test cases designed for interoperability. Test plans may be included 91 in future revisions of this work or maybe provided in some other 92 document. 94 2. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 Within this document the terms defined in [RFC2119] refer to the 101 functionality that has to be provided by an implementation for the 102 usage within this interoperability test document. 104 3. Diameter Credit Control Test Suite 106 Vendors that support the Diameter Credit Control application must 107 conform to [RFC4006]. The typical test topology for credit control 108 authorization is shown in Figure 1. A user typically requests a 109 service and thereby triggers the CC Client to contact the CC Server 110 requesting the CC Server to verify the user's credit standing prior 111 to service delivery. Since the test cases cover only CC Client and 112 CC Server interoperability, it is left to the tester to verify 113 correctness of the authentication method executed between the user 114 and the AAA server that is used as a pre-requisite for the 115 authorization of the user by the CC server. Additionally, the 116 interaction between the User's host and the CC Client that is used to 117 trigger the interaction between the CC client and the CC Server is 118 outside the scope of this document. 120 +--------+ +-----------+ +------------+ 121 | User |<--->| CC Client |<--->| AAA Server | 122 +--------+ +-----^-----+ +-----^------+ 123 | | 124 | | 125 | +-----V-----+ 126 +---------->| CC Server | 127 +-----------+ 129 Legend: 130 User - Simulated end user 131 CC Client - Vendor A Diam CCA client 132 CC Server - Vendor B Diam CCA server 134 Figure 1: Diameter CC Test Topology 136 A second test topology can exist for testing Diameter/RADIUS 137 translation agent as specified in Section 11 of [RFC4006]. This 138 topology is available for vendors implementing a prepaid RADIUS 139 translation agent. Since the test cases cover interoperability 140 scenarios, validation must be done between the Service Element and 141 the AAA Server/CC Client translation agent. As with Figure 1, it is 142 left to the tester to verify correctness of the access method between 143 User and Service Element. The test cases involving Figure 1 are also 144 relevant to validating AAA Server/CC Client and CC Server and should 145 be used in this topology as well. 147 +------+ +---------+ +---------------+ 148 | User |<--->| Service |<--->| AAA Server | 149 +------+ | Element | | +---------+ | 150 +---------+ | |CC Client| | 151 | +---------+ | 152 +--+----^----+--+ 153 | 154 | 155 +-----V-----+ 156 | CC Server | 157 +-----------+ 158 Legend: 159 User - Simulated user 160 Service Element - Simulated or vendor RADIUS prepaid 161 client application client 162 AAA Server/CC Client - Vendor A Diameter/RADIUS 163 translation agent 164 CC Server - Vendor B Diameter CC Server 166 Figure 2: Translation Gateway Test Topology 168 3.1. Required 170 Either test topology Figure 1 or Figure 2 can be used for these 171 cases. 173 3.1.1. Session Based Credit Control First Interrogation 175 Implementations must conform to Section 5.2 of [RFC4006]. This 176 section addresses the initial credit control interactions between a 177 CC Client and a CC Server, i.e., CC-Request-Type is set to the value 178 INITIAL_REQUEST in the CCR message. There are many parameters on 179 which a service can be granted a credit authorization but the 180 objective of these tests is to demonstrate for session based services 181 the initial credit authorization handling procedures are supported. 182 o Positive tests for credit authorization for a session based 183 service with the Requested-Service-Unit AVP NOT present. The 184 service quota profiles should be agreed between the vendors. The 185 test should be repeated to verify support for the following quota 186 types: 187 * Time based services. 188 * Volume (Total, Input, Output Octets) based services. 189 * Services with quota using service specific units. 190 * Money based services. 191 * Services with several unit types granted. 192 o Positive tests for credit authorization for a session based 193 service with the Requested-Service-Unit AVP being present. The 194 service quota profiles should be agreed between the vendors. The 195 test should be repeated to verify support for the following quota 196 types: 197 * Time based services. 198 * Volume (Total, Input, Output Octets) based services. 199 * Services with quota using service specific units. 200 * Money based services. 201 * Services with several unit types granted. 202 o Positive test for the CC Server's ability to support the granting 203 alternative amounts of credit to the values requested in the 204 Requested-Service-Unit AVP of the CCR message. 205 o Negative test for first interrogation of session based services 206 when the CC Server could not process the initial CCR message. 207 Verify support for the graceful handling of events such as unknown 208 end user, account being empty, invalid rating input, or errors 209 defined in [RFC3588]. 210 o Negative test for first interrogation of session based services 211 when the CC Client could not process the initial CCA message. 212 Verify support for the graceful handling of events such as 213 unsupported unit types. 215 o Negative test for first interrogation of session based services 216 when the CC Server includes a Final-Unit-Indication AVP with 217 Final-Unit-Action REDIRECT or RESTRICT_ACCESS in the Credit- 218 Control-Answer or in the AA answer. Verify that CC Client behaves 219 as directed. 221 3.1.2. Session Based Credit Control Intermediate Interrogation 223 Implementations must conform to Section 5.3 of [RFC4006]. This 224 section addresses the intermediate credit control interactions 225 between a CC Client and a CC Server, i.e., CC-Request-Type is set to 226 the value UPDATE_REQUEST in the CCR message. There are many 227 parameters on which a service can be reauthorized credit but the 228 objective of these tests is to demonstrate for session based services 229 the intermediate credit authorization handling procedures are 230 supported. 231 o Positive tests for credit reauthorization for a session based 232 service with the Requested-Service-Unit AVP NOT present. The 233 Event-Timestamp AVP must be used to mark the time the 234 reauthorization was triggered and the Used-Service-Unit AVP 235 contains the amount of used service units since the service was 236 activated or last interim. The service quota profiles should be 237 agreed between the vendors. The test should be repeated to verify 238 support for the following quota types: 239 * Time based services. 240 * Volume (Total, Input, Output Octets) based services. 241 * Services with quota using service specific units. 242 * Money based services. 243 * Services with several unit types granted. 244 o Positive tests for credit authorization for a session based 245 service with the Requested-Service-Unit AVP is present. The 246 Event-Timestamp AVP must be used to mark the time the 247 reauthorization was triggered and the Used-Service-Unit AVP 248 contains the amount of used service units since the service was 249 activated or last interim. The service quota profiles should be 250 agreed between the vendors. The test should be repeated to verify 251 support for the following quota types: 252 * Time based services. 253 * Volume (Total, Input, Output Octets) based services. 254 * Services with quota using service specific units. 255 * Money based services. 256 * Services with several unit types granted. 257 o Positive test for the CC Server's ability to support the granting 258 alternative amounts of credit to the values requested in the 259 Requested-Service-Unit AVP of the CCR message. 260 o Negative test for intermediate interrogation for session based 261 services when the CC Server could not process the update CCR 262 message. Verify support for the graceful handling of events such 263 as subscription ID missing, account being empty, invalid rating 264 input, or errors defined in [RFC3588]. 265 o Negative test for intermediate interrogation for session based 266 services when the CC Client could not process the update CCA 267 message. Verify support for the graceful handling of events such 268 as unsupported unit types. 270 3.1.3. Session Based Credit Control Final Interrogation 272 Implementations must conform to Section 5.4 of [RFC4006]. This 273 section addresses the final credit control interactions between a 274 credit control application client and server i.e., CC-Request-Type is 275 set to the value TERMINATION_REQUEST in the CCR message. 276 o Positive test for final interrogation for a session based service. 277 The Event-Timestamp AVP should be used to mark the time the 278 interrogation was triggered and the Used-Service-Unit AVP contains 279 the amount of used service units since the service was activated 280 or last interim. The CC Server must verify support for refunding 281 the unused reserved units and for charging the used monetary 282 amount to the end user's account. 284 3.1.4. Sub Sessions 286 Implementations must conform to Section 5.1.2 of [RFC4006]. 287 o Positive test for multiple services within a session. Verify 288 vendor support for interrogations when the Multiple-Services- 289 Credit-Control AVP present and the Requested-Service-Unit AVP is 290 not present. 291 o Positive test for multiple services within a session. Verify 292 vendor support for interrogations when the Multiple-Services- 293 Credit-Control AVP present and the Requested-Service-Unit AVP is 294 present. 295 o Positive test for credit pool support. Verify that a vendor's CC 296 Server implementation is capable of supporting credit pools for 297 services by including a G-S-U-Reference within a Granted-Service- 298 Unit AVP in a CCA message. An example scenario is detailed in 299 Appendix A (Flow IX) of [RFC4006]. 300 o Positive test for rating group support. Verify that a vendor's CC 301 Client implementation is capable of associating a service with a 302 rating group by including a Rating-Group AVP in an interrogation. 303 An example scenario is detailed in Appendix A (Flow IX) of 304 [RFC4006]. 305 o Negative test for multiple services within a session. Verify that 306 a CC Server not supporting multiple services within a session 307 treats the Multiple-Services-Indicator AVP and any received 308 Multiple-Services-Credit-Control AVPs as invalid AVPs. 310 o Negative test for invalid/insufficient rating input. Verify that 311 a CC Server receiving invalid rating input (e.g., unknown rating 312 group) shall inform the CC Client by including a result code of 313 DIAMETER_RATING_FAILED in the Multiple-Services-Credit-Control 314 AVP. 316 3.1.5. Session Based Credit Control Failure Procedures 318 Implementations must conform to Section 5.7 of [RFC4006]. 319 o Test failure behavior when Credit-Control-Failure-Handling AVP is 320 set to TERMINATE. Verify that the CC Client terminates the end 321 user's session if it does not receive a CCA message within the Tx 322 timer. 323 o Test failure behavior when Credit-Control-Failure-Handling AVP is 324 set to CONTINUE. Verify that when CC messages cannot be delivered 325 to CC Server because of transport or temporary failures that the 326 CC Client resends the request to a backup CC Server assuming CC 327 failover is supported or else the service should be granted by the 328 CC Client. 329 o Test failure behavior when Credit-Control-Failure-Handling AVP is 330 set to RETRY_AND_TERMINATE. Verify that when CC messages cannot 331 be delivered to the CC Server because of transport or temporary 332 failures that the CC Client resends the request to a backup CC 333 Server assuming CC failover is supported or else the service 334 should not be granted by the CC Client. 336 3.1.6. Service Price Enquiry 338 Implementations must conform to Section 6.1 of [RFC4006]. This test 339 uses an event based credit control interaction between the CC Client 340 and the CC Server (i.e., CC-Request-Type is set to the value 341 EVENT_REQUEST in the CCR message). The test is invoked by the CC 342 Client including the Service-Identifier and the Requested-Action AVP 343 set to PRICE_ENQUIRY in the CCR message. An example message flow is 344 shown in Appendix A (Flow V) of [RFC4006]. 345 o Positive test for a service price enquiry. Verify that the CC 346 Server returns the estimated cost of the service to the CC Client 347 in the in the Cost-Information AVP in the CCA message. 349 3.1.7. Balance Check 351 Implementations must conform to Section 6.2 of [RFC4006]. This test 352 uses an event based credit control interaction between the CC Client 353 and CC Server (i.e., CC-Request-Type is set to the value 354 EVENT_REQUEST in the CCR message). The test is invoked by the CC 355 Client including the Service-Identifier and the Requested-Action AVP 356 set to CHECK_BALANCE in the CCR message. An example scenario is 357 detailed in Appendix A (Flow IV) of [RFC4006]. 359 o Positive test for a check balance enquiry. Verify that the CC 360 Server returns the credit status for the subscriber to access the 361 service to the CC Client in the in the Check-Balance-Result AVP in 362 the CCA message. 364 3.1.8. Direct Debiting 366 Implementations must conform to Section 6.3 of [RFC4006]. This test 367 uses an event based credit control interaction between the CC Client 368 and CC Server (i.e., CC-Request-Type is set to the value 369 EVENT_REQUEST in the CCR message). The test is invoked by the CC 370 Client including the Service-Identifier and the Requested-Action AVP 371 set to DIRECT_DEBITING in the CCR message. An example message flow 372 is shown in Appendix A (Flow III) of [RFC4006]. 373 o Positive test for a direct debiting enquiry without the CC Client 374 including the requested units. Verify that the CC Server rates 375 the service event and deducts the corresponding monetary amount 376 from the end user's account. Verify that the granted service 377 units can be of type time, volume, service specific, or money. 378 o Positive test for a direct debiting enquiry with the CC Client 379 including the requested units. Verify that the CC Server just 380 deducts the corresponding monetary amount from the end user's 381 account without performing rating. Verify that the granted 382 service units can be of type time, volume, service specific, or 383 money. 384 o Positive test for a direct debiting enquiry where the CC Server 385 determines that no credit-control is required for the service 386 (e.g., free service). 388 3.1.9. Refunds 390 Implementations must conform to Section 6.4 of [RFC4006]. This test 391 uses an event based credit control interaction between the CC Client 392 and CC Server (i.e., CC-Request-Type is set to the value 393 EVENT_REQUEST in the CCR message). The test is invoked by the CC 394 Client including the Requested-Action AVP set to REFUND_ACCOUNT in 395 the CCR message. An example message flow is shown in Appendix A 396 (Flow VI) of [RFC4006]. 397 o Positive test for a refund request without the CC Client including 398 the requested units. Verify that the CC Server performs the 399 rating required prior to refunding the subscriber's account 400 balance. 401 o Positive test for a refund request with the CC Client including 402 the requested units. Verify that the CC Server refunds the 403 subscriber's account balance with the requested monetary amount. 405 3.1.10. Event Based Credit Control Failure Procedures 407 Implementations must conform to Section 6.5 of [RFC4006]. 408 o Test that CC Client forwards requests of type price enquiry or 409 balance check to an alternative CC Server if a transport failure 410 is detected and failover is supported. 411 o Test of direct debiting failure handling. Verify that the CC 412 Client behaves as described in section 6.5 of [RFC4006] when the 413 requested actions is direct debiting and the Direct-Debiting- 414 Failure-Handling AVP is set to TERMINATE_OR_BUFFER. 415 o Test of direct debiting failure handling. Verify that the CC 416 Client behaves as described in section 6.5 of [RFC4006] when the 417 requested actions is direct debiting and the Direct-Debiting- 418 Failure-Handling AVP is set to CONTINUE. 420 3.2. Optional 422 Either test topology Figure 1 or Figure 2 can be used for these 423 cases. 425 3.2.1. Tariff Time Support 427 Implementations must conform to Section 5.1.1 of [RFC4006]. 428 o Positive test for tariff change support. Verify that the CC 429 Server can send a CCA message including a Tariff-Time-Change AVP. 430 Verify that the CC Client itemizes the used units in respect to 431 the tariff time change when reporting service usage. 432 o Negative test for tariff change support. Verify that the CC 433 Client terminates the credit control session if it does not 434 support tariff time changes and it received a CCA message 435 including a Tariff-Time-Change AVP. 437 3.2.2. Graceful Service Termination 439 This section addresses the graceful termination features of a CC 440 Server in accordance with Section 5.6 of [RFC4006] utilizing the 441 Final-Unit-Indication AVP. 442 o Positive test for terminate action. Verify that a CC Client 443 terminates the service when the final units have been consumed and 444 it has received a Final-Unit-Action with a value of TERMINATE. 445 The CC Client must send a CCR final message including a CC- 446 Request-Type AVP set to the value TERMINATION_REQUEST. 447 o Positive test for redirect action. Verify that a CC Server 448 supports the inclusion of a Redirect-Server AVP when the Final- 449 Unit-Action AVP is set with a value of REDIRECT. Verify that the 450 end user is redirected by the CC Client to the appropriate 451 redirect server when the final units have been consumed. The CC 452 Client must send a CCR intermediate message specifying the used 453 units and to report that the specified action has started. 454 o Positive test for restriction filter rules. Verify that a CC 455 Server supports the inclusion of Restriction-Filter-Rule AVPs when 456 the Final-Unit-Action AVP is set with a value of REDIRECT or 457 RESTRICT. Verify that the end user packets not matching the 458 restriction filter are dropped by the CC Client when the final 459 units have been consumed. The CC Client must send a CCR 460 intermediate message specifying the used units and to report that 461 the specified action has started. 462 o Positive test for IP filter list handling. Verify that a CC 463 Server supports the inclusion of Filter-Id AVPs when the Final- 464 Unit-Action AVP is set with a value of REDIRECT or RESTRICT. 465 Verify that the end user packets not matching the filter are 466 dropped by the CC Client when the final units have been consumed. 467 The CC Client must send a CCR intermediate message specifying the 468 used units and to report that the specified action has started. 469 o Negative test for default final unit handling. Verify that a CC 470 Client terminates the service when the final units have been 471 consumed and it has received an unsupported Final-Unit-Action 472 value. The CC Client must send a CCR final message including a 473 CC-Request-Type AVP set to the value TERMINATION_REQUEST. 475 3.2.3. Validity Time 477 o Positive test for Validity-Time AVP support. Verify that the CC 478 Server is capable of including a validity time with granted 479 service units in a CCA message. Verify the CC Client generates a 480 CC update request and reports the used quota to the CC server when 481 the validity timer expires. 482 o Positive test for Validity-Time AVP support with multiple services 483 within a session. Verify that the CC Server is capable of 484 including a validity time in a Multiple-Services-Credit-Control 485 AVP in a CCA message. Verify the CC Client generates a CC update 486 request and reports the used quota to the CC server when the 487 validity timer expires. 489 3.2.4. Server Initiated Credit Reauthorization 491 Implementations must conform to Section 5.5 of [RFC4006]. 492 o Positive test for CC Server initiated reauthorization of all 493 services in a session. Verify that the CC Client follows the RAA 494 and CCR Update procedure defined in Section 5.5 of [RFC4006]. 495 o Positive test for CC Server initiated reauthorization for a credit 496 pool in a session. Verify that the CC Server includes the G-S-U- 497 Pool-Identifier AVP in the RAR message. Verify that the CC Client 498 follows the RAA and CCR Update procedure defined in Section 5.5 of 499 [RFC4006]. 501 o Positive test for CC Server initiated reauthorization for a rating 502 group in a session. Verify that the CC Server includes the 503 Rating-Group AVP in the RAR message. Verify that the CC Client 504 follows the RAA and CCR Update procedure defined in Section 5.5 of 505 [RFC4006]. 506 o Positive test for CC Server initiated reauthorization for a 507 specific service in a session. Verify that the CC Server includes 508 the Service-Identifier AVP in the RAR message. Verify that the CC 509 Client follows the RAA and CCR Update procedure defined in Section 510 5.5 of [RFC4006]. 511 o Positive test RAR-CCR Collision handling support. Verify that the 512 CC Client sends an RAA with a DIAMETER_SUCCESS result but does not 513 initiate a CCR. Verify that the CC Server processes the CCR 514 message as if it was generate in response to the RAR message. 515 o Positive test for CC Server initiated reauthorization for an 516 active sub session. Verify that the CC Server includes the CC- 517 Sub-Session-Id AVP in the RAR message. Verify that the CC Client 518 follows the RAA and CCR Update procedures defined in Section 5.5 519 of [RFC4006]. 521 4. Security Considerations 523 This document defines test cases and therefore tests various aspects 524 of the Diameter base specification and various Diameter applications. 526 5. IANA Considerations 528 This document does not require actions by IANA. 530 6. Normative References 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", BCP 14, RFC 2119, March 1997. 535 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 536 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 538 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 539 Loughney, "Diameter Credit-Control Application", RFC 4006, 540 August 2005. 542 Authors' Addresses 544 Alan McNamee 545 Openet Telecom Inc 546 6 Beckett Way, Park West Business Park 547 Clondalkin, Dublin 12 548 Ireland 550 Phone: +353 1 620 4600 551 Email: alan.mcnamee@openet-telecom.com 553 Hannes Tschofenig 554 Nokia Siemens Networks 555 Otto-Hahn-Ring 6 556 Munich, Bavaria 81739 557 Germany 559 Phone: +49 89 636 40390 560 Email: Hannes.Tschofenig@nsn.com 561 URI: http://www.tschofenig.com 563 Victor Fajardo 564 Toshiba America Research, Inc. 565 1 Telcordia Drive 566 Piscataway, NJ 08854 567 USA 569 Phone: +1 732 699 5368 570 Email: vfajardo@tari.toshiba.com 572 Julien Bournelle 573 France Telecom R&D 574 38-4O rue du general Leclerc 575 Issy-Les-Moulineaux 92794 576 France 578 Email: julien.bournelle@orange-ftgroup.com 580 Full Copyright Statement 582 Copyright (C) The IETF Trust (2007). 584 This document is subject to the rights, licenses and restrictions 585 contained in BCP 78, and except as set forth therein, the authors 586 retain all their rights. 588 This document and the information contained herein are provided on an 589 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 590 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 591 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 592 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 593 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 594 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 596 Intellectual Property 598 The IETF takes no position regarding the validity or scope of any 599 Intellectual Property Rights or other rights that might be claimed to 600 pertain to the implementation or use of the technology described in 601 this document or the extent to which any license under such rights 602 might or might not be available; nor does it represent that it has 603 made any independent effort to identify any such rights. Information 604 on the procedures with respect to rights in RFC documents can be 605 found in BCP 78 and BCP 79. 607 Copies of IPR disclosures made to the IETF Secretariat and any 608 assurances of licenses to be made available, or the result of an 609 attempt made to obtain a general license or permission for the use of 610 such proprietary rights by implementers or users of this 611 specification can be obtained from the IETF on-line IPR repository at 612 http://www.ietf.org/ipr. 614 The IETF invites any interested party to bring to its attention any 615 copyrights, patents or patent applications, or other proprietary 616 rights that may cover technology that may be required to implement 617 this standard. Please address the information to the IETF at 618 ietf-ipr@ietf.org. 620 Acknowledgment 622 Funding for the RFC Editor function is provided by the IETF 623 Administrative Support Activity (IASA).