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-670

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	57
4.5.1  Flooding	57
4.6	Peer Group Leader Election	59
4.6.1  For the Peer Group Leader Election (not PGL capable)	59
4.6.2	  For the Peer Group Leader Election (one SUT is PGL 
capable)	64
4.6.3	  For the Peer Group Leader Election (Both SUTs are PGL 
capable)	74
4.7	Border Node / PGL Interactions	78
4.7.1  Border Node / PGL Interactions	78
4.8	Logical Group Node	81
4.8.1   Logical Group Node (SVCC-Based RCC establishment)	81
4.8.2   Logical Group Node (Hello Protocol)	91
4.8.3   	Logical Group Node (Feeding Information Down the 
Hierarchy)	94

5	Interoperability Interface Tests (Signalling)	96
5.1	Test Case Index	97
5.2	Test Cases Dynamic Behavior (Point-to-Point)	116
5.2.1   Establishing an SVC (SS_M)	116
5.2.2	   Establishing an SVC (SS_M)  Detailed for Test 
Configuration #3a	121
5.2.2.1   	Optional tests for Establishment: Negotiation of ATM 
traffic descriptors (OPT_5)	135
5.2.3	   Establishing an SVC (SS_M)  Detailed for Test 
Configuration #3b	147
5.2.3.1   	Optional tests for Establishment: Negotiation of ATM 
traffic descriptors (OPT_5)	153
5.2.4	   Establishing an SVC (SS_M)  Detailed for Test 
Configuration #3c	157
5.3	Release	160
5.3.1   Releasing an SVC (SS_M)	160
5.3.2   	Releasing an SVC (SS_M)  Detailed for Test 
Configuration #3a	163
5.3.3   	Releasing an SVC (SS_M)  Detailed for Test 
Configuration #3b	168
5.3.4	   Releasing an SVC (SS_M)  Detailed for Test 
Configuration #3c	172
5.4	DTL Processing	174
5.4.1   DTL processing an SVC	174
5.4.2	   DTL processing an SVC  Detailed for Test Configuration 
#3a	177
5.4.3	   DTL processing an SVC  Detailed for Test Configuration 
#3b	185
5.4.4   DTL processing an SVC Detailed for Test Configuration 
#3c	193
5.5	Crankback Processing	196
5.5.1   Crankback processing on an SVC (SS_M)	196
5.5.2	   Crankback processing on an SVC (SS_M)  Detailed for 
Test Configuration #3a	198
5.5.3	   Crankback processing on an SVC (SS_M)  Detailed for 
Test Configuration #3b	205
5.5.4	   Crankback processing on an SVC (SS_M)  Detailed for 
Test Configuration #3c	209
5.5.5	   Crankback processing on an SVC (SS_M)  Detailed for 
Test Configuration #4a	210
5.5.6	   Crankback processing on an SVC (SS_M)  Detailed for 
Test Configuration #4b	217
5.6	Test Cases Dynamic Behavior (Point-to-Multipoint)	219
5.6.1   Setup of the initial party (SS_M)	219
5.6.2   Adding a party (SS_M)	222
5.6.3   Party dropping (SS_M)	224



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.)

af-test-csra-0111.000						   	      Interoperability Tests for PNNI
Interoperability Tests for PNNI			                   			     af-test-csra-0111.000
Page ii of 229						ATM Forum Technical Committee
ATM Forum Technical Committee						Page i of 229
Page 224 of 229						ATM Forum Technical Committee
ATM Forum Technical Committee						Page 225 of 229