---
Author: Eduard Czimbalmos
Version: 155 17-CNL 113 739, Rev. A
Date: 2012-06-14
---
= IP Daemon Dynamic for TTCN-3 Toolset with TITAN, Function Specification
:author: Eduard Czimbalmos
:revnumber: 155 17-CNL 113 739, Rev. A
:revdate: 2012-06-14
:toc:

= Introduction

== How to Read this Document
This is the Function Specification for the IP Daemon Dynamic (IPDD). IPDD is developed for the TTCN-3 Toolset with TITAN. This document should be read together with Product Revision Information <<_2, [2]>>.

== 	Scope

The purpose of this document is to specify the functionality of the IP Daemon Dynamic application.

== References

[1] [[_1]]ETSI ES 201 873-1 v.3.1.1 (2005-06) +
The Testing and Test Control Notation version 3. Part 1: Core Language

[2] [[_2]]109 21-CNL 113 739-1 Uen +
IP Daemon Dynamic for TTCN-3 Toolset with TITAN, Product Revision Information

[3] [[_3]]RFC 1006 +
ISO transport services on top of the TCP: Version 3

[4] [[_4]]198 17-CNL 113 739 Uen +
IP Daemon Dynamic for TTCN-3 Toolset with TITAN, User’s Guide

[5] [[_5]]155 17-CNL 113 531 Uen +
IPL4 Test Port for TTCN-3 Toolset with TITAN, Function Specification

[6] [[_6]]1/198 17-CRL 113 200 Uen +
TITAN User’s Guide

[7] [[_7]]198 17-CNL 113 531 Uen +
IPL4 Test Port for TTCN-3 Toolset with TITAN, User’s Guide

[8] [[_8]]6/198 17-CRL 113 200 Uen +
PROGRAMMER'S GUIDE API Technical Reference for TITAN TTCN-3 Test Executor

== Abbreviations

PPID:: Payload Protocol Identifier
RTE:: Run-Time Environment
SCTP:: Stream Control Transmission Protocol
UDP:: User Datagram Protocol
IPDD:: IP Daemon Dynamic
SUT:: System Under Test
TCP:: Transmission Control Protocol
TTCN-3:: Testing and Test Control Notation version 3

== Terminology

IPDD:: IP Daemon Dynamic, the abbreviation of this product

= General

IPDD provides the following features to a testcase:

* defining server and client connections
* SCTP, TCP or UDP payload relaying from the SUT via TCP connections between IPDD and the testcases
* keeping connections alive between testcases
* reconnect disconnected client connections
* dynamically create new SCTP client and server associations from the testcase
* close client and server connections from the testcase
* subscribe to connection events, if the connections are already present
* API to allow automatic handling of incoming messages (i.e. heartbeat messages) and events
* API to allow sending messages when a connection initiates (auto-startup functions)
* function callbacks that allow the user to extend the daemon so that routing can be implemented based on upper layer protocols
* automatic shutdown after an inactivity period

The usage of these features can be found in <<_4, [4]>>.

= Functional specification

The outline of the IPDD’s architecture can be seen in <<figure-1, Figure 1>>. IPDD is a standalone application, which is executed independently of the TTCN-3 testcases. This results that the SCTP, TCP and UDP connections remain active between the executions of testcases.

When the IPDD is started, it connects the configured client IP connections to the SUT, opens the configured server IP connections, and starts listening on a TCP port for incoming connection requests from the users (testcases). After the daemon accepted a TCP connection request, the IP messages sent by the testcase are forwarded to the selected IP connection.

Naturally, the answers coming from the SUT are relayed back to the user as well. Thus, IPDD provides an interface to access SCTP, TCP or UDP communication ports via TCP connections.
The daemon tries to re-establish client IP connections that were interrupted and in case of SCTP, the testcases are notified if the corresponding SCTP connection is lost or becomes active again. In case of TCP, connection opened and connection closed messages are sent.

[[figure-1]]
image::images/architecture.png[title="IP Daemon Dynamic architecture"]

== TCP Interface

The messages between IPDD and the daemon users are sent over one or more TCP connections, which are handled by IPL4 test port <<_7, [7]>>.The IPDD source code contains a dual-faced (see for ‎<<_8, [8]>> details) port definition `IPDD_Interface_P`T, which is used by the testcase and the IPDD to communicate with each other.

== IP interface

To handle IP connections, IPDD relies on the IPL4asp test port <<_5, [5]>>, thus the supported SCTP, TCP and UDP specifications also apply here. The user can control the SCTP, TCP or UDP connection Id, and in case of SCTP, the stream Id and PPID. The testcase can also assign a specific local address for each IP connection.

== Configuration

IPDD can be configured using the TITAN RTE configuration file. The description of the specific parameters can be found in the IP Daemon Dynamic User’s Guide <<_4, [4]>>.

== Logging

The logging mechanism logs information either to the log file or output console. The user can set the amount and type of logging in the configuration file. These logging options are described in <<_6, [6]>>.

== Error Handling

Erroneous behaviour detected during runtime is directed into the RTE log file. The following two types of messages are taken care of:

* Errors: information about errors detected is provided. If an error occurs the execution of the test case will stop immediately. The test ports will be unmapped.
* Warnings: information about warnings detected is provided. The execution continues after the warning is shown.

== Limitations

* To handle IP connections, IPDD relies on the IPL4asp test port. Therefore, the limitations described in <<_5, [5]>> also apply here.
* Several testcases can subscribe to the same association. If the association is closed by one of the testcases, the others are not notified about it.