EP1186198A1 - Atm metwork emulator - Google Patents

Abstract

An ATM network emulator (ANE) system includes ATM terminal emulators (ATEs) or ATM switch emulators (ASEs) or both interconnected at the control layer which are operative at real-time processing rates. The ANE further includes a management subsystem (ANE manager) for managing an ATM network interface to said ATM network environment. The ANE manager, ASE or ATE, or both can be interconnected with other ASEs or ATEs, or both in various combinations via Internet Protocol (IP) links for passing process control and data related to the control layer, and the ANE manager, ASE or ATE or both can be connected with real ATm switches via real-time communication links. The ANE manager can control the distribution of processes among interconnected processors to achieve real-time operation in real or simulated real-time environments for testing and emulating a variety of ATM network configurations.

Description

ATM NETWORK EMULATOR

BACKGROUND OF THE INVENTION This invention relates to tools for emulating Asynchronous Transfer Mode

(ATM) communication networks, and more particularly this invention relates to a real time ATM network emulation system.

Increasing deployment of ATM backbone networks has created a strong need for mechanisms to test and validate ATM solutions in large network configurations in a cost-effective manner. However, if all the product development, test, interoperability and performance validation are done using ATM hardware and software, the cost can mount to hundreds of thousands of dollars in equipment, software, support, interoperability and maintenance costs while also increasing the time to market. What is therefore needed is an effective low cost mechanism to test ATM environments. In the past non-real-time emulation systems have been developed for ATM environments. Examples are BoNES , a product from Cadence Design Systems, and OPNET from MIL3 with a network module. OPNET Modeler has been in wide use in 1987 and is produced by MIL3, Inc. of Washington, D.C. CACFs COMNET circuit and network emulation can be employed for network emulation of this type. However, none are known to be able to operate in real time interaction with real systems.

The following specifications are incorporated by reference for the purpose of illustrating the state of the art:

1) ATM User-Network Interface Specification , version 3.1, (UNI 3.1), copyright September 1994, The ATM forum. Hereinafter referred to as UNI 3.1. 2) ATM User-Network Interface Specification , version 4.0, (UNI 4.0), copyright Jul 1996, The ATM forum. Hereinafter referred to as UNI 4.0. Were if UNI is referred to without any version, then it may be UNI 3.1 or UNI 4.0.

3) Private Network-Network Interface Specification, Version 1.0, (PNNI 1.0), March 1996, The ATM Forum. Hereinafter referred to as PNNI. 4) Integrated Local Management Interface (ILMI) Specification, version

4.0, September 1996, The ATM Forum. Hereinafter referred to as ILMI.

5) RFC 1157 Simple Network Management Protocol (SNMP). J.D. Case, M. Fedor, M.L. Schoffstall, C. Davin. May-01-1990. Hereinafter referred to as SNMP. 6) International Telecommunications Union (ITU), ITU-T Recommendation Q.2931 (02/95) - Broadband Integrated Services Digital Network (B- ISDN) - Digital subscriber signaling system no. 2 (DSS 2) - User-network interface (UNI) - Layer 3 specification for basic call/connection control. [This document number may have been changed to Q.2971].

7) ITU-T Recommendation Q.2130 (07/94) - B-ISDN signaling ATM adaptation layer - Service specific coordination function for support of signaling at the user network interface (SSCF at UNI).

8) ITU-T Recommendation Q.2110 (07/94) - B-ISDN ATM adaptation layer - Service specific connection oriented protocol (SSCOP).

9) ITU-T Recommendation 1.363 (03/93) - B-ISDN ATM adaptation layer (AAL) specification.

SUMMARY OF THE INVENTION According to the invention, an ATM network emulator (ANE) system is provided which includes ATM terminal emulators (ATEs) or ATM switch emulators (ASEs) or both interconnected at the control layer which are operative at real-time processing rates in order to be able to interact in a real network environment. The ANE further includes a management subsystem (ANE manager) for managing an ATM network environment and for providing a single point of control via a user interface to said ATM network environment. The ANE manager, ASE or ATE, or both can be interconnected with other ASEs or ATEs, or both in various combinations via Internet Protocol (IP) links for passing process control and data related to the control layer, and the ANE manager, ASE or ATE, or both can be connected with real ATM switches via real-time communication links. The ANE manager can control the distribution of processes among interconnected processors to achieve real-time operation in real or simulated real-time environments for testing and emulating a variety of ATM network configurations.

In addition in one embodiment method for tracing a call in an ATM Network Emulator (ANE) using a computer system is described. The method includes, generating an Information Element in a message which uniquely identifies messages in a call. Next a call is established from a first call endpoint to a second endpoint over a combination of emulated or real ATM network elements or both. A call trace log stores call trace information of selected messages from selected emulated network elements as the selected messages proceed from the first call endpoint to the second call endpoint. The call trace log may be displayed on a call trace viewer and used for analyzing the routing taking place in a network. The ATM Network Emulator (ANE) according to the invention provides emulation of large network configurations of common technologies and protocols. The ANE according to the invention offers a flexible, comprehensive, cost-effective emulation and end-to-end testing of ATM hardware and applications in large network configurations. Performance analysis and duplication of field scenarios for both hardware and applications can be accomplished at a fraction of the cost of building and maintaining extensive test beds.

It is important to understand that the present invention is not a conventional modeling or simulation tool. Because it emulates the control layer of the network elements, it is able to implement protocols and signaling software sufficient to interact with a real environment. It is not necessary to develop and maintain models and to perform simulations. In addition, real and emulated components can be mixed and matched in any manner to create the desired test network.

The invention will be understood by reference to the following detailed description in connection with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a simplified illustration of the ATM interfaces in a real ATM network;

Figure 2 illustrates an example of an ATM signaling protocol stack ; Figure 3 A is a block diagram of one embodiment of a distributed architecture of workstations illustrating the interaction of an ATM network emulation system according to the invention;

Figure 3B illustrates a simplified blow-up of the hardware included in a workstation; Figure 4A shows the manager and agent modules of a specific embodiment of the invention;

Figure 4B shows an agent daemon which spawns, several ATE processes and several ASE processes;

Figure 4C shows an ATE process that has been spawned by agent daemon; Figure 4D shows an example of an ASE module; Figure 5 shows a simplified Transport Service Provider (TSP) model as described by one specific embodiment of the present invention;

Figure 6A illustrates the functional modules and their interconnection in a specific embodiment of an ATM network emulator (ANE) of the present invention;

Figure 6B illustrates in more detail a specific embodiment of the EAPP; Figure 7A illustrates the testing of a UNI port on a ATM hardware switch under load conditions;

Figure 7B illustrates the testing of a real ATM switch in a ATM network environment without requiring actual ATM hardware;

Figure 7C illustrates an example of an interconnection between two ATEs and an ASE;

Figure 7D illustrates how a Network Manager software product may be tested in an emulated network environment; Figure 8 A illustrates an example of an object model for the manager process;

Figure 8B shows the TSP object with its two children;

Figure 8C shows an example of the profile repository object;

Figure 8D shows an example of the object model for the agent daemon process;

Figure 8E shows an example of the object model for the EAPP process;

Figure 8F shows an example of an ATE process;

Figure 8G shows an example of an ASE process;

Figure 9 shows a state transition diagram for an example point to point call scenario;

Figure 10 shows a state transition diagram for an example of a point-to- multipoint call scenario;

Figure 11 shows an embodiment of a simplified Call Trace flow of the present invention.

DESCRIPTION OF SPECIFIC EMBODIMENTS 1. Overview of an Embodiment of an ANE

Figure 1 is a simplified illustration of the ATM interfaces in a real ATM network. ATM users 10, 12 may be ATM terminal equipment (ATE). The private network or switch 20 may be a hardware ATM switch, such as a FORE Systems ATM switch manufactured by FORE Systems of Warrendale, PA or a CISCO Lightstream ATM switch manufactured by CISCO Systems of San Jose, CA., or a private network of a vendor's, e.g., FORE Systems, compatible ATM switches. Either private network or switch 24 maybe the same as private network or switch 20, or it may consist of a different vendors private network, or ATM switches. The public UNI 14, is the user-network interface between an ATM user 10 and a Public ATM network 30. The Private UNI 16 is the user-network interface between an ATM user 12 and a Private ATM network 20. The Private-NNI (PNNI) 22 is the network-interface between two Private Networks or Switching systems, 20, 24. The Private UNI 16 interface and Public UNI 14 interface are both described by UNI specification versions 3.1 or 4.0 as referenced above. The Private NNI 22 is described by the PNNI specification, as referenced above.

Figure 2 illustrates an example of an ATM signaling protocol stack 40. The control plane 42 provides call establishment and release and other connection control functions necessary for providing switched service. The ATM layer 44 and physical layer 46 are typically implemented in hardware and are normally not emulated.

Both PNNI and UNI use the services of the UNI Signaling ATM adaptation layer (SAAL). The SAAL layer 50 comprises:

1. A Service Specific Coordination Function (SSCF) 52 as specified in ITU-T Recommendation Q.2130. This function maps the service of the Service

Specific Connection Oriented Protocol (SSCOP) to the needs of different AAL users.

2. The Service Specific Connection Oriented Protocol (SSCOP) 54 as specified in ITU-T Recommendation Q.2110. This assured service provides a peer-to- peer protocol to transfer signaling information between any pair of SSCOP entities. 3. The ATM Adaptation Layer Type 5 (AAL- 5) Common Part

Protocol 56 as specified in ITU-T Recommendation 1.363. This service provides segmentation and reassembly of signaling data units per ATM layer cell structure requirements.

In an specific embodiment, the control plane 42 and the SAAL 50 are emulated in the ANE. In an alternative embodiment, the data plane may be emulated. A specific embodiment of an ANE provides an environment for software emulation of a portion of or the whole hardware ATM network. Network elements that can be emulated include ATM terminal equipment, i.e., ATEs, ATM switches, i.e., ASEs, and ATM links for interconnecting these elements. Within an ATE, ANE provides emulation of real ATM applications in the control, i.e., signaling, plane. Within an ASE, it provides PNNI's call routing and switching functionality.

The ATE comprises of emulated applications (EAPPs), a user-side UNI signaling stack, user-side ILMI, and Simple Network Management Protocol (SNMP) modules. EAPPs are applications created by the user which exercise the control plane and the ANE provides an interface to create these applications and attach them to an ATE. The UNI signaling stack is used by the EAPPs to initiate Switched Virtual Circuit (SVC) connections based on their connection state and attribute profiles. The ILMI registers the ATE with the switch it is connected to. It obtains the network prefix of the switch and in turn provides the switch with its ESI (end system identifier). The SNMP agent is accessible from a standard SNMP manager for allowable MIB (Management Information Base) operations. Example MIBs are, MIB, MIB-II, ILMI MIB, AToM MIB and or PNNI MIB.

The ASE includes network-side UNI and PNNI signaling stacks and PNNI routing stacks for UNI and PNNI ports, respectively. The ASE also has a call manager which coordinates communication between the signaling stacks. Like an ATE, each ASE has an ILMI for registering ATM terminals and an SNMP agent for MIB operations.

ANE, in this embodiment, does not have a separate module for emulating ATM links. Rather, it provides each emulated network element, i.e., ATE and ASE, with a module called communication engine (CE). The CE provides communication between network elements.

An ATE or ASE may use either versions 3.1 or 4.0 of the UNI signaling protocol. The protocol version number is assigned to the ATM links in the topology. As a result, ANE's topology editor automatically configures the ports at its both ends accordingly. An ASE may use version 1.0 of the PNNI protocol on its PNNI ports.

Example Features of a Specific Embodiment

Some of the example features of the above embodiment are: Load Generation: The ANE provides the user with the ability to emulate applications running on one or more ATEs. These applications exercise the control plane by setting up SVC connections using the UNI stack of the ATE. These SVC connections generate loads for testing the network and/or the products being evaluated.

A SVC connection setup is a sequence of steps with finite (distinct) states.

A state change is triggered by a received or transmitted message. The process of connection establishment and disconnection may therefore be described using a sequence of these messages with intervening time intervals, if any. This message sequence forms a Connection State Profile.

On establishing a SVC connection, the call setup parameters are specified through a Connection Attribute Profile. These parameters basically define the connection type, its traffic shaping characteristics and Quality of Service (QoS) requirements. The following are examples of parameters that may be configured using this profile:

AAL (ATM Adaptation Layer) parameters

Traffic descriptor parameters - Quality of service (QoS)

BHLI (Broadband higher layer information)

BLLI (Broadband lower layer information)

Broadband bearer capacity

Transit network selector - Generic Identifier Transport

Connection Scope Selection

Alternative ATM Traffic Descriptor

Minimum ATM Traffic Descriptor

End-to-End Transit Delay - Extended QoS Parameters

ABR (Available Bit Rate) Additional Parameters

ABR Setup Parameters

Notification Indicator The connection attribute profile may be used to generate valid as well invalid parameter combinations and values. Default values for these parameters may be set if customization is not needed.

ATE Scripts: ANE provides the ability to create customized scripts for load generation. An ATE script includes commands which provide finer control over the connection states, and hence the type of load generated. It provides control over optional information elements of a UNI message and facilitates emulation of complicated network applications using if and goto statements seen generally in higher level programming languages.

ASE Scripts: ASE script allow control over the signaling packets exchanged between the ATM nodes for protocol interoperability and conformance tests. It provides the user a flexibility to override the emulated ATM switch's default behavior and determine the response of the switch to a UNI/PNNI signaling message. The script might, for example, direct the ASE to: ignore the signaling message; cause divergence from the normal message processing state machine and respond with a script-specified signaling message; or as default behavior, let the switch proceed with the usual message processing.

EAPP Profiles: An emulated application (EAPP) on an ATE may generate SVC connections with different connection state profiles and connection attribute profiles. An EAPP Profile may therefore be a mix of one or more connection state profiles, each with its own attribute profile. Each such pair of connection state and attribute profiles may be a scenario. The user may also use ATE scripts in the place of connection state profiles to create a scenario. Scenarios may be: incoming and/or outgoing, depending on the direction of the calls generated. An ATE script may have both the types of calls. In addition two types of call generation mechanisms are supported: concurrent and iterative. The concurrent call generation scheme generates calls simultaneously as per given call rate. Each of these calls independently execute the steps specified in its connection state profile or ATE script. The iterative call generation scheme generates a new call only after its previous call has executed all the steps specified in its connection state profile or ATE script.

Test Session: A test session may be a collection of one or more EAPPs running on the same or different ATEs in a topology. Multiple test sessions may be created to test a network topology.

SNMP: The entire ATM network may be fully SNMP manageable and could be distributed over multiple workstations while retaining centralized configuration and control. ANE may provide an SNMP agent on a workstation participating in the emulated topology. This agent is accessible from a standard SNMP manager over a UDP (User Datagram Protocol) port.

2. An Example Computer System for Implementing an embodiment of ANE Figure 3 A is a block diagram of one embodiment of a distributed architecture of workstations illustrating the interaction of an ATM network emulation system according to the invention. In an embodiment 100, Figure 3 A shows three workstations: 110, 120, and 150, connected by a TCP/IP and /or UDP/IP network connection 170. This network connection 170 may be for example an Ethernet network. Workstation 1, 110, includes the ANE manager 114 and the graphical user's interface (GUI) 112. Workstation 2, 120, includes the agent daemon 122, the ATE module 124, and ASE module 126. Workstation 2, 120, may also include an ATM network interface card (NIC) which allows a connection 160 to a hardware ATM switch 165. Alternate embodiments include: having all the operations performed by the three workstations 110, 120, and 150 combined into a single workstation; having workstation 2, 120, with only an ATE 124 or only an ASE 126 but not both; having workstation 3, 150, with two ATEs instead of the two ASEs 154, 156; or having workstation 3 or 2 be absent Thus, there are numerous combinations of connections of workstations, processes, modules, and ATM switches that should be apparent to one of ordinary skill in the art.

Figure 3B illustrates a simplified blow-up of the hardware included in workstation 2, 120, of Figure 3 A. Workstation 2, 120 includes a processor 132, a memory subsystem 134, a input/output interface, 136, an IP network interface 138, an ATM network interface 140, and a bus 130 interconnecting the previous components. The IP network interface 138 connects workstation 2, 120 to the IP network 170. The ATM network interface 140 connects workstation 2, 120 to the hardware ATM switch 165. The input/output interface 136 may, for example, include such items as a computer monitor, a mouse, and a keyboard. The processor 132 may include one or more computer processing units (CPUs), such as a SPARC processor. In an alternative embodiment Pentium or 68000 processors may be used. The memory subsystem 134 includes both volatile, e.g., RAM, and non-volatile, e.g., ROM, EPROM, hard disk, zip drive, floppy, or optical drive, memory. The memory subsystem 134 may store all or a portion of the ANE software. The ANE software includes code which executes, for example, the agent daemon 122, the ATE module 124, the ASE modules 126, 154, 156, the ANE manager 114, and the GUI 112 as shown in Figure 3 A.

3. Example ANE Processes

Figure 4A shows the manager 210 and agent 220 modules of a specific embodiment of the invention. Manager module 210 corresponds to the processes running on workstation 1, 110 in Figure 3 A. Where the Back-End 214 corresponds to the ANE manager 114. The manager module 210 has a TSP 216 which allows communication with the IP network 218, which is part of IP network 170 in Figure 3 A, to a TSP module 224 on the agent module 220. The agent module 220 corresponds to the processes running on, for example, workstation 2, 120 in Figure 3 A.

The manager module 210 including the GUI 112 and the backend 214, performs the functionality of providing the user the support necessary to execute the users' command. The manager module 210 communicates with the agent module 220 to convey user commands, for example, loading a test session, running it, and protocol information for analysis, stopping the test session, and finally, unloading it. The GUI 112 provides the user with an interface to create a topology of the network which, is to be emulated, and provides the user with the ability to assign resources to the various nodes and links in the topology. Subsequently, the user may give commands to load a test session, run it, stop it, and unload it. The user may also view the statistics and analysis at the workstation display. The backend process 214 accepts commands from the user, interprets the commands, and performs the actions required to execute the command. The actions, for example, include: communication with the agent modules 220 resident on workstations other than the workstations on which the manager module 210 resides, or on the same workstation on which the manager module 210 resides.

The agent module 220 performs the function of actually loading the topology. The agent daemon 122 may be a background process which accepts commands regarding operations on a test session, like loading and unloading of a test session. For every test session that is to be loaded, a number of ATE and ASE processes are spawned, as specified in the topology of the ATM network to be emulated.

Figure 4B shows an agent daemon 122 which spawns, i.e., forks, several ATE processes 232 to 234, and several ASE processes 236 to 238. An ATE process, for example, ATEO, 232 may create several EAPP threads 240 to 242.

Figure 4C shows an ATE process, for example, ATEO 232, that has been spawned by agent daemon 122. ATEO 232 is an instance of an ATE that is part of the topology that is loaded. The ATEO process 232 initializes itself with the parameters read from the data files. ATEO 232 then creates threads for each of the emulated applications, EAPP0 240 to EAPPn 242, which are part of the ATEO 232 for the loaded test session. ATEO 232 also creates threads for ILMI subsystem 262, signaling subsystem 264, and SNMP subagent 266. After successful initialization, the ATE waits for messages from the agent daemon on the UNIX domain socket 268.

The ATE process, for example, a portion of ATEO 232, in this embodiment is a portion of the referenced UNI specification. The ILMI process 272 is implemented using the referenced ILMI specification. The SNMP subagent 266 is used using the referenced SNMP Specification. The "SIG" or signaling process 264 implements the signaling, SAAL, including the references for the SSCF, SSCOP, and AAL-5 Common Point Protocol. Thus this of the ATE process includes the incorporation of known specifications with the processes of the present invention. In Figure 4C, EAPPO 240 generates a load on the network according to the specified EAPP profile after getting a "run" command. The EAPP also maintains the statistics associated with the load generation and uses the signaling subsystem for generating the load. Figure 4D shows an example of an ASE module. ASEO 236 is an instance of an ASE process that is part of the topology which was loaded. The ASE process initializes itself with parameters read from the data files. ASEO 236 then creates threads for the ILMI subsystem 272, "SIG", i.e., signaling subsystem 274, PNNI subsystem 278, and SNMP sub agent 276. The ASEO process 236 emulates the functions of an ATM switch and maintains the routing information and other required information for call routing purposes. After successful initialization, ASEO 236 waits for messages from the agent daemon 122 on the UNIX domain socket 279.

The ASE process, for example a portion of ASEO 236, in this embodiment is implemented using the PNNI, SNMP, SAAL, and ILMI specifications. The other portions of the ASE process, like the above ATE process, include processes described as part of the present invention.

Figure 5 shows a simplified Transport Service Provider (TSP) model as described by one specific embodiment of the present invention. The TSP in a specific embodiment is implemented as a library to be linked to all processes in the manager and the agent modules. The TSP library provides the capability to communicate over both UDP/IP 280 and UNIX domain 288 sockets. In an alternate embodiment there may also be TCP/IP sockets which may be substituted for or be in addition to a portion of or all of the UDP/IP sockets 280. There are two kinds of transfer services that TSP provides: Transfer of messages between master workstation 110 and e.g., agent workstation 120. The master 210 through its TSP_server 282 sends a message through its UDP/IP socket 280 to the UDP/IP socket 280 on the TSP_client 284. The message is then forwarded from the agent daemon 122 through its UNIX domain socket 288 to the destination sockets, for example, 288 on ASEn 238 and 288 on ATEO, 232. Any process, for example, ASEn 238, ATE1 232, or ATEn 234 that wishes to send a message to the master 210, directly sends the message through their UDP/IP sockets 280 to the UDP/IP socket 280 on the TSP server 282. 4. An Example ANE architecture

Figure 6A illustrates the functional modules and their interconnection in a specific embodiment of an ATM network emulator (ANE) of the present invention. In this specific embodiment there are eight major modules; a GUI 310, a Statistics Logger 312, a Fault Injector 314, a Topology Manager 316, a Protocol Analyzer 318, a SNMP MUX/DEMUX 320, an ATE 340, and an ASE 360.

The GUI 310 creates, modifies, and deletes connection attribute profiles, connection state profiles, and EAPP profiles; allows the user to define the ATM network topology, including both real and emulated network entities; assigns the various emulated network elements among the available set of workstations; provides the users with options to define trigger events and filters for capturing protocol related messages and for displaying filters for protocol analyzer logs; allows the user to view statistic reports of test sessions; and allows the user to inject faults, for example, protocol messages (for testing) or topology faults (e.g., bringing down a link), into the emulated network. The Statistics Logger 312 collects statistics from the load generator and protocol exerciser, displays reports of sessions, and provides support for online display of statistics.

The Fault Injector 314 enables the user to inject faults into the links or nodes or both of the ANE. The Fault Injector 314 also allows recovery from the injected faults.

The Topology Manager 316 reads network definition files, creates emulated network entities (ATEs, ASEs, and communication links), and supplies relevant data (for use of CEs) to each of the emulated entities.

The Protocol Analyzer 318 analyzes the signaling protocols. The signaling stack message information element should be captured according to user's specific capture filters. In case of the ASE, PNNI and the network side UNI message information elements, may be analyzed. In the case of the ATE the same may be done for the user's side UNI.

The SNMP agent (MUX/DEMUX) 320 provides for the situation where there are multiple SNMP sub-agents on a single workstation. The SNMP agent

(MUX/DEMUX) function allows the SNMP manager, which may be on a different workstation, to interact with the multiple SNMP sub-agents on another workstation. The SNMP agent (MUX/DEMUX) multiplexes/de-multiplexes SNMP sub-agents into an SNMP agent, hence allowing for multiple SNMP sub-agents on a workstation. The SNMP agent (MUX/DEMUX) 320 provides a UDP/IP interface to a SNMP agent (MUX/DEMUX) on the SNMP manager's workstation. The SNMP agent provides additional information at the MUXING (manager's side) to enable demultiplexing at the DEMUXING (the workstation(s) containing the emulated network); and provides the network manager with a view that the emulated network entities each have a unique IP address (see FIG. 7D).

Not shown is an SNMP manager which may interact with the SNMP agent 320 to read and write into the MIB (Management Information Base), the SNMP manager is not part of the ANE, but may be part of a Network Manager (FIG. 7D, 472) The ATE 340 includes, for example, four types of submodules: an EAPP

342, UNI-U stack 344, a communication engine (CE) 350, and an SNMP sub-agent 346. The EAPP (Emulated Application) 342 generates network workload based on the EAPP profile. The UNI-U (UNI user-side) stack 344 is described in the UNI specifications incorporated by reference. The communication engine (CE) 350 provides a means of communication between emulated and/or real network elements. This may either be through the TCP/IP socket or through a UNI port.

The ASE 360 includes, for example, the following submodules: a Call Manager 362, an SNMP sub-agent 363, a PNNI stack 364 with accompanying CE 365, and a UNI-N 366 with accompanying CE 368. There may be network side UNI (UNI-N) stacks 366 on some ports (configurable) and PNNI signaling stacks 364 on others. The communication engine (CE) 365, 368 is attached to each of the stacks on the ports. The CE maintains the address translation information between the ingress and egress ports and it enables communication between the emulated entities.

Figure 6A also shows the interaction between various software modules of ANE. The ANE creates a multi-threaded process for each of the emulated entities. The communication between the threads is through message queues designed as a generic library to ease porting to various platforms. The ANE includes, for example, the following seven threads:

1) Communication Engine, e.g., 350, 365, 368: the CE provides a communication mechanism between two emulated entities and between emulated and real entities. It provides the Signaling, PNNI and ILMI module, with a single API for configuration of ATM connections (for the control plane) and for sending and receiving messages from other ATM entities including messages exchanged over ATM NIC or IP. 2) PNNI - One instance of PNNI thread runs as part of an ASE. PNNI provides all functionality of Multi peer group PNNI. It implements, for example, the Hello state machine, neighboring peer state machines, integration of topology information received from other nodes in the network, propagation of topology information to other nodes in the network, and participates in Peer Group Leader selection and may be Peer Group Leader itself, the PNNI module may be configured for the configurable PNNI parameters given in the PNNI specification.

3) Signaling - One instance of the signaling thread using, for example, SAAL services to all ports of emulated switch. It receives messages from other ATM entities through the CE, validates the contents of the message, and updates the call state and parameter information. Also, the signaling thread includes the functions of the Call Manager 362 and SNMP sub-agents 346, 363: a) Call Manager - The Call Manager 362 is the module that implements, for example CAC (Connection Admission Control) and Routing Algorithms for the ASEs. On receiving the SETUP message from the signaling stack, the Call Handler checks for the availability of resources for the connection and selects the route for the call by accessing the topology database maintained by PNNI. It sends the route to the Signaling stack which in turn sends the SETUP message to the PNNI interface for the call. Call Manager 362 is responsible for updating PNNI for the resources allocated on the link of the ASE. b) SNMP Sub-agent - Each emulated entity may be configured to be SNMP manageable by associating an IP address with it. The sub-agent provides interface to MIB, MIB-II, ILMI MIB, AToM MIB and or PNNI MIB. This feature provides an ability to SET and GET all the SNMP MIB variables through Network Manager (see Fig 7D, 472). This helps in testing Network

Manager 472 applications and provides way of manipulating configuration information of emulated entities.

4) ILMI - The ILMI protocols run across UNI interfaces exchanging Network Prefix and ESI information between ATEs and ASEs. 5) Statistics - The Statistics Logger 312, for example collects statistics, including calls processed, calls successful, calls failed, cause of failure and link utilization.

6) Manager - Both ATE and ASE have a manager thread which receives commands from ANE Manager 114. These threads communicate to other threads in the process configuring the emulated entities as per the selection made by the user from the GUI interface. For example, to inject faults in the link by bringing it down, ANE manager 114 sends the fault injection message to appropriate emulated entity manager which in turn configures Communication Engine (CE) to indicate link fault and stop exchange of messages over that link.

7) Emulated Application (EAPP) - ATM applications are normally part of ATM Terminal Emulator (ATE) only and are used to generate call traffic as per user configuration. Each emulated end station can run many applications where each application can be configured to generate various types of calls and generate calls at the rate specified by the user.

The Call Manager 362 provides the user with the option to enter his/her nonproprietary routing algorithms. The routing library in ANE is written as a separate shared object which can be replaced by the one provided by the user. The interface between the routing algorithm and ANE (routing database and signaling software) is via API function calls.

The signaling software calls an API provided by the routing algorithm to compute the route to a particular destination. The routing algorithm in turn calls the API provided by the routing module to access the routing database to: a) determine the destination node, and b) determine the nodal link information for any node in the topology. In a specific embodiment of the invention, the following API's are given as examples.

The following example API's needs to be provided by the user to calculate a route to a destination:

1. aneRouteGetUserRoute - This API may be called by the signaling software when a route to a particular destination needs to be calculated. The information passed to this routine are: a. Destination ATM Address. b. Constraints and requirements (e.g., QoS, Bandwidth) of the call. c. Indication whether the call is an attempt after receiving a crankback.

In return the signaling software is returned the Designated Transit Lists (DTL) and if this call needs to be crankbacked then the cause code and diagnostic information is returned. Note paths in PNNI consist of a chain of DTLs. Each DTL consists of the transit Node identifier and the egress port from the node. 2. aneRouteFreeUserRoute - Since the memory for the DTL in the above API may be allocated by the routing algorithm code this API may be provided by the user to free the memory allocated for DTL. The signaling software calls the API after its work with DTL is over.

The ANE Routing module provides the following example APIs to access routing database.

1. anePnniGetBestMatchinRaddrs - This API is used to determine the best matching node which advertises reachability to the specified destination address. The user is expected to pass the destination address and the API returns node id (containing address etc.) of the best matching node. If required, the user can also obtain multiple matching node addresses

2. anePnniGetNodalRoutinglnfo - This API is used to determine the link information of a particular node. The user is expected to pass it the node information and in return the API provides for each link on the node: a. Local and remote port id. b. Remote node id. c. Resource availability on a per traffic category basis.

3. anePnniGetLocalNodeld - This API is used to get the lowest level node id i.e. the node on which the routing algorithm is running. Figure 6B illustrates in more detail a specific embodiment of the EAPP

342 shown in Figure 6 A. The specific embodiment in Figure 6B shows four modules: a Load Generator 380, a Service Profile Generator 382, a Protocol Exerciser 388, and a Data Transfer Model 390. The Load Generator 380 puts different loads on the network as prescribed by the user. Since, in this embodiment only the control plane is exercised, the load generator 380 includes controlling connection setup frequency, connection hold time, and connection acceptance frequency. The service profile generator 382 provides various load mixes of connections and creates the EAPP Profile There may be some default load mixes and the user may specify his/her own load mix. For an example, the user may be able to specify that 10% of the calls being generated should be point-to- multi -point calls. In each such connection, fifteen parties for example, may added and then dropped (order of adding parties and dropping parties may be specified separately). The Protocol Exerciser 388 communicate with the UNI control plane 394. This component uses API's provided by the UNI stack to setup calls, accept calls, abort calls, and release calls. The Protocol Exerciser 388 may in addition, use other API calls to exercise the UNI protocol stack. In an alternate embodiment, the data transfer module 390 may be used to send and receive data to and from the UNI data plane 392.

5. Examples of Connections Between Real and/or Emulated ATM Elements

Figures 7A through 7D show examples of ANE configurations. These examples are not meant to be limiting or all inclusive, and many other configurations may be implemented by one of ordinary skill in the art.

Figure 7A illustrates the testing of a UNI port on a ATM hardware switch under load conditions. Workstation 410 includes an ATE 412. In the ATE 412, the emulated application 342 generates various loads which it then transfers to the users side UNI (UNI-U)stack 344. The UNI-U 344 sends the information to the communication engine 350 (not shown) which then sends the information out through a UNI port to a real ATM link 420. The ATM switch 265 receives the information through its network side UNI (UNI-N) stack 422. Thus, there is bi-directional communication between a ATE 412 on workstation 410 and a real hardware ATM switch 265.

Figure 7B illustrates the testing of a real ATM switch 265 in a ATM network environment without requiring actual ATM hardware and accompanying real ATM link connectivity. The configuration 420 has two workstations, 424 and 442, and a real ATM switch 265. Workstations 424 and 442 are connected via a TCP/IP communication link. Workstation 424 and workstation 442 are connected to the ATM switch 265 by a real ATM link 448 which connects each workstation's NIC through the ATM links 448 to the PNNI ports 432 on the ATM switch 265. Workstation 424 may include an ATE 426 connected by its UNI-U port 436 to an ASE 428 UNI-N port 434. In this example, workstation 424 is the manager workstation and workstation 442 includes the agent daemon. The interface between emulated entities and real nodes is PNNI or UNI and ILMI depending on the PNNI or UNI interface. The routing and signaling messages between them are exchanged using SAAL through the network interface cards (NIC). The interface between emulated entities is also the same; except the messages are exchanged over IP. The communication engine (CE) abstraction makes emulated entities transparent to mode of communication.

Figure 7C illustrates an example of an interconnection between two ATEs and an ASE; This test may occur within a workstation without an ATM NIC. There are two ATEs 452, 454, connected to an ASE 456 on a manager workstation. Each ATE is connected through a UNI-U port 436 over a TCP/IP link to the ASE 456 UNI-N port 434. For simplicity, the CE modules are not shown.

Figure 7D illustrates how a Network Manager software product may be tested in an emulated network environment. Workstation 470 includes a Network Manager software product 472 which includes a SNMP Manager and which is connected to the SNMP Agent (MUX/DEMUX) module 375. Module 375 is connected via a IP link 496 to a similar SNMP Agent (MUX/DEMUX) module 494 in workstation 480. Module 494 links all the SNMP sub-agents located on emulated modules 482, 486, 488, and 490. Thus, for example an SNMP sub-agent in ATE module 482 is connected through SNMP agent (MUX/DEMUX) 494 to SNMP agent (MUX/DEMUX) 375 to the SNMP manager in Network Manager 472. Network manager system developers may develop and test their product on an emulated, rather than a real ATM network, hence reduce overall time to market and costs.

6. Example ANE Object Diagrams

Figures 8 A through 8G show the software object model diagrams for a specific embodiment of the ANE of the present invention.

Figure 8 A illustrates an example of an object model for the manager process 500. The test session manager object 502 is an aggregation of one or more test session objects 508 and one TSP (Transport Service Provider) 514 object. The test session object 508 uses the profile repository 512. The test session manager 502 is part of the manager module backend system 214. It interacts with the GUI 112 to get the user generated commands. This object 502 sends the user generated commands to the appropriate test session objects 508 for further processing. The test session object 508 interfaces with the agent modules 226 to accomplish the user generated task specified to it by the test session manager 502. It is also part of the backend system 214.

Figure 8B shows the TSP object 514 with its two children, the TSP_client 516 and the TSP_server 518. The inheritance symbol 515 indicates that the children 516 and 518 inherit the attributes and the operations of their parent TSP 514. In a specific embodiment, the TSP_server 518 object would reside on workstation 1, 210, in Figure 2 A and TSP_client 516 would reside on workstations 2, 220, and workstations 3, 250, in Figure 2A.

Figure 8C shows an example of the profile repository object 512 being an aggregation of one or more EAPP Profile objects 522, one or more Connection Attribute Profile objects 524, one or more Connection State Profile objects 526 and one or more Test Session objects 528.

Figure 8D shows an example of the object model for the agent daemon process 122. The agent daemon object 582 sends and receives messages using the TSP object 514. The agent daemon object 582 is an assembly object relating to 0 or one

Router objects 588. The Router object 588 routes the message to the appropriate network element. The Router object 588 sends messages using the TSP object 514.

Figure 8E shows an example of the object model for the EAPP process 580. This process is forked by the ATE process 554 and emulates an ATM application. The EAPP object 582 is associated with a load object 584. The load object 584 is an assembly object to one component object, Call Thread 586, which is itself an assembly object to one component object Conn list 588. Call Thread object 586 provides the communication with the TSP, statistics, EAPP, and scenario objects.. The Load object 584 also invokes service to access scenarios in the profile repository 512. The scenarios obtained from the profile repository 512 are from Conn_attrib_capsule (Connection attribute profile) object 590 and the Conn_state_capsule (Connection state profile) object 594. In one embodiment the Conn_attrib_capsule object 590 may be in a one-to-one relationship with the Conn_state_capsule object 594.

Figure 8F shows an example of an ATE process 550. The ATE process object 552 is an aggregation of one or more EAPP objects 554, one or more ILMI objects 558, one or more SIG objects 560, and one SNMP sub-agent object 562.

Figure 8G shows an example of an ASE process 565. The ASE process object 566, is an aggregation of one or more ILMI objects 568, one or more SIG objects 570, one or more PNNI objects 572, and one SNMP sub-agent object 574.

7. Example Scenarios

In an specific embodiment the EAPP makes outgoing calls and accept calls according to a user specified load, i.e., scenario. One example, scenario maybe that the user waits on an incoming call and when the call is presented, rejects the call. Another scenario maybe that a call is setup as a point to multipoint connection to specified addresses with specified attributes; a party is then added to this connection; another party is added to this connection; the second party is dropped from this connection and the first party is dropped from this connection. In one embodiment, the user may specified a scenario in a macro format. Macro execution may in turn call signaling API's. These API's take care of insuring proper, error free signaling messages are generated and delivered to the emulated network, taking care of executing the call state machine, detecting error protocols, and taking proper actions on the violations. In another embodiment a script format may be used to provide the more detailed testing of the protocols. Figs. 9 and 10 illustrates two example scenarios.

Figure 9 shows a state transition diagram for an example point to point call scenario. The items in the boxes 910, 914, 918, 922, 932, and 936 represent user defined states. User defined messages that allow transition between the states are PREP ARE_OUTGOING_C ALL 912, CONNECT 916, CALL RELEASE 924, PREP ARE JNCOMING_C ALL 930, ACCEPT 938, and REJECT 940. The following functions are invoked by the connection manager 362 ATM_p2p_call_active 920. ATM_call_release 926, and ATM_arrival_of_incoming_call 934.

An example scenario in Fig. 9 for a user placing an outgoing call, i.e., calling user, starts at state NULL 910. The outgoing profile then issues the PREP ARE OUTGOING C ALL message 912, which prepares the user, for example an ATE, for making an outgoing call. The flow diagram then transitions to the next state WAITING_TO_CONNECT 914. The profile next sends the CONNECT message 916, which then sends a UNI-U SETUP request to the network and transitions to state WAITING_FOR_ACK 918. If the function ATM_call_release 926 function is invoked then the connection is released. Upon receipt of a UNI CONNECT message from the network, the network indicates to the calling user the call acceptance by the called user. The ATM_p2p_call_active 920 function is next called, indicating to the application that a connection has been established by the network. In addition the state then transitions to the WAITING_FOR_RELEASE state 922. When the profile gives the CALL RELEASE message 924, a UNI RELEASE message is sent to the network to request to clear the end-to-end connection and the state is then transitioned after the network is cleared to the NULL state 910.

For an example of an incoming call profile in Fig. 9, the initial state is again NULL state 910. The profile then sends a PREP ARE_INCOMING_C ALL message 930, which prepares for receiving an incoming call by receiving an incoming UNI SETUP message. The state then transitions to WAITING_FOR_CALL state 932. The function ATM_arrival_of_incoming_call 934 is then invoked by the connection manager to indicate the presence of the call to the application. The state transitions from state 932 to the CALL_PRESENT state 936. If the incoming profile gives the REJECT message 940, then the incoming call is then rejected and returned to the NULL state 910. If the ACCEPT message 938 is given, then we transition to the WAITING_FOR_ACK state 918. When the UNI CONNECT ACKNOWLEDGE message is received by the network indicating that the user has been awarded the call, then we transition to the WAITING_FOR-RELEASE state 922.

Figure 10 shows a state transition diagram for an example of a point-to- multipoint call scenario. The starting state is again the NULL state 910. The outgoing call scenario is then similar to the PREP ARE OUTGOING C ALL 912 branch of Figure 9. The next states, WATING_TO_CONNECT 914 and WATING_FOR_ACK 918 are the same as Figure 9. The function ATM_p2mp_call_active 1018 has a similar function to ATM_p2p_call_active 920. The CALL ESTD (call established) 1020 state is similar to the WATING_FOR_RELEASE state 922. Next the multipoint call scenario may issue an ADD_PARTY message 1030 which then transitions the flow to the WAITING_FOR_ADD_PARTY_ACK state 1032. This is a request that the network add a party to the point to multipoint call. If the connection manager invokes the function ATM_add_party_success 1034 then a party has been successfully added and the state transitions to the LEAF_ACTIVE state 1036. If the connection manager invokes ATM_add_party_reject 1038, then there has been a failure in establishing the additional party and the diagram transitions back to the NULL state 1010. When the connection manager receives the DROP P ARTY message 1040 then the connection manager invokes the ATM_drop_party function and transitions to the WAITING FOR ACK state 1042. When the connection manager receives the DROP_PARTY_ACK message 1044 then the connection manager drops the party from the point-to-multipoint call. The state then transitions to the NULL 1010 state. In another embodiment the WAITING_FOR_ACK state 1042 is absent and upon the connection manager receiving the DROP_PARTY message 1040 the connection manager invokes the ATM_drop_party function and drops the party from the point-to-multipoint call and transitions to the NULL 1010 state.

The above are examples of two possible scenarios and many other scenarios may be envisioned and implemented by one of ordinary skill in the art. 8. ANE Call Tracing

An embodiment of the present invention includes a Call Trace feature which allows the user to view all the messages related to a particular call. The messages may be displayed in the sequence in which they happened in the network. The user also has the capability to view the details of the messages in terms of the Information Elements, timestamps, and other contents of the messages. In addition, the route taken by the call which has been traced can be viewed. This feature is useful to understand the elements of a network through which a call is passing and thus helps. In understanding the effective routing taking place for the calls in a network with both real and emulated elements.

Call Tracing is achieved by using BHLI as a user field. The 8 byte field entered in this Information Element (IE) may uniquely identify the call. The byte usage may be:

1. Tsess ID 1 byte

2. ATE ID 1 byte

3. EAPP ID 1 byte

4. Scenario ID 1 byte

5. Call No. 4 bytes

For each SETUP message which is generated and to be traced, the

Emulated ATM Application (EAPP) which is part of ATE may generate this BHLI value.

The same value may be used by the add party message in case of Multi-party call. The

SETUP message is logged into Call Trace file by the ATE. When such a SETUP message (with BHLI field filled in) is received by an ASE, the ASE makes an entry in a call trace log file about the call for the incoming port and an entry for the outgoing port. It also logs all messages (SETUP and subsequent messages) related to this call in the Protocol Analysis log file. The same processing is also done by the receiving ATE. All ATEs and ASEs log to same log file so that correlation of the path taken by the call may be determined.

Figure 11 shows an embodiment of a simplified Call Trace flow of the present invention. Figure 11 shows five emulated network elements, endpoints: ATEl 1110 and ATE2 1118, and 3 ASEs: ASE1 1112, ASE2, 1116, and ASE3 1114. The three ASEs, 1112, 1116, 1114, are connected together through PNNI connections 1113, 1119,1120. Figure 11 also shows a call trace log 1122 which receives information from ATEl 1110, ASE1 1112, ASE2 1116 and ATE2 1118, and passes that information to Call Trace Viewer 1124. ATEl 1110 is connected via UNI connection 1111 to ASE1 1112, which is connected via PNNI connection 1113 to ASE 2 1116, which is connected via UNI 1117 to ATE2 1118. An example call trace log SETUP flow starts with ATE 1110 logging its setup message to call trace log 1112 (step 1130). ATEl 1110 then sends its setup message to the UNI connection 1111 (step 1142) to ASE1 1112. ASE1 1112 then logs the message including the BHLI field received in the setup message to the call trace log 1122 (step 1132). Steps 1134, 1136, 1138, and 1140 shows the logging of the setup message as it moves from ASE1 1112 to ASE2 1116 and to the final endpoint ATE2 1118. In this embodiment as ASE3 1114 is not part of the SETUP, hence no call tracing is gathered concerning ASE3 1114.

9. Conclusion

In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. Other embodiments will be apparent to those of ordinary skill in the art. For example, while the specific embodiments include using the PNNI specification to describe the interface between a real or emulated ATM switch and a real or emulated ATM switch, in a private network, equivalent embodiments may include private to public or public to private network/switch interfaces or interfaces within a public network or between public networks/switches. In addition while the specific embodiments described use UNI version 3.1 and 4.0, PNNI, version 1.0, ILMI, version 4.0, and SNMP, version 1, other equivalent embodiments will be apparent to those of ordinary skill in the art, as the specifications evolve. For example, an SNMP version 2 alternative embodiment may be described by the present invention. Further, while the present invention has been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of the present invention. The present invention may be implemented only in hardware or only in software or using combinations thereof.

Thus, it is evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the invention as set forth in the appended claims and their full scope of equivalents.

Claims

WHAT IS CLAIMED IS:

1. For use with a mixture of real and virtual Asynchronous Transfer Mode (ATM) network switches interconnected in a network, an ATM network emulator (ANE) system comprising: at least one ATM terminal emulator (ATE) operative according to a predefined standard to implement an ATM terminal control layer in order to at least establish a connection with at least one real ATM switch via said control layer, said ATE being operative at real-time processing rates in order to be able to interact in a real network environment; a management subsystem (ANE manager) for managing an emulated ATM network environment and for providing a single point of control via a user interface to said ATM network environment; means for interconnecting said ATE with said real ATM switch via a real- time communication link.

2. The system according to claim 1 wherein said real-time communication link is a real communication link.

3. The system according to claim 1 wherein when there is a plurality of real ATM switches, at least two real ATM switches include communication protocols at the control layer which are incompatible with one another.

4. The system according to claim 1 wherein said ANE manager provides distribution of processing among a plurality of processors such that said ANE operates distributed processes in real time.

5. The system according to claim 1 further comprising: at least one ATM switch emulator (ASE) operative according to a predefined standard to implement an ATM switch control layer with network side interfaces in order to at least establish a connection with any one or more ATM switch emulators or ATM terminal emulators or real ATM switches or real ATM terminals via said control layer, said ATM switch emulator being operative at real-time processing rates in order to be able to interact in a real network environment; and means for connecting said ASE with other ASEs and ATEs via Internet Protocol (IP) links for passing process control and data related to said control layer.

6. The system according to claim 5 wherein said real-time communication links are real communication links.

7. The system according to claim 5 wherein when there is a plurality of real ATM switches, at least two real ATM switches include communication protocols at the control layer which are incompatible with one another.

8. The system according to claim 5 wherein said ANE manager provides distribution of processing among a plurality of processors such that said ANE operates distributed processes in real time.

9. A method for emulating an Asynchronous Transfer Mode (ATM) network using a computer system comprising: managing by a central manager module at least one agent module comprising an agent daemon process; creating by said agent daemon process at least one ATM terminal emulator (ATE) process for implementing an ATM terminal control layer according to a pre- defined standard; establishing a connection between the ATE and a network element; and creating by the ATE process at least one emulated application (EAPP) thread for providing the connection, with a connection state profile for giving a sequence of messages and associated states in establishing and disestablishing the connection at real-time processing speeds and a connection attribute profile for providing the call parameters for the connection.

10. The method of claim 9 further comprising communicating between the manager module and the agent module using an Internet Protocol (IP) network link.

11. The method of claim 10 wherein the communicating between the manager module and the agent module is communicating between a Transport Service Provider (TSP) server process on the manager module and the TSP agent process on the agent module.

12. The method of claim 9 wherein the network element includes a hardware ATM switch.

13. The method of claim 9 wherein the network element includes a ATM switch emulator (ASE).

14. The method of claim 9 further comprising creating by the agent daemon process at least one ATM switch emulator (ASE) process for implementing an ATM switch control layer according to a pre defined standard and establishing communication between the ATE and ASE in order to operate at real-time processing rates.

15. The method of claim 9 wherein the agent daemon may communicate with the ATE through a UNIX domain socket.

16. A system for emulating an Asynchronous Transfer Mode (ATM) network using a computer system comprising: an ATM Terminal Emulator (ATE) operative according to a predefined standard to implement an ATM terminal control layer in real time; an ATM Switch Emulator (ASE) operative according to a predefined standard to implement an ATM switch control layer in real time; a Topology Manager module for creating and linking network elements, comprising ATEs or ASEs or real ATM switches; a Fault Injector module for injecting faults into said network elements and links between them and providing for recovery from said injected faults. a Protocol Analyzer module for analyzing information exchanged between the network elements; a Statistics Logger module for collecting statistics including calls processed, calls failed, and link utilization; a Graphical Users Interface (GUI) module for displaying User input and ANE information; and wherein the GUI is connected to the Statistics Logger, Protocol Analyzer, Topology Manager, and Fault Injector modules and to the ATE, the Topology Manager module is connected to the ATE and ASE, the Protocol Analyzer module is connected to the ATE, and the ATE is connected to the ASE.

17. The system of claim 16 wherein the ATE comprises an Emulated Application (EAPP) module for generating switched virtual circuit connections with different connection state profiles and connection attribute profiles, User Side UNI stack module, a Communication Engine (CE) for providing communication between network elements, and a Simple Network Management Protocol (SNMP) sub-agent.

18. The system of claim 17 wherein the EAPP module comprises a Service Profile Generator for creating EAPP Profiles, the Load Generator for emulating applications running on one or more ATEs, and the Protocol Exerciser for exercising the UNI stack..

19. The system of claim 16 wherein the ASE further comprises a Call Manager for providing CAC (Connection Admission Control) and Routing Algorithms for the ASEs, an SNMP sub-agent, a PNNI stack with accompanying Communication Engine (CE), and a network side UNI stack with accompanying CE.

20. The system of claim 19 wherein the Routing Algorithms includes user customized routing algorithms.

21. A computer readable medium containing a data structure for managing an ATM network emulator (ANE) comprising a test session object which uses a profile repository object and a Transport Service Protocol (TSP) object for communicating with an agent daemon object.

22. The computer readable medium of claim 21 wherein the profile repository object comprises one or more connection attribute profile objects giving the call set-up perimeters for a switched virtual circuit (SVC) connection, one or more connection state profile objects for giving a sequence of messages and associated states in establishing and disestablishing a SVC connection, one or more EAPP Profile objects for generating a mix of connection attribute profiles and connection state profiles, and one or more test session objects comprising one or more EAPPs for testing the ANE under various load conditions.

23. The computer readable medium of claim 21 wherein the agent daemon object is associated with a Transport Service Protocol (TSP) client object for sending and receiving messages from a TSP server object, and comprises a router object for routing network messages to an appropriate network element.

24. A method for tracing a call in an ATE Network Emulator (ANE) using a computer system comprising: generating an Information Element in a message which uniquely identifies messages in a call; establishing a call connection from a first call endpoint to a second endpoint over emulated or real ATM network elements or both; storing call trace information in a call trace log of selected messages from selected emulated network elements as said selected messages proceed from the first call endpoint to the second call endpoint; and displaying a portion of the call trace log on a call trace viewer for analyzing the routing taking place in a network.

25. The method of claim 9 wherein the ATE process comprises a ATE object stored in a computer readable medium associated with one or more EAPP objects, one or more ILMI objects, one or more SIG objects for , and one SNMP sub-agent object.

26. The method of claim 9 wherein the ASE process comprises a ASE object stored in a computer readable medium associated with one or more PNNI objects, one or more ILMI objects, one or more SIG objects, and one SNMP agent object.

27. The method of claim 9 wherein the EAPP process comprises a EAPP object stored in a computer readable medium associated with a Load object comprising a Profile Repository Object and comprising a Call Thread object for providing communication with TSP, statistics, EAPP, and scenario objects.