<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3588 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml'>
<!ENTITY rfc4006 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4006.xml'> 
]>

<rfc ipr='trust200902' docName='draft-fajardo-dime-dcc-test-suite-02.txt'>
  <front>
    <title abbrev="DCC Interoperability Test Suite">
      Diameter Credit Control Interoperability Test Suite
    </title>
    
    <author initials="A." surname="McNamee"
      fullname="Alan McNamee">
      <organization abbrev="Openet-Telecom">
	Openet Telecom Inc
      </organization>
      <address>
	<postal>
          <street>6 Beckett Way, Park West Business Park</street>
          <city>Clondalkin</city>
          <region>Dublin</region>
          <code>12</code>
          <country>Ireland</country>
	</postal>
	<phone>+353 1 620 4600</phone>
	<email>alan.mcnamee@openet-telecom.com</email>
      </address>
    </author>
    <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
      <organization>Nokia Siemens Networks</organization>
      <address>
        <postal>
          <street>Linnoitustie 6</street>
          <city>Espoo</city>
          <code>02600</code>
          <country>Finland</country>
        </postal>
        <phone>+358 (50) 4871445</phone>
        <email>Hannes.Tschofenig@gmx.net</email>
        <uri>http://www.tschofenig.priv.at</uri>
      </address>
    </author>
    
    <author initials="V." surname="Fajardo" fullname="Victor Fajardo">
      <organization>Telcordia Technologies </organization>
      <address>
        <postal>
          <street>1 Telcordia Drive #1S-222</street>
          <city>Piscataway</city>
          <region>NJ</region>
          <code>08854</code>
          <country>USA</country>
        </postal>
        <email>vfajardo@research.telcordia.com</email>
      </address>
    </author>
    
    
    
    <author fullname="Julien Bournelle" surname="Bournelle" initials="J.">
      <organization>France Telecom R&amp;D </organization>
      <address>
        <postal>
          <street>38-4O rue du general Leclerc</street>
          <city>Issy-Les-Moulineaux</city>
          <code>92794</code>
          <country>France</country>
        </postal>
        <email>julien.bournelle@orange-ftgroup.com</email>
      </address>
    </author>

    <date year="2009"/>
    <workgroup>DIME</workgroup>

    <abstract>
      <t>
        This document describes a collection of test cases
        to be used for Diameter Credit Control application
        interoperability testing.
      </t>
    </abstract>

  </front>
  <middle>
    <section title='Introduction'>
      <t>
        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.
      </t>
      <t>
        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.
      </t>
    </section>
    <section title="Terminology">
      <t>
        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 <xref target='RFC2119'/>.
      </t>
      <t>
        Within this document the terms defined in
        <xref target='RFC2119'/> refer to the functionality 
        that has to be provided by an implementation for the 
        usage within this interoperability test document.
      </t>
    </section>
    <section title='Diameter Credit Control Test Suite' anchor='sec-app-credit-control'>
      <t>
        Vendors that support the Diameter Credit Control application must conform
        to <xref target='RFC4006'/>. The typical test topology for 
        credit control authorization is shown in 
        <xref target='fig-app-cc-01'/>. 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.          
        <figure anchor='fig-app-cc-01' title='Diameter CC Test Topology'>
          <artwork>
            <![CDATA[
  +--------+     +-----------+     +------------+ 
  | 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
          ]]> </artwork>
        </figure>
        A second test topology can exist for testing Diameter/RADIUS 
        translation agent as specified in Section 11 of 
        <xref target='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 <xref target='fig-app-cc-01'/>, it is left to the 
        tester to verify correctness of the access method between User and
        Service Element. The test cases involving 
        <xref target='fig-app-cc-01'/> are also relevant to validating AAA 
        Server/CC Client and CC Server and should be used in this topology
        as well.
        <figure anchor='fig-app-cc-02' title='Translation Gateway Test Topology'>
          <artwork><![CDATA[
  +------+     +---------+     +---------------+     
  | 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
        ]]>     </artwork>
        </figure>
      </t>
      <section title='Required' anchor='sec-app-cc-req'>
        <t>
          Either test topology <xref target='fig-app-cc-01'/> or 
          <xref target='fig-app-cc-02'/> can be used for these cases.
        </t>
        <section title='Session Based Credit Control First Interrogation' anchor='sec-app-cc-req1'>
          <t>
            Implementations must conform to Section 5.2 of <xref target='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.
            <list style='symbols'>
              <t>
                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:
                <list style="symbols">
                  <t>
                    Time based services.
                  </t>
                  <t>
                    Volume (Total, Input, Output Octets) based services.
                  </t>
                  <t>
                    Services with quota using service specific units.
                  </t>
                  <t>
                    Money based services.
                  </t>
                  <t>
                    Services with several unit types granted.
                  </t>
                </list>
              </t>
              <t>
                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:
                <list style="symbols">
                  <t>
                    Time based services.
                  </t>
                  <t>
                    Volume (Total, Input, Output Octets) based services.
                  </t>
                  <t>
                    Services with quota using service specific units.
                  </t>
                  <t>
                    Money based services.
                  </t>
                  <t>
                    Services with several unit types granted.
                  </t>
                </list>  
              </t>
              <t>
                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.          
              </t>
              <t>
                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 
                <xref target='RFC3588'/>.
              </t>
              <t>
                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.
              </t>
              <t>
                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.            
              </t>
            </list>
          </t>
        </section>
        <section title='Session Based Credit Control Intermediate Interrogation' anchor='sec-app-cc-req2'>
          <t>
            Implementations must conform to Section 5.3 of <xref target='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.
            <list style='symbols'>
              <t>
                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:
                <list style="symbols">
                  <t>
                    Time based services.
                  </t>
                  <t>
                    Volume (Total, Input, Output Octets) based services.
                  </t>
                  <t>
                    Services with quota using service specific units.
                  </t>
                  <t>
                    Money based services.
                  </t>
                  <t>
                    Services with several unit types granted.
                  </t>
                </list>
              </t>
              <t>
                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:
                <list style="symbols">
                  <t>
                    Time based services.
                  </t>
                  <t>
                    Volume (Total, Input, Output Octets) based services.
                  </t>
                  <t>
                    Services with quota using service specific units.
                  </t>
                  <t>
                    Money based services.
                  </t>
                  <t>
                    Services with several unit types granted.
                  </t>
                </list>  
              </t>
              <t>
                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.          
              </t>
              <t>
                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 
                <xref target='RFC3588'/>.
              </t>
              <t>
                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.
              </t>
            </list>
          </t>
        </section>
        <section title='Session Based Credit Control Final Interrogation' anchor='sec-app-cc-req3'>
          <t>
            Implementations must conform to Section 5.4 of <xref target='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. 
            <list style='symbols'>
              <t>
                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.
              </t>
            </list>
          </t>
        </section>
        <section title='Sub Sessions' anchor='sec-app-cc-req4'>
          <t>
            Implementations must conform to Section 5.1.2 of <xref target='RFC4006'/>. 
            <list style='symbols'>
              <t>
                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.
              </t>
              <t>
                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.
              </t>
              <t>
                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 
                <xref target='RFC4006'/>.
              </t>
              <t>
                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 <xref target='RFC4006'/>.
              </t>
              <t>
                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.
              </t>
              <t>
                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.
              </t>
            </list>
          </t>
        </section>
        <section title='Session Based Credit Control Failure Procedures' anchor='sec-app-cc-req5'>
          <t>
            Implementations must conform to Section 5.7 of 
            <xref target='RFC4006'/>.               
            <list style='symbols'>
              <t>
                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.
              </t>
              <t>
                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.
              </t>
              <t>
                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.
              </t>
            </list>
          </t>
        </section>
        <section title='Service Price Enquiry' anchor='sec-app-cc-req6'>
          <t>
            Implementations must conform to Section 6.1 of <xref target='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 
            <xref target='RFC4006'/>.
            <list style='symbols'>
              <t>
                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.
              </t>
            </list>
          </t>
        </section>
        <section title='Balance Check' anchor='sec-app-cc-req7'>
          <t>
            Implementations must conform to Section 6.2 of <xref target='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 <xref target='RFC4006'/>.
            <list style='symbols'>
              <t>
                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.
              </t>
            </list>
          </t>
        </section>
        <section title='Direct Debiting' anchor='sec-app-cc-req8'>
          <t>
            Implementations must conform to Section 6.3 of <xref target='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 <xref target='RFC4006'/>.
            <list style='symbols'>
              <t>
                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.
              </t>
              <t>
                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.
              </t>
              <t>
                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).
              </t>
            </list>
          </t>
        </section>
        <section title='Refunds' anchor='sec-app-cc-req9'>
          <t>
            Implementations must conform to Section 6.4 of <xref target='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 <xref target='RFC4006'/>.
            <list style='symbols'>
              <t>
                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.
              </t>
              <t>
                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.
              </t>
            </list>
          </t>
        </section>
        <section title='Event Based Credit Control Failure Procedures' anchor='sec-app-cc-req10'>
          <t>
            Implementations must conform to Section 6.5 of <xref target='RFC4006'/>.
            <list style='symbols'>
              <t>
                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.
              </t>
              <t>
                Test of direct debiting failure handling. Verify that the CC
                Client behaves as described in section 6.5 of
                <xref target='RFC4006'/> when the requested actions is direct
                debiting and the Direct-Debiting-Failure-Handling AVP is set
                to TERMINATE_OR_BUFFER.
              </t>
              <t>
                Test of direct debiting failure handling. Verify that the CC
                Client behaves as described in section 6.5 of
                <xref target='RFC4006'/> when the requested actions is direct
                debiting and the Direct-Debiting-Failure-Handling AVP is set
                to CONTINUE.
              </t>
            </list>
          </t>
        </section>
        <t>
        </t>
      </section>
      <section title='Optional' anchor='sec-app-cc-optional'>
        <t>
          Either test topology <xref target='fig-app-cc-01'/> 
          or <xref target='fig-app-cc-02'/> can be used for these cases.
        </t>
        <section title='Tariff Time Support' anchor='sec-app-cc-optional1'>
          <t>
            Implementations must conform to Section 5.1.1 of <xref target='RFC4006'/>. 
            <list style='symbols'>
              <t>
                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.
              </t>
              <t>
                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.
              </t>
            </list>
          </t>
        </section>
        <section title='Graceful Service Termination' anchor='sec-app-cc-optional2'>
          <t>
            This section addresses the graceful termination features of a CC Server
            in accordance with Section 5.6 of <xref target='RFC4006'/> utilizing the
            Final-Unit-Indication AVP. 
            <list style='symbols'>
              <t>
                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.
              </t>
              <t>
                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.
              </t>
              <t>
                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.
              </t>
              <t>
                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.
                </t>
              <t>
                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.
              </t>
            </list>
          </t>
        </section>
        <section title='Validity Time' anchor='sec-app-cc-optional3'>
          <t>
            <list style='symbols'>
              <t>
                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.
              </t>
              <t>
                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.
              </t>
            </list>
          </t>
        </section>
        <section title='Server Initiated Credit Reauthorization' anchor='sec-app-cc-optional4'>
          <t>
            Implementations must conform to Section 5.5 of <xref target='RFC4006'/>. 
            <list style='symbols'>
              <t>
                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 
                <xref target='RFC4006'/>.
              </t>
              <t>
                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 <xref target='RFC4006'/>.
              </t>
              <t>
                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 <xref target='RFC4006'/>.
              </t>
              <t>
                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 <xref target='RFC4006'/>.
              </t>
              <t>
                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. 
              </t>
              <t>
                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 <xref target='RFC4006'/>.
              </t>
            </list>
          </t>
        </section>
      </section>
    </section>
    <section title='Security Considerations' anchor='section-security-considerations'>
      <t>
        This document defines test cases and therefore tests
        various aspects of the Diameter base specification and 
        various Diameter applications.
      </t>
    </section>
    <section title='IANA Considerations'>
      <t>
        This document does not require actions by IANA.
      </t>
    </section>
  </middle>
  <back>
    <references title='Normative References'>
      &rfc2119;
      &rfc3588; 
      &rfc4006; 
     
    </references>
  </back>
</rfc>
