Draft Fajardo Dime Interop Test Suite 04

8/3/2019 Draft Fajardo Dime Interop Test Suite 04

1/66

AAA Working Group V. FajardoInternet-Draft TARIExpires: July 5, 2007 A. McNamee

Openet-TelecomH. Tschofenig

SiemensJ. Bournelle

GET/INTJanuary 2007

Diameter Interoperability Test Suitedraft-fajardo-dime-interop-test-suite-04

Status of this Memo

By submitting this Internet-Draft, each author represents that any

applicable patent or other IPR claims of which he or she is awarehave been or will be disclosed, and any of which he or she becomesaware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet EngineeringTask Force (IETF), its areas, and its working groups. Note thatother groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six monthsand may be updated, replaced, or obsoleted by other documents at anytime. It is inappropriate to use Internet-Drafts as referencematerial or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed athttp://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed athttp://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 5, 2007.

Copyright Notice

Copyright (C) The IETF Trust (2007).

Fajardo, et al. Expires July 5, 2007 [Page 1]


2/66

Internet-Draft Diameter Interoperability Test Suite January 2007

Abstract

This document describes a collection of test cases to be used for

Diameter base protocol and Diameter applications interoperabilitytesting.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 32. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 43. Diameter Base Protocol Test Suite . . . . . . . . . . . . . . 53.1. Required . . . . . . . . . . . . . . . . . . . . . . . . . 53.1.1. Connectivity and Peering . . . . . . . . . . . . . . . 53.1.2. Routing . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.3. Relay Agent . . . . . . . . . . . . . . . . . . . . . 113.1.4. Redirection Agent . . . . . . . . . . . . . . . . . . 123.2. Optional . . . . . . . . . . . . . . . . . . . . . . . . . 123.2.1. General Statemachine . . . . . . . . . . . . . . . . . 123.2.2. Dynamic Peer Discovery . . . . . . . . . . . . . . . . 12

4. Diameter Applications . . . . . . . . . . . . . . . . . . . . 144.1. Common Test Suite . . . . . . . . . . . . . . . . . . . . 144.1.1. Required . . . . . . . . . . . . . . . . . . . . . . . 14

4.2. Diameter Credit Control Test Suite . . . . . . . . . . . . 174.2.1. Required . . . . . . . . . . . . . . . . . . . . . . . 184.2.2. Optional . . . . . . . . . . . . . . . . . . . . . . . 24

4.3. Diameter SIP Test Suite . . . . . . . . . . . . . . . . . 274.3.1. Required . . . . . . . . . . . . . . . . . . . . . . . 28

4.4. 3GPP Interface Test Suite . . . . . . . . . . . . . . . . 364.4.1. Diameter Cx . . . . . . . . . . . . . . . . . . . . . 364.4.2. Diameter Sh . . . . . . . . . . . . . . . . . . . . . 394.4.3. Diameter Rf . . . . . . . . . . . . . . . . . . . . . 41

4.5. Diameter EAP Test Suite . . . . . . . . . . . . . . . . . 434.5.1. Required . . . . . . . . . . . . . . . . . . . . . . . 434.5.2. Optional Authorization/Accounting Tests . . . . . . . 45

4.6. Diameter NASREQ Test Suite . . . . . . . . . . . . . . . . 454.6.1. Required . . . . . . . . . . . . . . . . . . . . . . . 464.6.2. Optional . . . . . . . . . . . . . . . . . . . . . . . 49

4.7. Diameter MIP Test Suite . . . . . . . . . . . . . . . . . 494.7.1. Generic MIP Test Scenarios . . . . . . . . . . . . . . 494.7.2. Required . . . . . . . . . . . . . . . . . . . . . . . 504.7.3. Optional . . . . . . . . . . . . . . . . . . . . . . . 55

5. Security Considerations . . . . . . . . . . . . . . . . . . . 606. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 617. Normative References . . . . . . . . . . . . . . . . . . . . . 62Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64Intellectual Property and Copyright Statements . . . . . . . . . . 65



3/66


1. Introduction

The document is meant to aid in the identifying the functional test

cases of a Diameter implementation. The Diameter interoperabilitytest suites are categorized by different applications or extensions.Each category is further subdivided into required and optionalfunctionality. The required functionality is the baseline capabilitythat an implementation must support to allow basic interoperabilityfor that category. Optional functionality covers features that notall implementations support or may wish to test. The following is alist of Diameter applications that are currently categorized in thisdocument:

1. Diameter Base Protocol [RFC3588]

2. Diameter Credit Control

3. Diameter SIP

4. 3GPP Interfaces

5. Diameter EAP

6. Diameter NASREQ

7. Diameter MIP

Note that some of the test cases can overlap. For example, a NASREQ

test case would normally encompass base protocol routing. In suchcases, it is implied that multiple test scenario can be covered bysome test.

At its current state, this document provides only a collection oftest cases designed for interoperability. Test plans may be includedin future revisions of this work or maybe provided in some otherdocument.



4/66


2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in thisdocument are to be interpreted as described in [RFC2119].

Within this document the terms defined in [RFC2119] refers to thefunctionality that have to be provided by an implementation for theusage within this interoperability test event.



5/66


3. Diameter Base Protocol Test Suite

All implementation must conform to [RFC3588].

3.1. Required

3.1.1. Connectivity and Peering

Implementations must conform to Section 5.6 of [RFC3588]. Typicaltest topology for statemachine test uses peer pairs as shown inFigure 1. It is left to the testers if one-to-many or many-to-oneconnections will be performed to test scalability and loading. Thetest cases described below references Figure 1 below.

+--------+ +--------+

Vendor AVendor B+--------+ +--------+

Figure 1: Peer Statemachine Test Topology

3.1.1.1. Capabilities Negotiation

Implementations must be able to perform at least the followingbehavior described in Section 5.3 of [RFC3588].

o Positive test for establishment of connection with test pairsadvertising support for common application ids (auth, accountingor vendor). Vendor A initiates transport connection to B and

trigger the process.

o Positive test for establishment of connection with test pairs ofwhich one of them is advertising support for only relay app and noother app is in common.

o Positive test for establishment of connection advertising therelay app in auth app id, acct app id & VSA.

o Positive test for establishment of connection with test pairsadvertising support common transport security, specifically theuse of TLS and/or IPSec. It is left up to the participants togenerate appropriate keys and certificates specific for this test.Vendor A initiates transport connection to B and trigger theprocess and advertised proper Inband-Security support.

o Positive test for DWR/DWA exchange after connection isestablished. Vendor A and B both exchange watchdogs as perSection 3.4.1 of [RFC3539].



6/66


o Negative test where DIAMETER_NO_COMMON_APPLICATION is returned bya peer with no common application id (auth, accounting or vendor).Intentionally configure vendor A not to advertise any

applications, different applications than B or vendor id's knownonly to A.

o Negative test where DIAMETER_NO_COMMON_SECURITY is returned by apeer with no common application id. Intentionally configurevendor A to send Inband-Security-AVP with value 1 (TLS) that Bwill not support.

o Negative test for unknown peers. Use of DIAMETER_UNKNOWN_PEER orsilent discard to disconnect unknown peers. Intentionallyconfigure vendor A to send an origin-host that is not in B's peertable.

o Negative test case for TLS handshake failure. In the case wherethe negotiated Inband-Security involves subsequent TLSnegotiation, participants can simulate a TLS handshake failure(i.e. via invalid certificates, TLS/SSL version mis-match etc)that must result in the peers being disconnected.

Verification of each test result can be done manually.

3.1.1.2. Election

This test case refers to Section 5.6.4 of [RFC3588]. Responders mustbe able to resolve contention with initiator peers.

o Positive test for establishment of connection with responderhaving higher identity than initiator. Vendor A initiatesconnection followed by B doing the same a few milliseconds later.Vendor A having a higher identity should close B's connectionattempt.

o Positive test for disconnection with initiator having loweridentity than the responder. Vendor A initiates a connectionfollowed by B doing the same a few milliseconds later. Vendor Ahaving a lower identity should close its initial connectionattempt.

o Negative test for disconnection when initiator and responder haveequal identity. Vendor A and B will advertise the equal identity.Verify that both peers closed the connection.

Verification of test results can be done manually.



7/66


3.1.1.3. Disconnection

Implementations must conform to Section 5.6.4 of [RFC3588] and

Section 3.4.1 of [RFC3539]. Peers must be able to quickly determinedisconnection events. Verification of test results can be donemanually.

o Positive test for peer disconnection using DPR/DPA exchange.Vendor A initiates shutdown while connected to B. Implementationsbehavior may vary depending on disconnection cause such as aneventual connection retry if a disconnection cause of REBOOTING isreceived.

o Positive test for detecting disconnection via system level events(i.e., transport resets, socket error, system link-down signals,

etc). Implementation must be able to initiate failover procedure.Implementation should also attempt re-connection with lost peer.Hard disconnection of vendor A and B's wired link can be done tosimulate this scenario.

o Positive test for detecting disconnection via watchdog timeout.If there is no activity after a watchdog timer expires withpending request then the peer becomes suspect and implementationmust be able to initiate failover procedure. [RFC3539] suggest aminimum watchdog timeout at 6 sec. Vendor B can setup a transportlevel filter to silently drop AAA traffic from B to simulateunresponsiveness of B.

o Positive test for resetting connection after at least two(2)watchdog has expired. If a connection is already suspect, thepeers must reset the connection. Vendor A or B can setup atransport level filter to silently drop AAA traffic and simulateunresponsiveness of both peers.

Verification of test results can be done manually.

3.1.1.4. Re-Connection Algorithms

Implementations must conform to Section 2.1 of [RFC3588]. Although avendor can implement other algorithms and policies than thoseproposed in [RFC3588], a default reconnection scheme must beimplemented.

o Positive test for peer re-connection after disconnection has beendetected. The link between vendor A and B is temporarilydisconnected until such time that disconnection is detected byboth peers. The link can then be restored to test the re-connection behavior of both peers. Verify that at least three(3)



8/66


watchdog exchanges occur before both peers are no longer suspect.

3.1.1.5. Failover and Failback

Implementations must conform to Section 5.4.5 of [RFC3588] andSection 3.4.2 of [RFC3539]. Testing failover mechanism requiresalternate peer connections. A basic ring topology to test failoverand failback is shown in Figure 2 where vendor A has a primary routeto vendor C via vendor B and secondary route via vendor D. The samesymmetry is applied to all other vendors. As an example, vendor Chas a symmetric topology where D is its primary connection and B isits secondary. This allows the same tests to be performed for allvendors. For testing failover on vendor A and B, link0 can bedisconnected. For vendor C and D, link2 can be disconnected and soon.

+---------+Vendor B +---------+/ \

link0 link3+---------+/ \+---------+Vendor A Vendor C +---------+\ /+---------+

link1 link2\+---------+/Vendor D +---------+

Figure 2: Failover Test Topology

The enumerated test cases refers only to vendor A but can be appliedto any of the vendor implementations in Figure 2. Conditions for apositive test requires that realm routes to C is present in A andhost routing is not used. Initial traffic should flow from A to Cvia B (as the primary peer of A).

o Positive test for failover when link0 is disconnected. Vendor Ashould have pending requests queued prior to disconnection. Upondisconnection (see Section 3.1.1.3), verify that the pendingrequest with T-flag set has been forwarded to C via D.

o Positive test for failover by using device watchdog as a means oftriggering link0 disconnection. Vendor A should have pendingrequests queued prior to disconnection. Upon disconnection (seeSection 3.1.1.3), verify that the pending request with T-flag sethas been forwarded to C via D.



9/66


o Positive test for failback when link0 is restored and re-connection succeeds (See Section 3.1.1.4). Verify that newrequest message is routed back to B.

o Negative test to generate DIAMETER_UNABLE_TO_DELIVER on answermessage from B to A when Destination-Host is set to C. This can besimulated when link3 is disconnected and Vendor C is not reachablefrom Vendor. Note that alternate path via Vendor D should not beused.

o Negative test to detect duplicate messages on C. Vendor B candisable watchdog processing but still allow request messageforwarding. This makes B a suspect peer from A and triggerfailover procedure. Forwarding of queue request will then be donethrough D. However, the original request messages would have

reached C via B.

3.1.2. Routing

Implementation must conform to Section 6 of [RFC3588]. A basictopology to test Diameter routing is shown in Figure 3 where vendor Aand vendor B can deploy two(2) Diameter peers to test host, realm andanswer message routing. Vendor A1 and A2 shares the same realm(realmA). Vendor B1 and B2 share a different realm (realmB). Testbetween both realms are symmetric although the description focusesmostly to vendor A for editorial reasons. The topology is alsodesigned so that multi-hop forwarding, message loopback and agentconfiguration can be tested. Note that some test cases in this

section require link disconnection overlap with the test casesoutline in Section 3.1.1.3. An implementation experiencing linkdisconnection must update its peer and realm route table accordingly.Verification for usage of proper routing AVPs in Section 6.7 of[RFC3588] must be done when testing routing functionality.

+---------+Vendor A2 (realmA)+---------+/ \

(realmA) link1 link2+---------+/ \+---------+Vendor A1 link0 Vendor B2 (realmB)+---------+\ /+---------+

link4 link3\+---------+/Vendor B1+---------+(realmB)



10/66


Figure 3: Routing Test Topology

3.1.2.1. Peer Based Request Routing

Implementation must conform to Section 6.1.5 of [RFC3588]. In orderto perform the test cases the peer requesting the AAA routing musthave the destination-host and the destination-realm present in therequest message.

o Positive test for request forwarding from originator. Requestmessages generated from A1 should reach B2 via B1 if destination-host of the request is B2 and destination-realm is realmB and alllinks are up. A1 must perform realm routing to reach B1 and B1must perform forwarding to reach B2. Verification of routing canbe done manually if message has reached B2 via link4 and link3.

o Positive test for multi-hop request forwarding. Request messagesgenerated from A1 with destination-host B2 and destination-realmrealmB should reach B2 via A2 and B1 if all links are up exceptfor link4 and link2. A1 and A2 must perform realm routing whileB1 performs forwarding. A1 and A2 must be able to route therequest message to B1 even if it does not have B2 in its peertable. Verification of routing can be done manually if messagehas reached B2 via link1, link0 and link3.

o Negative test for request forwarding. If a request messagegenerated from A1 has a destination-host B2 and destination-realmrealmB with all links up except for link0, link2 and link4 then A2

must send an answer message to A1 with result-codeDIAMETER_UNABLE_TO_DELIVER. Verification can be done manually ifthe answer message has reached A1 with E-bit set.

3.1.2.2. Realm Based Routing

Implementation must conform to Section 6.1 and Section 6.1.6 of[RFC3588]. Test cases for realm-based request routing must havedestination-realm present but must not have destination-host presentin the request message. Note that there is some test overlap withthe test cases defined in Section 3.1.2.1.

o Positive test for request routing from originator. Requestmessages generated from A1 should reach B2 via B1 if thedestination-realm is realmB and all links are up. A1 and B1 mustperform realm routing to reach B2. The request must have an id(app, auth or vendor) that B1 must route and B2 must processlocally. Verification of routing can be done manually if messagehas reached B2 via link4 and link3.



11/66


o Positive test for multi-hop request routing. Request messagesgenerated from A1 with destination-realm realmB should reach B2via A2 and B1 if all links are up except for link4 and link2. A1,

A2 and B1 must perform realm routing. The request must have an id(app, auth or vendor) that A1, A2 and B1 must route and B2 mustprocess locally. Verification of routing can be done manually ifmessage has reached B2 via link1, link0 and link3.

o Negative test for request routing. If a request message generatedfrom A1 has a destination-realm realmB with all links up exceptfor link0, link2 and link4 then A2 must send an answer message toA1 with result-code DIAMETER_UNABLE_TO_DELIVER. Verification canbe done manually if the answer message has reached A1 with E-bitset.

3.1.2.3. Answer Message Routing

Implementations must conform to Section 6.2 of [RFC3588]. Answerrouting can be verified using test cases in Section 3.1.2.1 andSection 3.1.2.2.

3.1.2.4. Loop Detection

Implementation must conform to Section 6.1.3 of [RFC3588]. Allforwarders must verify that their local identity is not present inthe route-record of the request. If it is present, the forwardermust send an answer with result-code DIAMETER_LOOP_DETECTED. If itis not present, implementations must also insert route-records into

the request messages.

o Positive test for loop detection can be done if a requestoriginating from A1 has a destination-realm realmA and A1 isconfigure to route request for realmA to A2, A2 will route requestfor realmA to B1 and B1 will route request back to A1. Though A1originated the request, it must be able to send an answer messagewith the E-bit set through the request path.

3.1.3. Relay Agent

Implementations must conform to Section 2.8.1, 6.1.8 and 6.2.2 of[RFC3588]. The topology shown in Figure 3 is also used for testingrelay agent functionality. Note that an overlap exists with the testcase described in Section 3.1.2 when testing relay agents and thosetest cases should be used here as well. Verification for usage ofrouting AVPs in Section 6.7 of [RFC3588] must be done when testingagent functionality. Testing of proxy agents that keep vendorspecific state, such as proxy-info, proxy-state, proxy-host, is outof scope of this document and can be done in parallel or independent



12/66


of the test cases enumerated here.

3.1.4. Redirection Agent

Implementation must conform to Section 6.1.7 of [RFC3588].Verification can be made by inspecting the redirect answer messagewhether the result-code is set to DIAMETER_REDIRECT_INDICATION withthe E-bit enabled and redirect-hosts added.

o Positive test for redirection. Request messages generated from A1should reach B2 via B1 using redirect from A2 and all links are upexcept link0 and link2. A1 must be configured to forward requestmessage for realmB/B2 via A2. A2 must be configured to act as aredirect agent and signal a redirect indication to A1 to use B1instead. Verification of redirection can be done manually if

messages have reached B2 and re-direct indication was processed byA1.

3.2. Optional

Implementations must conform to Section 5.6 of [RFC3588]. Testtopology uses Figure 1. This section describes optional test cases.

3.2.1. General Statemachine

Implementations must conform to Section 5.6.1 of [RFC3588]. The sametopology in Figure 1 can be used to perform the test scenarios listedin this section.

o Negative test for non-CEA message received during CER/CEAexchange. Silent discard and peer disconnection. Vendor B caninitiate a non Diameter server listening on a Diameter definedport number to simulate unrecognizable messages from vendor B. Orthe AAA peer of vendor B is modified to generate a non-CEA messageonce a transport connection setup has been initiated. Verify thatvendor A has closed the connection.

3.2.2. Dynamic Peer Discovery

Implementations must conform to Section 5.3 of [RFC3588].Implementations must be able to perform at least the followingbehavior.

o Positive test for establishment of connection with unknown peer.The topology for this test is Figure 1. Test case is dependent onimplementation accepting dynamic peer table updates. In suchcase, lifetime of new peer entry should be check against lifetimeof connection. Intentionally configure vendor A to send an



13/66


origin-host that is not in B's peer table. Verification of resultcan be done manually by inspecting the resulting peer table of B.

o Positive test after redirection (Section 3.1.4). The topology forthis test is Figure 3. Additional verification can be done ifSection 3.1.4 is successful. Redirect-host routes can be cachedby an implementation as a new route entry. Same scenarios as inthe redirect test case except subsequent request messages will beforwarded to B1 by A1. Verify that only the initial messageresults in a redirect process.



14/66


4. Diameter Applications

4.1. Common Test Suite

4.1.1. Required

4.1.1.1. Authentication and/or Authorization

Applications intending to use authentication and/or authorizationmust conform to the statemachine specification in Section 8.1 of[RFC3588]. Since these test cases are session level, any topologycan be used by a pair of vendors performing interoperability. Theminimum topology will be based on Figure 1. Note that majority ofthese test are performed as part of other Diameter application testcases. Therefore, implementations must be able to comply with these

common cases.

4.1.1.1.1. Stateful Session


o Positive test for proper stateful session establishment. Verifythat auth-session-state with STATE_MAINTAINED is enforced in theclient session. Verify that auth-session-lifetime and auth-session-grace-period are negotiated properly and enforced betweenvendor implementations. Must conform to Section 8.4 of [RFC3588].

o Positive test for proper stateful session re-auth. Verify serverinitiated RAR/RAA exchange occurs on auth-lifetime and auth-graceperiod expiration. Must conform to Section 8.3 of [RFC3588].

o Positive test for proper stateful session disconnection. Verifyclient initiated STR/STA exchange occurs for auth failure andsession timeout. Verify values of auth-lifetime and auth-graceperiod against session-lifetime according to Section 8.9 of[RFC3588]. Verify application id value carried by the STR/STAmessage is that of the target application.

o Positive test for proper stateful session disconnection. Verifyserver initiated ASR/ASA exchange occurs when server decides todiscontinue service. Implementations that allow for hard sessiontermination should be able to perform these tests. Must conformto Section 8.5 of [RFC3588]. Verify application id value carriedby the STR/STA message is that of the target application.



15/66


o Positive test for proper stateful session disconnection usingorigin-state-id. Verify a vendor implementation can at leastcleanup stateful sessions once it has received a value of origin-

state-id greater than a previously known value from the sameissuer. Verification can be done in the absence of an STR/STAexchange. Must conform to Section 8.6 of [RFC3588].

4.1.1.1.2. Stateless Session


o Positive test for proper stateless session establishment. Verifythat auth-session-state negotiation between vendor implementation

with NO_STATE_MAINTAINED is enforced in the client session.

o Positive test for proper stateless session disconnection. Verifythat session-lifetime is enforced in the client session.

4.1.1.2. Accounting

Applications intending to use Diameter accounting may conform toSection 8.2 and 9 of [RFC3588] if the particular application has notalready defined its own statemachine. Since these test cases arealso session level, any topology can be used by a pair of vendorsperforming interoperability. The minimum topology will be based onFigure 1. Note that majority of these test are performed as part of

other Diameter application test cases. Therefore, implementationsmust be able to comply with these common cases.

4.1.1.2.1. Client Session

Implementations must conform to Section 8.2 of [RFC3588].Implementations must be able to perform at least the followingbehavior. Verification of test results for these cases can be donemanually.

o Positive test for proper client session establishment. Verifythat sub-session id is supported and that the client can supportevent record generation at the least. Verify that the clientshould at least be able to support DELIVER_AND_GRANT. Testentities must be able to configure their server implementation tosend this avp. Must conform to Section 9.4 and 9.8.7 of[RFC3588].

o Positive test for proper client session termination. Verify thatsession termination causes transmission of stop record events if



16/66


any and that all records generated are accounted for. Validationof accounting records can be Diameter application specific and isleft to the tester to confirm.

o Negative test for client session when server reports a failure.Verify that client session can cope with failed accounting startsor server storage failure and act accordingly based on Section 8.2[RFC3588]. Behavior of the client can be policy andimplementation specific and is left to the tester to confirm.Failed accounting starts and storage failures can be simulated bymis-configuration of the server test peer.

o Negative test for client session when connectivity fails. Verifythat client session can cope with connectivity failure and actaccordingly based on Section 9.4 [RFC3588]. The test can overlap

with Section 3.1.1.3 and Section 3.1.1.5.

4.1.1.2.2. Server Session

Implementations must conform to Section 8.2 and 9 of [RFC3588].Implementations must be able to perform at least the followingbehavior. Verification of test results for these cases can be donemanually. Since server sessions must support record storage it isleft to the testers to validate storage (Section 9.5 [RFC3588]),sequencing and co-relation (Section 9.6 [RFC3588]) of records.

o Positive test for proper server session establishment. Verifythat sub-session id is supported and that the server enforces

record generation on the client based on accounting-record-type.Verify that supervision timer is enforced when using statefulsessions. Must conform to Section 9.5 of [RFC3588].

o Positive test for proper server session termination. Verify thatexpiration of supervision timer in a stateful session terminatesboth client and server session on any vendor implementation.

o Negative test for server session when local storage failureoccurs. Verify that server can notify client of its state and actaccordingly based on Section 8.2 of [RFC3588]. Validation ispolicy and implementation specific and is left to the tester toconfirm. Storage failure can be simulated by mis-configuration onthe server test peer. This test is mostly a local validation butit can be used in parallel with Section 4.1.1.2.1.



17/66


4.2. Diameter Credit Control Test Suite

Vendors that support the Diameter Credit Control application must

conform to [RFC4006]. The typical test topology for credit controlauthorization is shown in Figure 4. A user typically requests aservice and thereby triggers the CC Client to contact the CC Serverrequesting the CC Server to verify the user's credit standing priorto service delivery. Since the test cases cover only CC Client andCC Server interoperability, it is left to the tester to verifycorrectness of the authentication method executed between the userand the AAA server that is used as a pre-requisite for theauthorization of the user by the CC server. Additionally, theinteraction between the User's host and the CC Client that is used totrigger the interaction between the CC client and the CC Server isoutside the scope of this document.

+--------+ +-----------+ +------------+ User CC Client AAA Server +--------+ +-----^-----+ +-----^------+

+-----V-----++----------> CC Server

+-----------+

Legend:User - Simulated end userCC Client - Vendor A Diam CCA client

CC Server - Vendor B Diam CCA server

Figure 4: Diameter CC Test Topology

A second test topology can exist for testing Diameter/RADIUStranslation agent as specified in Section 11 of [RFC4006]. Thistopology is available for vendors implementing a prepaid RADIUStranslation agent. Since the test cases cover interoperabilityscenarios, validation must be done between the Service Element andthe AAA Server/CC Client translation agent. As with Figure 4, it isleft to the tester to verify correctness of the access method betweenUser and Service Element. The test cases involving Figure 4 are alsorelevant to validating AAA Server/CC Client and CC Server and shouldbe used in this topology as well.



18/66


+------+ +---------+ +---------------+ User Service AAA Server +------+ Element +---------+

+---------+ CC Client +---------+ +--+----^----+--+

+-----V-----+ CC Server +-----------+

Legend:User - Simulated userService Element - Simulated or vendor RADIUS prepaid

client application client

AAA Server/CC Client - Vendor A Diameter/RADIUStranslation agentCC Server - Vendor B Diameter CC Server

Figure 5: Translation Gateway Test Topology

4.2.1. Required

Either test topology Figure 4 or Figure 5 can be used for thesecases.

4.2.1.1. Session Based Credit Control First Interrogation

Implementations must conform to Section 5.2 of [RFC4006]. Thissection addresses the initial credit control interactions between aCC Client and a CC Server, i.e., CC-Request-Type is set to the valueINITIAL_REQUEST in the CCR message. There are many parameters onwhich a service can be granted a credit authorization but theobjective of these tests is to demonstrate for session based servicesthe initial credit authorization handling procedures are supported.

o Positive tests for credit authorization for a session basedservice with the Requested-Service-Unit AVP NOT present. Theservice quota profiles should be agreed between the vendors. Thetest should be repeated to verify support for the following quotatypes:

* Time based services.

* Volume (Total, Input, Output Octets) based services.

* Services with quota using service specific units.



19/66


* Money based services.

* Services with several unit types granted.

o Positive tests for credit authorization for a session basedservice with the Requested-Service-Unit AVP being present. Theservice quota profiles should be agreed between the vendors. Thetest should be repeated to verify support for the following quotatypes:






o Positive test for the CC Server's ability to support the grantingalternative amounts of credit to the values requested in theRequested-Service-Unit AVP of the CCR message.

o Negative test for first interrogation of session based serviceswhen the CC Server could not process the initial CCR message.Verify support for the graceful handling of events such as unknownend user, account being empty, invalid rating input, or errors

defined in [RFC3588].

o Negative test for first interrogation of session based serviceswhen the CC Client could not process the initial CCA message.Verify support for the graceful handling of events such asunsupported unit types.

o Negative test for first interrogation of session based serviceswhen the CC Server includes a Final-Unit-Indication AVP withFinal-Unit-Action REDIRECT or RESTRICT_ACCESS in the Credit-Control-Answer or in the AA answer. Verify that CC Client behavesas directed.

4.2.1.2. Session Based Credit Control Intermediate Interrogation

Implementations must conform to Section 5.3 of [RFC4006]. Thissection addresses the intermediate credit control interactionsbetween a CC Client and a CC Server, i.e., CC-Request-Type is set tothe value UPDATE_REQUEST in the CCR message. There are manyparameters on which a service can be reauthorized credit but the



20/66


objective of these tests is to demonstrate for session based servicesthe intermediate credit authorization handling procedures aresupported.

o Positive tests for credit reauthorization for a session basedservice with the Requested-Service-Unit AVP NOT present. TheEvent-Timestamp AVP must be used to mark the time thereauthorization was triggered and the Used-Service-Unit AVPcontains the amount of used service units since the service wasactivated or last interim. The service quota profiles should beagreed between the vendors. The test should be repeated to verifysupport for the following quota types:






o Positive tests for credit authorization for a session basedservice with the Requested-Service-Unit AVP is present. TheEvent-Timestamp AVP must be used to mark the time thereauthorization was triggered and the Used-Service-Unit AVPcontains the amount of used service units since the service was

activated or last interim. The service quota profiles should beagreed between the vendors. The test should be repeated to verifysupport for the following quota types:






o Positive test for the CC Server's ability to support the grantingalternative amounts of credit to the values requested in theRequested-Service-Unit AVP of the CCR message.

o Negative test for intermediate interrogation for session basedservices when the CC Server could not process the update CCR



21/66


message. Verify support for the graceful handling of events suchas subscription ID missing, account being empty, invalid ratinginput, or errors defined in [RFC3588].

o Negative test for intermediate interrogation for session basedservices when the CC Client could not process the update CCAmessage. Verify support for the graceful handling of events suchas unsupported unit types.

4.2.1.3. Session Based Credit Control Final Interrogation

Implementations must conform to Section 5.4 of [RFC4006]. Thissection addresses the final credit control interactions between acredit control application client and server i.e., CC-Request-Type isset 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 theinterrogation was triggered and the Used-Service-Unit AVP containsthe amount of used service units since the service was activatedor last interim. The CC Server must verify support for refundingthe unused reserved units and for charging the used monetaryamount to the end user's account.

4.2.1.4. Sub Sessions

Implementations must conform to Section 5.1.2 of [RFC4006].

o Positive test for multiple services within a session. Verifyvendor support for interrogations when the Multiple-Services-Credit-Control AVP present and the Requested-Service-Unit AVP isnot present.

o Positive test for multiple services within a session. Verifyvendor support for interrogations when the Multiple-Services-Credit-Control AVP present and the Requested-Service-Unit AVP ispresent.

o Positive test for credit pool support. Verify that a vendor's CCServer implementation is capable of supporting credit pools forservices by including a G-S-U-Reference within a Granted-Service-Unit AVP in a CCA message. An example scenario is detailed inAppendix A (Flow IX) of [RFC4006].

o Positive test for rating group support. Verify that a vendor's CCClient implementation is capable of associating a service with arating group by including a Rating-Group AVP in an interrogation.An example scenario is detailed in Appendix A (Flow IX) of



22/66


[RFC4006].

o Negative test for multiple services within a session. Verify that

a CC Server not supporting multiple services within a sessiontreats the Multiple-Services-Indicator AVP and any receivedMultiple-Services-Credit-Control AVPs as invalid AVPs.

o Negative test for invalid/insufficient rating input. Verify thata CC Server receiving invalid rating input (e.g., unknown ratinggroup) shall inform the CC Client by including a result code ofDIAMETER_RATING_FAILED in the Multiple-Services-Credit-ControlAVP.

4.2.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 isset to TERMINATE. Verify that the CC Client terminates the enduser's session if it does not receive a CCA message within the Txtimer.

o Test failure behavior when Credit-Control-Failure-Handling AVP isset to CONTINUE. Verify that when CC messages cannot be deliveredto CC Server because of transport or temporary failures that theCC Client resends the request to a backup CC Server assuming CCfailover is supported or else the service should be granted by theCC Client.

o Test failure behavior when Credit-Control-Failure-Handling AVP isset to RETRY_AND_TERMINATE. Verify that when CC messages cannotbe delivered to the CC Server because of transport or temporaryfailures that the CC Client resends the request to a backup CCServer assuming CC failover is supported or else the serviceshould not be granted by the CC Client.

4.2.1.6. Service Price Enquiry

Implementations must conform to Section 6.1 of [RFC4006]. This testuses an event based credit control interaction between the CC Clientand the CC Server (i.e., CC-Request-Type is set to the valueEVENT_REQUEST in the CCR message). The test is invoked by the CCClient including the Service-Identifier and the Requested-Action AVPset to PRICE_ENQUIRY in the CCR message. An example message flow isshown in Appendix A (Flow V) of [RFC4006].

o Positive test for a service price enquiry. Verify that the CCServer returns the estimated cost of the service to the CC Client



23/66


in the in the Cost-Information AVP in the CCA message.

4.2.1.7. Balance Check

Implementations must conform to Section 6.2 of [RFC4006]. This testuses an event based credit control interaction between the CC Clientand CC Server (i.e., CC-Request-Type is set to the valueEVENT_REQUEST in the CCR message). The test is invoked by the CCClient including the Service-Identifier and the Requested-Action AVPset to CHECK_BALANCE in the CCR message. An example scenario isdetailed in Appendix A (Flow IV) of [RFC4006].

o Positive test for a check balance enquiry. Verify that the CCServer returns the credit status for the subscriber to access theservice to the CC Client in the in the Check-Balance-Result AVP in

the CCA message.

4.2.1.8. Direct Debiting

Implementations must conform to Section 6.3 of [RFC4006]. This testuses an event based credit control interaction between the CC Clientand CC Server (i.e., CC-Request-Type is set to the valueEVENT_REQUEST in the CCR message). The test is invoked by the CCClient including the Service-Identifier and the Requested-Action AVPset to DIRECT_DEBITING in the CCR message. An example message flowis 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 ratesthe service event and deducts the corresponding monetary amountfrom the end user's account. Verify that the granted serviceunits can be of type time, volume, service specific, or money.

o Positive test for a direct debiting enquiry with the CC Clientincluding the requested units. Verify that the CC Server justdeducts the corresponding monetary amount from the end user'saccount without performing rating. Verify that the grantedservice units can be of type time, volume, service specific, ormoney.

o Positive test for a direct debiting enquiry where the CC Serverdetermines that no credit-control is required for the service(e.g., free service).



24/66


4.2.1.9. Refunds

Implementations must conform to Section 6.4 of [RFC4006]. This test

uses an event based credit control interaction between the CC Clientand CC Server (i.e., CC-Request-Type is set to the valueEVENT_REQUEST in the CCR message). The test is invoked by the CCClient including the Requested-Action AVP set to REFUND_ACCOUNT inthe 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 includingthe requested units. Verify that the CC Server performs therating required prior to refunding the subscriber's accountbalance.

o Positive test for a refund request with the CC Client includingthe requested units. Verify that the CC Server refunds thesubscriber's account balance with the requested monetary amount.

4.2.1.10. Event Based Credit Control Failure Procedures


o Test that CC Client forwards requests of type price enquiry orbalance check to an alternative CC Server if a transport failureis 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 therequested 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 CCClient behaves as described in section 6.5 of [RFC4006] when therequested actions is direct debiting and the Direct-Debiting-Failure-Handling AVP is set to CONTINUE.

4.2.2. Optional

Either test topology Figure 4 or Figure 5 can be used for thesecases.

4.2.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 CCServer can send a CCA message including a Tariff-Time-Change AVP.



25/66


Verify that the CC Client itemizes the used units in respect tothe tariff time change when reporting service usage.

o Negative test for tariff change support. Verify that the CCClient terminates the credit control session if it does notsupport tariff time changes and it received a CCA messageincluding a Tariff-Time-Change AVP.

4.2.2.2. Graceful Service Termination

This section addresses the graceful termination features of a CCServer in accordance with Section 5.6 of [RFC4006] utilizing theFinal-Unit-Indication AVP.

o Positive test for terminate action. Verify that a CC Client

terminates the service when the final units have been consumed andit 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 Serversupports the inclusion of a Redirect-Server AVP when the Final-Unit-Action AVP is set with a value of REDIRECT. Verify that theend user is redirected by the CC Client to the appropriateredirect server when the final units have been consumed. The CCClient must send a CCR intermediate message specifying the usedunits and to report that the specified action has started.

o Positive test for restriction filter rules. Verify that a CCServer supports the inclusion of Restriction-Filter-Rule AVPs whenthe Final-Unit-Action AVP is set with a value of REDIRECT orRESTRICT. Verify that the end user packets not matching therestriction filter are dropped by the CC Client when the finalunits have been consumed. The CC Client must send a CCRintermediate message specifying the used units and to report thatthe specified action has started.

o Negative test for default final unit handling. Verify that a CCClient terminates the service when the final units have beenconsumed and it has received an unsupported Final-Unit-Actionvalue. The CC Client must send a CCR final message including aCC-Request-Type AVP set to the value TERMINATION_REQUEST.

4.2.2.3. Validity Time

o Positive test for Validity-Time AVP support. Verify that the CCServer is capable of including a validity time with grantedservice units in a CCA message. Verify the CC Client generates a



26/66


CC update request and reports the used quota to the CC server whenthe validity timer expires.

o Positive test for Validity-Time AVP support with multiple serviceswithin a session. Verify that the CC Server is capable ofincluding a validity time in a Multiple-Services-Credit-ControlAVP in a CCA message. Verify the CC Client generates a CC updaterequest and reports the used quota to the CC server when thevalidity timer expires.

4.2.2.4. Server Initiated Credit Reauthorization


o Positive test for CC Server initiated reauthorization of all

services in a session. Verify that the CC Client follows the RAAand CCR Update procedure defined in Section 5.5 of [RFC4006].

o Positive test for CC Server initiated reauthorization for a creditpool in a session. Verify that the CC Server includes the G-S-U-Pool-Identifier AVP in the RAR message. Verify that the CC Clientfollows the RAA and CCR Update procedure defined in Section 5.5 of[RFC4006].

o Positive test for CC Server initiated reauthorization for a ratinggroup in a session. Verify that the CC Server includes theRating-Group AVP in the RAR message. Verify that the CC Clientfollows the RAA and CCR Update procedure defined in Section 5.5 of

[RFC4006].

o Positive test for CC Server initiated reauthorization for aspecific service in a session. Verify that the CC Server includesthe Service-Identifier AVP in the RAR message. Verify that the CCClient follows the RAA and CCR Update procedure defined in Section5.5 of [RFC4006].

o Positive test RAR-CCR Collision handling support. Verify that theCC Client sends an RAA with a DIAMETER_SUCCESS result but does notinitiate a CCR. Verify that the CC Server processes the CCRmessage as if it was generate in response to the RAR message.

o Positive test for CC Server initiated reauthorization for anactive sub session. Verify that the CC Server includes the CC-Sub-Session-Id AVP in the RAR message. Verify that the CC Clientfollows the RAA and CCR Update procedures defined in Section 5.5of [RFC4006].



27/66


4.3. Diameter SIP Test Suite

Implementations that deploy SIP [RFC3261] services and use Diameter

for authentication, authorization, signaling, profile distribution,location services etc must conform to[I-D.ietf-aaa-diameter-sip-app]. For the purpose of Diameter SIP,each test nodes exercises only a specific set of functionalitydepending on their role in the SIP architecture. Since this SIParchitecture is synonymous to Diameter Cx [TS29.228], the scenariosenumerated in this section applies there as well. Therefore, therecan be a multitude of deployment scenarios. The test topologyfollows the general architecture in Figure 1 of[I-D.ietf-aaa-diameter-sip-app] in order to exercise the majority ofDiameter SIP features. For testing Diameter Cx, the mapping of thetest entities against this figure is described in Section 4.4.1.

Configuration of SIP user agents and SIP servers in all test casesare implementation specific and it is left to the tester to verifytheir correctness.



28/66


+--------+UAR/UAA +--->DiameterDiameter


29/66


o Positive test with Diameter server performing authentication.Assuming proper configuration of all test entities, SIP REGISTERrequest for user1@realmB should succeed with vendor D as the

allocated SIP server for the registration. The resulting messageflows should follow Figure 2 of [I-D.ietf-aaa-diameter-sip-app].For Diameter Cx, Section A.4.1 of [TS29.228] describes a similarscenario. UAR/UAA exchanges must indicate to vendor A that D isthe preferred SIP server to handle user1@realmB registration.Verify that DIAMETER_MULTI_ROUND_AUTH is followed by vendor A andD and that vendor A generates SIP unauthorized responseaccordingly. Verify that user1@realmB credentials and challengeresponse is validated by vendor B in subsequent MAR/MAA exchanges.

o Positive test with SIP server performing authentication. Assumingproper configuration of all test entities, SIP REGISTER request

for user1@realmB should succeed and the resulting message flowsshould follow Figure 3 of [I-D.ietf-aaa-diameter-sip-app]. Thistest scenarios is identical to the previous scenario except thatthat nonces must be transferred from vendor B to D (Digest-HA1avp). All verification procedure in the previous test applies.

o Positive test for server assignment. Assuming successfulauthentication of user1@realmB, verify that vendor D is properlyallocated as the designated SIP server for this user. Verify thatthis is a consequence of the previous positive tests and vendor Bis notified using SAR/SAA exchanges. Additional verification ofthis scenario can be done with subsequent SIP request such as inSection 4.3.1.3.

o Positive test for different settings of SIP-user-authorization-type. Using the same scheme as previous positive test, verifythat registration can succeed with authorizations types

* REGISTRATION

* REGISTRATION_AND_CAPABILITIES

Additional configuration on vendor B maybe required to perform thetest.

o Positive test for registering an already registered user. Verifythat user1@realmB can properly re-register with vendor D and thatthe re-registration triggers a SAR/SAA exchange between D and B toupdate server assignments. Verify that the MAR/MAA exchanges areskipped. The message flow should be as follows.



30/66


+--------+ +--------+ +--------+ SIP Diameter SIP server 1 server server 2

Vendor A Vendor B Vendor D+--------+ +--------+ +--------+

1. SIP REGISTER --------------------> 2. UAR

------------------> 3. UAA 5. SAR 7. SIP 200 (OK)

8. SIP 200 (OK)


31/66




1. SIP REGISTER --------------------> 2. UAR

------------------> 3. UAA 5. SAR 7. SIP 200 (OK)

8. SIP 200 (OK)


32/66




1. Timer Expires 1. Timer Expires

2. SAR

Figure 9: Message Flow for Registration Timeouts

Note that the message flow is synonymous to Figure A.4.4.1 of[TS29.228]. Therefore, the test scenario should apply toSection 4.4.1 as well.

o Positive test for Diameter server initiated de-registration usingadministrative means. Verify that the any soft states are removedfrom vendor B. Administrative de-registration is implementationspecific and is left up to the tester to simulate. Note that softstate termination also applies as described in Section 4.3.1.5.The message flow should be as follows.

+--------+ +--------+ +--------+

SIP Diameter SIP server 1 server server 2Vendor A Vendor B Vendor D+--------+ +--------+ +--------+

1. RTR ------------------> 2. De-REGISTER 5. RTA


33/66


Section 4.4.1 as well.

o Negative test for auth when user-name avp is required by the

Diameter server. Verify that vendor A sends a SIP unauthorizedresponse back to UA1 if MAA is set to DIAMETER_USER_NAME_REQUIRED.The result of the authentication/authorization may or may not besuccessful in this context. Vendor B can be configured to requirea user-name in the UAR. This may not be applicable to allimplementations.

o Negative test for failed authorization. Verify the behavior ofvendor A and B when the criteria for the following errors aremeet. Verify that vendor A can terminate the call with UA1. Notethat for Diameter Cx, these codes may be present in theexperimental-result-code avp instead.

* DIAMETER_ERROR_USER_UNKNOWN. Simulation requires usersidentity to be removed from vendor B.

* DIAMETER_ERROR_IDENTITIES_DONT_MATCH. Simulation may requiremis-configuration.

* DIAMETER_AUTHORIZATION_REJECTED. Simulate restrictions to useraccess in the network.

* DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED.

4.3.1.2. User Profile Update

Implementations must conform to Section 6.8 of[I-D.ietf-aaa-diameter-sip-app]. These test should be performed as aconsequence of Section 4.3.1.1. Updating of user profile in theDiameter server is out of scope and it is left to the tester toperform. The test scenario is also applicable to Section 6.6 of[TS29.228] and synonymous to the message flow described in FigureA.4.7.1 of the same document.

Positive test for updating user profile. Verify that a change inthe profile of user1@realmB can trigger a PPR/PPA exchange betweenvendor B and D.

Negative test for failed authorization. Verify the behavior ofvendor B and D when the criteria for the following errors aremeet.

* DIAMETER_ERROR_TOO_MUCH_DATA. Simulation may require some mis-configuration.



34/66


* DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA.

* DIAMETER_UNABLE_TO_COMPLY.

4.3.1.3. Proxy Service Authentication

Implementations must conform to Section 6.5 and 6.6 of[I-D.ietf-aaa-diameter-sip-app]. The test topology in Figure 6 canbe used to perform these test. Vendor A can be configured as theoutbound proxy for UA1 and vendor D for UA2. Note that the testsperformed on vendor A is symmetrical to vendor D. For simplicity,only vendor A is noted here. These test can also be performed as aconsequence of positive tests in Section 4.3.1.1. The test scenariosbelow use a call by user1@realmB to trigger authorization of SIPINVITE request.

Positive test for proxy service authorization with noncesgenerated by the Diameter server. Verify that at the least,user1@realmB can make a call to user2@realmA with SIP requestsfrom vendor A authorized by vendor B. Verify that the SIP INVITEstriggers a MAR/MAA exchange between vendor A and B and that usercredentials properly validated by vendor B. Note that vendor Dshould route SIP request normally to simplify the test. Themessage flow should follow Figure 4 of[I-D.ietf-aaa-diameter-sip-app].

Positive test for proxy service authorization with noncesgenerated by the outbound SIP proxy. Verify that at the least,

user1@realmB can make a call to user2@realmA and that the usercredentials are validated by vendor B only after the challenge isvalidated by vendor A. Verify that a valid challenge initiates aMAR/MAA exchange between vendor A and B. Note that vendor D shouldroute SIP request normally to simplify the test. The message flowshould follow Figure 5 of [I-D.ietf-aaa-diameter-sip-app].

Negative test for authorizing proxy service when user-name avp ismissing. Verify that vendor A sends a SIP unauthorized or SIPauthorization required messages back to UA1 if MAA is set toDIAMETER_USER_NAME_REQUIRED. The result of the authorization mayor may not be successful in this context. Vendor B can beconfigured to require a user-name in the UAR. This may not beapplicable to all implementations.

4.3.1.4. Location Service

Implementations must conform to Section 6.7 and 6.10 of[I-D.ietf-aaa-diameter-sip-app] and Section 6.1.4 of [TS29.228]. Alltest entities should be present to perform this test. The message



35/66


flow being tested is Figure 8. of [I-D.ietf-aaa-diameter-sip-app].This is also synonymous to Section A.4.5 of [TS29.228]. The testtopology in Figure 6 can be used to perform these test. The location

service test can be triggered by initiating a call to user2@realmAfrom UA1. The presence of SIP and/or SIPS URI for user2@realmA invendor B can be done via SIP registration in Section 4.3.1.1 or someother means. The test scenarios below assumes vendor D is theallocated/assigned SIP server for user2@realmA.

o Positive test for location query using Diameter server. Vendor Bis pre-provision in vendor A as location server. for realmA.Verify that a call (SIP INVITE) from UA1 to user2@realmA triggersvendor A to send an LIR towards vendor B. Verify that vendor Bforwards the INVITE to vendor D upon receipt of LIA.

o Positive test for location query using Diameter SL. Vendor C ispre-provisioned in vendor A as the location server. Verify thatthe INVITE from UA1 to user2@realmA triggers vendor A to send anLIR towards vendor C. Verify LIA redirection from vendor C causesan LIR to be forwarded to vendor B.

o Negative test for failed authorization. Verify the behavior ofvendor B and D when the criteria for the following errors aremeet.

* DIAMETER_ERROR_USER_UNKNOWN. Simulation may require mis-configuration.

* DIAMETER_UNABLE_TO_COMPLY. Simulation may require mis-configuration.

* DIAMETER_ERROR_IDENTITY_NOT_REGISTERED.

4.3.1.5. Soft Termination

Implementations must conform to Section 6.9 of[I-D.ietf-aaa-diameter-sip-app] and 6.5.2.2 of [TS29.228]. Thesetest should be performed as a consequence of Section 4.3.1.1. In theenumerated test scenarios, vendor A request removal of user bindingsin vendor B. This maybe a consequence of user1@reamlB logging off onUA1 (Section 10.2.2 in [RFC3261]) or an expiration of usage timer invendor B. It is left to the implementation to configure suchscenario.

o Positive test for soft termination when session is stateless andDiameter client initiates termination. Verify that at the least,vendor D can send a SAR to vendor B when user1@realmB de-registers. Note the appropriate result-codes are enumerated in



36/66


Section 6.9 of [I-D.ietf-aaa-diameter-sip-app]. This scenario issynonymous to Figure 8.

o Positive test for soft termination when session is stateless andDiameter server initiates termination. Verify that at the least,vendor B can send an RTR to vendor D to AOR(s) for [email protected] can also simulate multiple AORs for the user and verifythat RTR can selectively remove specific AORs. It is left to thetesters to simulate a SIP-deregistration-reason from the Diameterserver. This scenario is synonymous to Figure 10.

o Positive test for soft termination when session is stateful andDiameter client initiates termination. Verify that at the least,vendor D can send an STR to vendor B when user1@realmB de-registers. Verify application id value carried by the STR/STA

message is that of the target application.

o Positive test for soft termination when session is stateful andDiameter server initiates termination. Verify that at the least,vendor B can send an ASR to vendor B. Verify application id valuecarried by the STR/STA message is that of the target application.It is left to the testers to simulate session termination on theDiameter server, i.e., session-timeout or registration timeout.

4.4. 3GPP Interface Test Suite

The test suite in this section only covers the following IMSinterfaces. Future revisions will attempt to cover the remaining

interfaces.

o Diameter Cx, [TS29.228] and [TS29.229].

o Diameter Sh, [TS29.328] and [TS29.329].

o Diameter Rf, [TS32.260].

Because of the complexity in IMS deployment, a lot of assumptionshave been made in terms of the test topology. Since recreating anIMS network is not realistic, only entities implementing Diameterapplications will be involved in these test cases. Peripheralentities that instigate a test event should be simulated.

4.4.1. Diameter Cx

Implementations must conform to [TS29.228] and [TS29.229]. SinceDiameter Cx describes the same application as Diameter SIP, the testtopology and scenarios in Section 4.3 is applicable. For brevity,this section will only provide addendums to the existing test suites



37/66


in Section 4.3 as it applies to Diameter Cx. Authentication schemespresent in the SIP tests may or may not be present for Cx testing.The topology in Figure 6 will be used with the following mappings.

Diameter Cx Test Topology VendorNode Equivalent Assignments

----------------+---------------------+-----------------------

I-CSCF SIP Server 1 Vendor A, I-CSCFon Home Network

HSS Diameter Server Vendor B, HSSon Home Network

S-CSCF SIP Server 2 Vendor D, S-CSCFon Home Network

P-CSCF Optional Use UA1 to simulateP-CSCF

AS Optional Implementation specific,maybe simulated

Figure 11: SIP Test Topology Mapping

All test entities can share the same realm (Home Network). The SIP

proxy P-CSCF may or may not be present for testing the Cx interface.If it is not available, tests for registration and de-registrationdescribed in Section A.4.2 and A.4.3 of [TS29.228] can use UA1 tosimulate a P-CSCF. S-CSCF functions that rely on other entities suchas AS may also be simulated when service initiated test needs to beperformed. An AS maybe present to facilitate this though it is leftup to the implementation to provide an AS and verify itsconfiguration.

4.4.1.1. Required

The following are addendums to Section 4.3 for testing Diameter Cx.

o Positive test for de-registration initiated by S-CSCF. Verifythat a de-registration initiated by S-CSCF (vendor C) triggers theremoval of server assignments in vendor B. Verify SAR/SAA exchangeoccurs. Message flow can be as follows.



38/66


+--------+ +--------+Diameter SIP server server 2

Vendor B Vendor D+--------+ +--------+

1. Simulated Service De-registration

2. De-register

4. SAR

Figure 12: Message Flow for Service Initiated De-registration

o Positive test for session initiation to a non-registered user.Verify that a call made by UA1 can initiate a server assignment byvendor B for that call. Verify that the SIP INVITE also triggersa location query (LIR/LIA exchange) with vendor B. Message flowcan be as follows.

+--------+ +--------+ +--------+ SIP Diameter SIP

server 1 server server 2Vendor A Vendor B Vendor D+--------+ +--------+ +--------+

1. SIP INVITE --------------------> 2. LIR

------------------> 3. LIA 5. SAR

Figure 13: Message Flow for Session Initiation to a Non-registeredUser



39/66


Normally, server selection is performed during this process.Testers can verify if vendor A correctly determine vendor D as theassigned SIP server. Additional service control functions may

also need to be performed by vendor D. Though those would be outof scope of this document.

4.4.2. Diameter Sh

Implementations must conform to [TS29.328] and [TS29.329]. The testtopology for Diameter Sh is Figure 14. Because AS functionality isimplementation and service specific, it is left to the testers toverify configuration of the provided service. UA registration withAS services are also left up to the tester to verify. Someinteraction with the test topology for Section 4.4.1 maybe requiredin certain test scenarios.

Home Network

+--------+ +--------+Diameter AS

IMS Network server Vendor E Vendor B UDR/UDA +--------+ PUR/PUA +--------+ SNR/SNA PNR/PNA -------SIP to S-CSCF and UA1-------

Legend:IMS Network - Test topology for Diameter SIP.

Network details are not shownfor brevity.

Diameter server - Vendor B acting HSS for Home Network.Part of the IMS Network.

AS - Vendor E acting as AS

Figure 14: Diameter Sh Test Topology

The test topology shown above is an addendum to Figure 6. The ASuses Diameter Sh with the HSS and SIP with S-CSCF and UA1 in the IMSnetwork. For Diameter Sh, the message flow being tested is definedin Section B.1 of [TS29.328]. It is left to the testers to verifythat the AS is properly configured in the IMS network.



40/66


4.4.2.1. Required

The following are test scenarios to exercise Diameter Sh interface.

o Positive test for data handling. Implementations must conform toSection 6.1.1 and 6.1.2 of [TS29.328]. Verify that vendor E iscapable of storing and retrieving service related data into vendorB via PUR/PUA and UDR/UDA. If user1 in UA1 can register forservice to the vendor E, verify that vendor E is able to storeservice related data into vendor B. If user1 can then register tovendor D in the IMS network and trigger a third-party registrationto vendor E, verify that vendor E is able pull service relateddata from vendor B. Verify correctness of the following identity-set when reading data from vendor B.

* IMPLICIT_IDENTITIES

* REGISTERED_IDENTITIES

* ALL_IDENTITIES

o Positive test for subscription/notification. Implementations mustconform to Section 6.1.3 and 6.1.4 of [TS29.328]. Verify thatvendor E can successfully subscribe to notification in case ofdata changes in vendor B. This test should be performed after theprevious positive test. Simulation of data changes in vendor B isimplementation specific. Verify that vendor B sends a PNR to Ewhen simulated changes occur.

o Negative test for data update. Verify behavior of both vendor Band E when the criteria for following experimental result codesare meet.

* DIAMETER_ERROR_USER_DATA_CANNOT_BE_MODIFIED. Simulate updaterestrictions for vendor E in vendor B.

* DIAMETER_ERROR_USER_UNKNOWN.

* DIAMETER_ERROR_OPERATION_NOT_ALLOWED. Simulate restrictions onvendor B. Configuration of AS permission list maybe necessary.

* DIAMETER_PRIOR_UPDATE_IN_PROGRESS.

* DIAMETER_ERROR_TRANSPARENT_DATA_OUT_OF_SYNC. Simulation mayrequire some invalid configuration.

* DIAMETER_ERROR_TOO_MUCH_DATA. Simulation may require someinvalid configuration.



41/66


o Negative test for data read and notification subscriptions.Verify behavior of both vendor B and E when the criteria forfollowing experimental result codes are meet during data pull or

subscription.

* DIAMETER_ERROR_USER_DATA_CANNOT_BE_READ. Simulate readrestrictions for vendor E in vendor B.

* DIAMETER_ERROR_USER_UNKNOWN.

* DIAMETER_ERROR_OPERATION_NOT_ALLOWED. Simulate restrictions onvendor B. Configuration of AS permission list maybe necessary.

4.4.3. Diameter Rf

Implementations must conform to [TS32.260]. The test topology forDiameter Rf is Figure 15. The test cases in this section do notattempt to cover all accounting scenarios that are possible in an IMSnetwork. It only exercise accounting functions for test entitieslisted in Figure 11. Because the test topology only describes a homenetwork, the Rf interface is limited to S-CSCF and I-CSCF accounting.Record co-relation with a visited network is assumed not to be done.The CDF entity should be reachable to the SIP servers in Figure 6 andto the AS in Figure 14 if an AS is used. The test scenarios alsomakes a lot of assumptions in testing non-Diameter related Rfrequirements such as the CDR formats, operator configuration of theCDF, SIP based signaling or operator based decision on when to useoffline-charging etc. Since there can be a multitude of

configuration options, verification of actual billing schemes usedand its accuracy is left to the testers. For the purpose of Diameterinteroperability, the test scenarios in Section 4.1.1.2 applies hereas well.

IMS Network+----------+

CDF Vendor F

+----------+

Legend:IMS Network - Test topology for Diameter SIP and/or

Diameter Sh. Network details are notshown for brevity.

CDF - Vendor F acting CDF for Home Network.



42/66


Figure 15: Diameter Rf Test Topology

4.4.3.1. Required

The following are test scenarios to exercise Diameter Rf interface.

o Positive test for SIP session establishment. Implementations mustconform to Table 5.2.1.1 of [TS32.260]. Verify that vendor A or Dgenerates a START_RECORD on positive acknowledgment of SIP INVITE.The SIP server involved depends on the UA location. The testcould be performed as part of Section 4.3.1.3. Note that only themandatory triggers are recommended to be tested. The remainingtriggers specified in Table 5.2.1.1 of [TS32.260] is left up tothe test pairs.

o Positive test for SIP session updates. Implementations mustconform to Table 5.2.1.1 of [TS32.260]. Verify that vendor A or Dgenerates an INTERIM_RECORD on a SIP re-INVITE or UPDATE for anexisting SIP session. The test can be performed in sequence withthe previous positive test.

o Positive test for session-unrelated procedures. Implementationsmust conform to Section 5.2.2.1.5 of [TS32.260]. Verify thatvendor A or D generates EVENT_RECORD on a SIP SUBSCRIBE signal.The test can be performed in sequence with the previous positivetest.

o Positive test for SIP session termination. Implementations must

conform to Table 5.2.1.1 of [TS32.260]. Verify that vendor Dgenerates STOP_RECORD on a SIP BYE signal. The test can beperformed in sequence with the previous positive test.

o Negative test for unsuccessful SIP session establishment. Verifythat if a SIP session establishment fails, that vendor A or Dgenerates an EVENT_RECORD. The SIP server involved depends on thelocation of the UA initiating the session.

o Negative test for error cases. Verify that vendor A and/or Dfollows Section 5.2.2.2 of [TS32.260]. The error cases in thattext are general and may overlap with error cases in Section 3.

4.4.3.2. Optional

The following are optional test scenarios to exercise Diameter Rfinterface. Note that details of the tests are skipped for brevity.

o Positive test for multi-party call. Assuming a new UA isintroduced in the home network and S-CSCF is provided by vendor D,



43/66


the call flow should follow Section 5.2.2.1.10 of [TS32.260].

o Positive test for AS related procedures. If an AS is used, verify

that vendor E can generate EVENT_RECORDs for services rendered tothe UA. Such services are implementation specific. However,examples of such service is described in Section 5.2.2.1.11 of[TS32.260].

4.5. Diameter EAP Test Suite

Access device and AAA servers that support Diameter EAP Applicationmust conform to [RFC4072]. A typical test for network accessauthentication using Diameter EAP is shown in Figure 16. The Userhas an EAP Client to be authenticated for network access. The testcases only cover the NAS and Auth. Servers interoperability. To

perform these tests, one must choose an EAP method. It isrecommended to use an authentication method which derive keyingmaterial to test key transport between Auth. Server and NAS. As anexample, EAP-TLS [RFC2716] can be used.

+--------+ +--------+ +---------------+ User NAS Auth Server 1 Vendor A Vendor B +--------+ +--------+ +---------------+

^v

+---------------+ Auth Server 2 Vendor C +---------------+

Legend:UserNAS - Vendor A Diam EAP clientAuth Server 1 - Vendor B Diam EAP serverAuth Server 2 - Vendor C Diam EAP server

Figure 16: Diameter EAP

4.5.1. Required

Implementation must conform to section 2 of [RFC4072]. NAS and Auth.Servers advertises Diameter EAP support in their CER/CEA exchange.



44/66


4.5.1.1. Non-Roaming case

In this test, User, NAS and Auth. Server 1 belongs to the same

realm.

o Verify that all Diameter messages for a particular user containsthe same Session-Id AVP.

o Positive test for EAP initiation. Verify that the Auth. serverinitiates an EAP session while receiving either a DER containingan EAP-Payload AVP Empty (signifying an EAP-Start) or an EAP-Payload AVP containing an EAP-Response of Type Identity (cf.section 2.2 of [RFC4072]).

o Positive test for User-Name AVP. Verify that the User-Name AVP

sent in DER message by the NAS contains the value provided by theUser in the EAP exchange between User and NAS.

o Positive test for user registration. Verify that the Auth. server1 can authenticate and authorize User given a proper configuration(e.g. by using EAP-TLS method between the User and the Auth.Server). Verify that the AAA message flows is correct (cf.section 2.2 of [RFC4072]).

o Positive test for Key transport and configuration. If the EAPauthentication method derives keys, verify that the Auth. Servercorrectly provide keying material to the NAS and that these keysare correctly used between User and NAS.

o Positive test for session termination: User Disconnection. Verifythat if the User disconnects for the NAS, the NAS sends a STRmessage to the Auth. Server. Verify that the Auth. Serverreleases all state concerning this User.

o Positive test for session termination: Auth-lifetime expiration.Verify that if the auth-lifetime expires, the NAS send a STR tothe Auth. server. Verify that the Auth. Server releases allstate concerning this User.

o Negative test for authentication. Verify that the Auth. Serversends a DEA message containing a DIAMETER_AUTHENTICATION_REJECTEDresult-code to the NAS if the User is not correctly authenticated.

4.5.1.2. Roaming scenario

In this scenario, User and Auth. Server 2 belongs to realmB whileNAS and Auth. Server 1 belongs to realm A. All tests described inthe Non-Roaming scenario must work. As we are in roaming scenario,



45/66


the following two tests should also be performed.

o Positive test for Diameter EAP Direct Routing. Verify that if NAS

is properly configured, it can directly send Diameter EAP messagesto Auth. Server 2.

o Positive test for Diameter EAP Proxy Routing. Verify that if NASand Auth. Servers are correctly configured, Diameter EAP messagesare exchanged between NAS and Auth. Server 2 through Auth.Server 1.

4.5.2. Optional Authorization/Accounting Tests

o Positive test for Authorization AVPs. Verify that if someauthorizations are requested, the DEA containing the

DIAMETER_SUCCESS in the Result-Code AVP also contains appropriateAuthorization AVPs (cf. section 5 of [RFC4005]).

o Positive test for Accounting. Verify that NAS initiatesAccounting if authentication is successful and finishes it whileterminating the session.

o Positive test for re-authentication. Verify that the Auth.Server can reauthenticate the User via the NAS.

o Positive test for Redirection. Verify that the Redirect Scenariodescribed in section 2.3.2 of [RFC4072] is supported.

4.6. Diameter NASREQ Test Suite

Access device that supports Diameter NASREQ extension must conform to[RFC4005]. Typical test topology for single domain authenticationshown in Figure 17. Multi-domain test should use Figure 3. The Userentity typically employs PPP to access the NAS and is normallyimplementation dependent. Since the test cases covers only NAS andAuth Server interoperability, it is left to the tester to verifycorrectness of the access method between User and NAS and that thismethod is able to trigger creation of a NASREQ client session in theNAS.



46/66


+--------+ +--------+ +-------------+ User NAS Auth Server Vendor A Vendor B

+--------+ +--------+ +-------------+

Legend:User - Simulated userNAS - Vendor A Diam NASREQ clientAuth Sever - Vendor B Diam NASREQ server

Figure 17: Diameter NASREQ Test Topology

Another test topology can exist for testing Diameter/RADIUS gatewaysas specified in Section 9 of [RFC4005]. This topology is availablefor vendors implementing a translation gateway. It should simulate a

common deployment scenario where there is a prevalence of legacyRADIUS access devices ([RFC2865]). Since the test cases coversinteroperability scenarios, validation must be done between NAS andGateway. As with Figure 17, it is left to the tester to verifycorrectness of the access method between User and NAS. The testcases involving Figure 17 is also relevant to validating Gateway andAuth Server and should be used in this topology as well.

+--------+ +--------+ +---------+ +-------------+ User NAS Gateway Auth Server Vendor A Vendor B +--------+ +--------+ +---------+ +-------------+

Legend:User - Simulated userNAS - Simulated or vendor RADIUS clientGateway - Vendor A Diameter/RADIUS gatewayAuth Sever - Vendor B Diam NASREQ server

Figure 18: Translation Gateway Test Topology

4.6.1. Required

4.6.1.1. Auth Session

Implementations must conform to Section 2 of [RFC4005]. Testtopology Figure 17 can be used for these cases. These teststypically involves a myriad of configuration options. At the leastan implementation must be able to grant access to a user with areasonable level of security given the test cases below. The minimumtest that should be performed is PPP CHAP and PPP EAP with MD5method. These tests are heavily dependent on other parameters thatare implementation specific (username, password, medium type,



47/66


calling-station-id etc). It is left to the tester to verifycorrectness of this process but it must conform to Section 2.1, 3.1and 3.2 of [RFC4005]. This includes conformance to the use of

transport level security (TLS or IPsec) for signaling sensitiveinformation, i.e., passwords etc. This test is also an overlap withSection 4.1.1.1.1. Verification of test cases can be done manually.

o Positive test for proper Auth server session establishment withauthorization and authentication. Verify that user can initiatean access-request via vendor A and that vendor B can respond whenPPP negotiation begins. Vendor A and B can agree on the service-type. Verify that at the least B can support auth-request-typeAUTHORIZE_AUTHENTICATE.

o Positive test for proper NAS session establishment with

authorization and authentication. Verify that user can initiatean access-request via vendor A and that vendor B can respond whenPPP negotiation begins. Verify that A is able to supportDIAMETER_MULTI_ROUND_AUTH result-code.

o Positive test for proper NAS session establishment with PPP.Verify support for PPP CHAP/EAP in auth request/answer exchanges.Verify that call and session information are exchanged properly toconform to Section 4.1 of [RFC4005].

o Positive test for proper session termination. Verify that a NAScan initiate termination upon user disconnection. Verify that theauth server can

Draft Fajardo Dime Interop Test Suite 04

Documents

Transcript of Draft Fajardo Dime Interop Test Suite 04