Description: Node File
General format (United States and Canada locations):
#nodeID name npa nxx[MISC]
N01 NYC(5WTC) 212 392
General format (International locations):
#nodeID name npa nxx countrycode lat long [MISC]
N33 LEED 999 999 UK 534959N 0013459W
Description: Link File
#[LinkName] NodeA NodeZ Vendor # BwType [Misc]
N2 N6 ATT 3 T3 LINK1 N3 N4 DEF 1 OC3
Description: Demand File
#DemandID NodeA NodeZ bw Type_field Pri,Pre [Path]
I000123A N01 N02 256000 R2 12,10 N01-N05-N02
To add more demands without modifying the original demand file, use the
NEWDEMAND file (newdemand=filename)
Description: Node Hardware Type File
#nodeID/name hwtype [MISC]
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:
mysite01=N08 mysite02=N46=N86 = N71 = N72 \ = N73 = N74
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.
Description: Topology Groups File (useful for visual grouping; unlike the site file, this file does not influence diversity design, simulation, path placement, or pricing)
# Group_name Members
GROUPA N1, N2, N3
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.
Description: Topology Window Definition and Node Coordinates (useful for display only; to be distinguished from latitude & longitude coordinates and geographical V & H coordinates)
window 1228 158 2114 1515
#first line defines the window size, Only locations and #line segments within
the window coordinates are displayed.
#node npa nxx graph_v graph_h
N001 212 406 4919 1447 N002 212 406 4933 1570 N003 212 406 5154 1394 END
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.
Description: Domain File
#domain_ID domain_name color
1 REDNET MAGENTA V2 BLUENET BLUE TRANSIT=V2
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.
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.
Description: Owner File
#OwnerID Name Color
G1 wandl blue G5 wandl2 red
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.
Description: Facility Definition File (useful for diversity design, simulation)
#Facility_name net_element1 [net_element2 ]*
FAC1 L2N2N3 L3N2N3 FAC2 L2N4N5 L3N4N5 L4N4N5 \ L5N4N5
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
The format for the traffic load file is shown below:
# --Peak load in bits--
#DmdID Dir AvgFrameSize Period1 Period2 etc…
V0001 - 20 12800 12800 12800 12800 F0001 A2Z 87 6852 2083 1372 2749 F0001 Z2A 456 18795 11703 4578 5065
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.
This file is for discrete event simulation only.
#traname #msg Duration Msg size framsize
# second bits bytes
PATTERN1 1.0 2.0 160000 1500 PATTERN2 3.0 1.0 2000000 256 PATTERN3 4.0 3.0 500000 1000 PATTERN4 1.0 1.0 1000000 1000
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.
This file is for discrete event simulation only.
#format = unit unit_size
#interval = x (number of seconds)
#pvcname direction #unit unit_size #unit2 unit_size2
# format line may be one of the following:
# packet size
# byte size
# bit size
# size packet
# size byte
# size bit
format = packet size interval = 300 PVC1 A2Z 16,48,30,512,35,256,20,512 PVC1 Z2A 10,48,20,512,30,256 PVC2 A2Z 20,48,50,512 PVC2 Z2A 20,48,50,512
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.