<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3539 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3539.xml'>
<!ENTITY rfc3588 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml'> ]
>

<rfc ipr="trust200902" docName="draft-fajardo-dime-base-test-suite-02.txt">
  <front>
    <title abbrev="Base Interoperability Test Suite"> Diameter Base Protocol Interoperability Test
      Suite </title>

    <author initials="V." surname="Fajardo" fullname="Victor Fajardo">
      <organization>Telcordia Technologies </organization>
      <address>
	<postal>
	  <street>1 Telcordia Drive #1S-222</street>
	  <city>Piscataway</city>
	  <region>NJ</region>
	  <code>08854</code>
	  <country>USA</country>
	</postal>
        <email>vfajardo@research.telcordia.com</email>
      </address>
    </author>

    
    <author initials="A." surname="McNamee" fullname="Alan McNamee">
      <organization abbrev="Openet-Telecom"> Openet Telecom Inc </organization>
      <address>
	<postal>
          <street>6 Beckett Way, Park West Business Park</street>
          <city>Clondalkin</city>
          <region>Dublin</region>
          <code>12</code>
          <country>Ireland</country>
	</postal>
	<phone>+353 1 620 4600</phone>
	<email>alan.mcnamee@openet-telecom.com</email>
      </address>
    </author>
    <author fullname="Hannes Tschofenig" initials="H." surname="Tschofenig">
      <organization>Nokia Siemens Networks</organization>
      <address>
        <postal>
          <street>Linnoitustie 6</street>
          <city>Espoo</city>
          <code>02600</code>
          <country>Finland</country>
        </postal>
        <phone>+358 (50) 4871445</phone>
        <email>Hannes.Tschofenig@gmx.net</email>
        <uri>http://www.tschofenig.priv.at</uri>
      </address>
    </author>

    <author fullname="Julien Bournelle" surname="Bournelle" initials="J.">
      <organization>France Telecom R&amp;D </organization>
      <address>
        <postal>
          <street>38-4O rue du general Leclerc</street>
          <city>Issy-Les-Moulineaux</city>
          <code>92794</code>
          <country>France</country>
        </postal>
        <email>julien.bournelle@orange-ftgroup.com</email>
      </address>
    </author>

    <date year="2009"/>

    <workgroup>DIME</workgroup>

    <abstract>
      <t> This document describes a collection of test cases to be used for Diameter base protocol
        interoperability testing. </t>
    </abstract>

  </front>
  <middle>
    <section title="Introduction">
      <t> 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 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. This
        document also covers test suites for common application support provided by the diameter
        base protocol. </t>
      <t> At its current state, this document provides only a collection of test cases designed for
        interoperability. Test plans may be included in future revisions of this work or maybe
        provided in some other document. </t>
    </section>
    <section title="Terminology">
      <t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
        NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
        described in <xref target="RFC2119"/>. </t>
      <t> Within this document the terms defined in <xref target="RFC2119"/> refer to the
        functionality that has to be provided by an implementation for the usage within this
        interoperability test document. </t>
    </section>
    <section title="Diameter Base Protocol Test Suite" anchor="sec-base">
      <t> All implementation must conform to <xref target="RFC3588"/>. </t>
      <section title="Required" anchor="sec-base-req">
        <section title="Connectivity and Peering" anchor="sec-base-req-conn">
          <t> Implementations must conform to Section 5.6 of <xref target="RFC3588"/>. Typical test
            topology for statemachine test uses peer pairs as shown in <xref
              target="fig-peer-fsm-01"/>. 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 <xref target="fig-peer-fsm-01"/> below. <figure
              anchor="fig-peer-fsm-01" title="Peer Statemachine Test Topology">
              <artwork><![CDATA[
      +--------+                   +--------+         
      |Vendor A|<---wired link---->|Vendor B|
      +--------+                   +--------+
             ]]>
              </artwork>
            </figure>
          </t>
          <section title="Capabilities Negotiation" anchor="sec-base-req-conn1">
            <t> Implementations must be able to perform at least the following behavior described in
              Section 5.3 of <xref target="RFC3588"/>. <list style="symbols">
                <t> 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. </t>
                <t> 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. </t>
                <t> Positive test for establishment of connection advertising the relay app in auth
                  app id, acct app id &amp; VSA. </t>
                <t> 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. </t>
                <t> Positive test for DWR/DWA exchange after connection is established. Vendor A and
                  B both exchange watchdogs as per Section 3.4.1 of <xref target="RFC3539"/>. </t>
                <t> 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. </t>
                <t> 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. </t>
                <t> 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. </t>
                <t> 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. </t>
              </list> Verification of each test result can be done manually. </t>
          </section>
          <section title="Election" anchor="sec-base-req-conn2">
            <t> This test case refers to Section 5.6.4 of <xref target="RFC3588"/>. Responders must
              be able to resolve contention with initiator peers. <list style="symbols">
                <t> 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. </t>
                <t> 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. </t>
                <t> 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. </t>
              </list> Verification of test results can be done manually. </t>
          </section>
          <section title="Disconnection" anchor="sec-base-req-conn3">
            <t> Implementations must conform to Section 5.6.4 of <xref target="RFC3588"/> and
              Section 3.4.1 of <xref target="RFC3539"/>. Peers must be able to quickly determine
              disconnection events. Verification of test results can be done manually. <list
                style="symbols">
                <t> 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. </t>
                <t> 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. </t>
                <t> 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. <xref
                    target="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. </t>
                <t> 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. </t>
              </list> Verification of test results can be done manually. </t>
          </section>
          <section title="Re-Connection Algorithms" anchor="sec-base-req-conn4">
            <t> Implementations must conform to Section 2.1 of <xref target="RFC3588"/>. Although a
              vendor can implement other algorithms and policies than those proposed in <xref
                target="RFC3588"/>, a default reconnection scheme must be implemented. <list
                style="symbols">
                <t> 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) watchdog
                  exchanges occur before both peers are no longer suspect. </t>
              </list>
            </t>
          </section>
          <section title="Failover and Failback" anchor="sec-base-req-conn5">
            <t> Implementations must conform to Section 5.4.5 of <xref target="RFC3588"/> and
              Section 3.4.2 of <xref target="RFC3539"/>. Testing failover mechanism requires
              alternate peer connections. A basic ring topology to test failover and failback is
              shown in <xref target="fig-peer-fsm-02"/> 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. <figure anchor="fig-peer-fsm-02"
                title="Failover Test Topology">
                <artwork><![CDATA[
                   +---------+
                   |Vendor B |
                   +---------+
                  /           \
               link0         link3
     +---------+/               \+---------+         
     |Vendor A |                 |Vendor C |
     +---------+\               /+---------+
               link1         link2
                  \+---------+/
                   |Vendor D |
                   +---------+
                  ]]></artwork>
              </figure> The enumerated test cases refers only to vendor A but can be applied to any
              of the vendor implementations in <xref target="fig-peer-fsm-02"/>. 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). <list
                style="symbols">
                <t> Positive test for failover when link0 is disconnected. Vendor A should have
                  pending requests queued prior to disconnection. Upon disconnection (see <xref
                    target="sec-base-req-conn3"/>), verify that the pending request with T-flag set
                  has been forwarded to C via D. </t>
                <t> 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 <xref target="sec-base-req-conn3"/>),
                  verify that the pending request with T-flag set has been forwarded to C via D. </t>
                <t> Positive test for failback when link0 is restored and re-connection succeeds
                  (See <xref target="sec-base-req-conn4"/>). Verify that new request message is
                  routed back to B. </t>
                <t> 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. </t>
                <t> 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.
                </t>
              </list>
            </t>
          </section>
        </section>
        <section title="Routing" anchor="sec-base-req-route">
          <t> Implementation must conform to Section 6 of <xref target="RFC3588"/>. A basic topology
            to test Diameter routing is shown in <xref target="fig-routing-01"/> 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 <xref target="sec-base-req-conn3"/>. 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 <xref target="RFC3588"/>
            must be done when testing routing functionality. <figure anchor="fig-routing-01"
              title="Routing Test Topology">
              <artwork><![CDATA[
                   +---------+
                   |Vendor A2| (realmA)
                   +---------+
                  /     |     \
      (realmA) link1    |    link2
     +---------+/       |       \+---------+         
     |Vendor A1|      link0      |Vendor B2| (realmB)
     +---------+\       |       /+---------+
               link4    |    link3
                  \+---------+/
                   |Vendor B1|
                   +---------+
                    (realmB)
             ]]>
              </artwork>
            </figure>
          </t>
          <section title="Peer Based Request Routing" anchor="sec-base-req-route1">
            <t> Implementation must conform to Section 6.1.5 of <xref target="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. <list
                style="symbols">
                <t> 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. </t>
                <t> 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. </t>
                <t> 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. </t>
              </list>
            </t>
          </section>
          <section title="Realm Based Routing" anchor="sec-base-req-route2">
            <t> Implementation must conform to Section 6.1 and Section 6.1.6 of <xref
                target="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 <xref
                target="sec-base-req-route1"/>. <list style="symbols">
                <t> 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. </t>
                <t> 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. </t>
                <t> 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. </t>
              </list>
            </t>
          </section>
          <section title="Answer Message Routing" anchor="sec-base-req-route3">
            <t> Implementations must conform to Section 6.2 of <xref target="RFC3588"/>. Answer
              routing can be verified using test cases in <xref target="sec-base-req-route1"/> and
                <xref target="sec-base-req-route2"/>. </t>
          </section>
          <section title="Loop Detection" anchor="sec-base-req-route4">
            <t> Implementation must conform to Section 6.1.3 of <xref target="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. <list style="symbols">
                <t> 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. </t>
              </list>
            </t>
          </section>
        </section>
        <section title="Relay Agent" anchor="sec-base-req-agent">
          <t> Implementations must conform to Section 2.8.1, 6.1.8 and 6.2.2 of <xref
              target="RFC3588"/>. The topology shown in <xref target="fig-routing-01"/> is also used
            for testing relay agent functionality. Note that an overlap exists with the test case
            described in <xref target="sec-base-req-route"/> 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 <xref target="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 of the test cases enumerated here. </t>
        </section>
        <section title="Redirection Agent" anchor="sec-base-req-agent1">
          <t> Implementation must conform to Section 6.1.7 of <xref target="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. <list
              style="symbols">
              <t> 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. </t>
            </list>
          </t>
        </section>
      </section>
      <section title="Optional" anchor="sec-base-optional">
        <t> Implementations must conform to Section 5.6 of <xref target="RFC3588"/>. Test topology
          uses <xref target="fig-peer-fsm-01"/>. This section describes optional test cases.</t>

        <section title="General Statemachine" anchor="sec-base-opt-conn1">
          <t> Implementations must conform to Section 5.6.1 of <xref target="RFC3588"/>. The same
            topology in <xref target="fig-peer-fsm-01"/> can be used to perform the test scenarios
            listed in this section. <list style="symbols">
              <t> 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.
              </t>
            </list>
          </t>
        </section>
        <section title="Dynamic Peer Discovery" anchor="sec-base-opt-conn2">
          <t> Implementations must conform to Section 5.3 of <xref target="RFC3588"/>.
            Implementations must be able to perform at least the following behavior. <list
              style="symbols">
              <t> Positive test for establishment of connection with unknown peer. The topology for
                this test is <xref target="fig-peer-fsm-01"/>. 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 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. </t>
              <t> Positive test after redirection (<xref target="sec-base-req-agent1"/>). The
                topology for this test is <xref target="fig-routing-01"/>. Additional verification
                can be done if <xref target="sec-base-req-agent1"/> 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. </t>
            </list>
          </t>
        </section>

      </section>
    </section>
    <section title="Diameter Base Protocol Application Support" anchor="sec-app">
      <section title="Authentication and/or Authorization" anchor="sec-app-cmn-req-auth">
        <t> Applications intending to use authentication and/or authorization must conform to the
          statemachine specification in Section 8.1 of <xref target="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 <xref target="fig-peer-fsm-01"/>.
          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. </t>
        <section title="Stateful Session" anchor="sec-app-cmn-req-auth1">
          <t> Implementations must conform to Section 8.1 of <xref target="RFC3588"/>.
            Implementations must be able to perform at least the following behavior. <list
              style="symbols">
              <t> 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 <xref
                  target="RFC3588"/>. </t>
              <t> 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 <xref target="RFC3588"/>. </t>
              <t> 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 <xref target="RFC3588"/>. Verify application id value carried by the STR/STA
                message is that of the target application. </t>
              <t> 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 <xref target="RFC3588"/>. Verify application id value
                carried by the STR/STA message is that of the target application. </t>
              <t> 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 <xref target="RFC3588"/>. </t>
            </list>
          </t>
        </section>
        <section title="Stateless Session" anchor="sec-app-cmn-req-auth2">
          <t> Implementations must conform to Section 8.1 of <xref target="RFC3588"/>.
            Implementations must be able to perform at least the following behavior. <list
              style="symbols">
              <t> 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. </t>
              <t> Positive test for proper stateless session disconnection. Verify that
                session-lifetime is enforced in the client session. </t>
            </list>
          </t>
        </section>
      </section>
      <section title="Accounting" anchor="sec-app-cmn-req-acct">
        <t> Applications intending to use Diameter accounting may conform to Section 8.2 and 9 of
            <xref target="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 <xref
            target="fig-peer-fsm-01"/>. 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. </t>
        <section title="Client Session" anchor="sec-app-cmn-req-acct1">
          <t> Implementations must conform to Section 8.2 of <xref target="RFC3588"/>.
            Implementations must be able to perform at least the following behavior. Verification of
            test results for these cases can be done manually. <list style="symbols">
              <t> 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 <xref target="RFC3588"/>. </t>
              <t> Positive test for proper client session termination. Verify that session
                termination causes transmission of stop record events if 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. </t>
              <t> Negative test for client session when server reports a failure. Verify that client
                session can cope wistatemachine draft submissionth failed accounting starts or
                server storage failure and act accordingly based on Section 8.2 <xref
                  target="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. </t>
              <t> 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
                  <xref target="RFC3588"/>. The test can overlap with <xref
                  target="sec-base-req-conn3"/> and <xref target="sec-base-req-conn5"/>. </t>
            </list>
          </t>
        </section>
        <section title="Server Session" anchor="sec-app-cmn-req-acct2">
          <t> Implementations must conform to Section 8.2 and 9 of <xref target="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 <xref
              target="RFC3588"/>), sequencing and co-relation (Section 9.6 <xref target="RFC3588"/>)
            of records. <list style="symbols">
              <t> 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 <xref target="RFC3588"/>. </t>
              <t> 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. </t>
              <t> 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
                  <xref target="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 <xref target="sec-app-cmn-req-acct1"/>. </t>
            </list>
          </t>
        </section>
      </section>
    </section>
    <section title="Security Considerations" anchor="section-security-considerations">
      <t> This document defines test cases and therefore tests various aspects of the Diameter base
        specification and various Diameter applications. </t>
    </section>
    <section title="IANA Considerations">
      <t> This document does not require actions by IANA. </t>
    </section>
  </middle>
  <back>
    <references title="Normative References"> &rfc2119; &rfc3539; &rfc3588;
    </references>
  </back>
</rfc>
