Technical Documentation: General Design of the SA

From Go4IT project

Contents 1 Introduction 2 Use Cases 2.1 Use Cases for Core Protocol ATS (See [8]) 2.1.1 UC-C.1: Starting SA 2.1.2 UC-C.2: Setting-up SA using configuration CF01 2.1.3 UC-C.3: Setting-up SA using configuration CF02 2.1.4 UC-C.4: Setting-up SA using configuration CF02_HS01 2.1.5 UC-C.5: Setting-up SA using configuration CF03 2.1.6 UC-C.6: Setting-up SA using configuration CF03_RT01 2.1.7 UC-C.7: Setting-up SA using configuration CF01 with Upper Tester 2.1.8 UC-C.8: PDU Transmission to SUT 2.1.9 UC-C.9: PDU Reception from SUT 2.1.10 UC-C.10: Service Primitives 2.1.11 UC-C.11: Remote configuration of IUT 2.2 Use Cases for RIPng ATS (See [6]) 2.2.1 UC-R.1: Starting SA 2.2.2 UC-R.2: Setting-up test topology TT_01 for execution 2.2.3 UC-R.3: Setting-up ports to transmit test information 2.2.4 UC-R.4: PDU Transmission to IUT 2.2.5 UC-R.5: PDU Reception from SUT 2.2.6 UC-R.6: Resetting SA 3 Functional Requirements 3.1 Functional Requirements for Core Protocol ATS (See [8]) 3.1.1 FR-C.1: Construct a list of available network interfaces 3.1.2 FR-C.2: Set-up MAC parameters 3.1.3 FR-C.3: Open network interface 3.1.4 FR-C.4: Map network interfaces and TE 3.1.5 FR-C.5: Sending messages 3.1.6 FR-C.6: Receiving messages 3.1.7 FR-C.7: Filtering Capabilities 3.1.8 FR-C.8: Automated IUT set up 3.1.9 FR-C.9: Automated IUT data communication 3.1.10 FR-C.10: Safety shutdown 3.2 Functional Requirements for RIPng ATS (See [6]) 3.2.1 FR-R.1: Map network interfaces and TE 3.2.2 FR-R.2: Sending messages 3.2.3 FR-R.3: Receiving messages 4 Nonfunctional Requirements 4.1 NF-1: Documentation 4.2 NF-2: Maintainability 4.3 NF-3: Reliability 4.4 NF-4: Extensibility 4.5 NF-5: Performance 4.6 NF-6: Efficiency 4.7 NF-7: Platform Compatibility 4.8 NF-8: Dependency on other parties 5 Annex A – Test architecture to be supported by SA 5.1 Test architecture for Core Protocol ATS (See [8]) 5.2 Test architecture for RIPng ATS (See [6])

Introduction

This document intends to provide a preliminary introduction to the design of the System Adaptor (hereafter, SA) entity whithin a TTCN-3 test system. This entity is responsible for adapting the TTCN-3 communication operations with the SUT based on an abstract test system interface and implements the real test system interface.

The design of this SA module has been performed according to two different ATSs: IPv6 Core protocol (See [8]) and RIPng protocol (See [6]).

Use Cases

This section contains a set of use cases that describe the external behavior of this TM module. A use case is a description of a specific interaction that a user (or another module) may have with this module. Use cases are deceptively simple tools for describing the functionality of the software.

A use case is a simple, straightforward tool that can be used to completely describe all the behavior of a piece of software. It contains a textual description of all the ways that the intended users could work with the software through its interface. Use cases do not describe any internal workings of the software, nor do they explain how that software will be implemented. They simply show the steps that the user follows to use the software to do the work. All the ways the users interact with the software can be described in this manner.

This section will contain multiple use cases, enough to define all of the interactions the users will have with the module.

In the following figure a general overview of defined use cases and relationships between the different actors (i.e., users) which have been defined in this section is shown.

Use Cases for Core Protocol ATS (See [8])

UC-C.1: Starting SA

Sumary

Every component conforming SA are started and ready to be initialized.

Rationale

When a test case (TC) is going to be executed, SA must be ready to be initialized. SA consists of software components such as protocol layers conforming lower tester (LT) and upper tester (UT). In general, the protocol behaviour is defined by state machines and must be started and prepared into idle state. Also the devices supporting the physical layer require power supply and need to be switched on (system hosting the SA will abstract this feature via Enable/Disable device command).

Actors

TE

Preconditions

There are no preconditions because this is the initial use case.

Basic Course of Events

• Step1: TE is started (control part of TTCN-3 test system implementation).
• Step2: SA enables network interface devices conforming UT and LT.
• Step3: SA reset network interfaces devices bringing the protocols conforming the LT and UT into idle state.
• Step4: TE is ready to execute a test case.

Alternative Paths

1. There is no alternative path because UC-C.1 is common for all the test configurations.

Postconditions

SA components can be set up and TE can execute a test case.

UC-C.2: Setting-up SA using configuration CF01

Summary

TE interacts with IUT via SA using test configuration CF01 (extracted from [8]).

Rationale

CF01 is the basic configuration for router or host test. When TC to be executed uses this configuration, every component conforming SA must be configured properly in order to support the configuration CF01 according to ATS Document.

Actors

TE.

Preconditions

All the components conforming the SA must be started.

Basic Course of Events

• Step1: TE gets a list of the available network interfaces: name and description.
• Step2: TE selects according to the PIXIT one network interface (LT): Ethernet, ATM, token ring or ppp port.
• Step3: TE establishes the normal mode (not-promiscuous) for network interface selected.
• Step4: TE establishes the unicast MAC address for LT.
• Step5: TE establishes the MAC Solicited-Node multicast address for LT.
• Step6: TE establishes the IPv6 Link Local address for LT.
• Step7: TE establishes the IPv6 Global address for LT.
• Step8: TE establishes the IPv6 Solicited-Node multicast address for LT.
• Step9: TE establishes the logical connection with the Service Access Point (SAP) on the network adapter selected for LT.

Alternative Paths

1. There are no alternative paths.

Postconditions

TE is ready to communicate with the IUT.

NOTE: C01 is the test component 01.

UC-C.3: Setting-up SA using configuration CF02

Summary

TE interacts with IUT via SA using test configuration CF02 (extracted from [8]).

Rationale

CF02 is the basic configuration for router test. When TC to be executed uses this configuration, every component conforming SA must be configured properly in order to support the configuration CF02 according to ATS Document.

Actors

TE.

Preconditions

All the components conforming the SA must be started.

Basic Course of Events

• Step1: TE gets a list of the available network interfaces: name and description.
• Step2: TE selects according to the PIXIT two network interfaces (A and B): Ethernet, ATM, token ring or ppp port.
• Step3: TE establishes the normal mode (not-promiscuous) for the network interfaces selected.
• Step4: TE establishes the unicast MAC address for ‘A’ and ‘B’ interfaces.
• Step5: TE establishes the MAC Solicited-Node multicast address for ‘A’ and ‘B’ interfaces.
• Step6: TE establishes the IPv6 Link Local address for ‘A’ and ‘B’ interface.
• Step7: TE establishes the IPv6 Global address for ‘A’ and ‘B’ interface.
• Step8: TE establishes the IPv6 Solicited-Node multicast address for ‘A’ and ‘B’ interfaces.
• Step9: TE establishes the logical connection with the Service Access Point (SAP) on the network adapters ‘A’ and ‘B’. In this configuration, TE consists of two users of the SA adaptor (each one exciting both interfaces of the IUT).

Alternative Paths

1. There are no alternative paths.

Postconditions

TE is ready to communicate with the IUT.

NOTES:

• HS01 is the host 1.
• HS02 is the host 2.

UC-C.4: Setting-up SA using configuration CF02_HS01

Summary

TE interacts with IUT via SA using test configuration CF02_HS01 (extracted from [8]).

Rationale

CF02_HS01 is the basic configuration for router test and therefore only one interface of the IUT is going to be tested. When the test case to be executed uses this configuration, every component conforming SA must be configured properly in order to support the configuration CF02_HS01 according to ATS document.

Actors

TE.

Preconditions

All the components conforming the SA must be started.

Basic Course of Events

• Step1: TE gets a list of the available network interfaces: name and description.
• Step2: TE selects according to the PIXIT two network interfaces (A and B): Ethernet, ATM, token ring or ppp port.
• Step3: TE establishes the normal mode (not-promiscuous) for the network interfaces selected.
• Step4: TE establishes the unicast MAC address for ‘A’ and ‘B’ interfaces.
• Step5: TE establishes the MAC Solicited-Node multicast address for ‘A’ and ‘B’ interfaces.
• Step6: TE establishes the IPv6 Link Local address for ‘A’ and ‘B’ interface.
• Step7: TE establishes the IPv6 Global address for ‘A’ and ‘B’ interface.
• Step8: TE establishes the IPv6 Solicited-Node multicast address for ‘A’ and ‘B’ interfaces.
• Step9: TE establishes the logical connection with the Service Access Point (SAP) on the network adapters ‘A’ and ‘B’. In this configuration, TE consists of two users of the SA adaptor (each one exciting both interfaces of the IUT).

From the SA point of view, the network adaptor management (i.e. link and physical OSI layer) is the same regardless of IUT is either Router or Host. In this use case, IUT is a router, but only one interface is under test and therefore SA only must start and configure the components related to this interface.

Alternative Paths

1. There are no alternative paths.

Postconditions

TE is ready to communicate with the IUT.

NOTE: HS01 is the host 1

UC-C.5: Setting-up SA using configuration CF03

Summary

TE interacts with IUT via SA using test configuration CF03 (extracted from [8]).

Rationale

CF03 is the basic configuration for host test. When TC to be executed uses this configuration, every component conforming SA must be configured properly in order to support the configuration CF03 according to ATS Document.

Actors

TE.

Preconditions

All the components conforming the SA must be started.

Basic Course of Events

• Step1: TE gets a list of the available network interfaces: name and description.
• Step2: TE selects, according to the PIXIT information, two network interfaces (A and B): Ethernet, ATM, token ring or ppp port can be supported.
• Step3: TE establishes the normal mode (not-promiscuous) for the network interfaces selected.
• Step4: TE establishes the unicast MAC address for ‘A’ and ‘B’ interfaces.
• Step5: TE establishes the MAC Solicited-Node multicast address for ‘A’ and ‘B’ interfaces.
• Step6: TE establishes the IPv6 Link Local address for ‘A’ and ‘B’ interfaces.
• Step7: TE establishes the IPv6 Global address for ‘A’ and ‘B’ interfaces.
• Step8: TE establishes the IPv6 Solicited-Node multicast address for ‘A’ and ‘B’ interfaces.
• Step9: TE establishes the logical connection with the Service Access Point (SAP) on the network adapters ‘A’ and ‘B’. In this configuration, TE consists of two users for the SA adaptor (each one exciting one interface of the IUT).

Alternative Paths

1. There are no alternative paths.

Postconditions

TE is ready to communicate with the IUT. In figure below, it is important to remark that Net B and Net C management are out of the scope of SA.

NOTES:

• HS01 is the host 1.
• HS03 is the host 3.
• RT01 is the router 1.
• RT03 is the router 3

UC-C.6: Setting-up SA using configuration CF03_RT01

Summary

TE interacts with IUT via SA using test configuration CF03_RT01 (extracted from [8]).

Rationale

CF03 is the basic configuration for host testing. In this situation, only the interface between TE and the IUT is going to be tested. When TC to be executed uses this configuration, every component conforming SA must be configured properly in order to support the configuration CF03_RT01 according to ATS Document.

Actors

TE.

Preconditions

All the components conforming the SA must be started.

Basic Course of Events

• Step1: TE gets a list of the available network interfaces: name and description.
• Step2: TE selects according to the PIXIT one network interface (LT): Ethernet, ATM, token ring or ppp port.
• Step3: TE establishes the normal mode (not-promiscuous) for network interface selected.
• Step4: TE establishes the unicast MAC address for LT.
• Step5: TE establishes the MAC Solicited-Node multicast address for LT.
• Step6: TE establishes the IPv6 Link Local address for LT.
• Step7: TE establishes the IPv6 Global address for LT.
• Step8: TE establishes the IPv6 Solicited-Node multicast address for LT.
• Step9: TE establishes the logical connection with the Service Access Point (SAP) on the network adapter selected for LT.

Alternative Paths

1. There are no alternative paths.

Postconditions

TE is ready to communicate with the IUT.

NOTE:

• HS02 is the host 2.
• RT01 is the router 1.

UC-C.7: Setting-up SA using configuration CF01 with Upper Tester

Summary

TE interacts with IUT via SA using test configuration CF01 with upper tester (extracted from [8]).

Rationale

CF01 is the basic configuration for router or host test. Upper Tester (UT) enables the TE to send and receive service primitives to/from the upper interface of the IUT. In this Use Case, the element to be tested is the implementation under test as a stand-alone protocol layer. When TC to be executed uses this configuration, every component conforming SA must be configured properly in order to support the configuration CF01 according to ATS Document. In addition to set up the SA, TE establishes networks parameters into IUT according to the PIXIT values.

Actors

TE.

Preconditions

All the components conforming the SA must be started. IUT must implement an Upper Tester server.

Basic Course of Events

• Step1. TE gets a list of the available network interfaces: name and description.
• Step2. TE selects according to the PIXIT two network interfaces (LT and UT): Ethernet, ATM, token ring or ppp port.
• Step3. TE establishes the normal mode (not-promiscuous) for network interface selected.
• Step4. TE establishes the unicast MAC address for LT and IUT.
• Step5. TE establishes the MAC Solicited-Node multicast address for LT and IUT.
• Step6. TE establishes the IPv6 Link Local address for LT and IUT.
• Step7. TE establishes the IPv6 Global address for LT and IUT.
• Step8. TE establishes the IPv6 Solicited-Node multicast address for LT and IUT.
• Step9. TE establishes the logical connection with the Service Access Point (SAP) on the network adapter selected for LT.
• Step10. TE establishes the logical connection with the Service Access Point (SAP) on the network adapter selected for UT.

Alternative Paths

1. There are no alternative paths.

Postconditions

TE is ready to communicate with the IUT. The service primitives between TE (UT functionality) and SUT may use network interface, but it is not mandatory (e.g., it may use a well-defined API using a non distributed solution).

NOTE:

• C01 is the test component 01.

UC-C.8: PDU Transmission to SUT

Summary

TE interacts with IUT via SA sending PDUs.

Rationale

While TE sends raw data at layer 3 level, SA gets this data and sends the PDU to the IUT via the appropriate logical connection. SA is responsible for ensuring PDUs received from TE are sent to IUT.

Actors

TE and IUT.

Preconditions

All the components conforming the SA must be started and properly configured according to the test configuration selected.

Basic Course of Events

• Step1. SA receives encoded (according to the Base Specification) data from TE.
• Step2. SA identifies which TSI (Test System Interface) port (i.e. interface point between TE and SA) is being used.
• Step3. SA identifies which Test Component (i.e., node functionality implemented by TE such as C01, HS01, HS02, etc.) is sending the PDU.
• Step4. SA maps the TSI port and the logical connection established when the test configuration was set up.
• Step5. SA confirms the correct transmission to the TE.

Alternative Paths

1. The alternative behaviour is directly related to the result of the mapping performed in step 4

Postconditions

IUT receives the PDU data from the TE.

UC-C.9: PDU Reception from SUT

Summary

TE interacts with IUT via SA receiving PDUs.

Rationale

While IUT sends raw data at layer 3 level, SA gets this data and sends the PDU to the TE via the appropriate logical connection. SA is responsible for ensuring PDUs received from IUT are sent to TE.

Actors

TE and IUT.

Preconditions

All the components conforming the SA must be started and properly configured according to the test configuration selected.

Basic Course of Events

• Step1. SA receives raw data from IUT.
• Step2. SA identifies which logical connection (established when the test configuration was set up) is being used.
• Step3. SA maps the TSI port and the logical connection identified.
• Step4. SA identifies which Test Component (i.e. node functionality implemented by TE such as C0, HS01, HS02, etc.) is the destination of the PDU.
• Step5. SA confirms the correct reception by the TE.

Alternative Paths

1. The alternative behaviour is directly related to the result of the mapping performed in step 3.

Postconditions

TE decodes the PDU data received and the correct reception of the PDU by the TE.

UC-C.10: Service Primitives

Summary

UT client within TE interworks with the UT server inside of the SUT.

Rationale

During test execution, TE controls and observes the upper service boundary of the IUT.

Actors

TE and IUT.

Preconditions

All the components conforming the SA must be started. IUT must implement an Upper Tester server and TE must implement an UT client.

Basic Course of Events

• Step1. TE sends PDUs through SA to IUT.
• Step2. To perform step 1, SA sends the proper SP (Service Primitive) to the lower service boundary of the IUT.
• Step3. When IUT receives PDU, it sends SP via upper service boundary to the Upper Tester through the SA.
• Step4. IUT sends PDU through SA to IUT.
• Step5. To perform step 4, SA sends the proper SP (Service Primitive) from the UT to the upper service boundary of the IUT.
• Step6. When IUT receives the SP, it sends SP via lower service boundary to the LT through the SA.

Alternative Paths

1. There are no alternative paths.

Postconditions

IUT sends PDU through SA to IUT and SA sends the proper SP from the UT to the upper service boundary of the IUT.

UC-C.11: Remote configuration of IUT

Summary

TE sets up the IUT remotely.

Rationale

TE establishes networks parameters into IUT according to the PIXIT values.

Actors

TE and IUT.

Preconditions

All the components conforming the SA must be started.

Basic Course of Events

• Step1: TE establishes remotely the unicast MAC address for IUT.
• Step2: TE establishes remotely the MAC Solicited-Node multicast address for IUT.
• Step3: TE establishes remotely the IPv6 Link Local address for IUT.
• Step4: TE establishes remotely the IPv6 Global address for IUT.
• Step5: TE establishes remotely the IPv6 Solicited-Node multicast address for IUT.
• Step6: TE establishes the logical connection with the Service Access Point (SAP) on the network adapter selected for LT.

Alternative Paths

1. No alternative paths determined.

Postconditions

IUT is properly configured.

Use Cases for RIPng ATS (See [6])

UC-R.1: Starting SA

Sumary

Every component conforming SA must be started and ready to be initialized.

Rationale

When a test case (TC) is going to be executed, SA must be ready to be initialized. In general, the protocol behaviour is defined by state machines and must be started and prepared into idle state. Also the devices supporting the physical layer require power supply and need to be switched on (system hosting the SA will abstract this feature via Enable/Disable device command).

Actors

TE.

Preconditions

There are no preconditions because this is the initial use case.

Basic Course of Events

• Step1: TE is started (control part of TTCN-3 test system implementation).
• Step2: Initialisation of SA structures
• Step3: TE is ready to start the execution of a test case.

Alternative Paths

1. No alternative paths have been identified.

Postconditions

SA components have been set up and therefore TE is ready to start the execution of a test case.

UC-R.2: Setting-up test topology TT_01 for execution

Summary

TE interacts with IUT via SA using a test topology TT_01.

Rationale

TT_01 is the basic configuration for router test. When TC to be executed uses this configuration, every component conforming SA must be configured properly in order to support the configuration TT_01 according to ATS Document.

Actors

TE.

Preconditions

There are no preconditions because this is the initial use case.

Basic Course of Events

• Step1: TE gets a list of the available network interfaces: name and description.
• Step2: TE selects, according to the PIXIT information, network interfaces (Ethernet interfaces) where test information is going to be exchanged with the IUT.
• Step3: TE establishes the promiscuous for network interface selected.
• Step4: TE sets up structures representing the test system ports.
• Step5: The test system port is mapped to a TTCN-3 component port.
• Step6: The Ethernet interface is opened and start a listening thread.

Alternative Paths

1. In case of error selecting network interfaces (e.g., they are already in use), everything must be stopped.

Postconditions

TE is ready to communicate with the IUT.

TR.1-TR.5: Test Router 1 to Test Router 5.

UC-R.3: Setting-up ports to transmit test information

Sumary

TE interacts with IUT via SA using ports where test information is going to be exchanged.

Rationale

When a test case is going to be executed, SA must initialize ports for communication purposes. SA must perform operations required for the proper execution of the test case.

Actors

TE.

Preconditions

All the components conforming the SA must be started.

Basic Course of Events

• Step1: When TE is going to execute a test case, related port (Ethernet of logging information port) shall be created.
• Step2: This port must be properly initialized (see UC-R.2).
• Step3: After, the creation of this test system port, it shall be properly mapped to the correspondent TTCN-3 component port.

Alternative Paths

1. In step 1, a port is created. If there is an error, everything shall be stopped.
2. In step 3, ports shall be mapped to the correspondent test components. In there is an error, everything shall be stopped.

Postconditions

SA is ready to communicate with IUT, because Ethernet interface is ready to send/receive messaged to/from the IUT.

UC-R.4: PDU Transmission to IUT

Sumary

TE interacts with IUT via SA sending PDUs.

Rationale

While TE sends raw data at layer 4 level. SA gets this data and sends the PDU to the IUT via the appropriate logical connection. SA is responsible for ensuring PDUs received from TE are sent to IUT.

Actors

TE and IUT.

Preconditions

All the components conforming the SA must be started and properly configured according to the test configuration.

Basic Course of Events

• Step1: SA receives encoded data from TE.
• Step2: SA identifies which TSI (Test System Interface) port (i.e. interface point between TE and SA) is going to be used.
• Step3: SA identifies which test component is sending the PDU.
• Step4: SA maps the TSI port and the logical connection established when the test configuration was set up.
• Step5: SA sends the message to the IUT.
• Step6: SA confirms the correct transmission to the TE.

Alternative Paths

1. The alternative behaviour is directly related to the result of the mapping performed in step 4.

Postconditions

IUT receives the PDU data from the TE.

UC-R.5: PDU Reception from SUT

Sumary

TE interacts with IUT via SA receiving PDUs.

Rationale

While IUT sends raw data at layer 2 level, SA gets this data and sends the PDU to the TE via the appropriate logical connection. SA is responsible for ensuring PDUs received from IUT are sent to TE.

Actors

TE and IUT.

Preconditions

All the components conforming the SA must be started and properly configured according to the test configuration selected.

Basic Course of Events

• Step1: SA receives raw data from IUT.
• Step2: SA identifies which logical connection (established when the test configuration was set up) is being used.
• Step3: SA maps the TSI port and the logical connection identified.
• Step4: SA identifies which Test Component (i.e. node functionality implemented by TE such as TR.1, TR.2, TR.3, etc.) is the destination of the PDU.
• Step5: SA confirms the correct reception by the TE.

Alternative Paths

1. The alternative behaviour is directly related to the result of the mapping performed in step 3.

Postconditions

TE decodes the PDU data received and the correct reception of the PDU by the TE.

UC-R.6: Resetting SA

Sumary

TE resets the SA.

Rationale

This operation can be called by the TE at any time to reset the SA.

Actors

TE and IUT.

Preconditions

All the components conforming the SA must be started.

Basic Course of Events

• Step1: TE wants to reset the established communications with the IUT.
• Step2: The SA shall reset all communication means that it is maintaining, e.g. reset static connections to the IUT, close dynamic connections to the SUT, discard any pending messages or procedure calls.

Alternative Paths

1. In step 2, the SA shall reset all communications established with IUT. If there is an error, an error indication shall be sent to the TE.

Postconditions

IUT is properly configured.

Functional Requirements

Functional Requirements for Core Protocol ATS (See [8])

FR-C.1: Construct a list of available network interfaces

Summary

Construct a list of network interfaces that can be opened and properly configured i.e., in terms of test architecture, to make available the underlying service provider.

Rationale

Underlying service provider must be available in order to enable the communication between the TE and the IUT.

Requirements

All the listed network interfaces can be opened if needed.

Information provided with every network interface must be:

• Type of Media Access Control (MAC) protocol.
• Unique identifier.
• State: busy or free.

References

TCI Implementor routine: tciRootModule, tciGetModule, tciGetTestCases

UC-C.2, UC-C.3, UC-C.4, UC-C.5, UC-C.6 and UC-C.7.

FR-C.2: Set-up MAC parameters

Summary

Availability of TE for establishing the MAC parameters of the underlying service provider.

Rationale

Proper parameterization of underlying service provider enabling the communication between the TE and the IUT is needed. The parameterization is made according to the PIXIT information.

Requirements

Control channel is established between test component (configuration port) and underlying service provider.

These messages are configuration commands.

All test configurations described in Annex A must be supported.

Each of the listed network interfaces (FR-1) must be configured.

The items to be configured are:

• First Unicast MAC Address.
• Second Unicast MAC Address.
• MAC Solicited-Node Multicast Address.

The number of network interfaces to be configured depends on the Test Configuration selected (i.e., the number of service providers needed).

References

TRI Implementor routine: triExecuteTestCase and triMap.

UC-C.2, UC-C.3, UC-C.4, UC-C.5, UC-C.6 and UC-C.7.

FR-C.3: Open network interface

Summary

Open the connection at link layer.

Rationale

To provide logical connection between tests components conforming the TE and the network interface conforming the underlying service providers.

Requirements

The input to open a network interface must be the string that specifies a network interface and used to fill the list of network interfaces (FR-1).

The functional mode opened is normal (no promiscuous).

The number of network interfaces to be opened depends on the Test Configuration selected (i.e., the number of service providers needed) described in Annex A.

References

TRI Implementor routine: triExecuteTestCase.

UC-C.8 and UC-C.9.

FR-C.4: Map network interfaces and TE

Summary

Logical connection between TE and underlying service providers.

Rationale

To establish the logical connection between each test component conforming the TE and each network interface conforming one underlying service provider.

Requirements

The input to map a network interface must be:

• TSI ports at the lower boundary of TE interface.
• Test component identifier (e.g. HS01, HS02, etc,) at the lower boundary of TE interface.
• Connection identifier (achieved in FR-3) at the upper boundary of Service Provider interface.

The number of network interfaces to be mapped depends on the Test Configuration selected (i.e., the number of services providers needed) described in Annex A.

Mapping for all test configurations must be supported.

References

TRI Implementor routine: triMap.

UC-C.8 and UC-C.9.

FR-C.5: Sending messages

Summary

Capability of sending PDUs from TE to IUT.

Rationale

When a test stimulus is received in the test system, PDUs are sent from TE to the IUT via TRI interface.

Requirements

Availability to select the logical connection established and mapped (FR-3 and FR-4).

Mapping for all test configurations described in Annex A must be supported.

This function allows sending a raw packet (from SA point of view) to the network.

Parameters of the sending operation are summarized by:

• The packet (at IUT layer) to be sent.
• The logical connection (FR-4) used to send the data.
• The size of the buffer to be sent.
• CRC code needed to be included and added by the network interface.

The data to be sent is included into data payload at layer two (OSI level).

The correctness of data to be sent is out of scope of this requirement. TE (CODECS subsystem) is in charge of correct construction of the message.

Sending operation must notify Acknowledgment operation with the size of data correctly sent (e.g., “-1” if operation is unsuccessful).

Simultaneous sending operation must be supported for each logical connection established. Test configurations using several logical connections are possible as described in Annex A. Concurrent programming is therefore needed.

References

TRI Implementor routine: triSend.

UC-C.8.

FR-C.6: Receiving messages

Summary

Capability of receiving PDUs from IUT.

Rationale

PDUs are sent from IUT to the TE via TRI interface.

Requirements

Availability to identify the logical connection established and mapped (FR-3 and FR-4) based on the identifier of the receiving operation triggered.

Mapping for all test configurations must be supported.

This function allows receiving a raw packet (from SA point of view) to the network.

Parameters of the receiving operation are summarized by:

• The content of the packet (at IUT layer) received.
• The logical connection (FR-4) used from the data received.
• The size of the buffer received.
• CRC checking.

The data received is set the data payload into TRI routine: TriEnqueueMessage.

The correctness of data received (at IUT layer) is out of scope of this requirement. TE (CODECS subsystem) is in charge of correct decoding of the message.

Reception operation must notify Acknowledgment operation with the size of data correctly received (e.g., “-1” if operation unsuccessful).

Simultaneous reception operation must be supported for each logical connection established. Test configurations using several logical connections are possible. Concurrent programming is therefore needed.

Reception operation is implemented as callback routine enabling asynchronous operations. Blocking reception is not allowed.

References

TRI Implementor routine: TriEnqueueMessage.

UC-C.8.

FR-C.7: Filtering Capabilities

Summary

Only data payload under test is sent to the TE.

Rationale

All MAC frames with the adequate MAC destination address will be sent to SA from the underlying service provider (FR-6). Which frames will be processed must be taken into account according to the executing test case.

Requirements

Filtering applied on packets received must be aligned with RFCs supported by test system.

Only packets of IPv6 protocols under test must be sent to the TE.

The verification that the subtype of the message received is the correct (e.g., Destination Unreachable or Packet Too Big messages) is out of scope of this requirement.

TE (CODECS subsystem) is responsible for correct decoding and matching of the message.

References

TRI Implementor routine: TriEnqueueMessage.

UC-C.8.

FR-C.8: Automated IUT set up

Summary

TE is able to start up the IUT automatically.

Rationale

With the objective of being able to automate conformance testing in the better way, the upper interface of an IPv6 IUT needs to be accessible by the TE.

Therefore, IUT can be automatically set up by the TE.

Requirements

To enable the transport between the UT (Upper Tester) Client in TE, and UT Server in IUT.

To support for automated and controlled start up of the SUT prior to the execution of TTCN-3 test case or code.

The parameters to be set are:

• First Unicast MAC Address.
• Second Unicast MAC Address.
• MAC Solicited-Node Multicast Address.

The actions to be support over IUT are (more will be defined later if needed):

• Clear prefix list.
• Start/Stop listen by multicast address.
• Reboot the IUT.
• Execute IPv6 application with TCP payload.
• Execute IPv6 application with UDP payload.
• Clear the default router list.
• Add/delete specific routes.
• Stop to send router advertisement.
• Configure link MTU size.

TRI Implementor routine: TriSAReset.

References

UC-C.10 and UC-C.11.

FR-C.9: Automated IUT data communication

Summary

TE is able to send and receive service primitives to/from IUT.

Rationale

With the objective of being able to automate conformance testing, the upper interface of an IPv6 IUT needs to be accessible by the TE.

Then, TE should perform the actions required for the IUT to send and receive an IPv6 packet during test case execution.

Requirements

The upper IUT interface is driven by a test component acting as a UT Client. It uses SCOP (Simple Control and Observation Protocol) messages to communicate with the upper interface of the IUT.

The UTS implementation is not part of the TE. It is expected to be provided by the implementer of the IUT and therefore the set of functional requirements depend strongly on the concrete UTS implementation.

The construction and encoding of SCOP data messages is performed by TE. SA must only ensure the encoded SCOP packets are sent successfully to the UTS (and reception as well). Because the transport interface between UTC and UTS is not defined in the IPv6 Test Specification, the simpler solution to provide this is to use the typical Berkely Sockets solution supported by all system platforms.

References

TRI Implementor routine: triSend and TriEnqueueMessage.

UC-C.10 and UC-C.11.

FR-C.10: Safety shutdown

Summary

The main objective is ensuring a safety release of the underlying service provider (network adapter) and a safety unmapping of logical connection.

Rationale

In order to allow batch execution of test cases, a safety deallocation of resources used to execute a test case is needed.

Requirements

To release the network interface allocated in start up process (FR-1).

To reset the MAC parameters established in start up process (FR-2).

To ensure that there are no any pending data to be sent and received.

To unlink the logical connection established between TE (TSI ports) and network adapters selected (FR-4).

References

TRI Implementor routine: triUnmap and triSAReset.

UC-C.10 and UC-C.11.

Functional Requirements for RIPng ATS (See [6])

FR-R.1: Map network interfaces and TE

Summary

Logical connection between TE and underlying service providers.

Rationale

To establish the logical connection between each test component conforming the TE and each network interface conforming one underlying service provider.

Requirements

The input to map a network interface must be:

• TSI ports at the lower boundary of TE interface.

• Test component identifier (e.g. TR.1, TR.2, etc) at the lower boundary of TE interface.

• Connection identifier at the upper boundary of Service Provider interface.

The number of network interfaces to be mapped depends on the test topology selected (i.e., in this case, there are two network interfaces) described in UC-R.2.

References

TRI Implementor routine: triMap.

UC-R.3.

FR-R.2: Sending messages

Summary

Capability of sending PDUs from TE to IUT.

Rationale

When a test stimulus is received in the test system, PDUs are sent from TE to the IUT via TRI interface.

Requirements

Availability to select the logical connection established and mapped.

Mapping for test topology described in UC-2 shall be supported.

This function allows sending a raw packet (from SA point of view) to the network.

Parameters of the sending operation are summarized by:

• The packet (at IUT layer) to be sent.

• The logical connection used to send the data.

• The size of the buffer to be sent.

• CRC code needed to be included and added by the network interface.

The data to be sent is included into data payload at layer two (OSI level).

The correctness of data to be sent is out of scope of this requirement. TE (CODECS subsystem) is in charge of correct construction of the message.

Sending operation must notify Acknowledgment operation with the size of data correctly sent (e.g., “-1” if operation is unsuccessful).

Simultaneous sending operation must be supported for each logical connection established.

Concurrent programming is therefore needed.

References

TRI Implementor routine: triSend.

UC-R.4.

FR-R.3: Receiving messages

Summary

Capability of receiving PDUs from IUT.

Rationale

PDUs are sent from IUT to the TE via TRI interface.

Requirements

Availability to identify the logical connection established and mapped based on the identifier of the receiving operation triggered.

Mapping for test topology described in UC-2 shall be supported.

This function allows receiving a raw packet (from SA point of view) to the network.

Parameters of the receiving operation are summarized by:

• The content of the packet (at IUT layer) received.

• The logical connection used from the data received.

• The size of the buffer received.

• CRC checking.

The data received is set the data payload into TRI routine: TriEnqueueMessage.

The correctness of data received (at IUT layer) is out of scope of this requirement. TE (CODECS subsystem) is in charge of correct decoding of the message.

Reception operation must notify Acknowledgment operation with the size of data correctly received (e.g., “-1” if operation unsuccessful).

Simultaneous reception operation must be supported for each logical connection established. Test configurations using several logical connections are possible. Concurrent programming is therefore needed.

Reception operation is implemented as callback routine enabling asynchronous operations. Blocking reception is not allowed.

References

TRI Implementor routine: TriEnqueueMessage.

UC-R.5.

Nonfunctional Requirements

NF-1: Documentation

Summary

Detailed description of developed software.

Rationale

Documentation is a communicable material needed to describe the structure and components implemented. It also includes the programmer manual.

Requirements

The documentation will consist of:

• Software architecture of SA following the developer´s guide.
• Dependency with other parties (using a relationship or flow diagrams).
• Flow diagrams for each TRI routine implemented (or functions using TRI routines)

The documentation will be divided into component parts and for each one the following documentation will be provided:

• Component description.
• Reference to the specification (this document).
• Component peculiarities.
• Component documentation.
• API documented in detail: parameters return value and behavioral description.
• Configuration and installation guidelines.
• Component distribution.

Source code must be documented according to the rules established to edit Java code (i.e., javadocs). See also Developer's_Guide.

References

Developer's_Guide.

NF-2: Maintainability

Summary

Measurements of the extent to which the SA can be modified at the lowest possible cost.

Rationale

Ease with which the SA can be modified to correct faults, improve performance, or other attributes, or adapt to a changed environment (e.g., TE implements new test configuration or test cases).

Requirements

It is needed to provide the measurement of the time period necessary to restore a normal functionality of the system following a failure. The implementation must be oriented to minimize the MTTR (Mean Time To Repair).

SA capability to require the minimum changes when TE or IUT evolve including new test configurations, new test cases, new IPv6 protocols, etc.

References

This document.

NF-3: Reliability

Summary

Reliability is the ability of the SA to perform and maintain its functionality in routine and also in different unexpected circumstances.

Rationale

The establishment of good requirements and making a good design and implementation of the SA implies high software reliability. In this way an anticipation and design against unexpected consequences is achieved.

Requirements

It is needed to provide the measurement of the time period between two consecutive failures of the system. The implementation must be oriented to minimize the MTBF (Mean Time Between Failure).

It is needed to optimize:

• The capacity of the SA to perform as designed.
• The resistance to failure of the SA.
• The ability of the SA to perform the functional requirements under stated condition for a specified period of time.

A reliability block diagram and a fault tree (diagram showing the relationship between faults: causes and consequence) must be included.

References

This document.

NF-4: Extensibility

Summary

Capacity of adding new functionalities to the SA without affecting the functionalities already implemented.

Rationale

New features for the IPv6 test system may appear, for example, to add new test cases, new networks interfaces, new test configurations .

Requirements

SA implementation must offer the possibility to upgrade its programming code and static data according to changes agreed by the new versions of test specifications for IPv6 protocol.

TTCN-3 Specification (TRI part) may be also updated in the future and therefore SA implementation must make easier a possible migration process.

SA must support new test cases execution without affecting the functionality the test cases already supported.

SA must support new network interfaces without affecting the network interfaces already supported.

References

This document.

NF-5: Performance

Summary

SA temporary restrictions for run time.

Rationale

SA is a subpart of a whole test system consisting of several software layers. SA is the lowest layer in the Test System and therefore the performance capabilities are a remarkable ability for SA.

Requirements

SA must not cause 100% CPU usage (e.g. poll mechanism for communication purposes must be avoided).

TTCN-3 test system is not a real time environment. SA has no real time restrictions.

When SA receives from TE an IPv6 packet, it will send it to the underlying service provider in a maximum time of 100 milliseconds (FR-5).

When SA receives from underlying service provider a MAC frame, it will send it to TE in a maximum time of 100 milliseconds. (FR-6)

Time to set up the system adaptor components (FR-2, FR-3 and FR-4) must be less than 500 milliseconds.

Time to shutdown the system adaptor components (FR-10) must be less than 500 milliseconds.

Time to set up automatically IUT does not depend on the SA implementation. No performance requirement for FR-8.

References

FR-2, FR-3, FR-4, FR-5, FR-6, FR-8 and FR-10.

NF-6: Efficiency

Summary

To determine the amount of resources (such as time and storage) necessary to execute SA.

Rationale

SA will consist of a set of algorithms which solves a given computational problem. Algorithms analysis is an important part which provides theoretical estimates for the resources needed by any algorithm.

Requirements

Each algorithm used for communication purposes (FR-5, FR-6 and FR-7) will be analyzed:

A document with an analytic analysis of the algorithms will be provided by the implementer.

A document with an empirical analysis of the algorithms (execution) will be provided by the implementer.

A document comparing analytic and empirical analysis will be provided by the implementer. Strong deviations between analytic and empirical results will be justified.

References

FR-5, FR-6 and FR-7.

NF-7: Platform Compatibility

Summary

Platform requirements to execute SA.

Rationale

SA subsystem is part of test system that it will be complied and linked jointly in order to get the executable entity. All of them must be according to the same platform requirement.

Requirements

Operating System: Linux, kernel 2.6.

Compiler: gcc 3.4.

Additional compiler features: POSIX library.

They will be based on a design that focuses on C/C++ / Java interoperability:

• Detailed study on interoperability issues.
• Proposition of solution for interoperability problems.

T3RTS (TTCN-3 Runtime System) will be implemented in C/C++ language. However, T3RTS on Java are currently put on the market and therefore it will be needed to develop an initial study to migrate a SA implemented in C/C++ to Java implementation (e.g. using JNI, Java Native Interface).

References

See [3].

NF-8: Dependency on other parties

Summary

Dependency of SA with the other software elements conforming the test system.

Rationale

SA interworks with other software entities to be clearly identified.

Requirements

The dependencies must be clearly identified:

• Upper boundary of SA interface: T3RTS libraries.
• Lower boundary of SA interface; Network driver adapters used to access and manage the underlying service provider.

References

This document.

Annex A – Test architecture to be supported by SA

ISO 9646 (See [5]) presents the generic test architecture for OSI protocol conformance testing.

• Lower Tester (LT): the representation of the means of providing, during test execution, indirect control and observation of the lower service boundary of the IUT via the underlying service provider.
• Upper Tester (UT): the representation of the means of providing, during test execution, control and observation of the upper service boundary of the IUT, as defined by the Abstract Test Method.
• X-ASP: An implementation-independent description of an interaction between a service-user and a service-provider at an (X)-service boundary, as defined in an OSI service definition.
• Test coordination procedures: the rules for cooperation between the UT and LT during test execution.

The following figure shows the generic test archictures based on the methodology described before.

When the test architecture for IPv6 is implemented using TTCN-3, the architecture is shown in the figure below.

Test architecture for Core Protocol ATS (See [8])

Every functional requirement described is mapped on the general architecture, such as it is shown in the figure below.

Derived from the figure above, the test system specification for IPv6 Core protocol defines a set of test configurations supporting all the test cases to be executed. Each configuration is applicable in the proper situation (see related use cases).

Configuration CF01. Test System without Upper Tester

Configuration CF01. Test System with Upper Tester

Configuration CF02

Configuration CF02_HS01

Configuration CF03

Configuration CF03_RT01

Test architecture for RIPng ATS (See [6])

Every functional requirement described is mapped on the general architecture, such as it is shown in the figure below.