![[Main Page]](/themes/Go4ITv2/images/logo.gif){kind=logo}
[edit]
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]).
[edit]
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.
[edit]
Use Cases for Core Protocol ATS (See [8])
[edit]
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
- 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.
[edit]
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
- There are no alternative paths.
Postconditions
- TE is ready to communicate with the IUT.
- NOTE: C01 is the test component 01.
[edit]
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
- 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.
[edit]
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
- There are no alternative paths.
Postconditions
- TE is ready to communicate with the IUT.
- NOTE: HS01 is the host 1
[edit]
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
- 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
[edit]
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
- 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.
[edit]
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
- 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.
[edit]
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
- 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.
[edit]
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
- 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.
[edit]
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
- 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.
[edit]
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
- No alternative paths determined.
Postconditions
- IUT is properly configured.
[edit]
Use Cases for RIPng ATS (See [6])
[edit]
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
- 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.
[edit]
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
- 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.
[edit]
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
- In step 1, a port is created. If there is an error, everything shall be stopped.
- 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.
[edit]
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
- 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.
[edit]
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
- 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.
[edit]
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
- 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.
[edit]
Functional Requirements
[edit]
Functional Requirements for Core Protocol ATS (See [8])
[edit]
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.
[edit]
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.
[edit]
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
[edit]
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
[edit]
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.
[edit]
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.
[edit]
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.
[edit]
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
[edit]
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
[edit]
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
[edit]
Functional Requirements for RIPng ATS (See [6])
[edit]
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.
[edit]
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.
[edit]
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.
[edit]
Nonfunctional Requirements
[edit]
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
[edit]
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.
[edit]
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.
[edit]
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.
[edit]
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
[edit]
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
[edit]
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].
[edit]
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.
[edit]
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.
[edit]
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
[edit]
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.
