Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Backbone Data

MUXLOC (muxloc=filename)

Description: Node File

General format (United States and Canada locations):

BBLINK (bblink=filename)

Description: Link File

DEMAND (demand=filename)

Description: Demand File

To add more demands without modifying the original demand file, use the

NODEPARAM (nodeparam=filename)

Description: Node Hardware Type File

SITE (site=filename)

Description: Site Definition File (useful for diversity design, simulation, path placement, pricing)

Purpose: The site file is used to define sites as logical groupings of nodes. The site definitions are used for the purpose of failure simulation, diversity design, and diverse path placement. By default, if a node is not included in a user-defined site definition, it is treated as being in a site of its own for these purposes. Site information can also be used to facilitate pricing specifications, as in the usercost file.Purpose: The site file is used to define sites as logical groupings of nodes. The site definitions are used for the purpose of failure simulation, diversity design, and diverse path placement. By default, if a node is not included in a user-defined site definition, it is treated as being in a site of its own for these purposes. Site information can also be used to facilitate pricing specifications, as in the usercost file.

Usage: Each line entry in the site file uses the following syntax to indicate the nodes in a site:

A node can be indicated by ID or name. If you need multiple lines to define a site, use a back slash character (\) to continue the entry from one line to the next. Choose site names that differ from node names to avoid potential confusion in the input data.

GROUP (group=filename)

Description: Topology Groups File (useful for visual grouping; unlike the site file, this file does not influence diversity design, simulation, path placement, or pricing)

Grouping is a topology feature used to group nodes together. If you save your specification file with groups, the next time you open it up, nodes in a group is grouped together under one group symbol.

GRAPHCOORD (graphcoord=filename)

Description: Topology Window Definition and Node Coordinates (useful for display only; to be distinguished from latitude & longitude coordinates and geographical V & H coordinates)

Graphics coordinates for backbone nodes may be changed by moving locations around on the topology map and using the Map Views feature. Note that changing the graphical coordinates does not change geographical information which is stored in the muxloc file.

DOMAIN (domain=filename)

Description: Domain File

This file is needed only for large networks that are to be partitioned into different areas (domains). In it you can specify the ID, name, and color of domain regions. Nodes in different domains may only communicate with each other through gateway nodes. The domain file allows for node/link coloring by domain and for the specification of a transit domain.

For the Domain_ID, the format Dd, where d is a number, is reserved to signify a domain with domain number of d. For domains using this format, leading zeros are ignored, so D5, D05, and D005 are all treated as the same domain identifier.

Note:

This file can also be used for OSPF areas instead of domains. Depending on the hardware vendor specified in the dparam file (hwvendor=hardware_vendor), the domain file is interpreted to contain domains or OSPF areas.

OWNER (ownerfile=filename)

Description: Owner File

The purpose of this file is to facilitate the identification of node and demand ownership. By defining an owner and associating certain demands with that owner, service providers that carry traffic of several companies can use the owner feature to quickly determine the distribution of traffic in the network.

To associate a demand with an owner, the type field of the demand's entry in the demand file should include ownerID where ownerID is substituted by the corresponding ownerID in the owner file. To associate a node with an owner, specify OWNER=ownerID in the miscellaneous field of the muxloc file. Owner names defined in the muxloc and/or demand files are automatically added to the owner list if they are not defined in the owner file.

Valid Color Values: Red, Green, Cyan, Blue, White, Magenta, Yellow.

FACILITY (facility=filename)

Description: Facility Definition File (useful for diversity design, simulation)

The facility file is used to define facilities as logical groupings of nodes and links. The facility definitions are used for the purpose of failure simulation and diversity design.

Each entry of the facility file should be a separate line containing a facility name followed by the associated node ID (or node name) or link name.

The network elements should be delimited by tabs, spaces, or commas. If you need multiple lines to define a facility, use a back slash character (\) to continue the entry from one line to the next.

The facility feature does not check the validity of the nodes and/or links listed in the facility file. Duplicate links and/or nodes will also be duplicated in the facility. If both are used in the same facility, then that node is duplicated. Nodes that are not in the muxloc file and links not in the bblink file are ignored.

TRAFFIC LOAD (trafficload=filename)

Description: Peak Load by Period

For each demand, peak load information can be recorded in this file for various time periods. Data collected from the network or user-defined data can be stored in this file. Upon reading this data, the program can then calculate link bandwidth utilization at different times based on this information. This feature is applicable to ATM, Frame Relay, or Router networks.

  • DmdID must correspond to a demand ID defined in the demand file. The direction of the demand may be specified using one of the following three identifiers: "-" for Two-way, "A2Z" for One-way from Origination switch to Destination switch, or "Z2A" for One-way from Destination switch to Origination switch.

  • Alternatively, The FromNodeCardPort or ToNodeCardPort can be specified instead of the DemandID.

  • AvgFrameSize indicates the average frame size of the demand. It may be specified using a number or a dash. It is assumed that overhead is already included in the interval definition.

  • "#_bytes_in_frame": Traffic load specified is adjusted based on whether it is being routed over a frame or cell trunk.

  • The remaining columns (Period 1, Period 2, etc.) indicate the traffic load (bits) measured during the corresponding interval. A maximum of 24 intervals may be specified per PVC.

  • The field "unit = number" may be placed before the actual traffic data for demands or tunnels. The default unit value is 1 bit. All the traffic data in the traffic load file is interpreted as kilobits if the value of unit is specified as 1000. The data unit is interpreted as byte if unit = 8 is specified.

TRAFFICPATTERN (TRAFFICPATTERN=filename)

Note:

This file is for discrete event simulation only.

The traffic pattern file allows you to define several class types based on traffic characteristics. Each traffic type may be specified in terms of four parameters: number of messages, duration (seconds), message size (bits), and frame size (bytes).

In the example above, PATTERN1 is defined as 1 message lasting 2.0 seconds, with a message size of 160,000 bits and a frame size of 1,500 bytes. PATTERN2 is defined as 3 messages lasting 1 second, with a message size of 2,000,000 bits and a frame size of 256 bytes. PATTERN3 is defined as 4 messages with a duration of 3 seconds, a message size of 500,000 bits and a frame size of 1,000 bytes. PATTERN4 is defined as 1 message lasting 1 second, with a message size of 1,000,000 bits and a frame size of 1,000 bytes.

TRAFFICDATA (TRAFFICDATA=filename)

Note:

This file is for discrete event simulation only.

The traffic data file allows you to define each demand by specifying multiple packets and packet sizes. Although this requires you to have a reasonable knowledge of the traffic, more accurate simulation results can be obtained in this manner. For each PVC, up to 10 pairs (#unitx and unit_size) may be specified in defining the demand. Note that although the PVC definition entries in the example above are delimited by commas, you may also use spaces and tabs to separate entries.

This file specifies an interval of 300 seconds (5 minutes), and defines a traffic distribution for two PVCs. In this example, the PVCs are full duplex (both A2Z and Z2A directions are defined). To define a simplex PVC, specify either A2Z or Z2A for the direction field. The direction field assumes that a demand from the first node to the second node is marked as A2Z, and the reverse direction as Z2A. During the 5 minute interval, 16 packets of 48 bytes, 30 packets of 512 bytes, 35 packets of 256 bytes, and 20 packets of 512 bytes were sent in the A2Z direction of PVC1. Similarly, 10 packets of 48 bytes, 20 packets of 512 bytes, and 30 packets of 256 bytes were sent in the Z2A direction of PVC1. In PVC2 from the A2Z direction, 20 packets of 48 bytes, and 50 packets of 512 bytes were sent. The identical distribution is present for PVC2 in the Z2A direction because they have identical traffic entries.