Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Specification File Overview

You can read or navigate to the files within the specification file folder. Table 1 mentions these file categories and lists the individual files present in it.

Table 1: Spec File Categories
Type of Files File Names
Backbone Files bblink, demand, domainfile, facility, graphcoord, group, muxloc, newdemand, nodeparam, owner, site, srvcprofile, and srvctype. See Table 2.
Cost Files custrate and usercost. See Table 3.
Control Files admincost, fixlink, linkdist, nodeweight, and rsvbwfile. See Table 3
Traffic Files devicedir, egress, ingress, t_trafficload, trafdir, trafficload, and tunneltrafdir. See Table 4.
Access Design Files chanbank, offckt, offgraphcoord, offloc, and offsitek.
Discrete Event Simulation tfxdata and tfxpattern. See Table 5.
Device-Specific Files aclist, bgplink, bgpnode, bgpobj, intfmap, junospolicy, policymap, route, tbit, tunnel, and vpn . See Table 6.

Table 2 describes the network backbone files that specify how the network is represented.

Table 2: Spec File Backbone Files List
File Description
bblink The bblink file contains backbone link information for the network. Each link entry is defined by a link name [optional], From_Location, To_Location, vendor, number of links, and link type. A vendor may be specified as DEF (default) if it is not known.
demand The demand file contains user traffic requirements. A demand is defined by an ID, From_Location, To_Location, Bandwidth, Type, Priority, and Preempt Priority.
domainfile The domainfile contains the definitions for domain elements. Domain elements are defined by ID, name, and color to be used in the Map window. If OSPF is present in the network, this file is used to define OSPF areas.
facility The facility file defines the links or nodes or both associated with a facility. In this file, the first field defines the facility name. The subsequent fields specify the node IDs or link names associated with that facility, delimited by tabs, spaces, or commas. All elements associated with a facility should be specified on the same line. Whenever more than one line is needed to specify the elements, a backslash, '\', must be used to indicate that the element list is continued on the next line. The facility feature does not check the validity of the nodes and/or links listed in the facility file. Duplicate links and/or nodes are also duplicated in the facility. Nodes may be specified either by their node ID or node name. If both are used in the same facility, then that node is duplicated. Nodes which are not in the mux file and links not in the bblink file are ignored.
graphcoord The graphcoord file is used to position nodes at coordinates different from their true geographic location. This is helpful when multiple nodes have the same NPANXX location or are located in close proximity to each other. You can move the nodes by selecting and dragging them to the desired location. The pricing information does not change because the change is only to the graphical representation and not a physical change.
group The group file defines the grouping of nodes in the network topology. Discs are painted on the Standard map around grouped nodes.
muxloc Muxloc specifies the file containing switch information such as name, ID, NPANXX, latitude, longitude, vertical, or horizontal. This information is used to determine location placement in the map window as well as for link pricing.
newdemand The newdemand file allows you to specify an additional file containing user traffic requirements besides the demand file. The purpose is to reduce your effort in manually modifying the existing demand file, and/or having multiple versions. In addition, the newdemand file is often used in theoretical "What if..." situations in determining capacity planning for the current network state.
nodeparam The nodeparam file allows you to define specific information on a per-node basis such as the hardware type, vendor, or model.
owner The owner file facilitates identifying the ownership of nodes and demands. Ownership should be specified in either the muxloc or demand files.
site The site file specifies site information. The site file is used to define nodes in the same physical location such as a building or campus.
service profile The service profile file lists the service types and the percentage that are in each service profile.
service type The service type file lists service types (for example, FTP, TELNET) and their descriptions (for example, owner, min. and max. bandwidth, type, pri, pre).

Table 3 describes the cost and control files which are used to assign tariffs and implement link controls.

Table 3: Cost and Control Files
File Description
custrate The custrate file is used to assign tariffs for links used in the network to approximate the total cost of the network. You can specify the parameters from which these tariffs are calculated using the modify custom rate and custom rate class windows.
usercost The usercost file is used to define the cost for links according to the end nodes, vendor, and link type.
admincost The admincost file contains rules to set each link default admin weight/metric according to attributes such as link type, mileage, and the hardware type and sites of the endpoints.
fixlink The fixlink file specifies information for links that cannot be removed from the backbone topology. For varying reasons, a customer might have a group of links in the backbone that cannot be removed (even if it is optimal to do so). In this case, during the optimization phase of the design, links from the fixlink file are not modified. Note that the bblink file might be used for the fixlink file if the current topology cannot be changed.
linkdist The linkdist file is used to define link distance values on a node pair basis. Link distances can be used to bias path routing by assigning either a higher or lower weight to a node pair. If a linkdist file is not specified or a particular link’s metric is not defined, and the Admin Weight routing method is specified in the design options of the Path Placement tab, the default link distance value is assigned.
nodeweight

The nodeweight file is used to restrict the creation of links at particular nodes during design by assigning to the node a penalty for adding links or the maximum bandwidth capacity for links. This file can also be used to restrict the transit demand bandwidth at a node if the hardware model supports path configuration for demands.

Every entry in the nodeweight file consists of four fields: node ID or name, node weight (link penalty for design), maximum bandwidth capacity (to carry links), and transit demand bandwidth limit. Fields are separated by spaces or tabs. A node weight is required if maximum link bandwidth capacity is to be specified.

rsvbwfile The rsvbwfile is used to define reserved bandwidth for links between specific node pairs. Reserved bandwidth is specified as a fixed bandwidth (fixfat) plus a percentage of the link bandwidth (fatpct).
Table 4: Traffic Files
File Description
egress The egress file contains egress traffic of the network interfaces load. Egress traffic specifies traffic that is going out of the network interfaces. This data is used for calculating link utilization and load.
ingress The ingress file contains ingress traffic of the network interfaces load. Ingress traffic specifies traffic that is going into the network interfaces. This data is used for calculating link utilization and load.
trafdir, tunneltrafdir

The trafdir file identifies the location of the daily interface traffic directories repository.

The tunneltrafdir file identifies the location of the tunnel traffic directories repository.

trafficload, t_trafficload

The trafficload file allows you to import measured bandwidth utilization based on data collected from the network. Traffic loads for each PVC can be specified over the time intervals for which the data was collected.

The t_trafficload file (IP/MPLS only) is similar to the trafficload file, but for LSP tunnels (layer 2 instead of layer 3).

Table 5: Discrete Event Simulation
File Description
tfxdata 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 network simulation results can be obtained in this manner.
tfxpattern 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).

Table 6 describes the device specific files that contain the definitions for various types of devices.

Table 6: Device-Specific Files
Field Description
aclist The aclist file (Router only) contains information about access rules such as access lists, distribute lists, and filter lists.
bgplink The bgplink file (Router only) contains the definitions for BGP neighbors.
bgpnode The bgpnode file (Router only) contains the definitions for BGP speakers.
bgpobj The bgpobj file (Router only)contains information about BGP neighbors and is stored in binary format to speed up performance. Note: If you want to manually edit bgpnode and bgplink, comment out this entry before reloading the network.
intfmap The intfmap file (Router only) contains information about router interfaces, including the node, interface, IP address, status, bandwidth, VPN-list, and other details.
policymap The policymap file (Router only) contains information about CoS Policies on each router.
tbit The tbit file (Router only) stores names for the tunnel attributes (otherwise referred to as admin group for Juniper Networks).
tunnel The tunnel file (Router only) contains information about LSP tunnels.
vpn The vpn file (Router only) contains information about Virtual Private Network details such as vrf, route distinguisher, route target, and protocols.