DIME Working Group A. McNamee Internet-Draft Openet-Telecom Expires:October 30, 2007January 2, 2008 H. TschofenigNokiaSiemensNokia Siemens Networks V. Fajardo TARI J. BournelleGET/INT April 28,France Telecom R&D July 1, 2007 Diameter Credit Control Interoperability Test Suitedraft-fajardo-dime-dcc-test-suite-00draft-fajardo-dime-dcc-test-suite-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onOctober 30, 2007.January 2, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes a collection of test cases to be used for Diameter Credit Control application interoperability testing. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .43 3. Diameter Credit Control Test Suite . . . . . . . . . . . . . .53 3.1. Required . . . . . . . . . . . . . . . . . . . . . . . . .65 3.1.1. Session Based Credit Control First Interrogation . . .65 3.1.2. Session Based Credit Control Intermediate Interrogation . . . . . . . . . . . . . . . . . . . .76 3.1.3. Session Based Credit Control Final Interrogation . . .97 3.1.4. Sub Sessions . . . . . . . . . . . . . . . . . . . . .97 3.1.5. Session Based Credit Control Failure Procedures . . .108 3.1.6. Service Price Enquiry . . . . . . . . . . . . . . . .108 3.1.7. Balance Check . . . . . . . . . . . . . . . . . . . .118 3.1.8. Direct Debiting . . . . . . . . . . . . . . . . . . .119 3.1.9. Refunds . . . . . . . . . . . . . . . . . . . . . . .129 3.1.10. Event Based Credit Control Failure Procedures . . . .1210 3.2. Optional . . . . . . . . . . . . . . . . . . . . . . . . .1210 3.2.1. Tariff Time Support . . . . . . . . . . . . . . . . .1210 3.2.2. Graceful Service Termination . . . . . . . . . . . . .1310 3.2.3. Validity Time . . . . . . . . . . . . . . . . . . . .1311 3.2.4. Server Initiated Credit Reauthorization . . . . . . .1411 4. Security Considerations . . . . . . . . . . . . . . . . . . .1512 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . .1612 6. Normative References . . . . . . . . . . . . . . . . . . . . .1712 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .1812 Intellectual Property and Copyright Statements . . . . . . . . . .1914 1. Introduction The document is a companion document to the Diameter Base Protocol Interoperability Test Suite. This document is meant to aid in the identifying the functional test cases of a Diameter Credit Control implementation. The Diameter Credit Control interoperability test suites are categorized by required and optional functionality. The required functionality is the baseline capability that an implementation must support to allow basic interoperability for that category. Optional functionality covers features that not all implementations support or may wish to test. At its current state, this document provides only a collection of test cases designed for interoperability. Test plans may be included in future revisions of this work or maybe provided in some other document. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Within this document the terms defined in [RFC2119]refersrefer to the functionality thathavehas to be provided by an implementation for the usage within this interoperability testevent.document. 3. Diameter Credit Control Test Suite Vendors that support the Diameter Credit Control application must conform to [RFC4006]. The typical test topology for credit control authorization is shown in Figure 1. A user typically requests a service and thereby triggers the CC Client to contact the CC Server requesting the CC Server to verify the user's credit standing prior to service delivery. Since the test cases cover only CC Client and CC Server interoperability, it is left to the tester to verify correctness of the authentication method executed between the user and the AAA server that is used as a pre-requisite for the authorization of the user by the CC server. Additionally, the interaction between the User's host and the CC Client that is used to trigger the interaction between the CC client and the CC Server is outside the scope of this document. +--------+ +-----------+ +------------+ | User |<--->| CC Client |<--->| AAA Server | +--------+ +-----^-----+ +-----^------+ | | | | | +-----V-----+ +---------->| CC Server | +-----------+ Legend: User - Simulated end user CC Client - Vendor A Diam CCA client CC Server - Vendor B Diam CCA server Figure 1: Diameter CC Test Topology A second test topology can exist for testing Diameter/RADIUS translation agent as specified in Section 11 of [RFC4006]. This topology is available for vendors implementing a prepaid RADIUS translation agent. Since the test cases cover interoperability scenarios, validation must be done between the Service Element and the AAA Server/CC Client translation agent. As with Figure 1, it is left to the tester to verify correctness of the access method between User and Service Element. The test cases involving Figure 1 are also relevant to validating AAA Server/CC Client and CC Server and should be used in this topology as well. +------+ +---------+ +---------------+ | User |<--->| Service |<--->| AAA Server | +------+ | Element | | +---------+ | +---------+ | |CC Client| | | +---------+ | +--+----^----+--+ | | +-----V-----+ | CC Server | +-----------+ Legend: User - Simulated user Service Element - Simulated or vendor RADIUS prepaid client application client AAA Server/CC Client - Vendor A Diameter/RADIUS translation agent CC Server - Vendor B Diameter CC Server Figure 2: Translation Gateway Test Topology 3.1. Required Either test topology Figure 1 or Figure 2 can be used for these cases. 3.1.1. Session Based Credit Control First Interrogation Implementations must conform to Section 5.2 of [RFC4006]. This section addresses the initial credit control interactions between a CC Client and a CC Server, i.e., CC-Request-Type is set to the value INITIAL_REQUEST in the CCR message. There are many parameters on which a service can be granted a credit authorization but the objective of these tests is to demonstrate for session based services the initial credit authorization handling procedures are supported. o Positive tests for credit authorization for a session based service with the Requested-Service-Unit AVP NOT present. The service quota profiles should be agreed between the vendors. The test should be repeated to verify support for the following quota types: * Time based services. * Volume (Total, Input, Output Octets) based services. * Services with quota using service specific units. * Money based services. * Services with several unit types granted. o Positive tests for credit authorization for a session based service with the Requested-Service-Unit AVP being present. The service quota profiles should be agreed between the vendors. The test should be repeated to verify support for the following quota types: * Time based services. * Volume (Total, Input, Output Octets) based services. * Services with quota using service specific units. * Money based services. * Services with several unit types granted. o Positive test for the CC Server's ability to support the granting alternative amounts of credit to the values requested in the Requested-Service-Unit AVP of the CCR message. o Negative test for first interrogation of session based services when the CC Server could not process the initial CCR message. Verify support for the graceful handling of events such as unknown end user, account being empty, invalid rating input, or errors defined in [RFC3588]. o Negative test for first interrogation of session based services when the CC Client could not process the initial CCA message. Verify support for the graceful handling of events such as unsupported unit types. o Negative test for first interrogation of session based services when the CC Server includes a Final-Unit-Indication AVP with Final-Unit-Action REDIRECT or RESTRICT_ACCESS in the Credit- Control-Answer or in the AA answer. Verify that CC Client behaves as directed. 3.1.2. Session Based Credit Control Intermediate Interrogation Implementations must conform to Section 5.3 of [RFC4006]. This section addresses the intermediate credit control interactions between a CC Client and a CC Server, i.e., CC-Request-Type is set to the value UPDATE_REQUEST in the CCR message. There are many parameters on which a service can be reauthorized credit but the objective of these tests is to demonstrate for session based services the intermediate credit authorization handling procedures are supported. o Positive tests for credit reauthorization for a session based service with the Requested-Service-Unit AVP NOT present. The Event-Timestamp AVP must be used to mark the time the reauthorization was triggered and the Used-Service-Unit AVP contains the amount of used service units since the service was activated or last interim. The service quota profiles should be agreed between the vendors. The test should be repeated to verify support for the following quota types: * Time based services. * Volume (Total, Input, Output Octets) based services. * Services with quota using service specific units. * Money based services. * Services with several unit types granted. o Positive tests for credit authorization for a session based service with the Requested-Service-Unit AVP is present. The Event-Timestamp AVP must be used to mark the time the reauthorization was triggered and the Used-Service-Unit AVP contains the amount of used service units since the service was activated or last interim. The service quota profiles should be agreed between the vendors. The test should be repeated to verify support for the following quota types: * Time based services. * Volume (Total, Input, Output Octets) based services. * Services with quota using service specific units. * Money based services. * Services with several unit types granted. o Positive test for the CC Server's ability to support the granting alternative amounts of credit to the values requested in the Requested-Service-Unit AVP of the CCR message. o Negative test for intermediate interrogation for session based services when the CC Server could not process the update CCR message. Verify support for the graceful handling of events such as subscription ID missing, account being empty, invalid rating input, or errors defined in [RFC3588]. o Negative test for intermediate interrogation for session based services when the CC Client could not process the update CCA message. Verify support for the graceful handling of events such as unsupported unit types. 3.1.3. Session Based Credit Control Final Interrogation Implementations must conform to Section 5.4 of [RFC4006]. This section addresses the final credit control interactions between a credit control application client and server i.e., CC-Request-Type is set to the value TERMINATION_REQUEST in the CCR message. o Positive test for final interrogation for a session based service. The Event-Timestamp AVP should be used to mark the time the interrogation was triggered and the Used-Service-Unit AVP contains the amount of used service units since the service was activated or last interim. The CC Server must verify support for refunding the unused reserved units and for charging the used monetary amount to the end user's account. 3.1.4. Sub Sessions Implementations must conform to Section 5.1.2 of [RFC4006]. o Positive test for multiple services within a session. Verify vendor support for interrogations when the Multiple-Services- Credit-Control AVP present and the Requested-Service-Unit AVP is not present. o Positive test for multiple services within a session. Verify vendor support for interrogations when the Multiple-Services- Credit-Control AVP present and the Requested-Service-Unit AVP is present. o Positive test for credit pool support. Verify that a vendor's CC Server implementation is capable of supporting credit pools for services by including a G-S-U-Reference within a Granted-Service- Unit AVP in a CCA message. An example scenario is detailed in Appendix A (Flow IX) of [RFC4006]. o Positive test for rating group support. Verify that a vendor's CC Client implementation is capable of associating a service with a rating group by including a Rating-Group AVP in an interrogation. An example scenario is detailed in Appendix A (Flow IX) of [RFC4006]. o Negative test for multiple services within a session. Verify that a CC Server not supporting multiple services within a session treats the Multiple-Services-Indicator AVP and any received Multiple-Services-Credit-Control AVPs as invalid AVPs. o Negative test for invalid/insufficient rating input. Verify that a CC Server receiving invalid rating input (e.g., unknown rating group) shall inform the CC Client by including a result code of DIAMETER_RATING_FAILED in the Multiple-Services-Credit-Control AVP. 3.1.5. Session Based Credit Control Failure Procedures Implementations must conform to Section 5.7 of [RFC4006]. o Test failure behavior when Credit-Control-Failure-Handling AVP is set to TERMINATE. Verify that the CC Client terminates the end user's session if it does not receive a CCA message within the Tx timer. o Test failure behavior when Credit-Control-Failure-Handling AVP is set to CONTINUE. Verify that when CC messages cannot be delivered to CC Server because of transport or temporary failures that the CC Client resends the request to a backup CC Server assuming CC failover is supported or else the service should be granted by the CC Client. o Test failure behavior when Credit-Control-Failure-Handling AVP is set to RETRY_AND_TERMINATE. Verify that when CC messages cannot be delivered to the CC Server because of transport or temporary failures that the CC Client resends the request to a backup CC Server assuming CC failover is supported or else the service should not be granted by the CC Client. 3.1.6. Service Price Enquiry Implementations must conform to Section 6.1 of [RFC4006]. This test uses an event based credit control interaction between the CC Client and the CC Server (i.e., CC-Request-Type is set to the value EVENT_REQUEST in the CCR message). The test is invoked by the CC Client including the Service-Identifier and the Requested-Action AVP set to PRICE_ENQUIRY in the CCR message. An example message flow is shown in Appendix A (Flow V) of [RFC4006]. o Positive test for a service price enquiry. Verify that the CC Server returns the estimated cost of the service to the CC Client in the in the Cost-Information AVP in the CCA message. 3.1.7. Balance Check Implementations must conform to Section 6.2 of [RFC4006]. This test uses an event based credit control interaction between the CC Client and CC Server (i.e., CC-Request-Type is set to the value EVENT_REQUEST in the CCR message). The test is invoked by the CC Client including the Service-Identifier and the Requested-Action AVP set to CHECK_BALANCE in the CCR message. An example scenario is detailed in Appendix A (Flow IV) of [RFC4006]. o Positive test for a check balance enquiry. Verify that the CC Server returns the credit status for the subscriber to access the service to the CC Client in the in the Check-Balance-Result AVP in the CCA message. 3.1.8. Direct Debiting Implementations must conform to Section 6.3 of [RFC4006]. This test uses an event based credit control interaction between the CC Client and CC Server (i.e., CC-Request-Type is set to the value EVENT_REQUEST in the CCR message). The test is invoked by the CC Client including the Service-Identifier and the Requested-Action AVP set to DIRECT_DEBITING in the CCR message. An example message flow is shown in Appendix A (Flow III) of [RFC4006]. o Positive test for a direct debiting enquiry without the CC Client including the requested units. Verify that the CC Server rates the service event and deducts the corresponding monetary amount from the end user's account. Verify that the granted service units can be of type time, volume, service specific, or money. o Positive test for a direct debiting enquiry with the CC Client including the requested units. Verify that the CC Server just deducts the corresponding monetary amount from the end user's account without performing rating. Verify that the granted service units can be of type time, volume, service specific, or money. o Positive test for a direct debiting enquiry where the CC Server determines that no credit-control is required for the service (e.g., free service). 3.1.9. Refunds Implementations must conform to Section 6.4 of [RFC4006]. This test uses an event based credit control interaction between the CC Client and CC Server (i.e., CC-Request-Type is set to the value EVENT_REQUEST in the CCR message). The test is invoked by the CC Client including the Requested-Action AVP set to REFUND_ACCOUNT in the CCR message. An example message flow is shown in Appendix A (Flow VI) of [RFC4006]. o Positive test for a refund request without the CC Client including the requested units. Verify that the CC Server performs the rating required prior to refunding the subscriber's account balance. o Positive test for a refund request with the CC Client including the requested units. Verify that the CC Server refunds the subscriber's account balance with the requested monetary amount. 3.1.10. Event Based Credit Control Failure Procedures Implementations must conform to Section 6.5 of [RFC4006]. o Test that CC Client forwards requests of type price enquiry or balance check to an alternative CC Server if a transport failure is detected and failover is supported. o Test of direct debiting failure handling. Verify that the CC Client behaves as described in section 6.5 of [RFC4006] when the requested actions is direct debiting and the Direct-Debiting- Failure-Handling AVP is set to TERMINATE_OR_BUFFER. o Test of direct debiting failure handling. Verify that the CC Client behaves as described in section 6.5 of [RFC4006] when the requested actions is direct debiting and the Direct-Debiting- Failure-Handling AVP is set to CONTINUE. 3.2. Optional Either test topology Figure 1 or Figure 2 can be used for these cases. 3.2.1. Tariff Time Support Implementations must conform to Section 5.1.1 of [RFC4006]. o Positive test for tariff change support. Verify that the CC Server can send a CCA message including a Tariff-Time-Change AVP. Verify that the CC Client itemizes the used units in respect to the tariff time change when reporting service usage. o Negative test for tariff change support. Verify that the CC Client terminates the credit control session if it does not support tariff time changes and it received a CCA message including a Tariff-Time-Change AVP. 3.2.2. Graceful Service Termination This section addresses the graceful termination features of a CC Server in accordance with Section 5.6 of [RFC4006] utilizing the Final-Unit-Indication AVP. o Positive test for terminate action. Verify that a CC Client terminates the service when the final units have been consumed and it has received a Final-Unit-Action with a value of TERMINATE. The CC Client must send a CCR final message including a CC- Request-Type AVP set to the value TERMINATION_REQUEST. o Positive test for redirect action. Verify that a CC Server supports the inclusion of a Redirect-Server AVP when the Final- Unit-Action AVP is set with a value of REDIRECT. Verify that the end user is redirected by the CC Client to the appropriate redirect server when the final units have been consumed. The CC Client must send a CCR intermediate message specifying the used units and to report that the specified action has started. o Positive test for restriction filter rules. Verify that a CC Server supports the inclusion of Restriction-Filter-Rule AVPs when the Final-Unit-Action AVP is set with a value of REDIRECT or RESTRICT. Verify that the end user packets not matching the restriction filter are dropped by the CC Client when the final units have been consumed. The CC Client must send a CCR intermediate message specifying the used units and to report that the specified action has started. o Positive test for IP filter list handling. Verify that a CC Server supports the inclusion of Filter-Id AVPs when the Final- Unit-Action AVP is set with a value of REDIRECT or RESTRICT. Verify that the end user packets not matching the filter are dropped by the CC Client when the final units have been consumed. The CC Client must send a CCR intermediate message specifying the used units and to report that the specified action has started. o Negative test for default final unit handling. Verify that a CC Client terminates the service when the final units have been consumed and it has received an unsupported Final-Unit-Action value. The CC Client must send a CCR final message including a CC-Request-Type AVP set to the value TERMINATION_REQUEST. 3.2.3. Validity Time o Positive test for Validity-Time AVP support. Verify that the CC Server is capable of including a validity time with granted service units in a CCA message. Verify the CC Client generates a CC update request and reports the used quota to the CC server when the validity timer expires. o Positive test for Validity-Time AVP support with multiple services within a session. Verify that the CC Server is capable of including a validity time in a Multiple-Services-Credit-Control AVP in a CCA message. Verify the CC Client generates a CC update request and reports the used quota to the CC server when the validity timer expires. 3.2.4. Server Initiated Credit Reauthorization Implementations must conform to Section 5.5 of [RFC4006]. o Positive test for CC Server initiated reauthorization of all services in a session. Verify that the CC Client follows the RAA and CCR Update procedure defined in Section 5.5 of [RFC4006]. o Positive test for CC Server initiated reauthorization for a credit pool in a session. Verify that the CC Server includes the G-S-U- Pool-Identifier AVP in the RAR message. Verify that the CC Client follows the RAA and CCR Update procedure defined in Section 5.5 of [RFC4006]. o Positive test for CC Server initiated reauthorization for a rating group in a session. Verify that the CC Server includes the Rating-Group AVP in the RAR message. Verify that the CC Client follows the RAA and CCR Update procedure defined in Section 5.5 of [RFC4006]. o Positive test for CC Server initiated reauthorization for a specific service in a session. Verify that the CC Server includes the Service-Identifier AVP in the RAR message. Verify that the CC Client follows the RAA and CCR Update procedure defined in Section 5.5 of [RFC4006]. o Positive test RAR-CCR Collision handling support. Verify that the CC Client sends an RAA with a DIAMETER_SUCCESS result but does not initiate a CCR. Verify that the CC Server processes the CCR message as if it was generate in response to the RAR message. o Positive test for CC Server initiated reauthorization for an active sub session. Verify that the CC Server includes the CC- Sub-Session-Id AVP in the RAR message. Verify that the CC Client follows the RAA and CCR Update procedures defined in Section 5.5 of [RFC4006]. 4. Security Considerations This document defines test cases and therefore tests various aspects of the Diameter base specification and various Diameter applications. 5. IANA Considerations This document does not require actions by IANA. 6. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, "Diameter Credit-Control Application", RFC 4006, August 2005. Authors' Addresses Alan McNamee Openet Telecom Inc 6 Beckett Way, Park West Business Park Clondalkin, Dublin 12 Ireland Phone: +353 1 620 4600 Email: alan.mcnamee@openet-telecom.com Hannes Tschofenig Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Phone: +49 89 636 40390 Email: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.com Victor Fajardo Toshiba America Research, Inc. 1 Telcordia Drive Piscataway, NJ 08854 USA Phone: +1 732 699 5368 Email: vfajardo@tari.toshiba.com Julien BournelleInstitut National des Telecommunications 9France Telecom R&D 38-4O rueCharles Fourier Evry cedex, 91011du general Leclerc Issy-Les-Moulineaux 92794 FrancePhone: +33 1 60 76 44 79Email:julien.bournelle@int-evry.frjulien.bournelle@orange-ftgroup.com Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).