idnits 2.17.00 (12 Aug 2021) /tmp/idnits43234/draft-fajardo-dime-dcc-test-suite-00.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 646. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 664. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 670. 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 (April 28, 2007) is 5501 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: October 30, 2007 H. Tschofenig 5 NokiaSiemens 6 V. Fajardo 7 TARI 8 J. Bournelle 9 GET/INT 10 April 28, 2007 12 Diameter Credit Control Interoperability Test Suite 13 draft-fajardo-dime-dcc-test-suite-00 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 October 30, 2007. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Diameter Credit Control Test Suite . . . . . . . . . . . . . . 5 54 3.1. Required . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 3.1.1. Session Based Credit Control First Interrogation . . . 6 56 3.1.2. Session Based Credit Control Intermediate 57 Interrogation . . . . . . . . . . . . . . . . . . . . 7 58 3.1.3. Session Based Credit Control Final Interrogation . . . 9 59 3.1.4. Sub Sessions . . . . . . . . . . . . . . . . . . . . . 9 60 3.1.5. Session Based Credit Control Failure Procedures . . . 10 61 3.1.6. Service Price Enquiry . . . . . . . . . . . . . . . . 10 62 3.1.7. Balance Check . . . . . . . . . . . . . . . . . . . . 11 63 3.1.8. Direct Debiting . . . . . . . . . . . . . . . . . . . 11 64 3.1.9. Refunds . . . . . . . . . . . . . . . . . . . . . . . 12 65 3.1.10. Event Based Credit Control Failure Procedures . . . . 12 66 3.2. Optional . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 3.2.1. Tariff Time Support . . . . . . . . . . . . . . . . . 12 68 3.2.2. Graceful Service Termination . . . . . . . . . . . . . 13 69 3.2.3. Validity Time . . . . . . . . . . . . . . . . . . . . 13 70 3.2.4. Server Initiated Credit Reauthorization . . . . . . . 14 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 6. Normative References . . . . . . . . . . . . . . . . . . . . . 17 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 75 Intellectual Property and Copyright Statements . . . . . . . . . . 19 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] refers to the 101 functionality that have to be provided by an implementation for the 102 usage within this interoperability test event. 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. 183 o Positive tests for credit authorization for a session based 184 service with the Requested-Service-Unit AVP NOT present. The 185 service quota profiles should be agreed between the vendors. The 186 test should be repeated to verify support for the following quota 187 types: 189 * Time based services. 191 * Volume (Total, Input, Output Octets) based services. 193 * Services with quota using service specific units. 195 * Money based services. 197 * Services with several unit types granted. 199 o Positive tests for credit authorization for a session based 200 service with the Requested-Service-Unit AVP being present. The 201 service quota profiles should be agreed between the vendors. The 202 test should be repeated to verify support for the following quota 203 types: 205 * Time based services. 207 * Volume (Total, Input, Output Octets) based services. 209 * Services with quota using service specific units. 211 * Money based services. 213 * Services with several unit types granted. 215 o Positive test for the CC Server's ability to support the granting 216 alternative amounts of credit to the values requested in the 217 Requested-Service-Unit AVP of the CCR message. 219 o Negative test for first interrogation of session based services 220 when the CC Server could not process the initial CCR message. 221 Verify support for the graceful handling of events such as unknown 222 end user, account being empty, invalid rating input, or errors 223 defined in [RFC3588]. 225 o Negative test for first interrogation of session based services 226 when the CC Client could not process the initial CCA message. 227 Verify support for the graceful handling of events such as 228 unsupported unit types. 230 o Negative test for first interrogation of session based services 231 when the CC Server includes a Final-Unit-Indication AVP with 232 Final-Unit-Action REDIRECT or RESTRICT_ACCESS in the Credit- 233 Control-Answer or in the AA answer. Verify that CC Client behaves 234 as directed. 236 3.1.2. Session Based Credit Control Intermediate Interrogation 238 Implementations must conform to Section 5.3 of [RFC4006]. This 239 section addresses the intermediate credit control interactions 240 between a CC Client and a CC Server, i.e., CC-Request-Type is set to 241 the value UPDATE_REQUEST in the CCR message. There are many 242 parameters on which a service can be reauthorized credit but the 243 objective of these tests is to demonstrate for session based services 244 the intermediate credit authorization handling procedures are 245 supported. 247 o Positive tests for credit reauthorization for a session based 248 service with the Requested-Service-Unit AVP NOT present. The 249 Event-Timestamp AVP must be used to mark the time the 250 reauthorization was triggered and the Used-Service-Unit AVP 251 contains the amount of used service units since the service was 252 activated or last interim. The service quota profiles should be 253 agreed between the vendors. The test should be repeated to verify 254 support for the following quota types: 256 * Time based services. 258 * Volume (Total, Input, Output Octets) based services. 260 * Services with quota using service specific units. 262 * Money based services. 264 * Services with several unit types granted. 266 o Positive tests for credit authorization for a session based 267 service with the Requested-Service-Unit AVP is present. The 268 Event-Timestamp AVP must be used to mark the time the 269 reauthorization was triggered and the Used-Service-Unit AVP 270 contains the amount of used service units since the service was 271 activated or last interim. The service quota profiles should be 272 agreed between the vendors. The test should be repeated to verify 273 support for the following quota types: 275 * Time based services. 277 * Volume (Total, Input, Output Octets) based services. 279 * Services with quota using service specific units. 281 * Money based services. 283 * Services with several unit types granted. 285 o Positive test for the CC Server's ability to support the granting 286 alternative amounts of credit to the values requested in the 287 Requested-Service-Unit AVP of the CCR message. 289 o Negative test for intermediate interrogation for session based 290 services when the CC Server could not process the update CCR 291 message. Verify support for the graceful handling of events such 292 as subscription ID missing, account being empty, invalid rating 293 input, or errors defined in [RFC3588]. 295 o Negative test for intermediate interrogation for session based 296 services when the CC Client could not process the update CCA 297 message. Verify support for the graceful handling of events such 298 as unsupported unit types. 300 3.1.3. Session Based Credit Control Final Interrogation 302 Implementations must conform to Section 5.4 of [RFC4006]. This 303 section addresses the final credit control interactions between a 304 credit control application client and server i.e., CC-Request-Type is 305 set to the value TERMINATION_REQUEST in the CCR message. 307 o Positive test for final interrogation for a session based service. 308 The Event-Timestamp AVP should be used to mark the time the 309 interrogation was triggered and the Used-Service-Unit AVP contains 310 the amount of used service units since the service was activated 311 or last interim. The CC Server must verify support for refunding 312 the unused reserved units and for charging the used monetary 313 amount to the end user's account. 315 3.1.4. Sub Sessions 317 Implementations must conform to Section 5.1.2 of [RFC4006]. 319 o Positive test for multiple services within a session. Verify 320 vendor support for interrogations when the Multiple-Services- 321 Credit-Control AVP present and the Requested-Service-Unit AVP is 322 not present. 324 o Positive test for multiple services within a session. Verify 325 vendor support for interrogations when the Multiple-Services- 326 Credit-Control AVP present and the Requested-Service-Unit AVP is 327 present. 329 o Positive test for credit pool support. Verify that a vendor's CC 330 Server implementation is capable of supporting credit pools for 331 services by including a G-S-U-Reference within a Granted-Service- 332 Unit AVP in a CCA message. An example scenario is detailed in 333 Appendix A (Flow IX) of [RFC4006]. 335 o Positive test for rating group support. Verify that a vendor's CC 336 Client implementation is capable of associating a service with a 337 rating group by including a Rating-Group AVP in an interrogation. 338 An example scenario is detailed in Appendix A (Flow IX) of 340 [RFC4006]. 342 o Negative test for multiple services within a session. Verify that 343 a CC Server not supporting multiple services within a session 344 treats the Multiple-Services-Indicator AVP and any received 345 Multiple-Services-Credit-Control AVPs as invalid AVPs. 347 o Negative test for invalid/insufficient rating input. Verify that 348 a CC Server receiving invalid rating input (e.g., unknown rating 349 group) shall inform the CC Client by including a result code of 350 DIAMETER_RATING_FAILED in the Multiple-Services-Credit-Control 351 AVP. 353 3.1.5. Session Based Credit Control Failure Procedures 355 Implementations must conform to Section 5.7 of [RFC4006]. 357 o Test failure behavior when Credit-Control-Failure-Handling AVP is 358 set to TERMINATE. Verify that the CC Client terminates the end 359 user's session if it does not receive a CCA message within the Tx 360 timer. 362 o Test failure behavior when Credit-Control-Failure-Handling AVP is 363 set to CONTINUE. Verify that when CC messages cannot be delivered 364 to CC Server because of transport or temporary failures that the 365 CC Client resends the request to a backup CC Server assuming CC 366 failover is supported or else the service should be granted by the 367 CC Client. 369 o Test failure behavior when Credit-Control-Failure-Handling AVP is 370 set to RETRY_AND_TERMINATE. Verify that when CC messages cannot 371 be delivered to the CC Server because of transport or temporary 372 failures that the CC Client resends the request to a backup CC 373 Server assuming CC failover is supported or else the service 374 should not be granted by the CC Client. 376 3.1.6. Service Price Enquiry 378 Implementations must conform to Section 6.1 of [RFC4006]. This test 379 uses an event based credit control interaction between the CC Client 380 and the CC Server (i.e., CC-Request-Type is set to the value 381 EVENT_REQUEST in the CCR message). The test is invoked by the CC 382 Client including the Service-Identifier and the Requested-Action AVP 383 set to PRICE_ENQUIRY in the CCR message. An example message flow is 384 shown in Appendix A (Flow V) of [RFC4006]. 386 o Positive test for a service price enquiry. Verify that the CC 387 Server returns the estimated cost of the service to the CC Client 388 in the in the Cost-Information AVP in the CCA message. 390 3.1.7. Balance Check 392 Implementations must conform to Section 6.2 of [RFC4006]. This test 393 uses an event based credit control interaction between the CC Client 394 and CC Server (i.e., CC-Request-Type is set to the value 395 EVENT_REQUEST in the CCR message). The test is invoked by the CC 396 Client including the Service-Identifier and the Requested-Action AVP 397 set to CHECK_BALANCE in the CCR message. An example scenario is 398 detailed in Appendix A (Flow IV) of [RFC4006]. 400 o Positive test for a check balance enquiry. Verify that the CC 401 Server returns the credit status for the subscriber to access the 402 service to the CC Client in the in the Check-Balance-Result AVP in 403 the CCA message. 405 3.1.8. Direct Debiting 407 Implementations must conform to Section 6.3 of [RFC4006]. This test 408 uses an event based credit control interaction between the CC Client 409 and CC Server (i.e., CC-Request-Type is set to the value 410 EVENT_REQUEST in the CCR message). The test is invoked by the CC 411 Client including the Service-Identifier and the Requested-Action AVP 412 set to DIRECT_DEBITING in the CCR message. An example message flow 413 is shown in Appendix A (Flow III) of [RFC4006]. 415 o Positive test for a direct debiting enquiry without the CC Client 416 including the requested units. Verify that the CC Server rates 417 the service event and deducts the corresponding monetary amount 418 from the end user's account. Verify that the granted service 419 units can be of type time, volume, service specific, or money. 421 o Positive test for a direct debiting enquiry with the CC Client 422 including the requested units. Verify that the CC Server just 423 deducts the corresponding monetary amount from the end user's 424 account without performing rating. Verify that the granted 425 service units can be of type time, volume, service specific, or 426 money. 428 o Positive test for a direct debiting enquiry where the CC Server 429 determines that no credit-control is required for the service 430 (e.g., free service). 432 3.1.9. Refunds 434 Implementations must conform to Section 6.4 of [RFC4006]. This test 435 uses an event based credit control interaction between the CC Client 436 and CC Server (i.e., CC-Request-Type is set to the value 437 EVENT_REQUEST in the CCR message). The test is invoked by the CC 438 Client including the Requested-Action AVP set to REFUND_ACCOUNT in 439 the CCR message. An example message flow is shown in Appendix A 440 (Flow VI) of [RFC4006]. 442 o Positive test for a refund request without the CC Client including 443 the requested units. Verify that the CC Server performs the 444 rating required prior to refunding the subscriber's account 445 balance. 447 o Positive test for a refund request with the CC Client including 448 the requested units. Verify that the CC Server refunds the 449 subscriber's account balance with the requested monetary amount. 451 3.1.10. Event Based Credit Control Failure Procedures 453 Implementations must conform to Section 6.5 of [RFC4006]. 455 o Test that CC Client forwards requests of type price enquiry or 456 balance check to an alternative CC Server if a transport failure 457 is detected and failover is supported. 459 o Test of direct debiting failure handling. Verify that the CC 460 Client behaves as described in section 6.5 of [RFC4006] when the 461 requested actions is direct debiting and the Direct-Debiting- 462 Failure-Handling AVP is set to TERMINATE_OR_BUFFER. 464 o Test of direct debiting failure handling. Verify that the CC 465 Client behaves as described in section 6.5 of [RFC4006] when the 466 requested actions is direct debiting and the Direct-Debiting- 467 Failure-Handling AVP is set to CONTINUE. 469 3.2. Optional 471 Either test topology Figure 1 or Figure 2 can be used for these 472 cases. 474 3.2.1. Tariff Time Support 476 Implementations must conform to Section 5.1.1 of [RFC4006]. 478 o Positive test for tariff change support. Verify that the CC 479 Server can send a CCA message including a Tariff-Time-Change AVP. 481 Verify that the CC Client itemizes the used units in respect to 482 the tariff time change when reporting service usage. 484 o Negative test for tariff change support. Verify that the CC 485 Client terminates the credit control session if it does not 486 support tariff time changes and it received a CCA message 487 including a Tariff-Time-Change AVP. 489 3.2.2. Graceful Service Termination 491 This section addresses the graceful termination features of a CC 492 Server in accordance with Section 5.6 of [RFC4006] utilizing the 493 Final-Unit-Indication AVP. 495 o Positive test for terminate action. Verify that a CC Client 496 terminates the service when the final units have been consumed and 497 it has received a Final-Unit-Action with a value of TERMINATE. 498 The CC Client must send a CCR final message including a CC- 499 Request-Type AVP set to the value TERMINATION_REQUEST. 501 o Positive test for redirect action. Verify that a CC Server 502 supports the inclusion of a Redirect-Server AVP when the Final- 503 Unit-Action AVP is set with a value of REDIRECT. Verify that the 504 end user is redirected by the CC Client to the appropriate 505 redirect server when the final units have been consumed. The CC 506 Client must send a CCR intermediate message specifying the used 507 units and to report that the specified action has started. 509 o Positive test for restriction filter rules. Verify that a CC 510 Server supports the inclusion of Restriction-Filter-Rule AVPs when 511 the Final-Unit-Action AVP is set with a value of REDIRECT or 512 RESTRICT. Verify that the end user packets not matching the 513 restriction filter are dropped by the CC Client when the final 514 units have been consumed. The CC Client must send a CCR 515 intermediate message specifying the used units and to report that 516 the specified action has started. 518 o Negative test for default final unit handling. Verify that a CC 519 Client terminates the service when the final units have been 520 consumed and it has received an unsupported Final-Unit-Action 521 value. The CC Client must send a CCR final message including a 522 CC-Request-Type AVP set to the value TERMINATION_REQUEST. 524 3.2.3. Validity Time 526 o Positive test for Validity-Time AVP support. Verify that the CC 527 Server is capable of including a validity time with granted 528 service units in a CCA message. Verify the CC Client generates a 529 CC update request and reports the used quota to the CC server when 530 the validity timer expires. 532 o Positive test for Validity-Time AVP support with multiple services 533 within a session. Verify that the CC Server is capable of 534 including a validity time in a Multiple-Services-Credit-Control 535 AVP in a CCA message. Verify the CC Client generates a CC update 536 request and reports the used quota to the CC server when the 537 validity timer expires. 539 3.2.4. Server Initiated Credit Reauthorization 541 Implementations must conform to Section 5.5 of [RFC4006]. 543 o Positive test for CC Server initiated reauthorization of all 544 services in a session. Verify that the CC Client follows the RAA 545 and CCR Update procedure defined in Section 5.5 of [RFC4006]. 547 o Positive test for CC Server initiated reauthorization for a credit 548 pool in a session. Verify that the CC Server includes the G-S-U- 549 Pool-Identifier AVP in the RAR message. Verify that the CC Client 550 follows the RAA and CCR Update procedure defined in Section 5.5 of 551 [RFC4006]. 553 o Positive test for CC Server initiated reauthorization for a rating 554 group in a session. Verify that the CC Server includes the 555 Rating-Group AVP in the RAR message. Verify that the CC Client 556 follows the RAA and CCR Update procedure defined in Section 5.5 of 557 [RFC4006]. 559 o Positive test for CC Server initiated reauthorization for a 560 specific service in a session. Verify that the CC Server includes 561 the Service-Identifier AVP in the RAR message. Verify that the CC 562 Client follows the RAA and CCR Update procedure defined in Section 563 5.5 of [RFC4006]. 565 o Positive test RAR-CCR Collision handling support. Verify that the 566 CC Client sends an RAA with a DIAMETER_SUCCESS result but does not 567 initiate a CCR. Verify that the CC Server processes the CCR 568 message as if it was generate in response to the RAR message. 570 o Positive test for CC Server initiated reauthorization for an 571 active sub session. Verify that the CC Server includes the CC- 572 Sub-Session-Id AVP in the RAR message. Verify that the CC Client 573 follows the RAA and CCR Update procedures defined in Section 5.5 574 of [RFC4006]. 576 4. Security Considerations 578 This document defines test cases and therefore tests various aspects 579 of the Diameter base specification and various Diameter applications. 581 5. IANA Considerations 583 This document does not require actions by IANA. 585 6. Normative References 587 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 588 Requirement Levels", BCP 14, RFC 2119, March 1997. 590 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 591 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 593 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. 594 Loughney, "Diameter Credit-Control Application", RFC 4006, 595 August 2005. 597 Authors' Addresses 599 Alan McNamee 600 Openet Telecom Inc 601 6 Beckett Way, Park West Business Park 602 Clondalkin, Dublin 12 603 Ireland 605 Phone: +353 1 620 4600 606 Email: alan.mcnamee@openet-telecom.com 608 Hannes Tschofenig 609 Nokia Siemens Networks 611 Phone: 612 Email: Hannes.Tschofenig@nsn.com 614 Victor Fajardo 615 Toshiba America Research, Inc. 616 1 Telcordia Drive 617 Piscataway, NJ 08854 618 USA 620 Phone: +1 732 699 5368 621 Email: vfajardo@tari.toshiba.com 623 Julien Bournelle 624 Institut National des Telecommunications 625 9 rue Charles Fourier 626 Evry cedex, 91011 627 France 629 Phone: +33 1 60 76 44 79 630 Email: julien.bournelle@int-evry.fr 632 Full Copyright Statement 634 Copyright (C) The IETF Trust (2007). 636 This document is subject to the rights, licenses and restrictions 637 contained in BCP 78, and except as set forth therein, the authors 638 retain all their rights. 640 This document and the information contained herein are provided on an 641 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 642 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 643 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 644 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 645 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 646 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 648 Intellectual Property 650 The IETF takes no position regarding the validity or scope of any 651 Intellectual Property Rights or other rights that might be claimed to 652 pertain to the implementation or use of the technology described in 653 this document or the extent to which any license under such rights 654 might or might not be available; nor does it represent that it has 655 made any independent effort to identify any such rights. Information 656 on the procedures with respect to rights in RFC documents can be 657 found in BCP 78 and BCP 79. 659 Copies of IPR disclosures made to the IETF Secretariat and any 660 assurances of licenses to be made available, or the result of an 661 attempt made to obtain a general license or permission for the use of 662 such proprietary rights by implementers or users of this 663 specification can be obtained from the IETF on-line IPR repository at 664 http://www.ietf.org/ipr. 666 The IETF invites any interested party to bring to its attention any 667 copyrights, patents or patent applications, or other proprietary 668 rights that may cover technology that may be required to implement 669 this standard. Please address the information to the IETF at 670 ietf-ipr@ietf.org. 672 Acknowledgment 674 Funding for the RFC Editor function is provided by the IETF 675 Administrative Support Activity (IASA).