idnits 2.17.1 draft-fajardo-dime-dcc-test-suite-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 13, 2009) is 5401 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 (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DIME A. McNamee 3 Internet-Draft Openet-Telecom 4 Expires: January 14, 2010 H. Tschofenig 5 Nokia Siemens Networks 6 V. Fajardo 7 Telcordia Technologies 8 J. Bournelle 9 France Telecom R&D 10 July 13, 2009 12 Diameter Credit Control Interoperability Test Suite 13 draft-fajardo-dime-dcc-test-suite-02.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 14, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This document describes a collection of test cases to be used for 52 Diameter Credit Control application interoperability testing. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Diameter Credit Control Test Suite . . . . . . . . . . . . . . 3 59 3.1. Required . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1.1. Session Based Credit Control First Interrogation . . . 5 61 3.1.2. Session Based Credit Control Intermediate 62 Interrogation . . . . . . . . . . . . . . . . . . . . 6 63 3.1.3. Session Based Credit Control Final Interrogation . . . 7 64 3.1.4. Sub Sessions . . . . . . . . . . . . . . . . . . . . . 7 65 3.1.5. Session Based Credit Control Failure Procedures . . . 8 66 3.1.6. Service Price Enquiry . . . . . . . . . . . . . . . . 8 67 3.1.7. Balance Check . . . . . . . . . . . . . . . . . . . . 8 68 3.1.8. Direct Debiting . . . . . . . . . . . . . . . . . . . 9 69 3.1.9. Refunds . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.1.10. Event Based Credit Control Failure Procedures . . . . 10 71 3.2. Optional . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 3.2.1. Tariff Time Support . . . . . . . . . . . . . . . . . 10 73 3.2.2. Graceful Service Termination . . . . . . . . . . . . . 10 74 3.2.3. Validity Time . . . . . . . . . . . . . . . . . . . . 11 75 3.2.4. Server Initiated Credit Reauthorization . . . . . . . 11 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 6. Normative References . . . . . . . . . . . . . . . . . . . . . 12 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 81 1. Introduction 83 The document is a companion document to the Diameter Base Protocol 84 Interoperability Test Suite. This document is meant to aid in the 85 identifying the functional test cases of a Diameter Credit Control 86 implementation. The Diameter Credit Control interoperability test 87 suites are categorized by required and optional functionality. The 88 required functionality is the baseline capability that an 89 implementation must support to allow basic interoperability for that 90 category. Optional functionality covers features that not all 91 implementations support or may wish to test. 93 At its current state, this document provides only a collection of 94 test cases designed for interoperability. Test plans may be included 95 in future revisions of this work or maybe provided in some other 96 document. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 Within this document the terms defined in [RFC2119] refer to the 105 functionality that has to be provided by an implementation for the 106 usage within this interoperability test document. 108 3. Diameter Credit Control Test Suite 110 Vendors that support the Diameter Credit Control application must 111 conform to [RFC4006]. The typical test topology for credit control 112 authorization is shown in Figure 1. A user typically requests a 113 service and thereby triggers the CC Client to contact the CC Server 114 requesting the CC Server to verify the user's credit standing prior 115 to service delivery. Since the test cases cover only CC Client and 116 CC Server interoperability, it is left to the tester to verify 117 correctness of the authentication method executed between the user 118 and the AAA server that is used as a pre-requisite for the 119 authorization of the user by the CC server. Additionally, the 120 interaction between the User's host and the CC Client that is used to 121 trigger the interaction between the CC client and the CC Server is 122 outside the scope of this document. 124 +--------+ +-----------+ +------------+ 125 | User |<--->| CC Client |<--->| AAA Server | 126 +--------+ +-----^-----+ +-----^------+ 127 | | 128 | | 129 | +-----V-----+ 130 +---------->| CC Server | 131 +-----------+ 133 Legend: 134 User - Simulated end user 135 CC Client - Vendor A Diam CCA client 136 CC Server - Vendor B Diam CCA server 138 Figure 1: Diameter CC Test Topology 140 A second test topology can exist for testing Diameter/RADIUS 141 translation agent as specified in Section 11 of [RFC4006]. This 142 topology is available for vendors implementing a prepaid RADIUS 143 translation agent. Since the test cases cover interoperability 144 scenarios, validation must be done between the Service Element and 145 the AAA Server/CC Client translation agent. As with Figure 1, it is 146 left to the tester to verify correctness of the access method between 147 User and Service Element. The test cases involving Figure 1 are also 148 relevant to validating AAA Server/CC Client and CC Server and should 149 be used in this topology as well. 151 +------+ +---------+ +---------------+ 152 | User |<--->| Service |<--->| AAA Server | 153 +------+ | Element | | +---------+ | 154 +---------+ | |CC Client| | 155 | +---------+ | 156 +--+----^----+--+ 157 | 158 | 159 +-----V-----+ 160 | CC Server | 161 +-----------+ 162 Legend: 163 User - Simulated user 164 Service Element - Simulated or vendor RADIUS prepaid 165 client application client 166 AAA Server/CC Client - Vendor A Diameter/RADIUS 167 translation agent 168 CC Server - Vendor B Diameter CC Server 170 Figure 2: Translation Gateway Test Topology 172 3.1. Required 174 Either test topology Figure 1 or Figure 2 can be used for these 175 cases. 177 3.1.1. Session Based Credit Control First Interrogation 179 Implementations must conform to Section 5.2 of [RFC4006]. This 180 section addresses the initial credit control interactions between a 181 CC Client and a CC Server, i.e., CC-Request-Type is set to the value 182 INITIAL_REQUEST in the CCR message. There are many parameters on 183 which a service can be granted a credit authorization but the 184 objective of these tests is to demonstrate for session based services 185 the initial credit authorization handling procedures are supported. 186 o Positive tests for credit authorization for a session based 187 service with the Requested-Service-Unit AVP NOT present. The 188 service quota profiles should be agreed between the vendors. The 189 test should be repeated to verify support for the following quota 190 types: 191 * Time based services. 192 * Volume (Total, Input, Output Octets) based services. 193 * Services with quota using service specific units. 194 * Money based services. 195 * Services with several unit types granted. 196 o Positive tests for credit authorization for a session based 197 service with the Requested-Service-Unit AVP being present. The 198 service quota profiles should be agreed between the vendors. The 199 test should be repeated to verify support for the following quota 200 types: 201 * Time based services. 202 * Volume (Total, Input, Output Octets) based services. 203 * Services with quota using service specific units. 204 * Money based services. 205 * Services with several unit types granted. 206 o Positive test for the CC Server's ability to support the granting 207 alternative amounts of credit to the values requested in the 208 Requested-Service-Unit AVP of the CCR message. 209 o Negative test for first interrogation of session based services 210 when the CC Server could not process the initial CCR message. 211 Verify support for the graceful handling of events such as unknown 212 end user, account being empty, invalid rating input, or errors 213 defined in [RFC3588]. 214 o Negative test for first interrogation of session based services 215 when the CC Client could not process the initial CCA message. 216 Verify support for the graceful handling of events such as 217 unsupported unit types. 219 o Negative test for first interrogation of session based services 220 when the CC Server includes a Final-Unit-Indication AVP with 221 Final-Unit-Action REDIRECT or RESTRICT_ACCESS in the Credit- 222 Control-Answer or in the AA answer. Verify that CC Client behaves 223 as directed. 225 3.1.2. Session Based Credit Control Intermediate Interrogation 227 Implementations must conform to Section 5.3 of [RFC4006]. This 228 section addresses the intermediate credit control interactions 229 between a CC Client and a CC Server, i.e., CC-Request-Type is set to 230 the value UPDATE_REQUEST in the CCR message. There are many 231 parameters on which a service can be reauthorized credit but the 232 objective of these tests is to demonstrate for session based services 233 the intermediate credit authorization handling procedures are 234 supported. 235 o Positive tests for credit reauthorization for a session based 236 service with the Requested-Service-Unit AVP NOT present. The 237 Event-Timestamp AVP must be used to mark the time the 238 reauthorization was triggered and the Used-Service-Unit AVP 239 contains the amount of used service units since the service was 240 activated or last interim. The service quota profiles should be 241 agreed between the vendors. The test should be repeated to verify 242 support for the following quota types: 243 * Time based services. 244 * Volume (Total, Input, Output Octets) based services. 245 * Services with quota using service specific units. 246 * Money based services. 247 * Services with several unit types granted. 248 o Positive tests for credit authorization for a session based 249 service with the Requested-Service-Unit AVP is present. The 250 Event-Timestamp AVP must be used to mark the time the 251 reauthorization was triggered and the Used-Service-Unit AVP 252 contains the amount of used service units since the service was 253 activated or last interim. The service quota profiles should be 254 agreed between the vendors. The test should be repeated to verify 255 support for the following quota types: 256 * Time based services. 257 * Volume (Total, Input, Output Octets) based services. 258 * Services with quota using service specific units. 259 * Money based services. 260 * Services with several unit types granted. 261 o Positive test for the CC Server's ability to support the granting 262 alternative amounts of credit to the values requested in the 263 Requested-Service-Unit AVP of the CCR message. 264 o Negative test for intermediate interrogation for session based 265 services when the CC Server could not process the update CCR 266 message. Verify support for the graceful handling of events such 267 as subscription ID missing, account being empty, invalid rating 268 input, or errors defined in [RFC3588]. 269 o Negative test for intermediate interrogation for session based 270 services when the CC Client could not process the update CCA 271 message. Verify support for the graceful handling of events such 272 as unsupported unit types. 274 3.1.3. Session Based Credit Control Final Interrogation 276 Implementations must conform to Section 5.4 of [RFC4006]. This 277 section addresses the final credit control interactions between a 278 credit control application client and server i.e., CC-Request-Type is 279 set to the value TERMINATION_REQUEST in the CCR message. 280 o Positive test for final interrogation for a session based service. 281 The Event-Timestamp AVP should be used to mark the time the 282 interrogation was triggered and the Used-Service-Unit AVP contains 283 the amount of used service units since the service was activated 284 or last interim. The CC Server must verify support for refunding 285 the unused reserved units and for charging the used monetary 286 amount to the end user's account. 288 3.1.4. Sub Sessions 290 Implementations must conform to Section 5.1.2 of [RFC4006]. 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 not present. 295 o Positive test for multiple services within a session. Verify 296 vendor support for interrogations when the Multiple-Services- 297 Credit-Control AVP present and the Requested-Service-Unit AVP is 298 present. 299 o Positive test for credit pool support. Verify that a vendor's CC 300 Server implementation is capable of supporting credit pools for 301 services by including a G-S-U-Reference within a Granted-Service- 302 Unit AVP in a CCA message. An example scenario is detailed in 303 Appendix A (Flow IX) of [RFC4006]. 304 o Positive test for rating group support. Verify that a vendor's CC 305 Client implementation is capable of associating a service with a 306 rating group by including a Rating-Group AVP in an interrogation. 307 An example scenario is detailed in Appendix A (Flow IX) of 308 [RFC4006]. 309 o Negative test for multiple services within a session. Verify that 310 a CC Server not supporting multiple services within a session 311 treats the Multiple-Services-Indicator AVP and any received 312 Multiple-Services-Credit-Control AVPs as invalid AVPs. 314 o Negative test for invalid/insufficient rating input. Verify that 315 a CC Server receiving invalid rating input (e.g., unknown rating 316 group) shall inform the CC Client by including a result code of 317 DIAMETER_RATING_FAILED in the Multiple-Services-Credit-Control 318 AVP. 320 3.1.5. Session Based Credit Control Failure Procedures 322 Implementations must conform to Section 5.7 of [RFC4006]. 323 o Test failure behavior when Credit-Control-Failure-Handling AVP is 324 set to TERMINATE. Verify that the CC Client terminates the end 325 user's session if it does not receive a CCA message within the Tx 326 timer. 327 o Test failure behavior when Credit-Control-Failure-Handling AVP is 328 set to CONTINUE. Verify that when CC messages cannot be delivered 329 to CC Server because of transport or temporary failures that the 330 CC Client resends the request to a backup CC Server assuming CC 331 failover is supported or else the service should be granted by the 332 CC Client. 333 o Test failure behavior when Credit-Control-Failure-Handling AVP is 334 set to RETRY_AND_TERMINATE. Verify that when CC messages cannot 335 be delivered to the CC Server because of transport or temporary 336 failures that the CC Client resends the request to a backup CC 337 Server assuming CC failover is supported or else the service 338 should not be granted by the CC Client. 340 3.1.6. Service Price Enquiry 342 Implementations must conform to Section 6.1 of [RFC4006]. This test 343 uses an event based credit control interaction between the CC Client 344 and the CC Server (i.e., CC-Request-Type is set to the value 345 EVENT_REQUEST in the CCR message). The test is invoked by the CC 346 Client including the Service-Identifier and the Requested-Action AVP 347 set to PRICE_ENQUIRY in the CCR message. An example message flow is 348 shown in Appendix A (Flow V) of [RFC4006]. 349 o Positive test for a service price enquiry. Verify that the CC 350 Server returns the estimated cost of the service to the CC Client 351 in the in the Cost-Information AVP in the CCA message. 353 3.1.7. Balance Check 355 Implementations must conform to Section 6.2 of [RFC4006]. This test 356 uses an event based credit control interaction between the CC Client 357 and CC Server (i.e., CC-Request-Type is set to the value 358 EVENT_REQUEST in the CCR message). The test is invoked by the CC 359 Client including the Service-Identifier and the Requested-Action AVP 360 set to CHECK_BALANCE in the CCR message. An example scenario is 361 detailed in Appendix A (Flow IV) of [RFC4006]. 363 o Positive test for a check balance enquiry. Verify that the CC 364 Server returns the credit status for the subscriber to access the 365 service to the CC Client in the in the Check-Balance-Result AVP in 366 the CCA message. 368 3.1.8. Direct Debiting 370 Implementations must conform to Section 6.3 of [RFC4006]. This test 371 uses an event based credit control interaction between the CC Client 372 and CC Server (i.e., CC-Request-Type is set to the value 373 EVENT_REQUEST in the CCR message). The test is invoked by the CC 374 Client including the Service-Identifier and the Requested-Action AVP 375 set to DIRECT_DEBITING in the CCR message. An example message flow 376 is shown in Appendix A (Flow III) of [RFC4006]. 377 o Positive test for a direct debiting enquiry without the CC Client 378 including the requested units. Verify that the CC Server rates 379 the service event and deducts the corresponding monetary amount 380 from the end user's account. Verify that the granted service 381 units can be of type time, volume, service specific, or money. 382 o Positive test for a direct debiting enquiry with the CC Client 383 including the requested units. Verify that the CC Server just 384 deducts the corresponding monetary amount from the end user's 385 account without performing rating. Verify that the granted 386 service units can be of type time, volume, service specific, or 387 money. 388 o Positive test for a direct debiting enquiry where the CC Server 389 determines that no credit-control is required for the service 390 (e.g., free service). 392 3.1.9. Refunds 394 Implementations must conform to Section 6.4 of [RFC4006]. This test 395 uses an event based credit control interaction between the CC Client 396 and CC Server (i.e., CC-Request-Type is set to the value 397 EVENT_REQUEST in the CCR message). The test is invoked by the CC 398 Client including the Requested-Action AVP set to REFUND_ACCOUNT in 399 the CCR message. An example message flow is shown in Appendix A 400 (Flow VI) of [RFC4006]. 401 o Positive test for a refund request without the CC Client including 402 the requested units. Verify that the CC Server performs the 403 rating required prior to refunding the subscriber's account 404 balance. 405 o Positive test for a refund request with the CC Client including 406 the requested units. Verify that the CC Server refunds the 407 subscriber's account balance with the requested monetary amount. 409 3.1.10. Event Based Credit Control Failure Procedures 411 Implementations must conform to Section 6.5 of [RFC4006]. 412 o Test that CC Client forwards requests of type price enquiry or 413 balance check to an alternative CC Server if a transport failure 414 is detected and failover is supported. 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 TERMINATE_OR_BUFFER. 419 o Test of direct debiting failure handling. Verify that the CC 420 Client behaves as described in section 6.5 of [RFC4006] when the 421 requested actions is direct debiting and the Direct-Debiting- 422 Failure-Handling AVP is set to CONTINUE. 424 3.2. Optional 426 Either test topology Figure 1 or Figure 2 can be used for these 427 cases. 429 3.2.1. Tariff Time Support 431 Implementations must conform to Section 5.1.1 of [RFC4006]. 432 o Positive test for tariff change support. Verify that the CC 433 Server can send a CCA message including a Tariff-Time-Change AVP. 434 Verify that the CC Client itemizes the used units in respect to 435 the tariff time change when reporting service usage. 436 o Negative test for tariff change support. Verify that the CC 437 Client terminates the credit control session if it does not 438 support tariff time changes and it received a CCA message 439 including a Tariff-Time-Change AVP. 441 3.2.2. Graceful Service Termination 443 This section addresses the graceful termination features of a CC 444 Server in accordance with Section 5.6 of [RFC4006] utilizing the 445 Final-Unit-Indication AVP. 446 o Positive test for terminate action. Verify that a CC Client 447 terminates the service when the final units have been consumed and 448 it has received a Final-Unit-Action with a value of TERMINATE. 449 The CC Client must send a CCR final message including a CC- 450 Request-Type AVP set to the value TERMINATION_REQUEST. 451 o Positive test for redirect action. Verify that a CC Server 452 supports the inclusion of a Redirect-Server AVP when the Final- 453 Unit-Action AVP is set with a value of REDIRECT. Verify that the 454 end user is redirected by the CC Client to the appropriate 455 redirect server when the final units have been consumed. The CC 456 Client must send a CCR intermediate message specifying the used 457 units and to report that the specified action has started. 458 o Positive test for restriction filter rules. Verify that a CC 459 Server supports the inclusion of Restriction-Filter-Rule AVPs when 460 the Final-Unit-Action AVP is set with a value of REDIRECT or 461 RESTRICT. Verify that the end user packets not matching the 462 restriction filter are dropped by the CC Client when the final 463 units have been consumed. The CC Client must send a CCR 464 intermediate message specifying the used units and to report that 465 the specified action has started. 466 o Positive test for IP filter list handling. Verify that a CC 467 Server supports the inclusion of Filter-Id AVPs when the Final- 468 Unit-Action AVP is set with a value of REDIRECT or RESTRICT. 469 Verify that the end user packets not matching the filter are 470 dropped by the CC Client when the final units have been consumed. 471 The CC Client must send a CCR intermediate message specifying the 472 used units and to report that the specified action has started. 473 o Negative test for default final unit handling. Verify that a CC 474 Client terminates the service when the final units have been 475 consumed and it has received an unsupported Final-Unit-Action 476 value. The CC Client must send a CCR final message including a 477 CC-Request-Type AVP set to the value TERMINATION_REQUEST. 479 3.2.3. Validity Time 481 o Positive test for Validity-Time AVP support. Verify that the CC 482 Server is capable of including a validity time with granted 483 service units in a CCA message. Verify the CC Client generates a 484 CC update request and reports the used quota to the CC server when 485 the validity timer expires. 486 o Positive test for Validity-Time AVP support with multiple services 487 within a session. Verify that the CC Server is capable of 488 including a validity time in a Multiple-Services-Credit-Control 489 AVP in a CCA message. Verify the CC Client generates a CC update 490 request and reports the used quota to the CC server when the 491 validity timer expires. 493 3.2.4. Server Initiated Credit Reauthorization 495 Implementations must conform to Section 5.5 of [RFC4006]. 496 o Positive test for CC Server initiated reauthorization of all 497 services in a session. Verify that the CC Client follows the RAA 498 and CCR Update procedure defined in Section 5.5 of [RFC4006]. 499 o Positive test for CC Server initiated reauthorization for a credit 500 pool in a session. Verify that the CC Server includes the G-S-U- 501 Pool-Identifier AVP in the RAR message. Verify that the CC Client 502 follows the RAA and CCR Update procedure defined in Section 5.5 of 503 [RFC4006]. 505 o Positive test for CC Server initiated reauthorization for a rating 506 group in a session. Verify that the CC Server includes the 507 Rating-Group AVP in the RAR message. Verify that the CC Client 508 follows the RAA and CCR Update procedure defined in Section 5.5 of 509 [RFC4006]. 510 o Positive test for CC Server initiated reauthorization for a 511 specific service in a session. Verify that the CC Server includes 512 the Service-Identifier AVP in the RAR message. Verify that the CC 513 Client follows the RAA and CCR Update procedure defined in Section 514 5.5 of [RFC4006]. 515 o Positive test RAR-CCR Collision handling support. Verify that the 516 CC Client sends an RAA with a DIAMETER_SUCCESS result but does not 517 initiate a CCR. Verify that the CC Server processes the CCR 518 message as if it was generate in response to the RAR message. 519 o Positive test for CC Server initiated reauthorization for an 520 active sub session. Verify that the CC Server includes the CC- 521 Sub-Session-Id AVP in the RAR message. Verify that the CC Client 522 follows the RAA and CCR Update procedures defined in Section 5.5 523 of [RFC4006]. 525 4. Security Considerations 527 This document defines test cases and therefore tests various aspects 528 of the Diameter base specification and various Diameter applications. 530 5. IANA Considerations 532 This document does not require actions by IANA. 534 6. Normative References 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, March 1997. 539 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 540 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 542 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 543 Loughney, "Diameter Credit-Control Application", RFC 4006, 544 August 2005. 546 Authors' Addresses 548 Alan McNamee 549 Openet Telecom Inc 550 6 Beckett Way, Park West Business Park 551 Clondalkin, Dublin 12 552 Ireland 554 Phone: +353 1 620 4600 555 Email: alan.mcnamee@openet-telecom.com 557 Hannes Tschofenig 558 Nokia Siemens Networks 559 Linnoitustie 6 560 Espoo 02600 561 Finland 563 Phone: +358 (50) 4871445 564 Email: Hannes.Tschofenig@gmx.net 565 URI: http://www.tschofenig.priv.at 567 Victor Fajardo 568 Telcordia Technologies 569 1 Telcordia Drive #1S-222 570 Piscataway, NJ 08854 571 USA 573 Email: vfajardo@research.telcordia.com 575 Julien Bournelle 576 France Telecom R&D 577 38-4O rue du general Leclerc 578 Issy-Les-Moulineaux 92794 579 France 581 Email: julien.bournelle@orange-ftgroup.com