• HOME
  • About
  • Program Plan
  • Annual Report
  • Joining CAIDA
  • Staff
  • Jobs
  • Legal Agreements
  • How-To
  • Blog
  • Contact Us
• CATALOG
  • Datasets
  • Media
  • Papers
  • Recipes
  • Software
• RESEARCH
  • Topology
  • Security
  • Traffic Analysis
  • Economics and Policy
  • Visualization
• DATA
  • Overview
  • Data Sharing
  • Distribution Statistics
  • How-to
  • Data Usage FAQ
  • Papers using CAIDA Data
  • Acceptable Use Agreement
• TOOLS
  • Overview
• SERVICES
  • AS Rank
  • AS Rank API
  • BGPStream
  • BGPStream API
  • HI-CUBE (login required)
  • IODA
  • MANIC
  • MANIC API
  • Vela
  • Vela web API
  • Vela MIDAR API
  • Vela aliasq API
• PUBLICATIONS
  • Papers
  • Presentations
  • Blog
  • Visualizations
  • - Animations
  • - Posters
  • Networking Bibliography
• WORKSHOPS
  • Overview
  • AIMS
  • DUST
  • IMAPS
  • KISMET
  • WIE
  • WOMBIR
  • Collaborative
  • Archive
• PROJECTS
  • Ark
  • KISMET
  • MANIC
  • Macroscopic Topology
  • Spoofer
  • Network Telescope
  • IMPACT (PREDICT)
• FUNDING
  • PANDA
  • FANTAIL
  • PENMAN
  • SLAM
  • Censorship Outages
  • MapKIT
  • STARDUST
  • MADDVIPR
  • Program Plan

Online Simulation & Control Standard Input Files

files and documentation:

The Online Simulation and Control project is providing scenarios for network simulation in files in standard formats. Different aspects of the scenario come in different files. There are several formats that the OSC project uses internally to specify scenarios. For distribution to the NM&S community, we are currently using a subset of that set of standards. This is done for simplicity and for incremental implementation. Once the community participants interested in using these scenarios have implemented these standards we can add other details to enable various uses for the scenarios.

To describe the entities and their mobility, we use a part of the SEAMLSS SDF format. To describe the traffic between the entities, we use a simple flow description format designed for this program. The flow description format is also an output format for online simulation and control. These data are supplied separately, because for many scenarios there are many different traffic loads that can be applied to the entities. We have, typically, in excess of a dozen different loads for a scenario.

The description being provided to NM&S is currently focussed on wireless third generation networks, which means that the scenario does not specify any links among the radios. Data also does not specify attributes of the radios; those are expected, for now, to be added using whatever radio model the modeler want to use. We have used four different radios.

The scenario description file defines a 64 node stationary simulation with simulated operational traffic. Online Simulation & Control (OSC) application was used to meter the Transport Layer of a simulation engine to create the output file "tpSendFlow.txt". A brief description of the files follows.

64node.sdf:The SDF file

Scenario Description Files (SDF) defines a scenario and are described as ASCII flat files in a grammar defined from the NetWars program. The grammar allows division of the file into sections. In each section there is a set of simple and complex attributes that may be defined.

Table 1 summarizes the meanings and usage of the keywords in the files. The section start/end keywords in the SDF take no arguments. The others keywords are followed by a sequence of arguments that contain the data that specifies the attributed information.

Table 1. Summary of keywords

The "ar:" keyword allows dynamic definition of an array of simple or complex attributes. It indicates that a specific number of instances of a particular keyword follow.

• ar: <array name>: <array length>

The "at:" keyword is for defining simple attributes attached to a section of the SDF.

• at: <attribute name>: <value>:<data type >

The "st:" keyword is for specifying the motion and status of the platforms.

• st:<time>:<latitude>:<longitude>:<altitude>:<psi>:<theta>:<phi>:<mission>:

An SDF contains an overall simulation definition section "si:" and a platform instance "pi:" section for each platform instance in the scenario. Each "pi:" section in the SDF is primarily used to assign unique IDs to a platform instance. The sections start and end keywords in the SDF take no arguments. Others keywords are followed by a sequence of arguments that contain the meta-data which specifies the attribute information.

si/es Section:

The "si:-es:" keywords denote the start and end of a simulation summary section in the SDF. This must be the first section in the SDF, however it may be proeceeded by comments. This section includes the following:

1. Global scenario descriptors and simulation controls specified by "at:" keywords

2. Default "at:" settings for entities, which may be overridden for individual entities.

Table 2 shows the current set of "at:" attributes that are expected in the si/es section.

Table 2. "at:" Attributes in simulation initialization, "si" section

SDF_Ver specifies the version of the SDF specification in which the SDF file is written.

OPSIT_Name is a unique name for the simulation execution that represents a combination of the scenario, the doctrine, the device and the purpose of the run. It is used for naming files and as a header for results.

Scenario_Name provides a name for the scenario as specified through the set of platforms, their mobility, their command hierarchy, the events (triggers) and other information.

The Start_Time and End_Time use time-zero matched to the time-zero set by the stimulator. Thus, the simulation starts when the time from the stimulator exceeds the Start_Time and ends when the time from the stimulator exceeds the End_Time.

The Start_Offset provides a time interval at the beginning of the simulation to start up the network before loading it with the scenario traffic.

The End_Offset provides a time interval after the end of the scenario to allow the completion of threads started during the scenario.

The SNMP_IP can be set to 1.0.0.1 to indicate that the SNMP messages are to be sent to the data collector on the same computer node as the simulation. Not needed if SNMP is off.

The Simulator and Simulator_IP fields identify the simulation engine used.

The Message_Source is used to determine whether the simulation is supposed to self-trigger based on the generation rules (internal) or whether it is supposed to wait for trigger events from the HLA federation.

The Mobility specifies the choice of algorithm for moving the entities. The options are:

• None — do not move entities
• Trajectory — use trajectories specified in the SDF.
• Random — Ignore the trajectories and move the entities with a random motion. (default)
• HLA — Receive the mobility from the HLA interface.

The Comms_Device specifies the default communications device for each platform. It is overridden by the value in the pi/ep section, if specified.

pi/ep Section:

These keywords denote the start and end of a platform section in the SDF. A pi/ep section exists for each instance of a platform in the scenario. The pi/ep keywords bracket a group of simple and complex attribute values for the platform instance.

Figure 3 provides a sample section. It includes identifiers for the attributes and some initial settings. It shows a structure that is convenient, but not necessary. The ar: keywords are now optional.

Each pi/ep section has attributes that identify each platform instance in multiple ways. Following are the various identifiers currently used. They are not all required for all runs. The need depends on the choice of other parameters. The order of their appearance does not need to match the above example.

The platform_name is unique to the instance.

The ip_address field provides an option to match the simulation to a real network.

The entity type is the type of entity as defined in the scenario or wargaming tool.

The comms_entity_type identifies the entity type as related to the use of comms.

The federate provides a default specification identifying the federate in which simulation federate entities are to be simulated.

The comms_device (a.k.a communications element) is the name of the device package used by the platform.

tpSendFlow.txt:

The ttpSendFlow.txt file is an OSC generated file that set to at a desired granularity for a simulation that records the bytes sent between nodes. The interval at which the byte counts are reported is determined at the start of the simulation. Flow files show the relationship between source host (Source Ip) and destination host (Dest Ip). The start and stop times (both reported in seconds) relate the time between the last report (Start) and this report (End). The other values relate the method of transfer (Protocol), the number of bytes sent and the number of packets sent. The "Bytes Sent" and "Pkts Sent" values relate the quantity since the last report (i.e. they are non-cumulative). The additional lines END INTERVAL and END RUN relate the last report for this interval, and the last report for the run of the simulation, respectively. The values in parentheses (i.e. t=5) allows one to keep their simulation clock in sync with clock of the producer.

# UID Start (s) End (s) Source Ip Dest Ip Protocol Bytes Sent Pkts Sent

# END INTERVAL (t=3)

# END INTERVAL (t=6)

# END INTERVAL (t=9)

# END INTERVAL (t=12)

0 12.0 15.0 0.0.0.21 0.0.0.27 UDP 176 1

1 12.0 15.0 0.0.0.31 0.0.0.29 UDP 704 4

2 12.0 15.0 0.0.0.45 0.0.0.41 UDP 176 1

3 12.0 15.0 0.0.0.69 0.0.0.67 UDP 176 1

# END INTERVAL (t=15)

4 15.0 18.0 0.0.0.3 0.0.0.9 UDP 176 1

5 15.0 18.0 0.0.0.5 0.0.0.9 UDP 176 1

6 15.0 18.0 0.0.0.9 0.0.0.27 UDP 704 4

7 15.0 18.0 0.0.0.11 0.0.0.49 UDP 176 1

8 15.0 18.0 0.0.0.13 0.0.0.49 UDP 176 1

9 15.0 18.0 0.0.0.15 0.0.0.49 UDP 176 1

10 15.0 18.0 0.0.0.23 0.0.0.27 UDP 176 1

11 15.0 18.0 0.0.0.25 0.0.0.27 UDP 176 1

12 15.0 18.0 0.0.0.27 0.0.0.9 UDP 176 1

13 15.0 18.0 0.0.0.31 0.0.0.29 UDP 2112 12

14 15.0 18.0 0.0.0.33 0.0.0.41 UDP 176 1

15 15.0 18.0 0.0.0.41 0.0.0.33 UDP 176 1

16 15.0 18.0 0.0.0.47 0.0.0.41 UDP 176 1

17 15.0 18.0 0.0.0.49 0.0.0.41 UDP 176 1

18 15.0 18.0 0.0.0.51 0.0.0.41 UDP 176 1

19 15.0 18.0 0.0.0.71 0.0.0.67 UDP 176 1

20 15.0 18.0 0.0.0.73 0.0.0.67 UDP 176 1

21 15.0 18.0 0.0.0.75 0.0.0.67 UDP 176 1

22 15.0 18.0 0.0.0.77 0.0.0.67 UDP 2112 12

23 15.0 18.0 0.0.0.93 0.0.0.119 UDP 1408 8

24 15.0 18.0 0.0.0.119 0.0.0.27 UDP 176 1

25 15.0 18.0 0.0.0.121 0.0.0.119 UDP 176 1

# END INTERVAL (t=18)