< draft-fajardo-dime-dcc-test-suite-00.txt		draft-fajardo-dime-dcc-test-suite-01.txt >
	DIME Working Group A. McNamee		DIME Working Group A. McNamee
	Internet-Draft Openet-Telecom		Internet-Draft Openet-Telecom
	Expires: October 30, 2007 H. Tschofenig		Expires: January 2, 2008 H. Tschofenig
	NokiaSiemens		Nokia Siemens Networks
	V. Fajardo		V. Fajardo
	TARI		TARI
	J. Bournelle		J. Bournelle
	GET/INT		France Telecom R&D
	April 28, 2007		July 1, 2007
	Diameter Credit Control Interoperability Test Suite		Diameter Credit Control Interoperability Test Suite
	draft-fajardo-dime-dcc-test-suite-00		draft-fajardo-dime-dcc-test-suite-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on October 30, 2007.		This Internet-Draft will expire on January 2, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document describes a collection of test cases to be used for		This document describes a collection of test cases to be used for
	Diameter Credit Control application interoperability testing.		Diameter Credit Control application interoperability testing.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Diameter Credit Control Test Suite . . . . . . . . . . . . . . 5		3. Diameter Credit Control Test Suite . . . . . . . . . . . . . . 3
	3.1. Required . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.1. Required . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1.1. Session Based Credit Control First Interrogation . . . 6		3.1.1. Session Based Credit Control First Interrogation . . . 5
	3.1.2. Session Based Credit Control Intermediate		3.1.2. Session Based Credit Control Intermediate
	Interrogation . . . . . . . . . . . . . . . . . . . . 7		Interrogation . . . . . . . . . . . . . . . . . . . . 6
	3.1.3. Session Based Credit Control Final Interrogation . . . 9		3.1.3. Session Based Credit Control Final Interrogation . . . 7
	3.1.4. Sub Sessions . . . . . . . . . . . . . . . . . . . . . 9		3.1.4. Sub Sessions . . . . . . . . . . . . . . . . . . . . . 7
	3.1.5. Session Based Credit Control Failure Procedures . . . 10		3.1.5. Session Based Credit Control Failure Procedures . . . 8
	3.1.6. Service Price Enquiry . . . . . . . . . . . . . . . . 10		3.1.6. Service Price Enquiry . . . . . . . . . . . . . . . . 8
	3.1.7. Balance Check . . . . . . . . . . . . . . . . . . . . 11		3.1.7. Balance Check . . . . . . . . . . . . . . . . . . . . 8
	3.1.8. Direct Debiting . . . . . . . . . . . . . . . . . . . 11		3.1.8. Direct Debiting . . . . . . . . . . . . . . . . . . . 9
	3.1.9. Refunds . . . . . . . . . . . . . . . . . . . . . . . 12		3.1.9. Refunds . . . . . . . . . . . . . . . . . . . . . . . 9
	3.1.10. Event Based Credit Control Failure Procedures . . . . 12		3.1.10. Event Based Credit Control Failure Procedures . . . . 10
	3.2. Optional . . . . . . . . . . . . . . . . . . . . . . . . . 12		3.2. Optional . . . . . . . . . . . . . . . . . . . . . . . . . 10
	3.2.1. Tariff Time Support . . . . . . . . . . . . . . . . . 12		3.2.1. Tariff Time Support . . . . . . . . . . . . . . . . . 10
	3.2.2. Graceful Service Termination . . . . . . . . . . . . . 13		3.2.2. Graceful Service Termination . . . . . . . . . . . . . 10
	3.2.3. Validity Time . . . . . . . . . . . . . . . . . . . . 13		3.2.3. Validity Time . . . . . . . . . . . . . . . . . . . . 11
	3.2.4. Server Initiated Credit Reauthorization . . . . . . . 14		3.2.4. Server Initiated Credit Reauthorization . . . . . . . 11
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 15		4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	6. Normative References . . . . . . . . . . . . . . . . . . . . . 17		6. Normative References . . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	Intellectual Property and Copyright Statements . . . . . . . . . . 19		Intellectual Property and Copyright Statements . . . . . . . . . . 14
	1. Introduction		1. Introduction
	The document is a companion document to the Diameter Base Protocol		The document is a companion document to the Diameter Base Protocol
	Interoperability Test Suite. This document is meant to aid in the		Interoperability Test Suite. This document is meant to aid in the
	identifying the functional test cases of a Diameter Credit Control		identifying the functional test cases of a Diameter Credit Control
	implementation. The Diameter Credit Control interoperability test		implementation. The Diameter Credit Control interoperability test
	suites are categorized by required and optional functionality. The		suites are categorized by required and optional functionality. The
	required functionality is the baseline capability that an		required functionality is the baseline capability that an
	implementation must support to allow basic interoperability for that		implementation must support to allow basic interoperability for that
	skipping to change at page 4, line 11 ¶		skipping to change at page 3, line 28 ¶
	test cases designed for interoperability. Test plans may be included		test cases designed for interoperability. Test plans may be included
	in future revisions of this work or maybe provided in some other		in future revisions of this work or maybe provided in some other
	document.		document.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Within this document the terms defined in [RFC2119] refers to the		Within this document the terms defined in [RFC2119] refer to the
	functionality that have to be provided by an implementation for the		functionality that has to be provided by an implementation for the
	usage within this interoperability test event.		usage within this interoperability test document.
	3. Diameter Credit Control Test Suite		3. Diameter Credit Control Test Suite
	Vendors that support the Diameter Credit Control application must		Vendors that support the Diameter Credit Control application must
	conform to [RFC4006]. The typical test topology for credit control		conform to [RFC4006]. The typical test topology for credit control
	authorization is shown in Figure 1. A user typically requests a		authorization is shown in Figure 1. A user typically requests a
	service and thereby triggers the CC Client to contact the CC Server		service and thereby triggers the CC Client to contact the CC Server
	requesting the CC Server to verify the user's credit standing prior		requesting the CC Server to verify the user's credit standing prior
	to service delivery. Since the test cases cover only CC Client and		to service delivery. Since the test cases cover only CC Client and
	CC Server interoperability, it is left to the tester to verify		CC Server interoperability, it is left to the tester to verify
	correctness of the authentication method executed between the user		correctness of the authentication method executed between the user
	and the AAA server that is used as a pre-requisite for the		and the AAA server that is used as a pre-requisite for the
	authorization of the user by the CC server. Additionally, 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		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		trigger the interaction between the CC client and the CC Server is
	outside the scope of this document.		outside the scope of this document.
	+--------+ +-----------+ +------------+		+--------+ +-----------+ +------------+
	| User |<--->| CC Client |<--->| AAA Server |		| User |<--->| CC Client |<--->| AAA Server |
	+--------+ +-----^-----+ +-----^------+		+--------+ +-----^-----+ +-----^------+
	| |		| |
	| |		| |
	| +-----V-----+		| +-----V-----+
	+---------->| CC Server |		+---------->| CC Server |
	+-----------+		+-----------+
	Legend:		Legend:
	User - Simulated end user		User - Simulated end user
	CC Client - Vendor A Diam CCA client		CC Client - Vendor A Diam CCA client
	CC Server - Vendor B Diam CCA server		CC Server - Vendor B Diam CCA server
	Figure 1: Diameter CC Test Topology		Figure 1: Diameter CC Test Topology
	A second test topology can exist for testing Diameter/RADIUS		A second test topology can exist for testing Diameter/RADIUS
	translation agent as specified in Section 11 of [RFC4006]. This		translation agent as specified in Section 11 of [RFC4006]. This
	skipping to change at page 6, line 8 ¶		skipping to change at page 4, line 35 ¶
	scenarios, validation must be done between the Service Element and		scenarios, validation must be done between the Service Element and
	the AAA Server/CC Client translation agent. As with Figure 1, it is		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		left to the tester to verify correctness of the access method between
	User and Service Element. The test cases involving Figure 1 are also		User and Service Element. The test cases involving Figure 1 are also
	relevant to validating AAA Server/CC Client and CC Server and should		relevant to validating AAA Server/CC Client and CC Server and should
	be used in this topology as well.		be used in this topology as well.
	+------+ +---------+ +---------------+		+------+ +---------+ +---------------+
	| User |<--->| Service |<--->| AAA Server |		| User |<--->| Service |<--->| AAA Server |
	+------+ | Element | | +---------+ |		+------+ | Element | | +---------+ |
	+---------+ | |CC Client| |		+---------+ | |CC Client| |
	| +---------+ |		| +---------+ |
	+--+----^----+--+		+--+----^----+--+
	|		|
	|		|
	+-----V-----+		+-----V-----+
	| CC Server |		| CC Server |
	+-----------+		+-----------+
	Legend:		Legend:
	User - Simulated user		User - Simulated user
	Service Element - Simulated or vendor RADIUS prepaid		Service Element - Simulated or vendor RADIUS prepaid
	client application client		client application client
	AAA Server/CC Client - Vendor A Diameter/RADIUS		AAA Server/CC Client - Vendor A Diameter/RADIUS
	translation agent		translation agent
	CC Server - Vendor B Diameter CC Server		CC Server - Vendor B Diameter CC Server
	Figure 2: Translation Gateway Test Topology		Figure 2: Translation Gateway Test Topology
	skipping to change at page 13, line 18 ¶		skipping to change at page 10, line 42 ¶
	o Negative test for tariff change support. Verify that the CC		o Negative test for tariff change support. Verify that the CC
	Client terminates the credit control session if it does not		Client terminates the credit control session if it does not
	support tariff time changes and it received a CCA message		support tariff time changes and it received a CCA message
	including a Tariff-Time-Change AVP.		including a Tariff-Time-Change AVP.
	3.2.2. Graceful Service Termination		3.2.2. Graceful Service Termination
	This section addresses the graceful termination features of a CC		This section addresses the graceful termination features of a CC
	Server in accordance with Section 5.6 of [RFC4006] utilizing the		Server in accordance with Section 5.6 of [RFC4006] utilizing the
	Final-Unit-Indication AVP.		Final-Unit-Indication AVP.
	o Positive test for terminate action. Verify that a CC Client		o Positive test for terminate action. Verify that a CC Client
	terminates the service when the final units have been consumed and		terminates the service when the final units have been consumed and
	it has received a Final-Unit-Action with a value of TERMINATE.		it has received a Final-Unit-Action with a value of TERMINATE.
	The CC Client must send a CCR final message including a CC-		The CC Client must send a CCR final message including a CC-
	Request-Type AVP set to the value TERMINATION_REQUEST.		Request-Type AVP set to the value TERMINATION_REQUEST.
	o Positive test for redirect action. Verify that a CC Server		o Positive test for redirect action. Verify that a CC Server
	supports the inclusion of a Redirect-Server AVP when the Final-		supports the inclusion of a Redirect-Server AVP when the Final-
	Unit-Action AVP is set with a value of REDIRECT. Verify that the		Unit-Action AVP is set with a value of REDIRECT. Verify that the
	end user is redirected by the CC Client to the appropriate		end user is redirected by the CC Client to the appropriate
	redirect server when the final units have been consumed. The CC		redirect server when the final units have been consumed. The CC
	Client must send a CCR intermediate message specifying the used		Client must send a CCR intermediate message specifying the used
	units and to report that the specified action has started.		units and to report that the specified action has started.
	o Positive test for restriction filter rules. Verify that a CC		o Positive test for restriction filter rules. Verify that a CC
	Server supports the inclusion of Restriction-Filter-Rule AVPs when		Server supports the inclusion of Restriction-Filter-Rule AVPs when
	the Final-Unit-Action AVP is set with a value of REDIRECT or		the Final-Unit-Action AVP is set with a value of REDIRECT or
	RESTRICT. Verify that the end user packets not matching the		RESTRICT. Verify that the end user packets not matching the
	restriction filter are dropped by the CC Client when the final		restriction filter are dropped by the CC Client when the final
	units have been consumed. The CC Client must send a CCR		units have been consumed. The CC Client must send a CCR
	intermediate message specifying the used units and to report that		intermediate message specifying the used units and to report that
	the specified action has started.		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		o Negative test for default final unit handling. Verify that a CC
	Client terminates the service when the final units have been		Client terminates the service when the final units have been
	consumed and it has received an unsupported Final-Unit-Action		consumed and it has received an unsupported Final-Unit-Action
	value. The CC Client must send a CCR final message including a		value. The CC Client must send a CCR final message including a
	CC-Request-Type AVP set to the value TERMINATION_REQUEST.		CC-Request-Type AVP set to the value TERMINATION_REQUEST.
	3.2.3. Validity Time		3.2.3. Validity Time
	o Positive test for Validity-Time AVP support. Verify that the CC		o Positive test for Validity-Time AVP support. Verify that the CC
	Server is capable of including a validity time with granted		Server is capable of including a validity time with granted
	skipping to change at page 18, line 18 ¶		skipping to change at page 13, line 18 ¶
	Openet Telecom Inc		Openet Telecom Inc
	6 Beckett Way, Park West Business Park		6 Beckett Way, Park West Business Park
	Clondalkin, Dublin 12		Clondalkin, Dublin 12
	Ireland		Ireland
	Phone: +353 1 620 4600		Phone: +353 1 620 4600
	Email: alan.mcnamee@openet-telecom.com		Email: alan.mcnamee@openet-telecom.com
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
			Otto-Hahn-Ring 6
			Munich, Bavaria 81739
			Germany
	Phone:		Phone: +49 89 636 40390
	Email: Hannes.Tschofenig@nsn.com		Email: Hannes.Tschofenig@nsn.com
			URI: http://www.tschofenig.com
	Victor Fajardo		Victor Fajardo
	Toshiba America Research, Inc.		Toshiba America Research, Inc.
	1 Telcordia Drive		1 Telcordia Drive
	Piscataway, NJ 08854		Piscataway, NJ 08854
	USA		USA
	Phone: +1 732 699 5368		Phone: +1 732 699 5368
	Email: vfajardo@tari.toshiba.com		Email: vfajardo@tari.toshiba.com
	Julien Bournelle		Julien Bournelle
	Institut National des Telecommunications		France Telecom R&D
	9 rue Charles Fourier		38-4O rue du general Leclerc
	Evry cedex, 91011		Issy-Les-Moulineaux 92794
	France		France
	Phone: +33 1 60 76 44 79		Email: julien.bournelle@orange-ftgroup.com
	Email: julien.bournelle@int-evry.fr
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
End of changes. 18 change blocks.
	55 lines changed or deleted		61 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/