TULIP - Free protocol Simulator

The configuration file uses a simplified XML format. The structure is described within tulip.dtd file. It consists in a single root element <CONFIG>, in which is enclosed the hierarchy of configuration statements.

<TRAFFIC>: section which contains the test execution parameters. It may contain the following items:

<MODE> 0 or 1. Contains the mode used for test execution, usually corresponds to the protocol. If this anchor is not present, no mode library will be loaded.

Example:

<MODE>MEGACO</MODE>

<FORMAT> 0 or 1. Specify the format used to send/receive messages with the input pipeline. If equal to TEXT, the messages will be in text format (ASCII). If equal to hexa, messages will be described in hexadecimal format.

Example:

<SCENARIO> 0 or 1. Contains the root scenario file name, which will be executed first by Tulip. The file has to be located within source file lookup directory, otherwise a full path name may also be provided.

Example:

<NAME> 0 or 1. Name of the test scenario, not used right now (reserved for use by higher applicative layers).

Example:

<NAME>Common1</NAME>

<DESCRIPTION> 0 or 1. Description of the test scenario, not used right now (reserved for use by higher applicative layers).

Example:

<DESCRIPTION>Standard test</DESCRIPTION>

<DEBUG> 0 or 1. Used to control the application default trace level, the LEVEL attribute specifies the trace level at startup (from 0 to 4, can be modified during execution). A level of 0 means there is no trace and is the default value.

Example:

<ENVIRONMENT>: section which contains the test environmental parameters. It may contain the following items:

<LOCAL> 0 or 1: contains the local network socket description. Two attributes can be defined, “IP” is the local IPV4 address used, “PORT” is the transport level port used (UDP, TCP, SCTP).

<TEST> 0 or 1: activates the test input pipeline loop (see related section). The “OUPUT” attribute allows to redirecting the standard application output towards a file, or SCREEN (“SCREEN”, by default).

<REMOTE> 0 or more: declaration of a remote entity under test. By default, the first entry is the one used by application to send/receive packets. Le first attribute is the remote FQDN (fuly qualified domain name) or IPV4 address, contained in the “HOST” attribute. The “PORT” attribute contains the remote port.

<TRANSPORT> 0 or 1: specifies the options related to transport protocol:

- MODE: if equal to MONO, the same port will be used by all traffic agnets during test execution. If equal to MULTI, each agent will use a specific port within the specified range.

- ROLE: tulip supports two transport configurations. If the role is set to CLIENT, Tulip will connect to a distant server if applicable (ex, TCP server). If role is set to SERVER, tulip accepts connections from a remote client: no packet will be sent to a remote client until the connexion is established.

- PROTOCOL: specifies the transport protocol used by tulip. It can be equal to UDP (full UDP), TCP (full TCP) UDP_TCP/TCP_UDP (UDP+switch to TCP), and SCTP (full SCTP).

- RECONNECT: if equal to YES, the application will try to reconnect to the distant server if the connection is lost.

Example:

<INCLUDE_DIRECTORY> 0 or more: contains an additional source file lookup directory. Parameter not used right now (reserved for higher applicative layers).

Example:

<INCLUDE_DIRECTORY>C:\tulip/source</INCLUDE_DIRECTORY>

<INTERNAL_ROUTER> : section dedicated to the applicative routing criteria. It contains one or more <CRITERIA> anchors. A <CRITERIA> anchor contains the name of the criterion, specific to the chosen mode (ex, CONTEXT).

<AGENTS>: section containing the traffic agent declarations. Each declaration contains at least the “TYPE” attribute, which allows specifying the role of the agent in the chosen topology (CALLER, CALLED... see dedicated documentation).

Each declaration depends on the chosen mode, and has the following format:

<AGENT_name_mode att1="valAtt1" att2="valAtt2" att3="valAtt3" …/>

Example:

<AGENT_MEGACO TYPE="CALLER" TERM="P/1" ND="02420001"/>

The test agents are declared in a generic way:

<!ELEMENT AGENT_TEST>

<!ATTLIST AGENT_TEST

TYPE (CALLER | CALLED | MGC | OTHER | POOL)

ID ID

According to the chosen test configuration (ex, CALLER+CALLED), the agents are paired in the same order of declaration. Therefore, the n^th agent with type CALLER is associated to the n^th CALLED agent.

<DECLARE>: optional section to declare constants and variables.

- <VARIABLE> : variable declaration, the “NAME” attribute contains the variable name (unique), the “TYPE” attribute contains the variable type, ad the attribute “VALUE” corresponds the variable value (text or hexa format). See dedicated section for more details.

- <CONSTANT> : constant declaration, the "NAME" attribute contains the constant name, while "VALUE" contains the value. During compilation, constants are replaced with their values.

Example:

</DECLARE>

<COLLECTOR> : element used to declare statistic collection parameters. It has the following attributes:

- ALL_AGENTS: if set to YES, the sum of all counters is displayed.

- AGENT_SUMMARY: if set to YES, tulip displays the sum counters related to each traffic agent.

- AGENT_DETAIL: if set to YES, tulip displays the fault counters per agent, broken by state number.

- LOG_ANALYSIS: if set to YES, tulip performs traffic analysis based on the statistics collected.

- RESPONDER_LOG: if set to YES, statistics are also collected for responder (+ test responder).

- PERIOD: periodicity for statistics counters collection/display.

Example:

<SCHEDULER>: element containing execution scheduling parameters:

- INTERSIMU: number of time unit between two traffic agent group activation (typically, one call leg).

- UNIT: time unit, S or MS (seconds or milliseconds).

- SIMULTANEOUS: number of traffic agents activated at each time interval.

- PERIODS: number of periods until the end of traffic. When this number is reached, the application stops. By default, equal to zero (unlimited).

Example:

<COMMANDER>: declaration of a commander instance. According to the enclosed attribute "MODE", it can have three types:

LOCAL: commander using the standard input (keyboard by default). This allows interactive control of a running tulip instance by the user. In this case, the attribute « NAME» is used to identify the commander.

REMOTE: master network commander, located on a remote machine. In this case, the current tulip instance is controlled by a remote commander running elsewhere on the network (or on the same computer). The FQDN provided (fully qualified domain name) or IPV4 adress, are contained in « HOST» attribute. The «PORT» attribute contains the local TCP port used for management messages. The «NAME» attribute is not used. The attributes LOG + STATS allow to redirect the log/statistics flows towards the master commander, or to keep it on the local output.

SERVER: slave network commander, located on another machine. The “HOST” attribute contains the FQDN/IP of the commander, while “PORT” contains the port on the remote machine. The "NAME" attribute is used to identify the commander during execution (for remote control). The attributes LOG/STATS are not used in this case.

Example:

Configuration File

Home page