- Email: [email protected]
Protocol converter generation using the STS approach
ELSEVIER
Computer Communications 19 (1996) 1216-1225
Protocol converter generation using the STS approach Hou-Wa J. Jeng, Ming T. Liu Department of Computer and Information Science, The Ohio State University, 2015 Neil Avenue, Columbus, OH 43210-1277. USA
Abstract During the past four years, the authors have developed the Synchronizing Transition Set (STS) approach to solve protocol conversion problems for interconnecting heterogeneous computer networks. The STS approach is a S-step formal algorithm: given service specifications of target protocols as its input, it derives a protocol converter specification as output. Several variations of the STS algorithm have been studied, and it was formally proven that all of these variations support the same correctness properties [l-4], such as conformity, liveness and transparency properties. Recently, the STS algorithm has been fully implemented in an STS protocol converter generation package. The package is written in the C language under a standard UNIX operating system. It needs less than 1000 lines of C statements to fully implement the STS algorithm. Moreover, to generate a converter between some classical example protocols, such as ABP (alternating bit protocol) and go-back-n protocols, it only takes a few seconds to derive a correct protocol converter specification using a desktop workstation. In this paper, the STS algorithm and its implementation are presented. Keywords: Protocol conversion; Service specification; Synchronizing transition set; Implementation
1. Introduction
Since 1990, most researchers in protocol conversion have shifted their attention from the protocol specification approach to the service specification approach; typical examples of the latter are the methods proposed in early 1990s [5-91. In general, these methods have less complexity than those methods proposed [10-l?‘] which are in the category of the protocol specification approach. Even though the service specification’s high level of abstraction alleviates the complexity of protocol converter generation in the early design stage, the service specification by itself does not indicate directly how to perform the protocol conversion. As a result, the i&rmation on how to perform the conversion must be derived from the given service specifications and requirement. Since the conversion information derived, in general, is not specific, the resulting converter may not be correct. Consequently, serious drawbacks exist in these service specification methods, thereby rendering themselves impractical [ 11. In 1992, the synchronizing transition set (STS) algorithm in the CFSM (communication finite state machine) model was proposed to overcome the drawbacks of those early service specification methods [l-4]. The STS 0140-3664/96/%15.000 1996 Elsevier Science B.V. All rights reserved PII SO140-3664(96)01155-3
algorithm is a formal method that derives converters from the service specifications of its target protocols in five steps. The first three steps take as input the target protocols’ service specifications and requirement to derive the protocol conversion information needed, the synchronizing transition sets. Then, the last two steps apply the derived protocol conversion information to the original target protocol specifications. The output of the STS algorithm is a formal converter specification in the same level of detail as the original target protocol specifications. It has been formally proven that the converter generated by the STS algorithm always has the correctness properties [ 1,4]. Since 1992, the STS algorithm has been enhanced to work effectively in the EFSM (extended finite state machine) model, and in a multimedia network environment [2,3]. More recently, the STS algorithm has been successfully implemented in the C language under a standard UNIX operating system, and less than 1000 lines of C statements are needed to fully implement the STS algorithin. Moreover, during a test run of the implementation, it took less than a few seconds to generate a correct (as defined in [ 11)converter for some typical protocols such as the alternating bit protocol (ABP) and the go-back-n protocol [4].
1217
H.- W.J. Jeng. h4.T. LiulComputer Communications 19 (1996) 1216-1225
service Spccilieation
ConversionRequirementin ServiceSpec
Ps
Service Transition
Service Transition
Pa
Peer Transition
q
Serviu Transition
SAP
SAP
ServiceTransition
g-0
Pb
$J
Peer Transition ti
P
c
J
Ps
2. Original STS algorithm In this section, a class of state-transition systems, called CFSMs (Communication Finite State Machines), is adopted for the protocol specification and service specification. In such a model, a protocol system consists of a set of CFSMs called protocol entities. Each protocol entity communicates with the others through message passing, as shown in Fig. 1, where peer transitions support the interaction between two peer protocol entities and service transitions perform the interaction between a protocol entity and its environment (e.g. the protocol service users) through the SAP (Service Access Point). Formally, a protocol entity P, can be defined as a sixtuple (q, C, A, 6, i,f) where 1. q is the finite set of states in P,.
>
Qs >
C ST?3Algorithm
Fig. 1. Protocol system in the CFSM model.
In the rest of this paper, Section 2 provides an overview of the original STS algorithm in the CFSM model; Sections 3 and 4 discuss the variations of the STS algorithm in the EFSM model and in a multimedia network environment, respectively. Section 5 presents the STS algorithm implementation, and Section 6 concludes the paper. Note that, throughout this paper, the words approach, algorithm and method have been used interchangeably.
Peer Transition
Service Transition #
Service Transition t
t
Peer
Transition
t
C
Peer
Transition I
I
Fig. 2. Intermedia conversion node model.
2. C is the finite set of service transitions in P,. 3. X is the finite set of peer transitions in P,. 4. S is the transition function of P, which maps q x (C U A) into q. 5. i is the initial state of P,. 6. f is the set of the final states in P,. For ease in presentation, only 2-entity protocols are considered in this paper. In the rest of the section, a simple example is used to give an overview of the STS algorithm. Fig. 2 shows the STS algorithm’s conversion model. As illustrated in Fig. 2, the STS algorithm takes seven specifications as its input. In terms of the example of this section, the input specifications are as follows: l
l
specifications of the target protocols P (P, and Pb) and Q (Q, and Qb), as shown in Fig. 3, where the service transitions are labeled in capital letters; specifications of the service provided by each target protocol, P, and Q, (in Fig. 4);
Qb:
Fig. 3. Example 1: the given protocols P and Q.
H.- W.J. Jeng, M.T. LiujComputer Communications 19 (1996) 1216-1225
1218
BUSY
FULL
IN
OUT
Fig. 4. Example 1: the conversion service requirement and the service specifications. l
specification of the conversion service requirement R (also in Fig. 4).
In this example, protocol P is a simplified flow control protocol. Before sending each data from P, to Pb,a reservation needs to be confirmed. If Pb has no space available to receive data, it can send a choke message to P, to stop the sending. Protocol Q is a simple nonsequence protocol with no flow control functions. Given the aforementioned seven specifications as the input, the STS algorithm takes five steps to derive a converter. In the first step of the algorithm, the service system graph, G (Fig. 5), is generated from the given P,, R and Q, by a modified composite operation, 8, defined as follows: G = (P,,R,Q,) = P,8 R@ Q, is a 6-tuple entity (4, C, A, 6, i,f),
where
1. q = {[u, v, w]l u, v, w are states of P,,R and Q,, respectively};
2. C is the union of the service transition sets of entities P,and Q,, i.e. C = Cps U CQ,; 3. X is the set of peer transitions and X = Q,(A is empty); 4. 6( [u, v, w], t) = (a) [u’, v, w] if t E C,* & t 6 CR & Sp,(u, t) = u’ (b)[u,v,w’]iftECQS&t$CR&beS(w,t)=w’ (c) [u’, v’, w] if t E Cps & t E CR & bp,(u, t) = u’ & &(v, t) = v’ (d) [u, v’, w’] if t E CQ, & t E CR & 8R(v, t) = v’ & &(w, t) = w’ (e) t is not executable at state [u, v, w] in G if none of the above four conditions is true. (S,,, ~5, and ~5,~are the transition functions of P,,R and Q,, respectively); 5. i is the initial state and i = [ip,, iR, ie,], where ips, iR and ies are the initial states of P,,R and Q,, respectively; 6. f is the set of the final states in G and f = {pb,, fR, fQ))
(=
{bs9
iR9 iQ,l))-
In Fig. 5, the number in each state represents the
REC 721 BUS .4
FULL
REC
REC
Y
BUSY
REC
REC
REC
REC
REC
1
DEL
FULL
.
..
;.!iHl.;
722 Fig. 5. Example 1: the service system graph G.
H.- W.J. Jeng, M.T. LiulComputer Communications19 (1996) 1216-1225
corresponding state of each composing entity in the order of P,, R and Qs; e.g. state 111 in Fig. 5 means that all P,, R and Q, are in the initial state (state 1). This service system graph G, constructed by the modified composition operation, %I, describes how the protocols P and Q work together as a composed protocol system to perform the functions requested by the conversion service requirement R. Note that G does not contain any peer transition, and it describes the behavior of the composed protocol system at the service transition level (i.e. at SAP). In the second step, the goal is to derive the conversion service specification, M. Note that the conversion service requirement R (hence also the derived service system graph G) only describes how the final protocol system should function and neither R nor G indicates specifically how the conversion should be performed. The information on how to perform the conversion is, however, implied in G. Since the conversion is performed between Pb and Q,, in order to know how the conversion can be done, the relationship between the transitions in Pb and Qa must be derived first. By projecting G onto Cp, u CQ. (the union of the service transition sets of protocol entities Pb and Q,), one can derive a conversion service specification M (Fig. 6), which contains the transitions from only Pb and Q,. This conversion service specification, M, describes the necessary sequences of the transitions between Pb and Q, to provide the service required in R; i.e. M (= G(n, UcpO)describes how the service transitions of Pb and Q, interact to perform the service requested in R. Formally, the projection operation is defined as follows: M = GICpbuce,,is a CFSM derived from G by the following steps: 1. Change the transitions of G not belonging to C% U C,. into null transitions. 2. Remove all null transitions using the algorithm described in [18]. In the third step, the goal is to derive the synchronizing REC
/ FULL REQ
OK
1219
,“h
“_.j I’ *-
t <____J
CoadilIatcd Exection
Fig. 7. Concurrent execution with coordination of rj and fk.
transition sets from the conversion service specification M obtained in Step 2. A synchronizing transition set contains the transitions which must be executed together (in both Pb and Q,) for the protocol system to correctly perform the conversion as requested by the conversion service requirement R. The transitions in a synchronizing transition set is called the synchronizing transitions. Essentially, the idea behind this step is to identify the aforementioned synchronizing transitions, and make them execute together such that the other transitions before and after them in both protocol entities Pb and Q, can be executed synchronously. Fig. 7, where $ and ?k are members of a synchronizing transition set, illustrates how the synchronizing transitions tj and fk synchronize the execution of the transitions in protocol entities Pb and Q,. In Fig. 7, when Pb and Q, are forced to execute fj and tk at the same time, all the transitions t,‘s that are executable only after lj in Pb should not be executed before tk in QO is executed. For the same reason, the execution of the transitions tn’s in Q, (which are executable only after tk) is synchr&ized with that of fj in Pb. Consequently, the execution of the transitions tU’s(t,‘s) is synchronized with that of tn’s (t,‘s) which belong to a different entity. The generation procedure of the synchronizing transition sets is described in detailed elsewhere [ 1,4], and highlighted as follows: (a) Generate all legal paths of M, where a legal path, pi, is a sequence of service transitions that is accepted by M. In other words, a legal path is a sequence of service transitions which starts from the initial state of M and ends also at the initial state. (b) For each path, pi, generated in (a), create a transition set, Ti, whose members are the transitions in the path, ri = {t ( t is a transition in pi}
Fig. 6. Example 1: the conversion service specification M.
(c) For each transition set generated in (b), use the following definition to identify if it is a synchronizing transition set Sk, where k is an arbitrary number used to distinguish one synchronizing transition set from another.
H.-W.J. Jeng. M.T. LiujComputer Communications 19 (1996) 1216-1225
1220
+ack
Definition Synchronizing Transition Set S: A transition set Ti is a synchronizing transition set if the following is true: 3j#isTi=q & pi and pi are two different permutations of each other. In this example, the synchronizing transition set Sr is {OK, OUT, REC}. Note that there could be more than one synchronizing transition sets. It just happens in this example that there is only one synchronizing transition set (which is labeled Sr). In Step 4, the coordinated composition operation, 0, is used to derive the converter. The input to this o operation includes the synchronizing transition sets obtained in Step 3 (used as a synchronizing mechanism) and the original protocol specification Pb and Q,. Formally, this operation is described as follows: the converter, C = Pb o Q,, with the virtual atomic transitions Vi’s and the corresponding synchronizing transition sets Si’s obtained in Step 3, where i = 1,2,. . . , is a 6-tuple (q, C, X, 6, i, f ), where 1. q = {[u, v]I u, v are states of Pb and Q,, respectively}; 2. C = C, U CQ#U {all Vi’s}; 3. x = x, u XQ,; 4. 6 is the transition function of C and 6( [u, v], t) = (a) [u’, v] if t E X, & bPb(u, t) = u’ (b) [u, v’] if t E XQO& Se,(v, t) = v’ (c) [u’, v] if t E Cq & t g! any of the Si’s & s,, (u, t) = u’ (d) [u, v’] if t E C,. & t $ any of the Si’s & fi&(V, t) = v’ (e) [u’, v’] if t is a virtual atomic transition, Vi, & Spb(u, t’) = u’, where t’ E C% and t’ E Si & Saa(v, t”) = v’, where t” E CQOand t” E Si. (f) t is not executable at state [u, v] in C if none of the above is true; 5. i = [ipb,iQ.1, where ip, and iQ. are the initial states of Pt, and Q,, respectively; 6. f = {[fp,,fQ.])(= {[bbYiQO])).
Fig. 9. Example 1: the final converter.
concurrently in the sequence as the original protocols prescribed, as long as the transitions are not synchronizing transitions (i.e. transitions which do not belong to a synchronizing transition set). The synchronizing transitions in one entity have their chance of execution when the peer entity is ready to execute the corresponding synchronizing transitions in the same synchronizing transition set. In other words, one entity must wait for its peer to execute together the synchronizing transitions in a synchronizing transition set. Finally, the result of applying the o operation to Pb and Q, is shown in Fig. 8. In Fig. 8, transition Vi represents execution of all the synchronizing transitions atomically. Moreover, Vi’s execution also includes the peer transitions, -conf and +data, from the original protocol specifications. Therefore, in the last step (Step 5), the transition Vi is expended into peer transitions as shown in Fig. 9. Note that in the final converter specification in Fig. 9, there is no service transition needed since there is no service user on top of the converter node in the conversion model (Fig. 2) of this example. 3. STS algorithm in EFSM model Basically, an EFSM (extended finite state machine) is a generalization of a FSM (Finite State Machine). The
As depicted in Fig. 7, the coordinated composition operation, 0, will force protocol entities Pb and Q, to execute the transitions in synchronizing transition sets together. Consequently, the coordination/synchronization between transitions in Pb and Q, is achieved. The 0 operation allows all the transitions in Pb and Q, to execute
=q?Jf?gjhoke Fig. 8. Example 1: the converter with virtual atomic transition VI.
Fig. 10. Example 2: given protocols P (ABP) and Q (Go-Back-N Protocol).
H.- W.J. Jeng, M.T. LiulComputer Communications 19 (1996) 1216-1225
&--j-J &_-$J I
I
Fig. 11. Example 2: the conversion service requirement and service specifications.
major difference between CFSM and EFSM is the inclusion of state variables of various types in EFSM. The values of these state variables are changed by occurrence of events/transitions. An event can occur only if certain enabling conditions are satisfied. An enabling condition is a predicate on the state variables, and in this paper it is represented within a pair of square brackets (Fig. 10). Formally, the definitions of an EFSM protocol entity and of an EFSM service specification are the same as those in the CFSM model, except for the inclusion of state variables. The EFSM model has more express power than the CFSM model, and is more practical in specifying complex protocols. In this section, it is shown that the STS algorithm can also work effectively in the EFSM model. Consequently, the scope of coverage of the algorithm, in terms of the number of protocols to which it is applicable, is also extended. The main reason that the STS algorithm can work effectively in the EFSM model with only minor modification is that in the first three steps of the STS algorithm, only the service specifications and the conversion service requirement (in the same form as the service specifications) are used to derive the conversion service
1221
specification. The implementation details (i.e. the protocol specifications) are not involved until the last two steps, when the final converter is to be derived. Since the extension from the CFSM model to the EFSM model affects only the protocol specification, and as the high level service specification remains the same (i.e. the service provided by the protocols remains the same in both models), the first three steps of the STS algorithm need not be changed. In this section the example shown in Fig. 10 is used only to show the effectiveness of the STS algorithm. The two target protocols are the ABP (alternating bit protocol) and a Go-Back-N protocol. The service specification and its conversion service requirement are given in Fig. 11. As shown in Fig. 11, the service specifications are the same as those in the CFSM model. Therefore, by applying the same three steps of the STS algorithm to this example, a synchronizing transition set S, can be derived as Si = {[(x + l)%max ( ) y]REC, OUT}. Note that a synchronizing transition is basically a concatenation of some regular transitions. In the CFSM model, this transition concatenation is straightforward. However, in the EFSM model, due to the presence of predicates, the concatenation of transitions needs to concatenate not only the action parts, but also the predicates of the transitions. This is also the only enhancement in the STS algorithm that must be made for the EFSM specification model [2]. In the example of this section, with such an enhanced STS algorithm (Steps 4 and 5) a final converter can be derived as shown in Fig. 12. Note that the action part of the virtual atomic transition Vi is removed (i.e. Vi becomes a null-action transition), since it consists of service transitions only (in this example, it consists of OUT and REC). On the other hand, the predicate part of Vi cannot be removed because it consists
Fig. 12. Example 2: the final converter.
1222
H.- W.J. Jeng, M.T. Liu/Computer Communications 19 (1996) 1216-1225
of some legitimate state variables, as shown in Fig. 12. As a result, the virtual atomic transition Vi of this example cannot be reduced into a removable null transition. Note that a null transition is different from a null-action transition. Consequently, the virtual atomic transition Vt is kept in the final converter specification.
4. STS algorithm in multimedia networks A simulation study [3] shows that, due to the special characteristics (high speed and high connectivity) of integrated multimedia networks, the traditional protocol conversion model will introduce long transmission delays and render a network system useless. This simulation study makes it clear that a different and more efficient approach is needed for protocol conversion in multimedia networks. Therefore, to further demonstrate the flexibility of the STS algorithm described in Sections 2 and 3, another modification is presented in this section for converter generation in multimedia network environments. In the traditional conversion model (Fig. 2), the converter/gateway is a single point of connection for the two networks with protocol mismatches. All traffic between nodes of two different networks must travel the gateway through the gateway. Consequently, becomes a traffic bottleneck. In traditional data networks, since the number of internal nodes is less than a few hundred and internetwork communication is relatively less frequent, the bottleneck effect is tolerable. In fact, the throughput requirement of traditional internetwork communication is in the range of hundreds of Kbits/s or less; therefore, in terms of network interconnection, a high-speed bridge would suffice. In the case of multimedia networks, however, high connectivity means increased probability of traffic through the converter/gateway. Coupled with the high bandwidth requirements on each media stream, the transmission delay at a single point of traffic congestion will become unmanageable. For example, in a regular DQDB network, an intermediate station which attempts to transmit a message into a slot can simultaneously read from and write into the busy bit of the slot passing by to minimize the latency incurred [19]. To support the required transmission speed of a multimedia network, the delays in the intermediate nodes/stations are, in general, less than a few bits in most of the proposed high-speed networks. If an intermediate converter node is used as in the traditional model, the delay could be as high as a few messages, thereby reducing the total throughput significantly. To alleviate internetwork traffic congestion, more gateways could be installed between each pair of networks; however, these gateways would still be points of traffic congestion and delay, thereby reducing the QoS (Quality of Service).
Thus, in contrast to the traditional conversion model (i.e. the intermediate node model) used in previous section, a different model that performs conversion at end nodes is used in this section. In the protocol conversion literature, this category of conversion is known as the protocol compensation approach. In this end node model, it is assumed that a node can be physically connected to a network by simply tapping itself into an access point of the network, in the same manner as plugging in a telephone establishes a connection. This model, without an intermediate converter gateway, performs protocol conversion at the end nodes to reduce intermediate node delay in internetwork communication. Note that a converter gateway must still be used when the networks to be integrated are geographically separated far apart, and tapping into other networks is not feasible. However, it should also be noted that the networks in a multimedia network environment are often overlapped, much as telephone networks and cable TV networks: an average household often contains both cable TV and telephone outlets. Two networks are considered to be overlapping if they cover approximately the same geographical area, and an access point of one network is always close to an access point of the other, such that a node in one network can physically be connected to the other network without unreasonable difficulty. The new conversion model is shown in Figs 13 and 14. In Fig. 13, node N2 in network 2 taps itself into network 1 to initiate internetwork communication with node Nl in network 1. The dotted lines between node N2 and
r_______________________________--___________________, i Abstract Model: ,
:
. . .. . Converterc
:..................................................i Node Nl
Fig. 13. Option l-Conversion
Node N2
at receiving node.
I
H.- W.J. Jeng, M.T. LiulCotnputerCommunication 19 (1996) 1216-1225
1223
: Abstract Model:
:
; I
:
Fig. 15. Example 3: converter entity C. Converta C
: :................................................... NodeNl
Node N2
I
_____
L_________________________------__-_____________
Fig. 14. Option 2-Conversion
at sending node.
network 1 denote the attachment of N2 to network 1. From node Nl’s viewpoint, node N2 is only a newly added node in network 1 running the same protocol. Nl and N2 can be considered as two nodes connected by the same high speed links of network 1. Therefore, Nl would use the regular protocol of network 1 to communicate with N2 without knowing that N2 is a node in network 2. To keep the conversion transparent to high level application programs, node N2 performs the conversion within its low level protocol entities. The abstract model is shown in the dashed box of Fig. 13. Note that in this abstract model, protocol Q (of network 1) is used between nodes Nl and N2. The model in Fig. 14 works in the same way in the opposite direction, i.e. the conversion is performed at the communication initiation node. Due to space limitations, the remainder of this section focuses on the model shown in Fig. 13. In the following, the example in Section 2 (Fig. 3) is again used to demonstrate the applicability of the STS algorithm to multimedia networks. In the example of this section, an end node converter that allows Q, to send messages to Pb will be generated. The first three steps of the algorithm remain the same as before. Therefore, following through the first three steps of the STS algorithm, a synchronizing transition set Si can be derived: S, = {DEL, RSV, CONF, IN}. Step 4 contains the major difference between the new model and the original STS method. Recall that in the original STS algorithm, the intermediate converter specification is derived by composition of peer protocol entities Qb and P, (for this example) at step 4. In the new model, the converter entity C in Fig. 13 is composed of peer protocol entity Qb and the entire protocol P (as a
single entity). Since the peer transitions of P are internal to P and not observable from C’s standpoint, only the service transitions need to participate in the composition in this step. In fact, protocol P is treated as an entity consisting only of service transitions, i.e. the participants of this step in the new model are Qb and P, instead of Qb and Pa. The same coordinated composition operator o is used to derive protocol entity C. In short, protocol entity C in the new model is derived as follows: converter entity C = Qb o P,. In the last step (step 5) of the algorithm, the service transitions from Pa (RSV, BUSY, CONF and IN) and Qb (DEL) must be removed, since only the service interface of Pb needs to be supported by C. Finally, the specification of the resulting converter entity C is shown in Fig. 15. From the converter entity specification shown in Fig. 15, it can be verified that states [3,7l and [1,7] are redundant. This indicates the need for further refinement of the modified STS algorithm. Due to the space limitation, the readers are referred elsewhere [3] for the refinement.
5. Implementation Recently, all five steps of the STS algorithm have been fully implemented. This implementation, STS Protocol Converter Generation Package, is written in the C language running under a standard UNIX operating system, and has less than 1000 lines of C statements. Moreover, when testing with some classical example protocols, such as the ABP (alternating bit protocol) and the go-back-n protocol, it takes only a few seconds to derive a converter specification. In the rest of this section, various features of this STS implementation are briefly described. There are five modules in the STS protocol converter generation package. Each module implements a step of the STS algorithm. These five modules are integrated
1224 sequentially,
H.-W.J. Jeng, M.T. l&/Computer Communications19 (1996) 1216-1225
i.e. the output of one module (except the last module) automatically becomes the input to the next module. The input to the first module includes all seven specifications needed by the STS algorithm, even though the first step only uses the service specifications. The specifications are specified in a tabular form and can be batched into an input file. These specification files are broken down into blocks, each block specifying one entity required as an input to the STS algorithm. The order of the entity specification input is as follows: P,,P,,Pb,Q,,Q,,Qb and R. The converter generator always generates a converter that allows one direction of the traffic from Pa to Qb based on the input specifications. In each block of the input specifications, the first line gives the number of transitions in the block, and each line of the block specifies one transition in the format of (starting state, action, ending state). When specifying a protocol in the EFSM module, the format is (starting state, [predicate] action, ending state). The output of the last module is the specification of a final converter in a tabular form. In addition, the intermediate results from each step are also given in the final output. The intermediate results include specifications of the global system graph (G), the conversion service specification (M), legal paths from M, synchronizing transition sets, etc. A sample input and output can be found elsewhere [4]. In the STS implementation, each of the input and output specifications (FSMs) is treated as a directed graph rooted from the initial state. Since the STS algorithm is basically a group of operations applied to these graphs, the most frequently used function is a graph traverse. Therefore, it was believed that the traverse function would have the most impact on the performance. However, during the search of an efficient traverse function, it was found that either depth first or breadth first traverse will work tine in the STS algorithm. In fact, since converter generation is not a real time process, execution time is not critical as long as a correct converter can eventually be generated within a period of time. In the implementation, breadth first traverse is used. It was mentioned that for multimedia networks, one of the participants of the coordinated composition in step 4 of the STS algorithm is a service specification. To accommodate this, the integrated STS implementation package can be split into individual modules. The user is allowed to specify the input specification to the module of step 4. Since the same coordinated composition is used as in the traditional conversion model, the STS implementation (module of step 4) does not need to know that one of the input specifications consists of only service transitions. Consequently, the same STS implementation package can generate converters not only for protocols
in the CFSM and EFSM models, but also for protocols in a multimedia network environment.
6. Conclusion A formal proof of correctness can be found elsewhere [4], which shows that the STS algorithm always finds a converter that satisfies the given conversion service requirement. If the requirement given is semantically correct, so is the converter constructed, and validation of its correctness is not needed. This is one of the main reasons that the STS algorithm can be easily implemented, and is more practical than most of the other protocol conversion methods, which require complex and expensive validation procedures. Finally, for future research, it is believed that various techniques devised during the STS research could also be used to solve other issues in high speed internetworking. For example, as a future research subject, it has been considered to use the Petri net model and the synchronization mechanism from the STS algorithm to solve the media mixing problem. It is anticipated that such research will mature along with the maturity of high speed networks in the future.
Acknowledgements Research reported herein was supported by U.S. Army Research Office, under contract No. DAAL03-92-G0184. The views, opinions, and/or findings contained in this paper are those of the authors and should not be construed as an official Department of the Army position, policy or decision.
References [l] H.J. Jeng and M.T. Liu, From service specification to protocol converter: a synchronizing transition set approach, Technical Report No. OSU-CISRC-3/92-TR-10, The Ohio State University, Columbus, Ohio, March 1992. [2] H.J. Jeng and M.T. Liu, Protocol conversion: synchronizing transition set approach in EFSM model, Technical Report No. OSUCISRC-l/93-TR-2, The Ohio State University, Columbus, Ohio, January 1993. [3] H.J. Jeng and M.T. Liu, Protocol conversion in multimedia networks: simulation and algorithm, Simulation, 64 (January 1995) 51-60. [4] H.J. Jeng, Synchronizing Transition Set Approach to Protocol Conversion. PhD thesis, The Ohio State University, June 1995. [5] K.L. Calvert and S.S. Lam, Deriving a protocol converter: a topdown method, Proc. ACM SIGCOMM Symposium, Austin, Texas, September, 1989, pp. 247-258. [6] K.L. Calvert and S.S. Lam, Adaptors for protocol conversion, Proc. IEEE INFOCOM, San Francisco, CA, June 1990, pp. 552-560. [7j K.L. Calvert and S.S. Lam, Formal methods for protocol conversion, IEEE J. Selected Areas in Comm., 8 (January 1990) 127-142.
H.- W.J. Jeng, M.T. LiujComputer Communications 19 (1996) 1216-1225 [8] K. Okumura, Generation of proper adaptors and converters from
a formal service specification, Proc. IEEE INFOCOM, San Francisco, CA, January 1990, pp. X4-571. [9] Y.W. Yao and M.T. Liu, Constructing protocol converters from service specification, Proc. IEEE ICDCS-12, Yokohama, Japan, June 1992, pp. 344351. [lo] K. Okumura, A formal protocol conversion method, Proc. ACM SIGCOMM Symposium, Stowe, Vermont, August 1986, pp. 30-38. [ll] Y.W. Yao, W.S. Chen and M.T. Liu, A modular approach to constructing protocol converters, Proc. IEEE INFOCOM, San Francisco, CA, (June 1990) pp. 572-579. [12] S.S. Lam, Protocol conversion-correctness problems, Proc. ACM SIGCOMM Symposium, Stowe, Vermont, (August 1986) pp. 1928. [13] K.L. Calvert and S.S. Lam, An exercise in deriving a protocol converter, Proc. ACM SIGCOMM Symposium, Stowe, Vermont, (August 1987) pp. 151-160.
1225
[14] S.S. Lam, Protocol conversion, IEEE Trans. Software Engineering, SE-14 (March 1988) 353-362. [15] J.C. Shu and M.T. Liu, A synchronization model for protocol conversion, Proc. IEEE INFOCOM, Ottawa, Canada, April 1989, pp. 276-284. [16] J. Chang and M.T. Liu, Using protocol validation technique to solve protocol conversion problems, Proc. 9th IPCCC, Scottsdale, Arizona, March 1990, pp. 539-546. [17] J. Chang and M.T. Liu, An approach to protocol complementation for interworking, Proc. IEEE ICSI, Morristown, New Jersey, April 1990, pp. 205-211. [18] J.E. Hopcroft and J.D. Ulhnan, Introduction to Automata Theory, Language and Computation. Reading, MA: AddisonWesley, 1979. [19] 0. Sharon and A. Segall, A simple scheme for slot reuse without latency for a dual bus configuration, IEEE/ACM Trans. Networking, (February 1993) 96-104.
Computer Communications 19 (1996) 1216-1225
Protocol converter generation using the STS approach Hou-Wa J. Jeng, Ming T. Liu Department of Computer and Information Science, The Ohio State University, 2015 Neil Avenue, Columbus, OH 43210-1277. USA
Abstract During the past four years, the authors have developed the Synchronizing Transition Set (STS) approach to solve protocol conversion problems for interconnecting heterogeneous computer networks. The STS approach is a S-step formal algorithm: given service specifications of target protocols as its input, it derives a protocol converter specification as output. Several variations of the STS algorithm have been studied, and it was formally proven that all of these variations support the same correctness properties [l-4], such as conformity, liveness and transparency properties. Recently, the STS algorithm has been fully implemented in an STS protocol converter generation package. The package is written in the C language under a standard UNIX operating system. It needs less than 1000 lines of C statements to fully implement the STS algorithm. Moreover, to generate a converter between some classical example protocols, such as ABP (alternating bit protocol) and go-back-n protocols, it only takes a few seconds to derive a correct protocol converter specification using a desktop workstation. In this paper, the STS algorithm and its implementation are presented. Keywords: Protocol conversion; Service specification; Synchronizing transition set; Implementation
1. Introduction
Since 1990, most researchers in protocol conversion have shifted their attention from the protocol specification approach to the service specification approach; typical examples of the latter are the methods proposed in early 1990s [5-91. In general, these methods have less complexity than those methods proposed [10-l?‘] which are in the category of the protocol specification approach. Even though the service specification’s high level of abstraction alleviates the complexity of protocol converter generation in the early design stage, the service specification by itself does not indicate directly how to perform the protocol conversion. As a result, the i&rmation on how to perform the conversion must be derived from the given service specifications and requirement. Since the conversion information derived, in general, is not specific, the resulting converter may not be correct. Consequently, serious drawbacks exist in these service specification methods, thereby rendering themselves impractical [ 11. In 1992, the synchronizing transition set (STS) algorithm in the CFSM (communication finite state machine) model was proposed to overcome the drawbacks of those early service specification methods [l-4]. The STS 0140-3664/96/%15.000 1996 Elsevier Science B.V. All rights reserved PII SO140-3664(96)01155-3
algorithm is a formal method that derives converters from the service specifications of its target protocols in five steps. The first three steps take as input the target protocols’ service specifications and requirement to derive the protocol conversion information needed, the synchronizing transition sets. Then, the last two steps apply the derived protocol conversion information to the original target protocol specifications. The output of the STS algorithm is a formal converter specification in the same level of detail as the original target protocol specifications. It has been formally proven that the converter generated by the STS algorithm always has the correctness properties [ 1,4]. Since 1992, the STS algorithm has been enhanced to work effectively in the EFSM (extended finite state machine) model, and in a multimedia network environment [2,3]. More recently, the STS algorithm has been successfully implemented in the C language under a standard UNIX operating system, and less than 1000 lines of C statements are needed to fully implement the STS algorithin. Moreover, during a test run of the implementation, it took less than a few seconds to generate a correct (as defined in [ 11)converter for some typical protocols such as the alternating bit protocol (ABP) and the go-back-n protocol [4].
1217
H.- W.J. Jeng. h4.T. LiulComputer Communications 19 (1996) 1216-1225
service Spccilieation
ConversionRequirementin ServiceSpec
Ps
Service Transition
Service Transition
Pa
Peer Transition
q
Serviu Transition
SAP
SAP
ServiceTransition
g-0
Pb
$J
Peer Transition ti
P
c
J
Ps
2. Original STS algorithm In this section, a class of state-transition systems, called CFSMs (Communication Finite State Machines), is adopted for the protocol specification and service specification. In such a model, a protocol system consists of a set of CFSMs called protocol entities. Each protocol entity communicates with the others through message passing, as shown in Fig. 1, where peer transitions support the interaction between two peer protocol entities and service transitions perform the interaction between a protocol entity and its environment (e.g. the protocol service users) through the SAP (Service Access Point). Formally, a protocol entity P, can be defined as a sixtuple (q, C, A, 6, i,f) where 1. q is the finite set of states in P,.
>
Qs >
C ST?3Algorithm
Fig. 1. Protocol system in the CFSM model.
In the rest of this paper, Section 2 provides an overview of the original STS algorithm in the CFSM model; Sections 3 and 4 discuss the variations of the STS algorithm in the EFSM model and in a multimedia network environment, respectively. Section 5 presents the STS algorithm implementation, and Section 6 concludes the paper. Note that, throughout this paper, the words approach, algorithm and method have been used interchangeably.
Peer Transition
Service Transition #
Service Transition t
t
Peer
Transition
t
C
Peer
Transition I
I
Fig. 2. Intermedia conversion node model.
2. C is the finite set of service transitions in P,. 3. X is the finite set of peer transitions in P,. 4. S is the transition function of P, which maps q x (C U A) into q. 5. i is the initial state of P,. 6. f is the set of the final states in P,. For ease in presentation, only 2-entity protocols are considered in this paper. In the rest of the section, a simple example is used to give an overview of the STS algorithm. Fig. 2 shows the STS algorithm’s conversion model. As illustrated in Fig. 2, the STS algorithm takes seven specifications as its input. In terms of the example of this section, the input specifications are as follows: l
l
specifications of the target protocols P (P, and Pb) and Q (Q, and Qb), as shown in Fig. 3, where the service transitions are labeled in capital letters; specifications of the service provided by each target protocol, P, and Q, (in Fig. 4);
Qb:
Fig. 3. Example 1: the given protocols P and Q.
H.- W.J. Jeng, M.T. LiujComputer Communications 19 (1996) 1216-1225
1218
BUSY
FULL
IN
OUT
Fig. 4. Example 1: the conversion service requirement and the service specifications. l
specification of the conversion service requirement R (also in Fig. 4).
In this example, protocol P is a simplified flow control protocol. Before sending each data from P, to Pb,a reservation needs to be confirmed. If Pb has no space available to receive data, it can send a choke message to P, to stop the sending. Protocol Q is a simple nonsequence protocol with no flow control functions. Given the aforementioned seven specifications as the input, the STS algorithm takes five steps to derive a converter. In the first step of the algorithm, the service system graph, G (Fig. 5), is generated from the given P,, R and Q, by a modified composite operation, 8, defined as follows: G = (P,,R,Q,) = P,8 R@ Q, is a 6-tuple entity (4, C, A, 6, i,f),
where
1. q = {[u, v, w]l u, v, w are states of P,,R and Q,, respectively};
2. C is the union of the service transition sets of entities P,and Q,, i.e. C = Cps U CQ,; 3. X is the set of peer transitions and X = Q,(A is empty); 4. 6( [u, v, w], t) = (a) [u’, v, w] if t E C,* & t 6 CR & Sp,(u, t) = u’ (b)[u,v,w’]iftECQS&t$CR&beS(w,t)=w’ (c) [u’, v’, w] if t E Cps & t E CR & bp,(u, t) = u’ & &(v, t) = v’ (d) [u, v’, w’] if t E CQ, & t E CR & 8R(v, t) = v’ & &(w, t) = w’ (e) t is not executable at state [u, v, w] in G if none of the above four conditions is true. (S,,, ~5, and ~5,~are the transition functions of P,,R and Q,, respectively); 5. i is the initial state and i = [ip,, iR, ie,], where ips, iR and ies are the initial states of P,,R and Q,, respectively; 6. f is the set of the final states in G and f = {pb,, fR, fQ))
(=
{bs9
iR9 iQ,l))-
In Fig. 5, the number in each state represents the
REC 721 BUS .4
FULL
REC
REC
Y
BUSY
REC
REC
REC
REC
REC
1
DEL
FULL
.
..
;.!iHl.;
722 Fig. 5. Example 1: the service system graph G.
H.- W.J. Jeng, M.T. LiulComputer Communications19 (1996) 1216-1225
corresponding state of each composing entity in the order of P,, R and Qs; e.g. state 111 in Fig. 5 means that all P,, R and Q, are in the initial state (state 1). This service system graph G, constructed by the modified composition operation, %I, describes how the protocols P and Q work together as a composed protocol system to perform the functions requested by the conversion service requirement R. Note that G does not contain any peer transition, and it describes the behavior of the composed protocol system at the service transition level (i.e. at SAP). In the second step, the goal is to derive the conversion service specification, M. Note that the conversion service requirement R (hence also the derived service system graph G) only describes how the final protocol system should function and neither R nor G indicates specifically how the conversion should be performed. The information on how to perform the conversion is, however, implied in G. Since the conversion is performed between Pb and Q,, in order to know how the conversion can be done, the relationship between the transitions in Pb and Qa must be derived first. By projecting G onto Cp, u CQ. (the union of the service transition sets of protocol entities Pb and Q,), one can derive a conversion service specification M (Fig. 6), which contains the transitions from only Pb and Q,. This conversion service specification, M, describes the necessary sequences of the transitions between Pb and Q, to provide the service required in R; i.e. M (= G(n, UcpO)describes how the service transitions of Pb and Q, interact to perform the service requested in R. Formally, the projection operation is defined as follows: M = GICpbuce,,is a CFSM derived from G by the following steps: 1. Change the transitions of G not belonging to C% U C,. into null transitions. 2. Remove all null transitions using the algorithm described in [18]. In the third step, the goal is to derive the synchronizing REC
/ FULL REQ
OK
1219
,“h
“_.j I’ *-
t <____J
CoadilIatcd Exection
Fig. 7. Concurrent execution with coordination of rj and fk.
transition sets from the conversion service specification M obtained in Step 2. A synchronizing transition set contains the transitions which must be executed together (in both Pb and Q,) for the protocol system to correctly perform the conversion as requested by the conversion service requirement R. The transitions in a synchronizing transition set is called the synchronizing transitions. Essentially, the idea behind this step is to identify the aforementioned synchronizing transitions, and make them execute together such that the other transitions before and after them in both protocol entities Pb and Q, can be executed synchronously. Fig. 7, where $ and ?k are members of a synchronizing transition set, illustrates how the synchronizing transitions tj and fk synchronize the execution of the transitions in protocol entities Pb and Q,. In Fig. 7, when Pb and Q, are forced to execute fj and tk at the same time, all the transitions t,‘s that are executable only after lj in Pb should not be executed before tk in QO is executed. For the same reason, the execution of the transitions tn’s in Q, (which are executable only after tk) is synchr&ized with that of fj in Pb. Consequently, the execution of the transitions tU’s(t,‘s) is synchronized with that of tn’s (t,‘s) which belong to a different entity. The generation procedure of the synchronizing transition sets is described in detailed elsewhere [ 1,4], and highlighted as follows: (a) Generate all legal paths of M, where a legal path, pi, is a sequence of service transitions that is accepted by M. In other words, a legal path is a sequence of service transitions which starts from the initial state of M and ends also at the initial state. (b) For each path, pi, generated in (a), create a transition set, Ti, whose members are the transitions in the path, ri = {t ( t is a transition in pi}
Fig. 6. Example 1: the conversion service specification M.
(c) For each transition set generated in (b), use the following definition to identify if it is a synchronizing transition set Sk, where k is an arbitrary number used to distinguish one synchronizing transition set from another.
H.-W.J. Jeng. M.T. LiujComputer Communications 19 (1996) 1216-1225
1220
+ack
Definition Synchronizing Transition Set S: A transition set Ti is a synchronizing transition set if the following is true: 3j#isTi=q & pi and pi are two different permutations of each other. In this example, the synchronizing transition set Sr is {OK, OUT, REC}. Note that there could be more than one synchronizing transition sets. It just happens in this example that there is only one synchronizing transition set (which is labeled Sr). In Step 4, the coordinated composition operation, 0, is used to derive the converter. The input to this o operation includes the synchronizing transition sets obtained in Step 3 (used as a synchronizing mechanism) and the original protocol specification Pb and Q,. Formally, this operation is described as follows: the converter, C = Pb o Q,, with the virtual atomic transitions Vi’s and the corresponding synchronizing transition sets Si’s obtained in Step 3, where i = 1,2,. . . , is a 6-tuple (q, C, X, 6, i, f ), where 1. q = {[u, v]I u, v are states of Pb and Q,, respectively}; 2. C = C, U CQ#U {all Vi’s}; 3. x = x, u XQ,; 4. 6 is the transition function of C and 6( [u, v], t) = (a) [u’, v] if t E X, & bPb(u, t) = u’ (b) [u, v’] if t E XQO& Se,(v, t) = v’ (c) [u’, v] if t E Cq & t g! any of the Si’s & s,, (u, t) = u’ (d) [u, v’] if t E C,. & t $ any of the Si’s & fi&(V, t) = v’ (e) [u’, v’] if t is a virtual atomic transition, Vi, & Spb(u, t’) = u’, where t’ E C% and t’ E Si & Saa(v, t”) = v’, where t” E CQOand t” E Si. (f) t is not executable at state [u, v] in C if none of the above is true; 5. i = [ipb,iQ.1, where ip, and iQ. are the initial states of Pt, and Q,, respectively; 6. f = {[fp,,fQ.])(= {[bbYiQO])).
Fig. 9. Example 1: the final converter.
concurrently in the sequence as the original protocols prescribed, as long as the transitions are not synchronizing transitions (i.e. transitions which do not belong to a synchronizing transition set). The synchronizing transitions in one entity have their chance of execution when the peer entity is ready to execute the corresponding synchronizing transitions in the same synchronizing transition set. In other words, one entity must wait for its peer to execute together the synchronizing transitions in a synchronizing transition set. Finally, the result of applying the o operation to Pb and Q, is shown in Fig. 8. In Fig. 8, transition Vi represents execution of all the synchronizing transitions atomically. Moreover, Vi’s execution also includes the peer transitions, -conf and +data, from the original protocol specifications. Therefore, in the last step (Step 5), the transition Vi is expended into peer transitions as shown in Fig. 9. Note that in the final converter specification in Fig. 9, there is no service transition needed since there is no service user on top of the converter node in the conversion model (Fig. 2) of this example. 3. STS algorithm in EFSM model Basically, an EFSM (extended finite state machine) is a generalization of a FSM (Finite State Machine). The
As depicted in Fig. 7, the coordinated composition operation, 0, will force protocol entities Pb and Q, to execute the transitions in synchronizing transition sets together. Consequently, the coordination/synchronization between transitions in Pb and Q, is achieved. The 0 operation allows all the transitions in Pb and Q, to execute
=q?Jf?gjhoke Fig. 8. Example 1: the converter with virtual atomic transition VI.
Fig. 10. Example 2: given protocols P (ABP) and Q (Go-Back-N Protocol).
H.- W.J. Jeng, M.T. LiulComputer Communications 19 (1996) 1216-1225
&--j-J &_-$J I
I
Fig. 11. Example 2: the conversion service requirement and service specifications.
major difference between CFSM and EFSM is the inclusion of state variables of various types in EFSM. The values of these state variables are changed by occurrence of events/transitions. An event can occur only if certain enabling conditions are satisfied. An enabling condition is a predicate on the state variables, and in this paper it is represented within a pair of square brackets (Fig. 10). Formally, the definitions of an EFSM protocol entity and of an EFSM service specification are the same as those in the CFSM model, except for the inclusion of state variables. The EFSM model has more express power than the CFSM model, and is more practical in specifying complex protocols. In this section, it is shown that the STS algorithm can also work effectively in the EFSM model. Consequently, the scope of coverage of the algorithm, in terms of the number of protocols to which it is applicable, is also extended. The main reason that the STS algorithm can work effectively in the EFSM model with only minor modification is that in the first three steps of the STS algorithm, only the service specifications and the conversion service requirement (in the same form as the service specifications) are used to derive the conversion service
1221
specification. The implementation details (i.e. the protocol specifications) are not involved until the last two steps, when the final converter is to be derived. Since the extension from the CFSM model to the EFSM model affects only the protocol specification, and as the high level service specification remains the same (i.e. the service provided by the protocols remains the same in both models), the first three steps of the STS algorithm need not be changed. In this section the example shown in Fig. 10 is used only to show the effectiveness of the STS algorithm. The two target protocols are the ABP (alternating bit protocol) and a Go-Back-N protocol. The service specification and its conversion service requirement are given in Fig. 11. As shown in Fig. 11, the service specifications are the same as those in the CFSM model. Therefore, by applying the same three steps of the STS algorithm to this example, a synchronizing transition set S, can be derived as Si = {[(x + l)%max ( ) y]REC, OUT}. Note that a synchronizing transition is basically a concatenation of some regular transitions. In the CFSM model, this transition concatenation is straightforward. However, in the EFSM model, due to the presence of predicates, the concatenation of transitions needs to concatenate not only the action parts, but also the predicates of the transitions. This is also the only enhancement in the STS algorithm that must be made for the EFSM specification model [2]. In the example of this section, with such an enhanced STS algorithm (Steps 4 and 5) a final converter can be derived as shown in Fig. 12. Note that the action part of the virtual atomic transition Vi is removed (i.e. Vi becomes a null-action transition), since it consists of service transitions only (in this example, it consists of OUT and REC). On the other hand, the predicate part of Vi cannot be removed because it consists
Fig. 12. Example 2: the final converter.
1222
H.- W.J. Jeng, M.T. Liu/Computer Communications 19 (1996) 1216-1225
of some legitimate state variables, as shown in Fig. 12. As a result, the virtual atomic transition Vi of this example cannot be reduced into a removable null transition. Note that a null transition is different from a null-action transition. Consequently, the virtual atomic transition Vt is kept in the final converter specification.
4. STS algorithm in multimedia networks A simulation study [3] shows that, due to the special characteristics (high speed and high connectivity) of integrated multimedia networks, the traditional protocol conversion model will introduce long transmission delays and render a network system useless. This simulation study makes it clear that a different and more efficient approach is needed for protocol conversion in multimedia networks. Therefore, to further demonstrate the flexibility of the STS algorithm described in Sections 2 and 3, another modification is presented in this section for converter generation in multimedia network environments. In the traditional conversion model (Fig. 2), the converter/gateway is a single point of connection for the two networks with protocol mismatches. All traffic between nodes of two different networks must travel the gateway through the gateway. Consequently, becomes a traffic bottleneck. In traditional data networks, since the number of internal nodes is less than a few hundred and internetwork communication is relatively less frequent, the bottleneck effect is tolerable. In fact, the throughput requirement of traditional internetwork communication is in the range of hundreds of Kbits/s or less; therefore, in terms of network interconnection, a high-speed bridge would suffice. In the case of multimedia networks, however, high connectivity means increased probability of traffic through the converter/gateway. Coupled with the high bandwidth requirements on each media stream, the transmission delay at a single point of traffic congestion will become unmanageable. For example, in a regular DQDB network, an intermediate station which attempts to transmit a message into a slot can simultaneously read from and write into the busy bit of the slot passing by to minimize the latency incurred [19]. To support the required transmission speed of a multimedia network, the delays in the intermediate nodes/stations are, in general, less than a few bits in most of the proposed high-speed networks. If an intermediate converter node is used as in the traditional model, the delay could be as high as a few messages, thereby reducing the total throughput significantly. To alleviate internetwork traffic congestion, more gateways could be installed between each pair of networks; however, these gateways would still be points of traffic congestion and delay, thereby reducing the QoS (Quality of Service).
Thus, in contrast to the traditional conversion model (i.e. the intermediate node model) used in previous section, a different model that performs conversion at end nodes is used in this section. In the protocol conversion literature, this category of conversion is known as the protocol compensation approach. In this end node model, it is assumed that a node can be physically connected to a network by simply tapping itself into an access point of the network, in the same manner as plugging in a telephone establishes a connection. This model, without an intermediate converter gateway, performs protocol conversion at the end nodes to reduce intermediate node delay in internetwork communication. Note that a converter gateway must still be used when the networks to be integrated are geographically separated far apart, and tapping into other networks is not feasible. However, it should also be noted that the networks in a multimedia network environment are often overlapped, much as telephone networks and cable TV networks: an average household often contains both cable TV and telephone outlets. Two networks are considered to be overlapping if they cover approximately the same geographical area, and an access point of one network is always close to an access point of the other, such that a node in one network can physically be connected to the other network without unreasonable difficulty. The new conversion model is shown in Figs 13 and 14. In Fig. 13, node N2 in network 2 taps itself into network 1 to initiate internetwork communication with node Nl in network 1. The dotted lines between node N2 and
r_______________________________--___________________, i Abstract Model: ,
:
. . .. . Converterc
:..................................................i Node Nl
Fig. 13. Option l-Conversion
Node N2
at receiving node.
I
H.- W.J. Jeng, M.T. LiulCotnputerCommunication 19 (1996) 1216-1225
1223
: Abstract Model:
:
; I
:
Fig. 15. Example 3: converter entity C. Converta C
: :................................................... NodeNl
Node N2
I
_____
L_________________________------__-_____________
Fig. 14. Option 2-Conversion
at sending node.
network 1 denote the attachment of N2 to network 1. From node Nl’s viewpoint, node N2 is only a newly added node in network 1 running the same protocol. Nl and N2 can be considered as two nodes connected by the same high speed links of network 1. Therefore, Nl would use the regular protocol of network 1 to communicate with N2 without knowing that N2 is a node in network 2. To keep the conversion transparent to high level application programs, node N2 performs the conversion within its low level protocol entities. The abstract model is shown in the dashed box of Fig. 13. Note that in this abstract model, protocol Q (of network 1) is used between nodes Nl and N2. The model in Fig. 14 works in the same way in the opposite direction, i.e. the conversion is performed at the communication initiation node. Due to space limitations, the remainder of this section focuses on the model shown in Fig. 13. In the following, the example in Section 2 (Fig. 3) is again used to demonstrate the applicability of the STS algorithm to multimedia networks. In the example of this section, an end node converter that allows Q, to send messages to Pb will be generated. The first three steps of the algorithm remain the same as before. Therefore, following through the first three steps of the STS algorithm, a synchronizing transition set Si can be derived: S, = {DEL, RSV, CONF, IN}. Step 4 contains the major difference between the new model and the original STS method. Recall that in the original STS algorithm, the intermediate converter specification is derived by composition of peer protocol entities Qb and P, (for this example) at step 4. In the new model, the converter entity C in Fig. 13 is composed of peer protocol entity Qb and the entire protocol P (as a
single entity). Since the peer transitions of P are internal to P and not observable from C’s standpoint, only the service transitions need to participate in the composition in this step. In fact, protocol P is treated as an entity consisting only of service transitions, i.e. the participants of this step in the new model are Qb and P, instead of Qb and Pa. The same coordinated composition operator o is used to derive protocol entity C. In short, protocol entity C in the new model is derived as follows: converter entity C = Qb o P,. In the last step (step 5) of the algorithm, the service transitions from Pa (RSV, BUSY, CONF and IN) and Qb (DEL) must be removed, since only the service interface of Pb needs to be supported by C. Finally, the specification of the resulting converter entity C is shown in Fig. 15. From the converter entity specification shown in Fig. 15, it can be verified that states [3,7l and [1,7] are redundant. This indicates the need for further refinement of the modified STS algorithm. Due to the space limitation, the readers are referred elsewhere [3] for the refinement.
5. Implementation Recently, all five steps of the STS algorithm have been fully implemented. This implementation, STS Protocol Converter Generation Package, is written in the C language running under a standard UNIX operating system, and has less than 1000 lines of C statements. Moreover, when testing with some classical example protocols, such as the ABP (alternating bit protocol) and the go-back-n protocol, it takes only a few seconds to derive a converter specification. In the rest of this section, various features of this STS implementation are briefly described. There are five modules in the STS protocol converter generation package. Each module implements a step of the STS algorithm. These five modules are integrated
1224 sequentially,
H.-W.J. Jeng, M.T. l&/Computer Communications19 (1996) 1216-1225
i.e. the output of one module (except the last module) automatically becomes the input to the next module. The input to the first module includes all seven specifications needed by the STS algorithm, even though the first step only uses the service specifications. The specifications are specified in a tabular form and can be batched into an input file. These specification files are broken down into blocks, each block specifying one entity required as an input to the STS algorithm. The order of the entity specification input is as follows: P,,P,,Pb,Q,,Q,,Qb and R. The converter generator always generates a converter that allows one direction of the traffic from Pa to Qb based on the input specifications. In each block of the input specifications, the first line gives the number of transitions in the block, and each line of the block specifies one transition in the format of (starting state, action, ending state). When specifying a protocol in the EFSM module, the format is (starting state, [predicate] action, ending state). The output of the last module is the specification of a final converter in a tabular form. In addition, the intermediate results from each step are also given in the final output. The intermediate results include specifications of the global system graph (G), the conversion service specification (M), legal paths from M, synchronizing transition sets, etc. A sample input and output can be found elsewhere [4]. In the STS implementation, each of the input and output specifications (FSMs) is treated as a directed graph rooted from the initial state. Since the STS algorithm is basically a group of operations applied to these graphs, the most frequently used function is a graph traverse. Therefore, it was believed that the traverse function would have the most impact on the performance. However, during the search of an efficient traverse function, it was found that either depth first or breadth first traverse will work tine in the STS algorithm. In fact, since converter generation is not a real time process, execution time is not critical as long as a correct converter can eventually be generated within a period of time. In the implementation, breadth first traverse is used. It was mentioned that for multimedia networks, one of the participants of the coordinated composition in step 4 of the STS algorithm is a service specification. To accommodate this, the integrated STS implementation package can be split into individual modules. The user is allowed to specify the input specification to the module of step 4. Since the same coordinated composition is used as in the traditional conversion model, the STS implementation (module of step 4) does not need to know that one of the input specifications consists of only service transitions. Consequently, the same STS implementation package can generate converters not only for protocols
in the CFSM and EFSM models, but also for protocols in a multimedia network environment.
6. Conclusion A formal proof of correctness can be found elsewhere [4], which shows that the STS algorithm always finds a converter that satisfies the given conversion service requirement. If the requirement given is semantically correct, so is the converter constructed, and validation of its correctness is not needed. This is one of the main reasons that the STS algorithm can be easily implemented, and is more practical than most of the other protocol conversion methods, which require complex and expensive validation procedures. Finally, for future research, it is believed that various techniques devised during the STS research could also be used to solve other issues in high speed internetworking. For example, as a future research subject, it has been considered to use the Petri net model and the synchronization mechanism from the STS algorithm to solve the media mixing problem. It is anticipated that such research will mature along with the maturity of high speed networks in the future.
Acknowledgements Research reported herein was supported by U.S. Army Research Office, under contract No. DAAL03-92-G0184. The views, opinions, and/or findings contained in this paper are those of the authors and should not be construed as an official Department of the Army position, policy or decision.
References [l] H.J. Jeng and M.T. Liu, From service specification to protocol converter: a synchronizing transition set approach, Technical Report No. OSU-CISRC-3/92-TR-10, The Ohio State University, Columbus, Ohio, March 1992. [2] H.J. Jeng and M.T. Liu, Protocol conversion: synchronizing transition set approach in EFSM model, Technical Report No. OSUCISRC-l/93-TR-2, The Ohio State University, Columbus, Ohio, January 1993. [3] H.J. Jeng and M.T. Liu, Protocol conversion in multimedia networks: simulation and algorithm, Simulation, 64 (January 1995) 51-60. [4] H.J. Jeng, Synchronizing Transition Set Approach to Protocol Conversion. PhD thesis, The Ohio State University, June 1995. [5] K.L. Calvert and S.S. Lam, Deriving a protocol converter: a topdown method, Proc. ACM SIGCOMM Symposium, Austin, Texas, September, 1989, pp. 247-258. [6] K.L. Calvert and S.S. Lam, Adaptors for protocol conversion, Proc. IEEE INFOCOM, San Francisco, CA, June 1990, pp. 552-560. [7j K.L. Calvert and S.S. Lam, Formal methods for protocol conversion, IEEE J. Selected Areas in Comm., 8 (January 1990) 127-142.
H.- W.J. Jeng, M.T. LiujComputer Communications 19 (1996) 1216-1225 [8] K. Okumura, Generation of proper adaptors and converters from
a formal service specification, Proc. IEEE INFOCOM, San Francisco, CA, January 1990, pp. X4-571. [9] Y.W. Yao and M.T. Liu, Constructing protocol converters from service specification, Proc. IEEE ICDCS-12, Yokohama, Japan, June 1992, pp. 344351. [lo] K. Okumura, A formal protocol conversion method, Proc. ACM SIGCOMM Symposium, Stowe, Vermont, August 1986, pp. 30-38. [ll] Y.W. Yao, W.S. Chen and M.T. Liu, A modular approach to constructing protocol converters, Proc. IEEE INFOCOM, San Francisco, CA, (June 1990) pp. 572-579. [12] S.S. Lam, Protocol conversion-correctness problems, Proc. ACM SIGCOMM Symposium, Stowe, Vermont, (August 1986) pp. 1928. [13] K.L. Calvert and S.S. Lam, An exercise in deriving a protocol converter, Proc. ACM SIGCOMM Symposium, Stowe, Vermont, (August 1987) pp. 151-160.
1225
[14] S.S. Lam, Protocol conversion, IEEE Trans. Software Engineering, SE-14 (March 1988) 353-362. [15] J.C. Shu and M.T. Liu, A synchronization model for protocol conversion, Proc. IEEE INFOCOM, Ottawa, Canada, April 1989, pp. 276-284. [16] J. Chang and M.T. Liu, Using protocol validation technique to solve protocol conversion problems, Proc. 9th IPCCC, Scottsdale, Arizona, March 1990, pp. 539-546. [17] J. Chang and M.T. Liu, An approach to protocol complementation for interworking, Proc. IEEE ICSI, Morristown, New Jersey, April 1990, pp. 205-211. [18] J.E. Hopcroft and J.D. Ulhnan, Introduction to Automata Theory, Language and Computation. Reading, MA: AddisonWesley, 1979. [19] 0. Sharon and A. Segall, A simple scheme for slot reuse without latency for a dual bus configuration, IEEE/ACM Trans. Networking, (February 1993) 96-104.