Diameter Credit Control Interoperability Test Suite
draft-fajardo-dime-dcc-test-suite-02.txt

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 on January 14, 2010.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

This document describes a collection of test cases to be used for Diameter Credit Control application interoperability testing.

Table of Contents

1.  Introduction
2.  Terminology
3.  Diameter Credit Control Test Suite
    3.1.  Required
        3.1.1.  Session Based Credit Control First Interrogation
        3.1.2.  Session Based Credit Control Intermediate Interrogation
        3.1.3.  Session Based Credit Control Final Interrogation
        3.1.4.  Sub Sessions
        3.1.5.  Session Based Credit Control Failure Procedures
        3.1.6.  Service Price Enquiry
        3.1.7.  Balance Check
        3.1.8.  Direct Debiting
        3.1.9.  Refunds
        3.1.10.  Event Based Credit Control Failure Procedures
    3.2.  Optional
        3.2.1.  Tariff Time Support
        3.2.2.  Graceful Service Termination
        3.2.3.  Validity Time
        3.2.4.  Server Initiated Credit Reauthorization
4.  Security Considerations
5.  IANA Considerations
6.  Normative References
§  Authors' Addresses

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

Within this document the terms defined in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) refer to the functionality that has to be provided by an implementation for the usage within this interoperability test document.

3.  Diameter Credit Control Test Suite

Vendors that support the Diameter Credit Control application must conform to [RFC4006] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.). The typical test topology for credit control authorization is shown in Figure 1 (Diameter CC Test Topology). 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

  +------+     +---------+     +---------------+
  | 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

3.1.  Required

Either test topology Figure 1 (Diameter CC Test Topology) or Figure 2 (Translation Gateway Test Topology) can be used for these cases.

3.1.1.  Session Based Credit Control First Interrogation

Implementations must conform to Section 5.2 of [RFC4006] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.). 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.

• 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.
• 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.
• 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.
• 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] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.).
• 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.
• 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.). 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.

• 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.
• 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.
• 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.
• 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] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.).
• 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.). 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.

• 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.).

• 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.
• 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.
• 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.).
• 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.).
• 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.
• 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.).

• 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.
• 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.
• 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.). 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.).

• 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.). 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.).

• 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.). 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.).

• 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.
• 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.
• 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.). 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.).

• 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.
• 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.).

• 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.
• Test of direct debiting failure handling. Verify that the CC Client behaves as described in section 6.5 of [RFC4006] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.) when the requested actions is direct debiting and the Direct-Debiting-Failure-Handling AVP is set to TERMINATE_OR_BUFFER.
• Test of direct debiting failure handling. Verify that the CC Client behaves as described in section 6.5 of [RFC4006] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.) 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 (Diameter CC Test Topology) or Figure 2 (Translation Gateway Test Topology) can be used for these cases.

3.2.1.  Tariff Time Support

Implementations must conform to Section 5.1.1 of [RFC4006] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.).

• 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.
• 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.) utilizing the Final-Unit-Indication AVP.

• 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.
• 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.
• 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.
• 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.
• 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

• 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.
• 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.).

• 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.).
• 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.).
• 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.).
• 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.).
• 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.
• 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] (Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J. Loughney, “Diameter Credit-Control Application,” August 2005.).

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

Authors' Addresses