Technical Committee

Interoperability Test for PNNI Version 1.0

AF-TEST-CSRA-0111.000

February, 1999

© 1999 by The ATM Forum.  This specification/document may be reproduced and distributed in whole, but (except as provided in the next sentence) not in part, for internal and informational use only and not for commercial distribution.  Notwithstanding the foregoing sentence, any protocol implementation conformance statements (PICS) or implementation conformance statements (ICS) contained in this specification/document may be separately reproduced and distributed provided that it is reproduced and distributed in whole, but not in part, for uses other than commercial distribution.  All other rights reserved.  Except as expressly stated in this notice, no part of this specification/document may be reproduced or transmitted in any form or by any means, or stored in any information storage and retrieval system, without the prior written permission of The ATM Forum.

The information in this publication is believed to be accurate as of its publication date.  Such information is subject to change without notice and The ATM Forum is not responsible for any errors.  The ATM Forum does not assume any responsibility to update or correct any information in this publication.  Notwithstanding anything to the contrary, neither The ATM Forum nor the publisher make any representation or warranty, expressed or implied, concerning the completeness, accuracy, or applicability of any information contained in this publication.  No liability of any kind shall be assumed by The ATM Forum or the publisher as a result of reliance upon any information contained in this publication.

The receipt or any use of this document or its contents does not in any way create by implication or otherwise:

•	Any express or implied license or right to or under any ATM Forum member company's patent, copyright, trademark or trade secret rights which are or may be associated with the ideas, techniques, concepts or expressions contained herein; nor
•	Any warranty or representation that any ATM Forum member companies will announce any product(s) and/or service(s) related thereto, or if such announcements are made, that such  announced product(s) and/or service(s) embody any or all of the ideas, technologies, or  concepts contained herein; nor
•	Any form of relationship between any ATM Forum member companies and the recipient or user of this document.

Implementation or use of specific ATM standards or recommendations and ATM Forum specifications will be voluntary, and no company shall agree or be obliged to implement them by virtue of participation in The ATM Forum.

The ATM Forum is a non-profit international organization accelerating industry cooperation on ATM technology.  The ATM Forum does not, expressly or otherwise, endorse or promote any specific products or services.

NOTE:  The user's attention is called to the possibility that implementation of the ATM interoperability specification contained herein may require use of an invention covered by patent rights held by ATM Forum Member companies or others.  By publication of this ATM interoperability specification, no position is taken by The ATM Forum with respect to validity of any patent claims or of any patent rights related thereto or the ability to obtain the license to use such rights.  ATM Forum Member companies agree to grant licenses under the relevant patents they own on reasonable and nondiscriminatory terms and conditions to applicants desiring to obtain such a license.  For additional information contact:

The ATM Forum
Worldwide Headquarters
2570 West El Camino Real, Suite 304
Mountain View, CA 94040-1313
Tel:	 +1-650-949-6700
Fax: +1-650-949-6705
Interoperability Abstract Test Suite for PNNI

Table of Contents

1	Introduction	1
1.1	Scope	1
1.2	References	2
1.3	Abbreviations	3

2	Test Realization	3

3	Interoperability Test Case Information	4
3.1	Test Configurations	4
3.2	Test Case Layout	10

4	Interoperability Interface Tests (Routing	13
4.1	Test Case Index	13
4.2	Test Cases Dynamic Behavior	20
4.3	Hello Protocol	20
4.3.1  For the Hello Protocol (SS_M)	20
4.3.2  For the Hello Protocol (SS_B)	26
4.3.3  For the Hello Protocol	33
4.4	Database Synchronization Protocol	44
4.4.1  For the Database Synchronization Protocol (SS_M)	44
4.4.2  For the Database Synchronization Protocol (SS_P)	49
4.5	Flooding	52
4.5.1  Flooding	52
4.6	Peer Group Leader Election	52
4.6.1  For the Peer Group Leader Election (not PGL capable)	52
4.6.2	  For the Peer Group Leader Election (one SUT is PGL capable)	52
4.6.3	  For the Peer Group Leader Election (Both SUTs are PGL capable)	52
4.7	Border Node / PGL Interactions	52
4.7.1  Border Node / PGL Interactions	52
4.8	Logical Group Node	52
4.8.1   Logical Group Node (SVCC-Based RCC establishment)	52
4.8.2   Logical Group Node (Hello Protocol)	52
4.8.3   	Logical Group Node (Feeding Information Down the Hierarchy)	52

5	Interoperability Interface Tests (Signalling)	52
5.1	Test Case Index	52
5.2	Test Cases Dynamic Behavior (Point-to-Point)	52
5.2.1   Establishing an SVC (SS_M)	52
5.2.2	   Establishing an SVC (SS_M)  Detailed for Test Configuration #3a	52
5.2.2.1   	Optional tests for Establishment: Negotiation of ATM traffic descriptors (OPT_5)	52
5.2.3	   Establishing an SVC (SS_M)  Detailed for Test Configuration #3b	52
5.2.3.1   	Optional tests for Establishment: Negotiation of ATM traffic descriptors (OPT_5)	52
5.2.4	   Establishing an SVC (SS_M)  Detailed for Test Configuration #3c	52
5.3	Release	52
5.3.1   Releasing an SVC (SS_M)	52
5.3.2   	Releasing an SVC (SS_M)  Detailed for Test Configuration #3a	52
5.3.3   	Releasing an SVC (SS_M)  Detailed for Test Configuration #3b	52
5.3.4	   Releasing an SVC (SS_M)  Detailed for Test Configuration #3c	52
5.4	DTL Processing	52
5.4.1   DTL processing an SVC	52
5.4.2	   DTL processing an SVC  Detailed for Test Configuration #3a	52
5.4.3	   DTL processing an SVC  Detailed for Test Configuration #3b	52
5.4.4   DTL processing an SVC Detailed for Test Configuration #3c	52
5.5	Crankback Processing	52
5.5.1   Crankback processing on an SVC (SS_M)	52
5.5.2	   Crankback processing on an SVC (SS_M)  Detailed for Test Configuration #3a	52
5.5.3	   Crankback processing on an SVC (SS_M)  Detailed for Test Configuration #3b	52
5.5.4	   Crankback processing on an SVC (SS_M)  Detailed for Test Configuration #3c	52
5.5.5	   Crankback processing on an SVC (SS_M)  Detailed for Test Configuration #4a	52
5.5.6	   Crankback processing on an SVC (SS_M)  Detailed for Test Configuration #4b	52
5.6	Test Cases Dynamic Behavior (Point-to-Multipoint)	52
5.6.1   Setup of the initial party (SS_M)	52
5.6.2   Adding a party (SS_M)	52
5.6.3   Party dropping (SS_M)	52

1	Introduction

This document provides an interoperability abstract test suite for the Private Network-Network Interface Specification version 1.0 (PNNI v1.0)[1], including the Errata [3].  It belongs to a set of test documents supplied by the ATM Forum that cover the testing areas of conformance, performance, and interoperability testing.  The document, "Introduction to ATM Forum Test Specification" [2] provides an introduction to the different testing areas and should be consulted prior to using this test suite.
1.1	Scope

This document provides an interoperability abstract test suite for the PNNI v1.0, including the Errata [3].  It includes sample test cases that address interoperability in two major areas.  These major areas are routing and signalling.  Within these major areas there are a number of smaller areas.  These smaller areas are based on the protocol separation and the functionality of switching system subsets (see Annex G of PNNI v1.0).  Terms (e.g., SS_M, SS_B, SS_N, and SS_P) referring to these switching system subsets are described in the Protocol Implementation Conformance Statement (PICS) Proforma for PNNI v1.0 [3].

Note:	It is assumed that PNNI conformance testing has been completed on both SUTs before these tests are executed.

Routing
- procedures for neighbor discovery (i.e., Hello Protocol)
-- within the same peer group (SS_M)
-- between two peer groups (SS_B) 
- procedures for exchanging routing information (i.e., Database Synchronization)
-- lowest level (SS_M)
-- higher level (SS_P)
- procedures for flooding (SS_M)
- procedures for electing a peer group leader (i.e., Peer Group Leader Election)
-- this node is not capable of becoming a PGL (SS_M)
-- this node is capable of becoming a PGL (SS_P)
- procedures for PGL and Border node interactions
- procedures for higher layer neighbor discovery (i.e., SVCC-based RCC Hello protocol) (SS_N and SS_P)
- procedures for Logical Group Node (LGN) (SS_N and SS_P)

Signaling
- procedures for point-to-point calls (SS_M)
- procedures for point-to-multipoint calls (SS_M)

Under many of the above general headings are other subdivisions.  The details are specified in their respective sections.

There are two protocol stacks to be tested.  Figure 1 shows the protocol stack for the PNNI routing as described in PNNI v1.0

Figure 1:  Protocol Stack for PNNI Routing
section 5.5 and 5.5.1.  The protocol stack for PNNI signaling is shown in PNNI v1.0 figure 6-2, PNNI Control Plane.

1.2	References

[1]	Private Network-Network Interface Specification Version 1.0, af-pnni-0055.000, March 1996

[2]	Introduction to ATM Forum Test Specification, af-test-0022.000, November 1994

[3]	Private Network-Network Interface (PNNI) Version 1.0 Errata and Protocol Implementation Conformance Statement (PICS) Proforma, May 1997

1.3	Abbreviations

AMS	Audiovisual Multimedia Services
ATD	ATM Traffic Descriptor
ATM	Asynchronous Transfer Mode
ATS	Abstract Test Suite
CBR	Constant Bit Rate
CES	Circuit Emulation Services
DS	Database Sequence
DTL	Designated Transit List
FUNI	Frame based User Network Interface
IE	Information Element
ILMI	Integrated Local Management Interface
IUT	Implementation Under Test
LGN	Logical Group Node
LT	Lower Tester
OAM	Operations and Maintenance
PCO	Point of Control and Observation
PGL	Peer Group Leader
PNNI	Private Network Network Interface
PO	Point of Observation
PTSE	PNNI Topology State Element
PTSP	PNNI Topology State Packet
QoS	Quality of Service
RCC	Routing Control Channel
SUT	System Under Test
SVC	Switched Virtual Circuit
SVC	Switched Virtual Connection
SVCC	Switched Virtual Channel Connection
UNI	User-Network Interface
UT	Upper Tester
VBR	Variable Bit Rate
VCI	Virtual Channel Identifier
VPI	Virtual Path Identifier

2	Test Realization

The realization of each test case within this test suite shall be the responsibility of the test laboratory.  The test realization shall adhere to the following condition:
- the realization of a test case shall meet all of the requirements and objectives of the test case as specified in the test purpose of each test case.

3	Interoperability Test Case Information

There are two main parts to these tests.  The first is the physical configurations used for interoperability testing.  The second is an explanation of the individual test case layout (i.e. components).
3.1	Test Configurations

The generic test set-up for the interoperability test of two ATM switches/implementations (the SUTs) running PNNI v1.0 (including Errata) is shown in Figure 2.  Monitor point D is for interoperability testing/verification.  Monitor (possibly control) points A and C are shown, when necessary, to indicate other information (e.g. input needed to create event at Monitor point D).

In the test configurations shown on the following pages, only the relevant components are shown.  Other parts of the configuration are needed, but are for reasons of clarity omitted.  Not all of the monitoring points shown are required for each test.  Observations at Monitor point D are part of the pass/fail criteria (i.e. verdict); others observations at other monitor points may be needed.  Each test clearly states when observations at monitor points other than D, are part of the pass/fail criteria and when the observations are for trouble isolation

Figure 2:      Generic PNNI Test Configuration
(i.e. information).

Note 1: Monitor points may be included in the tester.  A single tester may suffice for all tests, provided the tester has enough ports, capabilities, and functions.

NOTE 2: As mentioned earlier the testers and monitors shown in the reference configurations may be part of one physical device.  On the other hand a tester(s) may be realized as a system of devices (in order to create the environment necessary to carry-out the test), not just as one physical device.

NOTE 3:	SUTs may be of the same or different types/manufacturer.  SUTs may also be a tester.  When the SUT is a tester, these tests are testing the tester's implementation of the PNNI protocol for interoperability with another SUT and not acting as a Tester in the context of these tests.  However, when the tests are used for testing single vendor implementation, it does not imply interoperability with other vendors equipment.

NOTE 4:	It is assumed that the tester, acting as an SUT, must pass these interoperibility tests before operability testing can be performed.

Figure 3:     Test Configuration #1
Test configuration #1 represents the case where two SUTs (e.g., ATM switches (PNNI capable)) are connected.  The main concern here is that there are some functions that are not externally controllable and therefore monitoring the link between the two SUTs is the only way that interoperability testing can be done.

Figure 4:     Test Configuration #2
Test configuration #2 represents the case where at least one of the SUTs needs to have external influence in order for an event to be observed at Monitor point D.  This external influence may be controlled by a single tester.

Figure 5:     Test Configuration #3a

Figure 6:     Test Configuration #3b

Figure 7:     Test Configuration #3c
Test configurations #3(a-c) represent the case where external influence is needed from both sides of the two SUTs (i.e. switches) that are connected.  The three test configuration show the different combinations of the two interfaces (i.e. PNNI or UNI) at monitor points A and C.

Figure 8:     Test Configuration #4a

Figure 9:     Test Configuration #4b
Test configurations #4(a-b) represent the case where external influence is needed from both sides of the two SUTs (i.e. switches) that are connected.  The two test configurations show the different combinations of the two interfaces (i.e. PNNI or UNI) at monitor point C.  These two test configuration are similar to those of test configuration #3, but with the addition of another physical connection between SUT B and Tester B.

Figure 10:     Test Configuration #5
Test configuration #5 represents the case where end-to-end interoperability is being tested between SUT A and SUT B.  SUT A and SUT B are not physically connected to each other, but are logically connected to each other through an intervening node(s) (i.e. Tester D).  In this case Monitor points DA and DC will observe the same information for testing and verification purposes, however the connection on which this information is observed may be different.
For example, SUT A and SUT B are both Peer Group Leaders of different peer groups, which have a common higher level peer group.  Therefore, an SVC based RCC must be established between them.  The VPI/VCI of the SVC at Monitor point DA may be different than the VPI/VCI of the SVC at Monitor point DC.  However, the PNNI information exchanged over this SVC will be the same.

Under test configurations #2, #3, #4, and #5 there are subclasses that represent internal reference configurations (e.g., specific PNNI features and functions) that the testers must operate (if a real network is not used).  An example of specific PNNI features and functions is when the tester must supply the information necessary (PTSEs) to make the tester appear to be another PNNI network (i.e., Peer group) with a Peer Group Leader.

3.2	Test Case Layout

Each Test case has the following parts: Test Case ID, Test Purpose, Reference, Pre-requisite, Test Configuration, Test Set-up, Test Procedure, Verdict Criteria, and Consequence of Failure*.
Test Case ID:
This is the test case identifier.  Layout is ABBBBCCCDDD.  The following table provides detailed information.
Test Case Identification Layout and Description			
Positions	Meaning	Current Values	
A	Type of test	V=Valid or E=error	
 BBBB	Section number in this document	See this document	
     CCC	Abbreviated description of the protocol or part of protocol being tested	H__=	Hello,
DBS=	DataBase Synchronization,
FLD=	Flooding,
PGL=	Peer Group Leader Election,
BPI=	Border Node / PGL Interactions,
LGN=	Logical Group Node,
EST=	Call Establishment,
REL=	Release call,
CRK=	Crankback,
DTL=	Designated Transit List,
RST=	Restart
	
        DDD	Number of the test case within the particular section	See this document	
Test Purpose:
Defines the reason for running the test.
Reference:
The section from the PNNI v1.0 Specification that supports this test case.
Pre-requisite:
Listed is the information that must be known before the test can be run.
Test Configuration:
Lists which of the test configurations should be used.
Test Set-up:
Describes the devices and physical connections needed for this test.
NOTE: The term connect two devices does not necessarily imply that the systems are on and operational when the physical connection is made.  The test being run will determine the situation.

Test Procedure:
Lists the steps necessary to carry out this test.  Items in parenthesis, "()", mean that the item occurs at either the A or C monitoring point.  Items in brackets, "[]", provide necessary information on coding of messages or information elements. 
Verdict Criteria:
Lists the observations that must occur in order for this test case results to be successful (i.e. satisfy the Test Purpose).  Items in parenthesis, "()", mean that the item occurs at either the A or C monitoring point.  It is given here as additional information, but is not required for determination of pass or failure of the test case.
Consequence of Failure*:
Reason for including this test case as a necessary part of this interoperability test suite.

4	*Note - not all test cases have this, at this time.
4	Interoperability Interface Tests (Routing

4.1	Test Case Index
Test Case ID	Test Purpose	
V4301H__001	Verify that the Hello Protocol is running on an operational physical link.	
V4301H__002	Verify that a PNNI version number is agreed upon.	
V4301H__003	Verify that the Hello sent from both sides contains Hello Interval and Port ID set to non-zero.	
V4301H__004	Verify that the first Hello sent from both sides contains Remote node ID and Remote port ID set to zero.	
V4301H__005	Verify that after receiving a Hello (2-WayInsideReceived) that the SUT acknowledges  the remote identification information.	
V4301H__006	Verify that Hello packets are transmitted periodically (i.e. when the Hello Timer expires).	
V4301H__007	Verify that after receiving a Hello (1-WayInsideReceived) that the SUT acknowledges  the remote identification information.	
E4301H__008	Verify that after a physical link failure, when corrected, that the Hello protocol starts over again from the beginning.	
V4302H__001	Verify that the Hello Protocol is running on an operational physical link.	
V4302H__002	Verify that a PNNI version number is agreed upon.	
V4302H__003	Verify that the Hello sent from both sides contains Hello Interval and Port ID set to non-zero.	
V4302H__004	Verify that the first Hello sent from both sides contains Remote node ID and Remote port ID set to zero.	
V4302H__005	Verify that the SUTs determine that they are in different peer groups.	
V4302H__006	Verify that after receiving a Hello (1-WayOutsideReceived) that the SUT acknowledges  the remote identification information.	
V4302H__007	Verify that after receiving a Hello (2-WayOutsideReceived) that the SUT acknowledges the remote identification information.	
V4302H__008	Verify that Hello packets are transmitted periodically (i.e. when the Hello Timer expires).	
V4302H__009	Verify that each SUT transmits an Uplink Information Attribute (ULIA) information group (34) containing one or more outgoing resource availability information groups (128) describing all metrics.	
E4302H__010	Verify that after a physical link failure, when corrected, that the Hello protocol starts over again from the beginning.	
V4303H__001	Verify that the Hello Protocol is running on an operational physical link.	
V4303H__002	Verify that a PNNI version number is agreed upon.	
V4303H__003	Verify that the Hello sent from both sides contains Hello Interval and Port ID set to non-zero.	
V4303H__004	Verify that the first Hello sent from both sides contains Remote node ID and Remote port ID set to zero.	
V4303H__005	Verify that the SUTs determine that they are in different peer groups.	
V4303H__006	Verify that after receiving a Hello (1-WayOutsideReceived) that the SUT acknowledges  the remote identification information.	
V4303H__007	Verify that after receiving a Hello (2-WayOutsideReceived) that the SUT acknowledges the remote identification information.	
V4303H__008	Verify that Hello packets are transmitted periodically (i.e. when the Hello Timer expires).	
V4303H__009	Verify that each SUT transmits an Uplink Information Attribute (ULIA) information group (34) containing one or more outgoing resource availability information groups (128) describing all metrics.	
V4303H__010	Verify that two SUTs in different peer groups can agree on a common peer group using outside Hellos, resulting in the advertisement of uplinks by each SUT.	
V4303H__011	Verify that when SUT B is in the parent peer group of SUT A, the SUTs can agree on a common peer group using outside Hellos, resulting in the advertisement of an uplink by SUT A and an attempt to establish an SVCC-based RCC from SUT B to the parent LGN of SUT A.	
E4303H__012	Verify that after a physical link failure, when corrected, that the Hello protocol starts over again from the beginning.	
V4401DBS001	Verify that the DataBase Synchronization protocol commences only after reaching the 2-WayInside state.	
V4401DBS002	Verify that the SUTs agree on which SUT is master and which SUT is slave.	
V4401DBS003	Verify that the SUTs request the PTSEs that were contained in the Database summary packets.	
V4401DBS004	Verify that the SUTs exchange their complete Database summaries.	
V4401DBS005	Verify that neither SUT advertises this lower -level link until the neighboring peer state machine is in the Full state.	
V4402DBS001	Verify that the DataBase Synchronization protocol commences only after reaching the 2-WayInside state.	
V4402DBS002	Verify that the SUTs agree on which SUT is master and which SUT is slave.	
V4402DBS003	Verify that the SUTs request the PTSEs that were contained in the Database summary packets.	
V4402DBS004	Verify that the SUTs exchange their complete Database summaries.	
V4402DBS005	Verify that neither SUT advertises this lower -level link until the neighboring peer state machine is in the Full state.	
V4501FLD001	Verify that SUT A floods a PTSE to SUT B.	
V4501FLD002	Verify that SUT A does not flood a PTSE with PTSE Remaining Lifetime of ExpiredAge to SUT B	
V4601PGL001	Verify that the nodes participate in the Peer group leader elections, when the Non-transit for PGL Election flag is not set.	
V4601PGL002	Verify that the nodes continue participating in the Peer group leader elections, when the Non-transit for PGL Election flag is not set. (i.e. PGLInitTimer Expires)	
V4601PGL003	Verify that the SUT B participates in the Peer group leader elections, when the Non-transit for PGL Election flag is not set.	
V4601PGL004	Verify that the SUT B elects a PGL, when the Non-transit for PGL Election flag is not set. (PGLInitTimer Expires)	
V4601PGL005	Verify that SUT B continues to participate in the Peer group leader elections by electing a PGL when a PGL capable device joins the peer group, when the Non-transit for PGL Election flag is not set.	
V4602PGL001	Verify that SUT B elects SUT A as Peer Group Leader (Advertise their preferred Peer Group Leader).	
V4602PGL002	Verify that SUT A becomes Peer Group Leader.	
V4602PGL003	Verify that SUT A elects SUT B as Peer Group Leader.	
V4602PGL004	Verify that SUT B becomes Peer Group Leader.	
V4602PGL005	Verify that SUT A continues to be PGL when another system is attached that is not PGL capable or has a peer group leadership priority lower than SUT A's.	
V4602PGL006	Verify that SUT A stops being Peer Group Leader when a system is attached with higher Peer Group Leadership priority.	
V4602PGL007	Verify that SUT B continues to be PGL when another system is attached that is not PGL capable or has a peer group leadership priority lower than SUT B's.	
V4602PGL008	Verify that SUT B stops being Peer Group Leader when a system is attached with higher Peer Group Leadership priority.	

V4602PGL009	Verify that SUT B elects new Peer Group Leader when a system is attached with Higher Peer Group Leadership priority than SUT's current PGL (i.e. SUT A).	
V4602PGL010	Verify that SUT A elects new Peer Group Leader when a system is attached with Higher Peer Group Leadership priority than SUT's current PGL (i.e. SUT B).	
V4603PGL001	Verify that SUT A becomes Peer Group Leader based on leadership priority.	
V4603PGL002	Verify that SUT A becomes Peer Group Leader based on Node ID.	
V4603PGL003	Verify that SUT B elects SUT A as Peer Group Leader based on leadership priority.	
V4603PGL004	Verify that SUT B elects SUT A as Peer Group Leader based on Node ID.	
V4701BPI001	Verify that two SUTs in the same peer group, one acting as PGL and the other acting as a border node, can communicate and act upon nodal hierarchy information.	
V4701BPI002	Verify that two SUTs in the same peer group, one acting as PGL and the other as a border node, can communicate and act upon uplink information.	
V4801LGN001	Verify that a PGL (i.e. SUT A) in one peer group initiates a switched virtual channel connection (SVCC) to the PGL (i.e. Tester B) in another peer group.	
V4801LGN002	Verify that local PGL (i.e. SUT A) accepts (i.e. sends CALL PROCEEDING message) a switched virtual channel connection (SVCC) from remote PGL (i.e. Tester B).	
V4801LGN003	Verify that local PGL (i.e. SUT A) accepts (i.e. sends CONNECT message) a switched virtual channel connection (SVCC) from remote PGL (i.e. Tester B).	
V4801LGN004	Verify that a PGL (i.e. SUT A) in one peer group initiates a switched virtual channel connection (SVCC) to the PGL (i.e. SUT B) in another peer group.	

V4801LGN005	Verify that remote PGL (i.e. SUT B) accepts (i.e. sends CALL PROCEEDING message) a switched virtual channel connection (SVCC) from local PGL (i.e. SUT A).	
V4801LGN006	Verify that remote PGL (i.e. SUT B) accepts (i.e. sends CONNECT message) a switched virtual channel connection (SVCC) from local PGL (i.e. SUT A).	
V4801LGN007	Verify that when a new Peer Group Leader (e.g. Tester B emulating a new node) is elected in the same peer group as SUT B, the old Peer Group Leader (i.e. SUT B) releases the RCC to the Peer Group Leader (i.e. SUT A) of another peer group with cause value=53.	
E4801LGN008	Verify that after a physical link failure, when corrected, that a PGL (i.e. SUT A) in one peer group initiates a switched virtual channel connection (SVCC) to the PGL (i.e. Tester B) in another peer group.	
E4801LGN009	Verify that after a physical link failure, when corrected, that a PGL (i.e. SUT A) in one peer group initiates a switched virtual channel connection (SVCC) to the PGL (i.e. SUT B) in another peer group.	
V4802LGN001	Verify that the Hello protocol is running over the SVCC-Based RCC.	
V4802LGN002	Verify that the Hello protocol is running over the SVCC-Based RCC and that the LGN learns about the other (remote) LGN.	
E4802LGN003	Verify that after a physical link failure, when corrected, that the Hello Protocol is running over the SVCC-Based RCC (2-WayInside).	
V4803LGN001	Verify that information is fed down the Hierarchy.	
4.2	
4.2	Test Cases Dynamic Behavior
4.3	Hello Protocol
4.3.1	For the Hello Protocol (SS_M)

All tests in this section require both SUTs to be in the same lowest level peer group.

All tests in this section use Test Configuration #1. 
------------------------------------------------------
1.	Test Case ID:	V4301H__001
Test Purpose:	Verify that the Hello Protocol is running on an operational physical link.
Reference:	5.6
Pre-requisite:	Both SUTs are SS_M and in the same lowest level peer group.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.

Verdict Criteria:
Hello packets shall be observed in both directions on the PNNI.

Consequence of Failure:	The PNNI protocol can not operate.

2.	Test Case ID:	V4301H__002
Test Purpose:	Verify that a PNNI version number is agreed upon.
Reference:	5.6.1
Pre-requisite:	Both SUTs are SS_M and in the same lowest level peer group.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe Test Case V4301H__001.

Verdict Criteria:
Observe that the value in the version field in the next exchanged Hello packets is the same in both directions, is the value between the oldest- and newest-version supported field, and is the value the highest common value.

Consequence of Failure:	The PNNI protocol can not operate unless a single version is agreed to.

3.	Test Case ID:	V4301H__003
Test Purpose:	Verify that the Hello sent from both sides contains Hello Interval and Port ID set to non-zero.
Reference:	5.6.2.3
Pre-requisite:	Both SUTs are SS_M and in the same lowest level peer group.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.

Verdict Criteria:
Observe that the value in the Hello Interval field and the Port ID field is set to non-zero in the Hello packets sent from both SUTs.

Consequence of Failure:	The PNNI protocol can not operate unless the Hello Interval and Port ID are set to non-zero.

4.	Test Case ID:	V4301H__004
Test Purpose:	Verify that the first Hello sent from both sides contains Remote node ID and Remote port ID set to zero.
Reference:	5.6.2.1.4 (Hp1), 5.6.2.1.2 (1-WayInside), 5.6.2.1.3 (1-WayInsideReceived)
Pre-requisite:	Both SUTs are SS_M and in the same lowest level peer group.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.

Verdict Criteria:
The first Hello packet observed from each SUT will have the Remote node ID field and Remote port ID field set to zero.

Consequence of Failure:	The old PNNI information was retained causing the protocol not to operate.

5.	Test Case ID:	V4301H__005
Test Purpose:	Verify that after receiving a Hello (2-WayInsideReceived) that the SUT acknowledges the remote identification information.
Reference:	5.6.2.1.4 (Hp4 and Hp15)
Pre-requisite:	Both SUTs are SS_M and in the same lowest level peer group.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Monitor stores the values contained in the Node Id, Port ID, Remote node ID, and Remote port ID fields in the first Hello that has the Remote node ID and Remote port ID fields set to something other than zero sent by each SUT.

Verdict Criteria:
Observe that the next Hello sent from SUT A contains in the Node ID, Port ID, Remote node ID, and Remote port ID fields values that are the same as those stored in Test Procedure step #2) as the Remote node ID, Remote port ID, Node ID and Port ID, respectively in the Hello from SUT B. 
- AND -
Observe that the next Hello sent from SUT B contains in the Node ID, Port ID, Remote node ID, and Remote port ID fields values that are the same as those stored in Test Procedure step #2) as the Remote node ID, Remote port ID, Node ID and Port ID, respectively in the Hello from SUT A. 

Consequence of Failure:	The PNNI protocol can not operate (i.e. not progress to next step).

6.	Test Case ID:	V4301H__006
Test Purpose:	Verify that Hello packets are transmitted periodically (i.e. when the Hello Timer expires).
Reference:	5.6.2.1.4 (Hp15)
Pre-requisite:	Both SUTs are SS_M and in the same lowest level peer group.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Monitor shall set two timers, Ta and Tb, with the value observed in the Hello interval field in the last Hello packet sent from each SUT, respectively, plus some delta.
3a.	Start the monitor timer (Ta) when the first Hello (2-WayInsideReceived) is sent from SUT A.
3b.	Start a monitor timer (Tb) when the first Hello (2-WayInsideReceived) is sent from SUT B.

Verdict Criteria:
Observe that before the timer, Ta, expires a Hello is sent by SUT A.
- AND -
Observe that before the timer, Tb, expires a Hello is sent by SUT B.

Consequence of Failure:	The PNNI protocol information is not updated and keep alive not working (system decays and then collapses).

7.	Test Case ID:	V4301H__007
Test Purpose:	Verify that after receiving a Hello (1-WayInsideReceived) that the SUT acknowledges the remote identification information.
Reference:	5.6.2.1.4 (Hp2)
Pre-requisite:	Both SUTs are SS_M and in the same lowest level peer group. (NOTE: This Test Case is a pre-requisite before beginning any of the Database Synchronization interoperability tests)
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Monitor stores the values contained in the Node ID and Port ID fields in the first Hello sent by each SUT.

Verdict Criteria:
Observe that the next Hello sent from SUT A contains in the Remote node ID and Remote port ID fields values that are the same as those stored as the Node ID and Port ID, respectively in the Hello from SUT B. 
- AND -
Observe that the next Hello sent from SUT B contains in the Remote node ID and Remote port ID fields values that are the same as those stored as the Node ID and Port ID, respectively in the Hello from SUT A. 

Consequence of Failure:	If this state is not reached, then the Database Synchronization protocol can not be initiated.

8.	Test Case ID:	E4301H__008
Test Purpose:	Verify that after a physical link failure, when corrected, that the Hello protocol starts over again from the beginning (i.e. as if this were the first time the connection was made).
Reference:	5.6.2.1.4 (Hp1), 5.6.2.3
Pre-requisite:	Both SUTs are SS_M and in the same lowest level peer group.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe at least one Hello (2-WayInsideReceived) sent from each SUT.
3.	Disconnect/remove the physical link between the two SUTs.  (Note: ILMI procedures may provide another way to indicate that the link is down.  This requires a different test configuration also) 
4.	Reconnect the physical link between the two SUTs using the same ports.

Verdict Criteria:
The first Hello packet observed from each SUT will have the Remote node ID field and Remote port ID field set to zero; and Hello Interval field, Port ID field and Node ID set to non-zero.

Consequence of Failure:	The old PNNI information was retained causing the protocol not to operate.
4.3.2	
4.3.2	For the Hello Protocol (SS_B)

All tests in this section require both SUTs to be in different lowest level peer groups.

All tests in this section use Test Configuration #1.

----------------------------------
1.	Test Case ID:	V4302H__001
Test Purpose:	Verify that the Hello Protocol is running on an operational physical link.
Reference:	5.6
Pre-requisite:	Both SUTs are SS_B and in different lowest level peer groups.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.

Verdict Criteria:
Hello packets shall be observed in both directions on the PNNI.

Consequence of Failure:	The PNNI protocol can not operate.

2.	Test Case ID:	V4302H__002
Test Purpose:	Verify that a PNNI version number is agreed upon.
Reference:	5.6.1
Pre-requisite:	Both SUTs are SS_B and in different lowest level peer groups.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Ignore the first Hello Packet from each side, as these packets are only the start of the negotiation process for the version field value.

Verdict Criteria:
Observe that the value in the version field in the next exchanged Hello packets is the same in both directions, is the value between the oldest- and newest-version supported field, and is the value the highest common value.

Consequence of Failure:	The PNNI protocol can not operate unless a single version is agreed to.

3.	Test Case ID:	V4302H__003
Test Purpose:	Verify that the Hello sent from both sides contains Hello Interval and Port ID set to non-zero.
Reference:	5.6.2.3
Pre-requisite:	Both SUTs are SS_B and in different lowest level peer groups.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.

Verdict Criteria:
Observe that the value in Hello Interval field and the Port ID field is set to non-zero.

Consequence of Failure:	The PNNI protocol can not operate unless the Hello Interval and Port ID are set to non-zero.

4.	Test Case ID:	V4302H__004
Test Purpose:	Verify that the first Hello sent from both sides contains Remote node ID and Remote port ID set to zero.
Reference:	5.6.2.1.4 (Hp1), 5.6.2.1.2 (1-WayOutside), 5.6.2.1.3 (1-WayOutsideReceived)
Pre-requisite:	Both SUTs are SS_B and in different lowest level peer groups.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.

Verdict Criteria:
The first Hello packet observed from each SUT will have the Remote node ID field and Remote port ID field set to zero.

Consequence of Failure:	The old PNNI information was retained causing the protocol not to operate.

5.	Test Case ID:	V4302H__005
Test Purpose:	Verify that the SUTs determine that they are in different peer groups.
Reference:	5.6.2.1.4 (Hp5)
Pre-requisite:	Both SUTs are SS_B and in different lowest level peer groups.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that one Hello (1-WayOutside) packet is sent from each SUT.

Verdict Criteria:
Observe that a Nodal hierarchy list information group is present in the next Hello packet sent by each SUT.

Consequence of Failure:	If the PNNI Nodal hierarchy information is not present, then the routing hierarchy can not be established.

6.	Test Case ID:	V4302H__006
Test Purpose:	Verify that after receiving a Hello (1-WayOutsideReceived) that the SUT acknowledges the remote identification information.
Reference:	5.6.2.1.4 (Hp5)
Pre-requisite:	Both SUTs are SS_B and in different lowest level peer groups.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Monitor stores the values contained in the Node Id and Port ID fields in the first Hello sent by each SUT.

Verdict Criteria:
Observe that the next Hello sent from SUT A contains in the Remote node ID and Remote port ID fields values that are the same as those stored as the Node ID and Port ID, respectively in the Hello from SUT B. 
- AND -
Observe that the next Hello sent from SUT B contains in the Remote node ID and Remote port ID fields values that are the same as those stored as the Node ID and Port ID, respectively in the Hello from SUT A. 

Consequence of Failure:	The PNNI protocol can not operate (i.e. progress to next step).

7.	Test Case ID:	V4302H__007
Test Purpose:	Verify that after receiving a Hello (2-WayOutsideReceived) that the SUT acknowledges the remote identification information.
Reference:	5.6.2.1.4 (Hp5)
Pre-requisite:	Both SUTs are SS_B and in different lowest level peer groups.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Monitor stores the values contained in the Node Id, Port ID, Remote node ID, and Remote port ID fields in the first Hello that has the Remote node ID and Remote port ID fields set to something other than zero sent by each SUT.

Verdict Criteria:
Observe that the next Hello sent from SUT A contains in the Node ID, Port ID, Remote node ID, and Remote port ID fields values that are the same as those stored in Test Procedure step #2) as the Remote node ID, Remote port ID, Node ID and Port ID, respectively in the Hello from SUT B. 
- AND -
Observe that the next Hello sent from SUT B contains in the Node ID, Port ID, Remote node ID, and Remote port ID fields values that are the same as those stored in Test Procedure step #2) as the Remote node ID, Remote port ID, Node ID and Port ID, respectively in the Hello from SUT A. 

Consequence of Failure:	The PNNI protocol can not operate (i.e. progress to next step).

8.	Test Case ID:	V4302H__008
Test Purpose:	Verify that Hello packets are transmitted periodically (i.e. when the Hello Timer expires).
Reference:	5.6.2.1.4 (Hp15)
Pre-requisite:	Both SUTs are SS_B and in different lowest level peer groups.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Monitor shall set two timers, Ta and Tb, with the value observed in the Hello interval field in the last Hello packet sent from each SUT, respectively, plus some delta.
3a.	Start the monitor timer (Ta) when the first Hello (2-WayOutsideReceived) is sent from SUT A.
3b.	Start a monitor timer (Tb) when the first Hello (2-WayOutsideReceived) is sent from SUT B.

Verdict Criteria:
Observe that before the timer, Ta, expires a Hello is sent by SUT A.
- AND -
Observe that before the timer, Tb, expires a Hello is sent by SUT B.

Consequence of Failure:	The PNNI protocol information is not updated and keep alive not working (system decays and then collapses).

9.	Test Case ID:	V4302H__009
Test Purpose:	Verify that each SUT transmits an Uplink Information Attribute (ULIA) information group (34) containing one or more outgoing resource availability information groups (128) describing all metrics.
Reference:	5.6.2.1.4 (Hp5 & Hp6), 5.6.2.2, 5.6.2.2.1
Pre-requisite:	Both SUTs are SS_B and in different lowest level peer groups.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that one Hello (1-WayOutside) packet is sent from each SUT.

Verdict Criteria:
Observe that an Uplink Information Attribute (ULIA) information group (34) containing one or more outgoing resource availability information groups (128)describing all metrics for all supported service categories is present in the next Hello packet sent by each SUT.

Consequence of Failure:	If the PNNI protocol information is not passed, the link can not be used, since the resources are not known.

10.	Test Case ID:	E4302H__010
Test Purpose:	Verify that after a physical link failure, when corrected, that the Hello protocol starts over again from the beginning.
Reference:	5.6.2.1.4 (Hp1), 5.6.2.3
Pre-requisite:	Both SUTs are SS_B and in different lowest level peer groups.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe at least one Hello (2-WayOutsideReceived) sent from each SUT.
3.	Disconnect/remove the physical link between the two SUTs.  (Note: ILMI procedures may provide another way to indicate that the link is down.  This requires a different test configuration also) 
4.	Reconnect the two SUTs using the same ports.

Verdict Criteria:
The first Hello packet observed from each SUT will have the Remote node ID field and Remote port ID field set to zero; and Hello Interval field, Port ID field and Node ID set to non-zero.

Consequence of Failure:	The old PNNI information was retained causing the protocol not to operate.
4.3.3	
4.3.3	For the Hello Protocol

All tests in this section require both SUTs to be in different lowest level peer groups.

----------------------------------
1.	Test Case ID:	V4303H__001
Test Purpose:	Verify that the Hello Protocol is running on an operational physical link.
Reference:	5.6
Pre-requisite:	Both SUTs are SS_B
Arrange the topology state of switches SUT A and SUT B such that:
- Tester A and SUT A belong to the same lowest level peer group, with PGL Tester A,
- Tester B and SUT B belong to the same lowest level peer group, with PGL Tester B,
- Both SUTs and both Testers have the same parent peer group.
Test Configuration:	#3a

Test Set-up:
1a.	Connect Tester A (PNNI) to SUT A.
1b.	Connect Tester B (PNNI) to SUT B.
2.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.

Verdict Criteria:
Hello packets shall be observed in both directions on the PNNI.

Consequence of Failure:	The PNNI protocol can not operate.

2.	Test Case ID:	V4303H__002
Test Purpose:	Verify that a PNNI version number is agreed upon.
Reference:	5.6.1
Pre-requisite:	Both SUTs are SS_B
Arrange the topology state of switches SUT A and SUT B such that:
- Tester A and SUT A belong to the same lowest level peer group, with PGL Tester A,
- Tester B and SUT B belong to the same lowest level peer group, with PGL Tester B,
- Both SUTs and both Testers have the same parent peer group.
Test Configuration:	#3a

Test Set-up:
1a.	Connect Tester A (PNNI) to SUT A.
1b.	Connect Tester B (PNNI) to SUT B.
2.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Ignore the first Hello Packet from each side, as these packets are only the start of the negotiation process for the version field value.

Verdict Criteria:
Observe that the value in the version field in the next exchanged Hello packets is the same in both directions, is the value between the oldest- and newest-version supported field, and is the value the highest common value.

Consequence of Failure:	The PNNI protocol can not operate unless a single version is agreed to.

3.	Test Case ID:	V4303H__003
Test Purpose:	Verify that the Hello sent from both sides contains Hello Interval and Port ID set to non-zero.
Reference:	5.6.2.3
Pre-requisite:	Both SUTs are SS_B
Arrange the topology state of switches SUT A and SUT B such that:
- Tester A and SUT A belong to the same lowest level peer group, with PGL Tester A,
- Tester B and SUT B belong to the same lowest level peer group, with PGL Tester B,
- Both SUTs and both Testers have the same parent peer group.
Test Configuration:	#3a

Test Set-up:
1a.	Connect Tester A (PNNI) to SUT A.
1b.	Connect Tester B (PNNI) to SUT B.
2.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.

Verdict Criteria:
Observe that the value in Hello Interval field and the Port ID field is set to non-zero.

Consequence of Failure:	The PNNI protocol can not operate unless the Hello Interval and Port ID are set to non-zero.

4.	Test Case ID:	V4303H__004
Test Purpose:	Verify that the first Hello sent from both sides contains Remote node ID and Remote port ID set to zero.
Reference:	5.6.2.1.4 (Hp1), 5.6.2.1.2 (1-WayOutside), 5.6.2.1.3 (1-WayOutsideReceived)
Pre-requisite:	Both SUTs are SS_B
Arrange the topology state of switches SUT A and SUT B such that:
- Tester A and SUT A belong to the same lowest level peer group, with PGL Tester A,
- Tester B and SUT B belong to the same lowest level peer group, with PGL Tester B,
- Both SUTs and both Testers have the same parent peer group.
Test Configuration:	#3a

Test Set-up:
1a.	Connect Tester A (PNNI) to SUT A.
1b.	Connect Tester B (PNNI) to SUT B.
2.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.

Verdict Criteria:
The first Hello packet observed from each SUT will have the Remote node ID field and Remote port ID field set to zero.

Consequence of Failure:	The old PNNI information was retained causing the protocol not to operate.

5.	Test Case ID:	V4303H__005
Test Purpose:	Verify that the SUTs determine that they are in different peer groups.
Reference:	5.6.2.1.4 (Hp5)
Pre-requisite:	Both SUTs are SS_B
Arrange the topology state of switches SUT A and SUT B such that:
- Tester A and SUT A belong to the same lowest level peer group, with PGL Tester A,
- Tester B and SUT B belong to the same lowest level peer group, with PGL Tester B,
- Both SUTs and both Testers have the same parent peer group.
Test Configuration:	#3a

Test Set-up:
1a.	Connect Tester A (PNNI) to SUT A.
1b.	Connect Tester B (PNNI) to SUT B.
2.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that one Hello (1-WayOutside) packet is sent from each SUT.

Verdict Criteria:
Observe that a Nodal hierarchy list information group is present in the next Hello packet sent by each SUT.

Consequence of Failure:	If the PNNI Nodal hierarchy information is not present, then the routing hierarchy can not be established.

6.	Test Case ID:	V4303H__006
Test Purpose:	Verify that after receiving a Hello (1-WayOutsideReceived) that the SUT acknowledges  the remote identification information.
Reference:	5.6.2.1.4 (Hp5)
Pre-requisite:	Both SUTs are SS_B
Arrange the topology state of switches SUT A and SUT B such that:
- Tester A and SUT A belong to the same lowest level peer group, with PGL Tester A,
- Tester B and SUT B belong to the same lowest level peer group, with PGL Tester B,
- Both SUTs and both Testers have the same parent peer group.
Test Configuration:	#3a

Test Set-up:
1a.	Connect Tester A (PNNI) to SUT A.
1b.	Connect Tester B (PNNI) to SUT B.
2.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Monitor stores the values contained in the Node Id and Port ID fields in the first Hello sent by each SUT.

Verdict Criteria:
Observe that the next Hello sent from SUT A contains in the Remote node ID and Remote port ID fields values that are the same as those stored as the Node ID and Port ID, respectively in the Hello from SUT B.
- AND -
Observe that the next Hello sent from SUT B contains in the Remote node ID and Remote port ID fields values that are the same as those stored as the Node ID and Port ID, respectively in the Hello from SUT A.

Consequence of Failure:	The PNNI protocol can not operate (i.e. progress to next step).

7.	Test Case ID:	V4303H__007
Test Purpose:	Verify that after receiving a Hello (2-WayOutsideReceived) that the SUT acknowledges the remote identification information.
Reference:	5.6.2.1.4 (Hp5)
Pre-requisite:	Both SUTs are SS_B
Arrange the topology state of switches SUT A and SUT B such that:
- Tester A and SUT A belong to the same lowest level peer group, with PGL Tester A,
- Tester B and SUT B belong to the same lowest level peer group, with PGL Tester B,
- Both SUTs and both Testers have the same parent peer group.
Test Configuration:	#3a

Test Set-up:
1a.	Connect Tester A (PNNI) to SUT A.
1b.	Connect Tester B (PNNI) to SUT B.
2.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Monitor stores the values contained in the Node Id, Port ID, Remote node ID, and Remote port ID fields in the first Hello that has the Remote node ID and Remote port ID fields set to something other than zero sent by each SUT.

Verdict Criteria:
Observe that the next Hello sent from SUT A contains in the Node ID, Port ID, Remote node ID, and Remote port ID fields values that are the same as those stored in Test Procedure step #2) as the Remote node ID, Remote port ID, Node ID and Port ID, respectively in the Hello from SUT B. 
- AND -
Observe that the next Hello sent from SUT B contains in the Node ID, Port ID, Remote node ID, and Remote port ID fields values that are the same as those stored in Test Procedure step #2) as the Remote node ID, Remote port ID, Node ID and Port ID, respectively in the Hello from SUT A. 

Consequence of Failure:	The PNNI protocol can not operate (i.e. progress to next step).

8.	Test Case ID:	V4303H__008
Test Purpose:	Verify that Hello packets are transmitted periodically (i.e. when the Hello Timer expires).
Reference:	5.6.2.1.4 (Hp15)
Pre-requisite:	Both SUTs are SS_B
Arrange the topology state of switches SUT A and SUT B such that:
- Tester A and SUT A belong to the same lowest level peer group, with PGL Tester A,
- Tester B and SUT B belong to the same lowest level peer group, with PGL Tester B,
- Both SUTs and both Testers have the same parent peer group.
Test Configuration:	#3a

Test Set-up:
1a.	Connect Tester A (PNNI) to SUT A.
1b.	Connect Tester B (PNNI) to SUT B.
2.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Monitor shall set two timers, Ta and Tb, with the value observed in the Hello interval field in the last Hello packet sent from each SUT, respectively, plus some delta.
3a.	Start the monitor timer (Ta) when the first Hello (2-WayOutsideReceived) is sent from SUT A.
3b.	Start a monitor timer (Tb) when the first Hello (2-WayOutsideReceived) is sent from SUT B.

Verdict Criteria:
Observe that before the timer, Ta, expires a Hello is sent by SUT A.
- AND -
Observe that before the timer, Tb, expires a Hello is sent by SUT B.

Consequence of Failure:	The PNNI protocol information is not updated and keep alive not working (system decays and then collapses).

9.	Test Case ID:	V4303H__009
Test Purpose:	Verify that each SUT transmits an Uplink Information Attribute (ULIA) information group (34) containing one or more outgoing resource availability information groups (128) describing all metrics.
Reference:	5.6.2.1.4 (Hp5 & Hp6), 5.6.2.2, 5.6.2.2.1
Pre-requisite:	Both SUTs are SS_B
Arrange the topology state of switches SUT A and SUT B such that:
- Tester A and SUT A belong to the same lowest level peer group, with PGL Tester A,
- Tester B and SUT B belong to the same lowest level peer group, with PGL Tester B,
- Both SUTs and both Testers have the same parent peer group.
Test Configuration:	#3a

Test Set-up:
1a.	Connect Tester A (PNNI) to SUT A.
1b.	Connect Tester B (PNNI) to SUT B.
2.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that one Hello (1-WayOutside) packet is sent from each SUT.

Verdict Criteria:
Observe that an Uplink Information Attribute (ULIA) information group (34) containing one or more outgoing resource availability information groups (128)describing all metrics for all supported service categories is present in the next Hello packet sent by each SUT.

Consequence of Failure:	If the PNNI protocol information is not passed, the link can not be used, since the resources are not known.

10.	Test Case ID:	V4303H__010
Test Purpose:	Verify that two SUTs in different peer groups can agree on a common peer group using outside Hellos, resulting in the advertisement of uplinks by each SUT.
Reference:	5.6.2.1.3 (CommonHierarchyReceived), 5.6.2.1.4 (Hp6 & Hp7), 5.6.2.3
Pre-requisite:	Both SUTs are SS_B
Arrange the topology state of switches SUT A and SUT B such that:
- Tester A and SUT A belong to the same lowest level peer group, with PGL Tester A,
- Tester B and SUT B belong to the same lowest level peer group, with PGL Tester B,
- Both SUTs and both Testers have the same parent peer group.
Test Configuration:	#3a

Test Set-up:
1a.	Connect Tester A (PNNI) to SUT A.
1b.	Connect Tester B (PNNI) to SUT B.
2.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI RCCs (VPI/VCI=0/18) between SUT A and SUT B, between Tester A and SUT A, and between Tester B and SUT B.
2.	Enable the links between the Testers and the SUTs, and let PNNI routing complete in each peer group.
3.	Enable the link between the two SUTs
4.	Observe that Hello packets are sent from each SUT to the other SUT.

Verdict Criteria:
Observe that SUT A sends a PTSE to Tester A including an uplink information group describing an uplink from the node ID of SUT A to the parent node ID of SUT B.  The Common Peer Group ID in that uplink information group is the parent peer group ID of SUT A and SUT B.
- AND -
Observe that SUT B sends a PTSE to Tester B including an uplink information group describing an uplink from the node ID of SUT B to the parent node ID of SUT A.  The Common Peer Group ID in that uplink information group is the parent peer group ID of SUT A and SUT B.

11.	Test Case ID:	V4303H__011
Test Purpose:	Verify that when SUT B is in the parent peer group of SUT A, the SUTs can agree on a common peer group using outside Hellos, resulting in the advertisement of an uplink by SUT A and an attempt to establish an SVCC-based RCC from SUT B to the parent LGN of SUT A.
Reference:	5.5.5, 5.6.2.1.3 (CommonHierarchyReceived), 5.6.2.1.4 (Hp6 & Hp7), 5.6.2.3
Pre-requisite:	SUT A is SS_B.
SUT B is SS_N.
Arrange the togology state of switches SUT A and SUT B such that:
- Tester A and SUT A belong to the same lowest level peer group, with PGL Tester A,
- SUT B's lowest level peer group is the parent peer group of Tester A and SUT A,
- SUT B's node ID is larger than the parent node ID of Tester A and SUT A.
Test Configuration:	#2

Test Set-up:
1.	Connect Tester A (PNNI) to SUT A.
2.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI RCCs (VPI/VCI=0/18) between SUT A and SUT B, and between Tester A and SUT A.  Also monitor the PNNI signalling channel (VPI/VCI=0/5) between SUT A and SUT B.
2.	Enable the link between Tester A and SUT A, and let PNNI routing complete in that peer group.
3.	Enable the link between the two SUTs.
4.	Observe that Hello packets are sent from each SUT to the other SUT.

Verdict Criteria:
Observe that SUT A sends a PTSE to Tester A including an uplink information group describing an uplink from the node ID of SUT A to the node ID of SUT B.  The Common Peer Group ID in that uplink information group is the parent peer group ID of SUT A, which is also the peer group ID of SUT B.
- AND -
Observe that SUT B sends a SETUP message to SUT A.  The called party address in the SETUP message is the address of the parent node of SUT A, as indicated in the nodal hierarchy list advertised in SUT A's Hellos.

Consequence of Failure:	The link between the SUTs cannot be used and the hierarchy cannot be established.

12.	Test Case ID:	E4303H__012
Test Purpose:	Verify that after a physical link failure, when corrected, that the Hello protocol starts over again from the beginning.
Reference:	5.6.2.1.4 (Hp1), 5.6.2.3
Pre-requisite:	Both SUTs are SS_B
Arrange the topology state of switches SUT A and SUT B such that:
- Tester A and SUT A belong to the same lowest level peer group, with PGL Tester A,
- Tester B and SUT B belong to the same lowest level peer group, with PGL Tester B,
- Both SUTs and both Testers have the same parent peer group.
Test Configuration:	#3a

Test Set-up:
1a.	Connect Tester A (PNNI) to SUT A.
1b.	Connect Tester B (PNNI) to SUT B.
2.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe at least one Hello (2-WayOutsideReceived) sent from each SUT.
3.	Disconnect/remove the physical link between the two SUTs.  (Note: ILMI procedures may provide another way to indicate that the link is down.  This requires a different test configuration also) 
4.	Reconnect the two SUTs using the same ports.

Verdict Criteria:
The first Hello packet observed from each SUT will have the Remote node ID field and Remote port ID field set to zero; and Hello Interval field, Port ID field and Node ID set to non-zero.

Consequence of Failure:	The old PNNI information was retained causing the protocol not to operate.
4.4	
4.4	Database Synchronization Protocol
4.4.1	For the Database Synchronization Protocol (SS_M)

All tests in this section require both SUTs to be in the same lowest level peer group.

All tests in this section use Test Configuration #1.

Tests in this section should only be run, if the SUTs passed
Test Case V4301H__007.
---------------------------------------------
1.	Test Case ID:	V4401DBS001
Test Purpose:	Verify that the Database Synchronization protocol commences only after reaching the 2-WayInside state.
Reference:	5.7
Pre-requisite:	Both SUTs must be in the same lowest level peer group and have passed Test Case V4301H__007.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that no Database summary packets are transmitted.
3.	Observe that Test Case V4301H__007 occurs.

Verdict Criteria:
Observe that a Database Summary packet is sent from each SUT after reaching Test Procedure step #3 and not before.

Consequence of Failure:	The Database Synchronization protocol is operating before the link to the neighbor is active (which is indicated by reaching the 2-WayInside state).

2.	Test Case ID:	V4401DBS002
Test Purpose:	Verify that the SUTs agree on which SUT is master and which SUT is slave. 
Reference:	5.7
Pre-requisite:	Both SUTs must be in the same lowest level peer group and have passed Test Case V4301H__007.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Store the Node ID for both SUT A and SUT B.
3.	Observe that no Database summary packets are transmitted.
4.	Observe that Test Case V4301H__007 occurs.
5.	Observe that one Database summary packet is sent from the SUT with the higher node ID from Test Procedure step #2 and store the DS sequence number of that Database summary packet.
6.	Ignore any Database summary packets sent from the SUT with the lower node ID before Test Procedure step #5.

Verdict Criteria:
Observe that the next Database summary packet sent by the SUT with the lower node ID contains the Master bit set to zero, the Initialize bit to zero, and the DS sequence number set to the value stored for the SUT which has the higher node ID from Test procedure step 2 and contains some data base summaries.
- OR -
Ignore the next Database summary packet sent by the SUT with the lower node ID, if it contains the Master, More and Initialize bits set to one and the contents of the packet is empty.  Then observe that the next Database summary packet sent by the SUT with the lower node ID contains the Master bit set to zero, the Initialize bit to zero, and the DS sequence number set to the value stored for the SUT which has the higher node ID from Test procedure step 2 and contains some data base summaries.
- AND -
Observe that the next Database summary packet sent by the SUT with the higher node ID contains the Master bit set to one, the Initialize bit to zero, and the DS sequence number set to the value stored for the SUT with the higher node ID from Test procedure step 2 incremented by one and contains some data base summaries.
- OR -
Ignore the next Database summary packet sent by the SUT with the higher node ID, if it contains the Master, More and Initialize bits set to one and the contents of the packet is empty.  Then observe that the next Database summary packet sent by the SUT with the higher node ID contains the Master bit set to one, the Initialize bit to zero, and the DS sequence number set to the value stored for the SUT with the higher node ID from Test procedure step 2 incremented by one and contains some data base summaries."

Consequence of Failure:	If a master and slave are not agreed to, then the Database Synchronization protocol can not proceed to next step and begin exchanging databases.

3.	Test Case ID:	V4401DBS003
Test Purpose:	Verify that the SUTs request the PTSEs that were contained in the Database summary packets.
Reference:	5.7.7
Pre-requisite:	Both SUTs must be in the same lowest level peer group and have passed Test Case V4401DBS002.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4401DBS002 occurs.
3.	Store the Nodal PTSE summaries from each database summary packet.

Verdict Criteria:
Observe that each SUT sends a PTSERequest packet for each Nodal PTSE summaries received from the other SUT.

Consequence of Failure:	If the SUT does not request information, then it can not learn about the network to which it is attached and therefore can not create routes for calls.

4.	Test Case ID:	V4401DBS004
Test Purpose:	Verify that the SUTs exchange their complete Database summaries. 
Reference:	5.7 & 5.8.2
Pre-requisite:	Both SUTs must be in the same lowest level peer group and have passed Test Case V4401DBS003.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4401DBS003 occurs.
3.	Store the PTSERequest packets from each SUT.

Verdict Criteria:
Observe that each SUT sends one or more PTSP packets that contain the PTSEs for each PTSE Requested by the other SUT until at least one occurrence of each PTSE is found.

Consequence of Failure:	If the SUTs do not send their entire database information, then they can not learn the complete information about each other.

5.	Test Case ID:	V4401DBS005
Test Purpose:	Verify that neither SUT advertises this lower -level link until the neighboring peer state machine is in the Full state. 
Reference:	5.7
Pre-requisite:	Both SUTs must be in the same lowest level peer group and have passed Test Case V4401DBS003.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4401DBS003 occurs.
3.	Store all PTSEs from each SUT.
4.	Observe that this link is not advertised in any of the PTSEs.
5.	Observe that Test Case V4401DBS004 occurs.

Verdict Criteria:
Observe that a PTSE for this link is originated by either SUT.
Consequence of Failure:	If either SUT advertises the shared link before reaching the Full state, system may become confused since this would indicate that the link already existed, but it just started.
4.4.2	
4.4.2	For the Database Synchronization Protocol (SS_P)

All tests in this section use Test Configuration #5.

Tests in this section are carried out over an SVC Based RCC which is established between the two SUTs.  Therefore it is assumed that for the given configuration, the two SUTs have passed the necessary tests to ensure this capability.  A high level description of these necessary tests is now described.
i)	Observations at Monitor Points DA and DC should be similar to those test cases in section 4.6.2.
(i.e. for Monitor Point DA, SUT A is SS_P and Tester D is not SS_P: V4602PGL001 and V4602PGL002;
for Monitor Point DC, SUT B is SS_P and Tester D is not SS_P: V4602PGL003 and V4602PGL004)
ii)	Followed by observations at Monitor Points DA and DC similar to those test cases in section 4.7.1
iii)	Followed by the same observations at both Monitor Points DA and DC similar to those test cases in section 4.8.1 i) where both SUTs are PGL
(i.e. V4801LGN004, V4801LGN005, and V4801LGN006)
iv)	Followed by the same observations at both Monitor Points DA and DC similar to those test cases in section 4.8.2.
(i.e. V4802LGN001 and V4802LGN002)

Figure 4.4.2-1

---------------------------------------------
1.	Test Case ID:	V4402DBS001
Test Purpose:	Verify that the Database Synchronization protocol commences only after reaching the 2-WayInside state.
Reference:	5.7
Pre-requisite:	Both SUTs are SS_P,
Arrange the topology state of switches SUT A, SUT B, and Tester D such that:
- SUT A and SUT B are in different peer groups,
-Tester D has two lowest level nodes, one in SUT A's peer group and one in SUT B's peer group that are logically connected with a PNNI link (see figure 4.4.2-1),
- Both SUTs are configured as PGLs with the same parent peer group.
Test Configuration:	#5

Test Set-up:
1.	Connect Tester D (PNNI) to SUT A.
2.	Connect Tester D (PNNI) to SUT B.

Test Procedure:
1.	Monitor the PNNI Signalling channel (VPI/VCI=0/5) between SUT A and Tester D and between SUT B and Tester D.
2.	Store the VPI/VCIs in the SETUP messages sent to establish the SVCC-based RCC.
3.	Monitor the PNNI RCC (VPI/VCIs of the SVCC-based RCC) between SUT A and SUT B (monitor points DA and DC).
4.	Observe that no Database summary packets are transmitted.
5.	Observe that Test Case V4802LGN002 occurs.

Verdict Criteria:
Observe that a Database Summary packet is sent from each SUT after reaching Test Procedure step #5 and not before.

Consequence of Failure:	The Database Synchronization protocol is operating before the link to the neighbor is active (which is indicated by reaching the 2-WayInside state).

2.	Test Case ID:	V4402DBS002
Test Purpose:	Verify that the SUTs agree on which SUT is master and which SUT is slave. 
Reference:	5.7
Pre-requisite:	Both SUTs are SS_P,
Arrange the topology state of switches SUT A, SUT B, and Tester D such that:
- SUT A and SUT B are in different peer groups,
-Tester D has two lowest level nodes, one in SUT A's peer group and one in SUT B's peer group that are logically connected with a PNNI link (see figure 4.4.2-1),
- Both SUTs are configured as PGLs with the same parent peer group.
Test Configuration:	#5

Test Set-up:
1.	Connect Tester D (PNNI) to SUT A.
2.	Connect Tester D (PNNI) to SUT B.

Test Procedure:
1.	Monitor the PNNI Signalling channel (VPI/VCI=0/5) between SUT A and Tester D and between SUT B and Tester D.
2.	Store the VPI/VCIs in the SETUP messages sent to establish the SVCC-based RCC.
3.	Monitor the PNNI RCC (VPI/VCIs of the SVCC-based RCC) between SUT A and SUT B (monitor points DA and DC).
4.	Store the Node ID for both SUT A and SUT B.
5.	Observe that no Database summary packets are transmitted.
6.	Observe that Test Case V4802LGN002 occurs.
7.	Observe that one Database summary packet is sent from the SUT with the higher node ID from Test Procedure step #4 and store the DS sequence number of that Database summary packet.
8.	Ignore any Database summary packets sent from the SUT with the lower node ID before Test Procedure step #7.

Verdict Criteria:
Observe that the next Database summary packet sent by the SUT with the lower node ID contains the Master bit set to zero, the Initialize bit to zero, and the DS sequence number set to the value stored for the SUT which has the higher node ID from Test procedure step #4 and contains some data base summaries. 
- OR -
Ignore the next Database summary packet sent by the SUT with the lower node ID, if it contains the Master, More and Initialize bits set to one and the contents of the packet is empty.  Then observe that the next Database summary packet sent by the SUT with the lower node ID contains the Master bit set to zero, the Initialize bit to zero, and the DS sequence number set to the value stored for the SUT which has the higher node ID from Test procedure step #4 and contains some data base summaries.
- AND -
Observe that the next Database summary packet sent by the SUT with the higher node ID contains the Master bit set to one, the Initialize bit to zero, and the DS sequence number set to the value stored for the SUT with the higher node ID from Test procedure step #4 incremented by one and contains some data base summaries.
- OR -
Ignore the next Database summary packet sent by the SUT with the higher node ID, if it contains the Master, More and Initialize bits set to one and the contents of the packet is empty.  Then observe that the next Database summary packet sent by the SUT with the higher node ID contains the Master bit set to one, the Initialize bit to zero, and the DS sequence number set to the value stored for the SUT with the higher node ID from Test procedure step #4 incremented by one and contains some data base summaries."

Consequence of Failure:	If a master and slave are not agreed to, then the Database Synchronization protocol can not proceed to next step and begin exchanging databases.

3.	Test Case ID:	V4402DBS003
Test Purpose:	Verify that the SUTs request the PTSEs that were contained in the Database summary packets. 
Reference:	5.7.7
Pre-requisite:	Both SUTs must have passed Test Case V4402DBS002.
Both SUTs are SS_P,
Arrange the topology state of switches SUT A, SUT B, and Tester D such that:
- SUT A and SUT B are in different peer groups,
- Tester D has two lowest level nodes, one in SUT A's peer group and one in SUT B's peer group that are logically connected with a PNNI link (see figure 4.4.2-1),
- Both SUTs are configured as PGLs with the same parent peer group.
Test Configuration:	#5

Test Set-up:
1.	Connect Tester D (PNNI) to SUT A.
2.	Connect Tester D (PNNI) to SUT B.

Test Procedure:
1.	Monitor the PNNI Signalling channel (VPI/VCI=0/5) between SUT A and Tester D and between SUT B and Tester D.
2.	Store the VPI/VCIs in the SETUP messages sent to establish the SVCC-based RCC.
3.	Monitor the PNNI RCC (VPI/VCIs of the SVCC-based RCC) between SUT A and SUT B (monitor points DA and DC).
4.	Observe that Test Case V4402DBS002 occurs.
5.	Store the Nodal PTSE summaries from each database summary packet.

Verdict Criteria:
Observe that each SUT sends a PTSERequest packet for each Nodal PTSE summaries received from the other SUT.

Consequence of Failure:	If the SUT does not request information, then it can not learn about the network to which it is attached and therefore can not create routes for calls.

4.	Test Case ID:	V4402DBS004
Test Purpose:	Verify that the SUTs exchange their complete Database summaries.
Reference:	5.7 & 5.8.2
Pre-requisite:	Both SUTs must have passed Test Case V4402DBS003.
Both SUTs are SS_P,
Arrange the topology state of switches SUT A, SUT B, and Tester D such that:
- SUT A and SUT B are in different peer groups,
- Tester D has two lowest level nodes, one in SUT A's peer group and one in SUT B's peer group that are logically connected with a PNNI link (see figure 4.4.2-1),
- Both SUTs are configured as PGLs with the same parent peer group.
Test Configuration:	#5

Test Set-up:
1.	Connect Tester D (PNNI) to SUT A.
2.	Connect Tester D (PNNI) to SUT B.

Test Procedure:
1.	Monitor the PNNI Signalling channel (VPI/VCI=0/5) between SUT A and Tester D and between SUT B and Tester D.
2.	Store the VPI/VCIs in the SETUP messages sent to establish the SVCC-based RCC.
3.	Monitor the PNNI RCC (VPI/VCIs of the SVCC-based RCC) between SUT A and SUT B (monitor points DA and DC).
4.	Observe that Test Case V4402DBS003 occurs.
5.	Store the PTSERequest packets from each SUT.

Verdict Criteria:
Observe that each SUT sends one or more PTSP packets that contain the PTSEs for each PTSE Requested by the other SUT until at least one occurrence of each PTSE is found.

Consequence of Failure:	If the SUTs do not send their entire database information, then they can not learn the complete information about each other.

5.	Test Case ID:	V4402DBS005
Test Purpose:	Verify that neither SUT advertises this lower -level link until the neighboring peer state machine is in the Full state.
Reference:	5.7
Pre-requisite:	Both SUTs must have passed Test Case V4402DBS003.
Both SUTs are SS_P,
Arrange the topology state of switches SUT A, SUT B, and Tester D such that:
- SUT A and SUT B are in different peer groups,
- Tester D has two lowest level nodes, one in SUT A's peer group and one in SUT B's peer group that are logically connected with a PNNI link (see figure 4.4.2-1),
- Both SUTs are configured as PGLs with the same parent peer group.
Test Configuration:	#5

Test Set-up:
1.	Connect Tester D (PNNI) to SUT A.
2.	Connect Tester D (PNNI) to SUT B.

Test Procedure:
1.	Monitor the PNNI Signalling channel (VPI/VCI=0/5) between SUT A and Tester D and between SUT B and Tester D.
2.	Store the VPI/VCIs in the SETUP messages sent to establish the SVCC-based RCC.
3.	Monitor the PNNI RCC (VPI/VCIs of the SVCC-based RCC) between SUT A and SUT B (monitor points DA and DC).
4.	Observe that Test Case V4402DBS003 occurs.
5.	Store all PTSEs from each SUT.
6.	Observe that this link is not advertised in any of the PTSEs.
7.	Observe that Test Case V4402DBS004 occurs.

Verdict Criteria:
Observe that a PTSE for this link is originated by either SUT.

Consequence of Failure:	If either SUT advertises the shared link before reaching the Full state, system may become confused since this would indicate that the link already existed, but it just started.
4.5	
4.5	Flooding
4.5.1	Flooding

All tests in this section require both SUTs to be in the same lowest level peer group.

All tests in this section use Test Configuration #2.

Tests in this section should only be run, if the SUTs passed
Test Case V4401DBS004.
----------------------------
1.	Test Case ID:	V4501FLD001
Test Purpose:	Verify that SUT A floods a PTSE to SUT B
Reference:	5.8.3.3 (6) (d) (iv)
Pre-requisite:	Both SUTs must be in the same lowest level peer group and have passed Test Case V4401DBS004.
Test Configuration:	#2

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	Connect Tester A to SUT A using a PNNI interface. 

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4401DBS004 occurs (i.e. Database Synchronization in Full state).
3.	Connect Tester A to SUT A using a PNNI interface.
4.	Monitor interface A until Hello protocol is in 2-Way Inside (similar behavior to Test Case V4301H__007)
5.	Monitor interface A until Database Synchronization is in state Negotiating and the Tester A is ready to send its first Database Summary Packet.
6.	Tester A sends first Database Summary packet containing at least one PTSE header.
7.	Observe a PTSE request from SUT A for this PTSE.
8.	Send PTSE to SUT A.

Verdict Criteria:
Observe that this PTSE is sent (i.e. flooded) from SUT A to SUT B with the PTSE Remaining Lifetime decremented by one.

Consequence of Failure:	New or updated information would not propagate through out the peer group, thus preventing each switch learning about all other nodes in its peer group.

2.	Test Case ID:	V4501FLD002
Test Purpose:	Verify that SUT A does not flood a PTSE with PTSE Remaining Lifetime of ExpiredAge to SUT B.
Reference:	5.8.3.3 (5) (b)
Pre-requisite:	Both SUTs must be in the same lowest level peer group and have passed Test Case V4401DBS004.
Test Configuration:	#2

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	Connect Tester A to SUT A using a PNNI interface. 

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4401DBS004 occurs (i.e. Database Synchronization in Full state).
3.	Connect Tester A to SUT A using a PNNI interface.
4.	Monitor interface A until Hello protocol is in 2-Way Inside (similar behavior to Test Case V4301H__007)
5.	Monitor interface A until Database Synchronization is in state Full (similar to behavior of Test Case V4401DBS004).
8.	Tester A send a PTSE with Remaining Lifetime set to ExpiredAge to SUT A.

Verdict Criteria:
Observe that this PTSE is not sent (i.e. flooded) from SUT A to SUT B.

4.6	Consequence of Failure:	Flooding needless information (possible congestion).
4.6	Peer Group Leader Election
4.6.1	For the Peer Group Leader Election (not PGL capable)

All tests in this section require both SUTs to be in the same peer group.

Tests in this section should only be run, if the SUTs passed
Test Case V4401DBS004 (i.e. completed Database Synchronization (in FULL state).
------------------------
1.	Test Case ID:	V4601PGL001
Test Purpose:	Verify that the nodes participate in the Peer group leader elections, when the Non-transit for PGL Election flag is not set.
Reference:	5.10.1.1, 5.10.1.1.5, PGLE5
Pre-requisite:	- Both SUTs must be in the same peer group,
- Both SUTs have passed Test Case V4401DBS004, and
- neither SUT is PGL capable.
Test Configuration: #1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4401DBS004 occurs.

Verdict Criteria:
Observe that a PTSE is sent from SUT A with its leadership priority, "I am leader" bit and the Preferred peer group leader node ID set to zero.
- AND - 
Observe that a PTSE is sent from SUT B with its leadership priority, "I am leader" bit and the Preferred peer group leader node ID set to zero.

Consequence of Failure:	If these PTSEs are not sent then a PGL can not be elected.

2.	Test Case ID:	V4601PGL002
Test Purpose:	Verify that the nodes continue participating in the Peer group leader elections, when the Non-transit for PGL Election flag is not set. (i.e. PGLInitTimer Expires).
Reference:	5.10.1.1
Pre-requisite:	- Both SUTs must be in the same peer group,
- both SUTs have passed Test Case V4601PGL001, and
- neither SUT is PGL capable.
Test Configuration: #1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4601PGL001 occurs.

Verdict Criteria:
Observe that a PTSE is sent from SUT A with its leadership priority, "I am leader" bit and the Preferred peer group leader node ID set to zero.
- AND - 
Observe that a PTSE is sent from SUT B with its leadership priority, "I am leader" bit and the Preferred peer group leader node ID set to zero.

Consequence of Failure:	If these PTSEs are not sent then a PGL can not be elected.

3.	Test Case ID:	V4601PGL003
Test Purpose:	Verify that SUT B participates in the Peer group leader elections, when the Non-transit for PGL Election flag is not set.
Reference:	5.10.1.1, 5.10.1.1.5, PGLE5
Pre-requisite:	- Both SUTs must be in the same peer group, 
- both SUTs have passed Test Case V4401DBS004, and
- neither SUT is PGL capable.
Test Configuration: #2

Test Set-up:
1.	Connect Tester A (PNNI) and SUT A with one physical link.
2.	After the PNNI between Tester A and SUT A has reached 2-Way Inside (Hello), Full (Database Synchronization), and OperNotPGL (Peer Group Leader Election), then connect SUT B to SUT A with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4401DBS004 occurs.

Verdict Criteria:
Observe that a PTSE is sent from SUT B with its leadership priority, "I am leader" bit and the Preferred peer group leader node ID set to zero.

Consequence of Failure:	If these PTSEs are not sent then a PGL can not be elected.

4.	Test Case ID:	V4601PGL004
Test Purpose:	Verify that the SUT B elects a PGL, when the Non-transit for PGL Election flag is not set. (PGLInitTimer Expires).
Reference:	5.10.1.1, 5.10.1.1.5, PGLE5
Pre-requisite:	- Both SUTs must be in the same peer group,
- both SUTs have passed Test Case V4401DBS004,
- neither SUT is PGL capable,
- Tester A has a non-zero peer group leadership priority.
Test Configuration: #2

Test Set-up:
1.	Connect Tester A (PNNI) and SUT A with one physical link.
2.	After the PNNI between Tester A (is PGL) and SUT A has reached 2-Way Inside (Hello), Full (Database Synchronization), and SUT A is in OperNotPGL and Tester A is in OperPGL (Peer Group Leader Election), then connect SUT B to SUT A with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Tester A is elected PGL by SUT A and Tester A accepts.
3.	Observe that Test Case V4401DBS004 occurs.
4.	Observe that SUT B sends a PTSE with zero in the preferred peer group leader, peer group leadership priority, and "I am leader" bits.

Verdict Criteria:
Observe that a PTSE is sent from SUT B with its leadership priority and "I am leader" bit set to zero and the Preferred peer group leader node ID is not zero (i.e. the node ID of the PGL (e.g. that Tester A is advertising)).

Consequence of Failure:	SUT B will not elect a valid PGL and may cause routing problems when processing DTLs in the SETUP message.

5.	Test Case ID:	V4601PGL005
Test Purpose:	Verify that SUT B continues to participate in the Peer group leader elections by electing a PGL when a PGL capable device joins the peer group, when the Non-transit for PGL Election flag is not set.
Reference:	5.10.1.1, 5.10.1.1.5, PGLE4
Pre-requisite:	- Both SUTs must be in the same peer group,
- both SUTs have passed Test Case V4601PGL002 and Test Case V4501FLD001,
- neither SUT is PGL capable, and
- Tester A has a non-zero peer group leadership priority.
Test Configuration: #2

Test Set-up:
1.	Connect SUT A and SUT B with one physical link.
2.	After the PNNI between SUT A and SUT B has reached 2-Way Inside (Hello), Full (Database Synchronization), and OperNotPGL (Peer Group Leader Election)(i.e. complete Test Case V4601PGL002), then connect Tester A to SUT A with a PNNI.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4601PGL002 occurs between SUT A and SUT B (i.e. at Monitor point D).
3.	Connect Tester A to SUT A with a PNNI.
4.	Observe that Test Case V4401DBS004 occurs at monitor point A.
5.	Observe that the information from Tester A (i.e. PGL) is flooded to SUT B.
6.	Observe that test case V4601PGL002 occurs at monitor point A.

Verdict Criteria:
Observe that a PTSE is sent across monitor point D (and flooded across monitor point A) from SUT B with its leadership priority, "I am leader" bit and the Preferred peer group leader node ID set to PGL advertised from Tester A.

Consequence of Failure:	SUT B will not elect a valid PGL and may cause routing problems when processing DTLs in a SETUP message.

4.6.2	6 - 8	Repeat Test Cases 3 - 5 with SUT A and SUT B interchanged.
4.6.2	For the Peer Group Leader Election (one SUT is PGL capable)

All tests in this section require both SUTs to be in the same peer group.

Tests in this section should only be run, if the SUTs passed
Test Case V4401DBS004.
--------------------------------------------
1.	Test Case ID:	V4602PGL001
Test Purpose:	Verify that SUT B elects SUT A as Peer Group Leader (Advertise their preferred Peer Group Leader).
Reference:	5.10.1.1, PGLE7
Pre-requisite:	- Both SUTs must be in the same peer group,
- both SUTs have passed Test Case V4401DBS004, and
- SUT A is SS_P and SUT B is not SS_P.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4401DBS004 occurs.
3a.	Observe that a PTSE is sent from SUT A with its leadership priority set to something other than zero and "I am leader" bit and the Preferred peer group leader node ID set to zero.
3b.	Observe that a PTSE is sent from SUT B with its leadership priority, "I am leader" bit and the Preferred peer group leader node ID set to zero.

Verdict Criteria:
1) Observe that a PTSE is sent from SUT B with its leadership priority, "I am leader" bit set to zero and the Preferred peer group leader node ID set to that of SUT A.
2) Observe that a PTSE is sent from A with its leadership priority, "I am leader" bit set to zero and the preferred peer group leader node ID set to that of SUT A (itself).

Consequence of Failure:	SUT B will not elect a valid PGL and may cause routing problems when processing DTLs in a SETUP message. Also SUT A may not get enough votes to become PGL.

2.	Test Case ID:	V4602PGL002
Test Purpose:	Verify that SUT A becomes Peer Group Leader.
Reference:	5.10.1.1, PGLE8
Pre-requisite:	- Both SUTs must be in the same peer group,
- both SUTs have passed Test Case V4401DBS004, and
- SUT A is SS_P and SUT B is not SS_P.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4401DBS004 occurs.
3a.	Observe that a PTSE is sent from SUT A with its leadership priority set to something other than zero and "I am leader" bit and the Preferred peer group leader node ID set to zero.
3b.	Observe that a PTSE is sent from SUT B with its leadership priority, "I am leader" bit and the Preferred peer group leader node ID set to zero.
4a.	Observe that a PTSE is sent from SUT A with its leadership priority set to something other than zero, the same as observed in step 3a, "I am leader" bit set to zero and the Preferred peer group leader node ID set to that of SUT A, itself.
4b.	Observe that a PTSE is sent from SUT B with its leadership priority, "I am leader" bit set to zero and the Preferred peer group leader node ID set to that of SUT A.

Verdict Criteria
Observe that a PTSE is sent from SUT A with its updated leadership priority increased by GroupLeaderIncrement, "I am leader" bit set to one, and Preferred peer group leader node ID set to that of SUT A.

Consequence of Failure:	SUT A does not become PGL, which may lead to no hierarchy of peer groups.

3.	Test Case ID:	V4602PGL003 (similar to #1, except SUT A and
SUT B are interchanged)
Test Purpose:	Verify that SUT A elects SUT B as Peer Group Leader.
Reference:	5.10.1.1, PGLE7
Pre-requisite:	- Both SUTs must be in the same peer group,
- both SUTs have passed Test Case V4401DBS004, and
- SUT B is SS_P and SUT A is not SS_P.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4401DBS004 occurs.
3a.	Observe that a PTSE is sent from SUT B with its leadership priority set to something other than zero and "I am leader" bit and the Preferred peer group leader node ID set to zero.
3b.	Observe that a PTSE is sent from SUT A with its leadership priority, "I am leader" bit and the Preferred peer group leader node ID set to zero.

Verdict Criteria:
Observe that a PTSE is sent from SUT A with its leadership priority, "I am leader" bit set to zero and the Preferred peer group leader node ID set to that of SUT B.

Consequence of Failure:	SUT A will not elect a valid PGL and may cause routing problems when processing DTLs in a SETUP message. Also SUT B may not get enough votes to become PGL.

4.	Test Case ID:	V4602PGL004 (similar to #2, except SUT A and
SUT B are interchanged)
Test Purpose:	Verify that SUT B becomes Peer Group Leader.
Reference:	5.10.1.1, PGLE8
Pre-requisite:	- Both SUTs must be in the same peer group,
- both SUTs have passed Test Case V4401DBS004, and
- SUT B is SS_P and SUT A is not SS_P.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4401DBS004 occurs.
3a.	Observe that a PTSE is sent from SUT B with its leadership priority set to something other than zero and "I am leader" bit and the Preferred peer group leader node ID set to zero.
3b.	Observe that a PTSE is sent from SUT A with its leadership priority, "I am leader" bit and the Preferred peer group leader node ID set to zero.
4a.	Observe that a PTSE is sent from SUT A with its leadership priority, "I am leader" bit set to zero and the Preferred peer group leader node ID set to that of SUT B.
4b.	Observe that a PTSE is sent from SUT B with its leadership priority set to something other than zero, the same as observed in step 3a, "I am leader" bit set to zero and the Preferred peer group leader node ID set to that of SUT B, itself.

Verdict Criteria:
Observe that a PTSE is sent from SUT B with its updated leadership priority increased by GroupLeaderIncrement, "I am leader" bit set to one, and preferred peer group leader node ID set to that of SUT B.

Consequence of Failure:	SUT B does not become PGL, which may lead to no hierarchy of peer groups.

5.	Test Case ID:	V4602PGL005
Test Purpose:	Verify that SUT A continues to be PGL when another system is attached that is not PGL capable or has a peer group leadership priority lower than SUT A's.
Reference:	5.10.1.1
Pre-requisite:	- Both SUTs must be in the same peer group,
- both SUTs have passed Test Case V4602PGL002, and
- SUT A is SS_P and SUT B is not SS_P.
Test Configuration:	#2

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	After the PNNI between SUT A and SUT B has reached 2-WayInside (Hello), Full (Database Synchronization), and SUT A is in state OperPGL and SUT B is in state OperNotPGL (Peer group Leader Election), then connect Tester A to SUT A with one physical link using a PNNI.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4602PGL002 occurs.
3.	Connect Tester A and SUT A with a PNNI and wait until the PNNI between Tester A and SUT A has reached 2-Way Inside (Hello) and Full (Database Synchronization).  {Tester can be advertising No PGL or a PGL with a lower leadership priority than the one advertised by SUT A}

Verdict Criteria:
Observe that a PTSE is sent from SUT A with the same value as previously advertised (i.e. leadership priority set equal to SUT A's initial peer group leadership priority + GroupLeaderIncrement, "I am leader" bit set to one, and Preferred peer group leader node ID set to that of SUT A. (Note:  This will take some time (upto refresh interval))

Consequence of Failure:	Peer group becomes unstable (i.e. PGL changes) when new systems are added.

6.	Test Case ID:	V4602PGL006
Test Purpose:	Verify that SUT A stops being Peer Group Leader when a system is attached with higher Peer Group Leadership priority.
Reference:	5.10.1.1.4 (PGLE6)
Pre-requisite:	- Both SUTs must be in the same peer group,
- both SUTs have passed Test Case V4602PGL002, and
- SUT A is SS_P and SUT B is not SS_P.
Test Configuration:	#2

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	After the PNNI between SUT A and SUT B has reached 2-WayInside (Hello), Full (Database Synchronization), and SUT A is OperPGL and SUT B is OperNotPGL (Peer group Leader Election), then connect Tester A to SUT A with one physical link using a PNNI.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4602PGL002 occurs.
3.	Connect Tester A and SUT A with a PNNI and wait until the PNNI between tester A and SUT A has reached 2-Way Inside (Hello) and Full (Database Synchronization).  {Tester A is advertising a PGL with a higher leadership priority (including GroupLeaderIncrement) than the one advertised by SUT A}

Verdict Criteria:
Observe that a new Nodal Information PTSE is sent from SUT A with the preferred Peer Group Leader ID field updated to the value advertised by Tester A, its original leadership priority, and "I am leader" bit set to zero.

Consequence of Failure:	The new PGL may not be elected or the old configuration may cause routing problems.

7.	Test Case ID:	V4602PGL007
Test Purpose:	Verify that SUT B continues to be PGL when another system is attached that is not PGL capable or has a peer group leadership priority lower than SUT B's.
Reference:	5.10.1.1
Pre-requisite:	- Both SUTs must be in the same peer group,
- both SUTs have passed Test Case V4602PGL004, and
- SUT B is SS_P and SUT A is not SS_P.
Test Configuration:	#2

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	After the PNNI between SUT A and SUT B has reached 2-WayInside (Hello), Full (Database Synchronization), and SUT B is in state OperPGL and SUT A is in state OperNotPGL (Peer group Leader Election), then connect Tester A to SUT A with one physical link using a PNNI.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4602PGL004 occurs.
3.	Connect Tester A and SUT A with a PNNI and wait until the PNNI between Tester A and SUT A has reached 2-Way Inside (Hello) and Full (Database Synchronization).  {Tester can be advertising No PGL or a PGL with a lower leadership priority than the one advertised by SUT B}

Verdict Criteria:
Observe that no PTSE is sent from SUT B before the PTSE Remaining Lifetime is expired or refreshed at which time the PTSE will have the same value as previously advertised (i.e. leadership priority set equal to SUT B's initial peer group leadership priority +  GroupLeaderIncrement, "I am leader" bit set to one, and Preferred peer group leader node ID set to that of SUT B.

Consequence of Failure:	Peer group becomes unstable (i.e. PGL changes) when new systems are added.

8.	Test Case ID:	V4602PGL008 
Test Purpose:	Verify that SUT B stops being Peer Group Leader when a system is attached with higher Peer Group Leadership priority.
Reference:	5.10.1.1.4 (PGLE6)
Pre-requisite:	- Both SUTs must be in the same peer group,
- both SUTs have passed Test Case V4602PGL004, and
- SUT B is SS_P and SUT A is not SS_P.
Test Configuration:	#2

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	After the PNNI between SUT A and SUT B has reached 2-WayInside (Hello), Full (Database Synchronization), and SUT B is in state OperPGL and SUT A is in state OperNotPGL (Peer group Leader Election), then connect Tester A to SUT A with one physical link using a PNNI.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4602PGL004 occurs.
3.	Connect Tester A and SUT A with a PNNI and wait until the PNNI between tester A and SUT A has reached 2-Way Inside (Hello) and Full (Database Synchronization).  {Tester A is advertising a PGL with a higher leadership priority (including GroupLeaderIncrement) than the one advertised by SUT B}

Verdict Criteria:
Observe that a new Nodal Information PTSE is sent from SUT B with the preferred Peer Group Leader ID field updated to the value advertised by Tester A, its original leadership priority, and "I am leader" bit set to zero.

Consequence of Failure:	The new PGL may not be elected or the old configuration may cause routing problems.

9.	Test Case ID:	V4602PGL009
Test Purpose:	Verify that SUT B elects new Peer Group Leader when a system is attached with Higher Peer Group Leadership priority than SUT's current PGL (i.e. SUT A).
Reference:	5.10.1.1.4 (PGLE4 & PGLE7)
Pre-requisite:	- Both SUTs must be in the same peer group,
- both SUTs have passed Test Case V4602PGL002, and
- SUT A is SS_P and SUT B is not SS_P.
Test Configuration:	#2

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	After the PNNI between SUT A and SUT B has reached 2-WayInside (Hello), Full (Database Synchronization), and SUT A is OperPGL and SUT B is OperNotPGL (Peer group Leader Election), then connect Tester A to SUT A with one physical link using a PNNI.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4602PGL002 occurs.
3.	Connect Tester A and SUT A with a PNNI and wait until the PNNI between tester A and SUT A has reached 2-Way Inside (Hello) and Full (Database Synchronization).  {Tester A is advertising a PGL with a higher leadership priority (including GroupLeaderIncrement) than the one advertised by SUT A}

Verdict Criteria:
Observe that a new Nodal Information PTSE is sent from SUT B with the preferred Peer Group Leader ID field updated to the value advertised by Tester A, its original leadership priority, and "I am leader" bit set to zero.

Consequence of Failure:	The new PGL may not be elected or the old configuration may cause routing problems.

10.	Test Case ID:	V4602PGL010
Test Purpose:	Verify that SUT A elects new Peer Group Leader when a system is attached with Higher Peer Group Leadership priority than SUT's current PGL (i.e. SUT B).
Reference:	5.10.1.1.4 (PGLE4 & PGLE7)
Pre-requisite:	- Both SUTs must be in the same peer group,
- both SUTs have passed Test Case V4602PGL004, and
- SUT B is SS_P and SUT A is not SS_P.
Test Configuration:	#2

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	After the PNNI between SUT A and SUT B has reached 2-WayInside (Hello), Full (Database Synchronization), and SUT B is in state OperPGL and SUT A is in state OperNotPGL (Peer group Leader Election), then connect Tester A to SUT A with one physical link using a PNNI.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4602PGL004 occurs.
3.	Connect Tester A and SUT A with a PNNI and wait until the PNNI between tester A and SUT A has reached 2-Way Inside (Hello) and Full (Database Synchronization).  {Tester A is advertising a PGL with a higher leadership priority (including GroupLeaderIncrement) than the one advertised by SUT B}

Verdict Criteria:
Observe that a new Nodal Information PTSE is sent from SUT A with the preferred Peer Group Leader ID field updated to the value advertised by Tester A, its original leadership priority, and "I am leader" bit set to zero.

4.6.3	Consequence of Failure:	The new PGL may not be elected or the old configuration may cause routing problems.
4.6.3	For the Peer Group Leader Election (Both SUTs are PGL capable)

All tests in this section require both SUTs to be SS_P capable.

All tests in this section require both SUTs to be in the same peer group.

All tests in this section use Test Configuration #1. 

Tests in this section should only be run, if the SUTs passed
Test Case V4401DBS004.
---------------------------------
1.	Test Case ID:	V4603PGL001
Test Purpose:	Verify that SUT A becomes Peer Group Leader based on leadership priority.
Reference:	5.10.1.1, PGLE8
Pre-requisite:	- Both SUTs must be in the same peer group,
- both SUTs have passed Test Case V4401DBS004, 
- both SUTs are SS_P, and
- the peer group leadership priority of SUT A is greater than SUT B's.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4401DBS004 occurs.
3.	Observe that Test Case V4603PGL004 ocurrs.

Verdict Criteria:
Observe that a PTSE is sent from SUT A with its updated leadership priority increased by GroupLeaderIncrement, "I am leader" bit set to one, and Preferred peer group leader node ID set to that of SUT A.

Consequence of Failure:	Leadership within the peer group is unstable.

2.	Test Case ID:	V4603PGL002
Test Purpose:	Verify that SUT A becomes Peer Group Leader  based on Node ID.
Reference:	5.10.1.1, PGLE8
Pre-requisite:	- Both SUTs must be in the same peer group, 
- both SUTs have passed Test Case V4401DBS004,
- both SUTs are SS_P, and
- both SUTs have the same peer group leadership priority, but the Node ID of SUT A is greater than the Node ID of SUT B.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4401DBS004 occurs.
3.	Observe that Test Case V4603PGL004 occurs.

Verdict Criteria:
Observe that a PTSE is sent from SUT A with its updated leadership priority increased by GroupLeaderIncrement, "I am leader" bit set to one, and Preferred peer group leader node ID set to that of SUT A.

Consequence of Failure:	The leadership of the peer group is unstable.

3.	Test Case ID:	V4603PGL003
Test Purpose:	Verify that SUT B elects SUT A as Peer Group Leader based on leadership priority.
Reference:	5.10.1.1, PGLE7
Pre-requisite:	- Both SUTs must be in the same peer group,
- both SUTs have passed Test Case V4401DBS004,
- both SUTs are SS_P, and
- the peer group leadership priority of SUT A is greater than SUT B's.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4401DBS004 occurs.
3a.	Observe that a PTSE is sent from SUT A with its leadership priority set to something other than zero and "I am leader" bit and the Preferred peer group leader node ID set to zero.
3b.	Observe that a PTSE is sent from SUT B with its leadership priority set to something other than zero and "I am leader" bit and the Preferred peer group leader node ID set to zero.

Verdict Criteria:
Observe that a PTSE is sent from SUT B with its leadership priority, "I am leader" bit set to zero and the Preferred peer group leader node ID set to that of SUT A.

Consequence of Failure:	The leadership of the peer group is unstable and may cause routing problems later.

4.	Test Case ID:	V4603PGL004
Test Purpose:	Verify that SUT B elects SUT A as Peer Group Leader based on Node ID.
Reference:	5.10.1.1, PGLE7
Pre-requisite:	- Both SUTs must be in the same peer group,
- both SUTs have passed Test Case V4401DBS004,
- both SUTs are SS_P, and
- both SUTs have the same peer group leadership priority, but the Node ID of SUT A is greater than the Node ID of SUT B.
Test Configuration:	#1

Test Set-up:
1.	Connect the two SUTs with one physical link.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4401DBS004 occurs.
3a.	Observe that a PTSE is sent from SUT A with its leadership priority set to something other than zero and "I am leader" bit and the Preferred peer group leader node ID set to zero.
3b.	Observe that a PTSE is sent from SUT B with its leadership priority set to something other than zero and "I am leader" bit and the Preferred peer group leader node ID set to zero.
4.	Observe that the two leadership priorities observed in 3a and 3b are the same.

Verdict Criteria:
Observe that a PTSE is sent from SUT B with its leadership priority, "I am leader" bit set to zero and the Preferred peer group leader node ID set to that of SUT A.

Consequence of Failure:	The leadership of the peer group is unstable and may cause routing problems later.

4.7	5 - 8	Repeat Test Cases 1 - 4 with SUT A and SUT B interchanged (i.e. SUT A and SUT B are replaced by SUT B and SUT A for all occurrences).
4.7	Border Node / PGL Interactions
4.7.1	Border Node / PGL Interactions

-----------------------------------------------
1.	Test Case ID:	V4701BPI001
Test Purpose:	Verify that two SUTs in the same peer group, one acting as PGL and the other acting as a border node, can communicate and act upon nodal hierarchy information.
Reference:	5.10.1.5
Pre-requisite:	SUT A is SS_B
SUT B is SS_P
Arrange the topology state of switches SUT A and SUT B such that:
- SUT A and SUT B belong to the same lowest level peer group, with PGL SUT B,
- Tester A is in a different peer group than SUT A, and runs a node in the parent peer group of SUT B.
Test Configuration: #2

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	Connect Tester A (PNNI) to SUT A.

Test Procedure:
1.	Monitor the PNNI RCCs (VPI/VCI=0/18) between SUT A and SUT B, and between SUT A and Tester A.
2.	Enable the link between the two SUTs.
3.	Observe that SUT B is elected peer group leader.  Store the next higher level binding information from SUT B's nodal information PTSE.  Observe that the PTSE is acknowledged by SUT A.
4.	Wait one PTSERxmtInterval.
5.	Enable the link between SUT A and Tester A.
6.	Observe that a nodal hierarchy list is included in the Hellos sent by SUT A to Tester A.  Store the nodal hierarchy list.

Verdict Criteria:
Observe that the nodal hierarchy list sent by SUT A to Tester A includes the node ID, address, and peer group ID from SUT B's next higher level binding information.

Consequence of failure:	Outside links from SUT A cannot be used and the hierarchy cannot be established.

2.	Test Case ID:	V4701BPI002
Test Purpose:	Verify that two SUTs in the same peer group, one acting as PGL and the other as a border node, can communicate and act upon uplink information.
Reference:	5.6.3.2, 5.10.3.1
Pre-requisite:	- SUT A is SS_B.
- SUT B is SS_P.
- Arrange the topology state of switches SUT A and SUT B such that:
- SUT A and SUT B belong to the same lowest level peer group, with PGL SUT B,
- Tester A is in a different peer group than SUT A, and runs a node in the parent peer group of SUT B, with a smaller node ID than the LGN of SUT B.
Test Configuration: #2

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	Connect Tester A (PNNI) to SUT A.

Test Procedure:
1.	Monitor the PNNI RCC (VPI/VCI=0/18) between SUT A and SUT B, and the PNNI signalling channel (VPI/VCI=0/5) between SUT A and SUT B.
2.	Enable the link between the two SUTs.
3.	Observe that SUT B is elected peer group leader.
4.	Enable the link between SUT A and Tester A.
5.	Observe that an uplink PTSE is advertised by SUT A to SUT B.  Store the PTSE.

Verdict Criteria:
Observe that a SETUP message is sent from SUT B to SUT A with:
 	A BLLI information element indicating that this call is a PNNI RCC [see PNNI 1.0 Section 5.5.4.1.4 for details], and
 	the Called party number the same as the “ATM End System Address of Upnode” field from the uplink PTSE advertised by SUT A to SUT B.

4.8	Consequence of Failure:	Outside links from SUT A cannot be used and the hierarchy cannot be established.
4.8	Logical Group Node
4.8.1	Logical Group Node (SVCC-Based RCC establishment)

In order for any of these test cases to be executed either
i) both SUTs must be the PGL in different peer groups and share a common higher level peer group; or
ii) one SUT must be PGL (local) and the other SUT must be in a peer group with a PGL (e.g. a Tester)(remote) and share a common higher level peer group.

The latter configuration (ii) is covered by Test Cases 1 - 3.
The former configuration (i) is covered by Test Cases 4 - 6.
------------------------------------------
1.	Test Case ID:	V4801LGN001
Test Purpose:	Verify that a PGL (i.e. SUT A) in one peer group initiates a switched virtual channel connection (SVCC) to the PGL (i.e. Tester B) in another peer group.
Reference:	5.5.6.3 (A.5), 5.5.4.1 (for SETUP parameters)
Pre-requisite:	- SUT A is SS_P and SS_B and SUT A must be elected as PGL of its peer group.
- SUT B is SS_B and not PGL of its peer group, but a PGL must be elected.
- The node ID of SUT A is greater than the node ID of the PGL (i.e. Tester B) in the other peer group.
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	Configure the Tester B's Node ID to be less than SUT A's Node ID (This is to ensure that SUT A establishes the SVCC).

Test Procedure:
1a.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
1b.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
2a.	Observe that SUT A becomes PGL of its peer group (monitor point A).
2b.	Observe that SUT B elects a PGL (i.e. Tester B) (monitor point C).
3.	Observe that an uplink is advertised from SUT B to SUT A (monitor point D).

Verdict Criteria:
Observe that SUT A sends a SETUP message on VPI/VCI=0/5 over interface D and that the destination address is that of PGL (i.e. Tester B).

Consequence of Failure:	Logical peer groups will not join and allow routing information to be passed between peer group.

2.	Test Case ID:	V4801LGN002
Test Purpose:	Verify that local PGL (i.e. SUT A) accepts (i.e. sends CALL PROCEEDING message) a switched virtual channel connection (SVCC) from remote PGL (i.e. Tester B).
Reference:	5.5.6.3 (A.3), 5.5.4.1.2, 5.5.4.1.10
Pre-requisite:	- SUT A is SS_P and SS_B and SUT A must be elected as PGL of its peer group.
- SUT B is SS_B and not PGL of its peer group, but a PGL must be elected.
- The node ID of SUT A is less than the node ID of the PGL (i.e. Tester B) in the other peer group.
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	Configure the Tester B's Node ID to be greater than SUT A's Node ID (This is to ensure that Tester B establishes the SVCC).

Test Procedure:
1a.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
1b.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
2a.	Observe that SUT A becomes PGL of its peer group (monitor point A).
2b.	Observe that SUT B elects a PGL (i.e. Tester B).
3.	Observe that an uplink is advertised from SUT B to SUT A.
4.	Remote PGL (i.e. Tester B) sends a SETUP message to SUT A through SUT B on VPI/VCI=0/5. 

Verdict Criteria:
Observe that SUT A sends a CALL PROCEEDING message on VPI/VCI=0/5 over interface D in response to the SETUP message.

Consequence of Failure:	Logical peer groups will not join and allow routing information to be passed between peer group.

3.	Test Case ID:	V4801LGN003
Test Purpose:	Verify that local PGL (i.e. SUT A) accepts (i.e. sends CONNECT message) a switched virtual channel connection (SVCC) from remote PGL (i.e. Tester B).
Reference:	5.5.6.3 (A.3), 5.5.4.2 (for CONNECT parameters)
Pre-requisite:	- SUT A is SS_P and SS_B and SUT A must be elected as PGL of its peer group.
- SUT B is SS_B and not PGL of its peer group, but a PGL must be elected.
- The node ID of SUT A is less than the node ID of the PGL (i.e. Tester B) in the other peer group.
- Must have passed Test Case V4801LGN002.
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	Configure the Tester B's Node ID to be greater than SUT A's Node ID (This is to ensure that Tester B establishes the SVCC).

Test Procedure:
1a.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
1b.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
2a.	Observe that SUT A becomes PGL of its peer group (monitor point A).
2b.	Observe that SUT B elects a PGL (i.e. Tester B).
3.	Observe that an uplink is advertised from SUT B to SUT A.
4.	Remote PGL (i.e. Tester B) sends a SETUP message to SUT A through SUT B on VPI/VCI=0/5. 
5.	Observe that SUT A sends a CALL PROCEEDING message on VPI/VCI=0/5 over interface D in response to the SETUP message.

Verdict Criteria:
Observe that SUT A sends a CONNECT message on VPI/VCI=0/5 over interface D.

Consequence of Failure:	Logical peer groups will not join and allow routing information to be passed between peer group.

4.	Test Case ID:	V4801LGN004
Test Purpose:	Verify that a PGL (i.e. SUT A) in one peer group initiates a switched virtual channel connection (SVCC) to the PGL (i.e. SUT B) in another peer group.
Reference:	5.5.6.3 (A.5), 5.5.4.1 (for SETUP parameters)
Pre-requisite:	- SUT A is SS_P and SS_B and SUT A must be elected as PGL of its peer group.
- SUT B is SS_P and SS_B and SUT B must be elected as PGL of its peer group.
- The node ID of SUT A is greater than the node ID of the PGL (i.e. SUT B) in the other peer group.
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	Configure the SUT B's Node ID to be less than SUT A's Node ID (This is to ensure that SUT A initiates the SVCC).

Test Procedure:
1a.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
1b.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
2a.	Observe that SUT A becomes PGL of its peer group (monitor point A).
2b.	Observe that SUT B becomes PGL of its peer group (monitor point C).
3.	Observe that an uplink is advertised from SUT B to SUT A (monitor point D).

Verdict Criteria:
Observe that SUT A sends a SETUP message on VPI/VCI=0/5 over interface D and that the destination address is that of PGL (i.e. SUT B).

Consequence of Failure:	Logical peer groups will not join and allow routing information to be passed between peer group.

5.	Test Case ID:	V4801LGN005
Test Purpose:	Verify that remote PGL (i.e. SUT B) accepts (i.e. sends CALL PROCEEDING message) a switched virtual channel connection (SVCC) from local PGL (i.e. SUT A).
Reference:	5.5.6.3 (A.3), 5.5.4.1.2, 5.5.4.1.10
Pre-requisite:	- SUT A is SS_P and SS_B and SUT A must be elected as PGL of its peer group.
- SUT B is SS_B and SS_B and SUT B must be elected as PGL of its peer group.
- The node ID of SUT A is greater than the node ID of the PGL (i.e. SUT B) in the other peer group.
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	Configure the SUT B's Node ID to be less than SUT A's Node ID (This is to ensure that SUT A initiates the SVCC).

Test Procedure:
1a.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
1b.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
2a.	Observe that SUT A becomes PGL of its peer group (monitor point A).
2b.	Observe that SUT B becomes PGL of its peer group (monitor point C).
3.	Observe that an uplink is advertised from SUT B to SUT A (monitor point D).
4.	Observe that SUT A sends a SETUP message on VPI/VCI=0/5 over interface D and that the destination address is that of PGL (i.e. SUT B).

Verdict Criteria:
	Observe that SUT B sends a CALL PROCEEDING message on VPI/VCI=0/5 over interface D in response to the SETUP message.

Consequence of Failure:	Logical peer groups will not join and allow routing information to be passed between peer group.

6.	Test Case ID:	V4801LGN006
Test Purpose:	Verify that remote PGL (i.e. SUT B) accepts (i.e. sends CONNECT message) a switched virtual channel connection (SVCC) from local PGL (i.e. SUT A).
Reference:	5.5.6.3 (A.3), 5.5.4.2 (for CONNECT parameters)
Pre-requisite:	- SUT A is SS_P and SS_B and SUT A must be elected as PGL of its peer group.
- SUT B is SS_P and SS_B and SUT B must be elected as PGL of its peer group.
- The node ID of SUT A is greater than the node ID of the PGL (i.e. SUT B) in the other peer group.
- Must have passed Test Case V4801LGN005.
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	Configure the SUT B's Node ID to be less than SUT A's Node ID (This is to ensure that SUT A initiates the SVCC).

Test Procedure:
1a.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
1b.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
2a.	Observe that SUT A becomes PGL of its peer group (monitor point A).
2b.	Observe that SUT B becomes PGL of its peer group (monitor point C).
3.	Observe that an uplink is advertised from SUT B to SUT A (monitor point D).
4.	Observe that SUT A sends a SETUP message on VPI/VCI=0/5 over interface D and that the destination address is that of PGL (i.e. SUT B).
5.	Observe that SUT B sends a CALL PROCEEDING message on VPI/VCI=0/5 over interface D in response to the SETUP message.

Verdict Criteria:
	Observe that SUT B sends a CONNECT message on VPI/VCI=0/5 over interface D.

Consequence of Failure:	Logical peer groups will not join and allow routing information to be passed between peer group.

7.	Test Case ID:	V4801LGN007
Test Purpose:	Verify that when a new Peer Group Leader (e.g. Tester B emulating a new node) is elected in the same peer group as SUT B, the old Peer Group Leader (i.e. SUT B) releases the RCC to the Peer Group Leader (i.e. SUT A) of another peer group with cause value=53.
Reference:	5.5.4.3, 5.5.6.3 (C.2)
Pre-requisite:	- SUT A is SS_P and SS_B and SUT A must be elected as PGL of its peer group. 
- SUT B is SS_P and SS_B and SUT B must be elected as PGL of its peer group.
- Must have passed Test Case V4801LGN006.
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	Configure the SUT B's Node ID to be less than SUT A's Node ID (This is to ensure that SUT A initiates the SVCC).

Test Procedure:
1a.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
1b.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
2a.	Observe that SUT A becomes PGL of its peer group (monitor point A).
2b.	Observe that SUT B becomes PGL of its peer group (monitor point C).
3.	Observe that an uplink is advertised from SUT B to SUT A (monitor point D).
4.	Observe that SUT A sends a SETUP message on VPI/VCI=0/5 over interface D and that the destination address is that of PGL (i.e. SUT B).
5.	Observe that SUT B sends a CALL PROCEEDING message on VPI/VCI=0/5 over interface D in response to the SETUP message.
6.	Observe that SUT B sends a CONNECT message on VPI/VCI=0/5 over interface D.
7.	Add another node to Tester B (or have Tester B emulate the addition of another node) which has a peer group leadership priority greater than the initial SUT B's leadership priority + GroupLeaderIncrement.
8.	Observe flooding of PTSE with new node's PGLship priority greater than (initial SUT B's + increment) from Tester B to SUT B (monitor point C).
9.	Observe that SUT B elects the new node (monitor point C).

Verdict Criteria:
Observe that SUT B sends a RELEASE message with cause value = 53, on VPI/VCI=0/5 over interface D and that the destination address is that of PGL (i.e. SUT A).

Consequence of Failure:	One peer group will be represented by two different Logical Group Nodes.

8.	Test Case ID:	E4801LGN008
Test Purpose:	Verify that after a physical link failure, when corrected, that a PGL (i.e. SUT A) in one peer group initiates a switched virtual channel connection (SVCC) to the PGL (i.e. Tester B) in another peer group.
Reference:	5.5.6.3 (D.2), 5.5.4.1 (for SETUP parameters)
Pre-requisite:	- SUT A is SS_P and SS_B and SUT A must be elected as PGL of its peer group.
- SUT B is SS_B and not PGL of its peer group, but a PGL must be elected.
- The node ID of SUT A is greater than the node ID of the PGL (i.e. Tester B) in the other peer group.
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	Configure the Tester B's Node ID to be less than SUT A's Node ID (This is to ensure that SUT A initiates the SVCC).

Test Procedure:
1a.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
1b.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
2a.	Observe that SUT A becomes PGL of its peer group (monitor point A).
2b.	Observe that SUT B elects a PGL (i.e. Tester B)(monitor point C).
3.	Observe that an uplink is advertised from SUT B to SUT A (monitor point D).
4.	Observe that SUT A sends a SETUP message on VPI/VCI=0/5 over interface D and that the destination address is that of PGL (i.e. Tester B).
5.	Observe that SUT B sends a CALL PROCEEDING message on VPI/VCI=0/5 over interface D in response to the SETUP message.
6.	Observe that SUT B sends a CONNECT message on VPI/VCI=0/5 over interface D.
7.	Disconnect/remove the physical link between the two SUTs.
8.	Reconnect the physical link between the two SUTs using the same ports.
Note: Provided that enough time has elasped to declare the link down by all protocols involved and enough time to redeclare the link is up by all protocols, once the link is reestablished.

Verdict Criteria:
Observe that SUT A sends a SETUP message on VPI/VCI=0/5 over interface D and that the destination address is that of PGL (i.e. Tester B)

Consequence of Failure:	The old information was retained causing the protocol not to operate

9.	Test Case ID:	E4801LGN009
Test Purpose:	Verify that after a physical link failure, when corrected, that a PGL (i.e. SUT A) in one peer group initiates a switched virtual channel connection (SVCC) to the PGL (i.e. SUT B) in another peer group.
Reference:	5.5.6.3 (D.2), 5.5.4.1 (for SETUP parameters)
Pre-requisite:	- SUT A is SS_P and SS_B and SUT A must be elected as PGL of its peer group.
- SUT B is SS_P and SS_B and SUT B must be elected as PGL of its peer group.
- The node ID of SUT A is greater than the node ID of the PGL (i.e. SUT B) in the other peer group.
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	Configure the SUT B's Node ID to be less than SUT A's Node ID (This is to ensure that SUT A initiates the SVCC).

Test Procedure:
1a.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
1b.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
2a.	Observe that SUT A becomes PGL of its peer group (monitor point A).
2b.	Observe that SUT B becomes PGL of its peer group (monitor point C).
3.	Observe that an uplink is advertised from SUT B to SUT A (monitor point D).
4.	Observe that SUT A sends a SETUP message on VPI/VCI=0/5 over interface D and that the destination address is that of PGL (i.e. SUT B).
5.	Observe that SUT B sends a CALL PROCEEDING message on VPI/VCI=0/5 over interface D in response to the SETUP message.
6.	Observe that SUT B sends a CONNECT message on VPI/VCI=0/5 over interface D.
7.	Disconnect/remove the physical link between the two SUTs.
8.	Reconnect the physical link between the two SUTs using the same ports.
Note: Provided that enough time has elasped to declare the link down by all protocols involved and enough time to redeclare the link is up by all protocols, once the link is reestablished.

Verdict Criteria:
Observe that SUT A sends a SETUP message on VPI/VCI=0/5 over interface D and that the destination address is that of PGL (i.e. SUT B)

Consequence of Failure:	The old information was retained causing the protocol not to operate
4.8.2	
4.8.2	Logical Group Node (Hello Protocol)

These tests should only be run after running the appropriate tests in section 4.8.1 on Logical Group Node (SVCC-Based RCC establishment).  The test written in this section are generic, so that either of the two configuration in section 4.8.1 can be used.  One LGN is assumed to be SUT A and the other (remote) LGN is either SUT B or Tester B depending upon which is PGL. 
--------------------------------------
1.	Test Case ID:	V4802LGN001
Test Purpose:	Verify that the Hello protocol is running over the SVCC-Based RCC.
Reference:	5.6.3.1
Pre-requisite:	SVCC-Based RCC is established (see Test Cases in section 4.8.1)
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	SVCC-Based RCC is established.

Test Procedure:
1a.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
1b.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
2.	Store the VPI/VCI in the SETUP message sent to establish the SVCC-Based RCC.
3.	Monitor the PNNI (VPI/VCI of the SVCC-Based RCC) between SUT A and SUT B.

Verdict Criteria:
Observe that a Hello packet is sent from LGN to LGN with the Port ID field value set to 0xFFFFFFFF, Hello Interval field value set to non-zero, Node ID equal to that of LGN and Remote Node ID and Remote Port ID set to zero (i.e. 1-WayInside).

Consequence of Failure:	If Hello is not observed, then the logical peer groups share routing information between these peer groups.  If the Hello has non-zero values for Remote Node ID and Remote Port ID, then old information was used, which could cause routing problems later on.

2.	Test Case ID:	V4802LGN002
Test Purpose:	Verify that the Hello protocol is running over the SVCC-Based RCC and that the LGN learns about the other (remote) LGN.
Reference:	5.6.3.1
Pre-requisite:	SVCC-Based RCC is established (see Test Cases in section 4.8.1)
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	SVCC-Based RCC is established.

Test Procedure:
1a.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
1b.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
2.	Store the VPI/VCI in the SETUP message sent to establish the SVCC-Based RCC.
3.	Monitor the PNNI (VPI/VCI of the SVCC-Based RCC) between SUT A and SUT B.
4.	Observe that a Hello packet is sent from LGN to LGN with the Port ID field value set to 0xFFFFFFFF, Node ID equal to that of LGN and Remote Node ID and Remote Port ID set to zero (i.e. 1-WayInside).

Verdict Criteria:
Observe that a Hello packet is sent from LGN to LGN with the Port ID field value set to 0xFFFFFFFF, Node ID equal to that of LGN and Remote Node ID set to Node ID of the other (remote LGN) and Remote Port ID set to 0xFFFFFFFF (i.e. 2-WayInside).

Consequence of Failure:	If the Hello does not have the correct values for Remote Node ID and Remote Port ID, then the Hello protocol will hang.

3.	Test Case ID:	E4802LGN003
Test Purpose:	Verify that after a physical link failure, when corrected, that the Hello Protocol is running over the SVCC-Based RCC (2-WayInside).
Reference:	5.5.6.3 (D.2), 5.6.3.1 (6)
Pre-requisite:	SVCC-Based RCC is established (see Test Cases in section 4.8.1)
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	SVCC-Based RCC is established.

Test Procedure:
1a.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
1b.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
2.	Store the VPI/VCI in the SETUP message sent to establish the SVCC-Based RCC.
3.	Monitor the PNNI (VPI/VCI of the SVCC-Based RCC) between SUT A and SUT B.
4.	Observe that SVCC-Based RCC is established.
5.	Observe that one Hello (2-WayInsideReceived) sent from each SUT.
6.	Disconnect/remove the physical link between the two SUTs.
7.	Reconnect the physical link between the two SUTs using the same ports.
Note: Provided that enough time has elasped to declare the link down by all protocols involved and enough time to redeclare the link is up by all protocols, once the link is reestablished.

Verdict Criteria:
Observe that an SVCC-Based RCC is established, and that a Hello packet is sent from LGN to LGN with the Port ID field value set to 0xFFFFFFFF, Hello Interval field value set to non-zero, Node ID equal to that of LGN and Remote Node ID and Remote Port ID set to zero (i.e. 1-WayInside).

Consequence of Failure:	The old PNNI information was retained causing the protocol not to operate.
4.8.3	
4.8.3	Logical Group Node (Feeding Information Down the Hierarchy)

-------------------------------------
1.	Test Case ID:	V4803LGN001
Test Purpose:	Verify that information is fed down the Hierarchy.
Reference:	5.10.4
Pre-requisite:	- SUT A is SS_P and SS_B.
- SUT A and SUT B are in the same peer group.
- Tester A is in a different peer group and PGL.
Test Configuration:	#2

Test Set-up:
1.	Connect the two SUTs with one physical link.
2.	Connect Tester A (PGL) to SUT A (PGL).
3.	SVCC-Based RCC is established.

Test Procedure:
1.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and SUT B.
2.	Observe that Test Case V4602PGL002 occurs.
3.	Connect Tester A to SUT A.
4.	Monitor the PNNI (VPI/VCI=0/18) between SUT A and Tester A.
5.	Observe that an exchange of information similar to the Border node test cases in section 4.3.2 occur at monitor point A.
6.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and Tester A.
7.	Store the VPI/VCI in the SETUP message sent to establish the SVCC-Based RCC.
8.	Monitor the PNNI (VPI/VCI of the SVCC-Based RCC) between SUT A and Tester A.
9.	Store PTSE sent from Tester A (LGN) to SUT A (LGN) during Database Synchronization. 

Verdict Criteria:
Observe that a PTSE (i.e. the PTSE information exchanged during the Database Synchronization between LGNs is flooded inside the peer group) from SUT A is sent to a SUT B.

Consequence of Failure:	Outside information is not fed down, which can causes routing problems due to lack of information.
5	
5	Interoperability Interface Tests (Signalling)

This section covers the PNNI signalling procedures, both point-to-point and point-to-multipoint.

The point-to-point signalling procedures are covered by multiple sections: Establishment procedures, Release procedures, DTL processing, Crankback procedures, and Restart procedures.
Within each of these sections are four sub-sections.  The first covers general test cases.  The next three sub-sections cover test cases in more detail (e.g. call states and information elements) based on the Test Configuration used.

In the more detailed sections, the following additional information is necessary.

The Test Case ID has an additional suffix.
CNI - Connection Identifier information element.
CON - Connection message.
ALR - Alerting message.
ACN - Connect message after an Alerting message.
TRA - Traffic parameter.
QoS - Quality of Service.
BFR - Before call establishment.
USR - User initiated call clearing. 

The Test Procedure requires the following additional information.  The first Step includes an initial state notation and the last Step includes a final state notation.  This state information is related to the Call States per call on the PNNI or UNI interfaces.  This state notation is described below.

#3a : ((s1,s2),(s3,s4)), where s1 and s2 represent call states of the succeeding side and the preceding side of the SUT A, respectively, and s3 and s4 represent call states of the succeeding side and the preceding side of the SUT B, respectively.
#3b : (s1,(s2,s3)), where s1 represents call state of the preceding side of the SUT A, and s2 and s3 represent call states of the succeeding side and the preceding side of the SUT B, respectively. 
#3c : (s1,s2), where s1 represents call state of the preceding side of the SUT A, and s2 represents call state of the succeeding side of the SUT B.

For example:
The states ((0,0),(0,0)), (0,(0,0)), and (0,0) represent the null state where no call exists for Test Configuration #3a, 3b, and 3c respectively.

The state ((3,9),(3,6)) can be reached by running Test Case V5202EST014_QOS, unless otherwise specified.

The state ((3,9),(3,9)) can be reached by running Test Case V5202EST001_CNI, unless otherwise specified.

The state ((4,7),(4,7)) can be reached by running Test Case V5202EST006_ALR, unless otherwise specified.

The state ((10,10),(10,10)) can be reached by running Test Case V5202EST005_CON, unless otherwise specified.

#4a and #4b do not use the state notation, since these test configurations have multiple interfaces between SUT B and Tester B; and the path of the call is non-deterministic.

The point-to-multipoint signalling procedures are covered by multiple sections: Initial party establishment, Additional party, and Drop party. 

5.1	Test Case Index

Test Case ID	Test Purpose	
V5201EST001	Verify that SUT A routes a call request through SUT B.	
V5201EST002	Verify that SUT B accepts a call request from SUT A.	
V5201EST003	Verify that SUT B continues to progress (ALERTING message) a call request from SUT A.	
V5201EST004	Verify that SUT B continues to progress (CONNECT message) a call request from SUT A.	
V5201EST005	Verify that an SVC is established end-to-end.	
V5202EST001_CNI	To verify that normal call setup can be supported between two switches. (connection identifier I.E. - associated signalling 1)	
V5202EST002_CNI	To verify that normal call setup can be supported between two switches. (connection identifier I.E. - associated signalling 2)	
V5202EST003_CNI	To verify that normal call setup can be supported between two switches. (connection identifier I.E. –         non-associated signalling 1)	
V5202EST004_CNI	To verify that normal call setup can be supported between two switches. (connection identifier I.E. –         non-associated signalling 2)	
V5202EST005_CON	To verify that normal call setup can be supported between two switches. (Reception of CONNECT after sending SETUP)	
V5202EST006_ALR	To verify that normal call setup can be supported between two switches. (Reception of ALERT after sending SETUP)	
V5202EST007_ACN	To verify that normal call setup can be supported between two switches.(Reception of CONNECT after receiving ALERT)	
V5202EST008_TRA	To verify two switches, during call/connection establishment, handle tagging parameters correctly when SUT A performs tagging for forward traffic.	
V5202EST009_TRA	To verify two switches, during call/connection establishment, handle tagging parameters correctly when SUT B performs tagging for forward traffic.	
V5202EST010_TRA	To verify two switches, during call/connection establishment, handle tagging parameters correctly when they receive Tf field coded as Tagging not allowed.	
V5202EST011_TRA	To verify two switches, during call/connection acceptance, handle tagging parameters correctly when SUT A performs tagging for forward traffic.	
V5202EST012_TRA	To verify two switches, during call/connection acceptance, handle tagging parameters correctly when they had received Tf field coded as Tagging not allowed.	
V5202EST013_TRA	To verify two switches, during call/connection establishment, handle backward tagging parameters correctly when none of two switches performs tagging for backward traffic.	
V5202EST014_QOS	To verify that both SUTs transfer QoS I.E. if it is included in the received SETUP message.	
V5202EST015_QOS	To verify that both SUTs increment values of the QoS parameters during call/connection establishment.	
V5221EST001_TRA	To check that the call can be progressed when two switches are able to provide the traffic parameter values specified in the ATD I.E. and Minimum acceptable ATD I.E.	
V5221EST002_TRA	To check that the call can be progressed when the second switch is able to provide the traffic parameter values specified in the Minimum acceptable ATD I.E. but cannot support those in the ATD       I.E. - Minimum acceptable ATD I.E. remains after negotiation.	
V5221EST003_TRA	To check that the call can be progressed when the second switch is able to provide the traffic parameter values specified in the Minimum acceptable ATD I.E. but cannot support those in the ATD I.E. - Minimum acceptable ATD I.E. removes after negotiation.	
V5221EST004_TRA	To check that the call can be progressed when the SUT A (first switch) is able to provide the traffic parameter values specified in the Minimum acceptable ATD I.E. but cannot support those in the ATD I.E.	
V5221EST005_TRA	To check that the call can be progressed when both SUTs are able to provide the traffic parameter values specified in the ATD I.E. and Alternative ATD I.E.	
V5221EST006_TRA	To check that the call can be progressed when SUT B (second switch) is able to provide the traffic parameter values specified in the ATD I.E. but cannot support those in the Alternative ATD I.E.	
V5221EST007_TRA	To check that the call can be progressed when SUT B (second switch) is able to provide the traffic parameter values specified in the Alternative ATD I.E. but cannot support those in the ATD I.E.	
V5221EST008_TRA	To check that both SUTs progress the CONNECT message with the same ATD I.E. if it is contained in the received CONNECT message.	
V5221EST009_TRA	To check that both SUTs progress the CONNECT message with the ATD I.E. of which parameters has been negotiated during call setup. ‑ SUT B (second switch) adds ATD I.E. on the CONNECT message.	
V5221EST010_TRA	To check that both SUTs progress the CONNECT message with the ATD I.E. of which parameters has been negotiated during call setup. ‑ SUT A (first switch) adds ATD I.E. on the CONNECT message.	
V5221EST011_TRA	To check that, after alerting, two switches progress the CONNECT message with the same ATD I.E. if it is contained in the received CONNECT message.	
V5221EST012_TRA	To check that, after alerting, two switches progress the CONNECT message with the ATD I.E. of which parameters has been negotiated during call setup. - SUT B (second switch) adds ATD I.E. on the CONNECT message.	
V5221EST013_TRA	To check that, after alerting, two switches progress the CONNECT message with the ATD I.E. of which parameters has been negotiated during call setup. - SUT A (first switch) adds ATD I.E. on the CONNECT message.	
V5203EST001_CNI	To verify that normal call setup can be supported between two switches. (connection identifier I.E. - associated signalling 1)	
V5203EST002_CNI	To verify that normal call setup can be supported between two switches. (connection identifier I.E. - associated signalling 2)	
V5203EST003_CNI	To verify that normal call setup can be supported between two switches. (connection identifier I.E. –         non-associated signalling 1)	
V5203EST004_CNI	To verify that normal call setup can be supported between two switches. (connection identifier I.E. -         non-associated signalling 2)	
V5203EST005_CON	To verify that normal call setup can be supported between two switches. (Reception of CONNECT after sending SETUP)	
V5203EST006_ALR	To verify that normal call setup can be supported between two switches. (Reception of ALERT after sending SETUP)	
V5203EST007_ACN	To verify that normal call setup can be supported between two switches.(Reception of CONNECT after receiving ALERT)	
V5203EST008_QOS	To verify that both SUTs transfer QoS I.E. if it is included in the received SETUP message.	
V5203EST009_QOS	To verify that the first switch sends SETUP including Extended QoS I.E. when the setup indication includes neither Extended QoS I.E. nor End-to-end transit delay I.E. and ATM service category of the call is CBR, real-time VBR, or    non-real-time VBR, and the second switch increments values of the QoS parameters during call/connection establishment.	
V5203EST010_CNI	To verify that normal call setup can be supported between two switches. (connection identifier I.E. - associated signalling 1)	
V5203EST011_CNI	To verify that normal call setup can be supported between two switches. (connection identifier I.E. - associated signalling 2)	
V5203EST012_CNI	To verify that normal call setup can be supported between two switches. (connection identifier I.E. -         non-associated signalling 1)	
V5203EST013_CNI	To verify that normal call setup can be supported between two switches. (connection identifier I.E. –         non-associated signalling 2)	
V5203EST014_CON	To verify that normal call setup can be supported between two switches. (Reception of CONNECT after sending SETUP)	
V5203EST015_ALR	To verify that normal call setup can be supported between two switches. (Reception of ALERT after sending SETUP)	
V5203EST016_ACN	To verify that normal call setup can be supported between two switches.(Reception of CONNECT after receiving ALERT)	
V5203EST017_QOS	To verify that the first switch transfers QoS I.E. if it is included in the received SETUP message.	
V5203EST018_QOS	To verify that the first switch increments values of the QoS parameters during call/connection establishment.	
V5231EST001_TRA	To check that SUT B (second switch) progresses the CONNECT message with the same ATD I.E. if it is contained in the received CONNECT message.	

V5231EST002_TRA	To check that, after alerting, second switch progresses the CONNECT message with the same ATD I.E. if it is contained in the received CONNECT message.	
V5231EST003_TRA	To check that the call can be progressed when two switches are able to provide the traffic parameter values specified in the ATD I.E. and Minimum acceptable ATD I.E.	
V5231EST004_TRA	To check that the call can be progressed when the second switch is able to provide the traffic parameter values specified in the Minimum acceptable ATD I.E. but cannot support those in the ATD      I.E.- Minimum acceptable ATD I.E. remains after negotiation.	
V5231EST005_TRA	To check that the call can be progressed when the second switch is able to provide the traffic parameter values specified in the Minimum acceptable ATD I.E. but cannot support those in the ATD I.E. - Minimum acceptable ATD I.E. removes after negotiation.	
V5231EST006_TRA	To check that the call can be progressed when the SUT A (first switch) is able to provide the traffic parameter values specified in the Minimum acceptable ATD I.E. but cannot support those in the ATD I.E.	
V5231EST007_TRA	To check that the call can be progressed when both SUTs are able to provide the traffic parameter values specified in the ATD I.E. and Alternative ATD I.E.	
V5231EST008_TRA	To check that the call can be progressed when SUT B (second switch) is able to provide the traffic parameter values specified in the ATD I.E. but cannot support those in the Alternative ATD I.E.	
V5231EST009_TRA	To check that the call can be progressed when SUT B (second switch) is able to provide the traffic parameter values specified in the Alternative ATD I.E. but cannot support those in the ATD I.E.	
V5204EST001_CNI	To verify that normal call setup can be supported between two switches. (connection identifier I.E. - associated signalling 1)	

V5204EST002_CNI	To verify that normal call setup can be supported between two switches. (connection identifier I.E. - associated signalling 2)	
V5204EST003_CNI	To verify that normal call setup can be supported between two switches. (connection identifier I.E. –         non-associated signalling 1)	
V5204EST004_CNI	To verify that normal call setup can be supported between two switches. (connection identifier I.E. -         non-associated signalling 2)	
V5204EST005_CON	To verify that normal call setup can be supported between two switches. (Reception of CONNECT after sending SETUP)	
V5204EST006_ALR	To verify that normal call setup can be supported between two switches. (Reception of ALERT after sending SETUP)	
V5204EST007_ACN	To verify that normal call setup can be supported between two switches.(Reception of CONNECT after receiving ALERT)	
V5204EST008_QOS	To verify that the preceding side includes QoS I.E. in the corresponding SETUP message, when the preceding side receives a setup indication that includes a QoS parameter I.E.	
V5204EST009_QOS	To verify that the first switch sends SETUP including Extended QoS I.E. when the setup indication includes neither Extended QoS I.E. nor End-to-end transit delay I.E. and ATM service category of the call is CBR, real-time VBR, or    non-real-time VBR.	
Release		
V5301REL001	Verify that SUT A releases a call request through SUT B.	
V5301REL002	Verify that SUT B acknowledges the release call request.	
V5301REL003	Verify that the SVC is released.	
V5302REL001_BFR	To verify that a call/connection can be released by originating user side before connection is established.	

V5302REL002_BFR	To verify that a call/connection can be released by destination user side before connection is established.	
V5302REL003_CNI	To verify that a call/connection can be released by a failure of connection identifier assignment.	
V5302REL004_DTL	To verify that the release of a call/connection can be relayed when call clearing occurs due to DTL processing failure.	
V5302REL005_USR	To verify that a call/connection can be released by originating user side after call/connection completion.	
V5302REL006_USR	To verify that a call/connection can be released by destination user side after call/connection completion.	
V5303REL001_BFR	To verify that a call/connection can be released by originating user side before connection is established.	
V5303REL002_BFR	To verify that a call/connection can be released by destination user side before connection is established.	
V5303REL003_CNI	To verify that a call/connection can be released by a failure of connection identifier assignment.	
V5303REL004_DTL	To verify that the release of a call/connection can be relayed when call clearing occurs due to DTL processing failure.	
V5303REL005_USR	To verify that a call/connection can be released by originating user side after call/connection completion.	
V5303REL006_USR	To verify that a call/connection can be released by destination user side after call/connection completion.	
V5303REL007_BFR	To verify that a call/connection can be released by originating user side before connection is established.	
V5303REL008_BFR	To verify that a call/connection can be released by destination user side before connection is established.	
V5303REL009_USR	To verify that a call/connection can be released by originating user side after call/connection completion.	

V5303REL010_USR	To verify that a call/connection can be released by destination user side after call/connection completion.	
V5304REL001_BFR	To verify that a call/connection can be released by originating user side before connection is established.	
V5304REL002_BFR	To verify that a call/connection can be released by destination user side before connection is established.	
V5304REL003_USR	To verify that a call/connection can be released by originating user side after call/connection completion.	
V5304REL004_USR	To verify that a call/connection can be released by destination user side after call/connection completion.	
DTL		
V5401DTL001	To verify that two switches process DTLs correctly during call/connection setup when SUTs are in the same lowest level peer group.	
V5401DTL002	To verify that two switches process DTLs correctly during call/connection setup when SUTs are in two different lowest level peer groups.	
V5402DTL001	To verify that two switches process DTLs correctly during call/connection setup as an entry border node and as an exit border node of the same peer group.	
V5402DTL002	To verify that two switches process DTLs correctly during call/connection setup as an entry border node and as an intermediate node.	
V5402DTL003	To verify that two switches process DTLs correctly during call/connection setup as an intermediate node and as an exit border node.	
V5402DTL004	To verify that two switches process DTLs correctly during call/connection setup as intermediate nodes.	
V5402DTL005	To verify that two switches process DTLs correctly during call/connection setup as an exit border node and as an entry border node of different peer groups.	

V5402DTL006	To verify that two switches process DTLs correctly as an intermediate node followed by an entry border node.	
V5402DTL007	To verify that two switches process DTLs correctly as an exit border node followed by an intermediate node.	
V5403DTL001	To verify that two switches process DTLs correctly during call/connection setup as a DTL originator and as an entry border node of two different lowest level peer groups.	
V5403DTL002	To verify that two switches process DTLs correctly during call/connection setup as a DTL originator and as an exit border node of a same lowest level peer group.	
V5403DTL003	To verify that two switches process DTLs correctly during call/connection setup as a DTL originator and as an intermediate node of the same lowest level peer group.	
V5403DTL004	To verify that two switches process DTLs correctly during call/connection setup as an exit border node and as a DTL terminator of two different lowest level peer groups.	
V5403DTL005	To verify that two switches process DTLs correctly during call/connection setup as an entry border node and as a DTL terminator of a same lowest level peer group.	
V5403DTL006	To verify that two switches process DTLs correctly during call/connection setup as an intermediate node and as a DTL terminator of a same lowest level peer group.	
V5403DTL007	To verify that two switches process DTLs correctly as an originating node that is not an exit border node followed by an entry border node.	
V5404DTL001	To verify that two switches process DTLs correctly during call/connection setup as a DTL originator and as a DTL terminator of two different lowest level peer groups.	
V5404DTL002	To verify that two switches process DTLs correctly during call/connection setup as a DTL originator and as a DTL terminator of a same lowest level peer group.	

Crankback		
V5501CRK001(Failure of V5201EST001)	Verify that SUT B includes a Crankback IE in a RELEASE COMPLETE message.	
V5501CRK002(Failure of V5201EST002)	Verify that SUT B includes a Crankback IE in a RELEASE message.	
V5502CRK001	To verify two switches, as an entry border node and as an exit border node, perform crankback procedure correctly when there is no alternate route.	
V5502CRK002	To verify two switches, as an entry border node and as an intermediate node, perform crankback procedure correctly when there is no alternate route.	
V5502CRK003	To verify two switches, as an intermediate node and as an exit border node, perform crankback procedure correctly when there is no alternate route.	
V5502CRK004	To verify two switches, as intermediate nodes, perform crankback procedure correctly when there is no alternate route.	
V5502CRK005	To verify two switches, as an exit border node and as an entry border node, perform crankback procedure correctly when there is no alternate route.	
V5503CRK001	To verify two switches, as a DTL originator and as an exit border node, perform crankback procedure correctly when there is no alternate route.	
V5503CRK002	To verify two switches, as a DTL originator and as an exit border node, perform crankback procedure correctly when there is no alternate route.	
V5503CRK003	To verify two switches, as DTL originator and as an intermediate node, perform crankback procedure correctly when there is no alternate route.	
V5505CRK001	To verify two switches, as an entry border node and as an intermediate node, perform crankback procedure correctly when there is an alternate route and crankback level matches.	

V5505CRK002	To verify two switches, as an entry border node and as an intermediate node, relay crankback message correctly when there is an alternate route and crankback level mismatches.	
V5505CRK003	To verify two switches, as two intermediate nodes, relay crankback message correctly even when there is an alternate route and crankback level matches.	
V5505CRK004	To verify two switches, as an exit border node and as an entry border node, relay crankback message correctly when there is an alternate route and crankback level mismatches for the entry border node.	
V5506CRK001	To verify two switches, as a DTL originator and as an intermediate node, perform crankback procedure correctly when there is an alternate route and crankback level matches.	
Point to Multipoint		
V5601P2M001	Verify that a SETUP message is sent from SUT A to SUT B with an endpoint reference IE, Broadband bearer capability IE set to point-to-multipoint, and no OAM traffic descriptor IE.	
V5601P2M002	Verify that a CALL PROCEEDING message is sent from SUT B to SUT A with an endpoint reference IE.	
V5601P2M003	Verify that an ALERTING message is sent from SUT B to SUT A with an endpoint reference IE.	
V5601P2M004	Verify that a CONNECT message is sent from SUT B to SUT A with an endpoint reference IE.	
V5602P2M001	Verify that an ADD PARTY message is sent from SUT A to SUT B to add another party to the existing point-to-multipoint call.	
V5602P2M002	Verify that an ADD PARTY ACKNOWLEDGE message is sent from SUT B to SUT A to acknowledge another party being added to the existing point-to-multipoint call.	
V5603P2M001	Verify that a party is dropped by sending a DROP PARTY message.	

V5603P2M002	Verify that a party dropped from the call is acknowledged by sending a DROP PARTY ACKNOWLEDGE message.	
5.2	
5.2	Test Cases Dynamic Behavior (Point-to-Point)

These interoperability test cases cover the dynamic behavior for point-to-point call/connection control.  The values used in the SETUP messages may be extracted from the PNNI v1.0 specification for SVCC-Based RCC call/connections or those specified in other relevant applications (e.g. FUNI, AMS, CES, etc.).

5.2.1	Establishing an SVC (SS_M)

1.	Test Case ID:	V5201EST001
Test Purpose:	Verify that SUT A routes a call request through SUT B.
Reference:	6.5.2.1
Pre-requisite:	PNNI Routing has completed
Test Configuration:	#3c

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (UNI) to SUT B.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B.
2.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
3.	Tester A sends a SETUP message to SUT A.

Verdict Criteria:
Observe that a SETUP message is sent from SUT A to SUT B.  (Also observe that a CALL PROCEEDING message is sent from SUT A to Tester A.)

2.	Test Case ID:	V5201EST002
Test Purpose:	Verify that SUT B accepts a call request from SUT A.
Reference:	6.5.2.4
Pre-requisite:	- PNNI Routing has completed and
- Test Case V5201EST001 was passed.
Test Configuration:	#3c

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (UNI) to SUT B.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B.
2.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
3.	Tester A sends a SETUP message to SUT A.
4.	Observe that a SETUP message is sent from SUT A to SUT B.  (Also observe that a CALL PROCEEDING message is sent from SUT A to Tester A.)

Verdict Criteria:
Observe that a CALL PROCEEDING message is sent from SUT B to SUT A. (Also observe that a SETUP message is sent to Tester B from SUT B.)

3.	Test Case ID:	V5201EST003
Test Purpose:	Verify that SUT B continues to progress (ALERTING message) a call request from SUT A.
Reference:	6.5.2.5
Pre-requisite:	- PNNI Routing has completed and
- Test Case V5201EST002 was passed.
Test Configuration:	#3c

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (UNI) to SUT B.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B.
2.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
3.	Tester A sends a SETUP message to SUT A.
4.	Observe that a SETUP message is sent from SUT A to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A)
5.	Observe that a CALL PROCEEDING message is sent from SUT B to SUT A.
6.	Observe that a SETUP message is sent to Tester B from SUT B.
7.	Tester B sends a CALL PROCEEDING message to SUT B.
8.	Tester B sends an ALERTING message to SUT B.

Verdict Criteria:
Observe that an ALERTING message is sent from SUT B to SUT A. (Also observe that an ALERTING message is sent to Tester A from SUT A.)

4.	Test Case ID:	V5201EST004
Test Purpose:	Verify that SUT B continues to progress (CONNECT message) a call request from SUT A.
Reference:	6.5.2.6
Pre-requisite:	- PNNI Routing has completed and
- Test Case V5201EST002 was passed.
Test Configuration:	#3c

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (UNI) to SUT B.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B.
2.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
3.	Tester A sends a SETUP message to SUT A.
4.	Observe that a SETUP message is sent from SUT A to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A)
5.	Observe that a CALL PROCEEDING message is sent from SUT B to SUT A.
6.	Observe that a SETUP message is sent to Tester B from SUT B.
7.	Tester B sends a CALL PROCEEDING message to SUT B.
8.	Tester B sends a CONNECT message to SUT B.

Verdict Criteria:
Observe that a CONNECT message is sent from SUT B to SUT A. (Also observe that a CONNECT message is sent from SUT A to Tester A.)

5.	Test Case ID:	V5201EST005
Test Purpose:	Verify that an SVC is established end-to-end.
Reference:	6.5.2.2, 6.5.2.6
Pre-requisite:	- PNNI Routing has completed and
- Test Case V5201EST004 was passed.
Test Configuration:	#3c

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (UNI) to SUT B.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B.
2.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
3.	Tester A sends a SETUP message to SUT A.
4.	Observe that a SETUP message is sent from SUT A to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A)
5.	Observe that a CALL PROCEEDING message is sent from SUT B to SUT A.
6.	Store the VPI/VCI contained in the SETUP or CALL PROCEEDING (correct message based on Node IDs of SUT A and SUT B).
7.	Observe that a SETUP message is sent to Tester B from SUT B.
8.	Tester B sends a CALL PROCEEDING message to SUT B.
9.	Tester B sends a CONNECT message to SUT B.
10.	Observe that a CONNECT message is sent from SUT B to SUT A.
11.	Observe that a CONNECT message is sent to Tester A from SUT A.
12.	Have Tester A send a user data ATM cell using the VPI/VCI for the call on interface A (UNI).

Verdict Criteria:
Observe that the user data ATM cell is passed over the VPI/VCI for interface D.  (Also that the user data ATM cell is passed over the VPI/VCI for interface C.)

Note: This test can be expanded for the purposes of verifying whether the connection satisfies the type (e.g. data rate, QoS, VBR, CBR, etc.) of SVC that was established.  However, further testing of the data plane is beyond the scope of this document.

6-10	Repeat Test cases 1 - 5 with the call initiated in the other direction.  (i.e. Tester B to Tester A)

11-15	Repeat Test Cases 1-5 with Test Configuration: #3a.

16-20	Repeat Test Cases 11-15 with Test Configuration: #3a and with the call initiated in the other direction (i.e. Tester B to Tester A)
5.2.2	
5.2.2	Establishing an SVC (SS_M)  Detailed for Test Configuration #3a

1.	Test Case ID:	V5202EST001_CNI
Test Purpose:	To verify that normal call setup can be supported between two switches. (connection identifier I.E. - associated signalling 1)
Reference:	6.5.2.2.1
Pre-requisite:	- Signalling between SUT A and SUT B is configured as associated signalling(i.e., (VPCI,VCI) = (non-zero,5)).
- SUT A has a higher node ID than SUT B.
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends SETUP to SUT A.
3.	Observe SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	Tester B sends a CALL PROCEEDING message to SUT B.
6.	The final state is ((3,9),(3,9)).

Verdict Criteria:
Observe that SUT A sends a SETUP message with a Connection identifier I.E., whose VP associated signalling field is coded as "VP associated signalling" and the Preferred/exclusive field is coded as "Exclusive VPCI; exclusive VCI".
- AND -
Observe that SUT B sends a CALL PROCEEDING message with the same Connection identifier I.E. as received in the SETUP message.

2.	Test Case ID:	V5202EST002_CNI
Test Purpose:	To verify that normal call setup can be supported between two switches. (connection identifier I.E. - associated signalling 2)
Reference:	6.5.2.2.1
Pre-requisite:	- Signalling between SUT A and SUT B is configured as associated signalling(i.e., (VPCI,VCI) = (non-zero,5)).
- SUT A has a lower node ID than SUT B.
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP to SUT A.
3.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B).
5.	Tester B sends a CALL PROCEEDING message to SUT B.
6.	The final state is ((3,9),(3,9)).

Verdict Criteria:
Observe that SUT A sends a SETUP message with a Connection identifier I.E., whose VP associated signalling field is coded as "VP associated signalling" and the Preferred/exclusive field is coded as "Exclusive VPCI; any VCI".
- AND -
Observe that SUT B sends a CALL PROCEEDING message with a Connection identifier I.E., whose VP associated signalling field is coded as "VP associated signalling" and the Preferred/exclusive field is coded as "Exclusive VPCI; exclusive VCI".

3.	Test Case ID:	V5202EST003_CNI
Test Purpose:	To verify that normal call setup can be supported between two switches. (connection identifier I.E. – non-associated signalling 1)
Reference:	6.5.2.2.2.1
Pre-requisite:	- Signalling between SUT A and SUT B is configured as non-associated signalling(i.e., (VPCI,VCI) = (0,5)).
- SUT A has a higher node ID than SUT B.
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
3.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	Tester B sends a CALL PROCEEDING message to SUT B.
6.	The final state is ((3,9),(3,9)).

Verdict Criteria:
Observe that SUT A sends a SETUP message with a Connection identifier I.E., whose VP associated signalling field is coded as "explicit indication of VPCI" and the Preferred/exclusive field is coded as "Exclusive VPCI; exclusive VCI".
- AND -
Observe that SUT B sends a CALL PROCEEDING message with the same Connection identifier I.E. as received in the SETUP message.

4.	Test Case ID:	V5202EST004_CNI
Test Purpose:	To verify that normal call setup can be supported between two switches. (connection identifier I.E. – non-associated signalling 2)
Reference:	6.5.2.2.2.1
Pre-requisite:	- Signalling between SUT A and SUT B is configured as non-associated signalling(i.e., (VPCI,VCI) = (0,5)).
- SUT A has a lower node ID than SUT B.
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
3.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	Tester B sends a CALL PROCEEDING message to SUT B.
6.	The final state is ((3,9),(3,9)).

Verdict Criteria:
Observe that SUT A sends a SETUP message without Connection identifier I.E., or with a Connection identifier I.E. whose VP associated signalling field is coded as "explicit indication of VPCI" and the Preferred/exclusive field is coded as "Exclusive VPCI; any VCI".
- AND -
Observe that SUT B sends a CALL PROCEEDING message with a Connection identifier I.E., whose VP associated signalling field is coded as "explicit indication of VPCI" and the Preferred/exclusive field is coded as "Exclusive VPCI; exclusive VCI".

5.	Test Case ID:	V5202EST005_CON
Test Purpose:	To verify that normal call setup can be supported between two switches. (Reception of CONNECT after sending SETUP)
Reference:	6.5.2.6
Pre-requisite:
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((3,9),(3,9)).
2.	Tester B sends a CONNECT message to SUT B.
3.	Observe that SUT B sends a CONNECT message to SUT A.  (Also observe that SUT A sends a CONNECT message to Tester A.)
4.	The final state is ((10,10),(10,10)).

Verdict Criteria:
Observe that SUT B sends a CONNECT message to SUT A.  (Also observe that SUT A sends a CONNECT message to Tester A.)

6.	Test Case ID:	V5202EST006_ALR
Test Purpose:	To verify that normal call setup can be supported between two switches. (Reception of ALERT after sending SETUP)
Reference:	6.5.2.6
Pre-requisite:
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((3,9),(3,9)).
2.	Tester B sends an ALERTING message to SUT B. 
3.	Observe that SUT B sends an ALERTING message to SUT A.  (Also observe that SUT A sends an ALERTING message to Tester A.)
4.	The final state is ((4,7),(4,7)).

Verdict Criteria:
Observe that SUT B sends an ALERTING message to SUT A.  (Also observe that SUT A sends an ALERTING message to Tester A.)

7.	Test Case ID:	V5202EST007_ACN
Test Purpose:	To verify that normal call setup can be supported between two switches.(Reception of CONNECT after receiving ALERT)
Reference:	6.5.2.6
Pre-requisite:
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((4,7),(4,7)).
2.	Tester B sends a CONNECT message to SUT B.
3.	Observe that SUT B sends a CONNECT message to SUT A.  (Also observe that SUT A sends a CONNECT message to Tester A.)
4.	The final state is ((10,10),(10,10)).

Verdict Criteria:
Observe that SUT B sends a CONNECT to SUT A.
(Also observe that SUT A sends a CONNECT message to Tester A.)

8.	Test Case ID:	V5202EST008_TRA
Test Purpose:	To verify two switches, during call/connection establishment, handle tagging parameters correctly when SUT A performs tagging for forward traffic.
Reference:	6.5.2.3.3, 6.4.5.9
Pre-requisite:	- SUT A performs tagging for forward traffics when it receives Tf field coded as "Tagging requested."
- The SUTs must be configurable administratively with respect to enabling or disabling tagging.  Note that this feature is not required by the PNNI v1.0 Specification or by the related PICS.  Inability to perform this function and hence this test does not necessarily mean that a SUT is non-compliant with respect to tagging. 
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
[The SETUP message contains ATD I.E. whose Tf field is coded as "Tagging requested."]
3.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is ((3,9),(3,6)).

Verdict Criteria:
Observe that SUT A sends a SETUP message to SUT B that contains ATD I.E. whose Tf field is coded as "Tagging not allowed."
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B that contains ATD I.E. whose Tf field is coded as "Tagging not allowed.")

9.	Test Case ID:	V5202EST009_TRA
Test Purpose:	To verify two switches, during call/connection establishment, handle tagging parameters correctly when SUT B performs tagging for forward traffic.
Reference:	6.5.2.3.3, 6.4.5.9
Pre-requisite:	- SUT A does not perform tagging for forward traffics when it receives Tf field coded as "Tagging requested," and
- SUT B performs tagging for forward traffics when it receives Tf field coded as "Tagging requested."
- The SUTs must be configurable administratively with respect to enabling or disabling tagging.  Note that this feature is not required by the PNNI v1.0 Specification or by the related PICS.  Inability to perform this function and hence this test does not necessarily mean that a SUT is non-compliant with respect to tagging.
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
[The SETUP message contains ATD I.E. whose Tf field is coded as "Tagging requested."]
3.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is ((3,9),(3,6)).

Verdict Criteria:
Observe that SUT A sends a SETUP message to SUT B.
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B that contains ATD I.E. whose Tf field is coded as "Tagging not allowed.")

10.	Test Case ID:	V5202EST010_TRA
Test Purpose:	To verify two switches, during call/connection establishment, handle tagging parameters correctly when they receive Tf field coded as Tagging not allowed.
Reference:	6.5.2.3.3, 6.4.5.9
Pre-requisite:	- The SUTs must be configurable administratively with respect to enabling or disabling tagging.  Note that this feature is not required by the PNNI v1.0 Specification or by the related PICS.  Inability to perform this function and hence this test does not necessarily mean that a SUT is non-compliant with respect to tagging.
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
[The SETUP message contains ATD I.E. whose Tf field is coded as "Tagging not allowed."]
3.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is ((3,9),(3,6)).

Verdict Criteria:
Observe that SUT A sends a SETUP message to SUT B that contains ATD I.E. whose Tf field is coded as "Tagging not allowed."
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B that contains ATD I.E. whose Tf field is coded as "Tagging not allowed.")

11.	Test Case ID:	V5202EST011_TRA
Test Purpose:	To verify two switches, during call/connection acceptance, handle tagging parameters correctly when SUT A performs tagging for forward traffic.
Reference:	6.5.2.6.1, 6.4.5.9
Pre-requisite:	- SUT A performs tagging for forward traffics when it receives Tf field coded as "Tagging requested."
- The SUTs must be configurable administratively with respect to enabling or disabling tagging.  Note that this feature is not required by the PNNI v1.0 Specification or by the related PICS.  Inability to perform this function and hence this test does not necessarily mean that a SUT is non-compliant with respect to tagging.
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((3,9),(3,6)).  {Note: Use Test Case V5202EST008_TRA to reach this state.}
2.	Tester B sends a CALL PROCEEDING message to SUT B.
3.	Tester B sends a CONNECT message to SUT B.
[The CONNECT message from Tester B contains an ATD I.E. whose Tf field is coded as "Tagging not applied."]
4.	Observe that SUT B sends a CONNECT message to SUT A.  (Also observe that SUT A sends a CONNECT message to Tester A.)
5.	The final state is ((10,10),(10,10)).

Verdict Criteria:
Observe that SUT B sends a CONNECT message to SUT A that contains ATD I.E. whose Tf field is coded as "Tagging not applied."
- AND -
Observe that SUT A sends a CONNECT message to Tester A that contains ATD I.E. whose Tf field is coded as "Tagging applied.")

12.	Test Case ID:	V5202EST012_TRA
Test Purpose:	To verify two switches, during call/connection acceptance, handle tagging parameters correctly when they had received Tf field coded as Tagging not allowed.
Reference:	6.5.2.6.1, 6.4.5.9
Pre-requisite:	- The SUTs must be configurable administratively with respect to enabling or disabling tagging.  Note that this feature is not required by the PNNI v1.0 Specification or by the related PICS.  Inability to perform this function and hence this test does not necessarily mean that a SUT is non-compliant with respect to tagging.
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((3,9),(3,6)).  {Note: Use Test Case V5202EST010_TRA to reach this state.}
2.	Tester B sends a CALL PROCEEDING message to SUT B.
3.	Tester B sends a CONNECT message to SUT B.  
[The CONNECT message from Tester B contains an ATD I.E. whose Tf field is coded as "Tagging not applied."]
4.	Observe that SUT B sends a CONNECT message to SUT A.  (Also observe that SUT A sends a CONNECT message to Tester A.
5.	The final state is ((10,10),(10,10)).

Verdict Criteria:
Observe that SUT B sends a CONNECT message to SUT A that contains ATD I.E. whose Tf field is coded as "Tagging not applied."
- AND -
(Observe that SUT A sends a CONNECT message to Tester A that contains ATD I.E. whose Tf field is coded as "Tagging not applied.")

13.	Test Case ID:	V5202EST013_TRA
Test Purpose:	To verify two switches, during call/connection establishment, handle backward tagging parameters correctly when none of two switches performs tagging for backward traffic.
Reference:	6.5.2.3.3, 6.4.5.9
Pre-requisite:	- Neither switch performs tagging for backward traffics when it receives Tb field coded as "Tagging not supported."
- The SUTs must be configurable administratively with respect to enabling or disabling tagging.  Note that this feature is not required by the PNNI v1.0 Specification or by the related PICS.  Inability to perform this function and hence this test does not necessarily mean that a SUT is non-compliant with respect to tagging.
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
[The SETUP message contains ATD I.E. whose Tb field is coded as "Tagging not supported."]
3.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is ((3,9),(3,6)).

Verdict Criteria:
Observe that SUT A sends a SETUP message to SUT B that contains ATD I.E. whose Tb field is coded as "Tagging not supported."
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B that contains ATD I.E. whose Tb field is coded as "Tagging not supported.")

14.	Test Case ID:	V5202EST014_QOS
Test Purpose:	To verify that both SUTs transfer QoS I.E. if it is included in the received SETUP message.
Reference:	6.5.2.3.5
Pre-requisite:
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
[The SETUP message contains QoS I.E.]
3.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is ((3,9),(3,6)).

Verdict Criteria:
Observe that SUT A sends a SETUP message to SUT B that includes the QoS I.E.  (Also observe that SUT B sends a SETUP message to Tester B that includes the QoS I.E.)

15.	Test Case ID:	V5202EST015_QOS
Test Purpose:	To verify that both SUTs increment values of the QoS parameters during call/connection establishment.
Reference:	6.5.2.3.5
Pre-requisite:
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
[The SETUP message contains Extended QoS I.E. and   End-to-end transit delay I.E.]
3.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is ((3,9),(3,6)).

Verdict Criteria:
Using both SETUP messages received by and sent from SUT A, check that SUT A incremented the cumulative forward and backward values of individual QoS parameters included in Extended QoS I.E. and End-to-end transit delay I.E.
- AND -
Using both SETUP messages received by and sent from SUT B, check that SUT B incremented the cumulative forward and backward values of individual QoS parameters included in Extended QoS I.E. and End-to-end transit delay I.E.

16-30	Repeat Test cases 1 - 15 with the call initiated in the other direction.  Tester A, SUT A, SUT B, and Tester B are exchanged with Tester B, SUT B, SUT A, and Tester A; and the state notation is changed from ((s1,s2),(s3,s4)) to ((s4,s3),(s2,s1)).
5.2.2.1	
5.2.2.1	Optional tests for Establishment: Negotiation of ATM traffic descriptors (OPT_5)

These tests are to be executed only if the implementation supports the optional procedures for Negotiation of ATM traffic descriptors as stated in Annex G #37 of the PNNI v1.0 specification.

1.	Test Case ID:	V5221EST001_TRA
Test Purpose:	To check that the call can be progressed when two switches are able to provide the traffic parameter values specified in the ATD I.E. and Minimum acceptable ATD I.E.
Reference:	6.5.2.3.4
Pre-requisite:
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP to SUT A.
[The SETUP message contains ATD I.E. and Minimum acceptable ATD I.E. such that, 
* Both SUT A and SUT B are able to provide the traffic parameter values specified in the ATD I.E.]
3.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.
5.	The final state is ((3,9),(3,6)).

Verdict Criteria:
Observe that SUT A sends a SETUP message with the same ATD I.E. and the same Minimum acceptable ATD I.E. which were sent by Tester A.
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message with the same ATD I.E. and the same Minimum acceptable ATD I.E. which are sent by Tester A.)

2.	Test Case ID:	V5221EST002_TRA
Test Purpose:	To check that the call can be progressed when the second switch is able to provide the traffic parameter values specified in the Minimum acceptable ATD I.E. but cannot support those in the ATD I.E. - Minimum acceptable ATD I.E. remains after negotiation.
Reference:	6.5.2.3.4
Pre-requisite:
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
[The SETUP message contains ATD I.E. and Minimum Acceptable ATD I.E. such that, 
* SUT A is able to provide the traffic parameter values specified in the ATD I.E.
* SUT B is not able to provide some traffic parameter values specified in the ATD I.E. but able to provide the traffic parameter values specified in the Minimum acceptable ATD I.E. Let the negotiated ATD I.E. has at least one traffic parameter value larger than Minimum acceptable ATD I.E.]
3.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is ((3,9),(3,6)).

Verdict Criteria:
Observe that SUT A sends a SETUP message with the same ATD I.E. and the same Minimum acceptable ATD I.E. as received.
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B with the modified ATD I.E. and the same Minimum acceptable ATD I.E. sent by Tester A.)

3.	Test Case ID:	V5221EST003_TRA
Test Purpose:	To check that the call can be progressed when the second switch is able to provide the traffic parameter values specified in the Minimum acceptable ATD I.E. but cannot support those in the ATD I.E. - Minimum acceptable ATD I.E. removes after negotiation.
Reference:	6.5.2.3.4
Pre-requisite:
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)). 
2.	Tester A sends a SETUP message to SUT A.
[The SETUP message contains ATD I.E. and Minimum Acceptable ATD I.E. such that, 
* SUT A is able to provide the traffic parameter values specified in the ATD I.E.
* SUT B is not able to provide some traffic parameter values specified in the ATD I.E. but able to just exactly provide the traffic parameter values specified in the Minimum acceptable ATD I.E.]
3.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A. (Also observe that SUT B sends a SETUP to Tester B.)
5.	The final state is ((3,9),(3,6)).

Verdict Criteria:
Observe that SUT A sends a SETUP message with the same ATD I.E. and the same Minimum acceptable ATD I.E. as received.
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message without the Minimum acceptable ATD I.E. Check that contents of the ATD I.E. are modified according to the Minimum acceptable ATD I.E.)

4.	Test Case ID:	V5221EST004_TRA
Test Purpose:	To check that the call can be progressed when the SUT A (first switch) is able to provide the traffic parameter values specified in the Minimum acceptable ATD I.E. but cannot support those in the ATD I.E. 
Reference:	6.5.2.3.4
Pre-requisite:
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)). 
2.	Tester A sends a SETUP to SUT A.
[The SETUP message contains ATD I.E. and Minimum Acceptable ATD I.E. such that, 
* SUT A is not able to provide some traffic parameter values specified in the ATD I.E. but able to provide the traffic parameter values specified in the Minimum acceptable ATD I.E. Let the modified ATD I.E. has at least one traffic parameter value larger than Minimum acceptable ATD I.E.
* SUT B is able to provide the traffic parameter values specified in the ATD I.E.]
3.	Observe that SUT A sends a SETUP to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message Tester B.)
5.	The final state is ((3,9),(3,6)).

Verdict Criteria:
Observe that SUT A sends a SETUP message to SUT B with the modified ATD I.E. and the same Minimum acceptable ATD I.E. sent by Tester A.
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message with the same ATD I.E. and the same Minimum acceptable ATD I.E. as received to Tester B.)

5.	Test Case ID:	V5221EST005_TRA
Test Purpose:	To check that the call can be progressed when both SUTs are able to provide the traffic parameter values specified in the ATD I.E. and Alternative ATD I.E. 
Reference:	6.5.2.3.4
Pre-requisite:
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
[The SETUP message contains ATD I.E. and Alternative ATD I.E. such that, 
* Both SUT A and SUT B are able to provide the traffic parameter values specified in the ATD I.E. and Alternative ATD I.E.]
3.	Observe that SUT A sends a SETUP to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is ((3,9),(3,6)).

Verdict Criteria:
Observe that SUT A sends a SETUP message to SUT B with the same ATD I.E. and the same Alternative ATD I.E. as received from Tester A.
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message with the same ATD I.E. and the same Alternative ATD I.E. as received to Tester B.)

6.	Test Case ID:	V5221EST006_TRA
Test Purpose:	To check that the call can be progressed when SUT B (second switch) is able to provide the traffic parameter values specified in the ATD I.E. but cannot support those in the Alternative ATD I.E.
Reference:	6.5.2.3.4
Pre-requisite:
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
[The SETUP message contains ATD I.E. and Alternative ATD I.E. such that, 
* SUT A is able to provide the traffic parameter values specified in the ATD I.E. and Alternative ATD I.E.
* SUT B is able to provide traffic parameter values specified in the ATD I.E. but not able to provide traffic parameter values specified in the Alternative ATD I.E.]
3.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.
5.	The final state is ((3,9),(3,6)).

Verdict Criteria:
Observe that SUT A sends a SETUP message to SUT B with the same ATD I.E. and the same Alternative ATD I.E. as received from Tester A.
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B with the same ATD I.E. as received but without the Alternative ATD I.E.)

7.	Test Case ID:	V5221EST007_TRA
Test Purpose:	To check that the call can be progressed when SUT B (second switch) is able to provide the traffic parameter values specified in the Alternative ATD I.E. but cannot support those in the ATD I.E.
Reference:	6.5.2.3.4
Pre-requisite:
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
[The SETUP message contains ATD I.E. and Alternative ATD I.E. such that, 
* SUT A is able to provide the traffic parameter values specified in the ATD I.E. and Alternative ATD I.E.
* SUT B is able to provide traffic parameter values specified in the Alternative ATD I.E. but not able to provide traffic parameter values specified in the ATD I.E.]
3.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to SUT A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is ((3,9),(3,6)).

Verdict Criteria:
Observe that SUT A sends a SETUP message with the same ATD I.E. and the same Alternative ATD I.E. as received from Tester A.
- AND -
Observe that SUT B sends CALL_PROC to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B without Alternative ATD I.E. Check that contents of the ATD I.E. are same with the received Alternative ATD I.E.)

8.	Test Case ID:	V5221EST008_TRA
Test Purpose:	To check that both SUTs progress the CONNECT message with the same ATD I.E. if it is contained in the received CONNECT message. 
Reference:	6.5.2.6.2
Pre-requisite:
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure: 
1.	The initial state is ((3,9),(3,6)).
2.	Tester B sends a CALL PROCEEDING message to SUT B.
3.	Tester B sends a CONNECT message to SUT B.
[The CONNECT message from Tester B contains the same ATD I.E. as received in the SETUP message.]
4.	Observe that SUT B sends a CONNECT message to SUT A.  (Also observe that SUT A sends a CONNECT message to Tester A.)
5.	The final state is ((10,10),(10,10)).

Verdict Criteria:
Observe that SUT B sends a CONNECT message with the same ATD I.E. as received with the exception of the Traffic Management Options.  (Also observe that SUT A sends CONNECT message to Tester A with the same ATD I.E. as received with the exception of the Traffic Management Options.)

9.	Test Case ID:	V5221EST009_TRA
Test Purpose:	To check that both SUTs progress the CONNECT message with the ATD I.E. of which parameters has been negotiated during call setup. - SUT B (second switch) adds ATD I.E. on the CONNECT message.
Reference:	6.5.2.6.2
Pre-requisite:	Must have passed Test Case V5221EST002_TRA.
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((3,9),(3,6)).  {Note: Use Test Case V5221EST002_TRA to reach this state.}
2.	Tester B sends a CALL PROCEEDING message to SUT B.
3.	Tester B sends a CONNECT message to SUT B.
[The CONNECT message from Tester B contains no ATD I.E.]
4.	Observe that SUT B sends a CONNECT message to SUT A.  (Also observe that SUT A sends a CONNECT message to Tester A.
5.	The final state is ((10,10),(10,10)).

Verdict Criteria:
Observe that SUT B sends a CONNECT message with the ATD I.E. which are the same as those of the SETUP message sent by SUT B to Tester B with the exception of the Traffic Management Options.  (Also observe that SUT A sends a CONNECT message to Tester A.)

10.	Test Case ID:	V5221EST010_TRA
Test Purpose:	To check that both SUTs progress the CONNECT message with the ATD I.E. of which parameters has been negotiated during call setup. - SUT A (first switch) adds ATD I.E. on the CONNECT message.
Reference:	6.5.2.6.2
Pre-requisite:	Must have passed Test Case V5221EST004_TRA.
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((3,9),(3,6)).  {Note: Use Test Case V5221EST004_TRA to reach this state.}
2.	Tester B sends a CALL PROCEEDING message to SUT B.
[The CONNECT message from Tester B contains no ATD I.E.]
3.	Observe that SUT B sends a CONNECT message to SUT A.  (Also observe that SUT A sends a CONNECT message to Tester A.
4.	The final state is ((10,10),(10,10)).

Verdict Criteria:
Observe that SUT A sends a CONNECT message to Tester A with an ATD I.E. of which contents are same with those of the SETUP message sent by SUT B with the exception of the Traffic Management Options.

11.	Test Case ID:	V5221EST011_TRA
Test Purpose:	To check that, after alerting, two switches progress the CONNECT message with the same ATD I.E. if it is contained in the received CONNECT message. 
Reference:	6.5.2.6.2
Pre-requisite:
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((3,9),(3,6)).
2.	Tester B sends a CALL PROCEEDING message to SUT B.
3.	Tester B sends an ALERTING message to SUT B.
4.	Observe that SUT B sends an ALERTING message to SUT A.  (Also observe that SUT A sends an ALERTING message to Tester A.)
5.	Tester B sends a CONNECT message to SUT B.
[The CONNECT message from Tester B contains the same ATD I.E. as received in the SETUP message.]
6.	Observe that SUT B sends a CONNECT message to SUT A.  (Also observe that SUT A sends a CONNECT message to Tester A.)
7.	The final state is ((10,10),(10,10)).

Verdict Criteria:
Observe that SUT B sends a CONNECT message with the same ATD I.E. as received.  (Also observe that SUT A sends a CONNECT message to Tester A.)

12.	Test Case ID:	V5221EST012_TRA
Test Purpose:	To check that, after alerting, two switches progress the CONNECT message with the ATD I.E. of which parameters has been negotiated during call setup. - SUT B (second switch) adds ATD I.E. on the CONNECT message. 
Reference:	6.5.2.6.2
Pre-requisite:	Must have passed Test Case V5221EST002_TRA.
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((3,9),(3,6)).  {Note: Use Test Case V5221EST002_TRA to reach this state.}
2.	Tester B sends a CALL PROCEEDING message to SUT B.
3.	Tester B sends an ALERTING message to SUT B.
4.	Observe that SUT B sends an ALERTING message to SUT A.  (Also observe that SUT A sends an ALERTING message to Tester A.)
5.	Tester B sends a CONNECT message to SUT B.
[The CONNECT message from Tester B contains no ATD I.E.]
6.	Observe that SUT B sends a CONNECT message to SUT A.  (Also observe that SUT A sends a CONNECT message to Tester A.)
7.	The final state is ((10,10),(10,10)).

Verdict Criteria:
Observe that SUT B sends a CONNECT message with the ATD I.E. with the same contents as those in the SETUP message sent by SUT B to Tester B with the exception of the Traffic Management Options.

13.	Test Case ID:	V5221EST013_TRA
Test Purpose:	To check that, after alerting, two switches progress the CONNECT message with the ATD I.E. of which parameters has been negotiated during call setup.  - SUT A (first switch) adds ATD I.E. on the CONNECT message. 
Reference:	6.5.2.6.2
Pre-requisite:	Must have passed Test Case V5221EST004_TRA.
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((3,9),(3,6)).  {Note: Use Test Case V5221EST004_TRA to reach this state.}
2.	Tester B sends a CALL PROCEEDING message to SUT B.
3.	Tester B sends an ALERTING message to SUT B.
4.	Observe that SUT B sends an ALERTING message to SUT A.  (Also observe that SUT A sends an ALERTING message to Tester A.)
5.	Tester B sends a CONNECT message to SUT B.
[The CONNECT message sent by Tester B contains no ATD I.E.]
6.	Observe that SUT B sends a CONNECT message to SUT A.  (Also observe that SUT A sends a CONNECT message to Tester A.)
7.	The final state is ((10,10),(10,10)).

Verdict Criteria:
Observe that SUT A sends a CONNECT message with an ATD I.E. of which contents are same with those of the SETUP message sent by SUT B to Tester B with the exception of the Traffic Management Options.

14-26	Repeat Test cases 1 - 13 with the call initiated in the other direction.  Tester A, SUT A, SUT B, and Tester B are exchanged with Tester B, SUT B, SUT A, and Tester A; and the state notation is changed from ((s1,s2),(s3,s4)) to ((s4,s3),(s2,s1)).

5.2.3	
5.2.3	Establishing an SVC (SS_M)  Detailed for Test Configuration #3b

1.	Test Case ID:	V5203EST001_CNI
Test Purpose:	To verify that normal call setup can be supported between two switches. (connection identifier I.E. - associated signalling 1)
Reference:	6.5.2.2.1
Pre-requisite:	- Signalling between SUT A and SUT B is configured as associated signalling (i.e., (VPCI,VCI) = (non-zero,5)).
- SUT A has higher node ID than SUT B.
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is (0,(0,0))
2.	Tester A sends a SETUP message to SUT A.
3.	Observe that SUT A sends a SETUP message to SUT B.
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	Tester B sends a CALL PROCEEDING message to SUT B.
6.	The final state is (9,(3,9))

Verdict Criteria:
Observe that SUT A sends a SETUP message with a Connection identifier I.E., whose VP associated signalling field is coded as "VP associated signalling" and the Preferred/exclusive field is coded as "Exclusive VPCI; exclusive VCI".
- AND -
Observe that SUT B sends a CALL PROCEEDING message with the same Connection identifier I.E. as received in the SETUP message from SUT A.

2.	Test Case ID:	V5203EST002_CNI
3.	Test Case ID:	V5203EST003_CNI
4.	Test Case ID:	V5203EST004_CNI
 : Obtained from V5202EST002_CNI, V5202EST003_CNI and V5202EST004_CNI by following changes,
   1. Replace states ((s1,s2),(s3,s4)) by (s2,(s3,s4)).
   2. Replace step 3 of Test Procedure by,
      "3.	Observe that SUT A sends a SETUP message to SUT B."

5.	Test Case ID:	V5203EST005_CON
6.	Test Case ID:	V5203EST006_ALR
7.	Test Case ID:	V5203EST007_ACN
 : Obtained from V5202EST005_CON, V5202EST006_ALR and V5202EST007_ACN by following changes,
   1. Replace states ((s1,s2),(s3,s4)) by (s2,(s3,s4)).

8.	Test Case ID:	V5203EST008_QOS
Test Purpose:	To verify that both SUTs transfer QoS I.E. if it is included in the received SETUP message.
Pre-requisite:
Reference:	6.5.2.3.5
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is (0,(0,0)).
2.	Tester A sends a SETUP message to SUT A.
[The SETUP message contains QoS I.E.]
3.	Observe that SUT A sends a SETUP message to SUT B.
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is (9,(3,6)).

Verdict Criteria:
Observe that SUT A sends a SETUP message to SUT B that includes QoS I.E. (Also observe that SUT B sends a SETUP message to Tester B that includes QoS I.E.)

9.	Test Case ID:	V5203EST009_QOS
Test Purpose:	To verify that the first switch sends SETUP including Extended QoS I.E. when the setup indication includes neither Extended QoS I.E. nor End‑to‑end transit delay I.E. and ATM service category of the call is CBR, real‑time VBR, or non‑real‑time VBR, and the second switch increments values of the QoS parameters during call/connection establishment.
Reference:	6.5.2.3.5
Pre-requisite:
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is (0,(0,0)).
2.	Tester A sends a SETUP message to SUT A.
[The SETUP message contains neither Extended QoS I.E. nor End-to-end transit delay I.E. and ATM service category of the call is CBR, real-time VBR, or      non-real-time VBR.]
3.	Observe that SUT A sends a SETUP message to SUT B.
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is (9,(3,6)).

Verdict Criteria:
Observe that SUT A sends a SETUP message to SUT B that includes Extended QoS I.E.
- AND - 
Using both SETUP messages received by and sent from SUT B, check that SUT B incremented the cumulative forward and backward values of individual QoS parameters included in the Extended QoS I.E.

10.	Test Case ID:	V5203EST010_CNI
Test Purpose:	To verify that normal call setup can be supported between two switches. (connection identifier I.E. - associated signalling 1)
Reference:	6.5.2.2.1
Pre-requisite:	- Signalling between SUT A and SUT B is configured as associated signalling (i.e., (VPCI,VCI) = (non-zero,5)),
- SUT B has higher node ID than SUT A.
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is (0,(0,0))
2.	Tester B sends a SETUP to SUT B. 
3.	Observe that SUT B sends a SETUP message to SUT A.  (Also Observe that SUT B sends a CALL PROCEEDING message Tester B.)
4.	Observe that SUT A sends a CALL PROCEEDING message to SUT B.  (Also observe that SUT A sends a SETUP message to Tester A.)
5.	The final state is (3,(9,3))

Verdict Criteria:
Observe that SUT B sends a SETUP message to SUT A with a Connection identifier I.E., whose VP associated signalling field is coded as "VP associated signalling" and the Preferred/exclusive field is coded as "Exclusive VPCI; exclusive VCI".
- AND -
Observe that SUT A sends a CALL PROCEEDING message to SUT B with the same Connection identifier I.E. as received in the SETUP message from SUT B.

11.	Test Case ID:	V5203EST011_CNI
12.	Test Case ID:	V5203EST012_CNI
13.	Test Case ID:	V5203EST013_CNI
 : Obtained from V5202EST002_CNI, V5202EST003_CNI and V5202EST004_CNI by following changes,
   1. Replace Tester A, SUT A, SUT B and Tester B by Tester B, SUT B, SUT A and Tester A, respectively.
   2. Replace states ((s1,s2),(s3,s4)) by (s3,(s2,s1)).

14.	Test Case ID:	V5203EST014_CON
15.	Test Case ID:	V5203EST015_ALR
16.	Test Case ID:	V5203EST016_ACN
 : Obtained from V5202EST005_CON, V5202EST006_ALR and V5202EST007_ACN by following
   changes,
   1. Replace Tester A, SUT A, SUT B and Tester B by Tester B, SUT B, SUT A and Tester A, respectively.
   2. Replace states ((s1,s2),(s3,s4)) by (s3,(s2,s1)).

17.	Test Case ID:	V5203EST017_QOS
Test Purpose:	To verify that the first switch transfers QoS I.E. if it is  included in the received SETUP message.
Reference:	6.5.2.3.5
Pre-requisite:
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is (0,(0,0)).
2.	Tester B sends a SETUP message to SUT B.
[The SETUP message contains QoS I.E.]
3.	Observe that SUT B sends a SETUP message to SUT A. (Also observe that SUT B sends a CALL PROCEEDING message to Tester B.)
4.	Observe that SUT A sends a CALL PROCEEDING message to SUT B.  (Also observe that SUT A sends a SETUP message to Tester A.)
5.	The final state is (3,(9,3)).

Verdict Criteria:
Observe that SUT B sends a SETUP message with QoS I.E.

18.	Test Case ID:	V5203EST018_QOS
Test Purpose:	To verify that the first switch increments values of the QoS parameters during call/connection establishment.
Reference:	6.5.2.3.5
Pre-requisite:
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is (0,(0,0)).
2.	Tester B sends a SETUP message to SUT B.
[The SETUP message contains Extended QoS I.E. and   End-to-end transit delay I.E.]
3.	Observe that SUT B sends a SETUP message to SUT A.  (Also observe that SUT B sends a CALL PROCEEDING message to Tester B.)
4.	Observe that SUT A sends a CALL PROCEEDING message to SUT B.  (Also observe that SUT A sends a SETUP message to Tester A.)
5.	The final state is (3,(9,3)).

Verdict Criteria:
Using both SETUP messages received by and sent from SUT B, check that SUT B incremented the cumulative forward and backward values of individual QoS parameters included in Extended QoS I.E. and End-to-end transit delay I.E.
5.2.3.1	
5.2.3.1	Optional tests for Establishment: Negotiation of ATM traffic descriptors (OPT_5)

These tests are to be executed only if the implementation supports the optional procedures for Negotiation of ATM traffic descriptors as stated in Annex G #37 of the PNNI v1.0 specification.

1.	Test Case ID:	V5231EST001_TRA
Test Purpose:	To check that SUT B (second switch) progresses the CONNECT message with the same ATD I.E. if it is contained in the received CONNECT message.
Reference:	6.5.2.6.2
Pre-requisite:
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is (9,(3,6)).
2.	Tester B sends a CALL PROCEEDING message to SUT B.
3.	Tester B sends a CONNECT message to SUT B.
[The CONNECT message from Tester B contains the same ATD I.E. as received in the SETUP message from SUT B.]
4.	Observe that SUT B sends a CONNECT message to SUT A.  (Also observe that SUT A sends a CONNECT message to Tester A.)
5.	The final state is (10,(10,10)).

Verdict Criteria:
Observe that SUT B sends a CONNECT message with the same ATD I.E. as received from Tester B with the exception of the Traffic Management Options.  (Also observe that SUT A sends a CONNECT message to Tester A.)

2.	Test Case ID:	V5231EST002_TRA
Test Purpose:	To check that, after alerting, second switch progresses the CONNECT message with the same ATD I.E. if it is contained in the received CONNECT message.
Reference:	6.5.2.6.2
Pre-requisite:
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is (9,(3,6)).
2.	Tester B sends a CALL PROCEEDING message to SUT B.
3.	Tester B sends an ALERTING message to SUT B
4.	Observe that SUT B sends an ALERTING message to SUT A.  (Also observe that SUT A sends an ALERTING message to Tester A.)
5.	Tester B sends a CONNECT message to SUT B.
[The CONNECT message from Tester B contains the same ATD I.E. as received in the SETUP message from SUT B.]
6.	Observe that SUT B sends a CONNECT message to SUT A.  (Also observe that SUT A sends a CONNECT message to Tester A.)
7.	The final state is (10,(10,10)).

Verdict Criteria:
Observe that SUT B sends a CONNECT message with the same ATD I.E. as received from Tester B with the exception of the Traffic Management Options.  (Also observe that SUT A sends a CONNECT message to Tester A.)

3.	Test Case ID:	V5231EST003_TRA
Test Purpose:	To check that the call can be progressed when two switches are able to provide the traffic parameter values specified in the ATD I.E. and Minimum acceptable ATD I.E.
Reference:	6.5.2.3.4
Pre-requisite:	- Arrange the generation of a SETUP message from Tester A to Tester B with:
- ATD I.E. and Minimum Acceptable ATD I.E. such that, both SUT B and SUT A are able to provide the traffic parameter values specified in the ATD I.E.
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is (0,(0,0)).
2.	Tester B sends a SETUP message to SUT B.
3.	Observe that SUT B sends a SETUP message to SUT A.  (Also observe that SUT B sends a CALL PROCEEDING message to Tester B.)
4.	Observe that SUT A sends a CALL PROCEEDING message to SUT B.  (Also observe that SUT A sends a SETUP message to Tester A.)
5.	The final state is (3,(9,3)).

Verdict Criteria:
Observe that SUT B sends a SETUP message with the same ATD I.E. and the same Minimum acceptable ATD I.E. which are sent by Tester B.
- AND -
Observe that SUT A sends a CALL PROCEEDING message to SUT B.  (Also observe that SUT A sends a SETUP message to Tester A.)

4.	Test Case ID:	V5231EST004_TRA
5.	Test Case ID:	V5231EST005_TRA
6.	Test Case ID:	V5231EST006_TRA
7.	Test Case ID:	V5231EST007_TRA
8.	Test Case ID:	V5231EST008_TRA
9.	Test Case ID:	V5231EST009_TRA
: Obtained from V5221EST002_TRA, V5221EST003_TRA, V5221EST004_TRA, V5221EST005_TRA, V5221EST006_TRA, V5221EST007_TRA by following changes,
   1. Replace Tester A, SUT A, SUT B and Tester B by Tester B, SUT B, SUT A and Tester A, respectively.
   2. Replace states ((s1,s2),(s3,s4)) by (s3,(s2,s1)).
   3. Replace Verdict Criteria of each test case by,

     "1.	Observe that SUT B sends a SETUP message with the same ATD I.E. and the same Minimum acceptable ATD I.E. as received.
      2.	Observe that SUT A sends a CALL PROCEEDING message to SUT B.  (Also Observe that SUT A sends a SETUP to Tester A.)"
      for the test V5231EST004_TRA and V5231EST005_TRA.

     "1.	Observe that SUT B sends a SETUP message with the modified ATD I.E. and the same Minimum acceptable ATD I.E. as sent by Tester B.
      2.	Observe that SUT A sends a CALL PROCEEDING message to SUT B.  (Also observe that SUT A sends a SETUP message to Tester A.)"
      for the test V5231EST006_TRA.

     "1.	Observe that SUT B send a SETUP message with the same ATD I.E. and the same Alternative ATD I.E. as received.
      2.	Observe that SUT A sends a CALL PROCEEDING message to SUT B.  (Also observe that SUT A sends a SETUP message to Tester A.)"
      for the test V5231EST007_TRA, V5231EST008_TRA and V5231EST009_TRA.
5.2.4	
5.2.4	Establishing an SVC (SS_M)  Detailed for Test Configuration #3c

1.	Test Case ID:	V5204EST001_CNI
Test Purpose:	To verify that normal call setup can be supported between two switches. (connection identifier I.E. - associated signalling 1)
Reference:	6.5.2.2.1
Pre-requisite:	- Signalling between SUT A and SUT B is configured as associated signalling (i.e., (VPCI,VCI) = (non-zero,5)),
- SUT A has higher node ID than SUT B.
Test Configuration:	#3c

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (UNI) to SUT B.

Test Procedure:
1.	The initial state is (0,0)
2.	Tester A sends a SETUP message to SUT A.
3.	Observe that SUT A sends a SETUP message to SUT B.
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is (9,3)

Verdict Criteria:
Observe that SUT A sends a SETUP message with a Connection identifier I.E., whose VP associated signalling field is coded as "VP associated signalling" and the Preferred/exclusive field is coded as "Exclusive VPCI; exclusive VCI".
- AND -
Observe that SUT B sends a CALL PROCEEDING message with the same Connection identifier I.E. as received in the SETUP message from SUT A.

2.	Test Case ID:	V5204EST002_CNI
3.	Test Case ID:	V5204EST003_CNI
4.	Test Case ID:	V5204EST004_CNI
 : Obtained from V5202EST002_CNI, V5202EST003_CNI and V5202EST004_CNI, respectively, by following 
   changes,
   1. Replace states ((s1,s2),(s3,s4)) by (s2,s3).
   2. Replace step 3 of Test Procedure by,
      "3. Observe that SUT A sends a SETUP message to SUT B."

5.	Test Case ID:	V5204EST005_CON
6.	Test Case ID:	V5204EST006_ALR
7.	Test Case ID:	V5204EST007_ACN
 : Obtained from V5202EST005_CON, V5202EST006_ALR, and V5202EST007_ACN, respectively,
   by following replacements,
   1.	Replace states ((s1,s2),(s3,s4)) by (s2,s3).

8.	Test Case ID:	V5204EST008_QOS
Test Purpose:	To verify that the preceding side includes QoS I.E. in the corresponding SETUP message, when the preceding side receives a setup indication that includes a QoS parameter I.E.
Reference:	6.5.2.3.5
Pre-requisite:
Test Configuration:	#3c

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (UNI) to SUT B.

Test Procedure:
1.	The initial state is (0,0)
2.	Tester A sends a SETUP message to SUT A.
3.	Observe that SUT A sends a SETUP message to SUT B.
[The SETUP message contains QoS I.E.] 
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is (9,3)

Verdict Criteria:
Observe that SUT A sends a SETUP message to SUT B that includes QoS I.E.

9.	Test Case ID:	V5204EST009_QOS
Test Purpose:	To verify that the first switch sends SETUP including Extended QoS I.E. when the setup indication includes neither Extended QoS I.E. nor End-to-end transit delay I.E. and ATM service category of the call is CBR,     real-time VBR, or non-real-time VBR.
Reference:	6.5.2.3.5
Pre-requisite:
Test Configuration:	#3c

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (UNI) to SUT B.

Test Procedure:
1.	The initial state is (0,0)
2.	Tester A sends a SETUP message to SUT A.
[The SETUP message sent by Tester A contains neither Extended QoS I.E. nor End-to-end transit delay I.E. and ATM service category of the call is CBR, real-time VBR, or non-real-time VBR.]
3.	Observe that SUT A sends a SETUP message to SUT B.
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is (9,3)

Verdict Criteria:
Observe that SUT A sends a SETUP message to SUT B that includes Extended QoS I.E.

5.3	10 - 18	Repeat Test Cases 1 - 9 with the call initiated in the other direction (i.e. from Tester B).  The state notation is changed from (s1,s2) to (s2,s1).
5.3	Release

5.3.1	Releasing an SVC (SS_M)

1.	Test Case ID:	V5301REL001
Test Purpose:	Verify that SUT A releases a call request through SUT B.
Reference:	6.5.3.3
Pre-requisite:	- PNNI Routing has completed and
- Call/connection was established (i.e. must have passed Test Case V5201EST005.)
Test Configuration:	#3c

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (UNI) to SUT B.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B.
2.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
3.	Establish a call.  {Note: Use Test Case V5201EST005 to establish a call.}
4.	Tester A sends a RELEASE message to SUT A.

Verdict Criteria:
Observe that a RELEASE message is sent from SUT A to SUT B.  (Also observe a RELEASE COMPLETE message from SUT A to Tester A.)

2.	Test Case ID:	V5301REL002
Test Purpose:	Verify that SUT B acknowledges the release call request.
Reference:	6.5.3.3
Pre-requisite:	- PNNI Routing has completed, 
- Call/connection was established (i.e. must have passed Test Case V5201EST005), and
- passed Test Case V5301REL001.
Test Configuration:	#3c

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (UNI) to SUT B.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B.
2.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
3.	Establish a call.  {Note: Use Test Case V5201EST005 to establish a call.}
4.	Tester A sends a RELEASE message to SUT A.
5.	Observe that a RELEASE message is sent from SUT A to SUT B.  Also observe a RELEASE COMPLETE message from SUT A to Tester A.

Verdict Criteria:
Observe that a RELEASE COMPLETE message is sent from SUT B to SUT A.  (Also observe a RELEASE message is sent from SUT B to Tester B.)

3.	Test Case ID:	V5301REL003
Test Purpose:	Verify that the SVC is released.
Pre-requisite:	- PNNI Routing has completed,
- Call/connection was established (i.e. must have passed Test Case V5201EST005), and
- passed Test Case V5301REL001.
Reference:	6.5.3.3
Test Configuration:	#3c

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (UNI) to SUT B.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B.
2.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
3.	Establish a call.  {Note: Use Test Case V5201EST005 to establish a call.}
4.	Tester A sends a RELEASE message to SUT A.
5.	Observe that a RELEASE message is sent from SUT A to SUT B.  Also observe a RELEASE COMPLETE message from SUT A to Tester A.
6.	Observe that a RELEASE COMPLETE message is sent from SUT B to SUT A.  Also observe a RELEASE message is sent from SUT B to Tester B.
7.	Tester B sends a RELEASE COMPLETE message.
8.	Have Tester A send a user data ATM cell using the VPI/VCI that was used for this call on interface A.

Verdict Criteria:
Observe that the user data ATM cell is not passed over the VPI/VCI that was used for this call over interface D.

4-6	Repeat test cases 1-3 but with the release call request initiated in the other direction. (i.e. Tester B to Tester A)

7-9		Repeat Test Cases 1-3 with Test Configuration #3a.

5.3.2	10-12	Repeat Test Cases 7-9 with Test Configuration #3a and with the release call request initiated in the other direction (i.e. Tester B to Tester A).
5.3.2	Releasing an SVC (SS_M)  Detailed for Test Configuration #3a

1.	Test Case ID:	V5302REL001_BFR
Test Purpose:	To verify that a call/connection can be released by originating user side before connection is established. 
Reference:	6.5.3
Pre-requisite:
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((3,9),(3,9)).
2.	Tester A sends a RELEASE message to SUT A.
3.	Observe that SUT A sends a RELEASE message to SUT B.  (Also Observe that SUT A sends a RELEASE COMPLETE message to Tester A.)
4.	Observe that SUT B sends a RELEASE COMPLETE message to SUT A.  (Also observe that SUT B sends a RELEASE message to Tester B.)
5.	Tester B sends a RELEASE COMPLETE message to SUT B.
6.	The final state is ((0,0),(0,0)).

Verdict Criteria:
Observe that SUT A sends a RELEASE message to SUT B.  (Also observe that SUT A sends a RELEASE COMPLETE message to Tester A.)
- AND -
Observe that SUT B sends RELEASE COMPLETE message to SUT A.  (Also observe that SUT B sends a RELEASE message to Tester B.)

2.	Test Case ID:	V5302REL002_BFR
Test Purpose:	To verify that a call/connection can be released by destination user side before connection is established. 
Reference:	6.5.3
Pre-requisite:
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((3,9),(3,6)).
2.	Tester B sends a RELEASE message to SUT B.
[The RELEASE message contains no Crankback I.E.]
3.	Observe that SUT B sends a RELEASE message to SUT A.  (Also observe that SUT B sends a RELEASE COMPLETE message to Tester B.)
4.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)
5.	Tester A sends a RELEASE COMPLETE message to SUT A.
6.	The final state is ((0,0),(0,0)).

Verdict Criteria:
Observe that SUT B sends a RELEASE message to SUT A. (Also observe that SUT B sends a RELEASE COMPLETE message to Tester B.)
- AND -
Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)

3.	Test Case ID:	V5302REL003_CNI
Test Purpose:	To verify that a call/connection can be released by a failure of connection identifier assignment.
Reference:	6.5.2.2, 6.5.3
Pre-requisite:	The node ID of SUT B is smaller than Tester B.
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((3,9),(3,6)).
2.	Tester B sends a RELEASE COMPLETE message to SUT B.
[The RELEASE COMPLETE message has cause #45, "no VPCI/VCI available]
3.	Observe that SUT B sends a RELEASE message to SUT A.
4.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)
5.	Tester A sends a RELEASE COMPLETE message to SUT A.
6.	The final state is ((0,0),(0,0)).

Verdict Criteria:
Observe that SUT B sends a RELEASE message to SUT A that includes a Crankback I.E.
- AND -
Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)

4.	Test Case ID:	V5302REL004_DTL
Test Purpose:	To verify that the release of a call/connection can be relayed when call clearing occurs due to DTL processing failure.
Reference:	Annex B, 6.5.3
Pre-requisite:
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((3,9),(3,9)).
2.	Tester B sends a RELEASE message to SUT B.
[The RELEASE message has cause code #3 "destination unreachable" and the crankback cause #3.]
3.	Observe that SUT B sends a RELEASE message to SUT A.  (Also observe that SUT B sends a RELEASE COMPLETE message to Tester B.)
4.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)
5.	Tester A sends a RELEASE COMPLETE message to SUT A.
6.	The final state is ((0,0),(0,0)).

Verdict Criteria:
Observe that SUT B sends a RELEASE message to SUT A with crankback I.E.  (Also observe that SUT B sends a RELEASE COMPLETE message to Tester B.)
- AND -
Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)

5.	Test Case ID:	V5302REL005_USR
Test Purpose:	To verify that a call/connection can be released by originating user side after call/connection completion.
Reference:	6.5.3
Pre-requisite:
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((10,10),(10,10)).
2.	Tester A sends a RELEASE message to SUT A.
3.	Observe that SUT A sends a RELEASE message to SUT B.  (Also observe that SUT A sends a RELEASE COMPLETE message to Tester A.)
4.	Observe that SUT B sends a RELEASE COMPLETE message to SUT A.  (Also observe that SUT B sends a RELEASE message to Tester B.)
5.	Tester B sends a RELEASE COMPLETE message to SUT B.
6.	The final state is ((0,0),(0,0)).

Verdict Criteria:
Observe that SUT A sends RELEASE message to SUT B.  (Also observe that SUT A sends a RELEASE COMPLETE message to Tester A.)
- AND -
Observe that SUT B sends a RELEASE COMPLETE message to SUT A.  (Also observe that SUT B sends a RELEASE message to Tester B.)

6.	Test Case ID:	V5302REL006_USR
Test Purpose:	To verify that a call/connection can be released by destination user side after call/connection completion.
Reference:	6.5.3
Pre-requisite:
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((10,10),(10,10)).
2.	Tester B sends a RELEASE message to SUT B.
3.	Observe that SUT B sends a RELEASE message to SUT A.  (Also observe that SUT B sends a RELEASE COMPLETE message to Tester B.
4.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)
5.	Tester A sends a RELEASE COMPLETE message to SUT A.
6.	The final state is ((0,0),(0,0)).

Verdict Criteria:
Observe that SUT B sends a RELEASE message to SUT A.  (Also observe that SUT B sends a RELEASE COMPLETE message to Tester B.)
- AND -
Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)

7-12	Repeat Test cases 1 - 6 with the call initiated in the other direction.  Tester A, SUT A, SUT B, and Tester B are exchanged with Tester B, SUT B, SUT A, and Tester A; and the state notation is changed from ((s1,s2),(s3,s4)) to ((s4,s3),(s2,s1)).
5.3.3	
5.3.3	Releasing an SVC (SS_M)  Detailed for Test Configuration #3b

1.	Test Case ID:	V5303REL001_BFR
Test Purpose:	To verify that a call/connection can be released by originating user side before connection is established.
Reference:	6.5.3
Pre-requisite:
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is (9,(3,9)).
2.	Tester A sends a RELEASE message to SUT A.
3.	Observe that SUT A sends a RELEASE message to SUT B.  (Also observe that SUT A sends a RELEASE COMPLETE message to Tester A.)
4.	Observe that SUT B sends a RELEASE COMPLETE message to SUT A.  (Also observe that SUT B sends a RELEASE message to Tester B.)
5.	Tester B sends a RELEASE COMPLETE message to SUT B.
6.	The final state is (0,(0,0)).

Verdict Criteria:
Observe that SUT A sends a RELEASE message to SUT B.
- AND -
Observe that SUT B sends a RELEASE COMPLETE message to SUT A.  (Also observe that SUT B sends a RELEASE message to Tester B.) 

2.	Test Case ID:	V5303REL002_BFR
3.	Test Case ID:	V5303REL003_CNI,
4.	Test Case ID:	V5303REL004_DTL,
5.	Test Case ID:	V5303REL005_USR, and
6.	Test Case ID:	V5303REL006_USR,
are obtained from V5302REL002_BFR, V5302REL003_CNI, V5302REL004_DTL, V5302REL005_USR, and V5302REL006_USR, respectively, by following changes,
   1.	Replace states ((s1,s2),(s3,s4)) by (s2,(s3,s4)).
   2.	Replace Verdict Criteria of each Test Case by,

     "1.	Observe that SUT B sends a RELEASE message to SUT A.  (Also observe that SUT B sends a RELEASE COMPLETE message to Tester B). 
      2.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)"
      for the test V5303REL002_BFR,

     "1.	Observe that SUT B sends a RELEASE message to SUT A with crankback I.E.  (Also observe that SUT B sends a RELEASE COMPLETE message to Tester B).
      2.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)"
      for the tests V5303REL003_CNI and V5303REL004_DTL,

     "1.	Observe that SUT A sends a RELEASE message to SUT B.
      2.	Observe that SUT B sends a RELEASE COMPLETE to SUT A.   (Also observe that SUT B sends a RELEASE message to Tester B.)"
      for the test V5303REL005_USR, and

     "1.	Observe that SUT B sends a RELEASE message to SUT A.  (Also observe that SUT B sends a RELEASE COMPLETE message to Tester B).
      2.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)"
      for the test V5303REL006_USR.

7.	Test Case ID:	V5303REL007_BFR
Test Purpose:	To verify that a call/connection can be released by originating user side before connection is established.
Reference:	6.5.3
Pre-requisite:
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is (3,(9,3)).
2.	Tester B sends a RELEASE message to SUT B.
3.	Observe that SUT B sends a RELEASE message to SUT A.  (Also observe that SUT B sends a RELEASE COMPLETE message to Tester B.)
4.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)
5.	Tester A sends a RELEASE COMPLETE message to SUT A.
6.	The final state is (0,(0,0)).

Verdict Criteria:
Observe that SUT B sends a RELEASE message to SUT A.  (Also observe that SUT B sends a RELEASE COMPLETE message to Tester B.)
- AND -
Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)

8.	Test Case ID:	V5303REL008_BFR
9.	Test Case ID:	V5303REL009_USR, and
10.	Test Case ID:	V5303REL010_USR, 
are obtained from V5302REL002_BFR, V5302REL005_USR, and V5302REL006_USR, respectively, by following changes, 
   1. Replace Tester A, SUT A, SUT B and Tester B by Tester B, SUT B, SUT A and Tester A, respectively.
   2. Replace states ((s1,s2),(s3,s4)) by (s3,(s2,s1)).
   3. Replace Verdict Criteria of each test case by,

"1.	Observe that SUT A sends a RELEASE message to SUT B.
      2.	Observe that SUT B sends a RELEASE COMPLETE message to SUT A.  (Also observe that SUT B sends a RELEASE message to Tester B.)"
      for the test V5303REL008_BFR,

"1.	Observe that SUT B sends a RELEASE message to SUT A.  (Also observe that SUT B sends a RELEASE COMPLETE message to Tester B).
      2.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)"
      for the test V5303REL009_USR, and

"1.	Observe that SUT A sends a RELEASE message to SUT B.
      2.	Observe that SUT B sends a RELEASE COMPLETE message to SUT A.  (Also observe that SUT B sends a RELEASE message to Tester B.)"
      for the test V5303REL010_USR.
5.3.4	
5.3.4	Releasing an SVC (SS_M)  Detailed for Test Configuration #3c

1.	Test Case ID:	V5304REL001_BFR
Test Purpose:	To verify that a call/connection can be released by originating user side before connection is established. 
Reference:	6.5.3
Pre-requisite:
Test Configuration:	#3c

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (UNI) to SUT B.

Test Procedure:
1.	The initial state is (9,3).
2.	Tester A sends a RELEASE message to SUT A.
3.	Observe that SUT A sends a RELEASE message to SUT B.  (Also observe that SUT A sends a RELEASE COMPLETE message to Tester A.)
4.	Observe that SUT B sends a RELEASE COMPLETE message to SUT A.  (Also observe that SUT B sends a RELEASE message to Tester B.)
5.	Tester B sends a RELEASE COMPLETE to SUT B.
6.	The final state is (0,0).

Verdict Criteria:
Observe that SUT A sends a RELEASE message to SUT B.
- AND -
Observe that SUT B sends a RELEASE COMPLETE message to SUT A.  (Also observe that SUT B sends a RELEASE message to Tester B.)

2.	Test Case ID:	V5304REL002_BFR
3.	Test Case ID:	V5304REL003_USR, and
4.	Test Case ID:	V5304REL004_USR, 
are obtained from V5302REL002_BFR, V5302REL005_USR, and V5302REL006_USR, respectively, by following changes,
   1. Replace states ((s1,s2),(s3,s4)) by (s2,s3).
   2. Replace Verdict Criteria of each test case by,

"1.	Observe that SUT B sends a RELEASE message to SUT A.
2.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)"
      for the test V5304REL002_BFR,

"1.	Observe that SUT A sends a RELEASE message to SUT B.
2.	Observe that SUT B sends a RELEASE COMPLETE message to SUT A.  (Also observe that SUT B sends a RELEASE message to Tester B.)"
      for the test V5304REL003_USR, and

"1.	Observe that SUT B sends a RELEASE message to SUT A.
2.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)"
      for the test V5304REL004_USR.

5.4	5 - 8	Repeat Test Cases 1 - 4 with the call initiated in the other direction (i.e. from Tester B).  The state notation is changed from (s1,s2) to (s2,s1).
5.4	DTL Processing

To observe whether an SUT is generating or processing Designated Transit Lists (DTLs) correctly requires a lot of prior network configurations in order to influence the creation and processing of DTLs, so that DTL processing may be observed.

5.4.1	DTL processing an SVC

The test cases shown here reflect a minimal network configuration.  That is, given two ATM switches, either they are in the same peer group or different peer groups.  The first is where both SUTs are within the same peer group.  The second is where the SUTs are border nodes in different peer groups.

1.	Test Case ID:	V5401DTL001
Test Purpose:	To verify that two switches process DTLs correctly during call/connection setup when SUTs are in the same lowest level peer group.
Reference:	Annex A
Pre-requisite:	- PNNI routing complete,
- SUT A and SUT B are in the same peer group, and
- both SUTs are SS_M.
Test Configuration:	#3

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A to SUT A.
2b.	Connect Tester B to SUT B.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B.
2.	Monitor the PNNI Signalling channel (VPI/VCI=0/5) between SUT A and SUT B).
3.	Tester A sends a SETUP message to SUT A.
4a.	Observe that SUT A sends a SETUP message to SUT B.
4b.	Store the DTL for examination.
5.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  Also observe that SUT B sends a SETUP message to Tester B.

Verdict Criteria:
Observe that the only DTL in the SETUP message contains the node ID of SUT A and the node ID of SUT B with the current transit pointer set to point to the second element (i.e. SUT B).
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  Also observe that SUT B sends a SETUP message to Tester B.

2.	Test Case ID:	V5401DTL002
Test Purpose:	To verify that two switches process DTLs correctly during call/connection setup when SUTs are in two different lowest level peer groups.
Pre-requisite:	- PNNI routing complete,
- SUT A and SUT B are in different peer group, and
- both SUTs are at least SS_B,
- SUT A and SUT B have the same parent peer group,
- There are peer group leaders in SUT A's and SUT B's peer groups.
Reference:	Annex A
Test Configuration:	#3

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A to SUT A.
2b.	Connect Tester B to SUT B.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B.
2.	Monitor the PNNI Signalling channel (VPI/VCI=0/5) between SUT A and SUT B).
3.	Tester A sends a SETUP message to SUT A.
4a.	Observe that SUT A sends a SETUP message to SUT B.
4b.	Store the DTL for examination.
5.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  Also observe that SUT B sends a SETUP message to Tester B.

Verdict Criteria:
Observe that the only DTL in the SETUP message contains the node ID of the parent node of SUT A and the node ID of the parent node of SUT B, with the transit pointer set to the second element (i.e. the parent node of SUT B).
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  Also observe that SUT B sends a SETUP message to Tester B.
5.4.2	
5.4.2	DTL processing an SVC  Detailed for Test Configuration #3a

1.	Test Case ID:	V5402DTL001
Test Purpose:	To verify that two switches process DTLs correctly during call/connection setup as an entry border node and as an exit border node of the same peer group.
Reference:	Annex A
Pre-requisite:	SUT A is SS_B
SUT B is SS_B and SS_P.
 Arrange the topology state of switches SUT A and SUT B such that:
- When a call/connection flows from Tester A to Tester B,
- SUT A and SUT B belong to a same lowest level peer group,
- SUT A is an entry border node for the peer group, and
- SUT B is an exit border node for the peer group.
- SUT B is PGL.
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
3.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is ((3,9),(3,6)).

Verdict Criteria:
Observe that SUT A sends a SETUP message to SUT B.  Check that the SETUP message includes a new DTL for the lowest level with the current transit pointer pointing to the node ID of SUT B and includes a DTL for the next higher level with the current transit pointer pointing to the node ID of the lowest level peer group containing SUT A and SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.  Check that the SETUP does not include a DTL for the lowest level and includes at least one DTL for higher level.

2.	Test Case ID:	V5402DTL002
Test Purpose:	To verify that two switches process DTLs correctly during call/connection setup as an entry border node and as an intermediate node.
Reference:	Annex A
Pre-requisite:	SUT A is SS_B.
SUT B is SS_M.
Arrange the topology state of switches SUT A and SUT B such that:
- When a call/connection flows from Tester A to Tester B,
- SUT A, SUT B, and Tester B belong to the same lowest level peer group,
- SUT A is an entry border node for the peer group,
- SUT B is neither entry nor exit border node for the peer group, and
- Tester B is PGL.
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
3.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is ((3,9),(3,6)).

Verdict Criteria:
Observe that SUT A sends a SETUP message to SUT B.  Check that the SETUP includes a DTL for the lowest level with the current transit pointer pointing to the node ID of SUT B and includes a DTL for the next higher level with the current transit pointer pointing to the node ID of the lowest level peer group containing SUT A and SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.  Check that the SETUP include a DTL for the lowest level with the current transit pointer pointing to the node ID of Tester B and includes a DTL for the next higher level with the current transit pointer pointing to the node ID of the lowest level peer group containing SUT A and SUT B.)

3.	Test Case ID:	V5402DTL003
Test Purpose:	To verify that two switches process DTLs correctly during call/connection setup as an intermediate node and as an exit border node.
Reference:	Annex A
Pre-requisite:	SUT A is SS_M,
SUT B is SS_B,
Arrange the topology state of switches SUT A and SUT B such that:
- When a call/connection flows from Tester A to Tester B,
- Tester A, SUT A, and SUT B belong to the same lowest level peer group,
- SUT A is neither entry nor exit border node for the peer group,
- SUT B is an exit border node for the peer group, and
- Tester A is PGL.
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
3.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is ((3,9),(3,6)).

Verdict Criteria:
Observe that SUT A sends a SETUP message to SUT B.  Check that the SETUP includes a DTL for the lowest level with the current transit pointer pointing to the node ID of SUT B and includes a DTL for the next higher level with the current transit pointer pointing to the node ID of the lowest level peer group containing SUT A and SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends SETUP message to Tester B.  Check that the SETUP does not include a DTL for the lowest level and includes at least one DTL for higher level.)

4.	Test Case ID:	V5402DTL004
Test Purpose:	To verify that two switches process DTLs correctly during call/connection setup as intermediate nodes.
Reference:	Annex A
Pre-requisite:	SUT A and SUT B are both SS_M
Arrange the topology state of switches SUT A and SUT B such that:
- When a call/connection flows from Tester A to Tester B,
- Tester A, SUT A, SUT B, and Tester B belong to the same lowest level peer group, and
- SUT A and SUT B are neither entry nor exit border nodes for the peer group.
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
3.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is ((3,9),(3,6)).

Verdict Criteria:
Observe that SUT A sends a SETUP message to SUT B.  Check that the SETUP includes a DTL for the lowest level with the current transit pointer pointing to the node ID of SUT B. (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.  Check that the SETUP includes a DTL for the lowest level with the current transit pointer pointing to the node ID of Tester B.)

5.	Test Case ID:	V5402DTL005
Test Purpose:	To verify that two switches process DTLs correctly during call/connection setup as an exit border node and as an entry border node of different peer groups.
Reference:	Annex A
Pre-requisite:	Both SUT A and SUT B are SS_B,
Arrange the topology state of switches SUT A and SUT B such that :
- When a call/connection flows from Tester A to Tester B,
- SUT A and SUT B belong to two different peer groups at the lowest level,
- Tester A and SUT A belong to the same lowest level peer group with Tester A as PGL,
- SUT B and Tester B belong to the same lowest level peer group with Tester B as PGL,
- SUT A is an exit border node for one peer group, and
- SUT B is entry border node for the other peer group
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
3.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is ((3,9),(3,6)).

Verdict Criteria:
Observe that SUT A sends a SETUP message to SUT B.  Check that the SETUP does not include a DTL for the lowest level and includes at least one DTL for higher level. (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.  Check that the SETUP includes a new DTL for the lowest level with the current transit pointer pointing to the node ID of Tester B and includes a DTL for the next higher level with the current transit pointer pointing to the node ID of the lowest level peer group containing SUT B.)

6.	Test Case ID:	V5402DTL006
Test Purpose:	To verify that two switches process DTLs correctly as an intermediate node followed by an entry border node.
Reference:	Annex A
Pre-requisite:	SUT A is SS_N,
SUT B is SS_B,
Arrange the topology state of switches SUT A and SUT B such that:
- Tester B and SUT B belong to the same lowest level peer group, with PGL Tester B,
- Tester A and SUT A belong to the same lowest level peer group, which is the parent peer group of Tester B and SUT B.
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B
2.	Monitor the PNNI Signalling channel (VPI/VCI=0/5) between SUT A and SUT B.
3.	Tester A sends a SETUP message to SUT A.
4a.	Observe that SUT A sends a SETUP message to SUT B.
4b.	Store the DTL for examination.
5.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  Also observe that SUT B sends a SETUP message to Tester B and store the DTL for examination.

Verdict Criteria:
Observe that the only DTL in the SETUP message between the SUTs contains the node ID of Tester A, the node ID of SUT A, and the node ID of the parent node of SUT B, with the transit pointer set to point to the third element (i.e. the parent node of SUT B).
- AND -
Observe that SUT B sends a CALL PROCEDDING message to SUT A.  Also observe that SUT B sends a SETUP message to Tester B.  Observe that the DTL at the bottom of the DTL stack is identical to that originally received by SUT B, and that another DTL has been pushed on top of the stack.

7.	Test Case ID:	V5402DTL007
Test Purpose:	To verify that two switches process DTLs correctly as an exit border node followed by an intermediate node.
Reference:	Annex A
Pre-requisite:	SUT A is SS_N,
SUT B is SS_B,
Arrange the topology state of switches SUT A and SUT B such that:
- Tester B and SUT B belong to the same lowest level peer group, with PGL Tester B,
- Tester A and SUT A belong to the same lowest level peer group, which is the parent peer group of Tester B and SUT B.
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B
2.	Monitor the PNNI Signalling channel (VPI/VCI=0/5) between SUT A and SUT B.
3.	Tester B sends a SETUP message to SUT B.
4a.	Observe that SUT B sends a SETUP message to SUT A.
4b.	Store the DTL for examination.
5.	Observe that SUT A sends a CALL PROCEEDING message to SUT B.  Also observe that SUT A sends a SETUP message to Tester A and store the DTL for examination.

Verdict Criteria:
Observe that the only DTL in the SETUP message between the SUTs contains the node ID of the parent node of SUT B, the node ID of SUT A, and the node ID of Tester A, with the transit pointer set to point to the second element (i.e. SUT A).
- AND -
Observe that SUT A sends a CALL PROCEDDING message to SUT B.  Also observe that SUT A sends a SETUP message to Tester A.  Observe that the DTL sent by SUT A contains the same node IDs as in the DTL originally received by SUT A, but the current transit pointer now points to the third element (i.e. Tester A).
5.4.3	
5.4.3	DTL processing an SVC  Detailed for Test Configuration #3b

1.	Test Case ID:	V5403DTL001
Test Purpose:	To verify that two switches process DTLs correctly during call/connection setup as a DTL originator and as an entry border node of two different lowest level peer groups.
Reference:	Annex A
Pre-requisite:	SUT A is SS_B and SS_P,
SUT B is SS_B,
Arrange the topology state of switches SUT A and SUT B such that:
- SUT A and SUT B belong to different peer groups at the lowest level, and
- SUT B and Tester B belong to the same lowest level peer group with Tester B PGL.
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is (0,(0,0))
2.	Tester A sends a SETUP message to SUT A
3.	Observe that SUT A sends a SETUP message to SUT B.
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is (9,(3,6))

Verdict Criteria:
Observe that SUT A sends a SETUP message to SUT B.  Check that the SETUP message does not include a DTL for the lowest level and includes at least one DTL for higher level.
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.  Check that the SETUP includes a new DTL for the lowest level with the current transit pointer pointing to the node ID of Tester B and includes a DTL for the next higher level with the current transit pointer pointing to the node ID of the lowest level peer group containing SUT B.)

2.	Test Case ID:	V5403DTL002
Test Purpose:	To verify that two switches process DTLs correctly during call/connection setup as a DTL originator and as an exit border node of a same lowest level peer group.
Reference:	Annex A
Pre-requisite:	SUT A is SS_M
SUT B is SS_B and SS_P,
Arrange the topology state of switches SUT A and SUT B such that:
- SUT A and SUT B belong to the same lowest level peer group and SUT B is an exit border node for the group when a call flows from Tester A to Tester B, and
- SUT B is PGL.
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is (0,(0,0))
2.	Tester A sends a SETUP message to SUT A.
3.	Observe that SUT A sends a SETUP message to SUT B.
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is (9,(3,6))

Verdict Criteria:
Observe that SUT A sends a SETUP message to SUT B. Check that the SETUP includes a new DTL for the lowest level with the current transit pointer pointing to the node ID of SUT B and includes a DTL for the next higher level with the current transit pointer pointing to the node ID of the lowest level peer group containing SUT A and SUT B.
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.  Check that the SETUP does not include a DTL for the lowest level and includes at least one DTL for higher level.)

3.	Test Case ID:	V5403DTL003
Test Purpose:	To verify that two switches process DTLs correctly during call/connection setup as a DTL originator and as an intermediate node of the same lowest level peer group.
Reference:	Annex A
Pre-requisite:	SUT A and SUT B are both SS_M,
Arrange the topology state of switches SUT A and SUT B such that:
- SUT A and SUT B belong to the same peer group and SUT B is not an exit border node for the peer group when a call flows from Tester A to Tester B, and
- Tester B is PGL.
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is (0,(0,0))
2.	Tester A sends a SETUP message to SUT A.
3.	Observe that SUT A sends a SETUP to SUT B.
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	The final state is (9,(3,6))

Verdict Criteria:
Observe that SUT A sends a SETUP message to SUT B. Check that the SETUP includes a DTL for the lowest level with the current transit pointer pointing to the node ID of SUT B.
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.  Check that the SETUP include a DTL for the lowest level with the current transit pointer pointing to the node ID of Tester B.)

4.	Test Case ID:	V5403DTL004
Test Purpose:	To verify that two switches process DTLs correctly during call/connection setup as an exit border node and as a DTL terminator of two different lowest level peer groups.
Reference:	Annex A
Pre-requisite:	SUT A is SS_B and SS_P,
SUT B is SS_B,
Arrange the topology state of switches SUT A and SUT B such that:
- SUT A and SUT B belong to different peer groups at the lowest level, and
- SUT B and Tester B belong to the same lowest level peer group with Tester B as PGL.
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is (0,(0,0))
2.	Tester B sends a SETUP message to SUT B.
3.	Observe that SUT B sends a SETUP message to SUT A.  (Also observe that SUT B sends a CALL PROCEEDING message Tester B.)
4.	Observe that SUT A sends a CALL PROCEEDING message to SUT B.  (Also observe that SUT A sends a SETUP message to Tester A.)
5.	The final state is (3,(9,3))

Verdict Criteria:
Observe that SUT B sends a SETUP message to SUT A.  Check that the SETUP does not include a DTL for the lowest level and includes at least one DTL for higher level.  (Also observe that SUT B sends a CALL PROCEEDING message to Tester B.)
- AND -
Observe that SUT A sends a CALL PROCEEDING message to SUT B.  (Also observe that SUT A sends a SETUP message to Tester A.)

5.	Test Case ID:	V5403DTL005
Test Purpose:	To verify that two switches process DTLs correctly during call/connection setup as an entry border node and as a DTL terminator of a same lowest level peer group.
Reference:	Annex A
Pre-requisite:	SUT A is SS_M,
SUT B is SS_B and SS_P,
Arrange the topology state of switches SUT A and SUT B such that :
- SUT A and SUT B belong to the same lowest level peer group and SUT B is an entry border node for the group when a call flows from Tester B to Tester A, and
- SUT B is PGL.
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is (0,(0,0))
2.	Tester B sends a SETUP message to SUT B.
3.	Observe that SUT B sends a SETUP message to SUT A.  (Also observe that SUT B sends a CALL PROCEEDING message to Tester B.)
4.	Observe that SUT A sends a CALL PROCEEDING message to SUT B.  (Also observe that SUT A sends a SETUP message to Tester A.)
5.	The final state is (3,(9,3))

Verdict Criteria:
Observe that SUT B sends a SETUP message to SUT A.  Check that the SETUP includes a new DTL for the lowest level with the current transit pointer pointing to the node ID of SUT A and includes a DTL for the next higher level with the current transit pointer pointing to the node ID of the lowest level peer group containing SUT B and SUT A.  (Also observe that SUT B sends a CALL PROCEEDING message to Tester B.)
- AND -
Observe that SUT A sends a CALL PROCEEDING message to SUT B.  (Also observe that SUT A sends a SETUP message to Tester A.)

6.	Test Case ID:	V5403DTL006
Test Purpose:	To verify that two switches process DTLs correctly during call/connection setup as an intermediate node and as a DTL terminator of a same lowest level peer group.
Reference:	Annex A
Pre-requisite:	SUT A and SUT B are both SS_M,
Arrange the topology state of switches SUT A and SUT B such that:
- SUT A and SUT B belong to the same peer group and SUT B is an intermediate node for the peer group when a call flows from Tester B to Tester A, and
- Tester B is PGL.
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is (0,(0,0))
2.	Tester B sends a SETUP message to SUT B.
3.	Observe that SUT B sends a SETUP message to SUT A.  (Also observe that SUT B sends a CALL PROCEEDING message to Tester B.)
4.	Observe that SUT A sends a CALL PROCEEDING message to SUT B.  (Also observe that SUT A sends a SETUP message to Tester A.)
5.	The final state is (3,(9,3))

Verdict Criteria:
Observe that SUT B sends a SETUP message to SUT A.  Check that the SETUP includes a DTL for the lowest level with the current transit pointer pointing to the node ID of SUT A  (Also observe that SUT B sends a CALL PROCEEDING message to Tester B.)
- AND -
Observe that SUT A sends a CALL PROCEEDING message to SUT B.  (Also observe that SUT A sends a SETUP message to Tester A.)

7.	Test Case ID:	V5403DTL007
Test Purpose:	To verify that two switches process DTLs correctly as an originating node that is not an exit border node followed by an entry border node.
Reference:	Annex A
Pre-requisite:	SUT A is SS_N,
SUT B is SS_B,
Arrange the topology state of switches SUT A and SUT B such that:
- Tester B and SUT B belong to the same lowest level peer group, with PGL Tester B,
- SUT A's lowest level peer group is the parent peer group of Tester B and SUT B.
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B
2.	Monitor the PNNI Signalling channel (VPI/VCI=0/5) between SUT A and SUT B.
3.	Tester A sends a SETUP message to SUT A.
4a.	Observe that SUT A sends a SETUP message to SUT B.
4b.	Store the DTL for examination.
5.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  Also observe that SUT B sends a SETUP message to Tester B and store the DTL for examination.
Verdict Criteria:
Observe that the only DTL in the SETUP message between the SUTs contains the node ID of SUT A and the node ID of the parent node of SUT B, with the transit pointer set to point to the second element (i.e. the parent node of SUT B).
- AND -
Observe that SUT B sends a CALL PROCEDDING message to SUT A.  Also observe that SUT B sends a SETUP message to Tester B.  Observe that the DTL at the bottom of the DTL stack is identical to that originally received by SUT B, and that another DTL has been pushed on top of the stack.
5.4.4	
5.4.4	DTL processing an SVC Detailed for Test Configuration #3c

1.	Test Case ID:	V5404DTL001
Test Purpose:	To verify that two switches process DTLs correctly during call/connection setup as a DTL originator and as a DTL terminator of two different lowest level peer groups.
Pre-requisite:	- PNNI routing complete,
- both SUTs are SS_B and SS_P,
- SUT A and SUT B are in different peer group, and
- both SUTs are PGLs with the same parent peer group.
Reference:	Annex A
Test Configuration:	#3c

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (UNI) to SUT B.

Test Procedure:
1.	The initial state is (0,0).
2.	PNNI Routing has completed between SUT A and SUT B.
3.	Monitor the PNNI Signalling channel (VPI/VCI=0/5) between SUT A and SUT B).
4.	Tester A sends a SETUP message to SUT A.
5a.	Observe that SUT A sends a SETUP message to SUT B.
5b.	Store the DTL for examination.
6.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  Also observe that SUT B sends a SETUP message to Tester B.
7.	The final state is (9,3).

Verdict Criteria:
Observe that the only DTL in the SETUP message contains the node ID of the parent node of SUT A and the node ID of the parent node of SUT B, with the transit pointer set to the second element (i.e. the parent node of SUT B).
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  Also observe that SUT B sends a SETUP message to Tester B.

2.	Test Case ID:	V5404DTL002
Test Purpose:	To verify that two switches process DTLs correctly during call/connection setup as a DTL originator and as a DTL terminator of a same lowest level peer group.
Reference:	Annex A
Pre-requisite:	- PNNI routing complete,
- SUT A and SUT B are is the same peer group, and
- both SUTs are SS_M.
Test Configuration:	#3c

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (UNI) to SUT B.

Test Procedure:
1.	The initial state is (0,0).
2.	PNNI Routing has completed between SUT A and SUT B.
3.	Monitor the PNNI Signalling channel (VPI/VCI=0/5) between SUT A and SUT B).
4.	Tester A sends a SETUP message to SUT A.
5a.	Observe that SUT A sends a SETUP message to SUT B.
5b.	Store the DTL for examination.
6.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  Also observe that SUT B sends a SETUP message to Tester B.
7.	The final state is (9,3).

Verdict Criteria:
Observe that the only DTL in the SETUP message contains the node ID of SUT A and the node ID of SUT B with the current transit pointer set to point to the second element (i.e. SUT B).
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  Also observe that SUT B sends a SETUP message to Tester B.

5.5	3 - 4	Repeat Test Cases 1 - 2 with the call initiated in the other direction (i.e. from Tester B).  The state notation is changed from (s1,s2) to (s2,s1).
5.5	Crankback Processing

Crankback processing may not be possible for interoperability testing, since it is necessary to control the SUT that will initiate crankback.  However, when a call is not able to be established (i.e. a test case from the establishment section fails), the RELEASE or RELEASE COMPLETE message should be examined to determine whether a crankback IE is included.

5.5.1	Crankback processing on an SVC (SS_M)

These are not test cases, but are listed as examples.

1.	Test Case ID:	V5501CRK001(Failure of V5201EST012)
{Note: Test Case V5201EST012 failed because a CALL PROCEEDING message was not sent from SUT B to SUT A.}
Test Purpose:	Verify that SUT B includes a Crankback IE in a RELEASE COMPLETE message.
Pre-requisite:	PNNI Routing has completed
Reference:	Annex B & 6.5.2.3
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B.
2.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
3.	Tester A sends a SETUP message to SUT A.
4.	Observe that a SETUP message is sent from SUT A to SUT B.  (Also observe that a CALL PROCEEDING message is sent from SUT A to Tester A.)

Verdict Criteria:
Observe a RELEASE COMPLETE message with a Crankback IE from SUT B to SUT A.

2.	Test Case ID:	V5501CRK002(Failure of V5201EST012)
{Note: In Test Case V5201EST012, it failed to observe a SETUP message sent from SUT B to Tester B.}
Test Purpose:	Verify that SUT B includes a Crankback IE in a RELEASE message.
Pre-requisite:	PNNI Routing has completed
Reference:	Annex B & 6.5.2.3
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B.
2.	Monitor the PNNI (VPI/VCI=0/5) between SUT A and SUT B.
3.	Tester A sends a SETUP message to SUT A.
4.	Observe that a SETUP message is sent from SUT A to SUT B.  (Also observe that a CALL PROCEEDING message is sent from SUT A to Tester A.)
5.	Observe that a CALL PROCEEDING message is sent from SUT B to SUT A.

Verdict Criteria:
Observe a RELEASE message with a Crankback IE from SUT B to SUT A.
5.5.2	
5.5.2	Crankback processing on an SVC (SS_M)  Detailed for Test Configuration #3a

1.	Test Case ID:	V5502CRK001
Test Purpose:	To verify two switches, as an entry border node and as an exit border node, perform crankback procedure correctly when there is no alternate route.
Reference:	6.5.3, Annex B.

Pre-requisite:	- Arrange the topology state of switches SUT A and SUT B such that when a call/connection flows from Tester A to Tester B, 
- SUT A and SUT B belong to the same lowest level peer group,
- SUT A is an entry border node for the peer group,
- SUT B is an exit border node for the peer group, and
- there is no alternate route from SUT A to the next destination at any hierarchical level.
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
3.	Observe that SUT A sends a SETUP message to SUT B. (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	Tester B sends a RELEASE COMPLETE message to SUT B.
[The RELEASE COMPLETE message contains Crankback I.E. whose crankback level is higher than lowest level and blocked transit type is either "blocked node" or "blocked link."]
6.	Observe that SUT B sends a RELEASE message to SUT A.
7.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)
8.	The final state is ((0,0),(0,0)).

Verdict Criteria:
Observe that SUT B sends a RELEASE message to SUT A that contains Crankback I.E. whose crankback level is the same as received in the RELEASE COMPLETE message.
- AND -
Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A with Crankback I.E. whose crankback level is no less than that of the received RELEASE message.)

2.	Test Case ID:	V5502CRK002
Test Purpose:	To verify two switches, as an entry border node and as an intermediate node, perform crankback procedure correctly when there is no alternate route.
Reference:	6.5.3, Annex B.
Pre-requisite:	-Arrange the topology state of switches SUT A and SUT B such that when a call/connection flows from Tester A to Tester B,
- SUT A, SUT B, and Tester B belong to the same lowest peer group,
- SUT A is entry border node, and
- There is no alternate route from SUT A to the next destination at any hierarchical level.
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
3.	Observe that SUT A sends a SETUP to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP to Tester B.)
5.	Tester B sends a RELEASE COMPLETE message to SUT B.
[The RELEASE COMPLETE message contains Crankback I.E. whose crankback level is lowest level and blocked transit type is either "blocked node" or "blocked link".]
6.	Observe that SUT B sends a RELEASE message to SUT A.
7.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)
8.	Tester A sends a RELEASE COMPLETE message to SUT A.
9.	The final state is ((0,0),(0,0)).

Verdict Criteria:
Observe that SUT B sends a RELEASE message to SUT A that contains Crankback I.E. whose crankback level is lowest level.
- AND -
Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A that contains Crankback I.E. whose crankback level is higher than lowest level.)

3.	Test Case ID:	V5502CRK003
Test Purpose:	To verify two switches, as an intermediate node and as an exit border node, perform crankback procedure correctly when there is no alternate route.
Reference:	6.5.3, Annex B.

Pre-requisite:	- Arrange the topology state of switches SUT A and SUT B such that when a call/connection flows from Tester A to Tester B,
- Tester A, SUT A and SUT B belong to the same lowest level peer group,
- SUT B is an exit border node for the peer group, and
- there is no alternate route from SUT A to the next destination at any hierarchical level.
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
3.	Observe that SUT A sends a SETUP message to SUT B. (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	Tester B sends a RELEASE COMPLETE message to SUT B.
[The RELEASE COMPLETE message contains Crankback I.E. whose crankback level is higher than lowest level and blocked transit type is either "blocked node" or "blocked link."]
6.	Observe that SUT B sends a RELEASE message to SUT A.
7.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)
8.	The final state is ((0,0),(0,0)).

Verdict Criteria:
Observe that SUT B sends a RELEASE message to SUT A that contains Crankback I.E. whose crankback level is the same as received in the RELEASE COMPLETE message.
- AND -
Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A with Crankback I.E. whose crankback level is the same as received in the RELEASE message.)

4.	Test Case ID:	V5502CRK004
Test Purpose:	To verify two switches, as intermediate nodes, perform crankback procedure correctly when there is no alternate route.
Reference:	6.5.3, Annex B.

Pre-requisite:	- Arrange the topology state of switches SUT A and SUT B such that when a call/connection flows from Tester A to Tester B,
- Tester A, SUT A, SUT B, and Tester B belong to the same lowest level peer group,
- there is no alternate route from SUT A to the next destination at any hierarchical level.
Test Configuration:	#3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
3.	Observe that SUT A sends a SETUP message to SUT B. (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	Tester B sends a RELEASE COMPLETE message to SUT B.
[The RELEASE COMPLETE message contains Crankback I.E. whose crankback level is lowest level and blocked transit type is either "blocked node" or "blocked link."]
6.	Observe that SUT B sends a RELEASE message to SUT A.
7.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)
8.	The final state is ((0,0),(0,0)).

Verdict Criteria:
Observe that SUT B sends a RELEASE message to SUT A that contains Crankback I.E. whose crankback level is lowest level.
- AND -
Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A with Crankback I.E. whose crankback level is lowest level.)

5.	Test Case ID:	V5502CRK005
Test Purpose:	To verify two switches, as an exit border node and as an entry border node, perform crankback procedure correctly when there is no alternate route.
Reference:	6.5.3, Annex B.
Pre-requisite:	- Arrange the topology state of switches SUT A and SUT B such that when a call/connection flows from Tester A to Tester B,
- SUT A and SUT B belong to two different lowest level peer groups,
- SUT A is an exit border node for one peer group,
- SUT B is entry border node for the other peer group, and
- there is no alternate route from SUT B to the next destination at any hierarchical level.
Test Configuration: #3a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is ((0,0),(0,0)).
2.	Tester A sends a SETUP message to SUT A.
3.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	Tester B sends a RELEASE COMPLETE message to SUT B.
[The RELEASE COMPLETE message contains Crankback I.E. whose crankback level is lowest level and blocked transit type is either "blocked node" or "blocked link".]
6.	Observe that SUT B sends a RELEASE message to SUT A.
7.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)
8.	The final state is ((0,0),(0,0)).

Verdict Criteria:
Observe that SUT B sends a RELEASE message to SUT A that contains Crankback I.E. whose crankback level is higher than lowest level.
- AND -
Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A with Crankback I.E. whose crankback level is the same as received in the RELEASE message.)

6-10	Repeat Test cases 1 - 5 with the call initiated in the other direction.  Tester A, SUT A, SUT B, and Tester B are exchanged with Tester B, SUT B, SUT A, and Tester A; and the state notation is changed from ((s1,s2),(s3,s4)) to ((s4,s3),(s2,s1)).
5.5.3	
5.5.3	Crankback processing on an SVC (SS_M)  Detailed for Test Configuration #3b

1.	Test Case ID:	V5503CRK001
Test Purpose:	To verify two switches, as a DTL originator and as an entry border node, perform crankback procedure correctly when there is no alternate route.
Reference:	6.5.3, Annex B.
Pre-requisite:	- Arrange the topology state of switches SUT A and SUT B such that when a call/connection flows from Tester A to Tester B,
- SUT A and SUT B belong to two different lowest level peer groups,
- SUT B is an entry border node for its peer group, and
- There is no alternate route from SUT B to the next destination at any hierarchical level.
- There is no alternate route from SUT A to the next destination at any hierarchical level.
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

	Test Procedure:
1.	The initial state is (0,(0,0)).
2.	Tester A sends a SETUP message to SUT A.
3.	Observe that SUT A sends a SETUP message to SUT B.
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	Tester B sends a RELEASE COMPLETE message to SUT B.
[The RELEASE COMPLETE message contains Crankback I.E. whose crankback level is the lowest level and blocked transit type is either "blocked node" or "blocked link".]
6.	Observe that SUT B sends a RELEASE message to SUT A. 
7.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)
8.	The final state is (0,(0,0)).

Verdict Criteria:
Observe that SUT B sends a RELEASE message to SUT A. Check that the RELEASE message contains Crankback I.E. whose crankback level is higher than the lowest level.
- AND -
Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)

2.	Test Case ID:	V5503CRK002
Test Purpose:	To verify two switches, as a DTL originator and as an exit border node, perform crankback procedure correctly when there is no alternate route.
Reference:	6.5.3, Annex B.
Pre-requisite:	- Arrange the topology state of switches SUT A and SUT B such that when a call/connection flows from Tester A to Tester B,
- SUT A and SUT B belong to the same lowest level peer group,
- SUT B is an exit border node for the lowest level peer group, and,
- There is no alternate route from SUT A to the next destination at any hierarchical level.
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is (0,(0,0)).
2.	Tester A sends a SETUP message to SUT A.
3.	Observe that SUT A sends a SETUP message to SUT B.
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	Tester B sends a RELEASE COMPLETE message to SUT B.
[The RELEASE COMPLETE message contains Crankback I.E. whose crankback level is higher than the lowest level and blocked transit type is either "blocked node" or "blocked link."]
6.	Observe that SUT B sends a RELEASE message to SUT A.
7.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)
8.	The final state is (0,(0,0)).

Verdict Criteria:
Observe that SUT B sends a RELEASE message to SUT A.  Check that the RELEASE message contains a Crankback I.E. whose crankback level is the same as received in the RELEASE COMPLETE message.
- AND -
Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)

3.	Test Case ID:	V5503CRK003
Test Purpose:	To verify two switches, as DTL originator and as an intermediate node, perform crankback procedure correctly when there is no alternate route.
Reference:	6.5.3, Annex B.
Pre-requisite:	- Arrange the topology state of switches SUT A and SUT B such that when a call/connection flows from Tester A to Tester B,
- SUT A, SUT B, and Tester B belong to the same lowest level peer group, and
- There is no alternate route from SUT A to the next destination at any hierarchical level.
Test Configuration:	#3b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B.

Test Procedure:
1.	The initial state is (0,(0,0)).
2.	Tester A sends a SETUP message to SUT A.
3.	Observe that SUT A sends a SETUP message to SUT B.
4.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.	Tester B sends a RELEASE COMPLETE message to SUT B.
[The RELEASE COMPLETE message contains Crankback I.E. whose crankback level is lowest level and blocked transit type is either "blocked node" or "blocked link".]
6.	Observe that SUT B sends a RELEASE message to SUT A.
7.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)
8.	The final state is (0,(0,0)).

Verdict Criteria:
Observe that SUT B sends a RELEASE to SUT A.  Check that the RELEASE message contains a Crankback I.E. whose crankback level is the lowest level.
- AND -
Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)
5.5.4	
5.5.4	Crankback processing on an SVC (SS_M)  Detailed for Test Configuration #3c

5.5.5	Not applicable for this Test Configuration.
5.5.5	Crankback processing on an SVC (SS_M)  Detailed for Test Configuration #4a

Test Cases in this section require so much configuration that figures are provided to complete the Pre-requisite section for each Test Case.

1.	Test Case ID:	V5505CRK001
Test Purpose:	To verify two switches, as an entry border node and as an intermediate node, perform crankback procedure correctly when there is an alternate route and crankback level matches.
Reference:	6.5.3, Annex B.
Pre-requisite:	- see figure 5.5.5-1 for the configuration information.

Figure 5.5.5-1
Test Configuration:	#4a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B with two physical links.

Test Procedure:
1.	Tester A sends a SETUP message to SUT A.
2.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
3.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
4.	Tester B sends a RELEASE COMPLETE message to SUT B.
[The RELEASE COMPLETE message contains Crankback I.E. whose crankback level is lowest level and blocked transit type is either "blocked node" or "blocked link."]
5.	Observe that SUT B sends a RELEASE message to SUT A.
6a.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  
6b.	Observe that SUT A sends a SETUP message to SUT B.
7.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)

Verdict Criteria:
Observe that SUT B sends a RELEASE message to SUT A that contains Crankback I.E. whose crankback level is lowest level.
- AND -
Observe that SUT A sends a RELEASE COMPLETE message and a SETUP message to SUT B.  (Also observe that no RELEASE message is transmitted from SUT A to Tester A during the steps 6a, 6b and 7.) 
- AND -
Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)

2.	Test Case ID:	V5505CRK002
Test Purpose:	To verify two switches, as an entry border node and as an intermediate node, relay crankback message correctly when there is an alternate route and crankback level mismatches.
Reference:	6.5.3, Annex B.
Pre-requisite:	- see figure 5.5.5-1 for the configuration information.
Test Configuration:	#4a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B with two physical links.

Test Procedure:
1.	Tester A sends a SETUP message to SUT A.
2.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
3.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
4.	Tester B sends a RELEASE COMPLETE message to SUT B.
[The RELEASE COMPLETE message contains Crankback I.E. whose crankback level is higher than the lowest level and blocked transit type is either "blocked node" or "blocked link."]
5.	Observe that SUT B sends a RELEASE message to SUT A.
6.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)
7.	Tester A sends a RELEASE COMPLETE message to SUT A.

Verdict Criteria:
Observe that SUT B sends a RELEASE message to SUT A that contains Crankback I.E. whose crankback level is the same as received in the RELEASE COMPLETE message.
- AND -
Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A with Crankback I.E. whose crankback level is no less than that of the received RELEASE message.)

3.	Test Case ID:	V5505CRK003
Test Purpose:	To verify two switches, as two intermediate nodes, relay crankback message correctly even when there is an alternate route and crankback level matches.
Reference:	6.5.3, Annex B.
Pre-requisite:	- see figure 5.5.5-2 for the configuration information.

Figure 5.5.5-2

Test Configuration:	#4a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B with two physical links.

Test Procedure:
1.	Tester A sends a SETUP message to SUT A.
2.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
3.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
4.	Tester B sends a RELEASE COMPLETE message to SUT B.
[The RELEASE COMPLETE message contains Crankback I.E. whose crankback level is lowest level and blocked transit type is either "blocked node" or "blocked link."]
5.	Observe that SUT B sends a RELEASE message to SUT A.
6.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)
7.	Tester A sends a RELEASE COMPLETE message to SUT A.

Verdict Criteria:
Observe that SUT B sends a RELEASE message to SUT A that contains Crankback I.E. whose crankback level is lowest level.
- AND -
Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A that contains Crankback I.E. whose crankback level is lowest level.)

4.	Test Case ID:	V5505CRK004
Test Purpose:	To verify two switches, as an exit border node and as an entry border node, relay crankback message correctly when there is an alternate route and crankback level mismatches for the entry border node.
Reference:	6.5.3, Annex B.
Pre-requisite:	- see figure 5.5.5-3 for the configuration information.

Figure 5.5.5-3

Test Configuration:	#4a

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (PNNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B with two physical links.

Test Procedure:
1.	Tester A sends a SETUP message to SUT A.
2.	Observe that SUT A sends a SETUP message to SUT B.  (Also observe that SUT A sends a CALL PROCEEDING message to Tester A.)
3.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
4.	Tester B sends a RELEASE COMPLETE message to SUT B.
[The RELEASE COMPLETE message contains Crankback I.E. whose crankback level is higher than the lowest level of SUT B and blocked transit type is either "blocked node" or "blocked link."]
5.	Observe that SUT B sends a RELEASE message to SUT A.
6.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A.)
7.	Tester A sends a RELEASE COMPLETE message to SUT A.

Verdict Criteria:
Observe that SUT B sends a RELEASE message to SUT A that contains Crankback I.E. whose crankback level is no less than that of the received RELEASE COMPLETE message.
- AND -
5.5.6	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  (Also observe that SUT A sends a RELEASE message to Tester A with Crankback I.E. whose crankback level is the same as received in the RELEASE message.)
5.5.6	Crankback processing on an SVC (SS_M)  Detailed for Test Configuration #4b

The Test Case in this section requires so much configuration that a figure is provided to complete the Pre-requisite section this Test Case.

1.	Test Case ID:	V5506CRK001
Test Purpose:	To verify two switches, as a DTL originator and as an intermediate node, perform crankback procedure correctly when there is an alternate route and crankback level matches.
Reference:	6.5.3, Annex B.
Pre-requisite:	- see figure 5.5.5-4 for the configuration information.

Figure 5.5.5-4

Test Configuration:	#4b

Test Set-up:
1.	Connect the two SUTs with one physical link.
2a.	Connect Tester A (UNI) to SUT A.
2b.	Connect Tester B (PNNI) to SUT B with two physical links.

Test Procedure:
1.	Tester A sends a SETUP message to SUT A.
2.	Observe that SUT A sends a SETUP message to SUT B.
3.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
4.	Tester B sends a RELEASE COMPLETE message to SUT B.
[The RELEASE COMPLETE message contains Crankback I.E. whose crankback level is lowest level (i.e., the level of PG(I)) and blocked transit type is either "blocked node" or "blocked link."]
5.	Observe that SUT B sends a RELEASE message to SUT A.
6a.	Observe that SUT A sends a RELEASE COMPLETE message to SUT B.  
6b.	Observe that SUT A sends a SETUP message to SUT B.
7.	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)

Verdict Criteria:
Observe that SUT B sends a RELEASE message to SUT A that contains Crankback I.E. whose crankback level is lowest level.
- AND -
Observe that SUT A sends a RELEASE COMPLETE and a SETUP message to SUT B.  (Also observe that no RELEASE message is transmitted from SUT A to Tester A during the steps 6a, 6b and 7.) 
- AND -
5.6	Observe that SUT B sends a CALL PROCEEDING message to SUT A.  (Also observe that SUT B sends a SETUP message to Tester B.)
5.6	Test Cases Dynamic Behavior (Point-to-Multipoint)

Most of the test cases for point-to-multipoint require SUTs to have multiple UNIs or PNNIs in order to observe multiple call/connections establishments.

5.6.1	Setup of the initial party (SS_M)

1.	Test Case ID:	V5601P2M001
Test Purpose:	Verify that a SETUP message is sent from SUT A to SUT B with an endpoint reference IE, Broadband bearer capability IE set to point-to-multipoint, and no OAM traffic descriptor IE.
Reference:	6.6.1
Pre-requisite:	Completed PNNI routing
Test Configuration:	#3a,b, or c

Test Set-up:
1.	Connect two SUTs with one physical link.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B.
2	Monitor signalling (VPI/VCI=0/5) between SUT A and SUT B.
3.	Tester A (root) sends a SETUP (multipoint) to SUT A.

Verdict Criteria:
Observe that a SETUP message is sent from SUT A to SUT B with an endpoint reference IE, Broadband bearer capability IE set to point-to-multipoint, and no OAM traffic descriptor IE.

2.	Test Case ID:	V5601P2M002
Test Purpose:	Verify that a CALL PROCEEDING message is sent from SUT B to SUT A with an endpoint reference IE.
Reference:	6.6.1
Pre-requisite:	Completed PNNI routing
Test Configuration:	#3a,b, or c

Test Set-up:
1.	Connect two SUTs with one physical link.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B.
2.	Monitor signalling (VPI/VCI=0/5) between SUT A and SUT B.
3.	Tester A (root) sends a SETUP (multipoint) to SUT A.
4.	Observe that a SETUP message is sent from SUT A to SUT B with an endpoint reference IE, Broadband bearer capability IE set to point-to-multipoint, and no OAM traffic descriptor IE.

Verdict Criteria:
Observe that a CALL PROCEEDING message is sent from SUT B to SUT A with an endpoint reference IE.  (Also a SETUP message is sent to Tester B.)

3.	Test Case ID:	V5601P2M003
Test Purpose:	Verify that an ALERTING message is sent from SUT B to SUT A with an endpoint reference IE.
Reference:	6.6.1
Pre-requisite:	Completed PNNI routing
Test Configuration:	#3a, b, or c

Test Set-up:
1.	Connect two SUTs with one physical link.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B.
2.	Monitor signalling (VPI/VCI=0/5) between SUT A and SUT B.
3.	Tester A (root) sends a SETUP (multipoint) to SUT A.
4.	Observe that a SETUP message is sent from SUT A to SUT B with an endpoint reference IE, Broadband bearer capability IE set to point-to-multipoint, and no OAM traffic descriptor IE.
5.	Observe that a CALL PROCEEDING message is sent from SUT B to SUT A with an endpoint reference IE.
6.	Observe that a SETUP message is sent to Tester B.
7.	Tester B sends an CALL PROCEEDING message to SUT B.
8.	Tester B sends an ALERTING message to SUT B.

Verdict Criteria:
Observe that an ALERTING message is sent from SUT B to SUT A with an endpoint reference IE.

4.	Test Case ID:	V5601P2M004
Test Purpose:	Verify that a CONNECT message is sent from SUT B to SUT A with an endpoint reference IE.
Reference:	6.6.1
Pre-requisite:	Completed PNNI routing
Test Configuration:	#3a, b, or c

Test Set-up:
1.	Connect two SUTs with one physical link.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B.
2.	Monitor signalling (VPI/VCI=0/5) between SUT A and SUT B.
3.	Tester A (root) sends a SETUP (multipoint) to SUT A.
4.	Observe that a SETUP message is sent from SUT A to SUT B with an endpoint reference IE, Broadband bearer capability IE set to point-to-multipoint, and no OAM traffic descriptor IE.
5.	Observe that a CALL PROCEEDING message is sent from SUT B to SUT A with an endpoint reference IE.
6.	Observe that a SETUP message is sent to Tester B.
7.	Tester B sends a CALL PROCEEDING message to SUT B.
8.	Tester B sends a CONNECT message to SUT B.

Verdict Criteria:
Observe that a CONNECT message is sent from SUT B to SUT A with an endpoint reference IE.
5.6.2	
5.6.2	Adding a party (SS_M)

1.	Test Case ID:	V5602P2M001
Test Purpose:	Verify that an ADD PARTY message is sent from SUT A to SUT B to add another party to the existing point-to-multipoint call.
Reference:	6.6.2
Pre-requisite:	- Completed PNNI routing and
- passed Test Case V5601P2M004 (i.e. initial call set up).
Test Configuration:	#3a, b, or c

Test Set-up:
1.	Connect two SUTs with one physical link.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B.
2.	Monitor signalling (VPI/VCI=0/5) between SUT A and SUT B.
3.	Complete Test Case V5601P2M004 and store the endpoint reference IE.
4.	Tester A (root) sends an ADD PARTY (multipoint) to SUT A.

Verdict Criteria:
Observe that an ADD PARTY message is sent from SUT A to SUT B with an endpoint reference IE equal to the stored value, Broadband bearer capability IE set to point-to-multipoint, and no OAM traffic descriptor IE.

2.	Test Case ID:	V5602P2M002
Test Purpose:	Verify that an ADD PARTY ACKNOWLEDGE message is sent from SUT B to SUT A to acknowledge another party being added to the existing point-to-multipoint call.
Reference:	6.6.2
Pre-requisite:	- Completed PNNI routing and
- passed Test Case V5601P2M004 (i.e. initial call set up)
Test Configuration:	#3a, b, or c

Test Set-up:
1.	Connect two SUTs with one physical link.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B.
2.	Monitor signalling (VPI/VCI=0/5) between SUT A and SUT B.
3.	Complete Test Case V5601P2M004 and store the endpoint reference IE.
4.	Tester A (root) sends an ADD PARTY (multipoint) to SUT A.
5.	Observe that an ADD PARTY message is sent from SUT A to SUT B with an endpoint reference IE equal to the stored value.
6.	Observe that an ADD PARTY message is sent from SUT B to Tester B.
7.	Tester B sends an ADD PARTY ACKNOWLEDGE message to SUT B.

Verdict Criteria:
Observe that an ADD PARTY ACKNOWLEDGEMENT message is sent from SUT B to SUT A with an endpoint reference IE equal to the stored value.  (Also observe that an ADD PARTY ACKNOWLEDGEMENT message is sent from SUT A to Tester A with an endpoint reference IE equal to the stored value.)
5.6.3	
5.6.3	Party dropping (SS_M)

1.	Test Case ID:	V5603P2M001
Test Purpose:	Verify that a party is dropped by sending a DROP PARTY message.
Reference:	6.6.3
Pre-requisite:	- Completed PNNI routing and
- completed Test Case V5602P2M002 (i.e. at least three parties in the call)
Test Configuration:	#3a, b, or c

Test Set-up:
1.	Connect two SUTs with one physical link.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B.
2.	Monitor signalling (VPI/VCI=0/5) between SUT A and SUT B.
3.	Complete Test Case V5601P2M004 and store the endpoint reference IE.
4.	Complete Test Case V5602P2M002 and store the endpoint reference IE.
5.	Tester A (root) sends an DROP PARTY message to SUT A.

Verdict Criteria:
Observe that a DROP PARTY message is sent from SUT A to SUT B with an endpoint reference IE equal to the stored value.

2.	Test Case ID:	V5603P2M002
Test Purpose:	Verify that a party dropped from the call is acknowledged by sending a DROP PARTY ACKNOWLEDGE message.
Reference:	6.6.3
Pre-requisite:	- Completed PNNI routing and
- completes Test Case V5602P2M002 (i.e. at least three parties in the call)
Test Configuration:	#3a, b, or c

Test Set-up:
1.	Connect two SUTs with one physical link.

Test Procedure:
1.	PNNI Routing has completed between SUT A and SUT B.
2.	Monitor signalling (VPI/VCI=0/5) between SUT A and SUT B.
3.	Complete Test Case V5601P2M004 and store the endpoint reference IE.
4.	Complete Test Case V5602P2M002 and store the endpoint reference IE.
5.	Tester A (root) sends an DROP PARTY message to SUT A.
6.	Observe that a DROP PARTY message is sent from SUT A to SUT B with an endpoint reference IE equal to the stored value.
7.	Observe that a DROP PARTY message is sent from SUT B to Tester B with an endpoint reference IE equal to the stored value.
8.	Tester B sends a DROP PARTY ACKNOWLEDGE message to SUT B.

Verdict Criteria:
Observe that a DROP PARTY ACKNOWLEDGE message is sent from SUT B to SUT A with an endpoint reference IE equal to the stored value.  (Also observe that a DROP PARTY ACKNOWLEDGE message is sent from SUT A to Tester A.)