Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

On TESTGEN+, an environment for protocal test generation and validation Zhou, Jingsong 1992

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_1993_spring_zhou_jingsong.pdf [ 2.66MB ]
Metadata
JSON: 831-1.0051208.json
JSON-LD: 831-1.0051208-ld.json
RDF/XML (Pretty): 831-1.0051208-rdf.xml
RDF/JSON: 831-1.0051208-rdf.json
Turtle: 831-1.0051208-turtle.txt
N-Triples: 831-1.0051208-rdf-ntriples.txt
Original Record: 831-1.0051208-source.json
Full Text
831-1.0051208-fulltext.txt
Citation
831-1.0051208.ris

Full Text

On TESTGEN+, An Environment for ProtocolTest Generation and ValidationbyZhou JingsongB.Sc., Changsha Institute of Technology, China, 1987A Thesis Submitted in Partial Fulfillment ofthe Requirements for the Degree ofMaster of ScienceinThe Faculty of Graduate StudiesDepartment of Computer ScienceWe accept this thesis as conformingto the required standardUniversity of British ColumbiaDecember 1992© Zhou jingsong, 1992In presenting this thesis in partial fulfilment of the requirements for an advanceddegree at the University of British Columbia, I agree that the Library shall make itfreely available for reference and study. I further agree that permission for extensivecopying of this thesis for scholarly purposes may be granted by the head of mydepartment or by his or her representatives. It is understood that copying orpublication of this thesis for financial gain shall not be allowed without my writtenpermission.(Signature)Department of kc The University of British ColumbiaVancouver, CanadaDate ^/0 77/1DE-6 (2/88)AbstractThis thesis addresses a significant tool ,TESTGEN+, for protocol test generation and valida-tion. TESTGEN+ consists of two basic components:TESTGEN for protocol test generation,and TESTVAL for test validation.TESTGEN, is a protocol TEST Generation and Selection Environment for conformance testingwhich has been developed at the University of British Columbia. This environment is menudriven and unique in that it is effective, general, flexible and portable. It is based on an inter-mediate extended transition system formalism and directly supports ASN.1 and Estelle. Thetest generation method adopted in the environment integrates both the control flow testing andthe data flow testing with parameter variation. Furthermore, test generation and selection areintegrated and guided by user-defined test suite generation constraints and parameter variationconstraints. The environment will serve as a useful testbed for experimenting with test gen-eration and selection as well as being a productive system for generating useful test suites forreal-life protocols.TESTVAL is a test suite validator, which is based on a trace analyzer, and which allows testcases to be validated against their protocol specification. Using TESTVAL, the validation ofthe test suite for the LAPB protocol defined in the ISO 9646 standard document has beenperformed and the validation result is presented in the thesis.ContentsAbstract^ iiTable of Contents^ iiiList of Figures VAcknowledgement^ vi1 Introduction 11.1 Motivation and Objectives ^ 11.2 Thesis Contributions 21.3 Thesis Outline ^ 22 Strategy 42.1 Extended Transition System^ 42.2 Definition ^ 62.3 Backtracking Algorithm 62.4 Comparison 73 Design and Architecture 83.1 User Input Part ^ 93.2 Parser Part 203.2.1^ASN.1 Parser 203.2.2^Protocol Parser ^ 203.3 Backtracking Testing Part 213.3.1^Dynamic Data Structure^ 213.3.2^Backtracking  Testing 223.4 Subtour Identification ^ 223.5 Abstract TTCN Test Suite 233.5.1^Modified TTCN Dynamic Part ^ 253.5.2^TTCN constraint table part 251114 Implementation^ 274.1 The Environment  274.2 Backtracking Testing Kernel^  284.2.1 Static Data Structure Checking Module ^  284.2.2 Dynamic Data Structure Module  304.2.3 Check Constraint Module ^  314.2.4 Expression and Effect Function Module ^  314.2.5 Initiate Module ^  324.2.6 Backtracking Module  324.2.7 Subpath Identification Module ^  344.2.8 TTCN Dynamic Module  404.2.9 TTCN Constraint Module  435 Test Case Validator and LAPB Validation^ 475.1 Trace Analysis and Validator ^  485.1.1 Trace Analysis  485.1.2 Validator ^  515.2 LAPB ^  525.2.1 Introduction  525.2.2 LAPB Estelle Specification ^  535.2.3 LAPB Specification  555.3 LAPB Validation and Result Analysis  565.4 Conclusion ^  616 Conclusion and Future work^ 626.1 Summary ^  626.2 Future work  63A LAPB Estelle Specification^ 64B PART OF LAPB SUBTOUR IDENTIFICATION OUTPUT^78C LAPB test cases and validation results for DL1^ 88D LAPB test cases and validation results for DL2 93Reference^ 99ivList of Figures3.1 Model of Test Case Generation Design ^  83.2 Model of Protocol Data Structure.  195.1 Components of TESTGEN+ ^  47VAcknowledgementI would like to acknowledge the tremendous amount of help, support and guidance given tome by my supervisor, Dr. Son Vuong, throughout the course of my thesis work and studies atUB C.Also, I would like to thank Dr. Samuel T. Chanson for serving as the second reader of thisthesis, and also for his invaluable comment and help on this thesis.Finally, I would like to extend my thanks to the department of Computer Science, and manygraduate students in this department, for the financial support as well as the great help andencouragement during my studies at UBC.viChapter 1Introduction1.1 Motivation and ObjectivesConformance testing of communication protocols is commonly used to ensure that the imple-mented protocol meets the design specifications and operates correctly in the communicationnetwork. The usual approach in conformance testing is based on the Finite State Machine(FSM) model, which is thus inherently limited to the testing of the control flow part of theprotocol.In the past, several methods have been put forward to handle the data flow of the protocol[Ura— 88], [Sra— 87], [Wu —89]. However these methods do not consider the dependencies be-tween transitions and they may therefore miss hidden interactions among the service primitivesexchanged in different parts of the protocol.The Test Suite Generation (TSG) method used in TESTGEN integrate both the control flowand the data flow testing with parameter variation and can produce test cases to cover anypath defined by the service primitives that an JUT is allowed to exchange with its environment.It also integrates the generation and selection of test suites by providing an environment where1CHAPTER 1. INTRODUCTION^ 2various TSG — constraints and constraints on the service primitive parameter can be definedby the user to control the limit and depth of the testing tree, it thus provide a great extent offlexibility.With a growing number of standardized test suites generated, it is very important to ascertainthe validity of the test suites with respect to the protocol specification. Since, TESTGEN isnot suitable for test case validation , a new validator based on a trace analyzer, is developed.This test case validator is incorporated into TESTGEN to produce an enhanced version calledTESTGEN+ which can handle both test case generation and validation.1.2 Thesis ContributionsThe main contributions of my thesis include the following:. Contributions in the design of TESTGEN.. Implementation of the test generation kernel part of a version of TESTGEN, including thesubpath identification and the test suite specification in TTCN.. Modifications of a trace analyzer to produce a test case validator, and validation of theLAPB test suite as defined in the ISO 9646 standard document.1.3 Thesis OutlineIn this thesis, I first discuss about the strategy in building the test generation kernel part ofTESTGEN, and then the design and the implementation of that test kernel. Finally, I presentCHAPTER 1. INTRODUCTION^ 3the modification of a trace analyzer to produce a test case validator and the results of validatinga standardized LAPB test suite using this validator.Chapter 2Strategy2.1 Extended Transition SystemIn this chapter, I mainly introduce the definition of an extendented transition system , and thealgorithm for building the test kernel.The old FSM formalism describes a protocol in terms of states and transitions. An input/outputpair (i/o) is associated with each transition. This specification is suited to describe the be-haviour of very simple systems. However in the real world, we need a formalism which candescribe the real world protocols, and thus cause the appearance of the ETS.The Extended Transition System (ETS) model is a quadruple ET S = (Q, E,T, Qint) where. Q is the set of states of the ETS,. E is the set of events of the ETS,. T is the set of transitions of ETS,• Qint is the initial state of ETS.4CHAPTER 2. STRATEGY^ 5The set of states Q denotes the set product:Q = STATES *VAR * C *TIMERQintt represents the initial control state Sinit, the initial values of all variables and timers.The set of event E denotes the set product:E = ISP * OSP * PDUISP is the set of Input Service Primitives, OSP is the set of Output Service Primitives, PDU isthe set of Protocol Data Units.A transition in T is a relation on Q * E *Q represented by a set productT = EPRED * AFNwhere an enabling predicate epred ( a subset of EPRED ) is a boolean function:epred :Q * E— > true, false(a transition can be executed only if its associated enabling predicate is true) and an actionfunction afn (a subset of AFN) is a function:afn :Q * E— > Q * Ewhich affects variables in VAR, timer in TIMER and parameters of OSPs and PDUs.A transition can be executed if and only if the ISP and PDU associated with the transition (ifany) are received and if the enabling predicate is true. When a transition fires, the associatedaction function is executed automatically. Variables and timers are set, OSP(s) and PDU(s)are assembled (their parameters are set), OSP(s) and PDU(s) are sent.CHAPTER 2. STRATEGY^ 62.2 DefinitionInteraction path(testing subpath):An interaction path IP is a ETS observable path on which a sequence of interactionsbetween the protocol and its external environment occurs, starting from the Q init andending in the same state.I/O path:An I/O path is the ETS observable track Pi, P2... .Pk in an IP, wherePi has the isp li with parameters Siii, ...Simi,Pi has the osp Oi with parameter Soli, ...Somi,Pi has the pdu Iii with parameter Suii,...Sunii.2.3 Backtracking AlgorithmOnce a protocol ETS data structure has been generated, we can use the following algorithm toidentify all its interaction pathes.Loop (if there is one or more transitions have been fired in set of Q)Stepl: find an unmarked transition with the lowest transition number in the current state.Step2: check whether the current transition can been applied or not. if the answer is TRUE,fire and mark this transition.Step3: if there is no unmarked transition in this state, back one step, and go to step 1.CHAPTER 2. STRATEGY^ 7step4: the new state Q is the receive state of the current transition.Q init •step5: if the newst ate = Qinit, store one interaction path, and currentstate =2.4 ComparisonComparing with other strategies, our strategy has the following advantages:Practicality:Unlike some other strategies which can only test simple toy protocols, our test strategycan test real protocols, and thus provides a practical tool.flexibility:Due to the flexibility of the TSG constraint part, we can get different test cases dependingon the user's different requests.generality:Unlike some other strategies, which limit their applications only to some certain specificprotocols, our TSG tool can test different protocol specifications. So it is a generalizedconformance test tool.Chapter 3Design and ArchitectureFigure 3.1: Model of Test Case Generation DesignCHAPTER 3. DESIGN AND ARCHITECTURE^ 9In this chapter, we will discuss in detail the design and architecture of each part of the TEST-GEN.From Figure 3.1, we can see the whole test process be mainly divided into three parts, parserpart, user input part and the backtracking test part.The user input is made of three parts: ASN.1 specification, Estelle.Y specification, and con-straint part.The parser part contains two parts, ASN.1 parser and protocol parser. The ASN.1 parser getsthe ASN.1 specification from the user, produce ASN.1 input to the parser.The protocol parser takes Estelle.Y specification provided by user, and the output provided bythe ASN.1 parser, to produce the static data structure of the whole protocol. It becomes theinput to the backtracking testing part.The backtracking test part takes the protocol static data structure as the input to producethe subtour identification as the output. Furthermore, it will produce the Modified TTCNGeneration (tree and verdict) and TTCN Constraint Tables.3.1 User Input PartThe user should provide three kinds of inputs, the Estelle.Y Protocol specification, the ASN.1Protocol specification, and the Constraint part.The ASN.1 Protocol specification specifies the protocol data structure using the ASN.1 defini-tion. Here is a simple example, which builds a subset of the X25 ASN.1 specification.X25 DEFINITIONS : :=CHAPTER 3. DESIGN AND ARCHITECTURE^ 10BEGINNetworkAsp ::= CHOICENConnectRequest,NconnectIndicationNConnectRequest ::= SEQUENCEcalledAddress OCTET STRING,callingAddress OCTET STRING (SIZE(0-109)),receiptConfirmationSelectionENUMERATED { nouse(0), use(1) 1,quality0fService SEQUENCEthroughput SEQUENCEtoTargetValue INTEGER,toLeastValue INTEGER1,CHAPTER 3. DESIGN AND ARCHITECTURE^ 11transitDelay SEQUENCE{targetValue INTEGER,leastValue INTEGER11NConnectIndication ::= SEQUENCE{calledAddress INTEGER,callingAddress OCTET STRING1x25Pdu ::= CHOICE{CallRequest,CallAcceptedCallRequest^::=^SEQUENCECHAPTER 3. DESIGN AND ARCHITECTURE^ 12{generalFormatId^NameBitString4,logicalChannelId^BitInteger12CallRequest ::=^SEQUENCE{generalFormatId^NamedBitString4,logicalChannelId BitInteger12,facilityLength^BitInteger41NameBitString4 ::= BIT STRING (SIZE(4,4))BitInteger12^::= INTEGER (SIZE(12..12))BitInteger4^::= INTEGER (SIZE(4..4))ENDThe definition of the Estelle.Y protocol specification was made by ourselves by modifying theNormal Form Estelle specification.CHAPTER 3. DESIGN AND ARCHITECTURE^ 13Here is a simple example of the Estelle.Y specification.Specification FDDIMAC;ConstCOUNT = -100 : int;tkrecvd = true : boolean;frrecvd = false : boolean;MAXSIZEaaabb = 1000 : int;STR = "stri-.*ngggg" : CHAR_STR;Varabcddddd, ccc, n1, n2: inta2: char_str;ISPNconnectRequest NASP;NconnectIndication NASP;PHY_DATA_ind PSAP;nisp nsap;CHAPTER 3. DESIGN AND ARCHITECTURE^ 14T_DATA_req tsap;OSPDL_data_req dsap;DL_data_ind dsap;T_DATA_ind tsap;PDUTPDU sent_in DL_data_ind,recv_in PHY_DATA_ind;NPDU sent_in T_DATA_ind, recv_in T_DATA_req;SPDU recv_in T_DATA_req;CallRequest recv_in NConnectRequest;TimerTVX 250;THT 380;StateCHAPTER 3. DESIGN AND ARCHITECTURE^ 15SO,S1,S2,S3,s4,s5;Transfrom S3to Siwhen NConnectrequestprovided (( NconnectRequest.calledAddress + 1055 * n2 / ccc) = 100 )priority 10OUTPUT TPDU, CallRequestprettybeginreset(TVX);NConnectRequest.calledAddress := NConnectRequest.quality0fServiceNconnectRequest.callingAddress := (10 + CallRequest.logicalChanne:STOP(THT);end;to S2beginif (m1) thenCHAPTER 3. DESIGN AND ARCHITECTURE^ 16if (m3 and m4) thenbeginn2 := NConnectRequest.calledAddress;reset(TVX)endelse if (m4 or ml) thenbeginn2 := n1;ccc := 0;n1 := 1end;START(TVX);end;TO SOWHEN SPDUPROVIDED (m2 = m3)uglyBEGINIF (m3 = true) THEN n1 := n2*10;END;CHAPTER 3. DESIGN AND ARCHITECTURE^ 17from S2to SOPROVIDED (ml or (not m2) and m3 and STOPPED(TVX))priority 20BEGINstart(THT);END;TRANSFROM s4to s5WHEN TPDUprovided m4Beginm3 := true;End;end.The constraint part can either be set by default or be interactively specified by the user toCHAPTER 3. DESIGN AND ARCHITECTURE^ 18guide the selective identification process.The user can specify the minimum and maximum uses of each state, transition, constant, inputservice primitive, output service primitive, protocol data unit and timer for the whole protocoltesting and subpath generation. This controls the depth of the testing tree by the user himself.Also, the user can specify the constraint for the primitives; it gives a certain field of the datawhich can be used for this service primitive during the testing. Meanwhile, the user can set thedefault, and the system can automatically give the entire constraints for the testing.CHAPTER 3. DESIGN AND ARCHITECTURE^ 19Figure 3.2: Model of Protocol Data Structure.CHAPTER 3. DESIGN AND ARCHITECTURE^ 203.2 Parser Part3.2.1 ASN.1 ParserAbstract Syntax Notation One (ASN.1) is a widespread, standardized notation that providesits user with an easy to read, yet powerful definition language for describing communicationprotocol data structures in terms of types and values of these types. Here, we mainly use thisdefinition to specify the data type of these data structure, and we also limit several basic datatype to be used in the specification of service primitive.3.2.2 Protocol ParserProtocol parser takes the Estelle.Y specification, the ASN.1 parser output to produce the staticdata structure of the protocol.As we can see from figure 3.2, The PDS is a complex structure which has the entire pointersfor each of the protocol static data structures, and these data structures contain the wholeinformation which each test part needs.Inside the input service primitive, output service primitive and protocol data unit, there is apointer to the ASN.1 data structure which contains the detailed service primitive information.When we do the protocol testing, we get a pointer pointing to the PDS after we call the parserfunction, then we get the whole information that we need in the backtracking testing.CHAPTER 3. DESIGN AND ARCHITECTURE^ 213.3 Backtracking Testing Part3.3.1 Dynamic Data StructureIn order to get the data value from every data structure which we defined in the static data part,to produce the subtour identification and TTCN test generation, we should define a dynamicdata structure.Each test case consists of some tested states and transitions; inside the state, we should writedown the actual value of every variable, timer, and service primitive.Inside the dynamic data structure, we define a backtracking timer structure; it records the state( stopped or running ) and value of the timer in each test state.Inside the dynamic data structure, we define a backtracking variable structure, it records theactual value for each variable in every testing state.Also, we define the backtracking service primitive structure in the dynamic data structure, andwe use it to record the actual value for each service primitive in every testing state.Then, we can define the backtracking state structure; it contains the transition number whichstarts from here, and the three data structures we described above. Therefore, the backtrack-ing state structure can get the actual values of timer, variable, and service primitive in eachbacktracking state.In order to check the constraint part which the user specified, we should define a data structureto record the times for each state, transition, isp, osp, constant, pdu and other data structureswhich we have tested.For each subpath, we need to get the information about how many backtracking states it has,CHAPTER 3. DESIGN AND ARCHITECTURE^ 22and the entire information about that state. So, we define a backtracking subpath structure;it will write down the entire information we described above. In order to store the subpathswe get from the backtracking test, we define a subpath head data structure, which storing thetotal subpaths and we can reach any of the subpath through this data structure.3.3.2 Backtracking TestingThe backtracking testing program will take the output from the ASN.1 parser and the inputfrom the user, create and store the dynamic backtracking state data structure as the testinggoes on. When a subpath has been reached, the program will also store this subpath and linkit to the previous one. After we finish the backtracking testing, we will create a subpath headdata structure and make a pointer to the beginning of the subpath and a pointer to the end ofthe subpath; also, it will record the total numbers of subpaths.3.4 Subtour IdentificationSubtour identification is a list of the subpaths, which are generated from the backtrackingtesting program. Inside the subpath, we can see the total states being tested in this subtour.Also during a certain state, there is information about which input service primitive and inputprotocol data unit we get, which output service primitive and output protocol data unit wesend.In addition, we provide detailed information about each backtracking state for all subtours wegenerate.For each state, we provide how many transitions which can be applied from there, the type andCHAPTER 3. DESIGN AND ARCHITECTURE^ 23the actual value for each variable in this backtracking state.Also, we provide the frequency for using each variable, timer, constant in that time and thefrequency in assigning variable, starting timer, stopping timer and resetting timer.For each transition, we provide the name of the associated input service primitive, input protocoldata unit, output service primitive, output protocol data unit, and the values of the serviceprimitives for the above three data structures.With these information, the user will fully understand the testing results.3.5 Abstract TTCN Test SuiteIn constructing a generic or abstract test suite, a test notation is used to describe abstract testcases. The test notation can be an informal notation or a formal description technique(FDT).TTCN is an informal notation with clearly defined, but not formally defined, semantics.In the abstract testing methodology, a test suite is looked upon as a hierarchy ranging from thecomplete test suite, through test groups, test cases and test steps, down to test events. TTCNprovides a naming structure to reflect the position of test cases in this hierarchy. It also providesthe means of structuring test cases as a hierarchy of test steps culminating in test events.In TTCN, the basic test events are sending and receiving Abstract Service Primitive(ASPs),Protocol Data Units(PDUs) and timer events.Two form of the notation are provided: a human readable tabular form, called TTCN.GR, foruse in OSI conformance test suite standards; and a machine-processable form, called TTCN.MP ,for use in representing TTCN in a canonical form within computer systems and as the syntaxCHAPTER 3. DESIGN AND ARCHITECTURE^ 24to be used when transferring TTCN test cases between different computer systems. The twoform are semantically equivalent.Normally, an abstract test suite written in TTCN shall have the following four sections in thefollowing order:a) Suite Overview:which is the information needed for the general presentation and understanding of thetest suite, such as test references and a description of its overall purpose:b) Declaration Part:which is the set of components that comprise the test suite is described. This sectionshall contain the definition of any abbreviations to be used later in the test suite:c) Constraint Part:which is when the set set of values for the ASPs, PDUs, and their parameters used in theDynamic Part. the constraint shall be specified using:1. TTCN tables: or2. the ASN.1 Modular Method; or3. both TTCN tables and the ASN.1 Modular Method.d) Dynamic Part:which comprises three sections that contain tables specifying test behaviour expressedmainly in terms of the occurrence of ASPs at PC0s.CHAPTER 3. DESIGN AND ARCHITECTURE^ 25After getting the subtour identification and the subtour data structure, we can use them toconstruct the Abstract TTCN test suite.Our abstract TTCN test suite will contain two parts, the modified TTCN dynamic part andthe TTCN constraint table part.3.5.1 Modified TTCN Dynamic PartIn this modified TTCN dynamic part, we build the behaviour description to describe the be-haviour of the lower tester and/or upper tester in terms of test events using the tree notation.We also place the verdict or result information in the verdicts column which is associated withTTCN statements in a behaviour tree.In the TTCN notation, each TTCN statement shall be shown on a separate statement line.Sequences of TTCN statements are represented one statement line after the other, each newTTCN statement being indented once from left to right.Test TTCN statements at the same level of identification and belonging to the same predeces-sor node represent the possible alternative TTCN statements which may occur at that time.Alternative TTCN statements shall be given in the order in which the tester shall repeatedlyattempt them until one occurs. Each behaviour description shall contain at least one behaviourtree.3.5.2 TTCN constraint table partIt is necessary to specify in detail the values of ASP parameter and PD1J fields. The encodingsshall be described using either the Tabular Method or the ASN.1 Modular Method. Here weCHAPTER 3. DESIGN AND ARCHITECTURE^ 26use the first one.In the TTCN tabular form, a constraint is defined by specifying a value and optional lengthfor each PDU field. Each field entry in the field name column shall have been declared in therelevant ASP or PDU type declaration. When defining constraints on an ASP or PDU, valuesassigned to each field shall be of the type specified in the ASP or PDU declaration.Chapter 4ImplementationIn this chapter, we discuss the implementation of the backtracking test kernel part and itsenvironment.The backtracking test generation part is implemented in the C and UNIX Sun 4 workstationenvironment.4.1 The EnvironmentThere are some advantages to achieving the implementation of the backtracking test kernelpart.First, The available ASN.1 parser and the protocol parser make it possible to get the entire staticdata structure (including the ASN.1 part), which has all the information for the backtrackingtesting part.Also, the UNIX environment provides a better programming debugging, a huge C-programlibrary, and almost all needed primitive functions. It is quite convenient to develop an entireprogram in this environment.27CHAPTER 4. IMPLEMENTATION^ 284.2 Backtracking Testing KernelThe backtracking testing kernel part consists of nine modules; they are static data structurechecking module, dynamic data structure module, check constraint module, expression andeffect function module, initial module, backing module, subpath identification module, TTCNdynamic module, and TTCN constraint module.4.2.1 Static Data Structure Checking ModuleIn order to make sure that each field of the static data structure completely correct, we need tomake a check function to check them first before we use this information for our backtrackingtesting.The checking function takes care of the following static data structure parts.general information PDS part:This part is the index part which points to the entire static data structure we build forthe testing; also, it has the total numbers of states, transitions, variables and other partsof static data structures. We check whether the total numbers of states, transitions andthe numbers of other data structure are among the maximum numbers we define for thesedata structures.state part:In the state part of the static data structure, we should check whether the key numberof the state is among the state numbers which we define in the static data structure; theCHAPTER 4. IMPLEMENTATION^ 29nb_o f_tr field is less than the total numbers of transitions we define in the static datastructure, and the tr_key[i] field is among the nb_o f_tr field we define for this state.transition past:In the transition part of the static data structure, we should check whether the key numberof the state is among the transition numbers which we define in the static data structure;the from_st and to_st fileds are among the state numbers which we define in the staticdata structure, and the other fields are also among the information which we define inthe static data structures.constant part and variable part:In the constant part and variable part of the static data structure, we should checkwhether the key number of both data structures are among the numbers we define for theconstants and the variables; also we should check the type of both data structures amongthe three data types we defined before.input, output service primitive part:In the input and output service primitive part of the static data structure, we shouldcheck whether the key number of both data structures are among the numbers we definefor them; also we should check the nb_of_pdus fields is less than the total number ofpdus we define in this static data structure.expression part:CHAPTER 4. IMPLEMENTATION^ 30In the expression part of the static data structure, we should check whether the key fieldis among the total expression numbers of the PPDS part, the le ft_kind field belongs tothe KIND type we defined before, and the operator field belongs to the OPERATOR typewe defined before.effect function part:In the effect function part of the static data structure, we should check whether the keynumber is among the total PDS effect function numbers, and the stmt_ kind field belongsto the SKIND type which we defined before.4.2.2 Dynamic Data Structure ModuleAs the backtracking goes on, this part creates and copies the dynamic data structure in orderto record the whole protocol testing results. This module includes the following functions.creat backtracking node submodule:The creating backtracking node part has new_bvar(), new_btimer(), new_bspam(),new_btrans(), new_bstate(), new_belt() functions; these functions create a new back-tracking node.copy backtracking node submodule:The copy backtracking node part has copy _bvar(), copy _btimer(), copy _bspam(), copy_btrans(),copy_bstate(), copy_belt() functions; those functions copy the current backtracking test-ing node to the current subpath and move to the next testing node after that.CHAPTER 4. IMPLEMENTATION^ 31subpath store and index creat submodule:This submodule includes the functions to link the testing nodes, store the available sub-pathes, link the current subpath to the previous one, and finally create the index for thewhole dynamic subpaths.4.2.3 Check Constraint ModuleWhen the user specifies the constraints for each part of the testing protocol, it limits the depthof the testing tree. Those constraints come to the static data structure part as the testing goeson. The check constraint module checks the constraints which the user specifies, to make surethat they do not pass the constraint limits.The check constraint module function set includes the following functions: check_state(),check_tran(), check _const(), check _isp(), check_osp(), check_pdu(), check _var(), check _assvar(),check_tstart(), check_tstop(), check_treset(), check_ crest(), check_cstart(), check _cstop(),check_ctimer(). They do the constraint checking for each part of the testing protocol.4.2.4 Expression and Effect Function ModuleUsually, there is some condition for the firing of a transition; it can simply be the constantexpression, variable expression, primitive expression. It can also be the timer expression andcomplex expression.Similarly, there is some effect action after the firing of a transition, it simply can be the assign-ment statement, timer statement. It can also be the if statement, and compound statement.The expression and effect function module set include the following functions:CHAPTER 4. IMPLEMENTATION^ 32trans_expr_check(), ifst_ef f n(), ast_ef fn(), tst_ef fn, cst_ef fn(), ef f_trans().The trans_expr_check() function handles the condition predicate for each of the transitions,and the rest functions handle the effect action whenever a transition is fired.4.2.5 Initiate ModuleAs the testing starts, there should be some initial values for the JUT, such as the initial state,initial values for variables, initial status for timer.In order to do the protocol backtracking testing, we also need to copy parts of the staticdata structure values into the dynamic data structure, such as the entire initial input serviceprimitives, output service primitives, protocol data units. All of these guarantee the consistencyof the whole dynamic data structure with the static data structure.4.2.6 Backtracking ModuleThe backtracking module is the kernel of the TESTGEN; it implements the backtracking algo-rithm we described before, finds the whole possible subpaths, and produces the entire testingresults.The backtracking module consists of a backtracking control part, a transition and state selectionpart, a backing part, a subpath storing part.control part:The control part controls the running of the entire backtracking testing process; thetesting is finished if the Boolean expression in the control part can satisfy the followingtwo requirements:CHAPTER 4. IMPLEMENTATION^ 331. The current testing state is the initial state.2. All the transitions in all testing states which can be fired have already been applied.Tithe control part detects that the current testing process meets the above two require-ments, it automatically stops the testing, and starts the subpath output modules. Oth-erwise, it continues running the backtracking module.transition and state selection part:The transition and state selection part handle the selection of a new testing state anda new applying transition in the current testing state. The new testing state is thedestination state of the current transition. To select a new testing state, we need to knowthe current applying transition from the old testing state, and we also need to checkwhether the new testing state passes the constraint limits which the user specifies.The new applying transition is the next applying transition in the current testing state.To select a new applying transition, we need to know the current testing state; also, weneed to check whether the new applying transition passes the constraint limit which theuser specifies.After the transition is fired , we need to mark the firing of that transition in the currenttesting state. The function set of this module includes Ntr_ find() function; it finds thenext applying transition for the current testing state, checks the constraint limit for thistransition, and decides whether this transition can be fired or not according to the returnvalue from the expression checking function of this transition. Also, it includes some otherCHAPTER 4. IMPLEMENTATION^ 34functions such as the mark_trans() function and so on.backing part:As the testing is in progress, we need to go back one step under one of the two circum-stances. The new testing state we reach is the initial state, or the current testing statehas no transition which can be applied.When the testing process is in one of the two above situations, the current testing stategoes back to the previous one, and all the transitions in the current testing state areunmarked.subpath store part:After building a subpath, we need to store it. Thus, the backtracking module calls thesubpath store function to store the current subpath and link it to the previous one.4.2.7 Subpath Identification ModuleThe subpath identification module outputs all the subpaths which generated from the back-tracking testing kernel in a certain format.The subpath identification module includes two functions sub_print() and sel_print().The sub_print() outputs all the subpaths, generated from the testing kernel. Here is a simplesubpath output example.Specification id = TPOCHAPTER 4. IMPLEMENTATION^ 35yyparse() = 0The subpathes number is 1The subpathes areidle - TCREQ /[CR]-> wfcc -[CC]/ TCCON-> data - TDATR /-> data -/EDT]-> data\-[DT]/-> data -/-> data - TDREQ / NDREQ->idle***************************************The subpathes number is 2The subpathes areidle - TCREQ /[CR]-> wfcc -[CC], TCCON-> data - TDATR /-> data -/[DT]-> data\-[DT]/-> data -/-> data - NDIND / TDIND->idle***************************************The subpathes number is 3The subpathes areidle - TCREQ /[CR]-> wfcc -[CC]/ TCCON-> data - TDATR /-> data -/[DT]-> data\-[DT]/-> data -/-> data - NRIND / TDIND->idle***************************************The subpathes number is 4The subpathes areCHAPTER 4. IMPLEMENTATION^ 36idle - TCREQ /[CR]-> wfcc -[DR]/ NDREQ, TDIND->idle***************************************The subpathes number is 6The subpathes areidle - TCREQ / TDIND->idle***************************************The subpathes number is 6The subpathes areidle -[CR]! TCIND-> wftr - TCRES /[CC]-> data - TDATR /-> data -/EDT]-> data\-[DT]/-> data -/-> data - TDREQ / NDREQ->idle***************************************The subpathes number is 7The subpathes areidle -[CR]! TCIND-> wftr - TCRES /[CC]-> data - TDATR /-> data -/[DT]-> data\-[DT]/-> data -/-> data - !WIND / TDIND->idle***************************************The subpathes number is 8CHAPTER 4. IMPLEMENTATION^ 37The subpathes areidle - [CR], TCIND-> wftr - TCRES /[CC]-> data - TDATR /-> data -/ [DT]-> data\- [DT] /-> data -/-> data - NRIND / TDIND->idle***************************************The sel_print0 prints the detailed information about some certain testing state in some sub-pathes. It prints until the current time, how many times that state, the whole variables,constants, and timers have been used in the backtracking testing. Also the values for the wholevariables, timers, the names and the values of the all service primitives which have been usedin this testing state. The user can select the testing state and the subpath number which hewould like to get more detailed information about the testing results.Here, we have a simple example of one testing state in one subpath of the tp0 testing result.The subpath number is 2The subpath areidle - TCREQ /[CR]-> wfcc - [CC]/ TCCON-> data - TDATR /-> data -/ [DT]-> data - [DT] /-ata -/-> data - NDIND / TDIND->idle*********************************************************************************************CHAPTER 4. IMPLEMENTATION^ 38This is the detailed information for the state 0******************************************************The used of the state in the backtracking is 0/////////////////// DETAILED INFORMATION /////////////////////******************************************///////This is the information about the transition 0//////******************************************///////****** The isp name of this transition is TCREQ *****TCREQ.qtsReq = TRUETCREQ.fromAddr = 312TCREQ.toAddr = 316**********output pdu one name of this transition is CR *******CR.sourceRef = 665Moption =CR.callingAddr = 314CR.calledAddr = 225CHAPTER 4. IMPLEMENTATIONCR.maxTpdu = 1024This is the information about the transition 1// ////**************** * ********* *********** ** ***///// //****** The isp name of this transition is TCREQ *****TCREQ.qtsReq =TCREQ.fromAddr = 321TCREQ.toAddr = 324********* osp 1 name of this transition is TDIND ********TDIND.tsDiscReason =TDIND.tsUserReason =************** The constant information are ****************//////////////**********************/////////////////////////The constant number is 0The used for this constant is 139/////////////*************************////////////////////////************ The timer information are ********************CHAPTER 4. IMPLEMENTATION^ 40/////////////*************************////////////////////////The timer key number is 0The started times for this timer is 0The stopped times for this timer is 0The reseted times for this timer is 0The check of the reseted for this timer is 0The check of the started for this timer is 0The check of the stopped for this timer is 0The check of the timed out for this timer is 04.2.8 TTCN Dynamic ModuleThe TTCN dynamic part contains the main body of the test suite, it comprises three sectionsthat contain tables specifying test behaviour expressed mainly in terms of the occurrence ofASPS at PC0s. it provides the information in a certain format, Behaviour Description, Label,Constraint Reference, Verdict, Comments.Our modified TTCN dynamic output simplifiesn the format, and provide some important partsof them. Such as behaviour tree part, constraint reference part and the verdict part.The TTCN dynamic module takes the subpathes from the testing kernel and produces themodified TTCN dynamic table. Here, we have a simple example, the two test cases of theFDDI.CHAPTER 4. IMPLEMENTATION^ 41Test^Case^Dynamic^BehaviourIdentifier^Case 1Behaviour Description^Constraint Ref^Verdict! SmMaCtrlReq! PhUnitDataIndication? PhUnitDataRequestSmMaCtrlReq_IOPhUnitDataIndication_IOPhUnitDataRequest_01passCHAPTER 4. IMPLEMENTATION^ 42Test^Case^Dynamic^BehaviourIdentifier^Case 2Behaviour Description^Constraint Ref^Verdict! SmMaCtrlReq! PhUnitDataIndication? PhUnitDataRequestSmMaCtriReq_I2PhUnitDataIndication_I2PhUnitDataRequest_03passCHAPTER 4. IMPLEMENTATION^ 434.2.9 TTCN Constraint ModuleIt is necessary to specify, in detail, the values of ASP parameters and PDU fields. The TTCNConstraint Part specifies values for the ASPs, PDUs, and their parameters used in the DynamicPart. And we use the TTCN constraint tables to specify these information.The TTCN tabular form a constraint is defined by specifying a value for each PDU field. Thisinformation shall be provided in some certain format. Also, each field entry in the field namecolumn shall have been declared in the relevant ASP or PDU declaration, values assigned toeach field shall be of the type specified in the PDU (or ASP) declaration.The TTCN constraint module takes the generated subpathes and the TTCN dynamic part asthe input, and produce corresponding TTCN constraint tables.Here, we have a simple example, part of the FDDI TTCN constraint table.ASP ConstraintASP Name: SmMaCtrlReq^Constraint Name: SmMaCtrlReq_IlCHAPTER 4. IMPLEMENTATION^ 44Field Name Value^CommentsSmMaCtrlReq.ctrlAction^ 0ASP ConstraintASP Name: PhUnitDataIndication^Constraint Name: PhUnitDataIndication.CHAPTER 4. IMPLEMENTATION^ 45 Field Name^Value^CommentsPhUnitDataIndication.phIndication^0ASP ConstraintASP Name: PhUnitDataRequest^Constraint Name: PhUnitDataRequest_01Field Name^Field Name^Value^CommentsCHAPTER 4. IMPLEMENTATION^ 46PhUnitDataRequest .phRequest^ 0Protocol Specification( ASN.1 )Protocol Specification( Estelle.Y) Constraint EditorSubtour identification outputTSO ConstraintChapter 5Test Case Validator and LAPBValidationTest generation kernel Modified TTCN generation( Tree and verdict ) 'ITCN Constraint TablesFigure 5.1: Components of TESTGEN+47CHAPTER 5. TEST CASE VALIDATOR AND LAPB VALIDATION^48In this chapter, I discuss the test case validator and the validation of the standardized LAPBtest suite.Test case generation and validation are two important topics in protocol testing research. Com-pared to test case generation, much less work has been done in the area of test case validation.As part of a Ph.D research conducted at the University of British Columbia, a trace analysistool has been developed based on the protocol data structure (PDS) produced by the parserTESTGEN. This tool can handle any protocol specifications that can be mapped into an EFSM,and can be easily modified to serve as a test case validator, called TESTVAL.TEST VAL can be incorporated into TESTGEN to produce an overal tool called TESTGEN+for protocol test generation and validation, as shown in Figure 5.15.1 Trace Analysis and Validator5.1.1 Trace AnalysisTrace analysis is a very important part of protocol conformance testing. Compared to test casegeneration, trace analysis has the following main differences.1. In test case generation, the initial and final states of each path are assumed to be known.Trace analysis is different; we need to determine the initial and final states from theobserved input and output message sequences. Even for finite state machines which dealwith control flow only, determining the initial state is not always possible. The conditionis even more complicated for extended finite state machines which deal with both controland data flows.CHAPTER 5. TEST CASE VALIDATOR AND LAPB VALIDATION^492. In test case generation, every possible path of a formal specification has to be considered.Trace analysis, on the other hand, needs only to consider a finite number of paths thatcomply with the observed sequence of input and output messages.3. The paths which have to be considered in trace analysis are finite in number and area subset of those for test case generation. The trace contains information to determinethe actual number of loop iterations, specific values of parameters, and the outcome ofconditional statements. The absence of this information is largely responsible for theinefficiency in test case generation.The trace analysis which was developed in the University of British Columbia is based on theextended finite state machine (EFSM), and the general steps are as following:Given an Estelle specification and its implementation M.1. Transform the Estelle specification into the single module Estelle specification.2. Map from Estelle specification E to finite state machine F.3. Perform trace analysis for conformance testing:a: Select from F the set of paths satisfying the input and output message in the case oftrace analysis, and all the paths from the given initial state to the given final statewith constraint for test case generation.b: Detect and delete the infeasible paths using symbolic evaluation if necessary.c: Assign verdict.CHAPTER 5. TEST CASE VALIDATOR AND LAPB VALIDATION^50The implementation of the trace analysis consists of three parts:Preprocessing Phase:In this phase, some transitions of formal specification are preprocessed to be changed intofinite state machine form.Main Phase:In order to make the implementation simple, fast and feasible without diminishing prac-ticality, we assume that the trace analysis is started at the initial state. We analyzetraces with respect to PDS of Estelle formal protocol specification. Data structure pathscontain information such as data structures on a number of transitions and to_state ofeach transition with respect to the same from_state. Also, the current pointer of traceprocessing by trace analyzer is kept in order to process the right trace from the file.Final Phase:At from_state and to_state, these states contain an environment on all variables of aspecification and all candidate transitions at that state. If there is a candiate transition,values of variables and service primitive from trace are substituted by a symbolic repre-sentation of PDS. lithe predicate and the output primitives of a transition are satisfiedwith a trace, we can say that the trace conforms to the formal specification with respectto the trace.Traces not conforming to the formal specifications are from the unsatisfaction of predi-cates, and the no matching of inputs and or outputs.CHAPTER 5. TEST CASE VALIDATOR AND LAPB VALIDATION^515.1.2 ValidatorThe trace analysis can also be used as a validator to validate the test cases. In order tohandle various kinds of unexpected test cases, I made modifications to several parts of the traceanalyzer to make it more general and practical for the users.To perform a validation, we need two input files: the protocol Estelle specification and theactual test cases.Here is an example for the test case input file, which is a simple test case of LAPB.Case 1:DataIndicat DISC A 1 - - - / DataRequest DM A 1 - - - / -DataIndicat DISC A 1 - - - / DataRequest DM A 1 - - - / -DataIndicat RR A 1 - 0 - / DataRequest DM A 1 - - - / -Each test case consists of "inputl(or input2)loutputlloutput2" where inputl and outputlare of lower interaction point of IUT and input2 and output2 are of upper interaction point.The inputl and outputl consist of "interactionprimitive","PDUtype","address","PI Fbit"," sendsequencenumber" , "receivesequencenumber" and "data f ields" .CHAPTER 5. TEST CASE VALIDATOR AND LAPB VALIDATION^525.2 LAPB5.2.1 IntroductionX.25 is a set making up the international standard network access protocols for layer 1, 2 and3. X.25 defined the interface between the host, called DTE(DATA Terminal Equipment) byCCITT, and the carrier's equipment, called a DCE(DATA Circuitterminating Equipment) byCCITT.X.25 layer 1, the X.21 interface standard deals with the electrical, mechanical, procedural, andfunctional interface between DTE and DCE. It generally defines the physical interface betweenthe DTE and DCE.Layer 2, data link layer protocol, performs the link management and data transfer between theDTE and DCE, and ensures reliable communication between the DTE and the DCE.Layer 3 manages connections between a pair of DTEs. Two forms of connection are provided,virtual calls and permanent virtual circuits.The data link layer protocol used with X.25 is a version of the HDLC protocol called LAPB.The function of LAPB protocol is to provide the packet layer with an error — free packettransport facility over the physical link between DTE and its local DCE.As discussed, the physical interface between the DTE and the local DCE is defined in recom-mendation X.21. The datalink layer provides the packet layer with a reliable packet transportfacility across the physical link between the DTE and the DCE. In the context of the OSI ref-erence Model, the packet layer is the same as the network layer. The transport layer thus usesthe services provided by the packet to enable it to exchange Transport PDUs with a remoteCHAPTER 5. TEST CASE VALIDATOR AND LAPB VALIDATION^53transport layer.The frame structure, error and flow control procedures used by the link layer are based on theHDLC protocol. HDLC is a link — level protocol that has been defined by the ISO for useon both point — to — point and multipoint data links. It supports full — duplex, transport —mode operation and is now extensively used in both terminal — based networks and computernetworks. It uses the ABM(asynchronous Balanced Mode) of operation, which is also referredto as LAPB in the CCITT X.25 standard document.5.2.2 LAPB Estelle SpecificationThe LAPB was specified according to the Packet— Switch Protocol documentation. The FiniteState Machine(FSM) structuring the LAPB protocol is described in the documentation.Link Set UpAfter DTE and DCE entered into the Initial State, The DCE sends the "DM" primitive to theDTE. It changes the state from the INITIAL to SEND_DM and starts the timerl. Whentimerl is out, the DCE retransmits the "DM". After N2 times of timeout, DCE sends a"SABM" to the DTE. It enters SABM_SENT state and starts timerl. DTE gets the "DM"N2 times but ignores them. Eventually, DTE gets "SABM" under INITIAL state; it sendsa "UA" to response the DCE and changes its state from INITIAL to ABM. DCE will receivethat "UA" response and change its state from SEND_SABM to ABM. At this moment, bothDCE and DTE get in ABM state and be ready to transmit the information frames.CHAPTER 5. TEST CASE VALIDATOR AND LAPB VALIDATION^54Information Frame SendingWhen the LAPB entity module gets a Data_Req primitive from its user module, the LAPBentity will transmit the Iframe by setting its parameter variable ns equal to its window variablevs, and parameter variable nr equal to its window variable yr. After sending the Iframe, the vs iscreased by 1 with mod k. This Iframe should be buffered in retxbuffer before it is acknowledgedby its peer LAPB entity.Information Frame ReceivingWhen an Mame arrives, it is accepted if its parameter variable ns is equal to the window's vr.The window variable yr is the number of the Mame the current LAPB waiting for. By acceptingthe Iframe, the yr is increased by 1 with mod k, and timer2 is started. The acknowledgementfor this Iframe should not be sent at this moment; it will be piggybacked in the next outsendingIframe or be sent when timer2 is out.Receiving AcknowledgementThere may be two kinds of acknowledgements: Mame with p f = 1, or in retransmission a buffershould be released. The corresponding action in this specification is that retxprt(retransmissionbuffer pointer) increases by 1 with mod k and window variable nubuffered(number of bufferedIframe in retransmission buffer) decreased by 1.CHAPTER 5. TEST CASE VALIDATOR AND LAPB VALIDATION^55Receiving RejectThe REJ_cmd can inform the receiving LAPB of the number of Iframe which the peer LAPBin remote station is waiting for.Link Disconnect ConditionWhen the LAPB receives the dis_req from the upper layer, it sends dis_cmd to remote stationand sets discmyself as true. When discmyself is true, the current LAPB entity module stopssending anything out, but can not refuse receiving coming messages until receiving disc_resp,and stops running LAPB protocol too. This disconnection procedure guarantees that no mes-sage is lost during the disconnection procedure.5.2.3 LAPB SpecificationPDU Encoding and DecondingEvery LAPB PDU contains the following items in the form of interaction parameters:.address: the address of the station the message comes from, DCE or DTE in this program..control: type of the message; it can be INF for information frame, SUP for supervisory frame,and UNB for unnumbered frame..ns: for information frame, it tells the receiver that sequence number of the coming informationframe. This ns is assigned to be window variable vs.CHAPTER 5. TEST CASE VALIDATOR AND LAPB VALIDATION^56.nr: for information frame; it tells the receiver the acknowledgement from sender if pf is equalto 1. This ns assigned to be window variable yr. It also includes the acknowledgementwhen the RR_cmd is sent while pf is set..pf: as Iframe; when it is set, it indicates that the acknowledgement is piggybacked. As Uframewhen pf is set, it indicates that the sender site is polling for an Mame..udata: transmitted user data.ASN.1 SpecificationThe ASN.1 specification part of the LAPB specification specifies the all filed data type of eachASP and PDU, and it will be inputted into the ASN.1 parser.5.3 LAPB Validation and Result AnalysisUsing this validator, I validated the whole LAPB test cases defined in the ISO 9646 standarddocument. In general, more than eighty percent of test cases passed our validation; the remain-der could not pass due to the incompleteness of the LAPB specification used in the validation.Further details of the validation and the analysis are given in this section.ValidationThe whole LAPB test suite consists of around 300 test cases which are classified into sevenphases.DL1:CHAPTER 5. TEST CASE VALIDATOR AND LAPB VALIDATION^57The DL1 is the Disconnected Phase; it is the state when JUT receives DISC and sendsthe UA or DM frame. There are 36 valuable test cases here. After the validation, 31test cases passed which means that more than ninety percent of test cases passed thevalidation in DLLDL2:The DL2 is the Link Disconnection phase; it is the state when JUT sends DISC frame.There are 31 valuable test cases here; 29 test cases passed the validation, which meansthat more than ninety three percent of test cases passed the validation in DL2.DL3:The DL3 is the Link Set up phase; it is the state when JUT sends SABM frame fromDisconnected Phase. There are 29 valuable test cases here. After the validation, 28 testcases passed. This means that more than ninety five percent of test cases passed thevalidation in DL3.DL4:The DL4 is the Information Transfer phase; it is the state when JUT receives the SABMand sends the UA frame, or JUT sends the SABM and it receives the UA frame. Thereare 43 valuable test cases here, and 33 test cases passed the validation after the test. Thismeans that around seventy percent of test cases passed the validation in DL4.DL5:CHAPTER 5. TEST CASE VALIDATOR AND LAPB VALIDATION^58The DL5 is the Frame reject condition phase; it is the state when JUT sends the FRMRframe from the Information Transfer phase. There are 40 valuable test cases here; 28 testcases passed the validation after the test. Thus seventy percent of test cases passed thevalidation in DL5.DL6:The DL6 is the JUT busy condition phase; it is the state when JUT sends the RNR framefrom the Information Transfer phase. There are 32 valuable test cases here, and 20 testcases passed the validation after the test; sixty percent of test cases passed the validationin DL6.DL7:The DL7 is the Sent Reject condition phase; it is the state when JUT sends the REJ framefrom the Information Transfer phase. There are 33 valuable test cases here, and 27 testcases passed this validation; it means that around eighty percent of test cases passed thevalidation in DL7.From the seven phase testing results, we see that more than eighty percent of test cases herepassed the validation. Clearly, this result is quite productive.AnalysisFrom the above results, we are surprised to see that the total percentage rate with which thetest cases passed this validation vary in different phases. This difference is mainly because ofCHAPTER 5. TEST CASE VALIDATOR AND LAPB VALIDATION^59the different limitations of this protocol specification among the seven phases. In the first threephases, we have a very complete LAPB specification. Most of the test cases which stand in theISO 9646 standard conform to the specification we used here, a few of them could not pass.However, in the later phases, due to the incompleteness of the LAPB specifications, some testcases have been ignored, and there is a relatively lower passing rate.After carefully analyzing these test cases, we find that some of the test cases couldn't bevalidated by this validator. There are several reasons:— limitations of the specification of the LAPB protocol:Due to the limitations of this LAPB specification, there are some test cases could not beincluded; for example, in the Disconnected phase, the DL1_102 is supposed to verify thatIUT sends a DM with F=0 in response to DISC P=0. The specifications here only havethis situation with F=1, and P=1. The validator could not find any corresponding casesin the current LAPB version; this will result in the failure of this test case validation.DL1_102DataIndicat DISC A 0 - - - / DataRequest DM A 0 - - / _— limitations of the validator:CHAPTER 5. TEST CASE VALIDATOR AND LAPB VALIDATION^60Due to the limitations of the validator, there are still some test cases which could not bevalidated. Let us look at some examples here.In the DL4, there is a test case DL4_116; it verifies that the JUT in the informationtransfer phase can manage its send window correctly. For the purposes of this test, the JUTshall transmit I frame that has a N(S) value within the send window. Acknowledgementsfrom the tester will rotate the send window for the DTE. The JUT window rotationshall be observed over the entire valid range of sequence numbers. The JUT shall stopthe window rotation function when outstanding acknowledgements are not sent from thetester.The test cases are obviously out of the input format we used here; thus, they can not bevalidated by this validator.The redundant test case:After carefully going through all the unsuccessful test cases, we find a few redundant testcases which may be omitted from a standard test suite.Let us look at two test cases in the DL4, and at the information transfer phase in theLAPB. The point is to verify that in this phase, the JUT shall transmit an FRMR framein response to a command frame with undefined or unimplemented control field. The C / Rbit can be set to "0" or "1" and the W bit shall be set to "1" in the FRMR informationfield. In the ISO 9646 standard test cases, this test case was put into two separated testcases, which include the C/R both 0 and 1.CHAPTER 5. TEST CASE VALIDATOR AND LAPB VALIDATION^61It definitely increases the number of unnecessary test cases, and produces some redundanttest cases.5.4 ConclusionThis chapter presents a test case validator, which is based on the finite state machine modeland Estelle.Y specification.After using it to validate the ISO 9646 LAPB test cases, a most satisfactory result has beenproduced.Here, we can see that this validator is not only an efficient, general, flexible and semi-automatictool for various kinds of protocol conformance test cases, but is also a very remarkable apporachto the protocol verification and validation, both theoretically and practically.However, with the limitation of this validator, we couldn't test all possible test cases here;clearly, some improvement is still needed. For example, in one of the LAPB test cases, we couldnot validate the test case which has wrong information in the "checksum" field simply becausewe hadn't provided any input format to do so. In short, some improvement is still needed infuture work.Chapter 6Conclusion and Future work6.1 SummaryIn this thesis, we discussed about the implementation of the TESTGEN and the test suitevalidation for some real protocol LAPB , TESTVAL, a test case validator based on an existingtrace analyzer.TESTGEN is intended to serve as a effective, general, flexible, portable, and user friendlyenvironment for protocol generation.However, TESTGEN is found to be unsuitable for test case validation. We have thus developeda test case validator called TESTVAL which is based on existing protocol trace analyzer andapplied it to the standard LAPB test suite.In general, we find TESTGEN+, including TESTGEN and TESTVAL, a general, useful andeffective tool for protocol test generation and validation.626.2 Future workDespite the usefulness of TESTGEN+, There are still some areas which need further work toimprove the tool.• In TESTGEN, the number of data types supported for the ASN.1 data part representation,is limited to only a few types, thus limiting its applicability to real-life protocols. How toextend TESTGEN to support more data types is one of the major improvements in thefuture TESTGEN version.• In practice, TESTGEN is for test case generation, and TESTVAL is for test case validation.It is useful to combine these two tools together to handle the entire test generation andvalidation. This is an ongoing piece of development work in the Protocol EngineeringGroup at UBC.. Also, we need to improve the output format of the TTCN dynamic part and TTCN constraintpart, as well as producing more complete and beautiful output format in general.. Still, we need to improve the parser part and the test kernel part to adopt more and morereal protocols for conformance testing.. For TEST VAL, we also need to improve it further and to make it more general for validingtest cases of any protocols.63Appendix ALAPB Estelle SpecificationSpecification lapb;CONSTMAXCLOCK = 1000: int;MAXSEQ^= 7: int;DATASIZE = 1024: int;N2MAX^= 6: int;= 8: int;ZERO^= 0: int;ONE^= 1: int;NO^= false: boolean;YES^= true : boolean;VARdatano,retxptr : int;busyremote : boolean;busymyself : boolean;discmyself : boolean;vs,vr : int;timerion,timer2on : boolean;n2,nubuffered : int;data : int;ISP64UP^nsap;OSPDOWN^nsap;PDUSABM^recv_in UP;DISC^recv_in UP;UA recv_in UP;DM^recv_in UP;recv_in UP;FRMR^recv_in UP;RRcmd^recv_in UP;RRresp^recv_in UP;RNRcmd^recv_in UP;REJcmd^recv_in UP;RNRresp recv_in UP;REJresp recv_in UP;BADcmd recv_in UP;BADresp recv_in UP;TimerTimer1^2;Timer2^1;STATEINITIAL, DMSend, SABMSend, ABM,SABMWait, UAWait;TRANSFROM INITIALTO DMSendWHEN^UPOUTPUT DM65BEGINtimerlon := YES;n2 := n2 + ONE;END;TO DMSendOUTPUT DMBEGINn2 := n2 + ONE;END;FROM DMSendTO DMSendWHEN^DISCOUTPUT DMBEGINtimerion := YES;n2 := n2 + ONE;END;TO SABMS endWHEN^DMOUTPUT SABMBEGINtimerion := NO;n2 := ZERO;END;TO SABMSendWHEN^FRMROUTPUT SABMBEGINtimerlon := NO;n2 := ZERO;66END;TO DMSendPROVIDED^((n2 < N2MAX) and (timerlon = true) and Timeout(Timer1))OUTPUT DMBEGINn2 := n2 + ONE;END;TO DMSendPROVIDED^((n2 >= N2MAX) and (timerlon = true))OUTPUT SABMBEGINtimer/on := NO;n2 := ZERO;END;TO ABMWHEN^SABMOUTPUT UABEGINvs := ZERO;vr := ZERO;timerlon := NO;timer2on := NO;n2 := ZERO;nubuffered := ZERO;END;FROM SABMSendTO SABMSendWHEN^SABMOUTPUT UABEGINtimerlon := YES;67n2 := n2 + ONE;END;TO DMSendWHEN^DISCOUTPUT DMBEGINtimerion := NO;n2 := ZERO;END;TO ABMWHEN^UABEGINvs := ZERO;vr := ZERO;timerlon := NO;timer2on := NO;n2 := ZERO;nubuffered := ZERO;END;TO DMSendWHEN^IOUTPUT DMBEGINtimerlon := NO;n2 := ZERO;END;TO DMSendWHEN^RRcmdOUTPUT DMBEGINtimerlon := NO;n2 := ZERO;68END;TO DMSendWHEN^RNRcmdOUTPUT DMBEGINtimerlon := NO;n2 := ZERO;END;TO DMSendWHEN^REJcmdOUTPUT DMBEGINtimerlon := NO;n2 := ZERO;END;TO DMSendWHEN^RRrespOUTPUT DMBEGINtimerlon := NO;n2 := ZERO;END;TO DMSendWHEN^RNRrespOUTPUT DMBEGINtimerlon := NO;n2 := ZERO;END;TO DMSendWHEN^REJrespOUTPUT DMBEGIN69timerion := NO;n2 := ZERO;END;TO DMSendWHEN^BADcmdOUTPUT DMBEGINtimerlon := NO;n2 := ZERO;END;TO DMSendWHEN^BADrespOUTPUT DMBEGINtimerlon := NO;n2 := ZERO;END;TO SABMSendPROVIDED^(timerlon = true )OUTPUT SABMBEGINtimerlon := YES;n2 := n2 + ONE;END;FROM ABMTO DMSendWHEN^DISCOUTPUT UABEGINtimerlon := NO;n2 := ZERO;END;70TO DMSendWHEN^UAOUTPUT DMBEGINtimer1on := NO;n2 := ZERO;END;TO ABMWHEN^RRcmdPROVIDED^((busymyself = false) and (discmyself = false))OUTPUT IBEGINretxptr := (retxptr + 1) mod k;nubuffered := nubuffered + 1;vs := (vs + 1) mod k;END;TO ABMWHEN^RRcmdPROVIDED^( busymyself = true )BEGINnubuffered := nubuffered - 1;retxptr := (retxptr + 1) mod k;END;TO ABMWHEN^REJcmdOUTPUT I;TO SABMSendWHEN^DMOUTPUT SABM;TO UAWaitWHEN^FRMROUTPUT SABM;71TO SABMWaitWHEN^BADcmdOUTPUT FRMR;TO SABMWaitWHEN^BADrespOUTPUT DM;TO ABMWHENPROVIDED^(busymyself = false)OUTPUT IBEGINvr := (yr + 1) mod k;timer2on := true;nubuffered := nubuffered - 1;vs := (vs + 1) mod k;nubuffered := nubuffered + 1;timerlon := YES;END;TO ABMWHEN^UPPROVIDED^((busyremote = false) and (timer2on = false) and (nubuffered < MIOUTPUT IBEGINvs := (vs + 1) mod k;nubuffered := nubuffered + 1;timer1on := YES;END;TO ABMPROVIDED^((busymyself = false) and (timer2on = true) and Timeout(Timer2):OUTPUT RRcmdBEGINtimer2on := NO;END;72TO ABMPROVIDED^((busyremote = false) and (timerlon = true ) and (nubuffered <OUTPUT IBEGINif (nubuffered <= k)thentimerlon := YESelsetimer2on := NO;END;TO ABMWHENPROVIDED^(busymyself = false)OUTPUT REJcmd;TO ABMWHENPROVIDED^(busymyself = true);TO ABMWHEN^UPPROVIDED^(UP.hostbusy = true)OUTPUT RNRrespBEGINbusymyself := YES;END;^FROM^SABMWaitTO^ABMWHEN^SABMOUTPUT UABEGINvs := ZERO;vr := ZERO;timerlon := NO;73timer2on := NO;n2 := ZERO;nubuffered := ZERO;END;TO^DMSendWHEN^DISCOUTPUT UABEGINtimerlon := NO;n2 := ZERO;END;TO^DMSendWHEN^UAOUTPUT^DMBEGINtimerlon := NO;n2 := ZERO;END;TO^DMSendWHEN^UAOUTPUT^SABMBEGINtimerlon := NO;n2 := ZERO;END;TO^SABMWaitWHEN^IOUTPUT FRMRBEGINtimerlon := YES;n2 := n2 + ONE;END;TO^DMSend74WHEN^FRMROUTPUT DMBEGINtimerion := NO;n2 := ZERO;END;TO^SABMWaitWHEN^RRcmdOUTPUT FRMR;TO^SABMWaitWHEN^RNRcmdOUTPUT FRMR;TO^SABMWaitWHEN^REJcmdOUTPUT^FRMR;TO^SABMWaitWHEN^BADcmdOUTPUT^FRMRBEGINtimerlon := YES;n2 := n2 + ONE;END;TO SABMWaitPROVIDED^((timer1on = true) and (n2 < N2MAX) and Timeout(Timer1))OUTPUT FRMRBEGINtimerlon := YES;n2 := n2 + ONE;END;TO UAWaitPROVIDED^((timer1on = true) and (n2 >= N2MAX))OUTPUT SABM75BEGINtimerlon := NO;n2 := ZERO;END;FROM UAWaitTO UAWaitWHEN^SABMOUTPUT UABEGINtimerlon := YES;n2 := n2 + ONE;END;TO DMSendWHEN^DISCOUTPUT DMBEGINtimerlon := NO;n2 := ZERO;END;TO ABMWHEN^UAOUTPUT DMBEGINtimerlon := NO;n2 := ZERO;END;TO SABMSendWHEN^DMOUTPUT SABMBEGINtimerlon := NO;n2 := ZERO;END;76TO UAWaitPROVIDED^((timerlon = true) and (n2 < N2MAX) and Timeout(Timeri))OUTPUT SABMBEGINtimerlon := YES;n2 := n2 + ONE;END;TO DMSendPROVIDED^((timerlon = true) and (n2 >= N2MAX))OUTPUT DMBEGINtimerion := NO;n2 := ZERO;END;END.77Appendix BPART OF LAPB SUBTOURIDENTIFICATION OUTPUTThe subpathes number is 1The subpathes areDMSend - [DISC] / [DM] ->DMSend***************************************The subpathes number is 2The subpathes areDMSend - [DM] / [SABM]-> SABMSend - [SABM] / [UA]-> SABMSend - [DISC] / [DM] ->DMSend***************************************The subpathes number is 3The subpathes areDMSend - [DM] / [SABM]-> SABMSend - [SABM]/ [UA]-> SABMSend - [UA]/-> ABM - UP / [RNRresp] -:ABM - UP / [I] -> ABM - [BADresp]/ [DM] -> SABMWait - [SABM] / [UA]->SABMWait - [DISC] / [UA]->DMSend***************************************The subpathes number is 4The subpathes areDMSend - [DM] / [SABM]-> SABMSend - [SABM] / [UA]-> SABMSend - [UA]/-> ABM - UP / [RNIIresp]-:ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / [UA]->SABMWait - [UA] / [DM] ->DMSend78***************************************The subpathes number is 5The subpathes areDMSend - [DM] / [SABM]-> SABMSend - [SABM] / [UA]-> SABMSend - [UA]/-> ABM - UP / [RNRresp]-:ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / [UA]->SABMWait - [UA] / [SABM]->DMSend***************************************The subpathes number is 6The subpathes areDMSend - [DM] / [SABM]-> SABMSend - [SABM] / [UA]-> SABMSend - [UA]/-> ABM - UP / [RNRresp]-:ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / [UA]->SABMWait - [I] / [FRMR]-> SABMWait - [FRMR] / [DM] ->DMSend***************************************The subpathes number is 7The subpathes areDMSend - [DM] / [SABM]-> SABMSend -[SABM] / [UA]-> SABMSend - [UA]/-> ABM - UP / [RNRresp]-:ABM - UP / [1]-> ABM - [BADresp] / [DM] -> SABMWait -ESABM] / [UA]->UAWait - [SABM] / [UA]-> UAWait - [DISC] / [DM] ->DMSend***************************************The subpathes number is 8The subpathes areDMSend - [DM]/ [SABM] -> SABMSend -[SABM]/ [UA]-> SABMSend - [UA] /-> ABM - UP / [RNRresp] -:ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / [UA]->UAWait - [SABM] / [UA]-> UAWait - [UA] / [DM] -> ABM -[RNRresp] /->ABM -[SABM] / [UA]-> ABM - [DISC] / [UA] ->DMSend***************************************The subpathes number is 9The subpathes areDMSend - [DM)/ [SABM] -> SABMSend - [SABM] / [17']-> SABMSend - [UA] /-> ABM - UP / [RNRresp] - :ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / [UA] - >UAWait - [SABM] / [UA] -> UAWait - [LTA]/ [DM] -> ABM - [RNRresp] /->ABM - [SABM] / [UA]-> ABM -[ITA] / [DM] ->DMSend***************************************79The subpathes number is 10The subpathes areDMSend - [DM] / [SABM] -> SABMSend - [SABM] / [UA] -> SABMSend -En] /-> ABM - UP / [RNRresp] -ABM - UP / [17-> ABM - [BADresp] / [DM] -> SABMWait -[SABM] / [UA]->UAWait - [SABM] / [UA]-> UAWait - [UA] / [DM] -> ABM -[RNEresp]/->ABM - [SABM] / [UA] -> ABM - [DM] / [SABM]-> SABMSend - [I] / [DM] ->DMSend***************************************The subpathes number is 11The subpathes areDMSend - [DM]! [SABM] -> SABMSend - [SABM] / En] -> SABMSend - [UA]/-> ABM - UP / [RNRresp] -ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / [UA] ->UAWait - [SABM] / [UA] -> UAWait - [UA] / [DM] -> ABM - [RNRresp] /->ABM - [SABM] / [UA] -> ABM - [DM] / [SABM] -> SABMSend - [RFtcmd] / [DM] ->DMSend***************************************The subpathes number is 12The subpathes areDMSend - [DM] / [SABM]-> SABMSend - [SABM] / [UA]-> SABMSend - [UA]/-> ABM - UP / [RNRresp]-:ABM - UP / [I] -> ABM -[BADresp] / [DM] -> SABMWait -[SABM]/ [UA]->UAWait - [SABM] / [UA]-> UAWait - [UA]/ [DM] -> ABM -ERNRresp]/->ABM - [SABM] / [UA]-> ABM - [DM] / [SABM] -> SABMSend - [RNRcmd] / [DM] ->DMSend***************************************The subpathes number is 13The subpathes areDMSend - [DM]! [SABM]-> SABMSend - [SABM] / [UA]-> SABMSend - [UA] /-> ABM - UP / [RNRresp]-:ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / [UA]->UAWait - [SABM] / [UA]-> UAWait - [UA] / [DM] -> ABM - [RNRresp] /->ABM -[SABM]/ [UA]-> ABM - [DM] / [SABM] -> SABMSend - [REJcmd] / [DM] ->DMSend***************************************The subpathes number is 14The subpathes areDMSend - [DM] / [SABM]-> SABMS end - [SABM] / [UA]-> SABMSend - [UA] /-> ABM - UP / [RNRresp]-:ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / [UA]->UAWait - [SABM] / [UA]-> UAWait - [UA] / [DM] -> ABM - [RNRresp] /->80ABM - [SABM] / [UA]-> ABM - [DM] / [SABM]-> SABMSend - [IRresp] / [DM] ->DMSend***************************************The subpathes number is 15The subpathes areDMSend - [DM] / [SABM]-> SABMSend - [SABM]/ [UP.] -> SABMSend - [UA]/-> ABM - UP / [RNRresp] -ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / [UA] ->UAWait - [SABM] / [UP.] -> UAWait - [UP.] / [DM] -> ABM - [RNRresp] /->ABM - [SABM] / [UP.] -> ABM - [DM] / [SABM] -> SABMSend - [RNRresp] / [DM] ->DMSend***************************************The subpathes number is 16The subpathes areDMSend - [DM] / [SABM] -> SABMSend - [SABM] / CUP.] -> SABMSend - CUP.] /-> ABM - UP / [RNRresp] -ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / [UP.] ->UAWait - [SABM] / [UA]-> UAWait - [UA] / [DM] -> ABM - [RNRresp] /->ABM - [SABM] / [UP.] -> ABM - [DM] / [SABM]-> SABMSend - [REJresp] / [DM] ->DMSend***************************************The subpathes number is 17The subpathes areDMSend - [DM] / [SABM]-> SABMSend - [SABM] / [UP.] -> SABMSend -[UA]/-> ABM - UP / [RNRresp] -:ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / [UP.] ->UAWait -[SABM]/ [UP.] -> UAWait - [UA]/ [DM] -> ABM - [RNRresp]/->ABM -[SABM]/[UA]-> ABM - [DM] / [SABM]-> SABMSend - [BADcmd] / [DM] ->DMSend***************************************The subpathes number is 18The subpathes areDMSend - [DM] / [SABM]-> SABMSend - [SABM] / [UP.] -> SABMSend - [UP.] I-> ABM - UP / [RNRresp]-:ABM - UP / [13-> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / [UA] ->UAWait - [SABM] / [UA] -> UAWait -[UA] / [DM] -> ABM - [RNRresp] /->ABM - [SABM] / [UP.] -> ABM - [DM]! [SABM] -> SABMSend - [BADresp] / [DM] ->DMSend***************************************The subpathes number is 19The subpathes areDMSend - [DM]! [SABM]-> SABMSend - [SABM] / [UP.] -> SABMSend - [UP.] I-> ABM - UP / [RNRresp] -:81ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / CM] ->UAWait - [SABM] / [UA]-> UAWait - [DM] / [SABM] -> SABMSend - [SABM] / [UA]->DMSend***************************************The subpathes number is 20The subpathes areDMSend - [DM)/ [SABM]-> SABMS end - [SABM] / [UA]-> SABMSend - [UA] /-> ABM - UP / [RNRresp] -ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait -[SABM] / [UA]->UAWait - [SABM] / [UA]-> UAWait - [DM] / [SABM] -> SABMSend -[SABM]/ [UA] ->ABM - [I] /-> ABM - UP / [I] -> ABM -[BADresp]/ [DM] ->ABM -[BADcmd] / [FRMR]-> SABMWait -[DISC] / [UA]->DMSend***************************************The subpathes number is 21The subpathes areDMS end - [DM] / [SABM]-> SABMSend - [SABM] / [UA]-> SABMSend - [UA]/-> ABM - UP / [RNRresp]ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / [UA] ->UAWait - [SABM] / [UA]-> UAWait - [DM] / [SABM] -> SABMSend - [SABM] / [UA]->ABM - [I] /-> ABM - UP / [I] -> ABM -[BADresp] / [DM] ->ABM -[BADcmd] / EFRMR]-> SABMWait - [UA] / [DM] ->DMSend***************************************The subpathes number is 22The subpathes areDMSend - [DM] / [SABM] -> SABMS end - [SABM] / [UA] -> SABMS end - [UA] /-> ABM - UP / [RNRresp]ABM - UP /^-> ABM - [BADresp] / [DM] -> SABMWait -[SABM] / [UA]->UAWait - [SABM] / [UA]-> UAWait - [DM] / [SABM]-> SABMSend -[SABM]/ [UA]->ABM - [I] /-> ABM - UP /^-> ABM -[BADresp] / [DM] ->ABM -[BADcmd]/ [FRMR]-> SABMWait - [UA]/ [SABM]->DMSend***************************************The subpathes number is 23The subpathes areDMSend - [DM] / [SABM] -> SABMS end - [SABM] / [UA] -> SABMS end - [UA] /-> ABM - UP / [RNRresp]ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / [UA] ->UAWait - [SABM] / [UA]-> UAWait - [DM]! [SABM]-> SABMS end - [SABM] / [UA]->ABM - [I] /-> ABM - UP / [I] -> ABM -[BADresp] / [DM] ->82ABM -[BADcmd]/ [FRMR]-> SABMWait - [I] / [FRMR] -> SABMWait - [FRMR]/ [DM] ->DMSend***************************************The subpathes number is 24The subpathes areDMSend - [DM] / [SABM]-> SABMS end - [SABM] / [UA]-> SABMSend - [UA]/-> ABM - UP / [RNRresp] -ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / [UA] ->UAWait - [SABM] / [UA] -> UAWait - [DM] / [SABM] -> SABMSend - [SABM] / [UA] - >ABM - [I] /-> ABM - UP / [I] -> ABM -[BADresp] / [DM] ->ABM - [DM] / [SABM] -> SABMSend - [I] / [DM] ->DMSend***************************************The subpathes number is 25The subpathes areDMSend - [DM] / [SABM]-> SABMSend - [SABM] / [UA] -> SABMSend - [LIA] /-> ABM - UP / [RNRresp]-:ABM - UP / [I] -> ABM - [BADresp] /[DM] -> SABMWait - [SABM] / [UA]->UAWait - [SABM] / [UA]-> UAWait - [DM] / [SABM]-> SABMSend - [SABM] / [UA] ->ABM - [I] /-> ABM - UP / [I] -> ABM - [BADresp] / [DM] ->ABM - [DM] / [SABM]-> SABMSend - [RRcmd]/ [DM] ->DMSend***************************************The subpathes number is 26The subpathes areDMSend - [DM] / [SABM]-> SABMSend - [SABM] / [UA]-> SABMSend - [UA]/-> ABM - UP / ERNRresp]-:ABM - UP / [I] -> ABM - [BADresp] /[DM] -> SABMWait - [SABM] / [UA]->UAWait - [SABM] / [UA]-> UAWait - [DM] / [SABM]-> SABMSend - [SABM] / [UA]->ABM - [I] /-> ABM - UP / [I] -> ABM -[BADresp] / [DM] ->ABM - [DM] / [SABM]-> SABMSend -[RNRcmd] /[DM] ->DMSend***************************************The subpathes number is 27The subpathes areDMSend - [DM] / [SABM] -> SABMSend - [SABM] / [UA] -> SABMSend -[UA]/-> ABM - UP / [RNRresp]ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / [UA]->UAWait - [SABM] / [UA]-> UAWait - [DM] / [SABM] -> SABMSend - [SABM] / [UA] ->ABM - [I] / -> ABM - UP / [I] -> ABM -[BADresp] / [DM] ->ABM - [DM] / [SABM] -> SABMSend -[REJcmd] / [DM] ->DMSend***************************************83The subpathes number is 28The subpathes areDMSend -CDM]/CSABM]-> SABMSend -CSABW[UA]-> SABMSend -CUA]/-> ABM - UP /[11NRresp]-ABM - UP /[I]-> ABM -EBADresp]/CDM]-> SABMWait -[SABM]/[UA]->UAWait -ESABM]/EUA]-> UAWait -DM]/[SABM]-> SABMSend -[SABM]/EUA]->ABM -[I]/-> ABM - UP /[I]-> ABM -[BADresp]/[DM]->ABM -[DM]/[SABM]-> SABMSend -[RRresp]/DM]->DMSend***************************************The subpathes number is 29The subpathes areDMSend -[DM]/[SABM]-> SABMSend -[SABM]/CUA]-> SABMSend -CUA]/-> ABM - UP MNRresp]-:ABM - UP /[1]-> ABM -[BADresp]/EDM]-> SABMWait -[SABM]/CUA]->UAWait -[SABM]/CUA]-> UAWait -[DM]/[SABM]-> SABMSend -[SABM]/CUA]->ABM -[I]/-> ABM - UP /[1]-> ABM -[BADresp]/CDM]->ABM -EDM]/[SABM]-> SABMSend -[RNRresp]/DM]->DMSend***************************************The subpathes number is 30The subpathes areDMSend -[DM]/CSABM]-> SABMSend -CSABMYEUA]-> SABMSend -EUA]/-> ABM - UP MNRresp]-:ABM - UP /[1]-> ABM -[BADresp]/EDM]-> SABMWait -[SABM]/[UA]->UAWait -[SABM]/CUA]-> UAWait -[DM]/[SABM]-> SABMSend -[SABM]/[UA]->ABM -[1]/-> ABM - UP /[1]-> ABM -[BADresp]/[DM]->ABM -[DM]/CSABM]-> SABMSend -DIEJresp]/DM]->DMSend***************************************The subpathes number is 31The subpathes areDMSend -CDM]/[SABM]-> SABMSend -[SABM]/NA]-> SABMSend -[UA]/-> ABM - UP /[INRresp]-:ABM - UP /[I]-> ABM -[BADresp]/[DM]-> SABMWait -[SABM]/CUA]->UAWait -[SABM]/CUA]-> UAWait -CDM]/[SABM]-> SABMS end -ISABM]/[UA]->ABM - [I]/ -> ABM - UP /M.> ABM - [BADresp]/DM] ->ABM -CDMYESABM]-> SABMSend -[BADcmd]/EDM]->DMSend***************************************The subpathes number is 3284The subpathes areDMSend - [DM] / [SABM]-> SABMSend - [SABM] / [UA]-> SABMSend - [UA] /-> ABM - UP / [RNRresp] -ABM - UP / [I] -> ABM - [BADresp]/ [DM] -> SABMWait -[SABM]/ [UA]->UAWait - [SABM] / [UA]-> UAWait - [DM] / [SABM]-> SABMS end -[SABM]/ [UA]->ABM - [I] /-> ABM - UP / [I] -> ABM -[BADresp] / [DM] ->ABM - [DM] / [SABM] -> SABMSend -[BADresp] / [DM] ->DMSend***************************************The subpathes number is 33The subpathes areDMSend - [DM] / [SABM]-> SABMSend - [SABM] / [UA]-> SABMSend - [UA] /-> ABM - UP / [RNRresp]-:ABM - UP / [I] -> ABM -[BADresp] / [DM] -> SABMWait -[SABM]/[UA]->UAWait - [SABM] / [UA]-> UAWait - [DM] / [SABM]-> SABMSend - [SABM] / [UA]->ABM - [I] /-> ABM - UP / [I] -> ABM - [BADresp] / [DM] ->ABM -[REJcmd] / [I] -> ABM - [RNRresp] /-> ABM - [RRresp] /->ABM - [DISC] / [UA]->DMSend***************************************The subpathes number is 34The subpathes areDMSend - [DM] / [SABM]-> SABMSend -[SABM] / [UA] -> SABMSend - [UA] /-> ABM - UP / [RNRresp] -:ABM - UP / [1]-> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / [UA]->UAWait - [SABM] / [UA]-> UAWait - [DM] / [SABM]-> SABMSend - [SABM] / [UA]->ABM - [I] /-> ABM - UP / [I] -> ABM -[BADresp] / [DM] ->ABM - [REJcmd] / [I] -> ABM - [RNRresp]/-> ABM - [RRresp]/->ABM -[UA] / [DM] ->DMSend***************************************The subpathes number is 35The subpathes areDMS end -[DM] / [SABM] -> SABMS end - [SABM] / [UA]-> SABMSend - [UA] /-> ABM - UP / [RNRresp] -:ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait -[SABM]/ [UA]->UAWait - [SABM] / [UA]-> UAWait - [DM] / [SABM]-> SABMSend - [SABM] / [UA] ->ABM - [I] /-> ABM - UP / [I] -> ABM -[BADresp] / [DM] ->ABM - [I] /-> ABM - UP / [I] -> ABM -[BADresp] / [DM] ->DMSend***************************************85The subpathes number is 36The subpathes areDMSend - [DM] / [SABM]-> SABMSend - [SABM] / [UA] -> SABMSend - [UA] /-> ABM - UP / [RNRresp] -ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / [UA] ->UAWait - [SABM] / [UA]-> UAWait - [DM] / [SABM]-> SABMSend - [SABM] / [UA]->ABM - [I] /-> ABM - UP / [I] -> ABM -[BADresp] / [DM] ->ABM - [I] /-> ABM - UP / [I] -> ABM -[BADresp] / [DM] ->DMSend***************************************The subpathes number is 37The subpathes areDMSend - [DM] / [SABM]-> SABMSend - [SABM] / [UA]-> SABMSend - [UA] /-> ABM - UP / [RNRresp] -:ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / [UA]->UAWait - [SABM] / [UA]-> UAWait - [DM] / [SABM]-> SABMSend - [SABM] / [UA] ->ABM - [I] /-> ABM - UP / [I] -> ABM -[BADresp] / [DM] ->ABM - [I] /-> ABM - UP / [I] -> ABM -[BADcmd] / [FRMR]->ABM -[FRMR] / [SABM] -> UAWait - [SABM] / [UA]-> UAWait - [UA] / [DM] ->ABM - [I] /-> ABM - UP / [I] -> ABM -[BADcmd]/ [FRMR]->ABM - [FRMR] / [SABM]-> UAWait - [DM] / [SABM]-> SABMSend - [SABM] / [UA] ->SABMSend - [UA] /-> ABM - [I] /-> ABM - UP / [I] ->SABMWait - [UA] / [DM] ->DMSend***************************************The subpathes number is 38The subpathes areDMSend - [DM] / [SABM]-> SABMSend - [SABM] / [UA]-> SABMSend - [UA] /-> ABM - UP / [RNRresp]-:ABM - UP / [I] -> ABM - [BADresp]/ [DM] -> SABMWait - [SABM] / [UA]->UAWait - [SABM] / [UA]-> UAWait - [DM] / [SABM]-> SABMSend - [SABM] / [UA] ->ABM - [I] /-> ABM - UP / [I] -> ABM -[BADresp] / [DM] ->ABM - [I] /-> ABM - UP / [I] -> ABM -[BADcmd] / [FRMR]->ABM - [FRMR] / [SABM]-> UAWait - [SABM] / [UA]-> UAWait - [UA] / [DM] ->ABM - [I] /-> ABM - UP / [I] -> ABM -[BADcmd]/ [FRMR]->ABM - [FRMR] / [SABM]-> UAWait - [DM] / [SABM]-> SABMSend - [SABM] / [UA] ->SABMSend - [UA] /-> ABM - [I] /-> ABM - UP / [I] ->SABMWait - [UA] / [SABM]->DMSend***************************************86The subpathes number is 39The subpathes areDMSend - [DM] / [SABM]-> SABMSend - [SABM] / [UA]-> SABMSend - [UA]/-> ABM - UP / [RNRresp] -ABM - UP / [I] -> ABM - [BADresp] / [DM] -> SABMWait - [SABM] / [UA] ->UAWait - [SABM] / [UA] -> UAWait - [DM] / [SABM] -> SABMS end - [SABM]/ [UA]->ABM - [I] /-> ABM - UP / [I] -> ABM -[BADresp] / [DM] ->ABM - [I] /-> ABM - UP / [I] -> ABM -[BADcmd] / [FRMR]->ABM -[FRMR] / [SABM]-> UAWait - [SABM] / [UA] -> UAWait - [SABM] / [UA] ->DMSend***************************************The subpathes number is 40The subpathes areDMSend - [DM] / [SABM] -> SABMSend - [SABM] / [UA]-> SABMSend - [UA]/-> ABM - UP / [RNRresp] -ABM - UP / [I] -> ABM - [BADresp] /[DM] -> SABMWait - [SABM] / [UA] ->UAWait - [SABM] / [UA]-> UAWait - [SABM] / [UA]-> UAWait - [DISC] /[DM] ->DMSend***************************************87Appendix CLAPB test cases and validationresults for DL1DL1_101:DataIndicat DISC A 1 - - - / DataRequest DM A 1 - - - / -passDL1_102:DataIndicat DISC A 0 - - - / DataRequest DM A 0 - - - / -failureDL1_103:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndpassDL1_104:DataIndicat SABM A 0 - - - / DataRequest UA A 0 - - - / -DataIndicat SABM A 0 - - - / DataRequest DM A 0 - - - / -failureDL1_201A:DataIndicat DM A 1 - - - / DataRequest SABM A 1 - - - /failureDL1_201B:88DataIndicat DM A 1 2 0 9 / Discard ^passDL1_202:DataIndicat SABM E 1 - - - / DiscardpassDL1_203:DataIndicat SABM A 1 9 0 5 / DiscardpassDL1_204:DataIndicat DM A 1 0 0 0 / DiscardpassDL1_205:DataIndicat DM A 1 9 0 9 / DiscardpassDL1_207:DataIndicat SABM A 1 9 0 9 / DiscardpassDL1_208:DataIndicat UA A 1 9 0 9 / Discard^/passDL1_209:DataIndicat RR A 1 9 0 9 / DiscardpassDL1_210:DataIndicat BNR A 1 9 0 9 / DiscardpassDL1_211:DataIndicat REJ A 1 9 0 9 / Discardpass///89DL1_216:DataIndicatIEEE0E/ DiscardpassDL1_216:DataIndicat DISC A / 9 0 9 / DiscardpassDL1_301:DataIndicat I A 1 - - - / DataRequest DM A 1 - - - /passDL1_302:DataIndicat RR A 1 - - - / DataRequest DM A 1 - - - / -failureDL1_303:DataIndicat RNR A 1 - - - / DataRequest DM A 1 - - - / -passDL1_304:DataIndicat REJ A 1 - - - / DataRequest DM A 1 - - - /passDL1_306:DataIndicat UA A 0 - - - / DiscardpassDL1_306:DataIndicat UA A 1 - - - / DiscardpassDL1_307:DataIndicat FRMR A 0 - - - / DiscardpassDL1_308:90DataIndicat FRMR A 1 - - - / Discard ^passDL1_309:DataIndicat I A 0 - - - / DiscardpassDL1_310:DataIndicat RR A 0 - - - / DiscardpassDL1_312:DataIndicat REJ A 0 - - - / DiscardpassDL1_313:DataIndicat RR A 1 - - - / DiscardpassDL1_314:DataIndicat RNR A 1 - - - / DiscardpassDL1_315:DataIndicat REJ A 1 - - - / DiscardpassDL1_316:DataIndicat RR A 0 - - - / DiscardpassDL1_317:DataIndicat RNR A 0 - - - / DiscardpassDL1_318:DataIndicat REJ A 0 - - - / Discardpass91DL1_319:DataIndicat I A 0 - - - / Discardpass92Appendix DLAPB test cases and validationresults for DL2DL2_101:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat DISC A 0 - - - / DataRequest UA A 0 - - - / -passDL2_102:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat DISC A 1 - - - / DataRequest UA A 1 - - - / -failureDL2_106:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat SABM A 0 - - - / DataRequest DM A 0 - - - / -passDL2_106:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDisReq ^ / DataRequest DISC B 1 - - - / -DataIndicat SABM A 1 - - - / DataRequest DM A 1 - - - / -93passDL2_109:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat DM A 1 - - - / Discard ^ / -passDL2_110:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat DM A 1 - - - / Discard ^ /passDL2_111:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat UA A 1 - - - / DiscIndpassDL2_201A:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat BAD E 0 - - - / Discard ^ /passDL2_201B:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat DM A 1 - - - / Discard ^ / -passDL2_205:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat DISC A 1 9 0 9 / Discard ^ / -pass94DL2_207:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat SABM A 1 9 0 9 / Discard ^ / -passDL2_209:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat UA A 0 9 0 9 / Discard ^ /passDL2_211:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat DM A 0 9 0 9 / Discard ^ /passDL2_219:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B / - - - / -DataIndicatIAFHHH/ Discard ^ / -passDL2_221:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat RR B 1 - - - / Discard ^ /passDL2_223:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat BNR B 1 - - - / Discard ^ /passDL2_225:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConInd95DiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat REJ B 1 - - - / Discard ^ / -passDL2_227:DataIndica t SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq  ^/ DataRequest DISC B 1 - - - / -DataIndica t DISC F 0 - - - / Discard ^ / -passDL2_229:DataIndicatDiscReq ^DataIndicatpassSABM A 1 - - - / DataRequest UA A 1 - - - / ConInd/ DataRequest DISC B 1 - - - / -DISCAOFFF/ Discard ^ / -DL2_231:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / dataRequest DISC B 1 - - - / -DataIndicat DM A 0 - - - / Discard ^ /passDL2_234:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat UA A 1 - - - / Discard ^ /passDL2_306:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / conIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat RR A 1 - - - / Disccard ^ / -passDL2_308:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat RR A 0 - - - / Discard ^ / -96passDL2_310:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat RNR A 1 - - - / Discard ^ /passDL2_312:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat RNR A 0 - - - / Discard ^ /passDL2_314:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat REJ A 1 - - - / Discard ^ /passDL2_316:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat REJ A 0 - - - / Discard ^ / -passDL2_318:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -Dataindicat FRMR A 0 - - - / Discard ^ /passDL2_332:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat FRMR A 1 - - - / Discard ^ / -pass97DL2_334:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat I A 0 0 0 0 / Discard ^ / -passDL2_336:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat I A 1 0 0 0 / Discard ^ /passDL2_338:DataIndicat SABM A 1 - - - / DataRequest UA A 1 - - - / ConIndDiscReq ^ / DataRequest DISC B 1 - - - / -DataIndicat I A 0 - - - / Discard ^ /passBibliography[1] W.Y.L.Chan,S. T. Vuong, and M. It. Ito,"An improved Protocol Test Generation ProcedureBased on UI0s " Proceedings of the ACM SIGCOMM '89 Symposium on CommunciationArchitecture and Protocols, 1989.[2] J.P. Wu and S. T. Chanson,"Test Sequence Derivation Based on External Behaviour Ex-pression" 2nd Internal Workshop on Protocol Test System , Germany, 1989.[3] ISO Transport Protocol Specification ISO DP 8073, 1984.[4] International Organization for Stansardization"The Tree and Tabular Combined Notation"ISO 9646 , 1989.[5] Information Processing system, "Open System Interconnection -Specification of AbstractSyntax Notation One" ISO 8824, September, 1987[6] Information Processing System, "Open System Interaction - Estelle- A Formal DescriptionTechnique Based on an Extended State Transition Model," IS 9074, 1989.[7] Roelof J. Velthuys, "Protocol Conformance Testing with Communciation Rule System,"IBM European Networking Center, 1989.[8] ISO DIS 9646 " OSI Conformance Testing Methodology and Framework", March, 1989.[9] M. Sample and G. Neufeld, "Support for ASN.1 within a Protocol Testing Enviroment",The third International Conformance on Formal description Techniques, Madrid Spain,November, 1990.[10] II. Janssen, Y. Lu and P. Zhou, "Definition of a Protocol Data Structure Representationfor Communciation Protocols", UBC Technical Report planned for summer, 1991[11] JingLu "Lapb Estelle specification", 1990[12] Russel Vuong "Lapb Estelle specification", 1989[13] U. Bar, J.M.Schneider, "Automated Validation of TTCN Test Suites" IBM European Net-working Centre99[14] Kshirasagar Naik, Behect Sarikaya, "Verification of Protocol Conformance Test Cases Us-ing Reachability Analysis" Dept. of Electrical and Computer Eng. Concordia University,Dept. of Computer Science and Operation Research, University of Montreal[15] M.C.Kim, Samuel T. Chanson and Son T. Vuong "Protocol Trace Analysis based on FormalSpecification" Department of Computer Science, University of British Columbia100

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
https://iiif.library.ubc.ca/presentation/dsp.831.1-0051208/manifest

Comment

Related Items