such internal data dependencies can be formally specied. A possible approach to specify

Transcription

1 Chapter 6 Specication and generation of valid data unit instantiations In this chapter, we discuss the problem of generating valid data unit instantiations. As valid data unit instantiations must adhere to internal data dependencies, i.e., data dependencies that occur between values of data unit parameters in one and the same data unit instantiation, the generation of such data unit instantiations can only be done when such internal data dependencies can be formally specied. A possible approach to specify the internal data dependencies is to use an extension to ASN.1 that exploits the theory of attribute grammars. Based on a data unit specication in this extended ASN.1 format, it is possible to generate instantiations that adhere to the internal data dependencies as well as to some possibly existing additional value restrictions for some of the data unit parameters. The generation of such data unit instantiations is based on linear programming techniques. The work presented in this chapter has been published in [40]. 6.1 General overview In our discussions regarding data dependencies and the generation of data tests, valid data unit instantiations play an important role. Up to now, we used functions to have the disposal of (sub)sets of data unit instantiations, i.e., valid inst, du inst. To make the results of the previous chapters practically applicable, it must be possible to specify and compute valid data unit instantiations. The requirements regarding the specication and generation of (sub)sets of valid data unit instantiations that follow from the previous chapters are the following: 1. It must be possible to specify internal data dependencies that occur in real life protocols. A typical example of internal data dependencies is provided for by the D ABORT REQ data unit of the DTAM protocol. The ASN.1 specication of this data unit is recalled below in example It must be possible to compute instantiations that are in the sets that are images of the function du inst and that can be used in test sequences. The data unit instantiations that must be computed must adhere to internal data dependency requirements. Furthermore, extra requirements may have been specied, e.g., (a) As explained in section 3.2, a label in the nite automaton may represent only a proper subset of the set of valid instantiations of a data unit.

2 156 Specication and generation of valid data unit instantiations (b) As described in section 5.4, labels in words of the nite automaton that represent test sequences must be replaced byvalid data unit instantiations. To some of the data unit instantiations that can replace a label, additional restrictions apply, e.g., restrictions that follow from the template tree. These additional restrictions limit the values that may be assigned to some of the data unit parameters in these data unit instantiations. Example 6.1 The ASN.1 description of the D ABORT REQ data unit which is also presented in section 2.2 is presented below. This specication provides for a typical example of a data unit internal data dependency, which is included as informal comment in the ASN.1 description. [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, g,, 8 bits maximum, only present if abortreason is invalid-parameter userinformation [3] OCTET STRING OPTIONAL The need to specify valid data unit instantiations that also adhere to some possible additional value restrictions for some of their data unit parameters, has also been recognised by others. Two approaches have been described in the literature. Both approaches are based on extensions to ASN.1 that exploit the theory of attribute grammars. Furthermore, both approaches are developed to allow test engineers to specify all restrictions for data unit instantiations that are used in tests and to allow the use of tools, e.g., parsers, to automatically check the correctness of exchanged data unit instantiations when evaluating test results. The rst approach, presented in [12], describes a general approach to extend ASN.1 such that it becomes powerful enough to meet the needs of test engineers. The resulting extended version of ASN.1 is called Attributed ASN.1. Furthermore, [12] mentions the successful application of compiler generators for attribute grammars to construct parsers that can mark (given) data unit instantiations as either being valid or invalid. The second approach, presented in [56], is similar but presents a less general solution. The extended version of ASN.1 presented in this paper is called Constraint Specication Notation One and is developed with the application of Yacc in mind. As

3 6.2 Attributed ASN the Attributed ASN.1 approach is more general and seems to be more complete, we adopt the Attributed ASN.1 technique to specify valid data unit instantiations. It is interesting to note that both approaches to extend ASN.1, are inspired by theneed to specify data unit instantiations and the need to check whether a given data unit instantiation is valid or not. So, our need to generate valid instantiations from a specication largely diers from the need as identied in [12] and [56]. Nevertheless, the ideas presented in these papers indicate a direct approach to generate valid instantiations. The outline of this approach is depicted in gure 6.1. ASN.1 specification restrictions data unit instantiation generator valid and invalid data unit instantiations parser valid instantiations used as filter invalid instantiations sink Figure 6.1: An approach to generate valid data unit instantiations The idea is to have a data unit instantiation generator, which generates all instantiations of a data unit from its ASN.1 description. This generator discards all requirements regarding values that may be assigned to data unit parameters. Consequently, it generates both valid and invalid data unit instantiations. The output stream of this generator is fed into a parser which is used as a lter. The parser will only let valid data unit instantiations pass. However, this approach is not very ecient in practice as the simple ASN.1 generator may start with the production of a lot of non-conforming values. So, a more direct approach to generate conforming ASN.1 constraints from Attributed ASN.1 is needed. The structure of the rest of this chapter is as follows. Section 6.2 presents an overview of Attributed ASN.1. Section 6.3 describes how internal data dependency specications in Attributed ASN.1 can be transformed into linear problem specications from which valid data unit instantiations can be computed by applying linear programming techniques. 6.2 Attributed ASN.1 ASN.1 is a description language that is used in protocol standards to dene the data units used by these communication protocols. Furthermore, ASN.1 and its associated

4 158 Specication and generation of valid data unit instantiations value notation is used in conformance testing to specify the data unit instantiations that are used in test cases of a TTCN test suite. Such specications of data unit instantiations are called (ASN.1) constraints. Using ASN.1, it is possible to specify the syntax of data units. Along with such a specication one implicitly denes a set of ASN.1 values or data unit instantiations. According to the data unit specication every ASN.1 value is a proper instantiation of the corresponding data unit. However, protocol specications may limit the set of proper instantiations of data units to a (real) subset of the ASN.1 value set that is specied by the ASN.1 specication of these data units. The reason for this is that usually there exist (internal) dependencies between values that may be assigned to certain elds of a data unit. An example of such internal dependencies is given in example 6.1 in the previous section. In order to enable the automatic generation of ASN.1 values that conform to a protocol standard, it is necessary to formalise the informally specied restrictions. A possible way to do this is by using an extension to ASN.1 that exploits the theory of attribute grammars as proposed in [12]. This extended version of ASN.1 is called Attributed ASN.1. An Attributed ASN.1 specication of a data unit uses ASN.1 for the description of the syntactic structure of that data unit. Additionally, inattributed ASN.1 specications it is possible to associate a set of attributes with any eld (or data unit parameter) of the ASN.1 data unit description. Viewing the ASN.1 data unit description as a structured tree, this means that a set of attributes can be associated with each node in the tree. There are two kinds of attributes, i.e., predened attributes and user dened attributes. The predened attributes are always implicitly dened for any Attributed ASN.1 specication. There are only predened attributes of type INTEGER and of type BOOLEAN. Some examples of predened attributes are: present: which is a boolean valued attribute used to denote the presence or absence of OPTIONAL elds (data unit parameters); length: whichisaninteger valued attribute associated with a eld (data unit parameter) of an ASN.1 STRING type used to denote the length of the string value; value: which holds the value of a eld (data unit parameter) of an ASN.1 Simple Type. The user dened attributes have to be declared and dened explicitly, the only restriction being that their names shall be dierent from the predened attribute names. The declaration of user dened attributes consists of the declaration of the name and the type of the attribute. The denition of the user dened attributes is done by specifying rules. These rules describe how a specic user dened attribute's value is computed using values of other user dened and predened attributes. The rules can thus be seen as a computation scheme, dening attributes in terms of attributes of surrounding nodes in the structured type tree. The general form of a rule is \attribute-name := expression". In this, expression can be any algebraic formula using the normal algebraic unary and

5 6.2 Attributed ASN binary operators like +,, etc. Furthermore, expression can be of the form \IF guard THEN value1 ELSE value2 FI". In this any algebraic formula is allowed for guard, value1 and value2. The relations between attributes are specied by predicates that are called conditions. Any predicate built from attributes and constants is allowed as a coniditon. The values dened by an Attributed ASN.1 specication are those values dened by the underlying ASN.1 specication for which all rules and conditions are satised. Example 6.2 presents the Attributed ASN.1 description of the D ABORTS REQ data unit of the DTAM protocol, including a formalisation of the internal data dependencies. It can be noted that this example only uses predened attributes. Examples of Attributed ASN.1 specications that also use user dened attributes and the accompanying rules are presented in section 6.3. Example 6.2 Using Attributed ASN.1, the DTAM D ABORT REQ can be specied as follows: [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, userinformation [3] OCTET STRING OPTIONAL g CONDITIONS: IF abortreason.value 6= invalid,parameter THEN reected,parameter.present =FALSE ELSE TRUE FI; reected,parameter.length 8; The structured tree of this Attributed ASN.1 type is presented in gure 6.2, where the attributes of the nodes are presented between square brackets. As follows from the example, we refer to attributes by using the string that consists of a path identication of the node associated with the relevant attribute, followed by a dot and the attribute's name. Here, a path identication consists of the dot separated concatenation of the names associated with the nodes of the path in the structured tree of the type.

6 160 Specication and generation of valid data unit instantiations D_ABORT_REQ abortsource [value] abortreason [value] reflected-parameter userinformation [value, present, length] [value, present, length] Figure 6.2: Structured tree of D ABORT REQ 6.3 Generating valid instantiations from Attributed ASN.1 In this section we present our approach to generate valid data unit instantiations from Attributed ASN.1 specications. An important part of this presentation consists of a worked out example. The Attributed ASN.1 specication that serves as the basis of the example is taken from [50]. The example specication is an articial specication, i.e., does not stem from a real life communication protocol specication. In [50], this example was presented to show that Attributed ASN.1 can be used to specify complex relations or internal data dependencies. We use this example as it incorporates all complicated aspects that one may encounter when generating valid data unit instantiations. It can be noted that the Attributed ASN.1 specications for data units of real life communication protocols are usually much simpler. The Attributed ASN.1 specication example comprises the specication of two data unit types, i.e., T1 and T2. Type T2 can be seen as a specication of a sequence of items of type T1, that contains at least one item. The specication of T1 and T2 is presented in gure 6.3. The basic ASN.1 structure for T1 is one boolean and two integers. T1 has two user dened attributes (also called properties). The rst being T1.max which is dened by means of rules and thus is a synthesised attribute. This attribute takes the value of the maximum of the two integers i1 and i2. The attribute T1.extbool is not dened by rules in the specication of T1 and thus is an inherited attribute. Here, it gets its value in type T2. Furthermore, it can be noted that the attribute T1.max is not used in the type T1 itself. However, it is used in the type T2 (referred to by f1.max). The basic ASN.1 structure for T2 is one T1 and one optional T2. T2 has one user dened attribute, i.e., T2.max which, according to the rules of T2, takes the value of f1.max and hence the maximum value of the two integers of f1. This example also shows the use of two kinds of predened attributes. The rst one holds the value of an ASN.1 Simple Type eld, e.g., i1.value, The second one, indicates the absence or presence of an optional eld, e.g., f2.present. To explain our approach to generate valid data unit instantiations, we describe the generation of a valid instantiation M of type T2. From the type denition T2 of M it follows that we have to construct an instantiation of T1, denoted by M.f1 and possibly an other

7 6.3 Generating valid instantiations from Attributed ASN T1 ::= PROPERTIES max : INT, extbool : BOOL SEQUENCEf b BOOLEAN, i1 INTEGER, i2 INTEGERg RULES: max := IF i1.value > i2.value THEN i1.value ELSE i2.value FI; CONDITIONS: IF b.value AND extbool THEN i1.value > i2.value ELSE TRUE FI; T2 ::= PROPERTIES max : INT SEQUENCEf f1 T1, f2 T2 OPTIONALg RULES: max := f1.max; f1.extbool := IF f2.present THEN f1.max > (2 * f2.max) ELSE FALSE FI; CONDITIONS: IF f2.present THEN f1.max > f2.max ELSE TRUE FI; IF f2.present THEN TRUE ELSE T2.max > 0 FI; Figure 6.3: Attributed ASN.1 specication example T2, denoted by M.f2. As will be clear, the problem of the recursive construction of instantiations of type T2 in the construction of M has to be solved rst. To prevent the example from becoming to long, we chose a recursive depth of 1 for M. So, M incorporates an instantiation of type T2, which itself does not contain an instantiation of type T2. Using attributes, this can be expressed more formally by the condition: M.f2.present = TRUE AND M.f2.f2.present = FALSE. Having decided upon the recursive construction problem, we can start the construction of M. It can be noted that the decision regarding the recursive depth can be solved in a tool by using successive depth exploration or can be made interactively with the user. Our method to generate valid data unit instantiations from Attributed ASN.1 specications consists of four steps. These steps, together with a worked out example for the generation of M, are described below. Step 1: flist all relevant restrictionsg To construct a valid data unit instantiation of a specic type T, that is specied bymeans of Attributed ASN.1, we recursively list all rules and conditions of T and its subtypes. This list thus contains all restrictions that shall be satised by the valid instantiations of type T. It can be noted that additional value restrictions for some data unit parameters, e.g., following from a template tree that was used in the computation of test sequence templates, can simply be added to this list. Listing all relevant rules and conditions for M results in the list presented in gure 6.4.

8 162 Specication and generation of valid data unit instantiations This list contains all conditions and rules that follow from the Attributed ASN.1 denitions of type T2. However, it should be noted that we have replaced the attribute names as they occur in the type denition by the names of the attributes as they are for the specic instantiation M. This makes the attributes uniquely identiable which is necessary to derive the proper problem specication. Furthermore, the restrictions that were added to stop the recursive construction of instantiations of type T2 have been added.it should be noted that the rules which originally were assignments, or rather denitions of attributes, are transformed into restricting predicates. ftop level T2: Mg (1) M.max = M.f1.max; (2) M.f1.extbool = IF M.f2.present THEN M.f1.max > (2 * M.f2.max) ELSE FALSE FI; (3) IF M.f2.present THEN M.f1.max > M.f2.max ELSE TRUE FI; (4) IF M.f2.present THENTRUE ELSE M.max > 0 FI; ffirst level T1: M.f1g (5) M.f1.max = IF M.f1.i1.value > M.f1.i2.value THEN M.f1.i1.value ELSE M.f1.i2.value FI; (6) IF M.f1.b.value AND M.f1.extbool THEN M.f1.i1.value > M.f1.i2.value ELSE TRUE FI; ffirst level T2: M.f2g (7) M.f2.max = M.f2.f1.max; (8) M.f2.f1.extbool = IF M.f2.f2.present THEN M.f2.f1.max > (2 * M.f2.f2.max) ELSE FALSE FI; (9) IF M.f2.f2.present THEN M.f2.f1.max > M.f2.f2.max ELSE TRUE FI; (10) IF M.f2.f2.present THENTRUE ELSE M.f2.max > 0FI; fsecond level T1: M.f2.f1g (11) M.f2.f1.max = IF M.f2.f1.i1.value > M.f2.f1.i2.value THEN M.f2.f1.i1.value ELSE M.f2.f1.i2.value FI; (12) IF M.f2.f1.b.value AND M.f2.f1.extbool THEN M.f2.f1.i1.value > M.f2.f1.i2.value ELSE TRUE FI; fadditional restrictionsg (13) M.f2.present =TRUE; (14) M.f2.f2.present =FALSE; Figure 6.4: List of restrictions for data unit instantiation M of type T2 Step 2: ftransform the list of restrictions into linear problem specicationsg Attributed ASN.1 does not put any restrictions on the form that the expressions in the rules and condition may take. One may for example use undecidable predicates as conditions. For generation purposes, we evidently have to limit the expressive power of Attributed ASN.1. Given the fact that we want to use linear programming techniques we (only) require that rules and conditions shall only use linear expressions. From this requirement and the fact that all predened attributes are (representable by) either integers or booleans, it easily follows that the value of any attribute can be represented by

9 6.3 Generating valid instantiations from Attributed ASN an integer, a real or a boolean. So, the list of rules and conditions obtained in step 1 can be transformed into a set of linear problem specication. It should be noted that the requirement to allow only rules and conditions that are linear, seems to be no problem when using Attributed ASN.1 to specify data types for real life communication protocols. original predicate PANDQ P Q osprings PORQ P Q IF guard THEN e1 guard :guard ELSE e2 FI e1 e2 x=ifguard guard :guard THEN e1 ELSE e2 FI x=e x=e2 x=p x=true x=false P :P y 6= z y < z y > z Table 6.1: Predicates and their osprings The transformation is done by recursively eliminating all IF/THEN/ELSE expressions and boolean valued operands The boolean values TRUE and FALSE are simply translated into 1 and 0 respectively. The elimination of boolean valued operands and IF/THEN/ELSE expressions is more complex. The reason for this is that this elimination produces several osprings which should all be taken into account in order to compute a valid data unit instantiation. The osprings of the relevant predicates are presented in table 6.1, in which P and Q represent predicates, x represents a boolean valued attribute and y and z represent integer or real valued attributes. So, the transformation, based on table 6.1, of the following list of predicates, IF X = 0 THEN Y > XELSE Y < XFI; Z>XAND Z<Y; will produce the following two problem specications: X =0; Y > X; Z>X; Z<Y; X 6= 0; Y < X; Z>X; Z<Y; The list presented in gure 6.5, that is constructed in step 1 for M, is transformed into a set of linear problem specications for M by eliminating all boolean valued operators and

10 164 Specication and generation of valid data unit instantiations attributes. One specic linear problem from this set is presented in gure 6.5. Every equation in this gure is preceded by a number indicating its parent equation from gure 6.4. Furthermore, the symbol is used to indicated cases that one of several possible osprings was chosen for our example, i.e., we only work out one specic problem specication from a set of possible problem specications. (1) M.max = M.f1.max; (2*) M.f2.present =1; (2*) M.f1.extbool = 1; (2) M.f1.max > (2 * M.f2.max); (3*) M.f2.present =1; (3) M.f1.max > M.f2.max; (4*) M.f2.present =1; (5*) M.f1.i1.value > M.f1.i2.value; (5) M.f1.max = M.f1.i1.value; (6*) M.f1.b.value = 1; (6*) M.f1.extbool = 1; (6) M.f1.i1.value > M.f1.i2.value; (7) M.f2.max = M.f2.f1.max; (8*) M.f2.f2.present =0; (8) M.f2.f1.extbool = 0; (9*) M.f2.f2.present =0; (10*) M.f2.f2.present =0; (10) M.f2.max > 0; (11*) M.f2.f1.i1.value M.f2.f1.i2.value; (11) M.f2.f1.max = M.f2.f1.i2.value; (12*) M.f2.f1.extbool = 0; (13) M.f2.present =1; (14) M.f2.f2.present =0; Figure 6.5: Linear problem specication for data unit instantiation M Step 3: fsolve the linear problem using linear programming techniques [48]g The result of step 2 consists of a set of linear problem specications which should all be considered to generate a valid data unit instantiation. As all attributes in these linear problem specications are either integers or reals, we can use mixed integer linear programming techniques to compute solutions. These techniques are designed to nd optimum solutions when given a list of linear equations and a function to be optimised. If we are just interested to nd a solution, we can use a constant function as the optimum function. However, it is also possible to specify that for example a valid data unit instantiation with minimum length should be generated. Some of the linear problem specications resulting from step 2 may be infeasible as the transformation may produce problem specications with contradicting equations. In practice, this does not pose any problems as linear programming techniques are capable of detecting infeasible problems. However, it is interesting to note that the Attributed ASN.1 specication denes an empty value type set, i.e., a data unit without any valid instantiations, if and only if all the linear problem specications are infeasible. A solution to the problem presented in gure 6.5 for M denes a conforming instantiation of type T2. Such a solution can be computed by using linear programming techniques, if an optimisation function is specied. If we are for example interested in an instantiation of T2 with a maximum value for M.f1.i1 we can use M.f1.i1.value as the target function. In this case we evidently have to specify an upper limit for the domain of M.f1.i1. Using a

11 6.3 Generating valid instantiations from Attributed ASN constant target function, which will result in the computation of an instantiation of type T2, a linear programming tool may compute the solution of gure 6.6. M.f1.b.value = 1 M.f1.extbool = 1 M.f1.i1.value = 3 M.f1.i2.value = 0 M.f1.max = 3 M.f2.f1.extbool = 0 M.f2.f1.i1.value = 1 M.f2.f1.i2.value = 1 M.f2.f1.max = 1 M.f2.f2.present = 0 M.f2.max = 1 M.f2.present = 1 M.max = 3 Figure 6.6: Linear problem solution of the example Step 4: fconstruct the valid instantiation from the computed solutiong Constructing a valid instantiation means that proper values must be assigned to data unit parameters. Such an instantiation can be described as an ASN.1 value or constraint. Consequently, constructing a valid instantiation from the computed solution means that the values must be assigned to ASN.1 elds of type Simple Type, unless it is a eld in an absent optional subtype. All necessary information to do so is provided by the solution(s) of step 3. It is possible that some predened value attributes are not restricted in a computed solution. For the elds associated with these attributes, we can simply use a random value taken from the relevant domain to construct a constraint. However, it is also possible to use the ASN.1 wild card values, i.e., \" and \?", to describe a set of conforming valid data unit instantiations. This option is important when specifying valid data unit instantiations for test sequences. For valid data unit instantiations that are sent by the tester, random values can be selected. In case the valid data unit instantiation is received by the tester the wild card symbols can be used. Instantiation M can be easily constructed from the computed solution presented in gure 6.6. It should be noted that the solution of gure 6.6 does not restrict M.f2.f1.b.value which thus can be randomly set to, e.g., 0. Doing so results in M =(T1; fftrue; 3; 0g; fffalse; 1; 1ggg) 1 : We have implemented our data unit instantiation generation method in a prototype tool to assess the practical feasibility. An overview of this tool is presented in chapter 7. We found that the performance and capabilities of the tool mainly depend on the following two aspects: the performance and capabilities of the linear programming software. 1 T2 is used here to denote the sort of M

12 166 Specication and generation of valid data unit instantiations the number of linear programming specications that have to be considered to compute a valid data unit instantiation for a specic Attributed ASN.1 type. Regarding these aspects we have the following experiences. The linear programming tool we used, implements a branch and bound technique to solve mixedinteger linear programming problems. It is said to solve integer linear programming problems with about 100 variables in reasonable time, provided that the problem is not too complex. However, the data unit instantiation generation tests that we performed, did not even come close to this limit. The order of the computation time we experienced is tenths of a second rather than seconds or minutes. The number of linear programming problems that have to be considered to compute a valid data unit instantiation grows exponentially with the number of boolean operators and attributes. However, many of these transformed problem specications are infeasible. Most of the time the infeasibility is easily (and quickly) detected, as the problems contain equations of the form x = 0; x = 1 which result from the boolean elimination in the second step of our approach. Our overall experience is that the performance of the data unit instantiation generation tool is acceptable. 6.4 Summary In this chapter we have described a method that can be used to automatically generate data unit instantiations that conform to internal data dependencies plus additional restrictions for values assigned to some data unit parameters. Furthermore, we have given indications on how these data unit instantiations can be specied as ASN.1 values or constraints. The method presented here to generate valid data unit instantiations is applicable to Attributed ASN.1 specications of data units. Attributed ASN.1 is an extended version of ASN.1, that exploits the theory of attribute grammars to formalise internal data dependencies. The method to generate valid data unit instantiations puts restrictions on the form of the Attributed ASN.1 specications. In order to generate valid data unit instantiations, it is required that the expressions that are used to specify the internal dependencies, are linear. We think that for practical protocols this restriction can always be satised. By building a prototype tool that implements our approach, we have shown its practical feasibility.