Internet DRAFT - draft-fajardo-dime-dcc-test-suite

draft-fajardo-dime-dcc-test-suite






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]