- Email: [email protected]
Euronet reference and test centre
Euronet reference and test centre Ken Weaving describes the facilities at a test centre for high level protocols The Commission of the European Communities Joint Research Centre at Ispra, Italy, has established a Euronet reference and test centre (RTC) for high-level protocols. The centre provides a reference implementation of the high-level protocols used in Euronet, and a test and debug service for the user to check his protocol implementation against the reference. The paper describes the operation of the centre and its facilities, which include a message service over Euronet, between the RTC and users of the service.
The Reference and Test Centre for Higher Level Protocols (RTC) was established to provide help to Euronet hosts with their higher level protocol implementations. In this context, a 'higher level protocol' (HLP) is any protocol implemented for the Euronet community on top of the X.25 interface. Currently there are: • •
ESP 20 protocol for driving TTY-oriented terminals, DEVT protocol for driving data-entry terminals with field addressing capabilities, • RPP protocol for remote printing and transfer of documents and files. The RTC has two main functions. The first is to provide a reference implementation of each protocol which are then considered to be the standard implementations of these protocols for Euronet. The second function is to provide, on a professional basis, a test and debug service to any user willing to check the conformity of his higher level protocol implementation with the Euronet reference. During the implementation of each protocol, the RTC should resolve all uncertainties, and specify all missing points and implementation details of the HLP definition. These technical complementary guidelines will then be considered as integral parts of the HLP definitions and should be followed by Euronet implementers.
the same protocol. Unfortunately, the way in which protocols are specified, using natural language, in many instances leads an implementer into uncertain situations. These can, of course, be resolved on a 'closed user group' basis, where each group of hostswishing to work together decide their own solutions. This, however, could mean that a host could not work with two different groups because of implementation incompatibilities. It is therefore necessary to give a single centre, such as an RTC, the mandate to resolve such uncertainties and to ensure the completeness of protocol descriptions by the production of complementary technical guidelines. The philosophy underlying the creation of a standard implementation of any protocol is that if two implementations are able to work correctlywith the standard, then they should be able to work correctly with each other. This can be expanded to imply that any implementation that can work with the standard should then work with all other implementations that have been checked against the standard. A centre, such as C in Figure 1, which has tested its HLP implementation against the standard, can be reasonably sure that its implementation will work with all others which have been tested in the same way (A and B in Figure 1). On the other hand, D can only be sure that his implementation will w o r k w i t h E, and further testing will be necessary if he wishes to begin working with another centre. The existence of an RTC, with its test and debug facilities, can reduce the amount of time that each host
j
/
Why RTC? The RTC is considered to be necessary to ensure complete interworking between all implementations of Commission of the European Communities Joint Research Centre, lspra Establishment, 21020 Ispra (Varese) Italy. The paper was presented at the Networks 80 conference, which was organized by Online Conferences in London, UK (3-5 June 1980).
vol 3 no 5 october 1980
Test -.,I-- -- =.- Compatible
Figure 1.
~
/~ /
Protocol standardization
0140-3664/80/050221-O3502.00 © 1980 IPC Business Press
221
must spend on producing its own tools for testing purposes. Another requirement which can best be fulfilled by an RTC is that of acting as a central coordinator for proposed HLP improvements and extensions. The RTC knows which centres have tested against the standard HLP implementation and who therefore will be interested in discussing any protocol enhancements. In this respect the RTC is necessary to protect the interests of those centres who have already invested time and effort in particular protocol implementations.
OPERATION The Euronet RTC will be operated by the EEC Joint Research Centre (JRC) at Ispra, Italy, on a Solar 16/65 medium sized computer, which will be dedicated to this function. The computer will have 192k of core memory and 2 × 10 Mbyte + 50 Mbyte of disc backing store. This computer is currently connected to the Rome node of Euronet, and is accessible during normal working hours. For each HLP there are two implementations to be considered: of the standard version, and of the test facility. The standard version is implemented following the protocol specifications, and is placed in its correct hierarchical position in the software layers. Currently, this is immediately above level 3 of X.25 for the protocols which have been defined for Euronet. Where possible, an attempt has been made to make applications available which have been especially designed to use as many facets as possible ofthe particular protocol. This allows hosts who have implemented the terminal part of a protocol for interactive terminals (ESP20 or DEVT) to test their implementations using these applications. As the P-FI- packet assembler/disassemblers (PADs) are available for terminal access at ESP20 level, they can be used for testing the various application interfaces for ESP20, and so the Euronet RTC is not providing any facilities to perform this same function. Figure 2 shows the RTC software for the DEVT protocol. DEVT applications ~
Message service To facilitate communications between the RTC and users (and also potential users), a mailbox service has been implemented which allows users to deposit messages or questions for the RTC and, after some time, to retrieve any replies. This is accessed using ESP20, and so is available from any terminal which can be connected via a PAD. It is designed to be used even by uninformed users (users not possessing any knowledge or documentation about the system), so that potential RTC users can deposit requests for information and documentation. It is expected that actual RTC users will deposit detailed technical questions, suggestions for improvement of RTC services, suggestions for protocol enhancements etc. The service will accept about 30 concurrent users, and each user can have a string of messages waiting for him.
Test facility A test facility is the implementation of the debug tool for a particular protocol, and these currently exist for DEVT and RPP. They must exist as seperate implementations from the standards for several reasons, the most important of which is that the test facility should allow error situations to be deliberately created, which is not usually possible with the standard implementation. A test facility is designed as an ESP20 application which has several X.25 ports available. A virtual circuit is established between a TrY-like
Applicotion
IESP20
Figure 3.
Use of a PAD
Figure 4.
Using a host
Stondo.rd ~erlorlos
~
E , t ~ l f ~ -mJvlJ
DEVT image
DEVT state
._•
Traffic
record
Figure 2.
222
RTC DEVT software
computer communications
terminal and the test facility using the ESP20 protocol (either from a PAD, or using a host implementation [Figures 3, 4]) which is used to control the test session, and which would usually be on the same site as the implementation being tested: The test facility can then be made, on receiving commands from the control terminal, to establish, accept or close virtual circuits between itself and the implementation under test. The test facility performs no autonomous actions, but reacts only to commands from the control terminal. This allows the operator to have complete control over what is being sent (or not!) to the test implementation. The operator is notified when data is received from the test implementation, and is also informed if the data is in error (a primitive which does not exist, a value which is not defined, or a primitive transferred when the automation is in the wrong state). The contents of the data are transformed into a readable form, the same form that is used in the commands which generate the primitives or items, and is only dumped in decimal or hexadecimal strings when it cannot be transformed (i.e. when an error has occurred). Although the test facility performs no autonomous action, it maintains state variables and indicates on the control terminal when primitives of the protocol have been transferred in the wrong state.
Test environment The test environment is independent of the protocol being tested, and the set of commands for a test facility contains a set of commands for modifying and handling the environment which is common to all test facilities. The environment provides a set of tools which can be used by the test operator, which includes the following. Scenarios A set of scenarios exist which are standard scenarios, and in addition a user can create and edit his own. The scenarios, which consist of command sequences, can be activated by the operator, and allow a pause facility where the scenario can be interrupted and later resumed. A command also exists for listing a scenario, so that a user can check its contents before it is activated. Traffic record This is a complete trace of all traffic on the test virtual circuit, which is recorded on disc. It can be turned off/on or printed at the control terminal on command from the operator. Echo This is a misnomer, and is simply a hexadecimal dump of all data that is being sent by the test facility on
vol 3 no 5 october 7980
the test connection. It can be turned on/off by the operator. Virtual image A virtual image of the protocol device is maintained by the test facility in order to help the operator to keep track of the effects of the commands exchanged.
These tools are designed to simplify the task of the operator in what can be quite a complex situation when he is trying to simulate a protocol interlocutor and its many state transitions. The set of commands related to controlling the environment are allowed at any time during a test session, whereas the commands which generate data are only allowed while the test virtual circuit exists.
Data generation commands A set of data generation commands exists for each protocol and, as far as possible, uses mnemonic names for primitives and items which correspond to the names attributed in the protocols. Commands may or may not have parameters, and a definite syntax exists for each command. Commands which are syntactically correct are accepted and sent on the test connection, even if they provoke a protocol error (in which case a warning message is given to the operator). A transparent mode of input also allows data to be generated which does not necessarily correspond to any primitive or item defined in the protocol. This is necessary to invoke error checking mechanisms in the test implementation.
BENEFITS Various departments of the Commission of the European Communities (CEC) are now specifying acceptance tests using the RTC when ordering equipment which uses Euronet protocols. As the network is used for communication, the tests can be done almost anywhere in Europe. The services offered by the Euronet RTC would be of benefit to those wishing to • • • •
interpret the High Level Protocol automata, implement a HLP test a HLP version, check compatibility with other Euronet hosts and terminals • propose HLP enhancements.
The RTC should be contacted by mail, telephone or telex or by the RTC message service on Euronet.
223
The Reference and Test Centre for Higher Level Protocols (RTC) was established to provide help to Euronet hosts with their higher level protocol implementations. In this context, a 'higher level protocol' (HLP) is any protocol implemented for the Euronet community on top of the X.25 interface. Currently there are: • •
ESP 20 protocol for driving TTY-oriented terminals, DEVT protocol for driving data-entry terminals with field addressing capabilities, • RPP protocol for remote printing and transfer of documents and files. The RTC has two main functions. The first is to provide a reference implementation of each protocol which are then considered to be the standard implementations of these protocols for Euronet. The second function is to provide, on a professional basis, a test and debug service to any user willing to check the conformity of his higher level protocol implementation with the Euronet reference. During the implementation of each protocol, the RTC should resolve all uncertainties, and specify all missing points and implementation details of the HLP definition. These technical complementary guidelines will then be considered as integral parts of the HLP definitions and should be followed by Euronet implementers.
the same protocol. Unfortunately, the way in which protocols are specified, using natural language, in many instances leads an implementer into uncertain situations. These can, of course, be resolved on a 'closed user group' basis, where each group of hostswishing to work together decide their own solutions. This, however, could mean that a host could not work with two different groups because of implementation incompatibilities. It is therefore necessary to give a single centre, such as an RTC, the mandate to resolve such uncertainties and to ensure the completeness of protocol descriptions by the production of complementary technical guidelines. The philosophy underlying the creation of a standard implementation of any protocol is that if two implementations are able to work correctlywith the standard, then they should be able to work correctly with each other. This can be expanded to imply that any implementation that can work with the standard should then work with all other implementations that have been checked against the standard. A centre, such as C in Figure 1, which has tested its HLP implementation against the standard, can be reasonably sure that its implementation will work with all others which have been tested in the same way (A and B in Figure 1). On the other hand, D can only be sure that his implementation will w o r k w i t h E, and further testing will be necessary if he wishes to begin working with another centre. The existence of an RTC, with its test and debug facilities, can reduce the amount of time that each host
j
/
Why RTC? The RTC is considered to be necessary to ensure complete interworking between all implementations of Commission of the European Communities Joint Research Centre, lspra Establishment, 21020 Ispra (Varese) Italy. The paper was presented at the Networks 80 conference, which was organized by Online Conferences in London, UK (3-5 June 1980).
vol 3 no 5 october 1980
Test -.,I-- -- =.- Compatible
Figure 1.
~
/~ /
Protocol standardization
0140-3664/80/050221-O3502.00 © 1980 IPC Business Press
221
must spend on producing its own tools for testing purposes. Another requirement which can best be fulfilled by an RTC is that of acting as a central coordinator for proposed HLP improvements and extensions. The RTC knows which centres have tested against the standard HLP implementation and who therefore will be interested in discussing any protocol enhancements. In this respect the RTC is necessary to protect the interests of those centres who have already invested time and effort in particular protocol implementations.
OPERATION The Euronet RTC will be operated by the EEC Joint Research Centre (JRC) at Ispra, Italy, on a Solar 16/65 medium sized computer, which will be dedicated to this function. The computer will have 192k of core memory and 2 × 10 Mbyte + 50 Mbyte of disc backing store. This computer is currently connected to the Rome node of Euronet, and is accessible during normal working hours. For each HLP there are two implementations to be considered: of the standard version, and of the test facility. The standard version is implemented following the protocol specifications, and is placed in its correct hierarchical position in the software layers. Currently, this is immediately above level 3 of X.25 for the protocols which have been defined for Euronet. Where possible, an attempt has been made to make applications available which have been especially designed to use as many facets as possible ofthe particular protocol. This allows hosts who have implemented the terminal part of a protocol for interactive terminals (ESP20 or DEVT) to test their implementations using these applications. As the P-FI- packet assembler/disassemblers (PADs) are available for terminal access at ESP20 level, they can be used for testing the various application interfaces for ESP20, and so the Euronet RTC is not providing any facilities to perform this same function. Figure 2 shows the RTC software for the DEVT protocol. DEVT applications ~
Message service To facilitate communications between the RTC and users (and also potential users), a mailbox service has been implemented which allows users to deposit messages or questions for the RTC and, after some time, to retrieve any replies. This is accessed using ESP20, and so is available from any terminal which can be connected via a PAD. It is designed to be used even by uninformed users (users not possessing any knowledge or documentation about the system), so that potential RTC users can deposit requests for information and documentation. It is expected that actual RTC users will deposit detailed technical questions, suggestions for improvement of RTC services, suggestions for protocol enhancements etc. The service will accept about 30 concurrent users, and each user can have a string of messages waiting for him.
Test facility A test facility is the implementation of the debug tool for a particular protocol, and these currently exist for DEVT and RPP. They must exist as seperate implementations from the standards for several reasons, the most important of which is that the test facility should allow error situations to be deliberately created, which is not usually possible with the standard implementation. A test facility is designed as an ESP20 application which has several X.25 ports available. A virtual circuit is established between a TrY-like
Applicotion
IESP20
Figure 3.
Use of a PAD
Figure 4.
Using a host
Stondo.rd ~erlorlos
~
E , t ~ l f ~ -mJvlJ
DEVT image
DEVT state
._•
Traffic
record
Figure 2.
222
RTC DEVT software
computer communications
terminal and the test facility using the ESP20 protocol (either from a PAD, or using a host implementation [Figures 3, 4]) which is used to control the test session, and which would usually be on the same site as the implementation being tested: The test facility can then be made, on receiving commands from the control terminal, to establish, accept or close virtual circuits between itself and the implementation under test. The test facility performs no autonomous actions, but reacts only to commands from the control terminal. This allows the operator to have complete control over what is being sent (or not!) to the test implementation. The operator is notified when data is received from the test implementation, and is also informed if the data is in error (a primitive which does not exist, a value which is not defined, or a primitive transferred when the automation is in the wrong state). The contents of the data are transformed into a readable form, the same form that is used in the commands which generate the primitives or items, and is only dumped in decimal or hexadecimal strings when it cannot be transformed (i.e. when an error has occurred). Although the test facility performs no autonomous action, it maintains state variables and indicates on the control terminal when primitives of the protocol have been transferred in the wrong state.
Test environment The test environment is independent of the protocol being tested, and the set of commands for a test facility contains a set of commands for modifying and handling the environment which is common to all test facilities. The environment provides a set of tools which can be used by the test operator, which includes the following. Scenarios A set of scenarios exist which are standard scenarios, and in addition a user can create and edit his own. The scenarios, which consist of command sequences, can be activated by the operator, and allow a pause facility where the scenario can be interrupted and later resumed. A command also exists for listing a scenario, so that a user can check its contents before it is activated. Traffic record This is a complete trace of all traffic on the test virtual circuit, which is recorded on disc. It can be turned off/on or printed at the control terminal on command from the operator. Echo This is a misnomer, and is simply a hexadecimal dump of all data that is being sent by the test facility on
vol 3 no 5 october 7980
the test connection. It can be turned on/off by the operator. Virtual image A virtual image of the protocol device is maintained by the test facility in order to help the operator to keep track of the effects of the commands exchanged.
These tools are designed to simplify the task of the operator in what can be quite a complex situation when he is trying to simulate a protocol interlocutor and its many state transitions. The set of commands related to controlling the environment are allowed at any time during a test session, whereas the commands which generate data are only allowed while the test virtual circuit exists.
Data generation commands A set of data generation commands exists for each protocol and, as far as possible, uses mnemonic names for primitives and items which correspond to the names attributed in the protocols. Commands may or may not have parameters, and a definite syntax exists for each command. Commands which are syntactically correct are accepted and sent on the test connection, even if they provoke a protocol error (in which case a warning message is given to the operator). A transparent mode of input also allows data to be generated which does not necessarily correspond to any primitive or item defined in the protocol. This is necessary to invoke error checking mechanisms in the test implementation.
BENEFITS Various departments of the Commission of the European Communities (CEC) are now specifying acceptance tests using the RTC when ordering equipment which uses Euronet protocols. As the network is used for communication, the tests can be done almost anywhere in Europe. The services offered by the Euronet RTC would be of benefit to those wishing to • • • •
interpret the High Level Protocol automata, implement a HLP test a HLP version, check compatibility with other Euronet hosts and terminals • propose HLP enhancements.
The RTC should be contacted by mail, telephone or telex or by the RTC message service on Euronet.
223