Internet DRAFT - draft-fajardo-dime-interop-test-suite
draft-fajardo-dime-interop-test-suite
AAA Working Group V. Fajardo
Internet-Draft TARI
Expires: July 5, 2007 A. McNamee
Openet-Telecom
H. Tschofenig
Siemens
J. Bournelle
GET/INT
January 2007
Diameter Interoperability Test Suite
draft-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 aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 July 5, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Fajardo, et al. Expires July 5, 2007 [Page 1]
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 interoperability
testing.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Diameter Base Protocol Test Suite . . . . . . . . . . . . . . 5
3.1. Required . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Connectivity and Peering . . . . . . . . . . . . . . . 5
3.1.2. Routing . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.3. Relay Agent . . . . . . . . . . . . . . . . . . . . . 11
3.1.4. Redirection Agent . . . . . . . . . . . . . . . . . . 12
3.2. Optional . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.1. General Statemachine . . . . . . . . . . . . . . . . . 12
3.2.2. Dynamic Peer Discovery . . . . . . . . . . . . . . . . 12
4. Diameter Applications . . . . . . . . . . . . . . . . . . . . 14
4.1. Common Test Suite . . . . . . . . . . . . . . . . . . . . 14
4.1.1. Required . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Diameter Credit Control Test Suite . . . . . . . . . . . . 17
4.2.1. Required . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.2. Optional . . . . . . . . . . . . . . . . . . . . . . . 24
4.3. Diameter SIP Test Suite . . . . . . . . . . . . . . . . . 27
4.3.1. Required . . . . . . . . . . . . . . . . . . . . . . . 28
4.4. 3GPP Interface Test Suite . . . . . . . . . . . . . . . . 36
4.4.1. Diameter Cx . . . . . . . . . . . . . . . . . . . . . 36
4.4.2. Diameter Sh . . . . . . . . . . . . . . . . . . . . . 39
4.4.3. Diameter Rf . . . . . . . . . . . . . . . . . . . . . 41
4.5. Diameter EAP Test Suite . . . . . . . . . . . . . . . . . 43
4.5.1. Required . . . . . . . . . . . . . . . . . . . . . . . 43
4.5.2. Optional Authorization/Accounting Tests . . . . . . . 45
4.6. Diameter NASREQ Test Suite . . . . . . . . . . . . . . . . 45
4.6.1. Required . . . . . . . . . . . . . . . . . . . . . . . 46
4.6.2. Optional . . . . . . . . . . . . . . . . . . . . . . . 49
4.7. Diameter MIP Test Suite . . . . . . . . . . . . . . . . . 49
4.7.1. Generic MIP Test Scenarios . . . . . . . . . . . . . . 49
4.7.2. Required . . . . . . . . . . . . . . . . . . . . . . . 50
4.7.3. Optional . . . . . . . . . . . . . . . . . . . . . . . 55
5. Security Considerations . . . . . . . . . . . . . . . . . . . 60
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
7. Normative References . . . . . . . . . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64
Intellectual Property and Copyright Statements . . . . . . . . . . 65
Fajardo, et al. Expires July 5, 2007 [Page 2]
Internet-Draft Diameter Interoperability Test Suite January 2007
1. Introduction
The document is meant to aid in the identifying the functional test
cases of a Diameter implementation. The Diameter interoperability
test suites are categorized by different applications or extensions.
Each category is further subdivided into 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. The following is a
list of Diameter applications that are currently categorized in this
document:
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 such
cases, it is implied that multiple test scenario can be covered by
some 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.
Fajardo, et al. Expires July 5, 2007 [Page 3]
Internet-Draft Diameter Interoperability Test Suite January 2007
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] refers to the
functionality that have to be provided by an implementation for the
usage within this interoperability test event.
Fajardo, et al. Expires July 5, 2007 [Page 4]
Internet-Draft Diameter Interoperability Test Suite January 2007
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]. Typical
test topology for statemachine test uses peer pairs as shown in
Figure 1. It is left to the testers if one-to-many or many-to-one
connections will be performed to test scalability and loading. The
test cases described below references Figure 1 below.
+--------+ +--------+
|Vendor A|<---wired link---->|Vendor B|
+--------+ +--------+
Figure 1: Peer Statemachine Test Topology
3.1.1.1. Capabilities Negotiation
Implementations must be able to perform at least the following
behavior described in Section 5.3 of [RFC3588].
o Positive test for establishment of connection with test pairs
advertising support for common application ids (auth, accounting
or vendor). Vendor A initiates transport connection to B and
trigger the process.
o Positive test for establishment of connection with test pairs of
which one of them is advertising support for only relay app and no
other app is in common.
o Positive test for establishment of connection advertising the
relay app in auth app id, acct app id & VSA.
o Positive test for establishment of connection with test pairs
advertising support common transport security, specifically the
use of TLS and/or IPSec. It is left up to the participants to
generate appropriate keys and certificates specific for this test.
Vendor A initiates transport connection to B and trigger the
process and advertised proper Inband-Security support.
o Positive test for DWR/DWA exchange after connection is
established. Vendor A and B both exchange watchdogs as per
Section 3.4.1 of [RFC3539].
Fajardo, et al. Expires July 5, 2007 [Page 5]
Internet-Draft Diameter Interoperability Test Suite January 2007
o Negative test where DIAMETER_NO_COMMON_APPLICATION is returned by
a 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 known
only to A.
o Negative test where DIAMETER_NO_COMMON_SECURITY is returned by a
peer with no common application id. Intentionally configure
vendor A to send Inband-Security-AVP with value 1 (TLS) that B
will not support.
o Negative test for unknown peers. Use of DIAMETER_UNKNOWN_PEER or
silent discard to disconnect unknown peers. Intentionally
configure vendor A to send an origin-host that is not in B's peer
table.
o Negative test case for TLS handshake failure. In the case where
the negotiated Inband-Security involves subsequent TLS
negotiation, 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 must
be able to resolve contention with initiator peers.
o Positive test for establishment of connection with responder
having higher identity than initiator. Vendor A initiates
connection followed by B doing the same a few milliseconds later.
Vendor A having a higher identity should close B's connection
attempt.
o Positive test for disconnection with initiator having lower
identity than the responder. Vendor A initiates a connection
followed by B doing the same a few milliseconds later. Vendor A
having a lower identity should close its initial connection
attempt.
o Negative test for disconnection when initiator and responder have
equal 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.
Fajardo, et al. Expires July 5, 2007 [Page 6]
Internet-Draft Diameter Interoperability Test Suite January 2007
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 determine
disconnection events. Verification of test results can be done
manually.
o Positive test for peer disconnection using DPR/DPA exchange.
Vendor A initiates shutdown while connected to B. Implementations
behavior may vary depending on disconnection cause such as an
eventual connection retry if a disconnection cause of REBOOTING is
received.
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 to
simulate this scenario.
o Positive test for detecting disconnection via watchdog timeout.
If there is no activity after a watchdog timer expires with
pending request then the peer becomes suspect and implementation
must be able to initiate failover procedure. [RFC3539] suggest a
minimum watchdog timeout at 6 sec. Vendor B can setup a transport
level filter to silently drop AAA traffic from B to simulate
unresponsiveness of B.
o Positive test for resetting connection after at least two(2)
watchdog has expired. If a connection is already suspect, the
peers must reset the connection. Vendor A or B can setup a
transport level filter to silently drop AAA traffic and simulate
unresponsiveness 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 a
vendor can implement other algorithms and policies than those
proposed in [RFC3588], a default reconnection scheme must be
implemented.
o Positive test for peer re-connection after disconnection has been
detected. The link between vendor A and B is temporarily
disconnected until such time that disconnection is detected by
both peers. The link can then be restored to test the re-
connection behavior of both peers. Verify that at least three(3)
Fajardo, et al. Expires July 5, 2007 [Page 7]
Internet-Draft Diameter Interoperability Test Suite January 2007
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] and
Section 3.4.2 of [RFC3539]. Testing failover mechanism requires
alternate peer connections. A basic ring topology to test failover
and failback is shown in Figure 2 where vendor A has a primary route
to vendor C via vendor B and secondary route via vendor D. The same
symmetry is applied to all other vendors. As an example, vendor C
has a symmetric topology where D is its primary connection and B is
its secondary. This allows the same tests to be performed for all
vendors. For testing failover on vendor A and B, link0 can be
disconnected. For vendor C and D, link2 can be disconnected and so
on.
+---------+
|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 applied
to any of the vendor implementations in Figure 2. Conditions for a
positive test requires that realm routes to C is present in A and
host routing is not used. Initial traffic should flow from A to C
via B (as the primary peer of A).
o Positive test for failover when link0 is disconnected. Vendor A
should have pending requests queued prior to disconnection. Upon
disconnection (see Section 3.1.1.3), verify that the pending
request with T-flag set has been forwarded to C via D.
o Positive test for failover by using device watchdog as a means of
triggering link0 disconnection. Vendor A should have pending
requests queued prior to disconnection. Upon disconnection (see
Section 3.1.1.3), verify that the pending request with T-flag set
has been forwarded to C via D.
Fajardo, et al. Expires July 5, 2007 [Page 8]
Internet-Draft Diameter Interoperability Test Suite January 2007
o Positive test for failback when link0 is restored and re-
connection succeeds (See Section 3.1.1.4). Verify that new
request message is routed back to B.
o Negative test to generate DIAMETER_UNABLE_TO_DELIVER on answer
message from B to A when Destination-Host is set to C. This can be
simulated when link3 is disconnected and Vendor C is not reachable
from Vendor. Note that alternate path via Vendor D should not be
used.
o Negative test to detect duplicate messages on C. Vendor B can
disable watchdog processing but still allow request message
forwarding. This makes B a suspect peer from A and trigger
failover procedure. Forwarding of queue request will then be done
through 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 basic
topology to test Diameter routing is shown in Figure 3 where vendor A
and vendor B can deploy two(2) Diameter peers to test host, realm and
answer message routing. Vendor A1 and A2 shares the same realm
(realmA). Vendor B1 and B2 share a different realm (realmB). Test
between both realms are symmetric although the description focuses
mostly to vendor A for editorial reasons. The topology is also
designed so that multi-hop forwarding, message loopback and agent
configuration can be tested. Note that some test cases in this
section require link disconnection overlap with the test cases
outline in Section 3.1.1.3. An implementation experiencing link
disconnection 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)
Fajardo, et al. Expires July 5, 2007 [Page 9]
Internet-Draft Diameter Interoperability Test Suite January 2007
Figure 3: Routing Test Topology
3.1.2.1. Peer Based Request Routing
Implementation must conform to Section 6.1.5 of [RFC3588]. In order
to perform the test cases the peer requesting the AAA routing must
have the destination-host and the destination-realm present in the
request message.
o Positive test for request forwarding from originator. Request
messages generated from A1 should reach B2 via B1 if destination-
host of the request is B2 and destination-realm is realmB and all
links are up. A1 must perform realm routing to reach B1 and B1
must perform forwarding to reach B2. Verification of routing can
be done manually if message has reached B2 via link4 and link3.
o Positive test for multi-hop request forwarding. Request messages
generated from A1 with destination-host B2 and destination-realm
realmB should reach B2 via A2 and B1 if all links are up except
for link4 and link2. A1 and A2 must perform realm routing while
B1 performs forwarding. A1 and A2 must be able to route the
request message to B1 even if it does not have B2 in its peer
table. Verification of routing can be done manually if message
has reached B2 via link1, link0 and link3.
o Negative test for request forwarding. If a request message
generated from A1 has a destination-host B2 and destination-realm
realmB with all links up except for link0, link2 and link4 then A2
must send an answer message to A1 with result-code
DIAMETER_UNABLE_TO_DELIVER. Verification can be done manually if
the 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 have
destination-realm present but must not have destination-host present
in the request message. Note that there is some test overlap with
the test cases defined in Section 3.1.2.1.
o Positive test for request routing from originator. Request
messages generated from A1 should reach B2 via B1 if the
destination-realm is realmB and all links are up. A1 and B1 must
perform realm routing to reach B2. The request must have an id
(app, auth or vendor) that B1 must route and B2 must process
locally. Verification of routing can be done manually if message
has reached B2 via link4 and link3.
Fajardo, et al. Expires July 5, 2007 [Page 10]
Internet-Draft Diameter Interoperability Test Suite January 2007
o Positive test for multi-hop request routing. Request messages
generated from A1 with destination-realm realmB should reach B2
via 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 must
process locally. Verification of routing can be done manually if
message has reached B2 via link1, link0 and link3.
o Negative test for request routing. If a request message generated
from A1 has a destination-realm realmB with all links up except
for link0, link2 and link4 then A2 must send an answer message to
A1 with result-code DIAMETER_UNABLE_TO_DELIVER. Verification can
be done manually if the answer message has reached A1 with E-bit
set.
3.1.2.3. Answer Message Routing
Implementations must conform to Section 6.2 of [RFC3588]. Answer
routing can be verified using test cases in Section 3.1.2.1 and
Section 3.1.2.2.
3.1.2.4. Loop Detection
Implementation must conform to Section 6.1.3 of [RFC3588]. All
forwarders must verify that their local identity is not present in
the route-record of the request. If it is present, the forwarder
must send an answer with result-code DIAMETER_LOOP_DETECTED. If it
is not present, implementations must also insert route-records into
the request messages.
o Positive test for loop detection can be done if a request
originating from A1 has a destination-realm realmA and A1 is
configure to route request for realmA to A2, A2 will route request
for realmA to B1 and B1 will route request back to A1. Though A1
originated the request, it must be able to send an answer message
with 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 testing
relay agent functionality. Note that an overlap exists with the test
case described in Section 3.1.2 when testing relay agents and those
test cases should be used here as well. Verification for usage of
routing AVPs in Section 6.7 of [RFC3588] must be done when testing
agent functionality. Testing of proxy agents that keep vendor
specific state, such as proxy-info, proxy-state, proxy-host, is out
of scope of this document and can be done in parallel or independent
Fajardo, et al. Expires July 5, 2007 [Page 11]
Internet-Draft Diameter Interoperability Test Suite January 2007
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 message
whether the result-code is set to DIAMETER_REDIRECT_INDICATION with
the E-bit enabled and redirect-hosts added.
o Positive test for redirection. Request messages generated from A1
should reach B2 via B1 using redirect from A2 and all links are up
except link0 and link2. A1 must be configured to forward request
message for realmB/B2 via A2. A2 must be configured to act as a
redirect agent and signal a redirect indication to A1 to use B1
instead. Verification of redirection can be done manually if
messages have reached B2 and re-direct indication was processed by
A1.
3.2. Optional
Implementations must conform to Section 5.6 of [RFC3588]. Test
topology 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 same
topology in Figure 1 can be used to perform the test scenarios listed
in this section.
o Negative test for non-CEA message received during CER/CEA
exchange. Silent discard and peer disconnection. Vendor B can
initiate a non Diameter server listening on a Diameter defined
port number to simulate unrecognizable messages from vendor B. Or
the AAA peer of vendor B is modified to generate a non-CEA message
once a transport connection setup has been initiated. Verify that
vendor 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 following
behavior.
o Positive test for establishment of connection with unknown peer.
The topology for this test is Figure 1. Test case is dependent on
implementation accepting dynamic peer table updates. In such
case, lifetime of new peer entry should be check against lifetime
of connection. Intentionally configure vendor A to send an
Fajardo, et al. Expires July 5, 2007 [Page 12]
Internet-Draft Diameter Interoperability Test Suite January 2007
origin-host that is not in B's peer table. Verification of result
can be done manually by inspecting the resulting peer table of B.
o Positive test after redirection (Section 3.1.4). The topology for
this test is Figure 3. Additional verification can be done if
Section 3.1.4 is successful. Redirect-host routes can be cached
by an implementation as a new route entry. Same scenarios as in
the redirect test case except subsequent request messages will be
forwarded to B1 by A1. Verify that only the initial message
results in a redirect process.
Fajardo, et al. Expires July 5, 2007 [Page 13]
Internet-Draft Diameter Interoperability Test Suite January 2007
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 authorization
must conform to the statemachine specification in Section 8.1 of
[RFC3588]. Since these test cases are session level, any topology
can be used by a pair of vendors performing interoperability. The
minimum topology will be based on Figure 1. Note that majority of
these test are performed as part of other Diameter application test
cases. Therefore, implementations must be able to comply with these
common cases.
4.1.1.1.1. Stateful Session
Implementations must conform to Section 8.1 of [RFC3588].
Implementations must be able to perform at least the following
behavior.
o Positive test for proper stateful session establishment. Verify
that auth-session-state with STATE_MAINTAINED is enforced in the
client session. Verify that auth-session-lifetime and auth-
session-grace-period are negotiated properly and enforced between
vendor implementations. Must conform to Section 8.4 of [RFC3588].
o Positive test for proper stateful session re-auth. Verify server
initiated RAR/RAA exchange occurs on auth-lifetime and auth-grace
period expiration. Must conform to Section 8.3 of [RFC3588].
o Positive test for proper stateful session disconnection. Verify
client initiated STR/STA exchange occurs for auth failure and
session timeout. Verify values of auth-lifetime and auth-grace
period against session-lifetime according to Section 8.9 of
[RFC3588]. Verify application id value carried by the STR/STA
message is that of the target application.
o Positive test for proper stateful session disconnection. Verify
server initiated ASR/ASA exchange occurs when server decides to
discontinue service. Implementations that allow for hard session
termination should be able to perform these tests. Must conform
to Section 8.5 of [RFC3588]. Verify application id value carried
by the STR/STA message is that of the target application.
Fajardo, et al. Expires July 5, 2007 [Page 14]
Internet-Draft Diameter Interoperability Test Suite January 2007
o Positive test for proper stateful session disconnection using
origin-state-id. Verify a vendor implementation can at least
cleanup stateful sessions once it has received a value of origin-
state-id greater than a previously known value from the same
issuer. Verification can be done in the absence of an STR/STA
exchange. Must conform to Section 8.6 of [RFC3588].
4.1.1.1.2. Stateless Session
Implementations must conform to Section 8.1 of [RFC3588].
Implementations must be able to perform at least the following
behavior.
o Positive test for proper stateless session establishment. Verify
that 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. Verify
that session-lifetime is enforced in the client session.
4.1.1.2. Accounting
Applications intending to use Diameter accounting may conform to
Section 8.2 and 9 of [RFC3588] if the particular application has not
already defined its own statemachine. Since these test cases are
also session level, any topology can be used by a pair of vendors
performing interoperability. The minimum topology will be based on
Figure 1. Note that majority of these test are performed as part of
other Diameter application test cases. Therefore, implementations
must 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 following
behavior. Verification of test results for these cases can be done
manually.
o Positive test for proper client session establishment. Verify
that sub-session id is supported and that the client can support
event record generation at the least. Verify that the client
should at least be able to support DELIVER_AND_GRANT. Test
entities must be able to configure their server implementation to
send this avp. Must conform to Section 9.4 and 9.8.7 of
[RFC3588].
o Positive test for proper client session termination. Verify that
session termination causes transmission of stop record events if
Fajardo, et al. Expires July 5, 2007 [Page 15]
Internet-Draft Diameter Interoperability Test Suite January 2007
any and that all records generated are accounted for. Validation
of accounting records can be Diameter application specific and is
left 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 starts
or server storage failure and act accordingly based on Section 8.2
[RFC3588]. Behavior of the client can be policy and
implementation specific and is left to the tester to confirm.
Failed accounting starts and storage failures can be simulated by
mis-configuration of the server test peer.
o Negative test for client session when connectivity fails. Verify
that client session can cope with connectivity failure and act
accordingly 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 following
behavior. Verification of test results for these cases can be done
manually. Since server sessions must support record storage it is
left 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. Verify
that 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 stateful
sessions. Must conform to Section 9.5 of [RFC3588].
o Positive test for proper server session termination. Verify that
expiration of supervision timer in a stateful session terminates
both client and server session on any vendor implementation.
o Negative test for server session when local storage failure
occurs. Verify that server can notify client of its state and act
accordingly based on Section 8.2 of [RFC3588]. Validation is
policy and implementation specific and is left to the tester to
confirm. Storage failure can be simulated by mis-configuration on
the server test peer. This test is mostly a local validation but
it can be used in parallel with Section 4.1.1.2.1.
Fajardo, et al. Expires July 5, 2007 [Page 16]
Internet-Draft Diameter Interoperability Test Suite January 2007
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 control
authorization is shown in Figure 4. 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.
+--------+ +-----------+ +------------+
| 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 4: 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 4, it is
left to the tester to verify correctness of the access method between
User and Service Element. The test cases involving Figure 4 are also
relevant to validating AAA Server/CC Client and CC Server and should
be used in this topology as well.
Fajardo, et al. Expires July 5, 2007 [Page 17]
Internet-Draft Diameter Interoperability Test Suite January 2007
+------+ +---------+ +---------------+
| 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 5: Translation Gateway Test Topology
4.2.1. Required
Either test topology Figure 4 or Figure 5 can be used for these
cases.
4.2.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.
Fajardo, et al. Expires July 5, 2007 [Page 18]
Internet-Draft Diameter Interoperability Test Suite January 2007
* 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.
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.
4.2.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
Fajardo, et al. Expires July 5, 2007 [Page 19]
Internet-Draft Diameter Interoperability Test Suite January 2007
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
Fajardo, et al. Expires July 5, 2007 [Page 20]
Internet-Draft Diameter Interoperability Test Suite January 2007
message. Verify support for the graceful handling of events such
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.
4.2.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.
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. 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
Fajardo, et al. Expires July 5, 2007 [Page 21]
Internet-Draft Diameter Interoperability Test Suite January 2007
[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.
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.
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 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.
4.2.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
Fajardo, et al. Expires July 5, 2007 [Page 22]
Internet-Draft Diameter Interoperability Test Suite January 2007
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 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].
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.
4.2.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).
Fajardo, et al. Expires July 5, 2007 [Page 23]
Internet-Draft Diameter Interoperability Test Suite January 2007
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 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.
4.2.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.
4.2.2. Optional
Either test topology Figure 4 or Figure 5 can be used for these
cases.
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 CC
Server can send a CCA message including a Tariff-Time-Change AVP.
Fajardo, et al. Expires July 5, 2007 [Page 24]
Internet-Draft Diameter Interoperability Test Suite January 2007
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.
4.2.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
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 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.
4.2.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
Fajardo, et al. Expires July 5, 2007 [Page 25]
Internet-Draft Diameter Interoperability Test Suite January 2007
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.
4.2.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].
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].
Fajardo, et al. Expires July 5, 2007 [Page 26]
Internet-Draft Diameter Interoperability Test Suite January 2007
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 functionality
depending on their role in the SIP architecture. Since this SIP
architecture is synonymous to Diameter Cx [TS29.228], the scenarios
enumerated in this section applies there as well. Therefore, there
can be a multitude of deployment scenarios. The test topology
follows the general architecture in Figure 1 of
[I-D.ietf-aaa-diameter-sip-app] in order to exercise the majority of
Diameter SIP features. For testing Diameter Cx, the mapping of the
test entities against this figure is described in Section 4.4.1.
Configuration of SIP user agents and SIP servers in all test cases
are implementation specific and it is left to the tester to verify
their correctness.
Fajardo, et al. Expires July 5, 2007 [Page 27]
Internet-Draft Diameter Interoperability Test Suite January 2007
+--------+
UAR/UAA +--->|Diameter|<----+ PPR/PPA
LIR/LIA | | server | | MAR/MAA
MAR/MAA | |Vendor B| | SAR/SAA
| +--------+ | RTR/RTA
| |
(realmB) | | (realmA)
v v
+------+ SIP +--------+ SIP +--------+ SIP +------+
| SIP |<--------->| SIP |<-------->| SIP |<--------->| SIP |
| UA1 | |server 1| |server 2| | UA2 |
+------+ |Vendor A| |Vendor D| +------+
+--------+ +--------+
Caller=user1@realmB ^ ^ Callee:user2@reamlA
| |
UAR/UAA | |
LIR/LIA | | MAR/MAA
| +--------+ | SAR/SAA
+--->|Diameter|<----+
| SL |
|Vendor C|
+--------+
Legend:
SIP UA's - SIP User Agents making/receiving calls
SIP server 1 - Vendor A acting as SIP proxy for reamlA
Diameter server - Vendor B acting as SIP auth server
Diameter SL - Vendor C acting as location server
SIP server 2 - Vendor D acting as SIP proxy for realmB
Figure 6: Diameter SIP Test Topology
4.3.1. Required
4.3.1.1. Authentication
Implementations must conform to Section 6.3 and 6.4 of
[I-D.ietf-aaa-diameter-sip-app]. All test entities should be present
to perform these test. The test scenarios check proper auth of
user1@realmB during SIP registration (SIP REGISTER) to SIP server 2.
Vendor A should be configured as proxy for UA1 and vendor D will be
the assigned SIP server for user1@realmB. Figure 2 and 3 of
[I-D.ietf-aaa-diameter-sip-app] can be used as a reference for these
test. All test scenario must follow the message flows described in
these figures. These test can be integrated with Section 4.3.1.4.
For simplicity, it is assumed that vendor A has knowledge of vendor B
as the Diameter server through static configuration or through the
location service.
Fajardo, et al. Expires July 5, 2007 [Page 28]
Internet-Draft Diameter Interoperability Test Suite January 2007
o Positive test with Diameter server performing authentication.
Assuming proper configuration of all test entities, SIP REGISTER
request for user1@realmB should succeed with vendor D as the
allocated SIP server for the registration. The resulting message
flows should follow Figure 2 of [I-D.ietf-aaa-diameter-sip-app].
For Diameter Cx, Section A.4.1 of [TS29.228] describes a similar
scenario. UAR/UAA exchanges must indicate to vendor A that D is
the preferred SIP server to handle user1@realmB registration.
Verify that DIAMETER_MULTI_ROUND_AUTH is followed by vendor A and
D and that vendor A generates SIP unauthorized response
accordingly. Verify that user1@realmB credentials and challenge
response is validated by vendor B in subsequent MAR/MAA exchanges.
o Positive test with SIP server performing authentication. Assuming
proper configuration of all test entities, SIP REGISTER request
for user1@realmB should succeed and the resulting message flows
should follow Figure 3 of [I-D.ietf-aaa-diameter-sip-app]. This
test scenarios is identical to the previous scenario except that
that nonces must be transferred from vendor B to D (Digest-HA1
avp). All verification procedure in the previous test applies.
o Positive test for server assignment. Assuming successful
authentication of user1@realmB, verify that vendor D is properly
allocated as the designated SIP server for this user. Verify that
this is a consequence of the previous positive tests and vendor B
is notified using SAR/SAA exchanges. Additional verification of
this scenario can be done with subsequent SIP request such as in
Section 4.3.1.3.
o Positive test for different settings of SIP-user-authorization-
type. Using the same scheme as previous positive test, verify
that registration can succeed with authorizations types
* REGISTRATION
* REGISTRATION_AND_CAPABILITIES
Additional configuration on vendor B maybe required to perform the
test.
o Positive test for registering an already registered user. Verify
that user1@realmB can properly re-register with vendor D and that
the re-registration triggers a SAR/SAA exchange between D and B to
update server assignments. Verify that the MAR/MAA exchanges are
skipped. The message flow should be as follows.
Fajardo, et al. Expires July 5, 2007 [Page 29]
Internet-Draft Diameter Interoperability Test Suite January 2007
+--------+ +--------+ +--------+
| SIP | |Diameter| | SIP |
|server 1| | server | |server 2|
|Vendor A| |Vendor B| |Vendor D|
+--------+ +--------+ +--------+
| | |
1. SIP REGISTER | | |
-------------------->| 2. UAR | |
|------------------>| |
| 3. UAA | |
|<------------------| |
| 4. SIP REGISTER |
|-------------------------------------->|
| | 5. SAR |
| |<------------------|
| | 6. SAA |
| |------------------>|
| 7. SIP 200 (OK) |
8. SIP 200 (OK) |<--------------------------------------|
<--------------------| | |
| | |
Figure 7: Message Flow for Registration of Currently Registered
User
Note that the message flow is synonymous to Figure A.4.2.1 of
[TS29.228]. Therefore, the test scenario should apply to
Section 4.4.1 as well.
o Positive test for user initiated deregistration. Verify that
user1@realmB can properly de-register with vendor D and that the
de-registration triggers a SAR/SAA exchange between D and B to
remove server assignments. Must conform with Section 10.2.2 of
[RFC3261]. Soft state termination also apply as described in
Section 4.3.1.5. The message flow should be as follows.
Fajardo, et al. Expires July 5, 2007 [Page 30]
Internet-Draft Diameter Interoperability Test Suite January 2007
+--------+ +--------+ +--------+
| SIP | |Diameter| | SIP |
|server 1| | server | |server 2|
|Vendor A| |Vendor B| |Vendor D|
+--------+ +--------+ +--------+
| | |
1. SIP REGISTER | | |
-------------------->| 2. UAR | |
|------------------>| |
| 3. UAA | |
|<------------------| |
| 4. SIP REGISTER |
|-------------------------------------->|
| | 5. SAR |
| |<------------------|
| | 6. SAA |
| |------------------>|
| 7. SIP 200 (OK) |
8. SIP 200 (OK) |<--------------------------------------|
<--------------------| | |
| | |
Figure 8: Message Flow for User Initiated De-registration
Note that the message flow is synonymous to Figure A.4.3.1 of
[TS29.228]. Therefore, the test scenario should apply to
Section 4.4.1 as well.
o Positive test for Diameter server initiated de-registration using
registration timeout. Verify that the server assignments are
remove from vendor D when vendor B decides to end the
registration. De-registration on vendor B can be simulated by
configuring a registration timeout for user1@realmB. Verify that
SAR/SAA exchanges are triggered by this event. The message flow
should be as follows.
Fajardo, et al. Expires July 5, 2007 [Page 31]
Internet-Draft Diameter Interoperability Test Suite January 2007
+--------+ +--------+ +--------+
| SIP | |Diameter| | SIP |
|server 1| | server | |server 2|
|Vendor A| |Vendor B| |Vendor D|
+--------+ +--------+ +--------+
| | |
1. Timer Expires | 1. Timer Expires
| | |
| | 2. SAR |
| |<------------------|
| | 3. SAA |
| |------------------>|
| | |
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 to
Section 4.4.1 as well.
o Positive test for Diameter server initiated de-registration using
administrative means. Verify that the any soft states are removed
from vendor B. Administrative de-registration is implementation
specific and is left up to the tester to simulate. Note that soft
state 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 2|
|Vendor A| |Vendor B| |Vendor D|
+--------+ +--------+ +--------+
| | |
| | 1. RTR |
| |------------------>|
| 2. De-REGISTER | |
|<--------------------------------------|
3. Inform | | |
<--------------------| 4. SIP 200 (0K) | |
5a. SIP 200 (0K) |-------------------------------------->|
-------------------->| | 5. RTA |
| |<------------------|
| | |
Figure 10: Message Flow for Administrative De-registration
Note that the message flow is synonymous to Figure A.4.4.2 of
[TS29.228]. Therefore, the test scenario should apply to
Fajardo, et al. Expires July 5, 2007 [Page 32]
Internet-Draft Diameter Interoperability Test Suite January 2007
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 unauthorized
response back to UA1 if MAA is set to DIAMETER_USER_NAME_REQUIRED.
The result of the authentication/authorization may or may not be
successful in this context. Vendor B can be configured to require
a user-name in the UAR. This may not be applicable to all
implementations.
o Negative test for failed authorization. Verify the behavior of
vendor A and B when the criteria for the following errors are
meet. Verify that vendor A can terminate the call with UA1. Note
that for Diameter Cx, these codes may be present in the
experimental-result-code avp instead.
* DIAMETER_ERROR_USER_UNKNOWN. Simulation requires users
identity to be removed from vendor B.
* DIAMETER_ERROR_IDENTITIES_DONT_MATCH. Simulation may require
mis-configuration.
* DIAMETER_AUTHORIZATION_REJECTED. Simulate restrictions to user
access 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 a
consequence of Section 4.3.1.1. Updating of user profile in the
Diameter server is out of scope and it is left to the tester to
perform. The test scenario is also applicable to Section 6.6 of
[TS29.228] and synonymous to the message flow described in Figure
A.4.7.1 of the same document.
Positive test for updating user profile. Verify that a change in
the profile of user1@realmB can trigger a PPR/PPA exchange between
vendor B and D.
Negative test for failed authorization. Verify the behavior of
vendor B and D when the criteria for the following errors are
meet.
* DIAMETER_ERROR_TOO_MUCH_DATA. Simulation may require some mis-
configuration.
Fajardo, et al. Expires July 5, 2007 [Page 33]
Internet-Draft Diameter Interoperability Test Suite January 2007
* 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 can
be used to perform these test. Vendor A can be configured as the
outbound proxy for UA1 and vendor D for UA2. Note that the tests
performed on vendor A is symmetrical to vendor D. For simplicity,
only vendor A is noted here. These test can also be performed as a
consequence of positive tests in Section 4.3.1.1. The test scenarios
below use a call by user1@realmB to trigger authorization of SIP
INVITE request.
Positive test for proxy service authorization with nonces
generated by the Diameter server. Verify that at the least,
user1@realmB can make a call to user2@realmA with SIP requests
from vendor A authorized by vendor B. Verify that the SIP INVITEs
triggers a MAR/MAA exchange between vendor A and B and that user
credentials properly validated by vendor B. Note that vendor D
should route SIP request normally to simplify the test. The
message flow should follow Figure 4 of
[I-D.ietf-aaa-diameter-sip-app].
Positive test for proxy service authorization with nonces
generated by the outbound SIP proxy. Verify that at the least,
user1@realmB can make a call to user2@realmA and that the user
credentials are validated by vendor B only after the challenge is
validated by vendor A. Verify that a valid challenge initiates a
MAR/MAA exchange between vendor A and B. Note that vendor D should
route SIP request normally to simplify the test. The message flow
should follow Figure 5 of [I-D.ietf-aaa-diameter-sip-app].
Negative test for authorizing proxy service when user-name avp is
missing. Verify that vendor A sends a SIP unauthorized or SIP
authorization required messages back to UA1 if MAA is set to
DIAMETER_USER_NAME_REQUIRED. The result of the authorization may
or may not be successful in this context. Vendor B can be
configured to require a user-name in the UAR. This may not be
applicable 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]. All
test entities should be present to perform this test. The message
Fajardo, et al. Expires July 5, 2007 [Page 34]
Internet-Draft Diameter Interoperability Test Suite January 2007
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 test
topology in Figure 6 can be used to perform these test. The location
service test can be triggered by initiating a call to user2@realmA
from UA1. The presence of SIP and/or SIPS URI for user2@realmA in
vendor B can be done via SIP registration in Section 4.3.1.1 or some
other means. The test scenarios below assumes vendor D is the
allocated/assigned SIP server for user2@realmA.
o Positive test for location query using Diameter server. Vendor B
is pre-provision in vendor A as location server. for realmA.
Verify that a call (SIP INVITE) from UA1 to user2@realmA triggers
vendor A to send an LIR towards vendor B. Verify that vendor B
forwards the INVITE to vendor D upon receipt of LIA.
o Positive test for location query using Diameter SL. Vendor C is
pre-provisioned in vendor A as the location server. Verify that
the INVITE from UA1 to user2@realmA triggers vendor A to send an
LIR towards vendor C. Verify LIA redirection from vendor C causes
an LIR to be forwarded to vendor B.
o Negative test for failed authorization. Verify the behavior of
vendor B and D when the criteria for the following errors are
meet.
* 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]. These
test should be performed as a consequence of Section 4.3.1.1. In the
enumerated test scenarios, vendor A request removal of user bindings
in vendor B. This maybe a consequence of user1@reamlB logging off on
UA1 (Section 10.2.2 in [RFC3261]) or an expiration of usage timer in
vendor B. It is left to the implementation to configure such
scenario.
o Positive test for soft termination when session is stateless and
Diameter 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
Fajardo, et al. Expires July 5, 2007 [Page 35]
Internet-Draft Diameter Interoperability Test Suite January 2007
Section 6.9 of [I-D.ietf-aaa-diameter-sip-app]. This scenario is
synonymous to Figure 8.
o Positive test for soft termination when session is stateless and
Diameter server initiates termination. Verify that at the least,
vendor B can send an RTR to vendor D to AOR(s) for user1@realmB.
Testers can also simulate multiple AORs for the user and verify
that RTR can selectively remove specific AORs. It is left to the
testers to simulate a SIP-deregistration-reason from the Diameter
server. This scenario is synonymous to Figure 10.
o Positive test for soft termination when session is stateful and
Diameter 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 and
Diameter server initiates termination. Verify that at the least,
vendor B can send an ASR to vendor B. Verify application id value
carried by the STR/STA message is that of the target application.
It is left to the testers to simulate session termination on the
Diameter server, i.e., session-timeout or registration timeout.
4.4. 3GPP Interface Test Suite
The test suite in this section only covers the following IMS
interfaces. 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 assumptions
have been made in terms of the test topology. Since recreating an
IMS network is not realistic, only entities implementing Diameter
applications will be involved in these test cases. Peripheral
entities that instigate a test event should be simulated.
4.4.1. Diameter Cx
Implementations must conform to [TS29.228] and [TS29.229]. Since
Diameter Cx describes the same application as Diameter SIP, the test
topology and scenarios in Section 4.3 is applicable. For brevity,
this section will only provide addendums to the existing test suites
Fajardo, et al. Expires July 5, 2007 [Page 36]
Internet-Draft Diameter Interoperability Test Suite January 2007
in Section 4.3 as it applies to Diameter Cx. Authentication schemes
present 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 Vendor
Node Equivalent Assignments
----------------+---------------------+-----------------------
I-CSCF SIP Server 1 Vendor A, I-CSCF
on Home Network
HSS Diameter Server Vendor B, HSS
on Home Network
S-CSCF SIP Server 2 Vendor D, S-CSCF
on Home Network
P-CSCF Optional Use UA1 to simulate
P-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-registration
described in Section A.4.2 and A.4.3 of [TS29.228] can use UA1 to
simulate a P-CSCF. S-CSCF functions that rely on other entities such
as AS may also be simulated when service initiated test needs to be
performed. An AS maybe present to facilitate this though it is left
up to the implementation to provide an AS and verify its
configuration.
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. Verify
that a de-registration initiated by S-CSCF (vendor C) triggers the
removal of server assignments in vendor B. Verify SAR/SAA exchange
occurs. Message flow can be as follows.
Fajardo, et al. Expires July 5, 2007 [Page 37]
Internet-Draft Diameter Interoperability Test Suite January 2007
+--------+ +--------+
|Diameter| | SIP |
| server | |server 2|
|Vendor B| |Vendor D|
+--------+ +--------+
| |
| 1. Simulated Service De-registration
2. De-register | |
<--------------------------------------|
| |
3. SIP 200 (OK) | |
------------------------------------->|
| 4. SAR |
|<------------------|
| 5. SAA |
|------------------>|
| |
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 by
vendor B for that call. Verify that the SIP INVITE also triggers
a location query (LIR/LIA exchange) with vendor B. Message flow
can be as follows.
+--------+ +--------+ +--------+
| SIP | |Diameter| | SIP |
|server 1| | server | |server 2|
|Vendor A| |Vendor B| |Vendor D|
+--------+ +--------+ +--------+
| | |
1. SIP INVITE | | |
-------------------->| 2. LIR | |
|------------------>| |
| 3. LIA | |
|<------------------| |
| | |
| 4. INVITE | |
|-------------------------------------->|
| | 5. SAR |
| |<------------------|
| | 6. SAA |
| |------------------>|
| | |
Figure 13: Message Flow for Session Initiation to a Non-registered
User
Fajardo, et al. Expires July 5, 2007 [Page 38]
Internet-Draft Diameter Interoperability Test Suite January 2007
Normally, server selection is performed during this process.
Testers can verify if vendor A correctly determine vendor D as the
assigned SIP server. Additional service control functions may
also need to be performed by vendor D. Though those would be out
of scope of this document.
4.4.2. Diameter Sh
Implementations must conform to [TS29.328] and [TS29.329]. The test
topology for Diameter Sh is Figure 14. Because AS functionality is
implementation and service specific, it is left to the testers to
verify configuration of the provided service. UA registration with
AS services are also left up to the tester to verify. Some
interaction with the test topology for Section 4.4.1 maybe required
in certain test scenarios.
Home Network
+--------+ +--------+
|Diameter| | AS |
IMS Network <---Cx--->| 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 shown
for 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 AS
uses Diameter Sh with the HSS and SIP with S-CSCF and UA1 in the IMS
network. For Diameter Sh, the message flow being tested is defined
in Section B.1 of [TS29.328]. It is left to the testers to verify
that the AS is properly configured in the IMS network.
Fajardo, et al. Expires July 5, 2007 [Page 39]
Internet-Draft Diameter Interoperability Test Suite January 2007
4.4.2.1. Required
The following are test scenarios to exercise Diameter Sh interface.
o Positive test for data handling. Implementations must conform to
Section 6.1.1 and 6.1.2 of [TS29.328]. Verify that vendor E is
capable of storing and retrieving service related data into vendor
B via PUR/PUA and UDR/UDA. If user1 in UA1 can register for
service to the vendor E, verify that vendor E is able to store
service related data into vendor B. If user1 can then register to
vendor D in the IMS network and trigger a third-party registration
to vendor E, verify that vendor E is able pull service related
data 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 must
conform to Section 6.1.3 and 6.1.4 of [TS29.328]. Verify that
vendor E can successfully subscribe to notification in case of
data changes in vendor B. This test should be performed after the
previous positive test. Simulation of data changes in vendor B is
implementation specific. Verify that vendor B sends a PNR to E
when simulated changes occur.
o Negative test for data update. Verify behavior of both vendor B
and E when the criteria for following experimental result codes
are meet.
* DIAMETER_ERROR_USER_DATA_CANNOT_BE_MODIFIED. Simulate update
restrictions for vendor E in vendor B.
* DIAMETER_ERROR_USER_UNKNOWN.
* DIAMETER_ERROR_OPERATION_NOT_ALLOWED. Simulate restrictions on
vendor B. Configuration of AS permission list maybe necessary.
* DIAMETER_PRIOR_UPDATE_IN_PROGRESS.
* DIAMETER_ERROR_TRANSPARENT_DATA_OUT_OF_SYNC. Simulation may
require some invalid configuration.
* DIAMETER_ERROR_TOO_MUCH_DATA. Simulation may require some
invalid configuration.
Fajardo, et al. Expires July 5, 2007 [Page 40]
Internet-Draft Diameter Interoperability Test Suite January 2007
o Negative test for data read and notification subscriptions.
Verify behavior of both vendor B and E when the criteria for
following experimental result codes are meet during data pull or
subscription.
* DIAMETER_ERROR_USER_DATA_CANNOT_BE_READ. Simulate read
restrictions for vendor E in vendor B.
* DIAMETER_ERROR_USER_UNKNOWN.
* DIAMETER_ERROR_OPERATION_NOT_ALLOWED. Simulate restrictions on
vendor B. Configuration of AS permission list maybe necessary.
4.4.3. Diameter Rf
Implementations must conform to [TS32.260]. The test topology for
Diameter Rf is Figure 15. The test cases in this section do not
attempt to cover all accounting scenarios that are possible in an IMS
network. It only exercise accounting functions for test entities
listed in Figure 11. Because the test topology only describes a home
network, 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 and
to the AS in Figure 14 if an AS is used. The test scenarios also
makes a lot of assumptions in testing non-Diameter related Rf
requirements such as the CDR formats, operator configuration of the
CDF, SIP based signaling or operator based decision on when to use
offline-charging etc. Since there can be a multitude of
configuration options, verification of actual billing schemes used
and its accuracy is left to the testers. For the purpose of Diameter
interoperability, the test scenarios in Section 4.1.1.2 applies here
as well.
IMS Network
+----------+
| |
<----ACR/ACA to SIP Server 1 ----->| CDF |
| Vendor F |
<----ACR/ACA to SIP Server 2 ----->| |
+----------+
Legend:
IMS Network - Test topology for Diameter SIP and/or
Diameter Sh. Network details are not
shown for brevity.
CDF - Vendor F acting CDF for Home Network.
Fajardo, et al. Expires July 5, 2007 [Page 41]
Internet-Draft Diameter Interoperability Test Suite January 2007
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 must
conform to Table 5.2.1.1 of [TS32.260]. Verify that vendor A or D
generates a START_RECORD on positive acknowledgment of SIP INVITE.
The SIP server involved depends on the UA location. The test
could be performed as part of Section 4.3.1.3. Note that only the
mandatory triggers are recommended to be tested. The remaining
triggers specified in Table 5.2.1.1 of [TS32.260] is left up to
the test pairs.
o Positive test for SIP session updates. Implementations must
conform to Table 5.2.1.1 of [TS32.260]. Verify that vendor A or D
generates an INTERIM_RECORD on a SIP re-INVITE or UPDATE for an
existing SIP session. The test can be performed in sequence with
the previous positive test.
o Positive test for session-unrelated procedures. Implementations
must conform to Section 5.2.2.1.5 of [TS32.260]. Verify that
vendor A or D generates EVENT_RECORD on a SIP SUBSCRIBE signal.
The test can be performed in sequence with the previous positive
test.
o Positive test for SIP session termination. Implementations must
conform to Table 5.2.1.1 of [TS32.260]. Verify that vendor D
generates STOP_RECORD on a SIP BYE signal. The test can be
performed in sequence with the previous positive test.
o Negative test for unsuccessful SIP session establishment. Verify
that if a SIP session establishment fails, that vendor A or D
generates an EVENT_RECORD. The SIP server involved depends on the
location of the UA initiating the session.
o Negative test for error cases. Verify that vendor A and/or D
follows Section 5.2.2.2 of [TS32.260]. The error cases in that
text 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 Rf
interface. Note that details of the tests are skipped for brevity.
o Positive test for multi-party call. Assuming a new UA is
introduced in the home network and S-CSCF is provided by vendor D,
Fajardo, et al. Expires July 5, 2007 [Page 42]
Internet-Draft Diameter Interoperability Test Suite January 2007
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 to
the 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 Application
must conform to [RFC4072]. A typical test for network access
authentication using Diameter EAP is shown in Figure 16. The User
has an EAP Client to be authenticated for network access. The test
cases only cover the NAS and Auth. Servers interoperability. To
perform these tests, one must choose an EAP method. It is
recommended to use an authentication method which derive keying
material to test key transport between Auth. Server and NAS. As an
example, EAP-TLS [RFC2716] can be used.
+--------+ +--------+ +---------------+
| User |<--->| NAS |<--->| Auth Server 1 |
| | |Vendor A| | Vendor B |
+--------+ +--------+ +---------------+
^
|
|
v
+---------------+
| Auth Server 2 |
| Vendor C |
+---------------+
Legend:
User
NAS - Vendor A Diam EAP client
Auth Server 1 - Vendor B Diam EAP server
Auth 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.
Fajardo, et al. Expires July 5, 2007 [Page 43]
Internet-Draft Diameter Interoperability Test Suite January 2007
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 contains
the same Session-Id AVP.
o Positive test for EAP initiation. Verify that the Auth. server
initiates an EAP session while receiving either a DER containing
an 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 the
User in the EAP exchange between User and NAS.
o Positive test for user registration. Verify that the Auth. server
1 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 EAP
authentication method derives keys, verify that the Auth. Server
correctly provide keying material to the NAS and that these keys
are correctly used between User and NAS.
o Positive test for session termination: User Disconnection. Verify
that if the User disconnects for the NAS, the NAS sends a STR
message to the Auth. Server. Verify that the Auth. Server
releases 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 to
the Auth. server. Verify that the Auth. Server releases all
state concerning this User.
o Negative test for authentication. Verify that the Auth. Server
sends a DEA message containing a DIAMETER_AUTHENTICATION_REJECTED
result-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 while
NAS and Auth. Server 1 belongs to realm A. All tests described in
the Non-Roaming scenario must work. As we are in roaming scenario,
Fajardo, et al. Expires July 5, 2007 [Page 44]
Internet-Draft Diameter Interoperability Test Suite January 2007
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 messages
to Auth. Server 2.
o Positive test for Diameter EAP Proxy Routing. Verify that if NAS
and Auth. Servers are correctly configured, Diameter EAP messages
are 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 some
authorizations are requested, the DEA containing the
DIAMETER_SUCCESS in the Result-Code AVP also contains appropriate
Authorization AVPs (cf. section 5 of [RFC4005]).
o Positive test for Accounting. Verify that NAS initiates
Accounting if authentication is successful and finishes it while
terminating 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 Scenario
described 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 authentication
shown in Figure 17. Multi-domain test should use Figure 3. The User
entity typically employs PPP to access the NAS and is normally
implementation dependent. Since the test cases covers only NAS and
Auth Server interoperability, it is left to the tester to verify
correctness of the access method between User and NAS and that this
method is able to trigger creation of a NASREQ client session in the
NAS.
Fajardo, et al. Expires July 5, 2007 [Page 45]
Internet-Draft Diameter Interoperability Test Suite January 2007
+--------+ +--------+ +-------------+
| User |<--->| NAS |<--->| Auth Server |
| | |Vendor A| | Vendor B |
+--------+ +--------+ +-------------+
Legend:
User - Simulated user
NAS - Vendor A Diam NASREQ client
Auth Sever - Vendor B Diam NASREQ server
Figure 17: Diameter NASREQ Test Topology
Another test topology can exist for testing Diameter/RADIUS gateways
as specified in Section 9 of [RFC4005]. This topology is available
for vendors implementing a translation gateway. It should simulate a
common deployment scenario where there is a prevalence of legacy
RADIUS access devices ([RFC2865]). Since the test cases covers
interoperability scenarios, validation must be done between NAS and
Gateway. As with Figure 17, it is left to the tester to verify
correctness of the access method between User and NAS. The test
cases involving Figure 17 is also relevant to validating Gateway and
Auth Server and should be used in this topology as well.
+--------+ +--------+ +---------+ +-------------+
| User |<--->| NAS |<--->| Gateway |<--->| Auth Server |
| | | | |Vendor A | | Vendor B |
+--------+ +--------+ +---------+ +-------------+
Legend:
User - Simulated user
NAS - Simulated or vendor RADIUS client
Gateway - Vendor A Diameter/RADIUS gateway
Auth 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]. Test
topology Figure 17 can be used for these cases. These tests
typically involves a myriad of configuration options. At the least
an implementation must be able to grant access to a user with a
reasonable level of security given the test cases below. The minimum
test that should be performed is PPP CHAP and PPP EAP with MD5
method. These tests are heavily dependent on other parameters that
are implementation specific (username, password, medium type,
Fajardo, et al. Expires July 5, 2007 [Page 46]
Internet-Draft Diameter Interoperability Test Suite January 2007
calling-station-id etc). It is left to the tester to verify
correctness of this process but it must conform to Section 2.1, 3.1
and 3.2 of [RFC4005]. This includes conformance to the use of
transport level security (TLS or IPsec) for signaling sensitive
information, i.e., passwords etc. This test is also an overlap with
Section 4.1.1.1.1. Verification of test cases can be done manually.
o Positive test for proper Auth server session establishment with
authorization and authentication. Verify that user can initiate
an access-request via vendor A and that vendor B can respond when
PPP negotiation begins. Vendor A and B can agree on the service-
type. Verify that at the least B can support auth-request-type
AUTHORIZE_AUTHENTICATE.
o Positive test for proper NAS session establishment with
authorization and authentication. Verify that user can initiate
an access-request via vendor A and that vendor B can respond when
PPP negotiation begins. Verify that A is able to support
DIAMETER_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 to
conform to Section 4.1 of [RFC4005].
o Positive test for proper session termination. Verify that a NAS
can initiate termination upon user disconnection. Verify that the
auth server can abort a session. Must conform to Section 2.3 of
[RFC4005]. Test can overlap with Section 4.1.1.1.1.
o Positive test for installation of NAS-filter-rules. Filter rule
implementation should at least carry the form IPFilterType as
specified in Section 4.3 of [RFC3588]. Verify that the rules sent
by the auth server is installed properly in the NAS for the
specific user. Note that implementation extensions done to the
NAS-filter-rule can affect interoperability between peers. If
commonality or agreements among implementations regarding the
definition of NAS-filter-rule can be found and it deviates from
the specification, it should be duly noted and used as a basis for
specifying future NAS-filter-rule extensions.
o Negative test for session failure when service type is
unsupported. Verify that the auth server can terminate the
session with DIAMETER_INVALID_AVP_VALUE for an unsupported service
type.
Fajardo, et al. Expires July 5, 2007 [Page 47]
Internet-Draft Diameter Interoperability Test Suite January 2007
4.6.1.2. Diameter/RADIUS Gateway
Implementations must conform to Section 9 of [RFC4005]. Test
topology Figure 18 can be used for these cases. Validation of these
tests maybe localized to the Gateway (vendor A) but for the purpose
of interoperability, end-to-end authentication and/or authorization
must succeed between User and Auth Server (vendor B).
o Positive test for forwarding RADIUS request as Diameter request.
Verify that Section 9.1 of [RFC4005] is followed and that
transaction states are maintained by the Gateway on behalf of the
RADIUS client.
o Positive test for forwarding RADIUS response from Diameter
responses. Verify that Section 9.1 of [RFC4005] is followed and
the session generated from the original RADIUS request is
maintained.
o Negative test for terminating a Diameter session upon auth
failure. Conditions for termination is specified in Section 9.1
of [RFC4005].
4.6.1.3. Multi-domain Scenario
Test cases in this section is synonymous to Section 4.6.1.1 and all
requirements in that section apply here as well. These scenarios,
however, uses Figure 3 instead. Vendor A1 can acts as the NAS and B1
or B2 can act as the auth server. A2 or B1 can act as either a
proxy/agent or redirect agent for A1. As with Section 3.1.2, these
tests are symmetric to both vendors.
o Positive test for multi-domain auth using proxy/relay agent.
Verify that A2 acting as a proxy/relay can reliably forward auth-
request and answers between A1 and B2. All test cases enumerated
in Section 4.6.1.1 must be performed. Note that this test cases
overlap with Section 3.1.3 and must conform to all requirements of
those test.
o Positive test for multi-domain auth using redirect agent. Verify
that A2 or B1 acting as a redirect can successfully respond with
redirect information to A1. All test cases enumerated in
Section 4.6.1.1 must be performed. Note that this test cases
overlap with Section 3.1.4 and must conform to all requirements of
those test.
Fajardo, et al. Expires July 5, 2007 [Page 48]
Internet-Draft Diameter Interoperability Test Suite January 2007
4.6.2. Optional
Implementations must conform to Section 2 of [RFC4005]. Test
topology uses Figure 17. These are optional test that
implementations can perform.
4.6.2.1. Auth Session
Implementations must conform to Section 2 of [RFC4005]. These test
cases are in support of Section 4.6.1.1.
o Positive test for proper NASREQ accounting. Verify that
accounting session is initiated by vendor A if supported by the
implementation. Implementations must conform to Section 8 of
[RFC4005]. Test can overlap with Section 4.1.1.2.
o Positive test for session re-authentication if supported. Must
conform to Section 2.2 of [RFC4005]. Behavior maybe dependent on
implementation and policy however auth-lifetime and auth-grace-
period must be utilized. Must conform to 8.3 of [RFC3588]. Test
can overlap with Section 4.1.1.1.1.
4.7. Diameter MIP Test Suite
Vendors that support Diameter Mobile IPv4 extension must conform to
[RFC4004]. There are typically several topologies that is possible
when deploying Diameter MIP. Those which are more likely to be
deployed are included in this document. The test cases are also
highly dependent on the topologies themselves hence each test case
provides its own test topology. Configuration of the mobility agents
(Mobile, HA and FA) for all test cases are implementation specific
and it is left up to the tester to verify their correctness. Testers
must also verify that the MIP implementation conforms to Section 4 of
[RFC4004] as it relates to Diameter. Testers must also ensure that
all positive test resulting in successful authentication and/or
authorization must generate appropriate session keys and MSAs as
needed. It should conform to [RFC3957] and [RFC3012] as it applies.
This is implementation and policy dependent but can be as a
consequence of positive test cases so it is worthwhile to verify.
4.7.1. Generic MIP Test Scenarios
The following are generic test scenarios that can be applied to any
MIP test topology. It is enumerated here for simplicity since it is
common to all topology.
o Positive test for mobile registration. Verify that at the least,
the HA can authenticate and authorize the Mobile given the proper
Fajardo, et al. Expires July 5, 2007 [Page 49]
Internet-Draft Diameter Interoperability Test Suite January 2007
configuration (MIP authorization extensions. Verify that the AAA
message flows for the specific topology is followed. Verify that
proper key distribution occurs in the process. If accounting is
supported, verify that accounting-sub-session-id is used. This
test can overlap with Section 4.1.1.2.1.
o Positive test for session termination. Verify that the expiration
of auth-lifetime causes an STR to be sent from the HA and that the
message flows are valid. Verify that the AAAH releases all
session state it keeps if any. The AAAH must conform to Section
4.1.3 of [RFC4004].
o Positive test for re-authentication. Verify that the Mobile can
successfully performs re-authentication if policy allows. Verify
that the AMR sent by the FA or Mobile on re-auth and carries the
original session-id, HA NAI and AAAH NAI as appropriate.
Implementations must conform to [RFC3846].
o Negative test for failed registration or authentication. Verify
that a failed authentication or registration causes an STR to be
sent from the HA and that DIAMETER_AUTHENTICATION_REJECTED result-
code is communicated back to the FA or Mobile in the AMA. Verify
that the AAAH releases all session state it keeps if any. AAAH
must conform to Section 4.1.3 of [RFC4004].
4.7.2. Required
4.7.2.1. Co-located Registration
Implementation must conform to Section 3.3 of [RFC4004]. Test
topology for co-located mobile node deployment is shown below in
Figure 19. Both HA and AAAH share the same realm which can be a home
or foreign realm of the Mobile. Verifying the correctness of the
Mobile to HA registration is out of scope for this document is left
to the tester. However, it must conform to [RFC3344] and its
successor document. Note also that there is a myriad of
configuration options for this test case and it is left to the test
pairs to agree on which and on how many configuration can and should
be tested.
Fajardo, et al. Expires July 5, 2007 [Page 50]
Internet-Draft Diameter Interoperability Test Suite January 2007
+--------+ +--------+ +-------------+
| Mobile |<--->| HA |<--->| AAAH |
| | |Vendor A| | Vendor B |
+--------+ +--------+ +-------------+
Legend:
Mobile - Mobile is IPv4 mobile node
HA - Vendor A as a MIP Home Agent
AAAH - Vendor B as a Home AAA server
Figure 19: Test Topology for Co-located Mobile Node
o All test scenarios in Section 4.7.1 must be performed.
4.7.2.2. Intra-Domain Registration
Implementation must conform to [RFC4004]. The basic test topology
for single domain registration is shown below in Figure 20. All
entities share the same realm with FA and HA presiding over different
networks. The topology can be a combination of different vendor
implementations. Testers must verify that the AAA message flows in
Figure 20 are followed for the registration process.
+---------+
| AAAH |
|Vendor B |
+---------+
AMR/AMA / \ HAR/HAA
/ \
+---------+ +---------+
| FA | | HA |
|Vendor A | |Vendor C |
+---------+ +---------+
^
| Mobile IP
v
+---------+
| Mobile |
+---------+
Legend:
Mobile - Mobile is IPv4 mobile node
FA - Vendor A as a MIP Foreign Agent
AAAH - Vendor B as a Home AAA server
HA - Vendor C as a MIP Home Agent
Figure 20: Test Topology for Intra-Domain MIP
Fajardo, et al. Expires July 5, 2007 [Page 51]
Internet-Draft Diameter Interoperability Test Suite January 2007
o All test scenarios in Section 4.7.1 must be performed. If
[RFC3846] is supported, MIP NAIs should be used to route the AMRs
towards the AAAH. This test can overlap with Section 4.1.1.2.1
and Section 3.1.2.2.
o Positive test for handover. Verify that if Mobile performs a
handover to HA that de-registration occurs properly and subsequent
AMR/AMA exchanges are appropriate. Verify also that the
accounting session is maintained if any.
o Negative test for failed allocation of home agent. Vendor B can
be configured not to provide a home agent for the Mobile. Verify
that DIAMETER_ERROR_HA_NOT_AVAILABLE is sent by vendor B to vendor
A. Verify that the B releases all session state it keeps if any.
Vendor B must conform to Section 4.1.3 of [RFC4004].
4.7.2.3. Inter-Domain Registration
Implementation must conform to Section 3.1 of [RFC4004]. The basic
test topology for inter-domain registration is shown below in
Figure 21. A1 and A2 reside in realmA and B1 and B2 reside in
realmB. The entities in the topology can be a combination of
different vendor implementations. Verifying the correctness of the
Mobile to FA discovery and registration is implementation specific
and out of scope of this document. It is left to the tester to
validate this process but it must conform to requirements [RFC3344]
and its successor document. As with previous test cases in Diameter
MIP, there is a myriad of configuration options for this test case
and it is left to the test pairs to agree on which and on how many
configuration can and should be tested. However, testers must verify
that the AAA message flows in Figure 21 are followed for the
registration process regardless of configuration.
Fajardo, et al. Expires July 5, 2007 [Page 52]
Internet-Draft Diameter Interoperability Test Suite January 2007
realmA (visited) realmB (home)
+---------+ +---------+
| AAAF | AMR/AMA | AAAH |
|Vendor A2|<----------->|Vendor B2|
+---------+ +---------+
^ ^
AMR/AMA | | HAR/HAA
v v
+---------+ +---------+
| FA | | HA |
|Vendor A1| |Vendor B1|
+---------+ +---------+
^
| Mobile IP
v
+---------+
| Mobile | mn@realmB.com
+---------+
Legend:
Mobile - Mobile is IPv4 mobile node
FA - Vendor A1 as a MIP Foreign Agent
AAAF - Vendor A2 as a Foreign AAA server
AAAH - Vendor B2 as a Home AAA server
HA - Vendor B1 as a MIP Home Agent
Figure 21: Test Topology for Inter-Domain MIP
o All test scenarios in Section 4.7.1 must be performed. If
[RFC3846] is supported, MIP NAIs should be used to route the AMRs
towards the AAAH. This test can overlap with Section 4.1.1.2.1
and Section 3.1.2.2.
o Positive test for handover. Verify that if Mobile performs a
handover to B1 that de-registration occurs properly and subsequent
AMR/AMA exchanges are appropriate. Verify also that the
accounting session is maintained if any.
o Negative test for failed allocation of home agent. B2 can be
configured not to provide a home agent for the Mobile. Verify
that DIAMETER_ERROR_HA_NOT_AVAILABLE sent by B2 is propagated to
FA via the AMA. Verify that the B2 releases all session state it
keeps if any. B2 must conform to Section 4.1.3 of [RFC4004].
Fajardo, et al. Expires July 5, 2007 [Page 53]
Internet-Draft Diameter Interoperability Test Suite January 2007
4.7.2.4. Allocation of HA in Foreign Network
Implementation must conform to Section 3.2 of [RFC4004]. The basic
test topology for dynamically allocated HA is shown below in
Figure 22. A1, A2 and A3 reside in realmA and B1 resides in realmB.
The entities in the topology can be a combination of different vendor
implementations. Policies in AAAF and AAAH must support dynamic
allocation of an HA. Testers must verify that the AAA message flows
in Figure 22 are followed for the registration and HA allocation
process.
realmA realmB
+---------+ ------- AMR ------> +---------+
| AAAF | <----- HAR -------- | AAAH |
+--->|Vendor A3| ------- HAA ------> |Vendor B1|
| +---------+ <----- AMA -------- +---------+
| ^ |
| | |
HAR/HAA | AMR | | AMA
v | v
+---------+ +---------+
| HA | | FA |
|Vendor A2| |Vendor A1|
+---------+ +---------+
^
+--------+ Mobile IP|
| Mobile |<----------+
+--------+
Legend:
Mobile - Mobile is IPv4 mobile node
FA - Vendor A1 as a MIP Foreign Agent
AAAF - Vendor A3 as a Foreign AAA server
AAAH - Vendor B1 as a Home AAA server
HA - Vendor A2 as a MIP Home Agent
Figure 22: Test Topology for Allocation of HA in Foreign Network
o All test scenarios in Section 4.7.1 must be performed. If
[RFC3846] is supported, MIP NAIs should be used to route the AMRs
towards the AAAH. This test can overlap with Section 4.1.1.2.1
and Section 3.1.2.2. For test scenarios resulting in the
termination of the session, verify that the HA allocated in A2 is
released if policy permits.
o Negative test for failed allocation of home agent. B1 can be
configured not to provide a home agent for the Mobile. Verify
that DIAMETER_ERROR_HA_NOT_AVAILABLE sent by B1 is propagated to
Fajardo, et al. Expires July 5, 2007 [Page 54]
Internet-Draft Diameter Interoperability Test Suite January 2007
A1. Verify that the B1 releases all session state it keeps if
any. B1 must conform to Section 4.1.3 of [RFC4004].
4.7.3. Optional
Vendors that support Diameter Mobile IPv4 extension must conform to
[RFC4004]. The following are optional test cases that can be
performed for Diameter MIP.
4.7.3.1. Co-located Registration via Redirect Indication
An addendum to the topology shown in Figure 21 is shown in Figure 23.
The redirect agent is introduced if additional transport security is
required between HA and AAAH in the co-located scenario as described
in Section 3.3 of [RFC4004]. Optional IPsec or TLS connectivity can
be established between HA and AAAH. For simplicity Figure 23 differs
from Figure 8 of [RFC4004] by not having an AAA proxy but relying on
the redirect agent directly.
+----------+
| Redirect |
| Vendor B1|
+----------+
|
|
+--------+ +--------+ +-------------+
| Mobile |<--->| HA |<--->| AAAH |
| | |Vendor A| | Vendor B2 |
+--------+ +--------+ +-------------+
Legend:
Mobile - Mobile is IPv4 mobile node
HA - Vendor A as a MIP Home Agent
Redirect - Vendor B1 redirect agent
AAAH - Vendor B2 as a Home AAA server
Figure 23: Test Topology for Co-located Mobile Node with Redirect
o Positive test for mobile registration. Verify that redirection
occurs between HA and Redirect agent. Verify that a secure
transport is established between HA and AAAH. Verify that at the
least, vendor B2 can authenticate and authorized the Mobile given
the proper configuration. This test can overlap with
Section 4.1.1.2.1 and Section 3.1.2.2.
o Verify that the all test cases in Section 4.7.2.1 is be applied in
this test case as well. This test case is an overlap with
Section 3.1.4 and requirements in that section applies here.
Fajardo, et al. Expires July 5, 2007 [Page 55]
Internet-Draft Diameter Interoperability Test Suite January 2007
4.7.3.2. Inter-Domain Registration with Redirect
An addendum to the topology shown in Figure 21 is shown in Figure 24.
The redirect agent B3 is introduced if additional transport security
is required and the use of an AAAF can be skipped. In this topology
B3 shares the same realm a B1 and B2. Optional IPsec or TLS
connectivity can be established between A1 and B2 as describe in
Figure 3 of [RFC4004]. However, the secure connectivity can be
omitted to simplify testing.
+---------+
|Redirect |
|Vendor B3|
+---------+
/
realmA (visited) / realmB (home)
+---------+ +---------+
| AAAF | AMR/AMA | AAAH |
|Vendor A2| -------|Vendor B2|
+---------+ / +---------+
^ / ^
AMR/AMA | / | HAR/HAA
v / v
+---------+ / +---------+
| FA | | HA |
|Vendor A1| |Vendor B1|
+---------+ +---------+
^
| Mobile IP
v
+---------+
| Mobile | mn@realmB.com
+---------+
Legend:
Mobile - Mobile is IPv4 mobile node
FA - Vendor A1 as a MIP Foreign Agent
AAAF - Vendor A2 as a Foreign AAA server
AAAH - Vendor B2 as a Home AAA server
HA - Vendor B1 as a MIP Home Agent
Redirect - Vendor B3 as a Redirect agent in reamlA
Figure 24: Test Topology for Inter-Domain MIP with Redirect
o Positive test for mobile registration. Verify that at the least,
B1 acting as HA can authenticate and authorize the Mobile given
the proper configuration. Verify that a secure transport is
established between A1 and B2 if used. If accounting is
Fajardo, et al. Expires July 5, 2007 [Page 56]
Internet-Draft Diameter Interoperability Test Suite January 2007
supported, verify that accounting-sub-session-id is used. If
[RFC3846] is supported, MIP NAIs should be used to route the
message towards the HA. This test can overlap with
Section 4.1.1.2.1 and Section 3.1.2.2.
o Positive test for handover. Verify that if Mobile performs a
handover to B1 that de-registration occurs properly and subsequent
AMR/AMA exchanges are appropriate. Verify also that the
accounting session is maintained if any.
o Verify that the all test cases in Section 4.7.2.3 is be applied in
this test case as well. This test case is an overlap with
Section 3.1.4 and requirements in that section applies here.
4.7.3.3. Inter-Domain Registration with Proxy/Relay
An addendum to the topology shown in Figure 21 is shown in Figure 25.
The proxy/relay agent B3 exists between A2 and B2. In this topology
B3 shares the same realm as B1 and B2.
Fajardo, et al. Expires July 5, 2007 [Page 57]
Internet-Draft Diameter Interoperability Test Suite January 2007
+------------+
|Proxy/Relay |
|Vendor B3 |
+------------+
/ AMR/AMA \
realmA (visited) / \ realmB (home)
+---------+ +---------+
| AAAF | | AAAH |
|Vendor A2| |Vendor B2|
+---------+ +---------+
^ ^
AMR/AMA | | HAR/HAA
v v
+---------+ +---------+
| FA | | HA |
|Vendor A1| |Vendor B1|
+---------+ +---------+
^
| Mobile IP
v
+---------+
| Mobile | mn@realmB.com
+---------+
Legend:
Mobile - Mobile is IPv4 mobile node
FA - Vendor A1 as a MIP Foreign Agent
AAAF - Vendor A2 as a Foreign AAA server
AAAH - Vendor B2 as a Home AAA server
HA - Vendor B1 as a MIP Home Agent
Redirect - Vendor B3 as a Redirect agent in reamlA
Figure 25: Test Topology for Inter-Domain MIP with Proxy/Relay
o Positive test for mobile registration. Verify that at the least,
B1 acting as HA can authenticate and authorize the Mobile given
the proper configuration. Verify that B3 can reliably relay AMR/
AMA exchanges between A1 and A2. If accounting is supported,
verify that accounting-sub-session-id is used. If [RFC3846] is
supported, MIP NAIs should be used to route the message towards
the HA. This test can overlap with Section 4.1.1.2.1 and
Section 3.1.2.2.
o Verify that the all test cases in Section 4.7.2.3 is be applied in
this test case as well.
o Positive test for handover. Verify that if Mobile performs a
handover to B1 that de-registration occurs properly and subsequent
Fajardo, et al. Expires July 5, 2007 [Page 58]
Internet-Draft Diameter Interoperability Test Suite January 2007
AMR/AMA exchanges are appropriate. Verify also that the
accounting session is maintained if any.
Fajardo, et al. Expires July 5, 2007 [Page 59]
Internet-Draft Diameter Interoperability Test Suite January 2007
5. Security Considerations
This document defines test cases and therefore tests various aspects
of the Diameter base specification and various Diameter applications.
Fajardo, et al. Expires July 5, 2007 [Page 60]
Internet-Draft Diameter Interoperability Test Suite January 2007
6. IANA Considerations
This document does not require actions by IANA.
Fajardo, et al. Expires July 5, 2007 [Page 61]
Internet-Draft Diameter Interoperability Test Suite January 2007
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS Authentication
Protocol", RFC 2716, October 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3012] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/
Response Extensions", RFC 3012, November 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3846] Johansson, F. and T. Johansson, "Mobile IPv4 Extension for
Carrying Network Access Identifiers", RFC 3846, June 2004.
[RFC3957] Perkins, C. and P. Calhoun, "Authentication,
Authorization, and Accounting (AAA) Registration Keys for
Mobile IPv4", RFC 3957, March 2005.
[RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and
P. McCann, "Diameter Mobile IPv4 Application", RFC 4004,
August 2005.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005,
August 2005.
[RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and J.
Loughney, "Diameter Credit-Control Application", RFC 4006,
August 2005.
Fajardo, et al. Expires July 5, 2007 [Page 62]
Internet-Draft Diameter Interoperability Test Suite January 2007
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072,
August 2005.
[I-D.ietf-aaa-diameter-sip-app]
Garcia-Martin, M., "Diameter Session Initiation Protocol
(SIP) Application", draft-ietf-aaa-diameter-sip-app-12
(work in progress), April 2006.
[TS29.228]
3GPP, "IMS Cx and Dx interfaces : signalling flows and
message contents", 3GPP TS 29.228 Version 7.0.0 2006.
[TS29.229]
3GPP, "IMS Cx and Dx interfaces based on the Diameter
protocol; Protocol details", 3GPP TS 29.229 Version
7.0.0 2006.
[TS29.328]
3GPP, "IMS Sh interface : signalling flows and message
content", 3GPP TS 29.328 Version 6.8.0 2005.
[TS29.329]
3GPP, "IMS Sh interface based on the Diameter protocol;
Protocol details", 3GPP TS 29.329 Version 6.6.0 2005.
[TS32.260]
3GPP, "IP Multimedia Subsystem (IMS) Charging", 3GPP TS
32.260 Version 6.4.0 2005.
Fajardo, et al. Expires July 5, 2007 [Page 63]
Internet-Draft Diameter Interoperability Test Suite January 2007
Authors' Addresses
Victor Fajardo
Toshiba America Research, Inc.
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 5368
Email: vfajardo@tari.toshiba.com
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
Siemens
Phone: +49 89 636 40390
Email: hannes.tschofenig@siemens.com
Julien Bournelle
Institut National des Telecommunications
9 rue Charles Fourier
Evry cedex, 91011
France
Phone: +33 1 60 76 44 79
Email: julien.bournelle@int-evry.fr
Fajardo, et al. Expires July 5, 2007 [Page 64]
Internet-Draft Diameter Interoperability Test Suite January 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Fajardo, et al. Expires July 5, 2007 [Page 65]
