2—The Model Library

2 The Model Library

This section describes the features available in the standard model library. The
results provided by simulations are a function of the models that you are working
with and the data that you enter for parameters of the models. To help you build
models that achieve their purpose, read the following topics:

• Overview of the Standard Model Library—describes general concepts

applied throughout the standard model library. This is the library of models
available to you as objects. You use objects in a plug-and-play fashion; there
is never any programming when you work with standard models.

• General Advice When Working with the Model Library—describes tips and
techniques to enhance your productivity when working with many of the
models in the library.

Overview of the Standard Model Library

OPNET Modeler provides an extensive library of models that you can use to
build networks. These models are called standard models because users can
also develop their own models. Those models can then be shared with other
OPNET analysis software users if desired. Certain models support the needs of
users with particular interests in emerging or vendor-specific technologies.
These specialized models are like the standard models, but an additional
license is needed to use these models in a simulation. Some users contribute
models to the user community at no charge. These are called contributed
models, and are available in each software release. Other application-specific
models are developed and sold by third-parties.

Most users work primarily with objects from the standard model library. It is
worthwhile to spend some time discovering what is available in this library, how
it is organized, and how to use the objects it provides.

Organization of the Model Library

The standard model library consists of the following types of objects:

• Device Models on page MC-2-2

• Link Models on page MC-2-4

• LAN and Cloud Models on page MC-2-4

• Utility Objects on page MC-2-8

OPNET Modeler/Release 16.1 MC-2-1

2—The Model Library

In actuality, the library also contains many models of networking protocols and
algorithms that allow your network models to simulate real network behavior.
However, as a user of OPNET Modeler, you do not manipulate the internals of
these protocols directly. Instead, you have access to the protocols’ functions via
parameters, much as you do in working with real networks. Their parameters
appear as attributes of the objects and are configurable via OPNET Modeler’s
GUI. One of the goals of this section is to explain the objects you have available
to you, and how to work with their attributes to represent your networks as
desired within the tool.

Device Models
Devices comprise the majority of the objects in the standard model library. They
correspond to a wide class of network hardware, including the following:

• Routers

• Switches

• Hubs

• Workstations

• Servers

• Firewalls

• Printers

As you can see, devices essentially correspond to the boxes, that is, the
chassis-type or rack-mounted systems in your network. They represent the
hardware that performs the information transmission and processing in the
network, ranging from simple repeaters like hubs, to content and computation
servers, like mainframe computers. Of course, these devices must not consist
solely of hardware; most of them contain large numbers of software models,
spanning appropriate layers of the protocol and application stack. What’s inside
a device depends on what its function is. For example, a typical router model
will contain hardware and software models of Ethernet, PPP, and perhaps other
Layer-2 protocols. It will also contain routing protocols such as RIP, OSPF,
IGRP, and BGP4.

MC-2-2 OPNET Modeler/Release 16.1

 2—The Model Library

The standard model library presents device models to you graphically.

Typically, you will select these objects from the object palette where they appear
graphically, though in some cases, you may choose their name from a menu of
available models. Devices appear as icons as soon as they are deployed in your
network model. The standard model library follows conventions (third-party or
supplemental models may not) for the appearance of each type of device, as
shown in the following figure.

Figure 2-1 Graphical Conventions for Network Objects

LAN Switch Router

Hub Server Workstation

Vendor Versus Generic Device Models

Device models are also categorized into two classes: vendor device models and
generic device models. Vendor models represent devices manufactured by a
particular company, such as Cisco Systems or 3Com. The developers of the
standard model library use data published by these manufacturers to
characterize the devices as well as they can. You can also create vendor device
models using the Device Creator operation, provided you have obtained values
for required parameters of the device.

Generic models provide behavior that is correct for devices of their class.
However, they are not configured to model any particular manufacturer’s
devices. Instead these devices provide attributes (that is, parameters), allowing
you to configure each one you deploy differently if you choose. For example, the
generic router below offers the forwarding rate attribute, which specifies the
throughput of the router in packets per second. Each instance of the router that
is deployed can be assigned its own forwarding rate. In contrast, a vendor
device model of a router would already be aware of its own forwarding rate, as
you would expect because the device type is already known. A vendor model
would therefore have a preconfigured forwarding rate attribute that is consistent
with the actual router’s forwarding rate.

Figure 2-2 Generic Model vs. Vendor Model

Vendor model
shows series
information

generic model
vendor models

OPNET Modeler/Release 16.1 MC-2-3

2—The Model Library

Link Models
To form a network of devices, you will need to use links and these links will
require specific characteristics. In OPNET Modeler, links represent the physical
media and properties, such as line rate in bits per second, delay, and likelihood
of data corruption. Link models also generally represent a choice of Layer-2
technology, allowing OPNET Modeler to verify compatibility of two or more
attached devices, and the link that connects them. One of the most important
characteristics of a link model from a network performance perspective, is the
speed of transmission, in bits per second. This characteristic is usually implicit
in the choice of link model (for example, a 10BaseT link automatically provides
for a 10 Mb/sec. transmission rate).

Links are represented as line segments or a series of line segments with

arrowheads in the GUI. When selecting links from the object palette, you will see
objects similar to those shown in the following figure.

Figure 2-3 Link Model Graphical Convention

LAN and Cloud Models

OPNET Modeler lets you model the end systems of your network in explicit
detail, representing each device, if necessary. However, in many simulation
studies, you will prefer to abstract local area network infrastructure into one
object, called a LAN object. The LAN object models many users on the same
LAN, and allows for a server within the LAN as well. However, it does so within
one object, dramatically reducing the amount of configuration you need to do to
represent your internetwork of LANs. Because fewer objects are present in your
network, LAN objects also help reduce the amount of memory needed to do
simulation. The following figure shows the types of LAN objects provided for
local area network technologies.

Figure 2-4 LAN Objects Abstract Local Area Infrastructure

Using LAN objects you can quickly generate large amounts of users for your
network. Specifically, each LAN object allows you to specify the number of
users present within it. You can then assign application traffic to a subset, or all
of the users of the LAN. Therefore, scaling the traffic generated by a LAN (to
model more users, for example), is a simple matter of increasing the specified
number of users. LANs can then be interconnected via switches and routers to
carry traffic to and from devices and LANs in other parts of the network.

MC-2-4 OPNET Modeler/Release 16.1

 2—The Model Library

In a manner similar to the use of LANs, it is sometimes useful to abstract parts

of the wide area network infrastructure. Cloud models are special objects in the
model library used to represent such infrastructure. They provide high-level
characteristics used to simulate the behavior of that portion of the network. The
ATM, Frame Relay, and IP model suites all include cloud models.

Figure 2-5 Cloud Objects Abstract WAN Infrastructure

Cloud models can have numerous applications. For example, your backbone
network may depend on services delivered by an Internet Service Provider
(ISP), which in turn may be connected to a carrier network. Because you do not
know the details of the backbone, a cloud node gives you a simpler model
without losing any detail.

You may also find cloud models useful if you are more interested in modeling
LAN infrastructures than network infrastructures. If your primary focus is on
modeling details on LAN traffic flows, you may not want to model the backbone
network in minute detail. Representing the backbone with a cloud should
suffice.

OPNET Modeler/Release 16.1 MC-2-5

2—The Model Library

You can simulate a backbone network using two cloud-model attributes,

described below. You can specify these through Edit Attributes, which then
applies the settings to all packets, or you can specify these through an external
file, which then applies to source-destination or ingress-egress pairs.

Figure 2-6 Cloud Attributes

• Packet (or Cell) Latency—specifies the one-way delay that each packet
experiences while traversing the network. You can run a simple test on your
network to determine this setting. First, configure your ping traffic (using an
option like IP’s record route) to report the number of hops that a packet
traverses. Then measure the response time and number of hops for a typical
ping packet sent across the network. (Keep in mind that this response time
includes transmission delays at each hop.) After you have these two values,
you can use the following equation to compute the actual network latency:

Latency = (Ping Response Time – (Hop Count * (Ping Packet Size/Data Rate)))/2

Note—One-way delay is not accurately derived by dividing the RTT by 2, since

links are not typically symmetric (i.e., forward and return path are not
guaranteed to be the same).

Use the resulting value for the latency parameter. You can also specify any
built-in or custom distribution to model variability in the delay.

• Packet (or Cell) Discard Ratio—specifies the ratio of packets dropped to

packets submitted to the network backbone. You can set this value based on
your network service provider’s statistics or its traffic-contract guarantees.

MC-2-6 OPNET Modeler/Release 16.1

 2—The Model Library

You can also import operational delay information and packet loss metrics for
cloud models using one of the methods listed below. Either method allows you
to specify pair-wise operational delay and packet loss metrics for cloud models
and to apply these metrics on each packet that traverses the cloud during a
simulation. The packet-loss and latency characteristics of cloud models can be
modeled either as single settings that are applied to all routed packets or as
separate settings for individual source and destination pairs using a .gdf file

• Explicitly Specify Performance Metrics on a Cloud

• Generate Performance Metrics for a Cloud from Router Information

Explicitly Specify Performance Metrics on a Cloud You can specify

performance metrics in an external .gdf file for source-destination or
ingress-egress device pairs. The file header determines how the file is
processed. An example file is shown in the following figure.

Figure 2-7 External Metrics File for Cloud Model

Header information (required)

The following lines constitute the header and are mandatory (see the figure
above), though the data fields need not be in the exact order as shown. A
minimum of three fields must be specified, however, one from each of the
following types:

• Input type—"Source Addr" or "Source Name" or "Ingress Addr" or

"Ingress Name"

• Output type—"Dest Addr" or "Dest Name" or "Egress Addr" or

"Egress Name"

• Performance type—"Delay (sec)" or "Packet Loss (%)"

The data rows following the header are processed based on the format
specified in the header. If a data field does not match the above listed set, it will
be ignored.

You can then specify the name of the file as an attribute in each cloud device,
as shown in Figure 2-6. The performance metrics file will be processed at the
start of simulation and appropriate log messages will be recorded to inform the
user of any inconsistencies in the performance metrics file.

OPNET Modeler/Release 16.1 MC-2-7

2—The Model Library

Generate Performance Metrics for a Cloud from Router Information You can
also generate performance metrics for a cloud based on router information. In
imported networks in which delay and loss metrics have been imported for
routers, the performance metrics for the cloud nodes can be determined from
the metrics in the router nodes by selecting Topology >
Generate IP Cloud Metrics File > From Router Metrics Information…, as
shown in the following figure. A new dialog box opens that allows you to specify
whether to use the minimum, maximum, average, or 95th percentile of the
measured round trip delay and of the measured packet loss specified in the
delay, jitter, and loss metrics of the routers.

Figure 2-8 Generate IP Cloud Metrics from Router Information

The process results in the generation of a performance metrics file for each
cloud device in the network. Each file, corresponding to a specific cloud node,
contains performance metrics information accumulated from router nodes
connected to the cloud node.

Utility Objects
Objects that don’t correspond to actual physical infrastructure are also used to
construct network models. In general, these do a logical function in the network,
such as configuration of network resources on a global level (for example,
provisioning of permanent virtual circuits, or PVCs). Another typical role for a
utility object is to enable a simulation-specific function, such as reporting on use
of memory resources. Finally, utility objects can be used to script special events

MC-2-8 OPNET Modeler/Release 16.1

 2—The Model Library

in the simulation, such as the failure of a particular network element at a given

time. In all of these cases, utility objects are selected from the palette and
deployed into the network model, and in general their location does not matter.
They have attributes that control their function in the simulation.

Figure 2-9 Utilities Object Palette

OPNET Modeler/Release 16.1 MC-2-9

2—The Model Library

The Failure-Recovery utility object is one that is commonly used to introduce

node or link failures at specific times. You can cause the same nodes/links to
then become operational (recover) at later times. The example below shows
how to configure node failures to have a particular device be disabled for 60
seconds, one hour into the simulation.

Figure 2-10 Failure-Recovery Utility Object Supports Scripting of Node and Link
Failures

MC-2-10 OPNET Modeler/Release 16.1

 2—The Model Library

Protocol Models and Protocol Menu Operations

Protocol models are at the heart of all of the device models in the standard
model library. These are models not just of communication protocols, but also
of other forms of processing that occur on messages sent throughout the
network. Examples selected from among the many protocols in the standard
model library are: IP, OSPF, TCP, IPX, Frame Relay, ATM, Token Ring, FDDI,
ARP, and FTP Client and Server.

Protocol models provide many parameters to configure the various aspects of

the network and system behavior. These parameters are accessed as attributes
of the various objects in the library. Because the protocols appear in many
different devices (for example, IP can appear in a router as well as in a
workstation), it is useful to understand the model library from a protocol
perspective. Armed with knowledge about how to work with each protocol, you
will be able to assemble and configure networks based on devices that use
these protocols in combination.

In the software, an entire menu is devoted to operations that provide easier

ways of configuring protocol models. In most cases, you can achieve the same
results by manually modifying model attributes on each object, but the Protocol
menu operations provide a faster, less error-prone way of doing so. Many of the
menu operations allow you to configure the same attributes on multiple objects
at the same time. Familiarize yourself with the operations that are available in
this menu—they are described in each protocol’s model description.

OPNET Modeler/Release 16.1 MC-2-11

2—The Model Library

General Advice When Working with the Model Library

This section presents general information about working with models in the
library, including:

• Standard and Specialized Model Library Protocols and Technologies on

page MC-2-13

• Advanced, Intermediate, and Final Models on page MC-2-14

• Modifying Object Attributes on page MC-2-14

• Verify Links on page MC-2-15

• Additional Online Information on Attributes on page MC-2-15

Most of the features and techniques described apply to all of the models.

MC-2-12 OPNET Modeler/Release 16.1

 2—The Model Library

Standard and Specialized Model Library Protocols and Technologies

Table 2-1 Standard Model Library Protocols and Technologies

Layer-1, -2 and Layer-3 and
Support Support Layer-4 Application

ATM ATM TCP FTP

Ethernet 10, 100, 1000 Frame Relay UDP E-Mail

ARP IP NCP HTTP

Frame Relay RSVP Voice

FDDI OSPF Video

Token Ring 4, 16 RIP Database

PPP BGP4 Printing

SLIP IGRP Remote Login

SRP EIGRP Customized Multi-tier

Spanning Tree IS-IS General Background

Traffic

ATM LANE X.25

X.25 (LAPB)

Table 2-2 Specialized Model Library Protocols and Technologies

MPLS (Multi-Protocol Label Switching)

UMTS (Universal Mobile Telecom System)

PNNI (Private Network-Network Interface

IP Multicasting

Advanced Servers

IPv6 for R&D

OPNET Modeler/Release 16.1 MC-2-13

2—The Model Library

Advanced, Intermediate, and Final Models

To give you a range of options with respect to complexity, many device models
are available in three flavors:

• Advanced—The advanced model is the most highly parameterized and

flexible type model of the three.

• Intermediate—The intermediate model is derived from the advanced model.

This means that it contains all of the same capabilities, but some of its
parameters have been fixed to particular values deemed reasonable for most
modeling situations.

• Final—The Final model is derived from the intermediate model and provides
even fewer attributes. The final model is the one you typically work with
unless a special need arises to tune a low-level protocol or hardware
parameter.

The nomenclature used for these models is simple. Advanced model names
bear the suffix “adv”. Intermediate model names carry the suffix “int”, Final
model names have no suffix.

Modifying Object Attributes

Configuring attributes of modeling objects is done in the GUI. A few features are
worth learning about before you start building and simulating your models. This
section does not show details about how to do these operations; for more
information, see the user interface sections of this manual set. When modifying
object attributes, use the following when they apply:

• Protocol menu operations—There are several short-cuts in the software that

can reduce the effort required to configure various protocols in your model.
Many of these are found on the Protocols menu in the Project Editor. Most of
these operations enable you to configure an attribute on several objects at
the same time, but others allow you to do things that cannot be done through
attributes. These include visualizing OSPF areas, displaying ATM VC routes,
and auto-assigning IP addresses. When working with a particular protocol in
your model, be sure to familiarize yourself with the available shortcuts and
use of them whenever possible.

MC-2-14 OPNET Modeler/Release 16.1

 2—The Model Library

• Selecting multiple objects—You can select a group of objects at a time by

dragging a selection box around them, or by clicking on them individually.
You can also use the select objects (advanced) feature to select objects
meeting a particular criteria. Finally, right-clicking on an object allows you to
select all objects of similar type (for example, all routers of the same make
and model).

• Group Attribute Assignment—This refers to the ability to simultaneously

change the attributes of many objects at once. To do this, simply select the
objects of interest as explained above. Then, edit any one of the objects as
a representative of the whole group. Make sure the Apply changes to
selected objects box is checked; your changes will take effect in all of the
selected objects when you finish editing this one.

Verify Links
The standard model library link and node objects carry information in them that
allows OPNET Modeler to determine if they are valid to connect to one another.
Most errors with respect to node interconnection can be determined within the
Project Editor before running simulations. Although the simulation will also
detect such errors, you will save time by using the verify links operation prior to
running simulations. In general, you should use it whenever you have made
substantial changes to your network involving links, and you are about to run a
simulation.

Additional Online Information on Attributes

Object attributes are the key mechanism for you to control model behavior when
working with standard library models. Much of this section is devoted to
explaining which attributes to use and how to work with them, given a particular
modeling objective. In addition to the information you can obtain from this
section, the standard library models provide you with online summaries for each
attribute. You can access this information by clicking on the Details button or “?”
icon when the attribute of interest is selected.

OPNET Modeler/Release 16.1 MC-2-15