软件学报
JOURNAL OF SOFTWARE
2000　Vol.11　No.4　P.427-434




基于形式化方法的因特网路由协议的一致性测试
毕军　吴建平
摘要　 并发数表组合表述法(并发TTCN)是可以描述并发测试行为的测试表述法.该文提出一种基于并发TTCN的分布式路由协议的测试方法.首先讨论路由协议实体的测试结构，然后给出基于并发TTCN测试系统的设计.最后介绍了测试集的设计.
关键词　一致行测试，分布式系统，路由协议，因特网，并发数表组合表述法.
中图法分类号　TP393
　A Formal Approach to Conformance Testing of Internet
Routing Protocols 
BI Jun　WU Jian-ping
　（Department of Computer Science and Technology　Tsinghua University　Beijing　100084）
　Abstract　　Concurrent TTCN (tree and tabular combined notation) is a test notation that can handle concurrent test behaviors. This paper proposes an approach to the conformance testing of distributed routing protocols based on concurrent TTCN. It first discusses the test architecture for the routing protocol entity, and then the concurrent TTCN based test system design is presented. Finally, this paper introduces the test suite design. 
　Key words　Conformance testing, distributed system, routing protocol, internet, concurrent TTCN. 
　　OSPF now is the most important routing protocol and is widely used in the Internet. The quality of the OSPF products would influence the stability of networks and it is really necessary to give the conformance test assessment of OSPF routers. However, the routing functions are realized by the cooperation of distributed routers. Then how to formally specify and test the concurrent behaviors of OSPF router is a challenge to the traditional protocol test methods and test systems. In Refs.[1,2], some problems of conformance testing in distributed systems were studied. The entity in distributed systems is more complex and general than traditional peer-to-peer protocol entity. An entity in distributed systems is associated with a set of interaction points and a set of concurrent behaviors at these interaction points. In this paper, we present a specification model called concurrent external behavior expression (CEBE) to specify the entity. CEBE could directly specify the concurrent external behaviors at different interaction points of an entity and reduce the internal states, actions and data. Therefore it is an ideal model to formally specify the entity in a complex distributed system and to generate concurrent TTCN (C-TTCN) test suite. Moreover, we formally define test system based on C-TTCN operational semantics. The above methods have been put into practice by using an integrated test system PITS and an automatic test generation tool TUGEN to test CISCO 4700 router. 
　　The rest of this paper is organized as follows. In Section 1, we give out the abstract test architecture. Then we discuss the test system design and test suite generation in Sections 2 and 3 respectively. Finally, we conclude this paper in Section 4.
1　Abstract Test Architecture
　　The Tree and Tabular Combined Notation (TTCN) is recommended by ISO to describe abstract test suite. C-TTCN is an extension of TTCN, that allows the test system to execute a test case by several test components (TCs) running in parallel. A tester consists of exactly one main test component (MTC) and any number of parallel test components (PTCs). TCs are linked by coordination points (CPs) capable of conveying coordination messages (CMs). Communications of TCs with the environment are through the points of control and observation (PCOs). C-TTCN is very suitable for the specification of a system consisting of several testers, while this is the common case in routing testing. The test architecture is a description of the environment in which IUT (Implementation under Test) is tested. For a router entity, there are k concurrent behaviors which happen at interaction points. If and only if all these behaviors conform to the behaviors of its specification, it is a conformance implementation. Then the test architecture should deal with these concurrent behaviors at several interaction points. We construct the abstract test architecture according to this feature. It consists of a test system, an entity under test, a test context, several PCOs and several interaction points. The test system is the implementation of a test suite written in C-TTCN. It carries out the experiments by executing test cases and observing results. The interactions of the IUT with its environment take place at interaction points (IPs). The test system communicates with the IUT indirectly: through the test context. The points, where the tester communicates with the test context and in this way indirectly controls and observes the IUT, are called the Points of Control and Observation (PCOs). Execution of a test case starts with the execution of MTC. It is the concern of MTC to set up all PTCs, and to manage all PCOs and CPs to be connected to. PTCs can be created by MTC on demand. A ‘create’ operation associates a PTC with a behavior tree. The newly created PTC starts execution of its assigned behavior tree concurrently with MTC. MTC may explicitly terminate a PTC by executing a ‘down’ operation.
2　C-TTCN Based Test System 
2.1　Preliminaries
　　Definition 2.1. A Labeled Transition System (LTS) is a 4-tuple 〈S,L,T,s0〉. (1) S is a countable, non-empty set of states. (2) L is a countable set of observable events. (3) TS×(L∪{τ})×S is a set of transitions, where τ denotes an unobservable event. Element (s,u,s′) in T can also be written as:where s, s′∈S, u∈L∪{τ}. (4) s0∈S is the initial state. 
　　 We use LTSs(L) to denote the set of all possible labeled transition systems over L. Trace is a common concept in LTS, Definition 2.2 gives out its definition and some useful notation. 
Definition 2.2. Let 〈S,L,T,s0〉 be an LTTS. L′=L∪{τ} contains all observable and unobservable events. s,s′, s1,s2,...,sn,sn+1∈S, u1,u2,...,un∈L′. Let σ=u1。u2。．．．。un be a sequence of labels in L′. ‘。’ denotes concatenation, then σ is said to be a trace over L′. L′* denotes the set of all possible traces over L′. We further have the following notations:
　　。
　　。 if is the concatenation of zero or more τ;
　　
　　In LTS model, events in L are treated in the same way no matter what they mean. In order to distinguish input events from output events, a kind of LTS called input-output transition system is introduced.
Definition 2.3. An Input-Output Transition System (IOTS) p is an LTS in which the set of events L is partitioned into input events Li and output events Lo, where elements in Li are events accepted by this LTS from its environment, and elements in Lo are events sent to its environment by this LTS. IOTS p satisfies: p∈LTSs(L), L=Li∪Lo and Li∩Lo=Φ. IOTSs(Li,Lo) represents the set of all possible input-output labeled transition systems over input events Li and output events Lo. IOTSs(Li,Lo)LTSs(Li∪Lo).
　　Definition 2.4. Input-queue operator is a unary operator ［。］σi:IOTSs(Li,Lo)→IOTSs(Li,Lo), where σi∈Li. Let TS∈IOTSs(Li,Lo), then ［TS］σi is defined by the axiom A1 and inference rules I1,I2 and I3:

　　We will name [S]σi as the Input-Buffered TransitionSys tem (IBTS).For a common communication system ,we can model its behavior by only one Input-Buffered Transition System.While considering communication systemwhose function is performed by several concurrents parts ,we need a group of IBTSs to model its beheviors.Then we introduce a formal definition of communication system in teh following.
Definition 2.5. A communication system consisting of n concurrent entities can be modeled by an IOTS Σ: 〈SΣ,{Ext}×N×LΣ,i∪N×{Ext}×LΣ,o,Tr,sΣ,0〉, where (1) SΣ is the state set of this IOTS, element in SΣ can be represented by 〈s1,s2,...,sn〉, where 1≤i≤n, si is the state of i-th IBTS that is defined over input actions ID×ID×Li and output actions ID×ID×Lo, ID={Ext,1,2,...,n}; (2) LΣ,i, LΣ,o are the set of input actions and the set of output actions of this communication system respectively; (3) Ext is the identification of the outside environment of this communication system; (4) N={1,2,...,n}, each number in N represents an IBTS; (5) sΣ,0 is the initial state, sΣ,0=〈s1,0,s2,0,...,sn,0〉, si,0 is the initial state of i-th IBTS; (6) Transitions set Tr is inferred from the following axiom and rules:

2.2　The C-TTCN based test system design
　　We will use “communication system” in definition 2.5 to formally describe the interaction between test system and IUT. To design the C-TTCN based test system, we should study the operational semantics of C-TTCN first. In a C-TTCN test case, the behavior of each test component is expressed with a Test Behavior Tree (TBE), which is a tree-like presentation of temporal relations between test events.
　　Definition 2.6. TBE B=defstop|exit|id?a; B|id!y;B|B［］B|BB|［q］;B|(I:=val);B|(B)| start tid val; B| cancel tid; B｜ timeout tid; B| create id B| done id.
　　Definition 2.7. A Test Component (TC) is a virtual machine that can perform the evaluation of test behavior expressions. It can be modeled by an IBTS: ［(ctl，sto)］σi. (1) ctl is a TBE specifying the behaviors of this TC. (2) sto is the test context of this test component, sto={(i,v)|(i,v)∈MEM=Ident×Value}. Ident and Value are the sets of identifiers and values respectively. Elements in sto are pairs of identifier and value, each element corresponds to a variable or constant in test suite and its value. (3) σi is the input-buffered queue of this test component. The initial state of this TC is TC0=［(TBETC,sto0)］ε, where TBETC is the complete behavior specification of this TC. sto0 denotes the initial situation of the test context and ε represents that the input-buffered queue is empty.
　　Definition 2.8. A Test System (TS) is a system that can perform the evaluation of a test case specified in C-TTCN. It contains one main test component and zero or more optional parallel test components. Its running can be modeled by a communication system: 〈STS,{Ext∪Tim}×N×LTS,i∪N×{Ext∪(Tim}×LTS,o,Tran,sTS,0〉 where (1) the state of TS in STS is the combination of the states of n test components: 〈TC1,TC2,...,TCn〉, TCi represents the state of test component i, TCi=［(TBEi,sto)］σi; (2) sTS,0 is the initial state of this TS, sTS,0=〈TCi,0|1≤i≤n〉, where TCi,0 is the initial state of test component i; (3) the set of input actions of this TS is {Ext∪Tim}×N×LTS,i, and the set of output actions is N×{Ext∪Tim}×LTS,o; (4) identifier Ext represents the outside environment of this test system; (5) Tim represents the timing system; (6) N is the set of natural number {1,2,..,n} which is used to identify each test component and τ denotes unobservable actions; (7) Tran is the set of transitions that are defined by the following axioms and reference rules:




　　For the convenience of discussion, we suppose that systems under test can also be modeled by a communication system. When testing, it consists of many interfaces connected to the test system.
Definition 2.9. The system under test (SUT) is a communication system Σ that consists of lots of Input-Buffered Transition Systems. Σ is denoted by 〈SSIUT,{Ext}×N×LTS,o∪N×{Ext}×LTS,i,Tran,sSUT,0〉, where: (1) the state of Σ is obtained from the states of two IBTSs, sSUT=〈sIUT1,sIUT2,...,sIUTn〉, where sIUT1,sIUT2,...,sIUTn are the states of the behaviors at each interaction point, respectively; (2) the initial state of Σ is sSUT,0=〈sIUT1,0,sIUT2,0,...,sIUTn,0〉, where sIUT1,0,sIUT2,0,...,sIUTn,0 are the initial states of the behaviors at each interaction point, respectively; (3) the set of input actions to Σ is {Ext}×{1,...,n}×LTS,o, corresponding to the output actions from TS; (4) the set of output actions from Σ is {1,...,n}×{Ext}×LTS,i, corresponding to the input action to TS, τ is an unobservable action; (4)Tran is the same as in definition 2.9.
　　The testing process can be described by synchronous communications between TS and SUT. We use a synchronous operator ‘‖’ to express that when TS (or SUT) sends out an action, SUT (or TS) will receive it at the same time (they are synchronous at this action). We can use sTS,0‖sSUT,0 to describe the whole test execution process. The synchronous operation can be represented as follows:

　　The result of test execution is a trace σ of sTS,0‖sSUT,0 that satisfies the above operation rules.Given a test case t ,the execution result of   t in a TS defined above is a traceσ:Run(t,SUTs)=σ,where

　　The final test verdict of this case t is based on the corresponding verdict of theis traceσ.
3　C-TTCN Test Suite Generation
3.1　Basic definitions of CEBE
　　In this section, we propose an entity specification model CEBE. It is an extension of EBE presented in Ref.[3]. The essence of both EBE and CEBE is to describe the data in addition to the control behavior from the viewpoint outside the system. By eliminating the internal actions, the specification of CEBE could be obtained from ETS (the extension of ETS presented in Ref.[4]), which could be translated from LOTOS and Estelle. Therefore, the CEBE may be translated from the standard FDTs.
Definition 3.1. A CEBE is a 7-tuple 〈S,G,Σ,A,R,s0,v0〉, where: (1) S is a finite set of external states, whose elements are pause states of interactions exchanged between the entity and its external environment; (2) G is a set of gates over which a CEBE can communicate; (3) Σ is the set of data on CEBE (see below); (4) A is a set of external actions on CEBE (see below); (5) R is a set of logic relations of transitions between external states (see below); (6) s0∈S is the initial state of the entity, which represents the initial external state; (7) v0 is the set of initial assignments (initial values of all variables and timers) of Σ.
　　Definition 3.2. Σ=IO∪VAR∪CONS∪TIMER∪PARA is a set of data on CEBE, where: (1) IO is the set of input or output events (i.e., the ASPs and PDUs); (2) VAR is the set of variables (the type of variables includes integer, boolean, octetstring, bitstring and so on); (3) CONS is the set of constants (the type of constants includes integer, boolean, octetstring, bitstring and so on); (4) TIMER is the set of timers (second and microsecond); (5) PARA is the set of parameters of events in IO. For an event e∈IO, the parameters p1,p2,...,pn are denoted as e.p1,e.p2,...,e.pn, e is denoted as e(e.p1,e.p2,...,e.pn).
　　Definition 3.3. A behavior b is elements g of G with a list of input and output events and their value declaration. Then the set of b is denoted as: B={〈gi,?ri(ri.p1,ri.p2,...,ri.pn), !si(si.p1,si.p2,...,si.pn)〉|gi∈G,ri,si∈IO, ri.pi,si.pi∈PARA}, where symbol “!” indicates the output of an event si to external environment and symbol “?” indicates the input of an event ri. The absence of ri or si could be denoted as symbol “-”, for example, b=〈gi,?ri(ri.p1,ri.p2,...,ri.pn), !- 〉. Here we give some notations: (1) b1b2...bn, the behaviors are sequential; (2) b1［］b2［］...［］bn, the behaviors are equally valid alternatives (choice); (3) b1‖b2‖...‖bn, the behaviors are parallel.
　　Definition 3.4. Actions A are the set of concurrent behaviors. A={ai|ai∈A}, ai=defbj∈B|ai［］ai|aiai|ai‖ai|(ai), where the operator precedence is ‘()’>‘［］’> ‘’>‘’. 
Definition 3.5. Transition relation RS×A×S×P×PowerSet(O)×PowerSet(F) is the set of transition relations where (1) A is the set of actions; (2) S is the set of states of the CEBE; (3) P(Σ): PowerSet(Σ)→{TRUE,FALSE} is the set of predicate functions (=,≥,≤,>,<,∧,∨,┐, Timeout, etc.); (4) O(Σ): PowerSet(Σ)→PowerSet(Σ) is the set of operation functions (:=,+,-,*,/, StartTimer, CancelTimer, etc.); (5) F(Σ): PowerSet(Σ)→PowerSet(Σ) is the set of functions (i.e. max(), min(), etc.). 
　　The intuitive meaning of a transition r∈R is that if CEBE is in state s and the enabling action a is offered, then the enabling predicate p is evaluated on the current assignment of variables. When p is true, CEBE will go into a new state s′ and the environment is updated by the operation o and function f. The absence of predicate could be denoted as TRUE, absence of operation or function could be denoted as NIL. 
3.2　CEBE based test sequence derivation
　　The test sequence derivation strategy is defined as two steps: 
Step 1. Identify all possible valid IPs (interaction path). An IP is the externally observable track on which a sequence of interactions between the entity and its external environment occurs, starting from the initial external state s0 and ending at the same state. Any interaction loop (or cycle) in an IP is traveled only once. Interaction path with loop is an interaction path in which one or more loop interactions exist. 
　　Step 2. Generate SIPs (I/O Subpath) from the above IPs by checking the dependencies between transitions in each IP. An SIP is the externally observable track r1,...,rk in an IP, where: 
1. r1=〈sr1,ar1,s′r1,pr1,Or1,Fr1〉 is the first transition relation which satisfies:
a) a predicate pr1(Σpr1), and/or
　　b) a set of operations {...,or1i(Σor1i),...}, and/or
　　c) a set of functions {...,fr1i(Σfr1i),...};
　　2. rk=〈srk,ark,s′rk,prk,Ork,Frk〉 is obtained when logical relations satisfy:
　　
　　b) a predicate pk(Σprk), and/or
　　c) a set of operations {...,okj(Σorkj),...} and/or
　　d) a set of functions {...,fkj(Σfrkj),...}.
3.3　The C-TTCN test suite generation 
　　Based on the SIP, a test tree with the correctness, nondeterminstic and defense branches can be derived, and three kinds of verdicts (PASS, FAIL and INCONC) are assigned to each leaf of the test tree. The test tree can be mapped to a test case in C-TTCN. Finally, these test cases are grouped according to some rules, and are mapped to a complete test suite in C-TTCN. To understand the algorithm, here we use TBE to describe the rules for C-TTCN generation.
Rule 1. Each SIP is mapped to one C-TTCN test case.
Rule 2. In one SIP, if there are several relations r1,r2,...,rn, then attach tree i+1 to tree i.
　　TBEM: r1r2...rn
　　Rule 3. In action a of relation r, if b1b2...bn, then b1,b2,...,bn are behaviors and it is successfully completed if bi+1 happens immediately after the successful completion of bi (i=1,2,...,n-1).
　　TBEM： create P1 TBE1;start t1; (CP1?CM-1; down P1; stop) [] (timeout t1; stop)
TBE1： b1b2...bn (CPi!CM-i; stop) 
Rule 4. In action a of relation r, if b1［］b2［］...［］bn, then an alternative is matched if the behavior bi corresponding to the alternative happens first.
　　TBEM： create P1 TBE1; start t1; (CP1?CM-1; down P1; stop) [] (timeout t1; stop)
TBE1： (b1 (CPi!CM-i; stop)) [] (b2 (CPi!CM-i; stop))[]...[](bn(CPi!CM-i; stop)
Rule 5. In action a of relation r, if b1‖b2‖...‖bn, then b1,b2,...,bn are started in parallel and the parallel tree completes only if b1,b2,...,bn complete. 
　　TBEM： create P1 TBE1; ... ; create Pn TBEn; start t1; (CP1?CM-1; down P1; start t2;(...; (CPn?CM-n; donePn; stop) [] (timeout tn; stop));...) [] (timeout t2; stop) []...[] (CPn?CM-n; down Pn;start t2;(......) [] (timeout t2; stop)) [] (timeout t1;stop)
　　TBEi： bi(CPi!CM-i;stop)
　　Rule 6. In each behavior b of action a in a relation r, there exists 〈gi,?ri(ri.p1,ri.p2,...,ri.pn),!si(si.p1,si.p2,...,si.pn) 〉, then
　　TBEi: gi!ri;gi?si; CP1!CM-1; stop 
Rule 7. In the declaration part, the timer, variable and constant could be mapped from TIMER, VAR, and CONS with the initial value from v0.
　　Rule 8. In declaration part, ASP, PDU could be mapped from IO with parameters PARA for the events.
　　Rule 9. In constraint part, the timer, variable, ASP and PDU could be mapped from each event ei (ei.p1,ei.p2,...,ei.pn) in b with the values of parameters.
4　Conclusions
　　In this paper, we use C-TTCN to meet the needs of OSPF routing protocol testing. The real testing is accomplished by an integrated test system PITS over Sun workstation and with Solaris operating system. PITS is a general system with C-TTCN operational schematics based test execution. In future, we would perform more real tests to verify our methods, test generation tool and test system. The CEBE and C-TTCN based concepts and method in this paper may be further used in the area of conformance testing in distributed systems. For example, CEBE could be used to model most entities in OSI, TCP/IP and ODP. 
毕军（清华大学计算机科学与技术系 北京 100084）　
吴建平（清华大学计算机科学与技术系 北京 100084）
References
1，Pickin S et al. An approach to the validation of open object-based distributed applications. In: Baumgarten B ed. Testing of Communicating Systems. London: Kluwer Academic Publisher, 1996,9:115～121
2，Wong A C Y, Chanson S T, Cheung S C et al. A framework for distributed object-oriented testing. In: Higashino T ed. Formal Description Techniques. London: Kluwer Academic Publisher, 1997,10:39～56
3，Wu J, Chanson S T. Testing sequence derivation based on external behavior expression. In: Chanson S T ed. IFIP International Workshop on Protocol Test Systems. Norh-Hollan: Chap & Hall, 1989
4，Wu J, Chanson S T. Translation from LOTOS and Estelle specifications to extended transition system and its verification. In: Hogrefe D ed. IFIP International Conference on Formal Description Techniques for Distributed Systems. North-Holland: Chap & Hall, 1989
