formal specification of an information gateway service interface in estelle

ELSEVIER Computer Standards & Interfaces 16 (1994) 341-368

BIR

Formal specification of an information gateway service interface in Estelle

Kassem Saleh a,,, Hasan Ural b

" Department of Electrical & Computer Engineering, Kuwait University, P.O. Box 5969, 13060 Safat, Kuwait b Department of Computer Science, University of Ottawa, Ottawa, Ont., Canada

Abstract

This paper introduces a new communication interface, the Information Gateway Service Interface (IGSI) and specifies it in Estelle, one of ISO's standard formal description techniques. IGSI allows a user to select and connect to a variety of information services using a single interactive access device by providing a standard interface for the interworking between communication switches and host computers. Such an interface will result in widening the range of accessible value-added services across communication networks. It will also encourage the development of standard client-server computer supported telecommunications applications in which the communication switch plays the role of the server.

Key words: Communication interfaces; Estelle; Information providers; Interworking; Services and protocols

I. Introduct ion

Presently, the interfaces between communication switches and computing facilities are often based on non-standard agreements between the switch and computer manufacturing companies. Therefore the interworking between switch-based information systems in operation in the market is not exploited at its full capacity since different manufacturers use their own proprietary protocols and interfaces to link user premises to information providers. The proliferation of private communication interfaces limits the universality and accessability to the available information services and prevents the multi-vendor offering of information-based value-added services.

A network-based information system must be able to exploit the power of interconnecting two major interacting types of components, namely, host computers and communication switches. Host computers provide access interfaces which allow interactive users to select and connect to a specific Information Service Provider (ISP). Communication switches provide the external physical interfaces to the user's access device and manage the switching and routing of user calls between various host computers and

* Corresponding author. Email: [email protected]

0920-5489/94/$07.00 © 1994 Elsevier Science B.V. All rights reserved SSDI 0920-5489(93)E0074-C

342 K. Saleh, H. Ural / Computer Standards & Interfaces 16 (1994) 341-368

ISPs. In this paper, we refer to a host computer and a switch as a Catalogue Access Machines (CAM) and a Gateway Access Switch (GAS), respectively. In a typical multi-vendor network-based information environment, many GASs, ISPs and CAMs may exist, and must be able to interwork in a harmonious and efficient manner.

Currently, an activity within the European Computer Manufacturers Association (ECMA) aims at providing integration between computing networks and private telecommunications networks, and at standardizing computer supported telecommunications applications [5].

In this paper, we propose a new standard communication interface between GASs and CAMs. The proposed interface will be very useful in allowing a smooth communication between various switches and computers, and therefore, will allow an easy expansion of the global information service. Such standardization will allow switches to interwork with computers all made by different manufacturers. As a result, the spectrum of accessible value-added information services across a variety of communication networks will be wider. Our contribution in this work enriches ECMA's activity by providing the framework for a standard interface over which standard applications can be supported. Our interface design is simple, elegant and provides a secure and efficient access to information providers.

The proposed interface is formally specified in Estelle [8], a formal description technique for the specification of distributed systems, and more specifically, communication protocols and services. Formal Description Techniques (FDTs) are basically specification languages which have been developed within ISO TC97/SC21/WG1 to formally and unambiguously describe OSI service and protocol standards. The intent of an FDT, in addition to being a specification technique, is to be used as a basis for

(i) analyzing specifications for correctness and efficiency, (ii) determining completeness of specifications,

(iii) verification of specifications against the requirements of the standards, and (iv) determining conformance of implementations to recommendations. Estelle is one of three FDTs standardized by ISO and CCIq-T.

The remainder of the paper is organized as follows. Section 2 presents a possible network configuration model embodying the proposed Information Gateway Service Interface (IGSI), and provides a brief introduction to the major features of Estelle. Section 3 gives an informal description of the interactions between CAM, GAS and ISP using an information gateway access scenario. Section 4 formally describes in Estelle the interface between a CAM and a GAS. Section 5 briefly describes the benefits of the formal definition of the interface. Finally, Section 6 concludes the paper.

2 . P r e l i m i n a r i e s

2.1. Network configuration model for information gateway services

In this section, we first introduce a configuration model which includes the various interacting network components where IGSI can be used. Then, we briefly introduce the formal description technique Estelle which will be used to formally specify IGSI.

Fig. 1 shows one possible network configuration in which standard and open interfaces would be very useful for providing an open system accessibility to a multitude of information providers. The elements involved in this model, in addition to the CAM, ISP and GAS introduced in the previous section, are: - The user access device through which the user interacts with the selected GAS and ISP. - The Public Switched Telephone Network (PSTN) which provides a dialed access communication from

the access device to the GAS. - The Packet Switch Network (PSN) which provides a communication medium between the GAS, the

CAM and the ISP.

K. Saleh, H. Ural / Computer Standards & Interfaces 16 (1994) 341-368 343

ISP

X.25

ISP

X.I ISP

ISP

Fig. 1. A possible network configuration model.

As shown in Fig. 1, the CAM can be connected to any PSN or directly to the GAS. It is also possible to support more than one CAM with the GAS allowing access to all of them. Also, ISPs can be connected to any PSN or directly to the GAS which can also be part of the PSN. The advantage of this configuration model is that CAM can be in a pass-off mode for the duration of the user access to ISP by eliminating the CAM from the information access path. Therefore, for a particular user access to an ISP, the CAM will be offioaded since its resources (i.e. CPU time and processes) will not be required for the entire duration of the user access to the ISP. However, the CAM will be responsible for saving the context for that user session and for restoring it back once the access to the ISP is terminated. This mode of operat ion will allow the CAM to handle an increased number of user calls. In general, with this configuration in mind, CAM will only be specialized in fetching information service catalogues and in user interface functions, while the GAS performs the call routing, control and management functions. In Fig. 2, a higher level of abstraction, which excludes the PSN and the PSTN, shows the major interfaces involved in the provision of the information gateway service. It also shows that the GAS can act as a logical switch between an ISP and a CAM.

The out-of-band signalling mode is used in this specification. A control channel (CC) is used to exchange control messages only between the GAS and the CAM for the purpose of multiplexing control information for many user sessions. However, many CCs can be established to provide some load balancing and to enhance overall throughput. A user channel (UC) is used to transfer user data for each

344 I~ Saleh, H. Ural / Computer Standards & Interfaces 16 (1994) 341-368

® tcom u r [

IGSI S S

S

, I ISP (computer)

Fig. 2. A simplified view showing the interfaces.

ongoing session. This signalling mode was chosen since it speeds up the processing and discrimination between user data and control primitives.

2.2. An overview of Estelle

Estelle [7] (extended state transition language) is a formalism developed by ISO (International Organization for Standardization) for the specification of distributed systems (e.g. telecommunication systems). In particular, it has been proposed for specifying OSI protocols and services. Estelle is a state-transition-oriented language based on (i) extended finite state machines to describe the system behaviour and

(ii) extensions to the Pascal programming language. Estelle elaborates the finite state machine model by using control structures and Pascal data types to fully specify distributed systems, among which protocols, services and communication interfaces. For a complete introduction to Estelle, the reader may refer to [4].

Estelle provides features for the description of two important aspects of distributed systems: the architectural model and the behavioural model. The architectural model describes a hierarchically structured system of nondeterministic and communicating modules exchanging messages across bidirectional channels. The model assumes that unbounded FIFO buffers exist at the receiving end of each channel where messages are kept until the receiving module is ready to process them. The hierarchical structure of modules, created during a module initialization phase, is dynamic and may change during the progress of communication between modules. The behavioural model allows the description of the state-transition-oriented behaviour of individual modules using an extended finite state machine (EFSM). An EFSM representation of a module consists of a set of transitions which are executed once the preconditions for executability are satisfied. So far, Estelle have been successfully used to specify OSI services and protocols, such as, the Virtual Terminal protocol [1], the Network service [7], the Transport protocol [3], the Session protocol [11] and the Presentation protocol [10].

In Estelle, a distributed system may be specified in terms of externally observable behavior of a collection of modules which are exchanging messages (called interactions) with each other and with their environment through bidirectional links (called channels) between their port (called interaction points). An interaction exchanged at an interaction point of a module transfers information either from the module (i.e. an output interaction of the module) or to the module (i.e. an input interaction of the module). Each interaction is defined as consisting of an interaction identifier followed by a (possibly empty) list of interaction parameters.


A system specification in Estelle consists of the definitions of the channels and the modules comprising the structure of the specification. A channel definition consists of a channel heading definition and a channel block definition. In the channel heading, the identifier for the channel and the two roles (i.e., 'user ' and 'provider ') that are used to indicate the initiator of interactions exchanged through the channel are given. These roles will be assumed by a pair of modules interacting through the channel. The channel block first groups interactions that are exchanged through the channel as those that are initiated by 'user' or 'provider' and then enumerates each group of interactions by giving identifiers of each interaction and its parameter fields.

A module definition consists of a module header definition and a module body definition. In the module header, the identifier for the module, the identifier of each interaction point of the module, the identifier of the channel associated with each interaction point, and the role of the module plays on the channel associated with each interaction point are given. The module body defines the externally observable behavior of the module (i.e. the possible orderings of interactions exchanged at the interaction points of the module) by an EFSM. Possible ordering of interactions that a module exchanges are given in terms of the state space and the possible state transitions of the module where extensions (e.g. operations on interaction parameters) are expressed in a version of ISO Pascal [6].

The state space of a module is specified by a set of variables (i.e. the control state variable, called state, and some additional state variables). A possible state of the module is characterized by the values of all of these variables. Each state transition is associated with an enabling condition and an action. The enabling condition of a transition defines the conditions that must be satisfied for the transition to be enabled for execution. At any given time there may be more than one transition enabled. However, only one enabled transition may be nondeterministically selected and executed at any given time. Execution of a transition is considered to be atomic (i.e. non-interruptible) and corresponds to performing the action associated with the transition. The action of a transition may change the state of the module, modify the values of additional state variables, and initiate output interactions.

Each state transition of a module is characterized by a clause group and a transition block. The clause group of a transition consists of at most one occurrence of each of the following clauses: (BNF notation is used for the syntax hereinafter) (a) FROM clause. ' from' (state-id t state-set-id).

Specifies the state (s) from which the transition may originate. If this clause is not present, then the transition is understood to originate from any state.

(b) TO clause: ' to' (state-id 1'same'). Specifies the state reached after the execution of the transition. If this clause is not present, then it is understood that the state does not change.

(c) WHEN clause: 'when' interaction-point-id ' . ' interaction-id [interaction-parameter-list]. Specifies which input interaction must be received to partially enable the transition. If this clause is not present, then the transition is said to be a spontaneous transition.

(d) P R O V I D E D clause: 'provided' (boolean-exp I'othcrwise'). Specifies a conjunct of the enabling condition that must be satisfied for the transition to be enabled. If this clause is not present, then it is understood to be 'TRUE' . Note that the other conjuncts of the enabling condition are identified by FROM and WHEN clauses.

(e) DELAY clause: 'delay' '(' (exp ',' exp [exp ',' '* ' lexp) ')', which may be used only for a spontaneous transition, specifies (1) the minimum time units that the transition remains enabled before it is considered for execution (2) an optional upper bound (i.e. the maximum) on time units after which an enabled transition must

be considered for execution. (f) PRIORITY clause: 'priority' (unsigned-integer I constant-id).

Specifies the relative priority of the transition with respect to other transitions in terms of a priority

346 K Saleh, H. Ural / Computer Standards & Interfaces 16 (1994) 341-368

number (the lowest non-negative integer is the highest priority). If this clause is not present, then the lowest priority is assumed.

(g) ANY clause: 'any' domain-list 'do'. Specifies the transition as a shorthand for a set of transitions in which no transition contains an ANY clause.

The transition block of a transition consists of a constant definition part; a type definition part; a variable declaration part; a procedure and function declaration part; a transition name, and a statement part. Definition and declaration parts are given as in the version of ISO Pascal used in [7]. The transition name is given by: 'name' id ':'. The statement part is given by a compound statement which is a statement sequence enclosed by 'begin' and 'end;'. Each statement in the statement sequence is either a simple statement (i.e. an assignment statement; a procedure statement; or an output statement) or a structured statement (i.e. a compound statement; a conditional statement, i.e. IF or CASE; a repetitive statement, i.e. REPEAT, WHILE, FOR; or a WITH statement). Together with the TO clause, the statement part of a transition block defines the action associated with the transition.

3. I n f o r m a t i o n gateway access se s s ion scenario

In this section, an informal scenario-based description of an Information Access Session (IAS) will be presented. In this scenario, the user will be able to first interact with the CAM through the GAS to select a particular ISP. Then the user terminates this access and selects another ISP after returning to the CAM. The interactions between the user and the ISP constitute an Information Retrieval Session (IRS). The interactions between the user and CAM constitute a Provider Selection Session (PSS). An IAS always starts and normally terminates with a PSS. An IAS consists of non-interleaved sequences of PSSs and IRSs (Fig. 3). To start a PSS, the CAM and the GAS need to exchange control information,

IAS

PSS PSS PSS PSS I I" I I I I

I I I I I I

I IRS I I m s I I m s I

User logon (dial in)

User Call duration

Fig. 3. Interleaving during an information access session.

User logoff


such as user identification and ISP database selection. However, during an IRS, information to initiate and terminate the session on behalf of the user must be communicated to CAM. The user can also access a new CAM, however, the current IAS must be terminated. The main features of our interface design are that:

(i) the internal design of the CAM and GAS are t ransparent to each other, and the interface makes no assumptions about them,

(ii) a bet ter access security to the information providers is achieved by requiring all user accesses to arrive through special ports from the GAS,

(iii) a bet ter throughput is achieved by using an out-of-band approach in which control and user data are separated, consequently, the processing overhead is eliminated, and

(iv) it is modular (using phases) so that the interface development (verification and implementation) is made easier.

A typical scenario of an IAS proceeds as follows. - The user dials the Information Gateway Access Switch (GAS) using a CAM phone number to which

the user subscribes. - The PSTN routes the call to a GAS, which terminates the dialed connection. - The GAS establishes communication with the CAM and indicates the service requested and the origin

of the call. - The GAS sets up a data call between the CAM and the user to enable the user to choose an ISP

through an interactive dialogue with the CAM. - The CAM tells the GAS which ISP has been selected by the user, how it can be accessed, and some

ISP logon data. - The GAS transfers the user 's data call from the CAM to the ISP. - The logon is automatically performed by the GAS on behalf of the user. The GAS sends the logon

data, and parses the ISP response for an indication of a successful logon. - The ISP and the user establish a dialogue or information retrieval session (IRS) to provide the user

with the information or service requested. - The user can terminate the IRS to return to the CAM. The ISP initiates the call clearing procedures. - The GAS establishes another call to the CAM and indicates which IAS is returning. The CAM starts

another PSS by restoring the previous context for that user. - Through the dialogue with the CAM, the user can then select another ISP as before and get

connected to it. - To terminate an IAS during a PSS, the user can indicate its request in the dialogue with the CAM.

The CAM informs the GAS, which drops the user connection through the PSTN, and disconnects the CAM call. The three interfaces shown in Fig. 2 are between the user access device and the GAS, the GAS and

the ISP, and the GAS and the CAM. In this paper, we only propose a definition of the interface between the GAS and the CAM, referred to as the Information Gateway Service Interface (IGSI), and we concentrate on the CAM's contribution to this interface.

4. Formal def init ion of the informat ion gateway service interface

In this section, we formally define the CAM's contribution to the IGSI. First, we introduce the architectural model and its components: the interaction points, channels and modules involved and their interconnections. Then, we introduce the behavioral model and its components, i.e. the extended finite state machine modeling the behaviour of the CAM which specifies both data and control flows.


GAS_Module

U_CAM_ACCESS_POINT C CAM ACCESS POINT

\ / ALARM ACCESS POINT X., _, f - -

CAM_Module

/

Fig. 4. High level architectural description of the CAM-GAS interface.

4.1. The architectural model

Fig. 4 shows a high level architectural description of the interface. The basic elements involved in this architecture are:

(i) two channels through which the GAS and the CAM exchange messages, namely, the User Channel (UC) and the Control Channel (CC),

(ii) five access points or interaction points, namely, the U_CAM_access_point, the U_ GAS _ access_ point, the C_ CAM_access_point, the C_ GAS_ access_point, and an Alarm_ access_point, and

(iii) the two interacting modules, namely, the CAM module and the GAS module. In the following we describe, in Estelle, the basic elements of the architectural model for IGSI.

(* Channel Definitions *) channel User_Channel (USER, PROVIDER); by USER:

(* messages sent on the user channel by CAM *) by PROVIDER:

(* messages sent on the user channel by GAS *)

channel Control _Channel (USER, PROVIDER); by USER:

(* message sent on the control channel by CAM *) by PROVIDER:

(* messages sent on the control channel by GAS *) channel Alarm_ Channel (USER); by USER:

(* messages sent on the alarm channel by CAM *) (* Module Definitions *) module CAM - entity;

ip A: Alarm_ Channel (USER); U : User_Channel (USER); C : Control_ Channel (USER);

end

Saleh, H. Ural / Computer Standards & Interfaces 16 (1994) 341-368 349

Body CAM_body for C A M e n t i t y ; (* behavioral definitions *)

Modvar Catalogue_Access_Machine: CAM_entity;

initialize (* of IGSI *) begin

init Catalogue_Access_Machine with CAM_body; connect Catalogue_Access_Machine.U to Gateway_Access_Switch.U; connect Catalogue_Access_Machine.C to Gateway_Access_Switch.C;

end; end.

The complete Estelle specification of the architectural model of the interface is provided in the appendix.

4.2. The behavioral model

To structure and modularize the behavioral model of the CAM's contribution to the interface, we identify the following main phases involved: (1) GAS setting up the CC with CAM, (2) identification and GAS parameters setting, (3) sanity checks or probes on the CC, (4) starting an IAS, (5) PSS activity, (6) starting a IRS, (7) ending an IRS, (8) starting nother PSS, and (9) clearing an IAS.

In the following, we present the complete Estelle specification of the behavioural model of the interface.

body CAM_body for CAM_entity; state

idle, CC_ estab, wait _ clear_ cnf, wait_ ack_ id, wait_ ack_ set_ CAM_ params, wait_IAS_request , w a i t p r o b e _ r e s p o n s e , wait_call_request, IAS_PSS_estab, wait _ IRS _ response, wait _ ack_ logon_ data, wait _ IRS _ params _ ack, wait_clear_indication, IRS_estab, wait_PSS_request , IAS_PSS_cleared, wait _ IAS _ PSS _ clear_ cnf, wait _ ack _ clear_ cnf, wait _ ack_ data;

stateset probe_state = [any state]; alarm c l e a r _ state = [any state excluding alarm_ state]; alarm _ state = [wait_ ack_ id, CC_ estab, wait_ ack_ set _ GAS _ params, wait_ IAS _ request]; IAS_cleared_s ta te = [any state excluding idle, CC_estab, wait_clear_cnf , wait_ack_id,

wait_ ack_set_ GAS_params, wait_ IAS_request]; var

expected_msg code, clear_cause, clear_diagnostic, seq_num: integer; ISP_name, DNA, IAS_id, GAS_PSS_id , CAM_PSS_id , CAM_CC_id: identifier string;


logon _ data, user_ data, IRS _ data, PSS _ data, logon _ reply, facilities: data_ string; buffer, l a s t s e n t m e s s a g e : m e s s a g e ;

(* Procedures and Functions *) procedure get _ PSS _ data(var PSS _ data: data_ string); primitive; procedure get_ IRS _ data(var IRS _ data: data_ string); primitive; procedure get user_data(var u s e r data: data:str ing); primitive; procedure retr ieve_last_ sent_ message(var last_ sent_ message: message, buffer: message); primitive; procedure store_ last _ sent_ message(var last_ sent_ message: message, var buffer: message); primitive; procedure get_ X.25 _ clearing_ info(var clear_ cause, clear_ diagnostic: integer); primitive; procedure get ISP info(ISP name: identifier_string; var DNA: identifier string; var facilities,

user data, logon data, logon reply: d a t a s t r i n g ) ; primitive; procedure get ± ISP_ name(var ISP_ name: identifier_ string); primitive; function invalid (DNA: identifier string): boolean; primitive; function user_ clear_ detected : boolean; primitive; function CAM_ congested : boolean; primitive; function get GAS PSS_id: identifier; primitive; function get CAM PSS id: identifier; primitive; function get C A M _ C C id: identifier; primitive; function ge t_GAS CC id: identifier; primitive; function reason f o r b a d _ i d e n t i f y ( IDENTIFY: message): integer; begin

reason _ for_ bad _ identify:= no _ error; if identify.GAS PSS i d < > GAS PSS id then reason _ for_ bad _ identify := unknown _ GAS _ PSS _ id else if identify.msg code < > expected_msg code then r eason_fo r_bad identify:= unexpected_message;

end; function r eason_fo r_bad IAS request(IAS request: message): integer; begin

reason_ for_ bad_ IAS _ request := no_ error; if invalid (IAS_ request .DNA) then reason _ for_ bad_ IAS_ request := invalid_ port_ D N A else if C A M c o n g e s t e d then reason_ for_ bad _ IAS_ request :-- invalid_ port_ user_ data;

end; function reason for_IAS clearing: integer; begin

reason for IAS_clearing := no_error ; if user clear detected then reason _ for_ IAS _ clearing := user_ cleared_ call else if C A M c o n g e s t e d then reason_ for_ IAS_ clear ing:= CAM_ problems;

end;

(* Initialization *) initialize to idle begin seq_ num := 0; end;

(* transitions of the CAM_ent i ty *)

I( Saleh, H. Ural / Computer Standards & Interfaces 16 (1994) 341-368 35

trans (* Set up CC (Cont ro l Channe l ) *)

when C . C A L L _ R E Q U E S T

from idle to C C _ e s t a b (* p rov ided CC is avai lable and reques t is val id *) name tO.l:

begin out C . C A L L _ A C C E P T

e x p e c t e d _ m s g _ c o d e := m s g _ c o d e _ I D E N T I F Y ; end; when C . C A L L _ R E Q U E S T

f rom idle to w a i t _ c l e a r _ c n f (* p rov ided CC is not avai lable or reques t is invalid *) name t0.2:

begin out C . C A L L _ C L E A R

end; when C . C A L L _ C L E A R _ C N F

f rom wai t _ c l ea r_ cnf to idle name t0.3:

begin end;

(* iden t i f i ca t ion and G A S p a r a m e t e r s se t t ing *) when C . I D E N T I F Y

f rom C C _ es tab to wai t _ ack _ id p rov ided r eason for bad i d e n t i f y ( I D E N T I F Y ) = no_ e r ro r

name t l . l : begin

G A S _ PSS _ id -'= ge t_ G A S _ PSS _ id; C A M _ C C _ i d := g e t _ C A M _ C C _ i d ; s e q _ n u m := s e q _ n u m + 1; out C . P O S _ A C K

( m s g _ c o d e _ P O S _ A C K , G A S _ PSS_ id, seq_ num, I D E N T I F Y . s e q _ n u m ) ; (* a c k e d _ s e q _ n u m *)

s t o r e _ l a s t _ s e n t _ m e s s a g e ( P O S _ A C K , buffer); seq_ num := seq_ n u m + 1; out C. I D E N T I F Y

(msg_ code _ I D E N T I F Y , G A S _ PSS _ id, s e q _ n u m , C A M _ id, C A M _ C C _ id);

s t o r e_ las t_ sen t_ message ( I D E N T I F Y , buffer); end; when C . P O S A C K

f rom wait _ ack_ id to wa i t_ ack_ se t_ G A S _ p a r a m s


name tl.2: begin

seq_num=seq_num + 1; out C.SET_ GAS _PARAMS

(msg_code_SET_ G A S _ P A R A M S , GAS_PSS_id , seq_ num, time _ CC _ inactivity_ max, GAS _ params);

store _ last_ sent_ message (SET_ GAS _ PARAMS, buffer); end; when C.POS_ACK from wait_ ack_ set_ CAM_ params to wait_ IAS_ request

name tl.3: begin end; when C.IDENTIFY from CC_ estab to CC_ estab provided r eason_fo r_bad_ iden t i fy ( IDENTIFY) < > no_er ro r

name tl.4: begin

seq_num := seq_num + 1; out C.NEG_ACK

( m s g _ c o d _ N E G _ A C K , GAS_PSS_id , seq_ num, IDENTIFY.seq_ num, (* nacked_ seq_ num *) reason_ for_ bad_ identify(IDENTIFY));

s to re_ las t_sen t_message ( N E G _ A C K , buffer); end;

(* CC Probe *) delay ( t ime_ CC_ inactivity_ max) from probe_ state to wait_ probe_ response

name t2.1: begin

seq_num "= seq_num + 1; out C.PROBE_REQUEST

( m s g _ c o d e _ P R O B E _ R E Q U E S T , GAS _ PSS _ id, seq_ hum, CAM_id, CAM _ CC_ id);

s tOre_las t_sent_message ( P R O B E _ R E Q U E S T , buffer); end; when C.PROBE_RESPONSE from wai t_probe_response to probe_s ta te (* provided valid probe response *)

K~ Saleh, H. Ural / Computer Standards & Interfaces 16 (1994) 341-368 353

name t2.2: begin end; when C.PROBE RESPON SE f rom wai t_ p r o b e _ r e sponse to p r o b e _ s ta te (* p rov ided inval id p r o b e r e sponse *)

name t2.3: begin

s e q _ n u m := s e q _ n u m + 1; out A . A L A R M

( m s g _ c o d e _ A L A R M , G A S _ PSS _ id, seq_ num, inval id_ p r o b e _ response) ; (* r e a s on_ for_ a l a rm *)

s t o r e_ las t_ sen t_ message ( A L A R M , buffer); end; delay ( a c k _ t i m e o u t _ m a x ) f rom wai t_ p r o b e _ r e sponse to p r o b e _ s ta te

name t2.4: begin

s e q _ n u m : = s e q n u m + l ; out A . A L A R M

( m s g _ c o d _ A L A R M , G A S _ P S S _ i d , seq_ num, t imeou t _ on _ ack); (* r eason _ for_ a l a rm * )

s tore _ las t_ sen t_ message ( A L A R M , buffer); end; when C . P R O B E _ R E Q U E S T f rom p r o b e _s ta te to p r o b e s ta te

name t2.5: begin

seq num := s e q _ n u m + 1; out C . P R O B E _ R E S P O N S E

( m s g _ c o d e _ P R O B E _ R E S P O N S E , G A S _ P S S _ i d , seq_ num, C A M _ id, C A M _ C C _ id);

s tore _ las t_ sen t_ message ( P R O B E _ R E S P O N S E , buffer); end;

(* S ta r t ing an I n f o r m a t i o n Access Session ( IAS) *) when C . I A S _ R E Q U E S T f rom wai t_ I A S _ reques t to wa i t_ I A S _ reques t (* p rov ided C A M resource are not avai lable or IAS reques t is invalid *)

354 I~ Saleh, H. Ural / Cornputer Standards & Interfaces 16 (1994) 341-368

name t3.1: begin

get_ X.25 _ clearing_ info(clear_ cause, clear_diagnostic) ; s e q _ n u m := s e q _ n u m + 1; out C. IAS_REFUSE

(msg_ code _ IAS _ R E F U S E , G A S _ PSS_ id, seq_ num, clear_ cause, c lear_ diagnostic, reason_ f o r _ b a d _ I A S _ r e q u e s t ( I A S _ R E Q U E S T ) ) ;

s t o r e _ l a s t _ se n t _m e ssa ge ( I A S _ R E F U S E , buffer); end; when C . I A S _ R E Q U E S T from wait_ I A S _ request to wait_ call_ request (* provided C A M resource are available and I A S _ R E Q U E S T is valid *)

name t3.2: begin

IAS _ id := IAS _ R E Q U E S T . I A S _ id; ge t _use r_da t a (u se r_da t a ) ; C A M _ P S S _ i d := g e t _ C A M _ P S S _ i d ; seq num := s e q _ n u m + 1; out C. I A S _ A C C E P T

(msg_ code _ IAS _ A C C E P T , GAS _ PSS _ id, seq_ num, IAS_id , C A M _ PS S _ id, C A M _ D N A , user_ data);

s t o r e _ l a s t s e n t _ m e s s a g e ( I A S _ A C C E P T , buffer); end; when U . G A S _ C A L L _REQUEST from wait_ call_ request to I A S _ PSS_ estab (* provided valid call request and resources are available *)

name t3.3: begin

out U.CAM_ CALL _ACCEPT store _ last_ sent_ message ( C A M _ C A L L _ A C C E P T , buffer);

end; when U . G A S _ C A L L _REQUEST f rom wai t_ca l l_ reques t to wa i t _c l ea r_cn f (* provided invalid call request or resources are not available *)

name t3.4: begin

out U.CAM_CLEAR _REQU ES T s t o r e _ l a s t _ se n t _m e ssa ge ( C A M _ C L E A R _ R E Q U E S T , buffer);

end;


when U.GAS _ C L E A R _ C O N F I R M

f rom wai t_ c l ea r_ cnf to wai t_ cal l_ r eques t name t3.5:

begin end;

(* P rov ide r Se lec t ion Session (PSS) activity *) f rom IAS _ PSS _ es tab to wait _ ack_ da t a

name t4.1: begin

ge t_ P S S _ d a t a ( P S S _ d a t a ) ; s e q _ n u m := s e q _ n u m + 1; out C.PSS _DA TA

(msg_ cod _ PSS _ D A T A , G A S _ PSS _ id, seq _ num, P S S _ d a t a ) ;

s to re_ las t_ sen t_ message (PSS_ D A T A , buffer); end; f rom IAS _ PSS _ es tabl to wai t _ ack_ da t a

name t4.2: begin

ge t_ I R S _ d a t a ( I R S _ d a t a ) ; seq num := s e q _ n u m + 1; out C . I R S _ D A T A

(msg_ code _ IRS _ D A T A , G A S _ PSS _ id, seq_ num, I R S _ d a t a ) ;

s tore _ las t_ sen t_ message ( I R S _ D A T A , buffer);

end; when C . P O S _ A C K

f rom wait ack_ da ta to I A S _ PSS_ es tab name t4.3:

begin end;

(* S ta r t ing an in fo rma t ion Re t r i eva l Session ( I R S ) * ) f rom I A S _ P S S _ e s t a b to w a i t _ I R S _ r e s p o n s e (* p rov ided val id call r eques t and resources a re avai lable *)

name t5.1: begin

ge t_ I S P _ n a m e ( I S P _ n a m e ) ; ge t_ ISP_ info ( ISP_ name , D N A , facil i t ies, logon_ da ta , logon_ reply); g e t _ u s e r _ d a t a ( u s e r _ d a t a ) ; s e q _ n u m := s e q _ n u m + 1; out C . I R S _ R E Q U E S T


( m s g _ c o d e _ I R S _ R E Q U E S T , G A S _ PSS _ id, seq_ num, D N A , facilities, user_ data);

s tore_ last_ sent_ message ( IRS_ R E Q U E S T , buffer); end; when C. I R S _ R E F U S E f rom wait_ I R S _ response to I A S _ PSS_ estab

name t5.2: begin end; when C . I R S _ A C C E P T f rom wait_ I R S _ response to wait_ ack_ logon_ data (* provided s e t _ I R S _ p a r a m is not required *)

name t5.3: begin

seq_ num := seq_ n u m + 1; out C . I R S _ L O G O N DATA

(msg_ code _ IRS _ L O G O N _ D A T A , G A S _ PSS_ id, seq_ num, logon_data ) ;

store _ last_ sent_ message ( IRS _ L O G O N _ D A T A , buffer); end; when C.IRS A C C E P T f rom wait_ I R S _ response to wait_ I R S _ pa rams_ ack (* provided s e t _ I R S _ p a r a m is not required *)

name t5.4: begin

s e q _ n u m := s e q _ n u m + 1; out C . S E T _ I R S _ P A R A M S

( m s g _ c o d e _ S E T _ IRS_ P A R A M S , G A S _ PSS_ id, seq_ num, logon_ reply);

s t o r e _ l a s t _ se n t _m e ssa ge ( S E T _ I R S _ P A R A M S , buffer); end; when C . P G S _ A C K f rom wait_ IRS _ pa rams_ ack to wait_ ack_ logon_ data

name t5.5: begin

seq num := s e q _ n u m + 1; out C.IRS _ L O G O N _ D A TA

(msg_ code _ IRS _ L O G O N _ D A T A , G A S _ PSS_ id, seq_ num,

K Saleh, H. Ural/Computer Standards & Interfaces 16 (1994) 341-368 357

logon_ data); s t o r e _ l a s t _ s e n t m e s s a g e ( I R S _ L O G O N _ D A T A , buffer);

end; when C.POS _ACK from wait ack logon_data to wait_clear indication

name 15.6: begin end; when U.GAS _ CLEAR _INDICATION from wait_clear_indicat ion to IRS_es tab

name I5.7: begin

out U.CAM_ CLEAR _ CONFIRM s tore_ las t_sent_message ( C A M _ C L E A R _ C O N F I R M , buffer);

end;

(* Ending an Information Retrieval Session ( I R S ) * ) when C. IRS _END from IRS _ estab to wait_ PSS _ request

name t6.1: begin

seq_num := seq_num + 1; out C.POS A C K

(msg_ code _ POS _ ACK, GAS_ PSS_id, seq_ num, IRS_END.seq_num) ; (* acked_seq_num *);

s t o r e l a s t s e n t _ m e s s a g e (POS ACK, buffer); end;

(* Starting another Provider Selection Session (PSS) *) when C.PSS R E Q U E S T from wait_ PSS _ request to wait_ call_ request (* provided call request is valid and resources are available *)

name t7.1: begin

seq n u m : = seq n u m + l ; out C . P S S _ A C C E P T

(msg_ code _ PSS _ ACCEPT, GAS _ PSS _ id, seq_ num, CAM _ DNA, CAM_user_da ta ) ;

store las t_sent_message (PSS_ACCEPT, buffer); end; when C . P S S _ R E Q U E S T from wait_ PSS_ request to wait_ PSS_ request (* provided call request is not valid or resources are not available *)


name t7.2: begin

get_ X.25 _ clearing_ info(clear_ cause, clear_diagnostic) ; seq num := s e q _ n u m + 1; out C . P S S _ R E F U S E

(msg_ code _ PSS _ R E F U S E , G A S _ PSS _ id, seq_ num, clear_ cause, clear_ diagnostic, C A M _ c o n g e s t e d _ c o d e ) ; (* r e a s o n _ c o d e *)

s t o r e _ l a s t s e n t _ m e s s a g e ( P S S _ R E F U S E , buffer); end;

(* Te rmina t i on / c l ea r ing of an informat ion access session *) when C . /AS_ C L E A R

from wait_ call_ request to I A S _ PSS_ cleared name t8.1:

begin s e q _ n u m := s e q _ n u m + 1; out C . I A S _ C L E A R _ C O N F I R M

( m s g _ c o d e _ I A S _ C L E A R _ C O N F I R M , G A S _ PSS _ id, seq_num) ;

s t o r e _ l a s t _ se n t _m e ssa ge ( I A S _ C L E A R _ C O N F I R M , buffer); end; from I A S _ c leared_ state to wait_ IAS _ PSS _ clear_ cnf (* provided user reques ted terminat ion or a disconnect sequence is de tec ted *)

name t8.2: begin

get_ X.25_ clearing_ info(clear_ cause, clear_diagnost ic) ; seq num := s e q _ n u m + 1; out C. I A S _ C L E A R

(msg_ code _ IAS _ C L E A R , G A S _ P S S _ i d , seq_ num, c lear_ cause, c lear_ diagnostic, reason _ for_ IAS _ clearing(IAS _ R E Q U E S T ) );

s t o r e _ l a s t _ se n t _m e ssa ge ( I A S _ C L E A R , buffer); end; from IAS_PSS_estab to w a i t _ I A S _ P S S _ c l e a r _ c n f (* provided Condi t ion to clear is satisfied *)

name t8.3: begin

get_ X.25 _ clearing_ info(clear_ cause, clear_diagnostic) ; s e q _ n u m := s e q _ n u m + 1; out C . I A S _ C L E A R

tC Saleh, H. Ural / Computer Standards & Interfaces 16 (1994) 341-368 359

(msg_ code _ IAS _ CLEAR, GAS _ PSS _ id, seq_ num, clear_ cause, clear diagnostic, reason for IAS c lear ing( IAS_REQUEST)) ;

s tore_last_sent_message ( IAS_CLEAR, buffer); end; when C. I A S _ C L E A R _ C O N F I R M

from wait_ 1AS _ PSS _ clear_ cnf to wait_ ack_ clear_ cnf n a m e t8.4:

begin out U . C A M _ C L E A R _ R E Q U E S T

store_last_sent_message ( C A M _ C L E A R _ R E Q U E S T , buffer); end; when U . G A S _ C L E A R _ C O N F I R M

from wait_ ack_ clear_ cnf to IAS_ PSS_ cleared n a m e t8.5:

begin end;

In addition to the above transitions, some additional transitions are applicable in more than one phase. These transitions are needed to handle the cases of negative acknowledgements and timeout.

(* Negative acknowledgement *) when C. N E G _ A C K

from alarm_ clear_ state to same (* provided conditions to clear are satisfied *)

n a m e t x l :

begin retrieve last sent message(last_sent message, buffer); out C . L A S T _ S E N T M E S S A G E

store _ last_ sent _ message (LAST_ SENT_ MESSAGE, buffer); end; when C . N E G A C K

from alarm_ clear_ state to wait_ IAS_ PSS _ clear_ cnf (* provided conditions to clear are not satisfied *)

n a m e tx2: begin

get X.25_ clearing info(clear_ cause, clear_diagnostic); seq num := seq_num + 1; out C. I A S _ C L E A R

(msg_ code _ IAS _ CLEAR, GAS _ PSS _ id, seq_ num, clear_ cause,

360 I£ Saleh, H. Ural / Computer Standards & Interfaces 16 (1994) 341-368

end;

clear_ diagnostic, user_ cleared_ call); (* reason_ code *)

s tore_last_sent_message ( IAS_CLEAR, buffer); seq_num := seq_num + 1; out A. ALARal4

(msg_code_ALARM, GAS _ PSS _ id, seq_ hum, IAS_ cleared); (* reason_ for_ alarm *)

store _ last_ sent_ message (ALARM, buffer);

(* T I M E O U T *) delay (ack_ t imeout_max) from alarm _ clear_ state to alarm _ clear _ state (* provided it is the first retransmission *)

name ty: begin

retrieve_ last_ sent_ message(last_ sent_ message, buffer); out C.LAST_SENT_MESSAGE store_last_sent_message (LAST_SENT_MESSAGE, buffer);

end; delay (ack_t imeout_max) from alarm_clear_state to wai t_IAS_PSS_clear_cnf (* provided it is not the first retransmission *)

name tz; begin

get_ X.25 _ clearing_ info(clear_ cause, clear_diagnostic); seq_num := seq_num + 1; out C.IAS_CLEAR

(msg_ code_ IAS _ CLEAR, GAS _ PSS _ id, seq_ num, clear_ cause, clear_ diagnostic, user_cleared_call); (* reason_code *)

s tore_last_sent_message ( IAS_CLEAR, buffer); seq_num := seq_num + 1; out A.ALARM

(msg_code_ALARM, GAS_PSS_id , seq_ num, IAS_ cleared); (* reason_ for_ alarm *)

store_last_ sent_ message (ALARM, buffer); end; delay (ack_ t imeout_ max) from alarm_state to alarm_state (* provided it is the first retransmission *)


name tvl: begin

seq_ num := seq_ n u m + 1; out A. ALARM

(msg_code ALARM, GAS_ PSS_id, seq_ num, t imeout_ on_ ack); (* reason_ for_ alarm * )

store _ last_ sent_ message (ALARM, buffer); end; delay (ack_ timeout max) from alarm s t a t e to C C estab (* provided it is not the first retransmission

name tv2: begin

end; end:

*)

get_ X.25 _ clearing_ info(clear cause, clear_diagnostic); seq hum := seq_num + 1; out C. I A S _ C L E A R

(msg_ code _ IAS _ CLEAR, GAS PSS id, seq_ hum, clear_ cause, clear_ diagnostic, user cleared_call); (* r e a s o n c o d e *)

store _ last _ sent message (IAS _ CLEAR, buffer); seq_num := seq n u m + 1; out A M L A R M

(msg_ c o d e _ A L A R M , GAS _ PSS _ id, seq_ num, IAS_cleared); (* reason _ for alarm *)

store last sent_message (ALARM, buffer);

5. Benefits of the formal specification

The use of a formal description technique (FDT) such as Estelle is motivated by the benefits it provides throughout the system development life cycle. In addition to being capable of expressing the system functionality in a concise and unambiguous manner, an FDT-based specification can also be validated and checked for correctness. Furthermore, it can be used for automatic test case generation and selection. Many tools exist to support the automatic development of protocols [2]. These tools span the wide spectrum of activities that exist in the protocol engineering [9] life cycle, among which, textual and visual editing, specification validation, automatic code generation, implementat ion testing, test case generation, and test results analysis. A natural extension of this work includes: (1) the use of existing automated protocol specification verification tools and techniques [12] to check

the correctness of the proposed interface specification, and


(2) the use of existing test case generation and selection techniques [13,14] to obtain test cases that can be applied later on to verify the conformance of the interface implementation to its formal specification.

6. Summary and conclusion

The main purpose of this paper is twofold. First, the introduction of a standard specification for a new interface between communication switches and host computers. The standardization of such interface will allow switches and computers from different manufacturers to interwork in an open environment in order to provide a universal access to information service providers. Second, the use of Estelle, a formal description technique introduced by ISO, to formally specify the proposed interface. Estelle can be used to provide an architectural high level view of the desired interface and a detailed view of the behavior of the interface during different phases. The use of Estelle is found to be helpful for the understandability of the overall architecture of the interface and the phases involved in the behavioral aspects of the interface, for avoiding incompletenesses and ambiguities from the interface specification, and for providing a formal basis for the development of the interface.

In this paper, we only show the Estelle specification of the host computer or CAM's involvement in the interface. However, the switch or the GAS side of the interface must be compatible with the CAM specification and can also be specified in Estelle. Finally, the paper did not address the definition of the switch-information provider (GAS-ISP) interface, which should be standardized for the same reasons stated earlier.

7. Acknowledgements

The authors thank the anonymous referees for their comments that helped to improve this paper. Also, the authors acknowledge the partial support of this work by Kuwait University Research Grant EE059.

8. Appendix

specification IGSI; default individual queue; timescale seconds; const (*** message code constants ***)

msg _ code _ SET _ GAS _ PARAMS = 100, msg_ code_ SET_ IRS_ PARAMS = 101, m s g _ c o d e _ I A S _ C L E A R = 102, m s g _ c o d e _ P S S _ D A T A = 103, msg_ code _ IRS _ R E Q U E S T = 104, msg_code_IRS_ L O G O N _ D A T A = 105, msg_ code _ I RS _ D A T A = 106, msg_ code _ IAS _ ACCEPT = 107, msg_ code _ IAS _ REFUSE = 108, msg_ code _ PSS _ ACCEPT = 109,

K~ Saleh, H. Ural / Computer Standards & Interfaces 16 (1994) 341-368 363

m s g _ c o d e _ PSS _ R E F U S E = 110,

m s g _ c o d e _ P R O B E _ R E Q U E S T = 111,

m s g _ c o d e _ P R O B E _ R E S P O N S E = 112,

m s g c o d e I D E N T I F Y = 113,

m s g c o d e I A S C L E A R C O N F I R M = 114,

m s g c o d e P O S _ A C K = 115,

m s g c o d e N E G A C K = 116,

m s g c o d e I A S R E Q U E S T = 117,

m s g c o d e PSS R E Q U E S T = 118,

m s g c o d e I R S _ E N D = 119,

m s g c o d e I R S A C C E P T = 120,

m s g _ c o d e _ I R S _ R E F U S E = 121,

m s g _ c o d e _ I A S _ C L E A R = 122,

m s g c o d e A L A R M = 123,

(*** t i m e r r e l a t e d c o n s t a n t s - in s e c o n d s * * * )

t i m e _ C C inac t iv i ty_ m a x = 600,

ack _ t i m e o u t _ m a x = 15,

( * * * e r r o r c o d e c o n s t a n t s * * * )

C A M _ c o n g e s t e d _ c o d e = 201,

C A M _ p r o b l e m s = 203,

u n e x p e c t e d _ m e s s a g e = 204,

u n k n o w n _ G A S _ P S S _ id = 205,

t i m e o u t _ o n _ ack = 206,

inva l id _ p r o b e _ r e s p o n s e = 207,

n o e r r o r = 208,

inva l id _ p o r t _ D N A = 209,

i n v a l i d _ p o r t _ u s e r _ d a t a = 210,

u s e r c l e a r e d call = 211,

I A S c l e a r e d = 213,

(*** C A M a n d G A S r e l a t e d c o n s t a n t s * * * )

C A M id = " . . . . . . ",

C A M _ D N A = "123456789" ,

C A M u s e r d a t a = " . . . u s e r d a t a . . . " ,

G A S ~_ p a r a m s = " . . . p a r a m s . . . ";

m a x _ d a t a _ s t r i n g _ l e n g t h = 100,

m a x _ i d e n t i f i e r _ s t r i n g _ l e n g t h = 20,

m a x _ r e m a i n d e r _ s ize = 200;

type

d a t a _ s t r i ng = a r r a y [ l . . m a x _ d a t a _ s t r i n g _ l eng th ] o f cha r ;

i d e n t i f i e r s t r i ng = a r r ay [ 1 . . m a x _ i d e n t i f i e r _ s t r i n g _ l e n g t h ] o f cha r ;

m e s s a g e = r e c o r d

m s g c o d e : i n t e g e r ;

p r o v i d e r _ s e l e c t i o n _ s e s s i o n _ i d : i d e n t i f i e r _ s t r i n g ;


e n d ;

seq_ number : integer; remainder : array[1..max_ remainder _ size] o f char;

(* Channel Definit ions *) channel U s e r _ C h a n n e l ( U S E R , P R O V I D E R ) ; by U S E R :

C A M _ C L E A R _ R E Q U E S T ( . . . ) ; C A M _ C A L L _ A C C E P T ( . . . ) ; C A M _ C L E A R _ C O N F I R M ( . . . ) ;

by P R O V I D E R : G A S _ C A L L _ R E Q U E S T ( . . . ) ; G A S _ C L E A R _ C O N F I R M ( . . . ) ; G A S _ C L E A R _ I N D I C A T I O N ( . . . ) ;

channel C o n t r o l _ C h a n n e l (USER, P R O V I D E R ) ; by U S E R :

C A L L _ C L E A R ( . . . ) ; C A L L _ A C C E P T ( . . . ) ; C A L L _ C L E A R _ C N F ( . . . ) ; S E T _ G A S _ P A R A M S (

msg_ code _ SET _ G A S _ P A R A M S , G A S _ PSS _ id, seq_ num, t ime_ CC_ inactivity_ max, G A S _ params);

S E T _ I R S _ P A R A M S ( m s g _ c o d e _ S E T _ I R S _ P A R A M S , G A S _ PS S _ id, seq_ num, logon_ reply );

I A S _ C L E A R ( msg_ code _ IAS _ C L E A R , GAS _ PS S _ id, seq_ num, clear_ cause, c lear_ diagnostic, r e a s o n _ c o d e );

PSS_ D A T A ( msg_ code _ PSS _ D A T A , G A S _ PSS _ id, seq_ num, P S S _ d a t a );

I R S _ R E Q U E S T ( m s g _ c o d e _ I R S _ R E Q U E S T , G A S _ PSS _ id, seq_ num, D N A ,


facilities, u s e r _ d a t a );

IRS _ L O G O N _ D A T A ( msg_ code _ IRS _ L O G O N _ D A T A , G A S _ P S S _ i d , seq_ hum, logon_ data );

I R S _ D A T A ( m s g _ c o d e _ I R S _ D A T A , G A S _ P S S _ i d , s eq_num, I R S _ d a t a );

I A S _ A C C E P T ( msg_ code _ IAS _ A C C E P T , G A S PSS_id , seq_ num, I A S _ id, C A M _ PSS_id, D N A , u s e r _ d a t a );

I A S _ R E F U S E ( m s g _ c o d e _ I A S _ R E F U S E , G A S _ P S S _ i d , seq_ num, clear_ cause, c lear_ diagnostic, r e a s o n _ c o d e );

P S S _ A C C E P T ( msg_ code _ PSS _ A C C E P T , G A S _ P S S _ i d , seq_ num, D N A , C A M _ user_ data );

PSS_ R E F U S E ( msg_ code _ PSS _ R E F U S E , G A S _ P S S _ i d , seq _ num, clear_ cause, c lear_ diagnostic, r e a s o n _ c o d e );

P R O B E _ R E Q U E S T ( m s g _ c o d e _ P R O B E _ R E Q U E S T , G A S _ PSS _ id, seq_ num, C A M _ id, C A M _ CC_ id );

P R O B E _ R E S P O N S E ( msg_ code _ P R O B E _ R E S P O N S E ,

366 I~ Saleh, H. Ural / Computer Standards & Interfaces 16 (1994) 341-368

G A S _ PSS _ id, s e q _ n u m , C A M _ id, C A M _ C C _ id );

I D E N T I F Y ( m s g _ c o d e _ I D E N T I F Y , G A S _ PSS _ id, s e q _ num, C A M _ id, C A M _ C C _ i d );

I A S _ C L E A R _ C O N F I R M ( m s g _ c o d e _ I A S _ C L E A R _ C O N F I R M , G A S _ PSS _ id, s e q _ n u m ) ;

P O S _ A C K ( m s g _ c o d e _ P O S _ A C K , G A S _ PS S _ id, s e q _ n u m , a c k e d _ s e q _ n u m );

N E G _ A C K ( m s g _ c o d e _ N E G _ A C K , G A S _ PSS _ id, s e q _ n u m , n a c k e d _ s e q _ n u m , r e a s o n _ c o d e );

by P R O V I D E R : C A L L _ R E Q U E S T ( . . . ) ; C A L L _ C L E A R _ C N F ( . . . ) ; I A S _ R E Q U E S T (

m s g _ c o d e _ I A S _ R E Q U E S T , C A M _ P S S _ id, s e q _ n u m , I A S _ i d , G A S _ PSS _ id, D N A , u s e r _ d a t a );

P S S _ R E Q U E S T ( m s g _ c o d e _ P S S _ R E Q U E S T , C A M _ P S S _ id, s e q _ num) ;

I R S _ E N D ( m s g _ c o d e _ I R S _ E N D , C A M _ P S S _ id, s e q _ num, c l e a r _ cause , c l e a r _ d i a g n o s t i c ,

Saleh, H. Ural / Computer Standards & Interfaces 16 (1994) 341-368 367

r e a s o n _ code ,

I R S _ d u r a t i o n ) ; I R S _ A C C E P T (

m s g _ code _ I R S _ A C C E P T , C A M _ PSS _ id,

seq_ n u m ) ; I R S _ R E F U S E (

m s g _ c o d e _ I R S _ R E F U S E , C A M _ PSS _ id, s e q _ n u m ,

r e a s o n _ c o d e ); P R O B E _ R E Q U E S T (

m s g _ c o d e _ P R O B E _ R E Q U E S T ,

C A M _ P S S _ i d , seq n u m ,

G A S _ id, G A S _ C C _ id );

P R O B E _ R E S P O N S E ( m s g _ code _ P R O B E _ R E S P O N S E ,

C A M _ PSS _ id, s eq_ h u m ,

G A S _ id, G A S _ C C _ id );

I A S _ C L E A R ( m s g _ code _ IAS _ C L E A R ,

C A M _ P S S _ i d , s e q _ n u m ,

c l e a r _ cause ,

c l e a r _ d iagnos t ic , r e a s o n c o d e );

I D E N T I F Y ( m s g _ c o d e _ I D E N T I F Y , C A M _ PSS _ id,

s eq_ n u m ,

G A S _ id, G A S _ C C _ id );

I A S _ C L E A R _ C O N F I R M ( m s g _ code _ I A S _ C L E A R _ C O N F I R M , C A M _ P S S _ i d ,

s eq_ n u m ) ; P O S _ A C K (

m s g _ code _ P O S _ A C K , C A M _ PSS _ id, s eq_ n u m , a c k e d _ seq_ n u m );

N E G _ A C K ( m s g _ c o d e _ N E G _ A C K , C A M _ P S S _ i d ,


seq_ num, nacked_ seq_num, reason_code );

References

[1] P. Amer and F. Ceceli, Estelle formal specification of ISO virtual terminal, Comput. Standards Interfaces 9(2) (1987) 87-104. [2] G. Von Bochmann, Usage of protocol development tools: the results of a survey, in: Proc. IFIP Int. Conf. on Protocol

Specification, Testing and Verification VII, Zurich (North-Holland, Amsterdam, 1988). [3] G. Von Bochmann, Specifications of a simplified transport protocol using different formal description techniques, Comput.

Networks ISDN Syst. 18(5) (June 1990) 335-378. [4] S. Budkowski and P. Dembinski, An introduction to Estelle: a specification language for distributed systems, Comput.

Networks ISDN Syst. 14(1) (1987) 3-24. [5] European Computer Manufacturers Association - Computer Supported Telecommunications Applications (CSTA),

ECMA/TC32-Tgl 1/90, 1990. [6] International Organization for Standardization - Programming Language - Pascal, IS 7185. [7] ISO - Information Processing Systems - Open systems Interconnection: Protocol for Providing the connectionless mode

Network Service, Addendum 2: EsteUe Formal Description, Proposed Draft 8473/PDAD2. [8] ISO - Information Processing Systems - Open Systems Interconnection: Estelle - A Formal Description Technique Based on

an Extended State Transition Model, IS 9074. [9] M.T. Liu, Protocol engineering, Advances in Comput. 29 (1989) 79-195.

[10] A. Lombardo, On Estelle specification of PSI protocols, Proc. Computer Networking Symp., Washington DC (Nov. 1986) 110-119.

[11] P. Mondain-Monval, ISO session service and protocol descriptions in Estelle, ESPRIT Project, SEDOS Report 70 (Nov. 1986). [12] B. Pehrson, Protocol verification for PSI, Comput. Networks ISDN Syst. 18 (3) (1989/90) 185-202. [13] H. Ural, Test sequence selection based on static data flow analysis, Comput. Commun. 10 (5) (1987) 234-242. [14] C. Wang and M.T. Liu, Automatic test case generation for Estelle, Proc. 1993 Int. Conf. on Network Protocols (Oct. 1993)

225-233.

Kassem Saleh received the B.Sc., M.Sc. degrees in Computer Science, and the Ph.D. degree in Electrical Engineering from the University of Ottawa, Canada in 1985, 1986 and 1991, respectively. He is currently an assistant professor in the department of electrical and computer engineering at Kuwait University. He was a computer systems specialist at Bell Canada from 1985 to 1991 before he joined Concordia University as an assistant professor for one year. He was awarded the IBM telecommunications Software Scholarship in 1988 and the George Franklin Prize for the best student paper in 1990 from the Canadian Interest Group on Open Systems (CIGOS). He is a member of ACM and Computer Society. His research and teaching interests include software engineering, distributed system design and communications protocol engineering.

Hasan Ural (ACM'81) received his B.Sc. degree in Electrical Engineering from the Middle East Technical University, M.Sc. degree in Computer Science from Hacettepe University, and Ph.D. degree in Electrical Engineering from the University of Ottawa. His research interests include communications software specification and validation, software verification and testing techniques, and distributed computing. He co-chaired the Tenth International Symposium on Protocol Specification, Testing and Verification. He has served on program committees of various international conferences on networks and communications protocols.

formal specification of an information gateway service interface in estelle

Documents