communication protocol that is taken as an example is the Document Transfer And Manipulation

Transcription

1 Chapter 2 Protocol standards and specication techniques for test generation In this chapter we giveanoverview of how communication protocols are specied in protocol standards. Furthermore, we discuss state tables, Mealy machines and nite automata. The goal of this presentation is to describe the starting point for test generation. The communication protocol that is taken as an example is the Document Transfer And Manipulation (DTAM) protocol. This protocol is part of the Document Architecture, Transfer And Manipulation (DATAM) approach, which is developed within ITU (formerly known as CCITT) to facilitate the ISDN telematic services. After a general description of this approach we focus on the DTAM protocol machine that implements the communication aspects for any telematic application that uses DATAM. 2.1 General overview of DATAM Document Architecture, Transfer and Manipulation is the general name for the ITU T.400 series of Recommendations [15, 16]. The Recommendations that are part of the T.400 series form the basis for the architecture, transfer and manipulation of documents in current and future telematic services. Services one can think of in this respect are, e.g., Videotex and Facsimile. The description of the Document Architecture, Transfer and Manipulation standard is divided into three parts. These three parts are shortly described below. The relation of the T.400 series to some other protocols in the OSI Basic Reference Model is depicted in gure 2.1. From this gure, it follows that the DATAM applications may be built on top of the MHS or the Teletex facsimile Application Service Elements. However, the DATAM application can also be built on top of ACSE or may directly access the Session Layer services. T.410 series The Recommendations in the T.410 series dene the Open Document Architecture, i.e., a description of what a document is in the light of the T.400 series of Recommendations. The T.410 series of Recommendations deal with Application Layer user aspects. More information regarding these series can be found in section T.430 series The Recommendations in the T.430 series dene the Document Transfer And Manipulation. These Recommendations describe services and protocols that reside in the Application Layer and are designed to be used for handling and

2 22 Protocol standards and specication techniques for test generation transferring documents. More information regarding these series can be found in section T.440 series The one Recommendation that is in the T.440 series is concerned with the operational structure, i.e., a set of rules describing how applications that use the Application Layer functionality can deal with documents in the light of the T.400 series of Recommendations. Consequently, the T.440 series of Recommendations provide for a link between the concepts of the T.410 and T.430 series and deals with Application Layer user aspects. The T.440 series of Recommendations is not further discussed in this thesis. Application Layer user T.400 series Open document architecture (ODA) interchange format T.411 T.418 Document architecture operations T.441 Teletex T.61 Document transfer & manipulation T.431 T.433 Teletex acces to MHS T.330 Application Layer MHS P1 X.419 MHS P2 X.240 MHS P7 X.419 P3 X.419 ROSE X.229 Teletex and group 4 facsimile control procedures T.62 bis RTSE X.228 ACSE X.227 Presentation Layer Session Layer Presentation protocol X.226 Session protocol X.225 MHS: Message Handeling Systems ROSE: Remote Operations Service Element RTSE: Remote Transfer Service Element ACSE: Association Control Service Element Figure 2.1: The T.400 series and the OSI Basic Reference Model

3 2.1 General overview of DATAM Open Document Architecture The T.410 series of Recommendations specify a document architecture, referred to as Open Document Architecture, and a document interchange format, referred to as Open Document Interchange Format. In the context of the T.400 series, a document can be anything like a memorandum, a letter, an invoice, a form or a report. A document may contain one or more dierent types of content, such as character text, images, graphics and sounds. The basic concept in the Open Document Architecture is to use tree structures to represent documents. In these tree structures, child nodes represent substructures of the parent nodes. Every document has both a logical structure, e.g., subdivision into sections and paragraphs, and a layout structure, e.g., subdivision into pages and text blocks. Furthermore, a document prole is associated with each document. This document prole consists of a set of attributes, e.g., the title, date, used character set, fonts, describing a summary of the document architecture features necessary to process the document. The interchange of documents is provided for either or both of the following purposes: to allow presentation as intended by the originator; to allow processing such as editing and reformatting. To provide for this, two basic document forms have been dened. The rst one is the formatted document form, which is suited to allow the presentation of the document. The second one is the processable document form, which is suited to allow editing and reformatting of the document. Furthermore, an additional third document form, the formatted processable document form, has been dened. This document form is suited to allow formatting, editing and reformatting. The availability and use of the document forms may depend on the specic content types of a document. In order to show the relations between the document forms and document processing functions, a generic document processing model is described in the T.400 series. This model is presented in gure 2.2. The dierent document forms and document processing functions that are depicted in this picture can be exemplied by using the preparation of a document using L A TEX. For such a document, the.tex le represents the document in processable form. The editing process consists of editing this le, for example by using the vi editor. The layout process consists of running the L A TEX formatting programme for the document. This will result in the.dvi le which represents the document in formatted form. The imaging process consists for example of running a dvi to postscript transformation tool and printing the document on a postscript printer. For this example there is no good representative for the formatted and processable document form. The document prole for the document can consist of the.sty le plus the preamble part of the document in which the document title and author can be specied.

4 24 Protocol standards and specication techniques for test generation Processable Document Editing process Layout process Formatted processable document Formatted document Imaging process Document Figure 2.2: Basic document processing model Although the dierent document processing functions have already been exemplied, we will also give a more abstract description of these functions (see also gure 2.2). During the document editing process, a new document can be created or an existing document can be modied. The processable and formatted processable document form provided by the Open Document Architecture can be used to represent an input document for this process. These document forms can furthermore represent control information which inuences the editing process. The Open Document Architecture processable form can also be used to represent the output document of the editing process. The document layout process deals with generating a layout, e.g., a page-oriented organisation, for the document content. The Open Document Architecture processable and formatted processable document form can be used to represent an input document to the layout process. These Open Document Architecture formats can also be used to represent control information which inuences the layout process. The Open Document Architecture formatted and formatted processable document form can be used to represent an output document of the layout process. The formatted form prevents the modication of the output document while the formatted processable form allows for the modication of the output document. Based on the input, the imaging process generates an image of the document in a human perceptible form, e.g., on paper or screen or by means of a loudspeaker. The imaging

5 2.1 General overview of DATAM 25 process is not dened in the T.410 series of Recommendations as this is considered to be a locally dened process that depends on the specic presentation device that is used. The Open Document Architecture formatted or formatted processable document form can be used to represent an input document to the imaging process. These document forms may also be used to represent image processing information that allows the originator of the document to dene the required layout of the document after the imaging process Document Transfer And Manipulation Apart from a document architecture, the T.430 series of Recommendations also dene a Document Transfer And Manipulation (DTAM) service and protocol that reside in the Application Layer of the OSI Basic Reference Model. The DTAM service and protocol together form one of the Application Service Elements (protocol machine), that is dedicated to document handling. The document handling facilities that are oered by the DTAM Application Service Element are document bulk transfer, document manipulation, document access and document management. These document facilities can be used for the realisation of dierent telematic applications like, e.g., Facsimile and Videotex. Document transfer can be done by using either one of two communication modes. The rst mode oers a direct document transfer functionality. This functionality can be used to directly transmit a document generated at one system to an other system. This communication mode is used for, e.g., Facsimile. The second mode oers an indirect communication functionality. This communication functionality is based on the Message Handling System X.400 series of Recommendations, which is comparable with . To oer the DTAM service at its upper interface, the DTAM Application Service Element, or protocol machine as we will call it from now on, implements the DTAM protocol. This protocol is used by the DTAM protocol machines to communicate. A DTAM protocol machine can operate in either one of two modes. These modes depend on the document type that is exchanged but is independent of the communication functionalities, i.e., direct and indirect, that are described above. The two operating modes of the DTAM protocol machine are: Transparent modein transparent mode, the protocol messages are exchanged using the service of the Session Layer directly, i.e., the protocol machine does not use the Presentation Layer functionality. Normal mode In normal mode, the protocol messages are exchanged using the functionality of the Association Control Service Element, i.e., an Application Service Element dedicated to managing communication connections at Application Layer level, and the Presentation Layer functionality. An overview of the Telematic Protocol Architecture representing both modes is depicted in gure 2.3.

6 26 Protocol standards and specication techniques for test generation user element DTAM service DTAM normal mode ACSE DTAM transparent mode Presentation Layer Session Layer Figure 2.3: Telematic Protocol Architecture for DTAM 2.2 DTAM service and protocol specication The DTAM protocol, which is used in ISDN facsimile services, is used as a real life protocol example to describe the starting point, i.e., a protocol standard, for test generation. Furthermore, it is used to explain the need for and ideas behind data test generation methods that are the subject of this thesis. In this respect we focus on the DTAM protocol machine in transparent mode. In this mode, the DTAM protocol machine does not use the Presentation Layer service but directly uses the Session Layer service to manage the communication connection for direct document bulk transfer with a peer DTAM protocol machine. The specication of the DTAM protocol machine in transparent mode in the T.430 series therefore extensively refers to the Session Layer functionality. Moreover, many of the data dependencies that are the subject of our data test generation method occur as relations between the DTAM data units and Session data units. Consequently, we choose the testing interfaces as depicted in gure 2.4. From this gure it follows that we view the DTAM protocol machine as a black boxthat provides the DTAM service at the upper interface, while the lower interface is described in terms of Session Layer Service Data Units. However, as the DTAM Protocol Data Units are carried by the Session Layer Service Data Units, they still play an important role. In the T.430 series of Recommendations, the DTAM service and protocol that are implemented by the DTAM protocol machine, are separately dened, each in its own Recommendation. For standardisation, such a separation is necessary. However, we will use the structural model presented in section 1.5 to describe DTAM in transparent mode.so,our

7 2.2 DTAM service and protocol specication 27 DTAM Service Session Service Figure 2.4: Chosen DTAM testing architecture description of DTAM is done by describing the data unit syntax, the dynamic behaviour and the data dependencies respectively Data unit syntax and layout In our testing architecture, the upper interface of the DTAM protocol machine oers the DTAM service in transparent mode. The Service Data Units that are used in this service can be grouped according to the subservices they implement. There are subservices to initiate, terminate and abort a connection with a peer DTAM protocol machine. Furthermore, there are some subservices to control the actual transfer of a document. The layout of the Service Data Units that are used in these subservices are described by tables that list the parameters. An example of such a description is presented in table 2.1, which presents the layout of the Service Data Units of the D-INITIATE subservice. This subservice is used to initiate a connection with a peer DTAM protocol machine and is realised by four Service Data Units, i.e., request, indication, response and conrm. In order to explain how application processes can use the D-INITIATE subservice to set upadtam connection, we assume the existence of two processes, A and B, that must exchange documents. Furthermore, we assume that process A initiates the connection. To set up a DTAM connection, the following steps are taken (see also gure 2.5): 1. Application process A issues a `request' Service Data Unit to its serving DTAM protocol machine; 2. The DTAM protocol machine will pass this request on to its peer, i.e., the DTAM protocol machine that serves application process B. This is done by exchanging DTAM Protocol Data Units; 3. The peer DTAM protocol machine subsequently issues an `indication' Service Data Unit to process B;

8 28 Protocol standards and specication techniques for test generation 4. Process B responds, possibly after consulting its user, by issuing a `response' Service Data Unit back to its serving DTAM protocol machine; 5. This DTAM protocol machine then issues a DTAM Protocol Data Unit to inform the initiating DTAM protocol machine about the response of process B; 6. The receiving DTAM protocol machine, which serves process A, in turn issues a `conrm' Service Data Unit to process A. application A application B 6. confirm SDU 3. indication SDU 1. request SDU DTAM PM A 4. response SDU 5. response PDU DTAM PM B 2. request PDU Figure 2.5: Stepping through the D-INITIATE service Depending on the \willingness" of process B (or its user) to set up a connection, which is expressed through the \Result" parameter that is part of the D-INITIATE response Service Data Unit, the DTAM protocol machines establish a connection or not. Analogously, process A is informed whether or not the connection request has been honoured or not through the \Result" parameter in the D-INITIATE conrm Service Data Unit. Parameter D-INITIATE D-INITIATE D-INITIATE D-INITIATE request indication response conrm Transparent Mode U { { { Telematic requirements M M C C Application capabilities M M M M Result { { M M Table 2.1: D-INITIATE service parameters in transparent mode From table 2.1, we see that there are four parameters that play a role in the D-INITIATE subservice. These parameters are listed in the rst column. Furthermore, this table species whether or not a specic parameter is present in a specic Service Data Unit and if so, whether this presence is mandatory (M), user optional (U), conditional (C) or absent ({). For example, from this table it follows that the Telematic Requirements

9 2.2 DTAM service and protocol specication 29 parameter must be present in the D-INITIATE request and the D-INITIATE indication data units while its presence in the D-INITIATE response and D-INITIATE conrm data units is conditional, i.e., depends on specic conditions that may or may not be satised. In transparent mode, a DTAM protocol machine directly interfaces with the Session service. The Session service is used to set up and control a Session connection with a peer DTAM protocol machine along which DTAM Protocol Data Units are exchanged. Any communication between a DTAM protocol machine and its servicing Session protocol machine is done through Session Service Data Units. The layout description of these Session Service Data Units can be found in Recommendation X.215 [17], and is not further discussed here. The Session Service Data Units that are exchanged between adtam protocol machine and a serving Session protocol machine, can carry DTAM Protocol Data Units. Usually, these Protocol Data Units (or parts of them) are assigned to the `user data' parameter of the Service Data Units. The Session Service Data Units can thus be regarded as envelopes that are used to send DTAM Protocol Data Units to a peer DTAM protocol machine. The serving Session protocol machine will transparently deliver the DTAM Protocol Data Units to the destination, i.e., it will not in any way alter information that is in the Protocol Data Units. As dierent Session Service Data Units must be used during dierent stages of a Session connection, there is no one to one mapping between DTAM Protocol Data Units and their enveloping Session Service Data Units. So, to describe the dynamic behaviour and the data aspects at the lower interface of the DTAM protocol machine in transparent mode with respect to our testing architecture, both the structure of the Session Service Data Units as well as the structure of DTAM Protocol Data Units should be taken into account. Like the DTAM Service Data Units, the DTAM Protocol Data Units are also linked to the specic subservice in which they are used. There are for example two Protocol Data Units used in the D-INITIATE subservice. These Protocol Data Units are called D-INITIATE-REQ and D-INITIATE-RESP. It will be clear that the rst of these is sent by the initiating DTAM protocol machine to inform its peer protocol machine that a connection is requested (step 2 in gure 2.5). The second one is sent as a response to this request by the peer to the initiating DTAM protocol machine (step 5 in gure 2.5). The layout of the DTAM Protocol Data Units is described by both informal tables as presented above, and ASN.1. As an example, the ASN.1 description of the D-INITIATE- REQ is presented below. [1] D,INITIATE,REQ ::= CHOICE f [4] IMPLICIT ApplicationCapabilities g ApplicationCapabilities ::= SET f documentapplicationprolet73 [0] IMPLICIT OCTET STRING OPTIONAL, documentarchitectureclass [1] IMPLICIT OCTET STRING OPTIONAL g From this ASN.1 example, it follows that the D-INITIATE-REQ protocol data unit consists of one parameter of type `ApplicationCapabilities'. The keywords and the bracketed

10 30 Protocol standards and specication techniques for test generation number 4 are mainly used for coding purposes. The type `ApplicationCapabilities' is dened to be a set of two elements, also referred to as data unit parameters, called documentapplicationprolet73 and documentarchitectureclass. Both these parameters are of type `OCTET STRING' which means that they are a concatenation of bytes Dynamic behaviour In the T.430 series of Recommendations, the specication of the dynamic behaviour of the DTAM protocol machine in transparent mode is done in three dierent ways. First, the behaviour of the protocol machine is described in plain English along with the description of the data units and their related subservices. Second, some message sequence charts are used to describe examples of communication scenarios. Third and last, the behaviour is described by means of state tables. This last description provides for the most extensive and complete description of DTAM, although it is only given for transparent mode. Nevertheless, it is stated that the state tables do not constitute a formal denition of the DTAM protocol machine and are only included to provide for a more precise specication of the subservices. As an example of a state table we present a small part of one of the DTAM protocol machine state tables in table 2.2. This example species the dynamic behaviour of the DTAM protocol machine during the establishment of a connection, i.e., when performing the D-INITIATE subservice. From this state table we can see for example (second row, second column) that if the DTAM protocol machine resides in state STA0, receives a D-INITIATE request Service Data Unit and predicate p1 holds, i.e., the protocol machine can support a connection, then the protocol machine will issue a D-INITIATE request Protocol Data Unit, perform action a1, i.e., set the variable DTAM-PM to true meaning that it is the connection's initiator, and transfer to state STA01. The state table above also shows a commonly used technique in specifying dynamic behaviour in communication protocol standards (third and fourth row) that needs explanation. As will be clear, the establishment of a connection and thus future dynamic behaviour of the protocol machine depends on the willingness of the peer protocol machine to set up a connection. This willingness is expressed through the `Result' parameter that is part of both the response and conrm D-INITIATE Service Data Unit as well as the D-INITIATE response Protocol Data Unit. So, instantiations of the D-INITIATE conrm and response Service Data Units, as well as instantiations of the D-INITIATE response Protocol Data Unit, can be divided into two classes, i.e., a class in which the `Result' parameters is assigned a positive value and all other parameters may be assigned any value from their domain, and a class in which this parameter is assigned a negative value and all other parameters may be assigne any value from their domain. The dynamic behaviour of the DTAM protocol machine, during the D-INITIATE service, changes with the class from which an instantiation stems. So, in the state table description of the dynamic behaviour of a DTAM protocol machine,

11 2.2 DTAM service and protocol specication 31 D-INTreq D-INTres+ D-INTres{ D-INQ STA0 STA01 STA02 p1: DINQ [a1] STA01 DINR+ STA22 DINR{ STA0 p1: D-INTind [a2] STA02 :p1: DINR{ STA0 D-INR+ D-INTcnf+ STA11 D-INR{ D-INTcnf{ STA0 D-INTreq D-INITIATE request Service Data Unit D-INTres D-INITIATE response Service Data Unit D-INTind D-INITIATE indication Service Data Unit D-INTcnf D-INITIATE conrmation Service Data Unit DINQ D-INITIATE request Protocol Data Unit DINR D-INITIATE response Protocol Data Unit p1: \connection can be supported" a1: \initiating connection DTAM-PM = true" a2: \initiating connection DTAM-PM = false" Table 2.2: Part of the DTAM protocol machine state table

12 32 Protocol standards and specication techniques for test generation the classes can be identied. This is established by introducing the postx `+' for the identier, e.g., DINTres+, of the positive class of instantiations and the postx `{' for the identier, e.g., DINTres{, of the negative class of instantiations. Put dierently, the postx is a way to express a requirement on the `Result' parameter without having to describe data unit instantiations in too much detail. An example of the use of postxes can be found in table 2.2. Upon receiving (third row, fourth column) a D-INITIATE response with a positive result when residing in state STA02, the DTAM protocol machine will issue a D-INITIATE response Protocol Data Unit with a positive `Result' parameter and transfer to state STA22. The value of the `Result' parameter in the response Protocol Data Unit will be equal to the value of this parameter in the response Service Data Unit. In our terminology, this is a dependency between these two parameters. This dependency is a simple copy relation. However, communication protocols may use more complex dependencies like, e.g., in negotiation procedures that are sometimes used while setting up a communication session. The state tables are closely related to nite state machines. The nite state machine model that is most commonly used for automatic test generation is the Mealy machine model [34]. Denition 2.1 AMealy machine is a six-tuple (S; I; O; s 0 ;;) where, S : is a nite set, elements of S are called states I : is a nite set, elements of I are called inputs O : is a nite set, elements of O are called outputs s 0 : is an element of S, called the start state : is an element of S I! S, called the state transition function : is an element of S I! O, called the output function The functions and may be partial functions but always have the same domain. The way to interpret the Mealy machine model is as follows. Initially, the system that is modeled by a Mealy machine M =(S; I; O; s 0 ;;), resides in the start state s 0.Furthermore, if the system is in state s 2 S and receives input i 2 I, then it will transfer to state (s; i) while producing output (s; i). An alternative way to represent Mealy machines, and which usually facilitates interpretations, is by using graphs. The states of a Mealy machine are represented by nodes and the state transitions are represented by edges that are associated by input output labels to represent the initiating input and produced output of a transition. For example, a transition from a state s to a state t, initiated by input i and producing output o, i.e.,(s; i) =t and (s; i) =o, is in a graph depicted as presented in gure 2.6. Predicates and actions on variables can not explicitly be specied by the nite state machine model. To do this, an extended nite state machine model should be used. However, if the domains of the variables are nite, it is always possible to transform an extended nite state machine into a nite state machine that exhibits the same dynamic

13 2.2 DTAM service and protocol specication 33 s i/o t Figure 2.6: Graph representation of a Mealy machine behaviour. The basic idea is to dene new states that incorporate a reference to the \old" state and the variable values. It is always possible to meet the requirement on the nite variable value domains, although this is not always practical for test generation due to state space explosion problems. We will show by an example how the dynamic behaviour of the DTAM protocol machine during the D-INITIATE subservice can be specied by a Mealy machine. Example 2.1 The Mealy machine M =(S; I; O; s 0 ;;) that species the D-INITIATE subservice ofadtam protocol machine is specied below. It should be noted that the states in S are chosen such that it is possible to take into account the dierent values that can be assigned to the variables which occur in the state table specication of table 2.2 and that inuence the dynamic behaviour. Furthermore, it is assumed that p1 holds until it is specically set to false. To improve understanding, some elements of S are accompanied by an informal semantical interpretation between quotes, in terms of the states and variable values of the state table specication. S = f STA0 true "STA0 and connection can be supported", STA0 false "STA0 and connection can not be supported", STA01 true "STA01 and initiating DTAM-PM = true", STA01 false "STA01 and initiating DTAM-PM = false", STA02 true "STA02 and initiating DTAM-PM = true", STA02 false "STA02 and initiating DTAM-PM = false", STA11, STA22g I = fd-intreq, D-INTres+, D-INTres{, D-INQ, D-INR+, D-INR{g O = fdinq, DINR+, DINR{, D-INTind, D-INTcnf+, D-INTcnf{g s 0 = STA0 true : (STA0 true, D-INTreq)! STA01 true (STA0 true, D-INQ)! STA02 false (STA0 false, D-INQ)! STA0 false (STA01 true, D-INR+)! STA11 (STA01 false, D-INR+)! STA11 (STA01 true, D-INR{)! STA0 true (STA01 false, D-INR{)! STA0 true (STA02 true, D-INTres+)! STA22 (STA02 false, D-INTres+)! STA22 (STA02 true, D-INTres{)! STA0 true (STA02 false, D-INTres{)! STA0 true

14 34 Protocol standards and specication techniques for test generation : (STA0 true, D-INTreq)! DINQ (STA0 true, D-INQ)! D-INTind (STA0 false, D-INQ)! DINR{ (STA01 true, D-INR+)! D-INTcnf+ (STA01 false, D-INR+)! D-INTcnf+ (STA01 true, D-INR{)! D-INTcnf{ (STA01 false, D-INR{)! D-INTcnf{ (STA02 true, D-INTres+)! DINR+ (STA02 false, D-INTres+)! DINR+ (STA02 true, D-INTres{)! DINR{ (STA02 false, D-INTres{)! DINR{ In section 1.3, the notion of communication sequence was introduced, and described as a sequence of data units that conforms to the specication. In terms of a Mealy machine, a communication sequences is a sequence of labels of consecutive state transitions, i.e., a sequence of labels that represents a path in the graph representing M. As the notion of communication sequence is an important one, we present its formal denition below. However, before we can give this denition we rst have to dene some auxiliary notions. The rst being the projection of a sequence of symbols on an arbitrary set. This notion of projection formalises the idea of deleting elements from a sequence that are not in the set upon which the initial sequence is projected. Denition 2.2 Let U be a set (universe) of symbols. The projection operator, denoted by#, is for any set A dened by 1. # A = 2. for any sequence u 2 U, and symbol s 2 U ( u # A if s 62 A us # A = (u # A)s if s 2 A The second is the transitive closure of the transition function of a Mealy machine. This transitive closure gives the state in which the Mealy machine will reside, when starting from a specic state and processing a sequence of inputs. Denition 2.3 For a Mealy machine M =(S; I; O; s 0 ;;), the transitive closure ofthe transition function, i.e., the function : S I! S, is, for any s 2 S, dened by: 1. (s; ) =s 2. for any u 2 I and i 2 I, ( (s; ui) = ( (s; u);i) undened if both (s; u) and ( (s; u);i) are dened otherwise The third is a denition of an operator that can be conveniently used to describe sequences of alternating elements taken from two sets.

15 2.2 DTAM service and protocol specication 35 Denition 2.4 The concatenation operator for sets, denoted by :, is for any two sets, A and B, dened by 1 : A:B = fab j a 2 A ^ b 2 Bg The notion of communication sequence in the context of Mealy machines can now be formally dened as follows. Denition 2.5 ForaMealy machine M =(S; I; O; s 0 ;;), the notion of communication sequence is completely dened by the following two constructive rules. 1. is a communication sequence; 2. for any communication sequence v, i 2 I and o 2 O, the sequence u = vio is a communication sequence if and only if (a) (s 0 ;u# I) is dened; (b) ( (s 0 ;v # I);i)=o. As follows directly from this denition, a communication sequence always is an elementof (I:O).Furthermore, any prex of a communication sequence that ends with an output, i.e., is an elementof(i:o), is itself a communication sequence. Later on, we willusethe more traditional nite state machine or nite automaton. The reason for this is that the presentation of the specication technique for data aspects becomes easier when using the nite automaton model. Therefore, we introduce the denition of a nite automaton below. After that we will describe how a Mealy machine specication can be transformed into an equivalent nite automaton, where \equivalent" means that a sequence in the Mealy machine context is a communication sequence if and only of it is in the language that is accepted by the nite automaton. The reason to describe this transformation is to show that our methods and approaches that start from the nite automaton model, are closely linked to current day practices in protocol specication and test generation that start from the Mealy machine model. Denition 2.6 A nite automaton is a ve tuple (S, A, I, T, ) where, S : is a nite set, elements of S are called states A : is a nite set of symbols called the alphabet I : is a nite set of initial states T : is a nite set of terminal states : is a subset of SAS, elements of which are called transitions or edges. 1 Note that if a 2 A \ B then a is not an element ofa:b as A:B contains only sequences of length two when counting elements of A [ B.

16 36 Protocol standards and specication techniques for test generation The idea behind the transformation of a Mealy machine M =(S M ;I M ;O M ;s 0 ;;)into a nite state automaton F =(S F ;A F ;I F ;T F ; F )istotake the inputs and outputs of M as the symbols of F and take the start state of M as the only initial state of F. Furthermore, new states and transitions for F are dened according to the principle that transitions are split up in an input and an output part by introducing a new intermediate state. For example, a transition in M from a state s to a state t, initiated by the reception of input i and producing output o, i.e., (s; i) = t and (s; i) = o, results in a state (s;,), intermediate state (s; i) and state (t;,), and transitions ((s;,);i;(s; i)) and ((s; i); o;(t;,)). Consequently, the relation with respect to such a transition between the graphs representing the Mealy machine and the nite automaton is as depicted in gure 2.7. It can be noted that the states (s;,) and(t;,) in F are closely related to the states s and t in M, while the (intermediate) state (s; i) has no counterpart in M. Therefore, only the states in F that, syntactically consist of a state/dash pair, are considered to be terminal states. The formal denition of F is as follows: i/ λ (i) s t Mealy machine (s,-) i (s,i) λ (i) (t,-) Finite automaton Figure 2.7: Graphs of a Mealy machine and related nite automaton S F = f(s;,) j s 2 S M g[f(s; i) j s 2 S M ^ i 2 I M ^9 t2s M [(s; i)=t]g A F = I M [ O M I F = f(s 0 ;,)g T F = f(s;,) j s 2 S M g F = f((s;,);i;(s; i)) j s 2 S M ^ i 2 I M ^9 t2s M [(s; i)=t]g[ f((s; i);(s; i); ((s; i);,)) j s 2 S M ^ i 2 I M ^9 t2s M [(s; i)=t]g The Mealy machine M and its derived nite automaton F specify the same dynamic behaviour, i.e., are equivalent in the sense that a sequence of inputs and outputs is a communication sequence of M if and only if is is in the language accepted by F. In order to make this more precise, we rst present the denition of the language accepted by a nite automaton.

17 2.2 DTAM service and protocol specication 37 Denition 2.7 Asequence c =(e i ) 0i<n of consecutive edges, i.e., of edges e i =(t i ;a i ;t i+1 ), of a nite automaton G =(S G ;A G ;I G ;T G ; G ),iscalled apath with origin t 0,endt n and label a 0 a 1 :::a n,1. We will use path(t 0,c,t n ) to denote that c is a path from t 0 to t n.apathcissuccessful if path(s, c, t) holds and s 2 I G and t 2 T G. A word w 2 A is recognised by nite automaton G if it is the label of some successful path in G. The language recognised byg, denoted byl(g) is the largest subset of A containing only recognised words. Using the denition of the derived nite automaton F and denition 2.7, it can be concluded that L(F ) (I M :O M ).Furthermore, any prexv of a recognised word w 2L(F ) with v 2 (I M :O M ) is also a recognised word. We now present two lemmas that will help to prove that M and F are equivalent. Both lemmas deal with the relation between communication sequences, elements from a language and the respective end states that the machine and the automaton will reside in after having processed the communication sequence or language element. Lemma 2.1 Let M =(S; I; O; s 0 ;;) be amealy machine and F =(S F ;A F ;I F ;T F ; F ) the nite automaton that is derived from M as described above. Let u be a communication sequence of M. Now: path((s 0 ;,);u;( (s 0 ;u# I);,)) proof: Let u be a communication sequence of M. Using induction on the length of u, and noting that u is considered as a sequence of input output pairs, we conclude: 1. if u = then (s 0 ;u # I) = s 0 and path((s 0 ;,);u;(s 0 ;,)). So, the statement holds for the empty sequence. 2. Let u be of length n>0 and assume that the lemma holds for any communication sequence with length smaller than n. Take v 2 (I:O), i 2 I and o 2 O, suchthatu = vio. As follows from denition 2.5 of communication sequence, v is a communication sequence of length n, 1. Using the induction hypothesis we conclude that path((s 0 ;,);v;( (s 0 ;v # I);,)). As furthermore u is a communication sequence, (s 0 ;u # I) = ( (s 0 ;v # I);i)is dened and ( (s 0 ;v # I);i)=o. Using the denition of F,we conclude that (( (s 0 ;v # I);,);i;( (s 0 ;v # I);i)) 2 F and also that (( (s 0 ;v # I);i);o;( (s 0 ;u# I);,)) 2 F Consequently, path((s 0 ;,);u;( (s 0 ;u# I);,)).

18 38 Protocol standards and specication techniques for test generation which proves the lemma. (end of proof) Lemma 2.2 Let M =(S; I; O; s 0 ;;) be amealy machine and F =(S F ;A F ;I F ;T F ; F ) the nite automaton that is derived from M as described above. Let w 2L(F ), and such that path((s 0 ;,);w;(s;,)). Now: s 2 S M (s 0 ;w # I) =s proof: Let w 2L(F ) and take s 2 S such that path((s 0 ;,);w;(s;,)). Using induction on the length of w, we conclude: 1. if w = then s = s 0. By denition, (s 0 ;# I) =s 0 which satises the lemma. 2. Let w be of length n > 0 and assume that the lemma holds for any element of the language recognised by F with length smaller than n. Take v 2 (I:O), i 2 I and o 2 O such that w = vio. As v 2 (I:O) is a prex of w, it is also recognised by F and we canthus take t 2 S such that path((s 0 ;,);v;(t;,)). As the length of v is smaller than n, we can use the induction hypothesis to conclude that (s 0 ;v # I) =t. Using the denition of F and the fact that w is recognised by F,we furthermore conclude that ((t; i);o;(s;,)) 2 F and thus (t; i) = s. Consequently, (s 0 ;w)=s. which proves the lemma. (end of proof) Using these lemma's, we can prove the following theorem, which states that a Mealy machine M and its derived nite automaton are equivalent in the sense that any communication sequence of M is an element of the language of F and vice versa. Theorem 2.1 ForaMealy machine M =(S; I; O; s 0 ;;) and its derived nite automaton F =(S F ;A F ;I F ;T F ; F ) as presented above, the following statement holds: A nite sequence of inputs and outputs is a communication sequence of M if and only if it is a word in the language of F. proof: Let u be a sequence of inputs and outputs. Using induction with respect to the length of u we conclude:

19 2.2 DTAM service and protocol specication if u =, then evidently u is a communication sequence while also u 2L(F ). Hence, the statement is satised by the empty sequence. 2. let u be of length n, for some 0 <n, and assume that the statement holds for all sequences of inputs and outputs with a length smaller than n. Assuming that u is a communication sequence we have to prove that u is an element of L(F ). First we note that because u is a communication sequence, u 2 (I:O). Now take v 2 (I:O), i 2 I and o 2 O such thatu = vio. As v is a prex of u, it also is a communication sequence. So, (s 0 ;v # I) is dened and, according to lemma 2.1, path((s 0 ;,);v;( (s 0 ;v # I);,)). Furthermore, because u = vio is a communication sequence, ( (s 0 ;v # I);i) is dened and ( (s 0 ;v # I);i)=o. Consequently, (( (s 0 ;v # I);,);i;( (s 0 ;v # I);i)) 2 F and (( (s 0 ;v # I);i);o;( (s 0 ;vi # I);,)) 2 F. From this, it follows that path((s 0 ;,);u;( (s 0 ;u# I);,)), and thus u 2L(F ). Assuming that u is an elementofl(f ), wehavetoprove that u is a communication sequence. As u is a word recognised by F, u 2 (I:O).Nowtake v 2 (I:O), i 2 I and o 2 O such that u = vio. As v is a prex of u and v 2 (I:O), it is also an element ofl(f ). By using the induction hypothesis, we conclude that v must also be a communication sequence. As v 2L(F ), there must exist an s 2 S M such that path((s 0 ;,);v;(s; v # I;,)). Using lemma 2.2, we conclude that this state s must be equal to (s 0 ;v # I), and thus path((s 0 ;,);v;( (s 0 ;v # I);,)). Furthermore by using the fact that u = vio is a word recognised by F,we conclude that and also that (( (s 0 ;v # I);,);i;( (s 0 ;v # I);i)) 2 F (( (s 0 ;v # I);i);o;( (s 0 ;u# I);,)) 2 F Consequently, ( (s 0 ;v # I);i) is dened and ( (s 0 ;v # I);i)=o. So, there are v 2 (I:O), i 2 I and o 2 O such that v is a communication sequence, u = vio, (s 0 ;u# I) is dened and ( (s 0 ;v # I);i)=o, which makes u acommunication sequence. which concludes the proof. (end of proof) The nite automaton F that is derived from a Mealy machine is deterministic, i.e., 8 s2s F 8 a2af [jft 2 S F j (s; a; t) 2 F gj1] A nite automaton, describing the behaviour of a protocol machine, that is not derived from a Mealy machine description may be non-deterministic. However, it is always possible ([2]) to transform a non-deterministic nite automaton into a deterministic nite

20 40 Protocol standards and specication techniques for test generation automaton that accepts the same language, i.e., species the same protocol machine behaviour. The problem with such a transformation is that it may blow up the state space into a set that is too large for any practical computation of test sequences. This state space explosion problem is a general problem in automatic test generation. It is not typical for the problem of generating tests for protocol data aspects. Therefore, we leave this problem for what it is and assume from now on that the nite automaton that species the behaviour of a protocol machine, is deterministic. In the state tables describing the DTAM protocol machine in transparent mode,both the DTAM Protocol Data Units and Session Service Data Units occur. Furthermore, a specication for mapping the Protocol Data Units onto the Service Data Units is provided in the T.430 series of Recommendations. It is thus possible to completely specify the dynamic behaviour of the DTAM protocol machine in terms of DTAM and Session Service Data Units. The mapping specication is discussed in the next section Data dependencies The DTAM service and protocol specication incorporates both internal and external data dependencies of whichwe will present examples here. The internal data dependencies, i.e., relations between parameter values that occur in one and the same data unit instantiation, are specied in English. An example of an internal data dependency for a DTAM Protocol Data Unit occurs for the D ABORT REQ Protocol Data Unit, which is used to inform a peer DTAM protocol machine that the connection is to be aborted. [5] D ABORT REQ ::= [APPLICATION 13] IMPLICIT SEQUENCE f abortsource [0] INTEGER f requestingdtampm (0), DTAMserviceProvider (1) g, abortreason [1] INTEGER f local,system,problem (0), invalid,parameter (1), unrecognized,activity (2), temporary,problem (3), protocol,error (4), permanent,error (5), transfer,completed (6) g, reected,parameter [2] IMPLICIT BIT STRING OPTIONAL,,, 8 bits maximum, only present if abortreason is invalid-parameter userinformation [3] OCTET STRING OPTIONAL g The internal data dependency is here incorporated as comment in the ASN.1 description. When issuing a D ABORT REQ, a DTAM protocol machine can inform its peer on the reason for the abortion request through the parameter `abortreason'. One of the possible reasons is that a previously exchanged Protocol Data Unit contained an

21 2.2 DTAM service and protocol specication 41 invalid parameter. If this is the case then the parameter `reected-parameter' can be used to identify this parameter. For all other reasons to request an abort, the parameter `reected-parameter' should not be present in the Protocol Data Unit instantiation. The external data dependencies deal with relations between data unit parameter values of dierent data unit instantiations that may occur during a communication. For the DTAM protocol machine and using our testing architecture, the relations between the contents of DTAM and Session Service Data Units fall into this category. A rst step to describe these relations is by specifying the mapping of the DTAM Service Data Units and Protocol Data Units onto the Session Service Data Units. This mapping is provided in Recommendation T.433. The mapping for the data units that relate to the D-INITIATE subservice is presented in table 2.3. Service Protocol Mapping onto Session Data Unit Data Unit Service Data Unit D-INITIATE req/ind D-INITIATE-REQ S-CONNECT req/ind res/cnf D-INITIATE-RESP S-CONNECT res/cnf Table 2.3: Mapping of DTAM D-INITIATE data units onto Session Service Data Units From this table it follows that for example the D-INITIATE request and indication Service Data Units are related to the D-INITIATE-REQ Protocol Data Unit. This Protocol Data Unit itself is mapped onto the S-CONNECT request Session Service Data Unit (for the sending DTAM protocol machine) and the S-CONNECT indication Session Service Data Unit (for the receiving DTAM protocol machine). This mapping mechanism is depicted in gure 2.8. The description of how to map the DTAM Service Data Units and Protocol Data Units onto the Session Service Data Units provides information on the external data dependencies at a rather high level. To get a complete overview of the relations, a description of the relations between the data unit parameters is needed. Information on the relations between parameters is usually described in plain English. An example of this, taken from the T.430 series of Recommendations regarding the D-INITIATE subservice, is as follows: No parameters of the D-INITIATE Service Data Unit are mapped directly onto the corresponding parameters of the S-CONNECT Session Service Data Units. The S-CONNECT `session requirements' parameter is set by the initiating DTAM protocol machine to select the functional units by means of the `telematic requirements' parameter in the D-INITIATE Service Data Unit as shown in table 2.4. For both the S-CONNECT request and indication Session Service Data Unit,

22 42 Protocol standards and specication techniques for test generation \telematic requirements" Token management Non-token management Capability Reliable transfer management Exception report functional units Half-duplex Duplex Capability data exchange Minor synchronisation Activity management Exceptions Table 2.4: Relation between telematic requirements and functional units the `user data' parameter is used to carry the D-INITIATE-REQ Protocol Data Unit. Apart from these relations, the DTAM protocol specication also describes some constant values for other relevant S-CONNECT Session Service Data Unit parameters that are not related to the `telematic requirements' parameter. A graphical representation of these relations can be found in gure 2.8. Initiating protocol machine Peer protocol machine D_INTreq TR Appl. Cap. TR Appl. Cap. D_INTind DINQ Appl. Cap. Appl. Cap. DINQ Session service provider S_CONreq SR User Data. SR User Data S_CONind D_INTreq: D-INITIATE request primitive D_INTind: D-INITIATE indication primitive DINQ: D-INITIATE request protocol data unit S_CONreq: S-CONNECT request primitive S_CONind: S-CONNECT indication primitive TR: Telematic Requirements Appl. Cap.: Application Capabilities SR: Session Requirements copy relation other relation Figure 2.8: Example of data dependencies An external data dependency of a completely dierent type occurs for the D-TRANSFER

23 2.3 Summary 43 subservice. This subservice provides for the document bulk transfer and is initiated by a D-TRANSFER request Service Data Unit. This Service Data Unit species the document to be transferred by means of a sequence of interchange data elements as depicted in gure 2.9. These interchange data elements describe parts of the document in an abstract form, e.g., document prole, document root. Upon receiving a D-TRANSFER request Service Data Unit, the DTAM protocol machine performs a couple of actions. The DTAM protocol machine divides the document to be transferred into smaller segments, e.g., page, block. To start the document transfer, it issues an S-ACTIVITY-START Session Service Data Unit, which may carry the rst interchange data element, followed by an S-MINOR-SYNCHRONIZE Session Service Data Unit. Next, the protocol machine successively transfers all other document segments by issuing an S-DATA Session Service Data Unit. After each S-DATA Session Service Data Unit, except the one carrying the last segment, the protocol machine issues an S-MINOR-SYNCHRONIZE Session Service Data Unit. After the S-DATA Session Service Data Unit that carries the last segment, an S-ACTIVITY-END Session Service Data Unit is issued. The intermediate S-MINOR- SYNCHRONIZE Session Service Data Units and the S-ACTIVITY-END Session Service Data Unit are used to identify points where the document transfer can be resumed in case the document transfer suers from a corruptive connection. These Service Data Units are successively numbered starting at the value 1, using the synchronisation point serial number eld. Consequently, the synchronisation point serial number eld of the S-ACTIVITY-END Session Service Data Unit species the total number of transmitted segments. This transfer process has been modeled in gure 2.9. From a conformance testing point of view it is interesting to test if all relations between the data unit contents have been implemented correctly. In our rst example of an external data dependency regarding the D-INITIATE subservice, it should be tested if all parameters of the S-CONNECT Session Service Data Units are assigned conforming values. In our second example regarding the D-TRANSFER subservice, several aspects should be tested. First, it should be tested if the user data eld parameters carry the right interchange data element information. Second, it should be tested if the synchronisation point serial number elds of the S-MINOR-SYNCHRONIZE and S-ACTIVITY-END Session Service Data Units are assigned the right values, i.e., the rst has value 1 while all others have a value equal to the previous value plus Summary In this chapter we have presented the Document Architecture and Manipulation Approach. We have given an overview of the DTAM service and protocol that is used in this approach to exchange documents of various types between systems. The overview of the DTAM service and protocol provides for a typical example of a communications standard that is the starting point for conformance testing of communication protocol implementations. Unlike as done in the standards, we have described the DTAM service and protocol