ISO/IEC 8882-1:1993

Information technology - Telecommunications and information exchange between systems - X.25 DTE conformance testing - Part 1: General principles

Technologies de l'information — Télécommunications et échange d'information entre systèmes — Test de conformité X.25 DTE — Partie 1: Principes généraux

General Information

• Status: Withdrawn
• Publication Date: 10-Nov-1993
• Withdrawal Date: 10-Nov-1993
• ICS: 35.100.20 - Data link layer
• ICS: 35.100.30 - Network layer
• Technical Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Drafting Committee: ISO/IEC JTC 1/SC 6/WG 1 - Physical and data link layers
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 19-Sep-1996
• Completion Date: 30-Oct-2025

Relations

• Revised: ISO/IEC 8882-1:1996 - Information technology - Telecommunications and information exchange between systems - X.25 DTE conformance testing - Part 1: General principles
• Effective Date: 15-Apr-2008

Standards Content (Sample)

I NTERNATI ON AL
ISO/IEC
STANDARD
8882-1
First edition
1993-1 1-1 5
Information technology -
Telecommunications and information
exchange between systems - X.25 DTE
conformance testing -
Part I:
G en era I p r i n ci pl es
Technologies de l'information - Télécommunications et échange
d'information entre systèmes - Test de conformité X.25 DTE -
Partie I: Principes généraux
Reference number
ISO/IEC 8882-1 :1993(E)
ISODEC 8882.1:1993 (E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the
International Electrotechnical Commission) form the specialized system for
worldwide standardization. National bodies that are members of IS0 or EC
participate in the development of International Standards through technical
committees established by the respective organization to deal with particular
c
fields of technical activity. IS0 and IEC technical committees collaborate in
fields of mutual interest. Other international organizations, governmental and
non-governmental, in liaison with IS0 and IEC, also take part in the work.
In the field of information technology, IS0 and IEC have established a joint
technical committee, ISO/IEC JTC 1. Draft International Standards adopted by
the joint technical committee are circulated to national bodies for voting.
Publication as an Intemational Standard requires approval by at least 75 % of the
national bodies casting a vote.
International Standard ISO/IEC 8882-1 was prepared by Joint Technical
Committee ISO/IEC JTC 1, Information technology, Sub-Committee SC 6,
Telecommunications and information exchange between systems.
ISO/IEC 8882 consists of the following parts, under the general title Information
technology - Telecommunications and information exchange between systems
- X.25 DTE conformance testing:
- Part I : General principles
C’
- Part 2: Data link layer conformance test suite
- Part 3: Packet level conformance test suite
Annex A forms an integral part of ISO/IEC 8882.
O ISO/IEc1993
All rights reserved No part of this publication may be reproduced or utilized in any form or by
any means, electronic or mechanical, including photocopying and microfilm, without
permission in writing from the publisher.
ISo/I~ Copyright Officc Case postde 56 CH-121 1 Genève 20. Switzerland
Printed in Switzerland
ii
‘SO/IEC ISOAEC 8882-1 : 1993 (E)
Introduction
ISOREC 8882 specifies a set of tests to evaluate Data Terminal Equipment
(DTE) conformance to International Standards IS0 7776 or ISOAEC 8208, or
both. IS0 7776 and ISOREC 8208 allow for a DTE to interface with a Data
Circuit-Terminating Equipment (DCE) conforming to CCIIT Recommendation
X.25 (1980,1984) or to another DTE conforming to IS0 7776 or ISOAEC 8208
or both. The implementations of IS0 7776 and ISOlIEC 8208 are tested indepen-
dently.
CCTC Recommendations X.25(1980) and X.25(1984) are written from the per-
spective of a DCE and therefore do not explicitly specify the DTE operation.
However, recommended operation of DES is included by implication because
of the need to communicate with X.25 DCEs. Tests within ISOAEC 8882-2 and
ISOREC 8882-3 pertaining to X.25 (1980, 1984) are based on the DTE operational
characteristics implied by CCTC X.25.
This part of ISOAEC 8882 specifies the framework in which the other parts of
ISOREC 8882 may be understood and the principles to be applied. The notation
used in ISOAEC 8882-2 and ISOREC 8882-3 is ?TCN as defined in ISOREC
9646-3.
ISOREC 8882-2 presents the Data Link Layer aspects for evaluating conformance
to IS0 7776 while ISOAEC 8882-3 presents the Packet Layer aspects for evaluating
conformance to ISOAEC 8208
The conformance tests are designed for use by
- test evaluators (responsible for analysing results and determining whether
confonnance has been achieved);
- test suite designers or implementors (for determining what tests are required
and what results can and should be anticipated by the test device); and
- users implementing IS0 7776 or ISOREC 8208 or DTEs interfacing to DCEs
that implement CCITT X.25 (1980 or 1984) (for determining the functionality
required of their implementations to be considered in conformance).
iii
ISO/IEC 8882-1 : 1993 (E)
INTERNATIONAL STANDARDQEomC
Information technology - Telecommunications and information
exchange between systems - X.25 DTE conformance testing -
Part 1: General principles
ISO/IEC 8208 : 1990, Information technoiogy - Data commu-
1 Scope
nicationr - X.25 Packzt Layer Protocol for Data Terminal Equip-
ment. .
ISOLEC 8882 defines the testing of a DTE operating at the
Data Link Layer and at the Packet Layer when accessing, by
ISO/iEC 8882-2 : 1992, Information technology - Telecommu-
means of a dedicated path connection, switched or permanent, a
nicatiom and information exchange between systems - X.25 DTE
public or private packet-switched network conforming to CCïIT
confîormance iesting - Part 2: Data Cid layer conformance test
Recommendation X.25 or another DTE conforming to IS0 7776
suite.
and ISO/IEC 8208.
ISO/IEC 8882-3 : 1991, Ir$ormation technology - Telecommu-
The tests will test the conformance of an implementation by
nications and information exchange between system - X.25 DTE
observing its external behaviour. The conformance tests will
conformance testing - Part 3: Packet layer conformance test suite.
not test the DTE performance characteristics, the diagnostic and
maintenance functions, the correctness of the protocol itself, or
ISOIIEC 9646-1 : 1991, Information technology - Open Systems
DTE internal implementation, or the full capabilities as stated in
Interconnection - Conformance testing methodology and frame-
the PICS.
work - Part I: General concepts. (See also CCllT Recommen-
dation X.291 (1991)).
This part of ISOAEC 8882
ISOAEC 9646-2 : 1991, Information technology - Open Systems
- provides a general introduction:
Interconnection - Conformance testing methodology and frame-
work - Part 2: Abstract test suite specijication. (See also CCITT
-
refers to those applicable International Standards;
Recommendation X.291 (1991)).
-
defines terms applicable to X.25-DTE conformance testing;
ISOliEC 9646-3 : 1992, Information technology - Open Systems
Interconnection - Conformance testing methodology and frame-
-
states the test case derivation and description; and
work - Part 3: The Tree and Tabular Combined Notation (lTCN).
- states the test methodology.
CCïiT Recommendation X.25 (1980), Interface between Data Ter-
minal Equipment (DTE) and Data Circuit-Terminating Equipment
ISOAEC 8882-1 contains no statement of conformance. Specific
(DCE) for Terminals Operating in the Packet Mode on Public Data
statements of conformance are given in ISOIIEC 8882-2 and
Networks.
ISOlIEC 8882-3.
CCI'lT Recommendation X.25 (1984), Interface between Data Ter-
minal Equipment (DTE) and Data Circuit-Terminating Equipment
(DCE) for Terminals Operating in the Packet Mode and Connected
2 Normative references
to Public Data Networks by Dedicated Circuit.
The following standards contain provisions which, through refer-
ence in this text, constitute provisions of this part of ISO/LEC 8882.
At the time of publication, the editions indicated were valid. All
standards are subject to revision, and parties to agreements based
on this part of ISO/LEC 8882 are encouraged to investigate the pos-
3 Definitions
sibility of applying the most recent editions of the standards listed
below. Members of IEC and IS0 maintain registers of currently
valid International Standards.
: 1984, Informationprocessing systems - Open Systems 3.1 Reference model definitions
IS0 7498
Interconnection - Basic Reference Model.
This part of ISOAEC 8882 makes use of the following term defined
IS0 7776 : 1986, It$ormation processing systems - Data commu- in IS0 7498:
nications - High-level data link control procedures - Description
(N)-protocol-data-unit (N)-PDU
of the X.25 WB-compatible DTE data link procedures.
OISOhEC
ISOAEC 8882-1 : 1993 (E)
4 Abbreviations
3.2 Conformance testing definitions
The following abbreviations are used in this part of ISOAEC 8882:
This part of ISO/IEC 8882 makes use of the following terms
defined in ISO/IEC 9646-1:
DCE Data Circuit-Terminating Equipment
a) Abstract Test Case
DE Data Terminal Equipment
b) Conformance Test Suite
DXE DTE or DCE
c) Conformance Testing
IUT Implementation Under Test
d) Implementation Under Test
PDU Protocol Data Unit
e) Inopportune PDU
PICS Protocol Implementation Conformance Statement
f) Lower Tester
PIXIT Protocol Implementation extra Information for Test-
g) Protocol Implementation Conformance Statement
ing
Protocol Implementation extra Information for Testing RS Remote Single Layer
h)
SUT System Under Test
Remote Single Layer Test Method
i)
TPDU Transport Protocol Data Unit
j) System Under Test
k) Test Group 'ITCN Tree and Tabular Combined Notation
1) Test Step
5 Test notation
m) Test Suite
The test notation used in ISO/IEC 8882-2 and ISOAEC 8882-3
is TïCN as defined in the DIS version of ISOAEC 96463. This
3.3 X.25 DTE conformance testing definitions
version of ISO/IEC 9646-3 is contained in annex A. ISO/IEC
8882-2 and ISOAEC 8882-3 contain an annex describing the
For the purpose of this part of ISO/IEC 8882 the following def-
differences between the DIS version of PCN used and the version
initions apply:
of 'ITCN defined in ISO/IEC 9646-3.
3.3.1 improper PDU: The (N)-PDU whose syntax does not
conform to the format specifications of IS0 7776 or ISOIIEC 8208
6 Test suite structure
or CCI" X.25.
The test suite structure used in ISOAFiC 8882-2 and ISOAEC
8882-3 is defined in ISO/IEC 9646-2 and is illustrated below.
3.3.2 proper PDU: The (N)-PDU whose syntax conforms to
the format specification of CCïlT X.25, IS0 7776 or ISOAEC
8208 and is acceptable to the state or phase of the interface.
Test Suite Structure
Test Group
3.3.3 tester: Refer to Lower Tester.
Test Subgroup 1 (Proper PDUs)
Test Case No.101
3.3.4 test case: Refer to Abstract Test Case.
Test Case No.102
3.3.5 test selection: Test selection is the process of choosing
test cases according to the specific criteria based on the IUT's Test Case No.1nn
PICS and PIXïï in order to constitute a conformance test suite
for the IUT.
Test Subgroup 2 (Improper PDUs)
Test Case No.201
Test Case No.202
3.3.6 test subgroup: A set of test cases that share a common
characteristic, such as testing for proper, improper, or inopporhme
PDUs. A test subgroup is the smallest testable set of test cases
that can be selected.
Test Case No.2nn
3.3.7 sub-function: A subset of the PDUs and functional
capabilities of the protocol level above the IUT that are needed to
allow data transfer testing to be accomplished.
OISO/IEC ISOAEC 8882-1 : 1993 (E)
Test Subgroup 3 (Inopportune PDUs) 7.1 Test principles
Test Case No.301
The testing of the Data Link aiid the Packet Layer protocols is
Test Case No.302
done separately. The data link layer is normally tested first since
the packet layer requires the correct operation of the data link
layer. The RS method is the selected test method since it cannot
Test Case No.3nn be assumed that a tester will be able to test completely each level
as a separate entity. The RS method requires that the tester shall
recognize and respond to a PDU received from the higher level
protocols. The specific PDUs which shall be accepted are defined
in ISOKEC 8882-2 and ISOKEC 8882-3.
7.2 Data transfer
7 Testing methodology
The sub-function chosen by the IUT provider should create an
The testing methodology is based on the OS1 Conformance Testing
alternating exchange of data-PDUs between the IUT and the tester.
Methodology and Framework. The test method used is the Remote
This exchange will be repeated until the sequence numbers of the
RS method effectively,
Single layer (RS) method. To employ the
layer under test have been rotated. The sub-function chosen shall
the concept of using sub-functions of higher layer protocols is
be defined in the PEIT of the IUT, and shall include the sequence
introduced. Sub-functions are a subset of the PDUs and functional
and contents of the user data fields required for the test. TWO
capabilities of the protocol layer above the IUT that are needed
examples of the use of a sub-function to accomplish data transfer
to allow data transfer testing to be accomplished. The required
testing are shown in figures 3 and 4.
properties of the sub-functions used are:
A more detailed explanation of data transfer testing is provided
That the number and sequence of data-PDUs received from
a)
in ISOAEC 8882-2 and ISO/IEC 8882-3. These explanations
the IUT after receiving a data-PDU from the tester is pre-
also address the data transfer testing of send-only and receive-
dictable, and that the number received from the IUT is greater
only IUTs.
than zero.
It is recognized that an IUT provider may not be able to accomplish
That the reactions of the IUT upon receipt of these data-
b)
data transfer testing by this means. In such instances the data
PDUs are known.
transfer tests are deselected.
That the sub-function allows either the tester or IUT to
c)
initiate transmission of the data-PDUs.
7.3 Other user data fields
That the sub-function allows for the exchange of data-PDUs
d)
When necessary, the content of user data fields in other than data-
by the layer under test with minimal interference from other
PDUs shall be provided to the tester by the owner of the IUT in
functions of the protocol layer(s) above the IUT (e.g., PDU
order to execute successfully the conformance test suite. In this
retransmission, error recovery, etc.).
case, the IUT requires the tester to transmit user data fields in
accordance with higher level protocols which are operating above
Examples of data transfer configurations are shown for the Data
the IUT. For example, user data fields of call set-up, clearing, and
Link Layer and the Packet Layer in figures 1 and 2 respectively.
interrupt packets of the Packet Layer may be affected.
The content of such user data fields shall be provided by the IUT
NOTE - The requirements on underlying protocols are specified in
ISOlIEC 8208, clause 3. owner in the PMIT.
Sub-function of
Figure 1 - Data Link Layer Data Transfer Configuration
Sub-function of OS1 Protocol(s) Sub-function of non-OS1 Protocol(s)
Packet Layer (layer under test)
LAN I other Protocoi(s)
Data
Link I Protocol(s)
I
Layer Note
I Note I
Note
I I I
Figure 2 - Packet Layer Data Transfer Configuration
ISO/IEC 8882-1 : 1993 (E) OISO/IEC
7.4 Testing configuration test activity from normal operation of underlying layers. At a
minimum, the tester should be capable of distinguishing between
The SUT is connected to the tester, point-to-point, when partici- I-frame retransmission at the data link layer (due to T1 expiration)
pating in active testing. The points of observation and control for and a packet layer retransmission. Some recommended functions
each test sequence are within the tester. of the tester include:
Detection of failures of the physical layer.
a)
ISOLEC 8882-2 and ISO/IEC 8882-3 include PIXIT proformas
which, when completed, describe the dynamic conformance test
The ability to respond transparently to timeout conditions at
b)
environment.
the data link layer.
Timely data link layer acknowledgement (to avoid retrans-
7.5 Operational consideration
c)
missions) when performing packet layer testing.
Testing is done in a controlled environment. It is not the intent
of this document to define the operational characteristics of test In the instance where an I-frame is retransmitted, the tester
d)
devices used to achieve DTE Conformance Testing. However, it should properly acknowledge the frame and not pass it on
to failures
is highly desirable that the device be capable of segregating IUT to the packet layer. The tester shall be sensitive
PDU sent by
Tester IUT
.
, Packet
Packet Data Link Data Link
I Layer
Layer
Layer Layer
CLEAR
I-frame _I)
INDICATION
I - frame CLEAR
CONFIRMATION
Figure 3 - Example of the use of a Packet Layer Sub-function
PDU sent by
Tester IUT
Packet Transport
Packet
Transport
Layer Layer
Layer Layer
Erroneous
Connect Data -
request TPDU packet
(CR TPDU)
.I-- Data Disconnect request
packet TPDU (DR TDPU)
Figure 4 - Example of the use of a Transport Layer Sub-function directly over ISOAEC 8208 (Le. OS1 Network Layer)
OISO/IEC
ISOhEC 8882-1 : 1993 (E)
that interfere with the tests, and when such a condition is multiple combinations of optional facilities may be required
b)
detected, the tester should abort the test. depending on the applications running above X.25.
The tester shall recognise the possibility of receiving unex- Optional facilities are tested individually. Where the IUT cannot
e)
support this method of testing these tests are deselected.
pected PDUs which do not affect the results of the test case.
These specific PDUs for each layer are defined in ISOlIEC
8882-2 and ISOAEC 8882-3. In addition, other unexpected
PDUs may be received which do affect the results of a test
7.9 Transient states
case. These PDUs will require further analysis and poten-
tially, re-execution of the test case. Receipt of such PDUs
It is recognized that for those IUTs that process PDUs sequentially,
may be due to interference from sources outside the realm of
certain states are not realizable.
Specifically, the testing of the
the X.25 environment (e.g. the IUT operating system, IUT
IUT during the DXE defined states (for example, for the packet
operator).
layer, r3 - Restart Indication, p3 - Incoming Call, p7 - Clear
Indication, and d3 - Reset indication) may result in the testing
of some other states (pl - Ready, p4 - Data Transfer, dl -
7.6 DTE initiated actions
Flow Control Ready). For example, to test the response to an
error packet (inopportune or improper packet) in the DXE Restart
Generally the tester forces the IUT to transmit a particular PDU.
Indication (1-3) state, the tester will send a Restart Indication,
However, in order to execute some test groups, it is required that
immediately followed by the error packet. The tester expects the
the IUT initiate the transmission of particular PDUs. When a
IUT to discard the error packet and then send a Restart Request in
DTE-initiated action is required, it is specified in the appropriate
response to the error packet. However, the IUT generally responds
test group. Direct control of such actions may not be feasible for
immediately to the Restart Indication with a Restart Confirmation
the IUT owner. In such instances these tests are deselected.
and processes the next packet from the packet level state rl. When
these states are not observable in the IUT, transient test cases
are deselected. The specific handling of transient state testing is
7.7 Timing considerations
described in ISO/IEC 8882-2 and ISO/IEC 8882-3.
There are two types of timing considerations which should be taken
into account - timing considerations for the tester and timing
considerations for the SUT.
8 Structure of other parts of ISO/IEC 8882
a) Tester Considerations: The tester shall allow for the time
required by the IUT to progress from one test case to the
In order to ensure consistency between ISOAEC 8882-2 and
next. This timing consideration should be accomodated for
ISOlIEC 8882-3 the following items shall be included in those
in the test preamble.
standards.
For example, the time required by the IUT to initiate a CALL
a) A PIXIT pro forma
REQUEST after completing a CALL CLEARING operation,
and the time required by the IUT to re-establish the data link
A statement of Acceptable Unexpected responses.
b)
after completing a disconnect operation. The precise timing
requirements of the IUT shall be specified in the PIXIT, as
A statement of Tester Timing Considerations.
c)
defined in ISOAEC 8882-2 and ISOLEC 8882-3.
PICS and PElT based abstract test selection rules.
d)
b\ SUTConsiderations: Where the protocol standard identifies a
’
need for timers, values for those timers shall be those stated
A definition of the test cases.
e)
in the PIXIT.
f) A statement of conformance.
7.8 Optional facility testing
An annex describing the differences between the version of
g)
TTCN used and the version of TTCN defined in ISOAEC
Full testing of optional facilities is not possible because
9646-3.
optional facilities may be managed by levels above X.25; and
a)
ISOhEC 8882-1 : 1993 (E) OISO/IEC
OISO/IEC ISO/IEC 8882-1 : 1993 (E)
Annex A
(informative)
DIS level text for ISOOEC 9646 - Part 3
The Tree and Tabular Combined Notation (TTCN)
Important - This Annex contains an extract from the DIS text of ISO/IEC 9646-3. The clause, figure and table numbering has been
changed to align with the numbering in this standard. Example and proforma numbering is unchanged from the original text. Refer-
ences to the annexes in the original text have been placed in braces; for example “{Annex A}”. All errors contained in the original text
which were subsequently corrected in the published International Standard are also present here.
Introduction
This Part of the multi-part ‘standard/recommendation’ (hereafter abbreviated to ‘standard*’) defines a test notation, called the Tree and Tabular
Combined Notation (TTCN), for use in the specification of ‘OS1 or related CCIlT X.series or T.series’ (hereafter abbreviated to ‘OSI*’) ge-
neric and abstract conformance test suites.
In constructing a generic or abstract test suite, a test notation is used to describe abstract test cases. The test notation can be an informal notation
an informal notation with clearly defined, but not for-
(without formally defined semantics) or a formal description technique (FDT). lTCN is
mally defined, semantics.
to meet the following objectives:
‘ITCN is designed
a) to provide a notation in which generic and abstract test cases can be expressed in test suite standards*;
b) to provide a notation which is independent of test methods, layers and protocols;
c) to provide a notation which reflects the abstract testing methodology defined in this multi-part standard*.
In the abstract testing methodology a test suite is looked upon as a hierarchy ranging from the complete test suite, through test groups, test cases
and test steps, down to test events. ‘ITCN provides a naming structure to reflect the position of test cases in this hierarchy. It also provides the
means of structuring test cases as a hierarchy of test steps culminating in test events. In TïCN the basic test events are sending and receiving
Abstract Service Primitives (ASPS), Protocol Data Units (PDUs) and timer events.
Two forms of the notation are provided: a human-readable tabular form, called ‘ITCN.GR, for use in OSI* conformance test suite standards;
and a machine-processable form, called lTCN.MP, for use in representing TTCN in a canonical form within computer systems and as the syn-
are semantically equivalent.
tax to be used when transferring ‘ITCN test cases between different computer systems. The two forms
A.l Scope
This Part of the multi-part standard* defines an informal test notation, called TTCN, for OSI* conformance test suites, which is independent
of test methods, layers and protocols, and which reflects the abstract testing methodology defined in Parts 1 and 2 of this multi-part standard*.
It also specifies requirements and provides guidance for using lTCN in the specification of system-independent conformance test suites for
to the production of conformance
one or more OSI* standards*. It specifies two forms of the notation: one, a human-readable form, applicable
test suite standards* for OSI* protocols; and the other, a machine-processable form, applicable to processing within and between computer
systems.
This Part of this multi-part standard* applies to the specification of conformance test cases which can be expressed abstractly in terms of control
and observation of protocol data units and abstract service primitives. Nevertheless, for some protocols, test cases may be needed which cannot
be expressed in these terms. The specification of such test cases is outside the scope of this standard*, although those test cases may need to be
included in a conformance test suite standard*.
NOTE 1 - For example, some static conformance requirements related to an application service may require testing techniques which are specific to
thai particular application.
This Part of this multi-part standard* applies to the specification of conformance test suites for OSI* protocols in OS1 layers 2 to 7, specifically
including ASN.l based protocols. The specification of conformance test suites for multi-peer or Physical layer protocols is outside the scope
of this standard*.
OISO/IEC
ISO/IEC 8882-1 : 1993 (E)
The relation between TI'CN and formal description techniques is outside the scope of this standard*.
The specification of test cases in which more than one behaviour description is to be run concurrently, is outside the scope of this standard*.
NOTE 2 - Use of parallel trees and synchronization between them IS expected to be covered by an Addendum to this standard*
Although this Part of this multi-pari standard* specifies requirements on abstract test suites written in TI'CN, including their operational se-
mantics, the means of realization of executable test suites from abstract test suites is outside the scope of this Part. Nevertheless, this Part spec-
ifies requirements on what a test suite standard* may specify about a conforming realization of the test suite.
NOTE 3 - IS0 9646-4 specifies requirements concerning test realization including ETS derivation.
A.2 Normative References
IS0 9646-1, Information Processing Systems - Open Systems Interconnection - OSX Conformance Testing Methodology and Framework. - Part
I: General Concepts. (See also CCITT Recommendation X.290)
IS0 9646-2, Information Processing Systems - Open Systems Interconnection - OSI Conformance Testing Methodology and Framework. - Part
(See also CClTï Recommendation X.290)
2: Abstract Test Suite Specijïcation.
IS0 646, Information Processing Systems - Open Systems Interconnection - IS0 7-bit Coded Character Set for Information Exchange
IS0 8824 (1989), Information Processing System - Open Systems Interconnection - Abstract Syntax Notation One (ASN.1). (See also CClTï
Recommendation X ,208)
IS0 8825 (1989), Information Processing Systems - Open Systems Interconnection - Basic Encoding Rules for ASN. 1. (See also CCïïï Rec-
X.209)
ommendation
NOTE - These versions of ASN.1 include ASN.1 Extensions Addenda.
IS0 7498-1 , Information Processing Systems - Open Systems Interconnection - Basic Reference Model. (See also CCITI' Recommendation
X.200)
IS0 TR 8509 , Information Processing Systems - Open Systems Interconnection -Sewice Conventions, (See also CCITT Recommendation
X.210)
A.3 Definitions
A.3.1 Basic Term from IS0 W6-1
The following terms defined in IS0 9646-1 apply:
abstract service primitive
abstract testing methodology
abstract test case
abstract test method
abstract test suite
conformance log
conformance statement
conformance testing
conformance test suite
coordinated test method
distributed test method
embedded testing
executable test case
executable test suite
external test methods
fail verdict
foreseen outcome
generic test case
generic test suite
implementation under test
ISOAEC 8882-1 : 1993 (E)
OISO/IEC
u) inconclusive verdict
v) inopportune test event
w) local test methods
x) lower tester
y) multi-layer testing
z) pass verdict
aa) PICS proforma
ab) PMIT proforma
point of control and observation
ac)
ad) protocol data unit
ae) protocol implementation
af) real tester
ag) remote test method
ah) syntactically invalid test event
ai) system under test
aj) test case
ak) test coordination procedures
al) testevent
am) test group
an) test management protocol
ao) test outcome
ap) test purpose
aq) test realizer
ar) test step
as) test suite
at) unforeseen outcome
au) upper tester
av) valid test event
aw) verdict
A.3.2 Terms from IS0 7498-1
The following terms defined in IS0 7498-1 apply:
a) (N)-layer
b) (N)-protocol
c) (N)-protocol control information
d) (N)-protocol data unit
e) (N)-service
f) (N)-service access point
g) (N)-user data transfer syntax
A.3.3 Terms from IS0 TR 8509
The following terms defined in IS0 TR 8509 apply:
a) service primitive
b) service provider
c) service user
A.3.4 Terms from IS0 8825
The following term defined in IS0 8825 applies:
encoding
l
ISOlIEC 8882-1 : 1993 (E) OISO/IEC
A.3.5 Terms from IS0 8824
The following terms defined in IS0 8824 apply:
a) Numericstring
b) Printablestring
c) TeletexSîring
d) VideotexString
e) VisibleSiring
f) IASString
g) Graphicstring
h) Generalstring
A.3.6 TTCN Specific Terms
For the purposes of this standard* the following definitions apply:
A.3.6.1 Abbreviation identifier: A name for an abbreviation, which identifies its definition.
A.3.6.2 Attach statement: A TTCN statement which attaches a sub-tree to a calling tree.
A.3.6.3 Base constraint: Specifies a set of default values for each and every field in an ASP or PDU type declaration.
A.3.6.4 Behaviour line: An entry in a dynamic behaviour table representing a test event or other TTCN statement together with associated
label, verdict, constraints reference and comment information as applicable.
A.3.6.5 Behaviour tree: A specification of a set of sequences of test events, and other TTCN statements.
A.3.6.6 Blank entry: In a modified multiple constraint a blank entry in a constraint parameter or field denotes that a constraint value is to be
inherited.
A.3.6.7 Calling tree: The behaviour tree to which a sub-tree is attached.
A.3.6.8 Constraints part: That component of a TïCN test suite concerned with the specification of the values of ASP parameters and param-
eter groups and PDU fields and field groups.
A.3.6.9 Constraints reference: A reference to a constraint, given in a behaviour line.
A.3.6.10 Decode expression: A specification of the decoding of PDUs embedded in ASPs or other PDUs.
A.3.6.11 Default behaviour: The events, and other TTCN statements, which may occur at any level of the associated tree, and which arc in-
dicated in the default behaviour proforma.
A.3.6.12 Defaults library: The set of the default behaviours in a test suite.
A.3.6.13 Defaults reference: A structured name which specifies the location of the default in the defaults library.
A.3.6.14 Dotted identifier: An identifier, consisting of a base consiraint identifier concatenated with one or more modified constraint identi-
fiers, separated by dots.
A.3.6.15 Encode expression: A specification of the encoding of PDUs embedded in ASPs or other PDUs.
A.3.6.16 Field groups: A collection of one or more PDU fields which may occur in more than one PDU type declaration and which is defined
in a separate declaration.
A.3.6.17 Implicit send event: A mechanism used in Remote methods for specifying that the IUT should be made to initiate a particular PDU
or ASP.
A.3.6.18 Inheritance: The means by which constraint values specified for a base constraint are passed to a modified constraint.
A.3.6.19 Local tree: A behaviour tree defined in the same proforma as its calling tree.
A.3.6.20 Modified constraint: A subsequent constraint defined for an ASP or a PDU that already has a Base constraint, and which makes
modifications on that Base constraint.
A.3.6.21 Multiple constraint: Declaration of a set of constraints for an ASP or PDU of a given type arranged in a single table.
A.3.6.22 Operational semantics: Semantics explaining the execution of a TïCN behaviour tree.
A.3.6.23 Otherwise event: The TTCN mechanism for dealing with unforeseen events in a controlled way.
A.3.6.24 Parameter groups: A collection of one or more ASP parameters which may occur in more than one ASP type declaration and which
is defined in a separate declaration.
A.3.6.25 Pseudo-event: A pseudo-event is a TTCN expression or Timer operation appearing in the behaviour description.
A.3.6.26 Receive event: The receipt of an ASP or PDU at a named or implied PCO.
OISO/IEC ISO/IEC 8882-1 : 1993 (E)
A.3.6.27 Root tree: The main behaviour tree of a test case, occurring at the level of entry into the test case.
A.3.6.28 Send event: The sending of an ASP or PDU to a named or implied PCO.
A.3.6.29 Set of alternatives: TTCN statements coded at the same level of indentation and belonging to the same predecessor node. They rep-
resent the possible events, pseudo-events and constructs which are to be considered at the relevant point in the execution of the test case.
A.3.6.30 Single constraint: Declaration of a constraint for a single ASP or PDU of a given type arranged in a single table.
A.3.6.31 Snapshot semantics: A semantic model to minimize the effect of timing on the execution of a test case, defined in terms of 'snap-
shots' of the test environment, during which the environment is effectively frozen for a prescribed period.
A.3.6.32 Static chaining: The linking from the declaration of an ASP parameter or PDU field to the declaration of another ASP or PDU.
A.3.6.33 Static semantics: Semantic rules that restrict the usage of the TTCN syntax.
A.3.6.34 Sub-tree: An identifiable part of a behaviour tree which can be separated, then attached and executed at various places in that (or
some other) behaviour tree.
A.3.635 Test case identifier: A short name for the test case.
A.3.6.36 Test case reference: A full name for the test case behaviour description, which defines its conceptual location in the test suite struc-
ture.
A.3.6.37 Test case variable: One of a set of variables declared globally to the test suite, but whose value is retained only for the execution of
a single test case.
A.3.638 Test step library: The set of the test step dynamic behaviour descriptions in the test suite.
A.3.639 Test step objective: An informal statement of what the test step is meant to accomplish.
A.3.6.40 Test Suite constant One of a set of constants, not derived from the PICS or PIXIT, which will remain constant throughout the test
suite.
A.3.6.41 Test suite parameter: One of a set of constants derived from the PICS or PIXIT which globally parametenze a test suite.
A.3.6.42 Test suite variable: One of a set of variables declared globally to the test suite, and which retain their values between test cases.
A.3.6.43 Timeout event: An event which is used within a behaviour tree to check for expiration of a specified timer.
A.3.6.44 Tree attachment: The method of indicating that a behaviour tree specified elsewhere (either at a different point in the current pro-
forma, or as a test step in the test step library) is to be included in the current behaviour tree.
A.3.6.45 Tree header: That which prefixes a local behaviour tree. The header contains a tree identifier, and a specification of any parameters
and their types used in the tree.
A.3.6.46 Tree identifier: A name identifying a local behaviour tree.
A.3.6.47 Tree indentation: A method of indicating the tree structure of a behaviour description. It is reflected in the behaviour description by
indentation of text.
A.3.6.48 Tree leaf The TTCN statement in a behaviour tree or sub-tree which has no specified subsequent behaviour.
A.3.6.49 Tree node: A single TTCN statement.
A.3.6.50 Tree notation: The notation used in TTCN to represent test cases as trees.
A.3.6.51 TTCN abbreviation: A method of indicating a textual substitution to be performed in a dynamic behaviour table.
A.3.6.52 TTCN statement: A TTCN statement is an event, a pseudo-event or construct which is specified in a behaviour description.
A.3.6.53 Unforeseen test event: A test event which has not been identified as a possible outcome in the test suite. It is normally handled using
the OTHERWISE event.
A.3.6.54 Unqualified send event: A send event that does not have a Boolean expression or EncodedAs expression on the same statement line.
A.4 Abbreviations
A.4.1 Abbreviations Defined in IS0 9646-1
For the purposes of this Part of IS0 9646, the following abbreviations defined in clause 4 of IS0 9646-1 apply:
ASP : abstract service primitive
OS1 : open systems interconnection
OSI* : OS1 related CCITT X.series or T.series
PCO : point of control and observation
PDU : protocol data unit
PICS : protocol implementation conformance statement
ISODEC 8882-1 : 1993 (E)
OISO/IEC
PIXIT : protocol implementation extra information for testing
SAP : service access point
standard* : standard or recommendation
SUT : system under test
A.4.2 Abbreviations Defined in IS0 9646-2
For the purposes of this Part of IS0 9646, the following abbreviations defined in clause 4 of IS0 9646-2 apply:
DS : distributed single-layer (test method)
FDT : formal description technique
TTCN : tree and tabular combined notation
A.4.3 Other Abbreviations
For the purposes of this Part of IS0 9646, the following abbreviations also apply:
ASN.1 : abstract syntax notation one
BNF : The extended Backus-Naur form used in lTCN
CEId : connection endpoint identifier
FIFO : fiist in first out
TTCN,GR : tree and tabular combined notation, graphical form
TTCN.MP : tree and tabular combined notation, machine processable form
AS The Syntax Forms of TTCN
lTCN is provided in two forms:
a) a graphical form (ïTCN.GR) suitable for human readability;
b) a machine processable form (TLTCN.MP) suitable for transmission of TLTCN descriptions between machines and possibly suitable for other
automated processing.
ïTCN.GR is defined using tabular proformas. TTCN.MP differs from ïTCN.GR only in syntax; keywords, instead of boxes, are used as in-
formation deiimiters. The syntax of TLTCN.MP is defined in Annex A of this standard* by means of a BNF grammar.
As an aid to clarifying the ïTCN.GR many TLTCN.MP productions are embedded in the text of this standard*, and are marked: SYNTAX
DEFINïïION. To improve the readability of this document some productions will appear in the text in several places.
The two forms of TïCN are equivalent. If there is a conflict between the two forms, this is an error, and should be reported back to the stan-
dards* organization via a defect report. In such cases, however, the TLTCN.MP shall take precedence over the lTCN.GR form pending correc-
tion by the standards* organization.
A.6 Compliance
6.1 Test suites that claim to comply with this Part of this multi-part standard* shall state that they comply with the requirements for either
TïCN.GR or ïTCN.MP.
6.2 Test suites that claim to comply with the requirements of TTCN.GR shall comply with the lTCN.GR syntax requirements stated in clauses
A.8 through A.16 and clause IA.3). Generic test suites may also use the options specified in clause A.18.
6.3 Test suites that claim to comply with the requirements of ?TCN.MP shall comply with the lTCN.MP syntax requirements stated in clause
{ A.3).
6.4 Test suites that claim to comply with this Part of this multi-part standard* shall comply with the static semantic requirements specified in
clauses A.8 through A.15 and have operational semantics in accordance with the definition of the operational semantics in (Annex B}, such
that they are semantically valid.
6.5 A test suite standard* that claims to comply with this Part of this multi-part standard* shall require that any realization of that test suite
that claims to conform to that test suite standard* shail:
a) have operationai semantics equivalent to the operational semantics of the test suite as defined by {Annex B};
b) be able to produce a conformance log that as a minimum meets all the requirements in clause 17;
c) comply with IS0 96464.
I
OISO/IEC ISO/IEC 8882-1 : 1993 (E)
A.7 Conventions
A.7.î Introduction
The following conventions have been used when defining the lTCN.GR table profonnas and the lTCN.MP grammar.
A.7.2 TTCN.GR Table Proformas
The TTCN.GR notation is defined using a number of different types of table. The following conventions will be used in the description of
proformas for these tables:
a) Bold text (like this) shall appear verbatim in each actual table in a TïCN test case;
b) Text in italics (like this) shall not appear verbatim in a lTCN test case. This font is used to indicate that actual text must be substitute for
the italicized symbol. Syntax requirements for the actual text can be found in the corresponding lTCN.MP BNF production.
EXAMPLE 1 - SuiteldentGer corresponds to production 3 in {Annex A}
OISOAEC
A.7.3 Syntactic Metanotation
Table A.l defines the metanotation used to specify the extended form of BNF grammar for TI'CN (henceforth called BNF):
Table A.l: The TTCN.MP Syntactic Metanotatia
is defined to be
aitemative
O or 1 instances of abc
O or more instances of abc
1 or more instances of abc
textual grouping
the non-terminai symbol abc
the terminal symbol $abc
the terminal symbol abc
A.7.4 TTCN.MP Syntax Definitions
A.7.4.1 Complete tables defined in TTCN.GR are represented in TTCN.MP by productions of the kind:
$BEGIN-KEY WORD . $END-KEYWORD
EXAMPLE 2 - TSPARdcls ::= $BeginTS-PARdcls { TSPARdcl} + $End-TS-PARdcls
Normally, these productions contain at least one mandatory field.
A.7.4.2 Lines of a table, i.e. sets of fields in a table, are represented by productions of the kind:
$KEYWORD . $ENQKEYWORD
BEGIN does not appear in the opening keyword.
EXAMPLE 3 - TS-PARdcl ::= $TS-PARdcl TS-PARid TSPARtype PICS-PIXIT [Comment]
$End-TS-P ARdcl
A.7.4.3 Individual fields in a line are represented by:
$KEYWORD .
There is no closing keyword.
EXAMPLE 4 - TSPARid ::= $TS-PARid TSPARidentifier
NOTE - Symbols such as TS-PARid can only be used to name a field. The contents of the field must be called, in that case, TS-PARidentifier,
further defined as an identifier.
EXAMPLE 5 - TSPARidentiFier ::= Identifier
A.7.4.4 Sets of tables, up to and including the test suite, are represented by productions of the kind:
$KEYWORD . $END-KEYWORD
EXAMPLE 6 - ASPdcls ::= $ASPdcls [TTCN-ASPdcls] [ASNlASPdcls] $End-ASPdcls
EXAMPLE 7 - Suite : := $Suite SuiteId Suiteoverview Declarations Dynamicpart ConstraintsPart $End-Suite.
A.7.4.5 All other productions defining non-terminal symbols have no keywords at the beginning or the end of the right-hand expres-
sion.
EXAMPLE 8 - TimerIdentifier ::=Identifier
Most of the terminal symbols used in the TTCN.MP grammar are defined in clause {A.3.9}.
A.7.5 TTCN.MP and TTCN.GR Symbols
a) TTCN keywords (terminal symbols) that belong only to the TTCN.MP form start with the dollar character ($):
EXAMPLE 9 - $SuiteId
b) TïCN keywords (terminal symbols) that belong to both the TTCN.MP and the TTCN.GR forms do not start with the dollar character ($):
ISO/IEC 8882-1 : 1993 (E)
OISO/EC
EXAMPLE 10 - the 'ITCN keyword REPEAT
A.7.6 Uniqueness of Names in TTCN Test Suites
A.7.6.1 Identifiers used within TTCN test suites are case sensitive. Whenever in the TTCN an identifier used from a protocol standard*
contains "-" (dash) the dash shall be replaced by "-" (underscore).
A.7.6.2 All identifier names of the following items shall have unique meaning throughout the test suite (i.e. declarations and con-
straints).
a) Redefined 'ITCN types;
b) user defined TTCN types;
c) User defined operators;
d) Test suite parameters;
e) Test suite constants;
f) Test suite variables;
g) Test case variables;
h) PCO types
...