Standard Models User Guide 2—ATM Model User Guide

2 ATM Model User Guide

Asynchronous Transfer Mode (ATM) is a connection-oriented packet switching
technique that is universally accepted as the transfer mode of choice for
Broadband Integrated Services Digital Network. This document describes key
features of the ATM model suite shipped as part of the standard OPNET model
library.

Modeler/Release 11.5 STM-2-1

2—ATM Model User Guide Standard Models User Guide

Model Features
This section provides a list of the main features available in the ATM model:

• The ATM model suite captures the following protocol behavior:

Table 2-1 ATM Model Features

Feature Description

Signaling Support Signaling is provided for point-to-point, full-duplex, Switched Virtual

Circuit (SVC), Soft-Permanent Virtual Circuit (SPVC) and
Soft-Permanent Virtual Path (SPVP).
Dynamic call setup and teardown procedures are supported.

Traffic Control Traffic control includes Call Admission Control (CAC) and Usage
Parameter Control (UPC).
Traffic Control is based on specific service category, traffic parameters
(PCR, SCR, MCR, MBS) and QoS parameters (ppCDV, maxCTD,
CLR).
Traffic Control prevents all calls with unsupportable traffic
requirements from establishing a connection and prevents established
calls from degrading network service below the specified Quality of
Service requirements.

Buffering Output port buffering is modeled.

Output buffer supports the round-robin and weighted round-robin
queueing schemes.
Buffers can be configured at each switch for various QoS levels. A QoS
level is made up of the QoS category (CBR, rt-VBR, nrt-VBR, ABR,
UBR), the QoS parameters, (ppCDV, max CTD, CLR), and the traffic
parameters.

Connection support The connections of the ATM model suite enable you to do the
following:
• Configure hard and soft PVPs and PVCs
• Switch between hard and soft PVPs and PVCs
• Import hard and soft PVCs from a file
• Specify a preferred route for an SPVx
• Accelerate capacity planning using the Call Only Mode feature on
ATM uni-source nodes
• Set up SVC connections on a per-demand basis
• Display VC routes using the route browser
• ATM connection models are implemented based on information
available from the sources listed below and in Table 2-2.

End of Table 2-1

• Configurable parameters for Service Specific Connection Oriented Protocol

(SSCOP)

STM-2-2 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

• Dynamic routing using PNNI or an adaptation of the Bellman-Ford shortest

path algorithm

• Simulation efficiency modes to reduce the duration of large simulations

without sacrificing accuracy

• An API package that applications can use to create, destroy, and send
packets through an ATM Virtual Circuit

• SPVC reroute capability to reroute SPVC connections on failure

• ATM models are implemented based on information available from the

following sources

Table 2-2 Reference Documents

ATM Forum, September 1993 ATM User-Network Interface Specification, Version 3.0

ATM Forum, April 1996 ATM Traffic Management Specification, Version 4.0

ITU-TSS Recommendation I.150 B-ISDN ATM Functional Characteristics

ITU-TSS Recommendation I.361 B-ISDN ATM Layer Specification

ITU-TSS Recommendation I.362 B-ISDN ATM Adaptation Layer (AAL) Functional

Description

ITU-TSS Recommendation I.363 B-ISDN ATM Adaptation Layer (AAL) Specification

ITU-T Specification Q.2110 B-ISDN AAL - Service Specific Connection Oriented

Protocol (SSCOP)

P-NNI V1.0 PNNI 1.0 ATM Forums: Private Network-Network

Interface Specification Version 1.0 (PNNI1.0)

End of Table 2-2

Modeler/Release 11.5 STM-2-3

2—ATM Model User Guide Standard Models User Guide

Node Models
The ATM model suite contains several client and server node models, which
can be subdivided into the following categories: workstations and servers,
uni-clients and uni-servers, uni-sources and uni-destinations, and intermediate
switching elements (such as clouds and switches). The ATM nodes can be
found in the object palettes with an “atm” prefix: atm, atm_advanced, atm_lane,
and atm_lane_advanced. The table below can be used as a starting point for
deciding which of the traffic generating ATM nodes to use.

Table 2-3 Generating Traffic Using the ATM Model Suite

To Model... Use this Node Model

Applications running over IP over ATM atm_wkstn

Applications running over IP on an Ethernet LAN over ATM ethlane_wkstn

Applications running over IP on a Token Ring LAN over ATM trlane_wkstn

Applications that run directly over ATM atm_uni_client

A general traffic source (not applications) running over ATM atm_uni_src

End of Table 2-3

The main features of the various types of ATM node models are described
below. For additional information on specific node models, right-click on the
node in the project workspace and select View Node Description from the
pop-up menu.

Workstations and Servers

Workstations
The atm_wkstn model features an application layer that resides over an IP
layer, which in turn resides over the ATM layer. The application layer supports
all of the OPNET application models; specifically, the standard network
application and custom application models.

All data going to the same destination is multiplexed into a single ATM
connection, regardless of the application the data is from. The atm_wkstn node
model is found on the atm object palette, whereas the corresponding
intermediate and advanced models are located on the atm_advanced object
palette.

The basic atm_wkstn model, like all of OPNET’s basic models, has the same
functionality as the intermediate and advanced versions, but certain attributes
are hidden from view. To change the value of attributes that are hidden in the
basic model, switch to a model with an _int or _adv suffix.

STM-2-4 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

Servers
The atm_server node model is used with the workstation described above
(atm_wkstn). This server can support all of the application models. The
atm_server node model is found in the atm object palette, whereas the
intermediate and advanced versions are located on the atm_advanced object
palette.

LANE (LAN Emulation) Workstations and Servers

The ATM LANE workstations and servers have the same functionality as the
main ATM workstations and servers described above, with the additional
feature of supporting LAN emulation (Ethernet or Token Ring). In the
workstation nodes, the application layer resides over IP over LANE over ATM.
The LANE node models are located on the atm_lane and atm_lane_advanced
object palettes. The models are:

• ethlane_wkstn, trlane_wkstn

• ethlane_server, ethlane_service, trlane_server, trlane_service

Uni-clients and Uni-servers

These client node models feature an application layer that resides directly over
the ATM layer. Unlike the ATM workstation node model, the ATM uni-client
model establishes a separate ATM connection for each application task.
Examples of application tasks are sending an e-mail, downloading a file, and
making a voice call. ATM uni-clients can be used only with ATM uni-servers,
which are capable of supporting all of the application services.

The ATM uni-client and uni-server node models are located in the
atm_advanced object palette. The models are:

• atm_uni_client

• atm_uni_server

Uni-sources and Uni-destinations

These node models are unlike the workstations and clients described so far, in
that they do not use the application models to generate traffic. Instead, traffic is
generated by a raw packet generator, which resides over the ATM layer. The
raw packet generator enables you to specify traffic in terms of packets — by
specifying values for packet sizes and packet interarrival times.

Modeler/Release 11.5 STM-2-5

2—ATM Model User Guide Standard Models User Guide

The atm_uni_source and atm_uni_dest nodes are always used together, since
the atm_uni_source node can only generate traffic, but not receive it, while the
atm_uni_dest node can only receive traffic. The traffic generated by one
atm_uni_source node can be distributed amongst several atm_uni_dest nodes.
Similarly, an atm_uni_dest node can receive traffic from one or more
atm_uni_source nodes. The models are:

• atm_uni_src

• atm_uni_dest

Switching Elements
Switching elements in the network topology neither generate nor sink traffic.
Instead, they retain connection information related to the network and switch
incoming packets through a fabric. The atm_cloud node models aggregated
switching elements, which would typically be a service provider’s network. You
can specify values for the loss and delay across the aggregation. The models
are:

• atm_<switch_name>

• atm_cloud

The following figure shows the internal architecture of an ATM switch.

Figure 2-1 ATM Switch Architecture

Fabric Delay Output Buffering

Input Switching Output

Ports Fabric Ports
• Per-VC and Per-Flow Queuing
• Round-Robin and
VP/VC Lookup Delay/ UPC
Weighted Round-Robin Servicing

Notice that the input ports of a switch perform UPC, if enabled, and introduce a
VP/VC lookup delay for every cell. Every cell then experiences a fabric delay,
as specified by the switching speed. Finally, the output ports perform buffer
management; each port has an independent set of buffers that are managed
separately. The buffers can be categorized on a per-VC or per-class basis.

STM-2-6 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

Types of Connections
The model supports the following hard and soft connections.

• Permanent Virtual Path (PVP)

• Permanent Virtual Circuit (PVC)

• Soft Permanent Virtual Path (SPVP)

• Soft Permanent Virtual Circuit (SPVC)

• Switched Virtual Circuit (SVC)

Collectively, the soft connections are referred to as SPVXs and the hard
connections are referred to as PVXs.

PVPs and SPVPs

PVPs are hard-coded “pipes” of bandwidth that are reserved in advance
between a source-destination pair. SPVPs are like PVPs except that the pipes
are signalled rather than hard-coded. You can set up multiple virtual circuits
within a pipe, as long as there is enough bandwidth in the pipe.

PVC and SPVCs

PVCs are hard-coded “channels” of bandwidth that are reserved for a specified
time between a source-destination pair. SPVCs are like PVCs except that the
channels are signalled rather than hard-coded. When a PVC is set up, all
application traffic to the specified destination uses the PVC. PVCs remain in
place for the duration of the simulation.

SVC
When application traffic starts, an SVC is automatically set up according to the
application’s traffic contract specifications and the application’s traffic flows
through that SVC. When the application session ends, the SVC is torn down.

Modeler/Release 11.5 STM-2-7

2—ATM Model User Guide Standard Models User Guide

Model Attributes
The intermediate and advanced ATM nodes have several attributes that can be
used to specify ATM configuration details. In the basic node models, these
attributes are “hidden”, or unconfigurable. By default, workstation and client
nodes are configured to generate only UBR calls, but accept calls of all types.
Details on any of the attributes can be obtained by selecting the attribute’s
name, then clicking the Details button in the Attributes dialog box.

Figure 2-2 ATM Switch Architecture

STM-2-8 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

Some of the important ATM model attributes are listed below.

• Traffic Contract. Based on the type of ATM node being used, this attribute
has appropriate names:
— ATM-IP Interface->ATM IP Parameters->SVC Characteristics->Traffic
Contract (IP)
— ATM LANE Parameters (LANE)
— ATM Application Parameters (UNI-Client and UNI-Sources)

This attribute specifies the traffic contract used by the application layer when
it sends traffic over an ATM stack. Although the application layer includes
data traffic, signaling traffic and IP/ATM routing traffic, only data traffic has a
configurable traffic contract. The Traffic Contract attribute has 3 parts: the
Category, the Requested Traffic Contract, and the Requested QoS.

Figure 2-3 Traffic Contract Dialog Box

• Category: This attribute specifies the service category used by the

application. OPNET supports all five categories specified by the ATM Forum
Traffic Management Specification 4.0: CBR, rt-VBR, nrt-VBR, ABR, and
UBR. For a call to be admitted by call admission control, there should be at
least one path to the destination where all nodes support the requested
service category.

Figure 2-4 Category Attribute Settings

Modeler/Release 11.5 STM-2-9

2—ATM Model User Guide Standard Models User Guide

• Requested Traffic Contract: This attribute specifies the traffic parameter

settings for the connection. The Requested Traffic Contract allows you to
specify the peak cell rate (PCR), minimum cell rate (MCR), sustainable cell
rate (SCR), and mean burst duration (MBS) in the incoming and outgoing
directions. During call admission control, these requested values are
compared to the supported parameters on all intermediate nodes.

Figure 2-5 Specifying the Requested Traffic Contract Attribute

• Requested QoS: This attribute specifies the application’s requested Quality

of Service, which includes the peak-to-peak cell delay variation (ppCDV), the
maximum cell transfer delay (maxCTD), and the cell loss ratio (CLR). During
call admission control, these requested values will be compared to the
supported parameters on all intermediate nodes.
Note that the name of the traffic contract attribute varies, depending upon the
node model being used. For example, it is called IP_ATM Traffic Contract in
workstations, Application Traffic Contract in uni-clients, Traffic Generation
Parameters in uni-sources, and LANE_ATM Traffic Contract in LANE
workstations.

STM-2-10 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

Figure 2-6 Specifying the Requested QoS Attribute

Queue Configuration. This attribute is used to specify supported parameters

and to configure the queues on each port of a node. The configuration specified
in this attribute applies to all ports of the node.

Figure 2-7 Sample Queue Configuration

• Queue Number: This attribute specifies the queue index. To automatically

assign indices to the queues, you can use the Per VC setting. Alternatively,
you can assign each queue a unique queue number. The queue number is
used to identify the queue being monitored for certain statistics (such as
queue length).

• Queue Parameters: This attribute allows you to specify the amount of

bandwidth that is allocated to a specific queue.

Modeler/Release 11.5 STM-2-11

2—ATM Model User Guide Standard Models User Guide

Figure 2-8 Dialog Box to Specify Queue Parameters

— Max_Avail_BW (% Link BW): This is the maximum bandwidth available

to this queue. It is calculated as a percentage of the link bandwidth. For
CBR calls, this attribute regulates the maximum bandwidth reserved and
hence guarantees this bandwidth as well.
— Min_Guaran_BW (% Link BW): This is the minimum guaranteed
bandwidth expressed as a percentage of link bandwidth. For non-CBR
calls, this attribute defines the bandwidth reserved. For example, for a
rt-VBR call, SCR is the minimum guaranteed bandwidth. The following
equation holds true for non-oversubscribed ports.

Maximum Available Bandwidth of CBR queues + Minimum Guaranteed Bandwidth of

non-CBR queues = 100%

— Size: This attribute determines the number of cells in the queue.

Figure 2-9 Guidelines for Specifying Traffic and QoS Parameters

traffic parameters of
the incoming call
should be less than
the values specified
here

traffic parameters of
the incoming call
should be greater
than the values
specified here

STM-2-12 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

Per-Port Configuration. This attribute is used to specify the per-port

specifications on a node.

Figure 2-10 Dialog Box to Specify Per-Port Configuration

.

• Port Number. This attribute identifies the port to which the configuration
corresponds.

• Port Name. Assigns a port name to this port for user identification. All output
reports and statistics would use the port name specified. If this attribute is left
as “Unassigned”, then the port number will be used for reporting purposes

• Administrative Cost. Cost of the link as seen from this port for the Distance
Vector routing protocol. It can be assigned any value or left to “Auto
Calculate”, in which case, the cost will be calculated based on the current
available bandwidth on the port and the reference bandwidth configured

• Reference Bandwidth. Used to calculate the cost of the link as seen from
this port for the Distance Vector routing protocol. If the Administrative Cost is
set to Auto Calculate, the cost will be calculated based on the current
available bandwidth on the port and the reference bandwidth configured

• Administrative Weight. Administrative Weight of the link as seen by this

port for the PNNI routing protocol. The administrative weight can be specified
in a per-category basis

Modeler/Release 11.5 STM-2-13

2—ATM Model User Guide Standard Models User Guide

• Buffer Configuration. This attribute is the same as the “Queue

Configuration” attribute but on a per-port basis. When left to default, the value
of this attribute defaults to the top level common “Queue Configuration”
attribute. If this attribute is explicitly specified, then the top level attribute will
be ignored

• Connection Limit. Maximum number of VCs that can be routed through this
port at any point of time

• Queuing Scheme. Specifies the queuing scheme for scheduling packets for
different queues within a port. The two queueing schemes available are
round robin and weighted round robin

• Buffer Size. Buffer size in Megabytes that is shared by all queues on this
port. There is a “Queue Size” attribute in cells on a per-queue basis. The
queue will start to drop packets (overflow) if either the buffer size limit or the
queue size limit is reached

• QoS Parameters. Specifies the supported quality of service parameters on

a per-category per-port basis, which include the peak-to-peak cell delay
variation, the maximum cell transfer delay and the cell loss ratio

Policing Parameters. This attribute is used to specify the usage policy control
(UPC) function. After a connection is set up, the incoming traffic may violate the
traffic contract that was requested when the connection was made. This policy
control mechanism determines whether the incoming data conforms to the
traffic contract specified during connection setup. The Policing functionality can
be enabled by setting this attribute to either the Tagging or Discard Option.

• Tagging Option: non-conforming cells are tagged with the CLP bit set to a
high value.

• Discard Option: non-conforming cells are discarded.

The Policing functionality is a dual leaky bucket implementation that polices for
the peak cell rate (PCR) of the incoming traffic. In VBR virtual circuits, a dual
leaky bucket polices for both the peak cell rate (PCR) and the sustainable cell
rate (SCR) of the incoming cells.

SPVC Reroute Parameters. This compound attribute specifies the number of

SPVC reroute attempts and the time between the attempts for re-routing SPVC
connections on failure.There are link attributes to export reports on a particular
link:

• ATM Link Failure Report: Exports the number of VCs traversing the link at
the time of failure, number of rerouted connections and the paths taken by
the rerouted connections

• ATM Trunk Report: Exports the number of VCs traversing the trunk at the
specified time and the bandwidth allocated on the trunk at the specified time

STM-2-14 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

Processing Parameters. Parameters used to compute processing time of the

packet within a node

• VC Lookup Delay. This attribute specifies the processing delay for VP/VC
(Virtual Path/Virtual Connection) Switching.

• VP Lookup Delay. This attribute specifies the processing delay for VP

Switching.VC and VP lookup delays model the effect of lookup in the
switching tables to determine the output VPI and VCI, since these identifiers
are of local significance.

• Switching Speed. This attribute specifies how fast a cell is switched through
the core switching fabric. This speed is specified in cells/sec

• Segmentation Rate. Rate at which the incoming higher layer packets are
segmented into AAL PDUs.

Queuing Scheme. This attribute specifies the servicing scheme for the queues.
Three types of queuing schemes are available: round-robin, weighted
round-robin, and priority queuing.

• Weighted round-robin scheme: queues are serviced depending on the

weights assigned to them. Weights are determined according to the
Minimum Guaranteed Bandwidth attribute (in ATM Queue Configuration >
Queue Parameters attribute) of each queue parameter. This scheme
ensures that the guaranteed bandwidth is reserved.

• Round-robin scheme: all queues have the same priority and therefore have
the same chance of being serviced. The link’s bandwidth is equally divided
amongst the queues being serviced.

• Priority queuing scheme: queues are serviced depending on their priority.

The priority of a queue is determined by the minimum guaranteed bandwidth
for the queue.

Figure 2-11 Servicing in Weighted Round-robin and Round-robin Schemes

Counter Reset Counter Reset

2
AAAAAA
Scheduler
CCACBACCACBA
1 Weighted Round Robin
BBBBBB

CCCCCC 3
CBACBACBACBA
Round Robin

Modeler/Release 11.5 STM-2-15

2—ATM Model User Guide Standard Models User Guide

ATM Address. This attribute specifies the address of the ATM node. The ATM
value must be unique across the network. Leaving the address as
auto-assigned selects unique ATM addresses at the start of a simulation. You
can choose to assign addresses manually by specifying a unique integer for
each node.

AAL Layer Selection. This attribute specifies the adaptation layer used by a
node. The atm_uni_src node can establish many ATM connections with
different traffic contracts for each connection; each connection can specify its
own AAL type.

In the atm_uni_src node model, this attribute appears as a sub-attribute of the

Traffic Generation Parameters attribute. For the other workstation and client
nodes, use the “Application Transport Layer Protocol” attribute to specify the
AAL type for each application.

SSCOP Parameters. This attribute contains configurable parameters relating

to the Service Specific Connection Oriented Protocol, according to ITU Q.2110
specifications.

Figure 2-12 SSCOP Parameters

Routing Attributes
Switches in the ATM model suite use a dynamic routing protocol, ATM Distance
Vector Routing, which is implemented as a distributed, asynchronous
adaptation of the Bellman-Ford shortest path algorithm. When the ATM
signaling layer receives a call setup request, the source node finds a route to
the call destination.

The following attributes are used to configure this routing protocol.

Routing Update Interval. This attribute specifies the time between regular
routing updates. Routing tables are periodically updated to ensure that all nodes
are aware of the latest topology changes.

STM-2-16 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

Active and Passive Failure Detection Modes. Failures and recoveries in the
network must be detected by nodes adjacent to the failure or recovery point.
These (adjacent) nodes must then inform other nodes in the network of the
failure or recovery.

• active failure detection mode: the routing process detects a neighbor node
or link failure/recovery and updates its routing tables immediately. The node
sends out route advertisements that reflect its updated routing table.

• passive failure detection mode: failure is detected implicitly when no route

costs have been received in two or more route update periods.

See Chapter 6 PNNI Model User Guide on page SPM-6-1 for details on PNNI
parameters.

SPVx Attributes
Some of the important model attributes relevant to modeling ATM connection
are described in this section.

• SPVX Traffic Characteristics. This attribute maps different IP traffic

flows—based on type of service, destination address, and so on—to different
ATM connections (SPVX, SVC), assigning each flow with a specific traffic
contract. This allows you to set up ATM connections to handle different types
of traffic and to control the priority assigned to different traffic flows.

• ATM VC Reports. This attribute exports the various reports to external

generic data files.

Figure 2-13 ATM VC Reports Table

Modeler/Release 11.5 STM-2-17

2—ATM Model User Guide Standard Models User Guide

The following reports can be exported:

— The ATM VC routes report, which specified the routes taken by the
various VCs in the network. This report is exported to an external GDF
file in the following format:
<project_name>-<scenario_name>-vc_routes.gdf.
— The SPVX routed connections report, which contains the list of SPVX
connections that were routed successfully in the network. This report is
exported to an external.GDF file in the following format:
<project_name>-<scenario_name>-atm_vc_routed_connections.gdf
— The SPVX unrouted connections report, which lists the SPVX
connections that failed to get routed. This report is exported to an
external GDF file in the following format:
<project_name>-<scenario_name>-atm_vc_unrouted_connections.gdf
— The ATM VC record routes option, which records the routes taken by all
connections in the network when set to enabled. You can view these
routes by using the route browser after running the simulation. To view
the routes, go to Protocols > ATM > Display ATM VC Routes.

• SPVX Demand Sequencing. This attribute enables you to sequence the

demands based on the various criteria such as service category, amount of
bandwidth reserved, type of connection or an administrative weight. The
SPVX connections are set up the order specified in this attribute.
The SPVX Demand Sequencing table (shown in the first table in Figure 2-14)
contains three attributes: Mode, Ordering, and Criteria Ranking. The first
attribute, Mode, has two choices:
— Simultaneous Mode sets up all connections that originate from a node at
the same time. If the start times of the connections are the same, the
demands are sequenced in the order specified in SPVX demand
sequencing.
— Sequential Mode sets up the connections that originate from a node in a
sequential manner, that is, the next connection setup is sent out once the
first connection is completely set up.
The second attribute is Ordering. After you select a mode, edit the Ordering
attribute as shown in Figure 2-14:

STM-2-18 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

Figure 2-14 Setting up a Demand Sequence

After you specify the order for the QoS criteria, Reserved Bandwidth Criteria,
and SPVX Criteria, the final ranking of the various criteria is done in the
Criteria Ranking table. For example, in the above figure, the connection
weight gets precedence over reserved bandwidth, which gets precedence
over QoS, and so on. If one or more of the criteria is not a basis of
differentiation, they can be left as Not Used and thereby not specified in the
criteria ranking table. The connection weight (which is an integer weight) can
be specified in the SPVX Configuration table. A connection with a higher
weight will be set up before a connection with a lower one.
Finally, you can export the sequence of setup of the various SPVX
connections to a log message at the end of simulation by setting the Demand
Sequencing Output attribute to Enabled.

• SPVX Start Time Jitter. This attribute allows you to configure a jitter to the
start time of the SPVX connections. As a result, all the SPVX connections are
spread uniformly across the spread interval that you specify.

• ATM VC Routes Export. This attribute is found only on end nodes, such as
a source node, a destination node, a server, a workstation, or a simulation
attribute. When set on a per node basis, routes taken by all calls originating
from that node will be exported to a .GDF file. When set on a global basis
using the simulation attribute, routes taken by all calls in the network will be
exported to a .GDF file
Setting this attribute to Export prints out all routes taken. The resulting file
has the following name format: <project>-<scenario>-pnni_routes.gdf.

Modeler/Release 11.5 STM-2-19

2—ATM Model User Guide Standard Models User Guide

Simulation Attributes
Simulation attributes can be used to reduce the simulation run time duration. By
enabling one or more of the simulation attributes, you can reduce the amount of
time needed for the simulation to run, without sacrificing the accuracy of your
results.

The ATM simulation attributes are described below:

ATM Address Information Export. This attribute defaults to Do Not Export. In

the simulation configuration, you can set the value to Export. This attribute is
used to obtain the ATM address of all nodes in the network, as well as PNNI
level and ID information. The resulting file has the following name format:
<project>-<scenario>-atm_addresses.gdf

ATM Dynamic Routing Protocol. This simulation attribute determines the

routing protocol used by the ATM switches. When this simulation attribute is set
to Distance Vector, all switches in the network use the Distance Vector Routing
Protocol, as described in the Switch Attributes section. Using the Fast-Mode
PNNI setting reduces simulation run time by using the static PNNI routing
protocol whereas using the Explicit-Mode PNNI would run the full blown PNNI
routing protocol on all nodes.

ATM SSCOP Sim Efficiency Mode. When this simulation attribute is set to
enabled, the IDLE timer is set to infinity. The IDLE timer is started when there is
no outstanding data waiting to be acknowledged or any pending data to be
transmitted. When data traffic begins, the SSCOP process transitions from the
IDLE phase to the active phase. When this simulation attribute is enabled, the
SSCOP process will not be able to detect link or node failures when there is no
data traffic between the peer processes. Therefore, you should disable this
attribute if you are studying node and link failures.

ATM Sim Efficiency. When this simulation attribute is set to Enabled, cells are
delivered directly to the destination nodes and are not transmitted via the link
pipeline stages. Propagation and transmission delays are computed internally.
This efficiency attribute increases simulation speed by reducing the total
number of events. Note that you cannot collect link utilization and throughput
statistics if this efficiency mode is enabled.

compound_cell_enabled. When this simulation attribute is set to enabled,

packets are sent into the ATM network without being segmented into cells.
However, overheads and segmentation delays are computed. Although this
efficiency mode affects the value of statistics monitored at the ATM layer (such
as cell delay, cell loss ratio, and cell delay variation), statistics monitored at
higher layers are unaffected.

STM-2-20 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

Available Statistics
Statistics that can be collected from the ATM model suite are categorized into
three groups:

• ATM: this group contains general ATM statistics

• ATM VC: this group contains connection-based statistics to evaluate the

load, throughput and utilization on a per-VC level

• ATM Switch: this group contains numerous switch-related statistics to study

the traffic flowing through the switch as well as the queue lengths and
queuing delays.

Figure 2-15 Available Statistics in the ATM Model Suite

ATM VC Statistics

ATM Switch Statistics

ATM statistics

Figure 2-15 shows the interface to set up statistic probes before a simulation.
The following diagram shows the interface seen when viewing results for the
ATM Switch statistics after a simulation. Note that queue lengths are displayed
for each port and each queue (these map to the queue numbers configured in
the port buffer configuration attribute). Results are displayed according to queue
type, servicing scheme, service category and port numbers.

Modeler/Release 11.5 STM-2-21

2—ATM Model User Guide Standard Models User Guide

Figure 2-16 Viewing Results for ATM Switch Simulations

From Choose Results
dialog box

From View Results

dialog box. Notice
that the results are
shown for each
queue.

STM-2-22 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

Figure 2-16 shows the interface for viewing the results for connection-based
statistics after a simulation. Note that each statistic is annotated and shows the
statistic (load, throughput, and so on), type of connection (PVC, SVC, and so
on), call reference number (to differentiate multiple connections), and node
names of the conversation pair (n1 --> n2 for load and n1 <-- n2 for
utilization and throughput, if viewing the results from node n1).

Figure 2-17 Annotated Results for Connection-based Statistics

From Choose
Results dialog box

From View Results

dialog box. Notice that
the results are shown for
each direction

Modeler/Release 11.5 STM-2-23

2—ATM Model User Guide Standard Models User Guide

ATM Menu
The following operations are available under the Protocols > ATM menu.

Table 2-4 ATM Menu Operations

Configure Global Allows you to specify the oversubscription percentage for
Oversubscription CBR, RT-VBR, NRT-VBR, and ABR queues on a global basis

Configure a SPVX between Allows you to configure an SPVX connection between two
selected nodes nodes

Display ATM VC Routes... Displays the routes taken by the various ATM VC connections
(DES) setup in the network

Hide ATM VC Routes Hides the ATM VC routes that have been displayed

Visualize Routability of
PVXs (Flow Analysis)

Clear Routability Clears the routability visualization that was displayed.

Visualization

Display ATM PVX Routes

Configure ATM Port Type Configures whether the port is a PNNI or VNN port for Flow
Analysis

Configure Admin Weights

for selected ATM Links...

Create IMA Groups

Model User Guide Opens this document.

End of Table 2-4

STM-2-24 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

The ATM Protocols Menu is shown below.

Figure 2-18 ATM Protocols Menu

Modeler/Release 11.5 STM-2-25

2—ATM Model User Guide Standard Models User Guide

The ATM VC Routes Display dialog box is shown below.

Figure 2-19 ATM VC Routes Display

Supported PVX Configurations

The model supports the following types of connection configurations:

• Soft connections

• Hard connections

• A combination of soft and hard connections

STM-2-26 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

For any of the three connection types, the end-to-end circuit should be either a
virtual circuit connection or a virtual path connection, but not a combination of
these two.

Figure 2-20 Supported Connection Configuration

Hard PVX only

Soft PVX only

Hard and Soft PVXs

Both hard and soft PVXs are configured in the ATM SPVx Configuration object,
which is available from the ATM object palette.

Figure 2-21 PVX Configuration Table

hard
You can use the
GUI or a
configuration file
to set up PVXs.

soft

Modeler/Release 11.5 STM-2-27

2—ATM Model User Guide Standard Models User Guide

Hard PVX Configuration

To configure a hard PVX, you can specify a configuration file that describes the
PVXs or you can described the PVXs manually in the PVX Configuration
attribute. The following diagram and accompanying text highlight some of the
guidelines you should observe when configuring this attribute.

Figure 2-22 Configuring a PVX

➊ ➋ ➌ ➍ ➊

The Port number for

Input and Output
parameters
corresponds to the
link interfaces.
➎

The VPI and VCI

values on a node and
Each row of the PVX
port should be
Circuit Table ➏ unique for each PVX.
represents a hop in
the PVX.

Note the following configuration details illustrated in the previous diagram:

• Connection Name and Connection Description attributes are for

informational (reference) purposes only. These attributes do not affect
simulation results.

• Traffic Contract can be any of the standard profiles, or you can configure your
own traffic contract by double-clicking in this field. More information on this
attribute appears in the section on Soft PVX configuration.

• AAL Type specifies the type of AAL supported by this call. More information
on this attribute appears in the section on Soft PVX configuration.

• PVX Type specifies whether this connection is a PVC or PVP.

STM-2-28 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

• Use the pre-configured values of PVC Origin and PVC Termination for the
source input and destination output parameters, respectively.

• The Special Value attribute in the Output/Input Parameters table is set to

Transit in all cases except the following: source input parameters and
destination output parameters. In these cases, the pre-configured values
mentioned above set this value to Origin and Termination, respectively.

Soft PVX Configuration

Soft PVXs are configured in the ATM SPVX config object’s SPVX Configuration
attribute. When configuring a soft PVX, you do not need to configure the
following attributes:

• Ingress Parameters

• Egress Parameters

• Preferred Route

Ingress and Egress parameters are used only if you are configuring a
connection that uses both hard and soft PVCs. A preferred route for the SPVX
can be set up, but is not required.

Figure 2-23 Configuring an SPVX

Use these attributes only if

configuring a PVX with both hard
and soft connections.

Source and Destination node names are specified for the SPVX’s origin and
termination nodes. This name can be either the actual node name or the full
hierarchical name of the node. In either case, the name must be unique
throughout the network.

The Traffic Contract attribute specifies the contract requested by the SPVX.
The nodes on which the SPVX is set up should support the requested traffic
contract. When a node receives an incoming call request between the same
source-destination pair as the SPVX, it compares the call’s requested traffic
contract to the SPVX’s supported traffic contract(s).

The AAL Type attribute specifies the type of AAL this SPVX supports. To use
the SPVX, an incoming call must have the same AAL type and as the SPVX.

Modeler/Release 11.5 STM-2-29

2—ATM Model User Guide Standard Models User Guide

The SPVX Type attribute denotes the type of virtual connection. It can be either
a Soft Permanent Virtual Path (SPVP) or a Soft Permanent Virtual Circuit
(SPVC).

The Start Time and Deletion Time specify the duration of the SPVX. The start
time must occur after the network’s routing tables have converged. If the start
time occurs too early in the simulation, the SPVX will not be set up. When
configuring start time, also consider when application traffic using this SPVX
begins—any calls occurring before the SPVX is set up are dropped.

Hard and Soft PVX Configuration

PVXs that have both hard and soft connections are configured in both the PVX
Configuration and the SPVX Configuration attributes. Hard connections are
configured in the PVX Configuration Table and soft connections in the SPVX
Configuration Table. The SPVX Configuration Table also specifies the ingress
and egress information needed to link the hard and soft connections.

In the PVX Configuration attribute’s PVX Circuit table, configure the hard
connection as described in section Hard PVX Configuration on page STM-2-28,
but exclude the nodes of the soft PVX.

Figure 2-24 PVX Circuit Table for Hard and Soft PVX Configuration

These nodes excluded from the

PVX Circuit table because they are
they are part of the SPVX.

STM-2-30 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

In the SPVX Configuration attribute, use the ingress and egress parameters to
indicate input and output parameters that connect to the hard PVX.

Figure 2-25 SPVX Configuration Table for Hard and Soft PVXs

Set the ingress port to

Use the same Switch1’s (the source’s)
identifiers incoming interface.
specified for the
hard component.

Mapping IP Flows to ATM Connections

You can map different IP traffic flows—based on type of service, destination
address, and so on—to different ATM connections (SPVX or SVC), assigning a
specific traffic contract to each flow. This allows you to set up ATM connections
to handle different types of traffic and to control the priority assigned to different
traffic flows. The procedure for doing this differs slightly depending on whether
you are modeling an SVC or an SPVX.

Procedure 2-1 Mapping IP Flows to an ATM SPVX Connection

1 Your first step is to create the traffic characteristics for the IP flows that you want
to map to specific ATM connections. From the ATM SPVX Config attribute dialog
box, edit the Traffic Characteristics attribute to specify different traffic
characteristics for different IP traffic flows. Use the following editing path:

Modeler/Release 11.5 STM-2-31

2—ATM Model User Guide Standard Models User Guide

Figure 2-26 Creating Traffic Flow Characteristics

Note that you can characterize

traffic by any combination of
these attributes.

2 Your next step is to define one or more SPVX connections. Go back to the ATM
SPVX Config attribute dialog box and edit the SPVX Configuration attribute. Create
one row for each SPVX connection you want to define, and then specify the
attributes for each connection. For details, see Soft PVX Configuration on
page STM-2-29.

3 Your final step is to assign a traffic characteristic to the SPVX connections you
defined in Step 2. Edit the SPVX Configuration > Traffic Contract attribute and set
the Traffic Characteristic attribute in both the incoming and outgoing directions to
the same characteristic that was defined earlier in the SPVX Traffic Characteristics
attribute (as shown in Figure 2-27). This maps specific IP flows onto this SPVX
connection. Repeat for as many connections as you want to define.

STM-2-32 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

Figure 2-27 Assigning a Characteristic to an SPVX Connection

End of Procedure 2-1

Procedure 2-2 Mapping IP Flows to an ATM SVC Connection

1 Once the traffic characteristics have been defined in the SPVX Traffic
Characteristics attribute, all traffic belonging to a defined characteristic is mapped
to a specific ATM Traffic Contract.

2 To map the characteristic, edit the ATM IP Parameters > SVC Characteristics
attribute and specify all the characteristics that this node can support. An SVC to
the same destination will be created for each of the different service categories.

3 Alternatively, select the No SVCs option if this node should not create any SVCs.
It will use only PVX/SPVX connections that already exist.

Modeler/Release 11.5 STM-2-33

2—ATM Model User Guide Standard Models User Guide

Figure 2-28 Mapping an IP Characteristic to a Specific ATM Traffic Contract

End of Procedure 2-2

Configuring Multiple PVXs Between a Source-Destination Pair

Multiple PVXs (hard and soft) can be configured between a source-destination
pair. The PVXs can have (but are not required to have) different traffic contracts,
AAL types, and QoS categories.

When a call arrives at a source node, a PVX is chosen at random from those
supporting the call’s AAL type, traffic contract, and destination.

Rerouting SPVC Connections on Failure

SPVC connections are automatically rerouted on a failure of a node or link on
its path. The SPVC Reroute Parameters attribute can be used to specify the
number of reroute attempts to be made and the time between the reroute
attempts. Rerouting is done from the source node of the connection in case of
Distance Vector routing and from the entry border node in a peer group in case
of PNNI.

STM-2-34 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

Specifying a Preferred Route for an SPVX

A preferred route consists of a list of ATM switches that are preferred hops in
the route between source and destination. These required hops may or may not
be directly connected with each other, or with the source/destination. You can
also specify a preferred egress port from the preferred nodes. If no egress port
is specified, the default port, as determined by the route selection algorithm, is
used.

Preferred route for SPVX may be specified through the OPNET GUI or through
the SPVX configuration file. To specify preferred route through the GUI, first
define the route in the SPVX Configuration object’s Preferred DTL Configuration
attribute. Then specify this attribute in the SPVX Configuration > Preferred
Route attribute. Note that if the Preferred DTL Configuration attribute is set to
NOT_USED, no routes appear in the Preferred Route pull-down list.

Figure 2-29 Defining a Preferred Route

Figure 2-30 Specifying a Preferred Route

Modeler/Release 11.5 STM-2-35

2—ATM Model User Guide Standard Models User Guide

The Preferred Route list can also be specified using a text file. Specify the name
of this file in the SPVX Configuration File attribute from the SPVX Configuration
object. An example entry from the above file is as follows:

Figure 2-31 Sample Entry From an SPVX Configuration File

SPVC Connection,wkstn,server,UBR,1,1,0.001,0,0,0.5,
0.5,5,5,default,default,default,default,default,
default,AAL5,SPVC,4.0,-1,0,default,default,default,
default,default,default,Example SPVC Setup,Email
characteristic,Email
Characteristic,sw_2_1:not_used,sw_1_2:1

preferred route entries

The last two entries (separated by commas) are part of the preferred route
specification. The format is as follows: <node_name>:<port_number>

Use the string “not_used” to NOT specify a specific egress port from that node.

Handling Error Conditions Related to Preferred SPVX Routing

If a call cannot be routed using the preferred route, the protocol falls back to the
default routing.

If a call cannot be routed from the specified egress port for a preferred node, the
default port is used, as determined by the route selection algorithm.

Simulation Log Messages Related to Preferred SPVX Routing

If a specified node name is not valid (maybe, it was spelled incorrectly in the
SPVX Configuration file, or the node name entered is not an ATM switch), that
entry in the preferred route list is ignored, and a message is written to the
simulation log.

If the port number specified is not valid (for example, if there is no route to the
destination given that port number), the default port is used, and a message is
written to the simulation log.

STM-2-36 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

Traffic Modeling
This section describes traffic modeling using the ATM model suite.

Setting up Multiple Calls from a Source Node

You can set up calls for the following:

• ATM Uni-Source

• ATM Uni-Clients

• ATM Workstations

ATM Uni-Source
The ATM Uni-Source can be configured with multiple calls as shown below.

Figure 2-32 Setting Up Multiple Calls from ATM Uni-source

Modeler/Release 11.5 STM-2-37

2—ATM Model User Guide Standard Models User Guide

Each row in the ATM Application Parameters table represents one call. Each
call can be repeated as many times as required during the simulation. This can
be done by setting the Arrival Parameters as shown below:

Figure 2-33 Arrival Parameters Table

Call Only Mode: By setting the ATM Application Parameters or the Arrival
Parameters to Call Only Mode, you can quickly perform capacity planning on
your network. In Call Only Mode, only signaling data is generated; no actual
data traffic is generated. By setting the incoming calls to Call Only Mode,
bandwidth is reserved on the ports and SPVX, if any. In this manner, you can
determine the amount of bandwidth used on the links and the amount that is
free. Statistics such as the Call Blocking Ratio can be collected to view the
number of calls being blocked.

ATM Uni-Clients
The ATM Uni-Client can also be configured with multiple calls. This is done by
configuring multiple concurrent application sessions. Each session is
represented as one call.

ATM Workstations
The incoming IP traffic can be characterized into different flows based on a
number of options, such as ToS or Destination Address. Each characteristic can
then be assigned to a different connection, so that all traffic belonging to that
characteristic flows over the specified connection to the destination.

STM-2-38 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

Available Traffic Modeling Statistics

The following statistics are available to analyze traffic modeling in your network.

Figure 2-34 Load, Delay, and Throughput Node Statistics

Simulation Log Messages

Log messages are generated at the end of a simulation if the models detect
problems due to configuration, protocol interaction, and so on. Some of the
categories are “Call Setup”, “Call Admission”, and “Cell Loss (buffer overflow,
UPC)”. The most common log messages are due to call admission failures.

Modeler/Release 11.5 STM-2-39

2—ATM Model User Guide Standard Models User Guide

The following message is generated if, for any reason, there is a call admission
failure. The message indicates the node that failed the call, the service
category, the requested parameters, and the direction in which the CAC was
applied. A “forward” direction refers to a port towards the destination and a
“reverse” direction refers to a port towards the source.

Figure 2-35 Error Message Generated by a Call Admission Failure

STM-2-40 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

The following messages are logged if the call admission failed because a
suitable buffer was not found as a result of mismatched traffic or QoS
parameters. Refer to the Traffic and QoS Parameters section for the rules
applied when searching for a suitable buffer.

Figure 2-36 Sample Error Messages Generated by Call Admission Failures

Traffic parameters mismatch

QoS parameters mismatch

Modeler/Release 11.5 STM-2-41

2—ATM Model User Guide Standard Models User Guide

Suppose a suitable buffer has been identified on a port. If that buffer does not
support the requested bandwidth, then the following message is logged.

Figure 2-37 Error Message Due to an Unsupported Bandwidth Request

This log message in Figure 2-37 is sensitive to the service category and reports
if the incoming request exceeded the maximum available bandwidth or
minimum guaranteed bandwidth.

Log messages are also created for preferred SPVX routing.

• If a specified node name is not valid (maybe, it was spelled incorrectly in the
SPVX Configuration file, or the node name entered is not an ATM switch),
that entry in the preferred route list is ignored, and a message is written to
the simulation log.

• If the port number specified is not valid (for example, if there is no route to
the destination given that port number), the default port is used, and a
message is written to the simulation log.

STM-2-42 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

Model Architecture
Figure 2-38 illustrates the underlying architecture of the atm_wkstn node model.
Notice the three different layers reflecting the Application layer over IP over
ATM architecture that characterizes the atm_wkstn model.

Figure 2-38 Architecture of the atm_wkstn Node Model

Application Layer

IP Layer

ATM Layer. All of the ATM node

models contain this ATM Layer

atm_wkstn

The following table summarizes the process models used by the ATM model
suite.

Table 2-5 Process Models (Part 1 of 3)

AAL Module

ams_aal1_conn_v3 Implements the encapsulation and decapsulation of SAR_PDUs

following the AAL1 protocol.

ams_aal2_conn_v3 Implements the encapsulation and decapsulation of SAR_PDUs

following the AAL2 protocol.

ams_aal34_conn_v3 Implements the encapsulation and decapsulation of SAR_PDUs

following the AAL3/4 protocol.

ams_aal5_conn_v3 Implements the encapsulation and decapsulation of SAR_PDUs

following the AAL5 protocol.

ams_aal_disp_v3 Root process of the AAL module. It creates and invokes

signaling and connection processes to handle new connections,
incoming signals and data.

Modeler/Release 11.5 STM-2-43

2—ATM Model User Guide Standard Models User Guide

Table 2-5 Process Models (Part 2 of 3)

ams_aal_sscop Performs reliable transfer of SAAL messages for each signaling
connection

ATM_call_control Module

ams_atm_call_control Accesses interfaces between the data plane and the control
plane.

ATM_sig Module

ams_atm_call_dst_v3 Handles signaling to establish and release an ATM connection

at the called (i.e., destination) node.

ams_atm_call_net_v3 Handles signaling to establish and release an ATM connection

at a node that is neither the calling nor the called (i.e., network)
node.

ams_atm_call_src_v3 Handles signaling to establish and release an ATM connection

at the calling (i.e., source) node.

ams_atm_signaling Handles all signaling to establish an ATM connection

ATM_rte Module

ams_atm_dr Builds and updates ATM routing table; provides route

recommendations to other ATM processes.

ATM Layer Module

ams_atm_layer_v3 Encapsulates and forwards data from the AAL layer;

decapsulates and forwards data to the AAL layer; forwards cells
from the ATM Management module.

ATM Switch Module

ams_atm_sw_v3 Switches cells to output ports. It also implements buffer

management, based on QoS and the ABR feedback
mechanism.

ATM Translation Module

ams_atm_trans_v3 Receives incoming ATM cells from network; translates VPI/VCI

values for outgoing cells; forwards cells to appropriate ATM
module.

IPAL Module

ams_ipif_v4 Transports IP datagrams across the ATM network; establishes

and releases AAL connections, as required.

traf_src Module

STM-2-44 Modeler/Release 11.5

Standard Models User Guide 2—ATM Model User Guide

Table 2-5 Process Models (Part 3 of 3)

ams_traf_gen_v3 Initiates call start and end, generates the actual packets, and
sends them to the AAL module.

traf_srct Module

ams_traf_sink_v3 Acts as the final destination for the data packets.

End of Table 2-5

Model Interfaces
The following sections discuss the topics necessary for interfacing with the ATM
model.

Packet Formats
The following table lists the packet formats used in the ATM model and gives a
brief description of each.

Table 2-6 Packet Formats

Name Description

ams_aal5_cpcs_pdu AAL 5 PDU encapsulating an AAL 5 client SDU for transfer to the
ATM layer.

ams_aal_signal Carries signals within the Signaling AAL process model.

ams_atm_call_proceed Control data used to send CALL PROCEEDING message for ATM
ing signaling protocol.

ams_atm_cell ATM data cell.

ams_atm_connect_v2 Control data used to send CONNECT message for ATM signaling
protocol.

ams_atm_connect_ack Control data used to send CONNECT_ACK message for ATM

signaling protocol.

ams_atm_dr Control cell used to implement dynamic routing within ATM.

ams_atm_release Control data used to send RELEASE message for ATM signaling
protocol.

ams_atm_release_com Control data used to send RELEASE message for ATM signaling
plete protocol.

ams_atm_rm Resource management cell that carries feedback information.

ams_atm_setup_v2 Control data used to send RELEASE message for ATM signaling
protocol.

End of Table 2-6

Modeler/Release 11.5 STM-2-45

2—ATM Model User Guide Standard Models User Guide

ICI Formats
The following table describes the interface control information (ICI) formats
used in the ATM model suite.

Table 2-7 ICI Formats

Name Description

ams_aal_handle Contains the AAL and SAAL process handles associated with a
virtual connection. Passed to ATM as an upper layer handle and to
a client as a lower layer handle within ams_if_ici_v2 during call
establishment and release.

ams_aal_request Used within AAL to store incoming setup requests. It contains the
ams_if_ici_v2 described below, as well as an interrupt code, and
the object ID of the module or node sending the setup request.

ams_atm_handle Passed as a lower layer handle within the ams_if_ici_v2 by ATM

to forward state information associated with a call to AAL. It is
returned to ATM during data transfer and call release.

ams_if_ici_v2 Used within AMS to pass establish and release messages

between the layers of a node.

ams_ipif_handle Passed as an upper layer handle within the ams_if_ici_v2 by the

ams_ipif_v4 process to forward connection information to AAL.

ams_neighbor_notify Carries neighbor notify messages between the modules of an

AMS node model.

ams_saal_ici Used within AAL to pass signal packets to a SAAL process.

End of Table 2-7

STM-2-46 Modeler/Release 11.5