Design of simplified protocol converters through protocol complementation

Design of simplified protocol converters through protocol complementation

Subir Das, P. Dhar*

Department of Electronics and Electrical Communication Engineering, Indian Institute of Technology, Kharagpur 721 302, India

Received 20 October 1995; revised 31 January 1996; accepted 3 February 1996

Abstract

This paper presents an approach, called the complementation approach, to synthesize protocol converters from its service specification.We describe the design procedure systematically and discuss the end results with other existing conversion procedures. An example is used toillustrate the method. The converter is also implemented and verified using a semiautomatic Estelle-C compiler.q 1997 Elsevier ScienceB.V.

Keywords:Protocol converters; Complementation

1. Introduction

Over the last decade most of the practical protocol con-verters have been designed by the protocol conversiontechnique. In fact, protocol conversion is a part of protocolinterworking. Green [1,2] first rightly pointed out the impor-tance of protocol conversion and suggested some possibleways to design a converter. Following Green a chain offormal methods have been proposed in the literature[3–6,1,7–15] for constructing converters. Some methodshave been based on PDU-level (protocol data unit) orbottom up [1,8,11,15] and some others are the SDU-level(service data unit) or top down [4,16] approach. Both tech-niques have some merits and demerits. Due to the complex-ity of the problem and the number of issues that have to bedealt with, the interconnection of networks has been per-formed by designing a gateway in an ad hoc fashion [3,15].However, the generation of gateways from formal specifi-cations has several advantages in spite of the nonavailabilityof proper formal methods for it [11,16].

Recently, it has been proved [17] that existing protocolconversion techniques are not sufficient to solve the inter-networking problems though it has been recognized as away to achieve interoperability for quite a long time. Weargue that a formal specification model which can combinethe communicating finite state machine (CFSM) model witha powerful programming language is more suitable. Theconverters designed by these methods must be specifiedcompletely and precisely and implemented correctly for a

system to work properly. The complexity of the existingapproaches are mostly exponential except in one case[16]. Here the authors have developed a polynomial timealgorithm for generating converters. For this reason, a newapproach calledprotocol complementation[6,18–20] isadopted here. It is an approach to protocol interworking inwhich a virtual layer is needed to provide a uniform view tothe users.

In this paper, we present a complementation procedureand algorithm that computes protocol converters fromformal specification. The approach describes the systematicway to generate the new virtual layer and hence theconverter between two protocols from their service specifi-cations. To illustrate the procedure, the interworkingbetween alternating bit (AB) and nonsequenced protocolhas been chosen for an example.

The rest of the paper is organized as follows: Section 2describes the formalization onprotocol complementationwhile Section 3 gives the systematic procedure for con-verter design. In Section 4 we giveprotocol complementa-tion results with an example; finally Section 5 contains adiscussion.

2. Formalization on protocol complementation

A protocol consists of interacting processes, each ofwhich is represented by a communicating finite statemachine (CFSM) [21,22]. These CFSMs are communi-cating asynchronously by exchanging messages via con-necting channels (mostly unbounded FIFO (First In FirstOut) channels).

Computer Communications 20 (1997) 528–534

0140-3664/97/$17.00q 1997 Elsevier Science B.V. All rights reservedPII S0140-3664(97)00055-8

* Corresponding author. E-mail: [email protected]

2.1. Definition

2.1.1. Model of protocolA protocol [9] P〈P1,P2,...,Pn〉 is a quadruple

〈SNi ,M( þ =¹ )

ij , dij ,qi 〉whereN is a positive integer, which represents the numberof processes,Si is a nonempty finite set, i.e., set of states ofprocessi, i [ [1,N], Mij is the finite message set withMii

empty for all i, i [ [1,N], Mij represents the messages thatcan be sent from processi, i [ [1,N], to j, j [ [1,N]; d ij is apartial function mapping for eachi and j

Si 3 M( þ =¹ )ij → Si andSi 3 M( þ =¹ )

ji → Si

whereqi is the initial state of the processi, d(S, 6 X) is thestate entered after a process transmits or receives messageXin the stateS. The superscript ‘þ’ means receiving a mes-sage and ‘¹’ means sending a message.Si always refers to astate in processi, i.e., to a member ofSi. Similarly Xij refersto a member ofMij, i.e., a message can be sent from processi to processj.

The transition functiond can be extended to a sequenceXof message in the usual way, viz.

d(S,f) ¼ S; wheref denotes an empty sequence

d(S,xY) ¼ [d(d(S,x), Y)]; wherex andY are messagesand message sequence respectively

The message sequence or path can also be defined as

Path(P) ¼ Yl'd(x, q0);

whereq0 is the initial state.

2.2. Projection of a tracePd(t)

The projection of a trace into an operation setd denotedby Pd(t) is a subtrace oft which contains only the operationfrom d. The restricted sequencePd(t) is defined as follows:

Pd(F) ¼ F; whereF is a null or empty trace

Pd(t : X) ¼ [Pd(t)] ¼ X; if X [ d

¼ [Pd(t)]; otherwise

2.3. Significant operation setDs

An operation involving a significant message is called asignificant operation and the set of such operations consti-tute the significant operation setDs.

2.4. Range of tracePDs(t)

The projection of a tracet onto the significant operationsetDs writtenPDs

(t) is called the range of the tracet denotedby t r, i.e.,tr ¼ PDs

(t). It is to be noted that the range of a traceis again a trace andt r is a subtrace oft, i.e., t r $ t.

2.5. Syntax and semantics

Protocols, like languages, may be described in terms ofthese components [11,23,24]. The syntax of a protocoldefines the rules how one may construct a message from agiven set of all allowed messages and the semantics definethe meaning of each message segment or a sequence ofmessages, i.e., allowed sequences of message exchanges[17].

3. Converter design and procedure

3.1. Protocol complementation approach

Protocol complementation[6,18,20] is an approach toprotocol interworking which is related to the layering ofcommunication protocols. For protocolP〈P1,P2,...,Pn 〉 of alayer in one network that has to interwork with protocolQ〈Q1,Q2,...,Qn〉 of a layer in another network, a virtuallayer can be added on top ofP andQ to provide a uniformview to the users. Users on both the networks need not beaware of the fact that there are different networks in thesystem. The virtual layer is constructed from the originalprotocols so that when we add on or project the transitionsequences of the virtual layer onto any of the original proto-cols, we will get a subset of transition sequences of thatprotocol [16,18]. So the protocol complementation consistsof using additional layers, adding protocol functions, e.g.,splitting, segmenting, sequencing, window size, etc. Gate-ways still need to be inserted between the networks whicheffectively implement the uniform view of the virtual layer.Access protocols may be changed for users in both net-works which essentially leads to opaqueness. In order toestablish communication between the two subnets throughcomplementation the following conditions must besatisfied:

1. above the layer of interconnection the same protocol hasto be used, and

2. protocols must have some common functionality at thebeginning.

So a network structure dictates the choice of the layer atwhich the complementation is to be made. Fig. 1 depicts thescenario of networks in which the internetworking is madebetweenNx and My layer protocols of networks 1 and 2.Note that networks 1 and 2 obey different architecturesand Nx is not necessarily equal toMy. The complexity ofthe problem depends upon the mismatches between theprotocols as well as the type of service expected and pro-vided. Here the degree of overlap between the set of servicesprovided at levelsNx andMy indicates the extent to which acomplementation can be made. Another important issuewhich has to be considered is whether the common servicesubset of two layers is effective enough to provide usefulservices if a complementation is made.

529S. Das, P. Dhar/Computer Communications 20 (1997) 528–534

3.2. Protocol complementation rules

To design the gateway for protocol complementation onehas to follow certain rules which we call the complementa-tion rules. The rules are simple and can be easily applied tothe state transition graph of CFSMFi since they have beendescribed in a set of production rules. If CFSM specifica-tions of two protocolsP[Ps,Pr] andQ[Qs,Qr] are given, thenthe following steps must be followed before transformingthe CFSM to a new complemented CFSM.

• Step 1: study the original protocols and figure out thetranslation rules, i.e., the semantics of the translationbetween transitions in different networks.

• Step 2: represent the set of production rules in a sys-tematic way.

A significant state pair consists of two states such thatthey are connected to each other by significant transitions oredges only. The functionally similar types of messages canalso be put to a set of states called matched pair sets. Duringeach step of complementation the CFSMFi is enhanced byone or more state(s) with the addition of at least one or moresignificant state(s).

3.3. Procedure for complementation

If X1 andX2 are two states in the CFSMFi such that alltransitions betweenX1 andX2 are labelled with significantoperations, then perform the following to obtain the com-plemented machineFi9.

(a) find out functionally similar states in the corre-sponding sender (receiver) CFSMFj ;(b) add X1 and X2 to the CFSM Fj such that thesequence of messages or traces of the machine is pre-sented. The new machine isFj9;

(c) similarly add the message set of CFSMFj, e.g.,Y1

andY2 to the CFSMFi in the same way and the newmachine will beFi9;(d) delete all insignificant self loops associated withX1

and X2 or Y1 and Y2 and keep all the significant selfloops inFi9 or Fj9 in the proper order;(e) merge the states in the complemented machine thathave the same or similar type of ingoing and outgoingedge to a single state;(f) copy other states and performFi to Fi9 andFj to Fj9;(g) addFi andFj to get final machine;(h) check the machine with respect to the given set ofsignificant transitions.

Starting with the initial state we apply the rule recursivelyuntil we get a complemented machine which containsalmost all significant states or matched set pairs with mini-mum number of states and in conformance with the rulespecified. The syntax and semantics of the original machinemust be preserved in the final machine.

3.4. Algorithm

Given two heterogeneous protocolsP[Ps,Pr] andQ[Qs,Qr] to construct a protocol for the virtual layer andhence the converter between the sender entityPs andreceiver entityQr, the algorithm is given below.

• Input:

(1) CFSM specification of protocolsP[Ps,Pr] andQ[Qs,Qr] and(2) significant message set.

• Output: a single CFSMRPQ between protocol processesPs andQr.

• Method: this consists of the following steps:

Fig. 1. Scenario of internetworking.

530 S. Das, P. Dhar/Computer Communications 20 (1997) 528–534

(a) determine the significant message(s) from the exist-ing message sets, i.e.,Dsi

$ M( þ =¹ )i 3 (SPr

∪ SQs);

(b) check whether DSicontains at least one

element from both Pr and Qs, i.e., ifS9 ¼ (DSi

∩ SPr) or S0 ¼ (DSi

∩ SQs) is null, then either

redo from the beginning, if possible, or go to the endstep;(c) add on or project the significant message(s) ontoprotocol CFSMPr to form complemented CFSMPr9according to the semantic specifications, i.e.,Pr 9 ¼PD(Pr);(d) similarly add on the significant message(s) ontoprotocol CFSMQs to form complemented CFSMQs9,i.e., Qs9 ¼ PD(Qs);(e) combinePr9 andQs9 to form the composite CFSMRPQ;(f) refineRPQ subject toDSi

(significant message set) toobtainRFPQ;(g) if RPQ or RFPQ is a null CFSM then declare that theconverter is not found and go to next step;(h) outputRFPQ as the desired converter or machine;(i) stop.

• End of algorithm.

A pseudo-Pascal procedure for the algorithm is given inAppendix A.

4. An example

As an aid to understanding our method we pose a simpleexample problem which involves a mismatch in deliveringdata. Alternating bit (AB) protocol, [Ps,Pr], and a protocolthat does not use any sequence numbers, called the non-sequenced (NS) protocol [Qs,Qr] have been chosen for thesame. For the example problem it is desired to transfer datafrom an AB sender, i.e.,Ps to an NS receiverQr. The proto-col specifications are shown in Figs. 2 and 3, respectively.The ‘acc’ (acceptance) and ‘del’ (delivery) events modelinteraction with the user. The AB sender (Ps) attaches aone-bit sequence number to each data unit transmitted,e.g., d0 and d1. ReceiverPr uses this number to synchronizewith the sender and determine whether a received datamessage has already been delivered. An acknowledgmentmessage, containing the sequence number of the last delivereddata message (a0 or a1), is returned for each data messagereceived. The NS protocol has no sequence numbers. ThereceiverQr simply delivers every data message, and returnsan acknowledgment message A. The senderQs repeatedlytransmits the data until an acknowledgment is received. Ifan acknowledgment is lost, the same message may be deliv-ered several times by the receiver of the NS protocol.

4.1. Converter synthesis via complementation

Complementation can be considered as a solution to aprotocol hard mismatch to soft mismatch when the protocolsprovide some common functionality at the beginning.Suppose protocolsP and Q can be complemented andeach be projected onto another protocolRPQ which embodiesthe functionality that is common toP andQ. RPQ defines asemantic correspondence between states ofP and Q whichgoverns the new virtual layer for protocol complementation.In order to get the complemented protocol one has to write thesyntax and semantics of the protocol very carefully. Inour example, the syntax ofP[Ps,Pr] and Q½Qs;Qr ÿ

are 〈(acc),(d0),(ls),(a0),(tm),(a1),(d1),(d0,a0),(d0,a0,acc),(d1,a1), (del,¹ tm),(D),(Ls),(Tm),(D,A),(acc,Ls),...〉.

Fig. 2. Alternating bit protocolP[Ps,Pr].

Fig. 3. Nonsequenced protocol [Qs,Qr].


The semantics ofP andQ are:

1. send d0 to AB;2. if d0 is not accepted or time-out (tm) occurs

then send lselse send a0;

3. convert d0 to D and send D to NS;4. if D is not accepted or time-out (tm) occurs

then send Lselse send A;

5. send d1 to AB;6. if d1 is not accepted or time-out (tm) occurs

then send lselse send a1;

7. convert d1 to D and send D to NS;8. if D is not accepted or time-out (Tm) occurs

then send Lselse send A.

Applying the above procedure and algorithm we getthe complementedP and Q denoted byPr9 andQs9 asshown in Fig. 4. The protocol for the new virtual layer is

represented byRPQ (Fig. 5). In fact, the complementedPr

andQs are projected ontoRPQ, which essentially does thenecessary translation for transferring data from an AB sen-der to NS receiver. The final converter machineRFPQ isshown in Fig. 6 which is obtained after the refinement,e.g., the states (2) and (4) ofRPQ have been merged becausein both the states the ingoing edges are an acknowledgmentfor message d0 or D. We can view the conversion system,i.e., the combination ofPr, Qs and channels between them,as a single component. Similarly, the complement ofQr andPs can be projected ontoRQP to transfer data from an NSsender to an AB receiver. It follows that the properties ofAB hold for the communication between the sender and theconverter, and those of NS hold between converter andreceiver. Using these properties we can easily deduce theproperties of the global system.

5. Discussion

The complementation approach provides a sufficientcondition for finding a useful converter to overcome a protocolmismatch. If some common functionality can be found at

Fig. 4. Complemented protocolPr and complemented protocolQs.


the beginning, a very simple converter can be easilyobtained. However, a mapping can always be done fromthe syntax and semantics of the protocols. Complementationis very useful to convert the hard protocol mismatch to softprotocol mismatch. This approach considers almost all tran-sition sequences on the intended internetworking functionbetween the original protocols.

The converter has been implemented through an Estelle-C compiler and compared with Lam’s protocol projectionapproach and Okumura’s conversion seed approach. Tocompare with Lam’s projection approach we found thatour method does not require any heuristic search and itwill generate a converter if little common functionalityexists between the protocols at the beginning. Since ourapproach considers almost all transitions of the intendedinternetworking the correctness of the converter can be veri-fied formally with the help of CFSM. To compare withOkumura’s conversion seed approach we also found thatour algorithm allows efficient construction of the converterfrom the existing components of protocols without search-ing for the existence of a suitable seed. According to ourmethod it is very easy to infer whether the converter doesnot exist due to the hard mismatch between the protocols orthe problem is with the incorrect specification of protocols.

Finally, the computational complexity of the algorithm isthe lowest among the existing methods.

Acknowledgements

The authors are thankful to the Council of Scientific andIndustrial Research (CSIR), Govt. of India and the IndianInstitute of Technology, Kharagpur for supporting thisresearch. Special thanks are due to Dr. D. Datta and theanonymous referees for their helpful comments.

Appendix A Algorithm (complement): Procedure

1. ProcedureComplement (varPr, Qs, F: CFSM); /inputPr,Qs, F are all CFSMs/

2. var Pr9, Qs9, RPQ: CFSM; d i: operation set;3. FLAG A, FLAG B: boolean; FLAG: boolean;4. begin5. Pr9: NULL; Qs9: NULL; RPQ: NULL;/ * initialization */6. FLAG A: ¼ FALSE; FLAG B: ¼ FALSE;7. d i; SF; S9: ¼ (di ∩ SPr

); S0 : ¼ (di ∩ SQs);

8. if9. ((S9 , . NULL) and (S0 , . NULL))10. then /* to avoid reduction to null CFSM*/11. begin12. Complement(var Pr, Pr9: CFSM; d i: operation set;

FLAG A: boolean);13. /* to producePr9 ¼ Pdi

(Pr) */14. Complement(var Qs, Qs9: CFSM; d i: operation set;

FLAG B: boolean);15. /* to produceQs9 ¼ Pdi

(Qs) */16. if17. ((FLAG A ¼ TRUE) and (FLAG B ¼ TRUE))18. thenFLAG: ¼ TRUE;19. Convert(var Pr9, Qs9, F: CFSM);

Fig. 5. Resultant protocol after complementation.

Fig. 6. Final converter machine.


20. /* to produceRPQ ¼ (Pr9 þ Qs9) */21. if22. (RPQ , . NULL)23. then / * converter exists*/24. begin if FLAG: ¼ TRUE25. then / * refinement is required*/26. Refine(var RFPQ, Pr, Qs, RPQ: CFSM)27. else RPQ ¼ RFPQ;28. RFPQ as the required converter;29. end30. elsedeclare converter not found;31. elsego to the first step;32. end33. elsedeclare significant message set faulty;34. end

References

[1] P.E. Green, Protocol conversion, IEEE Trans. Commun., COM-34(1986) 288–296.

[2] P.E. Green (ed.), Computer Network Interconnection and ProtocolConversion, IEEE Press, 1988.

[3] E.W. Biersack, A systematic approach for constructing gateways,Computer Network and ISDN Systems, 18 (1990) 79–95.

[4] K.L. Calvert and S.S. Lam, Deriving a protocol converter: a top-downmethod, Proc. ACM SIGCOMM, San Francisco, CA, 1989, pp. 247–258.

[5] K.L. Calvert and S.S. Lam, Formal methods for protocol conversion,IEEE J. Sel. Area. Comm., 8 (1990) 127–142.

[6] J. Chang and M.T. Liu, An approach to protocol complementation forinternetworking, Proc. IEEE, ICSI ’90, NJ, April 1990, pp. 205–211.

[7] S. Lam, Protocol conversion, IEEE Trans. Software Eng., 14 (1988)353–362.

[8] Y. Ohara, S. Yoshitake and T. Kawoka, Protocol conversion methodfor heterogeneous systems interconnection in multiprofile environ-ment, 7th IFIP Symposium on Protocol Specification, Testing andVerification, Vol. 7, 1987.

[9] K. Okumura, A formal protocol conversion method, Proc. ACMSIGCOMM ’86 Symp., Stowe, VT, August 1986, pp. 30–37.

[10] K. Okumara, Generation of proper adapters and converters from aformal service specification, Proc. IEEE INFOCOMM, Austin, TX,1990, pp. 564–571.

[11] M. Rajagopal and R.E. Miller, Synthesizing a protocol converter fromexecutable protocol traces, IEEE Trans. Computer, C-40 (1991) 487–499.

[12] J.C. Shu, Protocol conversion for computer networks, Ph.D. thesis,Ohio State University, 1990.

[13] J.C. Shu and M.T. Liu, A synchronisation model for protocol con-version, Proc. INFOCOMM, April 1989, pp. 276–284.

[14] J.C. Shu and M.T. Liu, An approach to indirect protocol conversion,Computer Network and ISDN Systems, 21 (1991) 93–108.

[15] Y.W. Yao, W.S. Chen and M.T. Liu, A modular approach to con-structing protocol converters, Proc. IEEE INFOCOMM, Austin, TX,1990, pp. 572–579.

[16] D.M. Kristol, D. Lee, A. Netravali and K. Sabnani, A polynomial

algorithm for gateway generation from formal specifications, IEEE/ACM Trans. Networking, 1 (1993) 217–229.

[17] M. Peyravian and C.T. Lea, Construction of protocol converters usingformal methods, Comp. Communs., 16 (1993) 215–288.

[18] S. Das, R.C. Ganguli, P. Dhar and D. Saha, Network interconnectionand protocol conversion: a protocol complementation approach, J.Inst. Eng., India, 75 (1994) 30–32.

[19] S. Das and P. Dhar, Internetworking between TP4 and TCP throughprotocol complementation, Proc. IEEE 1st Int. Conf. on Algorithmsand Architectures for Parallel Processing (ICA3PP-95), Brisbane,Australia, Vol. 1, April 1995, pp. 315–323.

[20] M.T. Liu, Protocol engineering, in: M.C. Yovits (ed.), Advances inComputers, Academic Press, 1989, pp. 79–195.

[21] D. Brand and R. Zafiropoulo, On communicating finite statemachines, J. Assoc. Comput. Mach., 30 (1983) 323–342.

[22] R. Zafiropulo, H.C. West, H. Rudin et. al., Towards analysing andsynthesizing protocols, IEEE Trans. Commun., 28 (1980) 651–660.

[23] J.E. Hopcroft and J.D. Ullman, Introduction to Automata Theory,Language and Computation, Addison-Wesley, New York, 1979.

[24] P. Merlin and G.V. Bochmann, On construction of submodule specifi-cations and communication protocols, ACM Trans. Progr. Lang. Sys.,5 (1983) 1–25.

Subir Das received his four-year integratedM.Tech. degree in Radio Physics and Elec-tronics from Calcutta University, Calcutta,in 1990. From 1991 to 1994 he was an Insti-tute Research Scholar in the Indian Instituteof Technology, Kharagpur, India. FromFebruary 1995 to February 1997 he was aResearch Associate of the Council of Scien-tific and Industrial Research, Government ofIndia, in the Department of Electronics andElectrical Communication Engineering,Indian Institute of Technology, Kharagpur,

India. At present he is a lecturer of Computer Engineering in theDepartment of Electronics and Electrical Communication Engineeringat the Indian Institute of Technology, Kharagpur, India. His currentresearch interests include heterogeneous network interconnection,formal modelling, protocol interworking, converter synthesis andimplementation.

Prantosh Dhar received his M.Sc.(Tech.) inApplied Physics from Calcutta University,India, in 1959 and Ph.D. in Electrical Engin-eering from Aston University, UK, in 1968.In between he spent about six years in indus-try in India and the UK from 1959 to 1965.At present he is a Professor of ComputerEngineering in the Department of Elec-tronics and Electrical CommunicationEngineering at the Indian Institute of Tech-nology, Kharagpur, India. He was a VisitingProfessor in the Department of Computing

Science at the University of Alberta, Canada, and a Senior TeachingFellow in the School of Applied Science at the Nanyang TechnologicalUniversity, Singapore. His research interests currently lie in the areasof computer communication networks, protocol engineering, highspeed protocols, hypermedia, distributed systems and softwareengineering.


Design of simplified protocol converters through protocol complementation

Documents

Transcript of Design of simplified protocol converters through protocol complementation