ATM Model Desc

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:

• Configurable parameters for Service Specific Connection Oriented Protocol (SSCOP)

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

STM-2-2 Modeler/Release 11.5


• 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



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.

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.

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



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.



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

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.

• Per-VC and Per-Flow Queuing• Round-Robin and

Weighted Round-Robin Servicing

Output Buffering

Input Ports

SwitchingFabric

OutputPorts

Fabric Delay

VP/VC Lookup Delay/ UPC

• Per-VC and Per-Flow Queuing• Round-Robin and

Weighted Round-Robin Servicing

Output BufferingOutput Buffering

Input Ports

SwitchingFabric

OutputPorts

Fabric Delay

VP/VC Lookup Delay/ UPC



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.



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



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



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



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.



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



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



• 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



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

AAAAAA

BBBBBB

CCCCCC

ABCACCABCAC

2

1

3

C

Counter Reset

ABCABCABCABC

Weighted Round Robin

Round Robin

Scheduler

Counter Reset

AAAAAA

BBBBBB

CCCCCC

ABCACCABCAC

2

1

3

C

Counter Reset

ABCABCABCABC

Weighted Round Robin

Round Robin

Scheduler

Counter Reset



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.



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



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:



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.



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.



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

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.

ATM statistics

ATM VC Statistics

ATM Switch Statistics



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.



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 View Results dialog box. Notice that the results are shown for each direction

From Choose Results dialog box



ATM Menu

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

Table 2-4 ATM Menu Operations

Configure Global Oversubscription

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

Configure a SPVX between selected nodes

Allows you to configure an SPVX connection between two nodes

Display ATM VC Routes... (DES)

Displays the routes taken by the various ATM VC connections 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 Visualization

Clears the routability visualization that was displayed.

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



The ATM Protocols Menu is shown below.

Figure 2-18 ATM Protocols Menu



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



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

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

Soft PVX only

Hard PVX only

Hard and Soft PVXs

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

hard

soft



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

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.

The Port number for Input and Output parameters corresponds to the link interfaces.

The VPI and VCI values on a node and port should be unique for each PVX.

➊ ➌

➏

➋ ➊➍

➎

➎

Each row of the PVX Circuit Table represents a hop in the PVX.



• 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

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.

Use these attributes only if configuring a PVX with both hard and soft connections.



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.



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

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:

Set the ingress port to Switch1’s (the source’s) incoming interface.

Use the same identifiers specified for the hard component.



Figure 2-26 Creating Traffic Flow Characteristics

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.

Note that you can characterize traffic by any combination of these attributes.



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.



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.



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



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

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.

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,Emailcharacteristic,EmailCharacteristic,sw_2_1:not_used,sw_1_2:1

preferred route entries



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



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.



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.



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



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



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.



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

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_aal34_conn_v3 Implements the encapsulation and decapsulation of SAR_PDUs following the AAL3/4 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.

atm_wkstn

Application Layer

IP Layer

ATM Layer. All of the ATM node models contain this ATM Layer



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




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.

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


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_proceeding

Control data used to send CALL PROCEEDING message for ATM 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_complete

Control data used to send RELEASE message for ATM signaling 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



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
