DIME A. McNamee
Internet-Draft Openet-Telecom
Expires: January 14, 2010 H. Tschofenig
Nokia Siemens Networks
V. Fajardo
Telcordia Technologies
J. Bournelle
France Telecom R&D
July 13, 2009
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.
McNamee, et al. Expires January 14, 2010 [Page 1]
Internet-Draft DCC Interoperability Test Suite July 2009
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Diameter Credit Control Test Suite . . . . . . . . . . . . . . 3
3.1. Required . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Session Based Credit Control First Interrogation . . . 5
3.1.2. Session Based Credit Control Intermediate
Interrogation . . . . . . . . . . . . . . . . . . . . 6
3.1.3. Session Based Credit Control Final Interrogation . . . 7
3.1.4. Sub Sessions . . . . . . . . . . . . . . . . . . . . . 7
3.1.5. Session Based Credit Control Failure Procedures . . . 8
3.1.6. Service Price Enquiry . . . . . . . . . . . . . . . . 8
3.1.7. Balance Check . . . . . . . . . . . . . . . . . . . . 8
3.1.8. Direct Debiting . . . . . . . . . . . . . . . . . . . 9
3.1.9. Refunds . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.10. Event Based Credit Control Failure Procedures . . . . 10
3.2. Optional . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1. Tariff Time Support . . . . . . . . . . . . . . . . . 10
3.2.2. Graceful Service Termination . . . . . . . . . . . . . 10
3.2.3. Validity Time . . . . . . . . . . . . . . . . . . . . 11
3.2.4. Server Initiated Credit Reauthorization . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
McNamee, et al. Expires January 14, 2010 [Page 2]
Internet-Draft DCC Interoperability Test Suite July 2009
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] 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]. 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.
McNamee, et al. Expires January 14, 2010 [Page 3]
Internet-Draft DCC Interoperability Test Suite July 2009
+--------+ +-----------+ +------------+
| 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
McNamee, et al. Expires January 14, 2010 [Page 4]
Internet-Draft DCC Interoperability Test Suite July 2009
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.
McNamee, et al. Expires January 14, 2010 [Page 5]
Internet-Draft DCC Interoperability Test Suite July 2009
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
McNamee, et al. Expires January 14, 2010 [Page 6]
Internet-Draft DCC Interoperability Test Suite July 2009
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.
McNamee, et al. Expires January 14, 2010 [Page 7]
Internet-Draft DCC Interoperability Test Suite July 2009
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].
McNamee, et al. Expires January 14, 2010 [Page 8]
Internet-Draft DCC Interoperability Test Suite July 2009
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.
McNamee, et al. Expires January 14, 2010 [Page 9]
Internet-Draft DCC Interoperability Test Suite July 2009
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
McNamee, et al. Expires January 14, 2010 [Page 10]
Internet-Draft DCC Interoperability Test Suite July 2009
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].
McNamee, et al. Expires January 14, 2010 [Page 11]
Internet-Draft DCC Interoperability Test Suite July 2009
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.
McNamee, et al. Expires January 14, 2010 [Page 12]
Internet-Draft DCC Interoperability Test Suite July 2009
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
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Victor Fajardo
Telcordia Technologies
1 Telcordia Drive #1S-222
Piscataway, NJ 08854
USA
Email: vfajardo@research.telcordia.com
Julien Bournelle
France Telecom R&D
38-4O rue du general Leclerc
Issy-Les-Moulineaux 92794
France
Email: julien.bournelle@orange-ftgroup.com
McNamee, et al. Expires January 14, 2010 [Page 13]