boch90b - from ieee library

8/13/2019 Boch90b - From IEEE Library

1/10

12 IEEE J O U R N A L ON S E L E C l E D A R E A S IN C O M M U N I C A T I O N S . V O L U. NO I J A N U A R Y 1990

Design Principles for Communication GatewaysGREGOR V . BOCHMANN, S E N I O R M E M B E R , IEEE, A N D PIERRE MONDAIN-MONVAL

Abstracr-The purpose of this paper is to define principles that applyto the design of communication gateways between heterogeneous com-puter systems, and to identify strategies to solve incompatibilit ies in asystemat ic manner . The importance of communicat ion service com-mon properties is explored in detail. The modification of the serviceavailable for interworking due to subset selection and service concat-enation is discussed. Various methods of adaptation are described. Twoarchitectural options for the design of communication gateways areexplored, namely conversion at the service level or at the PDU level.While the former is conceptually simpler, various optimizations arepossible through the latter approach. A method for deriving the spec-ification of a protocol adapter from the two protocol specifications isalso given. All these issues are explained with a number of s imple ex-amples .

I. INTRODUCTIONHE concept of gateways was first introduced for theT nterconnection of different communication networks.

Gateways, sometimes also called relays are now used forthe interconnection of public packet-switching data net-works and private data processing networks, often includ-ing local area networks. These gateways belong to theNetwork layer of the OS1 reference model (OS1 RM). Inthis context, any difference between the communicationservices provided by the different networks has a strongimpact on the gateway design and functions. Interworkingat other layers of the reference model has been consid-ered, for instance, at the transport or application layers.An OSI-gateway for a non-OS1 system is a typical ex-ample.

An overview of the issues involved in the interworkingbetween heterogeneous networks is given in [6]. Muchliterature exists about solving interconnection problems inparticular cases, and about incompatibilities between dif-ferent systems and approaches to their resolution (see forinstance [7]). The purpose of this paper is to explain prin-ciples that apply to the design of gateways, to identifjstrategies for solving incompatibilities in a systematicmanner, and to provide clear definitions of the relevantconcepts.

Already Gien and Zimmerman [ 5 ] pointed out that in-terconnection o networks must be based on a commoncommunication service provided in both networks. Thisprinciple is further investigated in this paper. Some pre-vious work does not explicitly take into account the com-munication service [9], [ l 11. We indicate in Section Vthat a specification of a protocol converter can be obtained

Manuscript received October 15, 1988: revised August 20. 1989.The authors are with the Departement d'lnformatique et de RechercheI E E E Log Number 8932038.Operationelle, Universite de Montreal. Montreal. P . Q . . Canada.

automatically if a mapping between the respective ser-vices is defined.

In order to clarify the issues, much of the discussion ofthis paper is based on simple examples showing the prin-ciples involved. In some cases, examples from existingcomputer communication protocols are also discussed.

Section 11 presents some basic interconnection scena-rios. The importance of a common (often subset) com-munication service is explored. Concatenation of servicesis defined in Section 111. Different concatenation ap-proaches depending on the types of interfaces and ser-vices are discussed. Concatenation properties are inves-tigated. The concept of concatenation invariance isdiscussed with some examples.While the discussion up to that point is mainly con-cerned with the service characteristics, Section IV dealswith an alternative approach already widely used, proto-col conversion, where the gateway needs to know in detailthe different protocols to explicitly establish a correspon-dence between them. Advantages and drawbacks of thisprotocol level adaptation approach are discussed. Amethod for deriving the specification of an adaptationmodule from the interworking protocol specifications isalso given.

Finally, Section V contains a list of general conclu-sions.11. INTERCONNECTIONF COMMUNICATIONERVICES

A . A Basic ExampleThis basic example is the interconnection of modules.

called Basic Medium, providing a simple message trans-fer service (Fig. 1 . Such a module has two ports throughwhich it interacts with its users. The port on the left-handside of the picture (sending port S allows for a user tcsend a block of data through a Data-request event, whilethe port on the right-hand side (receiving port R allow:for a user to receive a data block through a Data-indica-tion event. For a given module, blocks are delivered irFIFO order, i.e., blocks sent through successive Data-request events are delivered in the same order as Data-indication events at the other end of the medium. Thecommunication service provided by the Basic Medium isused by two types of processes, sender and receiver pro-cesses, which execute an unspecified application proto-col.B . Service Concatenation

The first interconnection scenario is trivial. Two BasicMedia are interconnected as shown in Fig. 2. D ata - id - -

0733-8716/90/0100-0012$01 OO 990 IEEE


2/10

, .

B O C H M A N N A N D M O N D A I N - M O N V A L D E S IG N P R I N C I P L E S FOR C O M M U N I C A T IO N G A T E W A k S

Fig. 1 . Basic Medium.

Fig. 2 . Basic Media direct concatenation

cation events at the receiving port of the left medium areidentified with Data-request events at the sending port ofthe right medium. This kind of interconnection is calleddirect concatenation and is represented in Fig. 2 by thehorizontal line between the two ports at the gateway site.Thus, a Data-request event at the sending port of the leftmedium leads to a Data-indication and a Data-requestevent at the interconnection point, and eventually to aData-indication event at the receiving port of the right me-dium. Service concatenation and various related problemsare investigated in Sections I11 and IV.C . Service Enhancements

The following example introduces interconnectionproblems related to discrepancies in t h e communicationservices. The previous example is used with the followingconstraint. The left medium handles data blocks of sizeup to Large, while the right-hand side medium handlesdata blocks of size up to Small (with Small significantlysmaller than Large). Therefore, data blocks of a size be-tween Small and Large are handled by the left mediumwithout any trouble, but cannot go further through theright medium. Three approaches can be used to solve thisproblem.

1 The simplest approach is to use the minimum ser-vice subset, i.e., to forbid users at the sending port of theleft medium to request transmission for data blocks of asize greater than Small. However, this solution is not verypowerful in the sense that the full capabilities of the com-munication services provided by the left-hand side me-dium are not used any more. Interconnection realized insuch a way would force applications using these servicesto be modified, going against the transparency require-ments.

2 A regional complementation protocol can be builton top of the less powerful medium, namely the right one,to segment blocks received from the left medium intoblocks of a size no longer than Small (Fig. 3 ) . This ap-proach thus upgrades the lower level service to the levelof the other one. An entity must reside on all systemswithin the less powerful network to realize this protocol.The dashed line in Fig. 3between the two entities indi-cates that a protocol exists between these two entities, but

mP+TS e r v i c e Y

Fig. 3. Regional complementation protocol.

does not represent a real connection. All protocol dataunits (PDUs) are exchanged through the underlying ser-vice Y .

3 ) The last approach is quite similar to the second one.A complementation protocol is introduced throughout theentire system, on top of the minimum service subset (Fig.4 , and may also provide additional services not providedby any of the interconnected components. Additional ent-ities in Fig. 4realize a global complementation protocolproviding a common service to all users.

Although quite simple, this example shows differentproblems related to transparent interconnection of com-munication services.

It is necessary to cope with applications using exist-ing services when interconnecting these services. In orderto avoid a great deal of burden for interconnected appli-cations, solution of the first type is to be avoided.

The second solution is better suited, but the follow-ing question arises:

-What is the needed enhancement function to bridgethe gap between the two services, i.e., to upgradethe lower level service up to the level of the otherone?

The third solution requires in addition the consider-ation of a common service subset:

-What is the common service subset?-What are the desired services to provide?-What is the necessary function to offer on top of the

As previously shown, service enhancement approachesare based on concatenation. The second approach relieson concatenation of one original service with an up-graded service. The third approach relies on services con-catenation with restriction to a common service subset;then additional facilities are built up on top. Therefore,concatenation is a central issue when interworking withdifferent communication services.

The discussion in this paper mainly focuses on the ser-vices concatenation principles. It will be shown that care-ful analysis of concatenation properties is necessary be-fore defining any complementation protocol.

common service subset?

D . Realistic ExamplesThe classical examples of gateways are used for com-

puter network interconnection.I Network Layer: Within the OS1 reference model,

Network interconnection is foreseen through so-calledNetwork relays. The general protocol hierarchy (Fig. 5 )within the Network layer (OS1 NL) foresees a combina-tion of the approaches of Figs. 3and 4.

The SNAP (Sub-Network Access Protocol) sublayer


3/10

14 I E E E J O U R N A L ON S E L E C T E D A R E A S I N C O M M U N I C A T I O N S . VOL X. N O I J A N U A R Y I O Y I I

LFig . 4. Global complementation protocol.

Fig. 5 . OS1 Network sublayers

provides the interface to access a particular network (e .g .,X . 2 5 .The SNDCP (Sub-Network Dependent Convergence

Protocol) sublayer, corresponding to the complementa-tion protocol of Fig. 3, is used to provide a uniform ser-vice over all networks participating in the interconnec-tion, which individually may provide different types andgrades of communication services.

Sublayer SNICP (Sub-Network Independent Conver-gence Protocol) provides addressing OS1 NA) and otherglobal functions for internetworking.2) Transport Layer: Another example is interconnec-tion at the Transport level. The OS1 Transport serviceOS1 TS), similar in nature to the Network service, is acommon service provided by the different classes of OS1Transport protocols (OS1 TP) over different network con-figurations, and is used by all higher level protocols withinthe OS1 reference model. For the interconnection of OS1systems using different classes of Transport protocols,e.g., class 4 within a local area network and class 0 or 2over long distance networks, concatenation of transportservices can be envisaged [3] .

Interconnection at the Transport level can also be con-sidered between the OS1 and DARPA TCP/IP protocolhierarchies. TCP is a protocol similar to the OS1 class 4protocol, and its service is similar to the OS1 Transportservice. The selection of a suitable service subset includ-ing normal data transfer is, however, not straightforward[SI, [2]. Some difficulties are related to the identificationof message boundaries and addressing. The graceful closefacility, in addition to the abort included in the subset,can be provided by use of the OS1 Session Release func-tion, according to Fig. 3.3) Messaging Serv ices: Another example correspond-ing to the protocol architecture of Fig. 3 is the Teletexaccess procedure to the message handling systems (MHS)as defined by CCITT in [18]. The messaging service tobe accessed by that procedure includes functions not pro-vided by Teletex, such as delivery confirmation, messagestore and retrieve, probes, . . Therefore, the approachof Fig. 3was chosen where the defined complementationprocedure is executed between the Teletex terminal and

the MHS-Teletex conversion facility, which plays the roleof a gateway between the M H S systems and the Teletexnetwork.

111. SERVICEONCATENATIONService concatenation allows us to build up a global

communication service from two or more basic commu-nication services. The interfaces of the global service of-fered to users are the same as those offered by the basicservices. Concatenation is thus mainly concerned withconnecting interfaces at gateway site (s) .

To define services concatenation, we must first inves-tigate how a service is defined, i.e., what its interface?are, which events can occur at these interfaces, and whichproperties about occurrences of these events can be stated.

We then define three concatenation methods coping witt-connecting: 1) services with identical interfaces; 21equivalent services with different interfaces; 3 service:,of different types.

The concept of concatenation invariance is then intro-duced and discussed with several examples.A . Serv ice De nition

Service definition includes two parts. The first is theabstract definition of the interfaces of the Communicationservice. The second consists of the description of globalproperties relating events at the different interfaces.

I User-Provider In terface: An interface does not al.-ways explicitly exist but defines the logical exchanges ofinformation occurring between the user and the provide-of the service. User and provider might be two logicalparts of the same process, or two different processes communicating through an implementation of a real interface.2 User-Provider In terac t ions: An interaction throughan interface consists of an exchange of information. Onr:

side of the interface is responsible for initiating the ex-change and selecting the appropriate values for the param-eters to be exchanged. Therefore, an interaction-some -times called service primitive-is described by its name.its parameters, and its initiator. Interactions are supposedto be executed in rendez-vous. Conceptually, only oneinteraction may occur at one time.3 Temporal Ordering: The service specification also

defines which sequences of interactions are legal. We canconsider two types of ordering. Local ordering describe.;the possible sequences at one interface of a communica-tion service. Global ordering describes the possible se-quences of interactions at both interfaces of the commu-nication service. Such orderings can be described bymeans of a finite state machine or any other suitable no-tation.4 ) Other Serv ice Propert ies: Usually, more specificproperties must be defined for each interaction, in addi-tion to the temporal ordering. Very often, service prop-erties will correlate parameters of interactions at one i n-terface of the service with parameters of other interactionsat the same interface or at the remote one. As in the cas:of temporal ordering, the properties can be classified intolocal constraints pertaining to a single interface and globa


4/10

, , .R O C H M A N N A N D M O N D A I N - M O N V A L : D E S I G N P R I N C I P L M F OR C O M M U N I C A T I O N G A T E W A Y S

constraints. In the following, we use the term global prop-erties to denote the combination of the global orderingrules and the other global constraints. For instance, theBasic Medium satisfies the following two global proper-ties.

Every Data-request interaction initiated at the send-ing port eventually generates a Data-indication interactionat the receiving port (error-free medium).

Two successive Data-request interactions initiated atthe sending port eventually generate two successive Data-indication interactions (FIFO order).5 Example: OSI Transport Service: As a realistic ex-

ample, we consider the OS1 Transport service as shownin Fig. 6 . This service distinguishes two kinds of ports,so-called calling and called ports.Interactions: A definition of this service for the callinguser describes the possible interactions at the calling ser-vice interface and their parameters.Interactions initiated by the calling user

-TCONreq (calling, called: transport-address;QoS: quality-of-service;options: user-options;data: data-type)

-TDATAreq (user-data: data-type)-TEXDTreq (user-data: data-type)-TDISCreq (reason: data-type)Interactions initiated by the prov ider at the cd i n gport-TCONconf (calling, called: transport-address;QoS: quality-of-service;

options: user-options;data: data-type)

-TDATAind (user-data: data-type)-TEXDTind (user-data: data-type)-TDISCind (origin: (user, provider);

reason: data-type)Interface for the called user is quite similar although theconnection establishment phase involves different inter-actions.Interactions initiated by the called user

-TCONresp (calling, called: transport-address;QoS: quality-of-service;options: user-options;data: data-type)

-TDATAreq (data: data-type)-TEXDTreq (user-data: data-type)-TDISCreq (reason: data-type)Interactions initiated by the provider at the calledport-TCONind (calling, called: transport-address;

QoS: quality-of-service;options: user-options;data: data-type)

-TDATAind (data: data-type)-TEXDTind (user-data: data-type)-TDISCind (orgin: (user, provider);

reason: data-type)Local Ordering: This service definition is com-pleted with the legal sequences of interactions repre-

iaa i ngOS -T -s e rv i c e

IFig. 6 OS1 Transport service.

T D I S C r e q / i n d i C O N r e q * / i n d T D A i A r e q I i n d

T E X D T r e q I l n dFig. 7. Local ordering of Transport primitives.

sented as a finite state machine in Fig. 7.The orderingrules for both kinds of interface are represented by thesame diagram. Interactions that may occur at the callingport only are identified by a star symbol. Those occurringat the called port only are identified by an apostrophysymbol. It is to be noted that sequences of interactionsoccurring at both interfaces are not described.Local Constraints: Additional constraints on interac-tions parameters are stated as follows.

The QoS and options parameters of a TCONconf in-teraction must be smaller than or equal to the corre-sponding parameters of the TCONreq interaction.

The QoS and options parameters of a TCONresp in-teraction must be smaller than or equal to the corre-sponding parameters of the TCONind interaction.Global Properties: Global properties of the Transporlservices are informally stated.

I) Connection Establishment:A TCONreq interaction at the calling port implies asubsequent TCONind at the called port, unless a TDISC-req or TDISCind interaction occurs at the calling port.

A TCONresp interaction implies a TCONconf inter-action at the calling port unless a TDISCreq or TDISCincinteraction previously occurred at that port.2) Data Transfer:

A TDATAreq (respectively, TEXDTreq) interactiorigenerates a remote TDATAind (respectively, TEXDTind) interaction with the same data parameter value (reliable transfer).

Two successive TDATAreq interactions from thesame user will generate two successive TDATAind interactions, in the same order (FIFO property-normal data)

Two successive TEXDTreq interactions from the.same user will generate two successive TEXDTind interactions, in the same order (FIFO property-expediteddata).

A TEXDTreq following a TDATAreq may generatea TEXDTind before the TDATAind is generated (expe-dited data transfer may bypass normal data transfer).3 Disconnection:

A provider-initiated disconnection leads to the OC-


5/10

16 I E E E JOU R NA L . O N S E L E C T E D A R E A S I N C O M M U N I C A T I O N S . VOL. X. NO I JA N U A R Y 1940

currence of a TDISCind interaction at the ports where noTDISCreq interaction already occurred.

A TDISCreq interaction will generate a remoteTDISCind interaction if no provider-initiated disconnec-tion occurs at the same time and no TDISCreq interactionoccurred at the remote port.

A provider or user initiated disconnection may implysome loss of in-transit data.The TDISCind interaction indicates with the origin

service provider as having a user origin. If a TDISCindindicates a provider-initiated disconnection, the informa-tion cannot be transmitted in the parameter of the corre-sponding TDISCreq.2 Interface Aduptation: As an example of different in-terfaces providing the same abstract service, we consideran alternative description of the Transport service inter-face. The TCONreq and TCONconf interactions are re-placed by the following procedure.parameter whether the disconnection was initiated by the

remote user or by the service provider. In the first case,the reason parameter is the reason parameter of the cor-responding TDISCreq interaction. I n the latter case, t h ereason parameter is selected by the service provider.When two TDISCind interactions are initiated at bothends, the origin parameter value must be provider.

- .TCALL (calling, called: transport-address ;proposed-QoS: quality-of-service;selected-QoS: quality-of-service;proposed-options: user-options;selected-options: user-options;status: boolean)

B. Concatenation MethodsThree different methods of concatenation are discussed,

depending on the services to be concatenated (type of pro-vided services, interfaces).

1 Direc t Concatenat ion: The example of the inter-connection of two Basic Media is very simple since inter-actions at both interfaces can be directly identified. Wecall direct concatenation an interconnection of two com-munication services where each interaction of one inter-face is identified with (mapped onto) a corresponding in-teraction of the other connected interface. Anotherexample is the Transport service previously described.The mapping to be performed by the gateway between thetwo interfaces (one calling, the other called) is simply thefollowing.

TCONind interactions are mapped onto TCONreqinteractions.

TCONconf interactions are mapped onto TCONrespinteractions.TDATAind interactions are mapped onto TDA-TAreq interactions.

TEXDTind interactions are mapped onto TEXDTreqinteractions.

TDISCind interactions are mapped onto TDISCreqinteractions.I n general, two interfaces A and B can be directly con-catenated if the following conditions hold.

1 Interactions initiated by the provider at interface A(respectively, B ) can be mapped onto interactions initi-ated by the user at interface B (respectively, A ) ; thisshould include a mapping of corresponding parameters ofthe mapped interactions.2 Legal sequences of interactions initiated by theprovider at interface A (respectively, B ) are consistentwith the legal sequences of interactions that could be ini-tiated by a user at interface B (respectively, A ) .

It is interesting to note that direct concatenation is notcompletely possible for t h e OS1 Transport service. In fact,the parameters of a TDISCind cannot be directly mappedonto a parameter of the TDlSCreq. According to the OS1specification, a TDISCreq is always interpreted by the

The status parameter is returned as true (respectively,false) after successful (respectively, failed) establishmentof the Transport connection. The proposed-QoS and pro -posed-opt ions parameters are set to appropriate values bqt h e calling user. The selected-QoS and selected-option.parameters indicate which values have been selected forthe established connection. We note that calling this pro-cedure is equivalent to initiating the TCONreq interac-tion, and that returning from it is equivalent to the occur-rence of the TCONconf (respectively, TDISCindlinteraction.

This alternative Transport interface cannot be directljconcatenated with the interface described in Section 111A-5). However, service concatenation may be realized bjan interface adapter, as shown in Fig. 8 , which calls theTCALL procedure after the occurrence of a TCONind atthe called interface, and initiates a TCONresp or TDISCreq at this interface when the procedure returns control.

This interface adaptation provides a local mapping:within the gateway between the concatenated service in -terfaces. It differs from the function of an enhancemententity which executes a protocol in relation to other re-mote system components, as shown in Fig. 3 .In general, identical services can be concatenatedthrough an interface adapter module if:

1) abstract interactions can be extracted from thetwo interface specifications; and2 the conditions defined for direct concatenation i nSection 111-B-1) hold for this set of interactions.3 Service Adaptation: In the above example the two

concatenated services are not identical, but abstractlyequivalent since some equivalence relation between theinteractions at t h e different interfaces could be defined.The same approach can also be used for the minimumsubset service if the services to be concatenated are notequivalent. As an example, we consider the concatenationbetween the Basic Medium and the OS1 Transport ser-vice, as shown in Figs. 9 and 10. Without using a serviceenhancement, as discussed in Section 11-C, we are re-stricted to using the minimum service subset, which is i nthis case equal to the service provided by t h e Basic Me-dium. We therefore consider the TDATAreq (respec-


6/10

17O C H M A N N A N D M O N D A I N - M O N V A L D ESI G N PR I N C I PLES F O R C O M M U N I C A T I O N CA I kWAYS

L a l l i n g L a l l e d 53SI-T-se rv ice Bas ic Med ium

Interface Adapter The connection is kept, based on a time limit or an

J C > I Eer5 a l l i n g L a l l e d

Fig. 8 . Concatenation with interlace adapter.

I Bas ic Med ium I PSI-T-se rv iceFig . I O . Basic Medium and OS1 Transport

tively, TDATAind) interaction equivalent to the Data-re-quest (respectively, Data-indication) interaction. If thesewere the only interactions to be considered, the directconcatenation approach could be used for the gateways inFigs. 9 and 10 for providing the basic subset service.

However, the OS1 Transport service requires a connec-tion to be established before the TDATAreq and TDA-TAind interactions can occur. Therefore, the gateway ar-chitecture with an adapter module (see Fig. 8 may beused where these additional interactions of the Transportservice are handled by the adapter module. If the left userin Fig. 9, for example, wants to send data to the rightuser, he/she will first establish a connection to the gate-way through the Transport service. The adapter modulewill accept the incoming TCONind interaction by issuinga TCONresp if the parameters are acceptable, e.g., thecalled address is recognized as reachable through the BasicMedium service; otherwise a TDISCreq will be issued.Incoming TDATAind and TEXDTind interactions will beforwarded by the adapter as Data-requests over the BasicMedium, while an incoming TDISCind interaction can beignored.

In the case of data transfer in the opposite direction (seeFig. lo), the adaptation is less straightforward. Theadapter module i n the gateway has to decide when and forhow long to establish Transport connections to the receiv-ing user. When it receives a Data-indication and noTransport connection is established, a new connectionmust be set up before the data can be forwarded. Possiblestrategies for terminating the connection are the follow-ing, all transparent to the users.

The Transport connection is maintained forever, orat least until the Transport service user explicitly requestsa disconnection.

expected number of data transfer requests.transfer of one block of data.

The connection is released immediately after the

C . Concatenation InvarianceWe say that a global property of a communication ser-vice is concatenation invariant if it remains satisfied on

an end-to-end basis over several concatenated communi-cation services and it is satisfied by each service individ-ually. In the following we consider different examples ofconcatenation to question whether invariance can be guar-anteed. As will be shown, the answer turns out to besometimes.

1 ) An Example: Delivery Conjirmation: The first ex-ample is derived from the Basic Medium described in Sec-tion 11-A. A new interaction called Data-confirmation isadded which provides the sending user with a kind of de-livery confirmation. The following three different types ofconfirmation can be considered.Type A : This first type of confirmation informs theuser that a data block has been received by the networkand will be forwarded to the destination user (Fig. 1 1 .Type B: It informs the sending user that a data blockhas been received by the receiving user (Fig. 12) .Type C: This third type of confirmation is only is-sued after the receiving user has explicitly acknowledgedthe receipt of the data by initiating a Data-response inter-action (Fig. 13).

Clearly, these different confirmations have different se-mantics. The first type of confirmation has a local confir-mation meaning, the second one has a remote confirma-tion meaning, and the third one has a user-to-userconfirmation meaning. In Figs. 11-17, solid (respec-tively, dashed) arrows denote Data-request and Data-in-dication (respectively, Data-response and Data-confir-mation) interactions. Numbers associated with arrowsrepresent a relative temporal ordering. An arrow withoutany associated number denotes an interaction for whichno relative temporal ordering is defined.

We consider in the following four interconnection sce-narios. The three first scenarios consider concatenation ofidentical services. The mapping occurring at the gatewaysite is explained case by case. The last scenario considersinterconnection of two different services.Type A ConJirmation: The gateway maps Data-in-dication interactions from the left service to Data-requestinteractions to the right service. The Data-confirmationinteraction is not mapped onto any other interaction (seeFig. 14 .Here the Data-confirmation has no global sig-nificance, only a local one. Therefore, concatenation in-variance holds vacuously.Type B Conjirmation: The same mapping as in theprevious case is considered. Here, a Data-confirmationdelivered to a sending user does not imply that the sentdata were delivered to the receiving user (Fig. 15);it onlyimplies that the data were received by the gateway. Glob-ally, therefore, the meaning of the confirmation loses its


7/10

18

L IFig. I I Local delivery Confirmation

Fig. 12 Remote delivery confirmation.

IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS VOL. X. NO I JANUAKY I Y W

Fig. 13. User-to-user delivery confirmation.

Fig. 15. Type B service concatenation.

Fig. 16 Type C service concatenation.

Fig. 17. Type A and C service concatenation.

Fig. 14. Type A service concatenation.

remote character; however, it implies a Type A con-firmation. We conclude that the global property of theType B Data-confirmation is not concatenation invariant.Type C Conjirmation: A direct mapping between aData-confirmation interaction from the right service ontoa Data-response interaction to the left service ensures thatthe Data-confirmation delivered to the sending user has auser-to-user meaning (Fig. 16 . Here the sending user re-ceives the confirmation only after the receipt of the databy the receiver. The global confirmation property is there-fore concatenation invariant.Type A and C Conjirmafion: In this case (Fig. 17),it is obvious that the user-to-user confirmation meaningcannot be provided whatever the mapping at the gatewaysite is. This was expected since one of the concatenatedservices alone does not provide such a confirmation.2 Orher Examples: It seems that most global proper-ties of communication services are concatenation invari-ant. Simple data transfer, as represented by the Basic Me-dium clearly is. The previous discussion shows thatdelivery confirmation of Type C is a good service sinceit is concatenation invariant, which simplifies interwork-ing.

Another important example is flow control. The OS1Network and Transport services have back-pressure flowcontrol at the interfaces. The local constraint requires thatno data can be sent over an interface when the receivingside invokes flow control. The global property of thecommunication service postulates that the service provi-der may-and eventually will-invoke flow control at itsinterface with a sending user in response to flow controlinvoked by the receiving user at the remote interface. In

a straightforward implementation of flow control. withoutbuffering in the gateway, a gateway will invoke flow con-trol at the interface where it receives data when flow con-trol is invoked at the interface where it sends. This meansthat flow control invoked by a receiving user over a con-catenated communication service usually will give rise toflow control invoked at the interface of the sending user.This means that back-pressure flow control is concatena-tion invariant.

In the case of the OS1 Transport protocol discussed i nSection III-A-5), all global properties are concatenationinvariant, except the significance of the origin parameterof the TDISCind interaction. As already mentioned i nSection 111-B- I , this parameter does not allow for directconcatenation. Here, problems arise when one of the tw3Transport services initiates a disconnection due to someinternal error. A TDISCind interaction occurs at both endsof the service, and the gateway thus has to trigger aTDISCreq interaction at the interface of the other service.The origin parameter of the TDISCind interaction indi-cates a provider-initiated disconnection, with the reasovparameter detailing the cause of the disconnection. TheTDISC-req interaction eventually generates a TDISCindinteraction to the remote user with the origin parameterindicating a user-initiated disconnection (Fig. 18). Thw,the two users have a different view of the disconnection.Properties stated for the disconnection service are notmaintained when Transport services are concatenated.

The easiest solution to this problem seems to be theaddition of an origin parameter to the TDISCreq interac-tion such that direct concatenation becomes possible atthe gateway. The gateway may then use provider as avalue of the origin parameter of the TDISCreq generatedin the case described above.3) Handling Noninvariant Properties: As shown by theexample of interworking between two networks providingType B confirmation, not all global properties of corn-


8/10

,, .B O C H M A N N A N D M O N D A I N -M O N V A I . : D E S IG N P R I N C I P L E S FOR C O M M U N I C A T I O K G A T E W A Y S 19

munication services remain invariant under concatena-tion. If such noninvariant properties are nevertheless re-quired for the resulting end-to-end communicationservice, it is necessary to use a complementation proto-col, as discussed in Section 11-C. In the case of Type Bconfirmation, there are two possible architectures.

A new Data-confirmation primitive with end-to-endsignificance may be provided by a global complementa-tion protocol on top of the common subset service asshown in Fig. 4. In this case the confirmation services ofthe concatenated services are not used at all.

A complementation protocol that operates only overthe left network shown in Fig. 15(similar to Fig. 3 pro-vides a Type C confirmation. This enhanced service isused by the gateway to forward the Type B confirmationreceived from the right network of Fig. 15to the sendinguser on the left network.

It is to be noted that both of these complementation pro-tocols require a data transmission service from right to leftfrom the underlying network, while the Basic Medium as-sumed in our example only provides this service from leftto right. However, any realistic network will provide datatransfer in both directions; our example is over-simpli-fied.4) Quantitative Properties: Noninvariant: The globalproperties discussed above are of qualitative nature.Quantitative properties are also important, in particularfor performance considerations. It is important to note thatthe latter properties are not concatenation invariant; in-stead they behave in an additive manner, or some othernumerical fashion.

The most important quantitative properties of a com-munication link are its delay and maximum throughput.If we concatenate two such links with delays D1 and 0 2 ,and maximum throughputs T1 and T 2 , respectively, andif we can ignore the degrading influence of the gateway,we obtain an end-to-end communication service with adelay equal to D1 0 2 and a maximum throughput equalto the minimum of T1 and T 2 . This shows that the delayis additive under concatenation, while the throughput fol-lows the minimum limit-similar to the maximum datablock length discussed in Section 11-C.

IV. SERVICEDAPTATIONERSUS ROTOCOLC O N V E R S I O NThe adaptation issues so far discussed rarely required

the consideration of protocols but only of services. Oneobjective of this DaDer is to Doint out that most comDati-

bility issues for interworking and gateways can be dis-cussed in terms of compatibility of services.A . Service Adap tation

The easiest way to convert between different protocolsis through a common service boundary, as previously dis-cussed. The example of the OS1 Transport service andprotocols showed this clearly. Fig. 19shows a possiblearchitecture for interworking between different protocolhierarchies used in different networks. The conversion isdone at a level y assuming that the protocols in the twonetworks above that level are compatible. The gatewayincludes implementations of both protocol hierarchies, upto layer n , and provides for concatenation at the ( N )-ser-vice level. We call this approach a gateway based on ser-vice adaptation (called service interface conversion in1101).B . Protocol Conversion

It is possible to discuss the interworking of networkswith different protocols directly at the level of the in-volved protocols. We call protocol conversion or conver-sion at t h e PDU level a situation where the gateway func-tion is defined explicitly in terms of the PDU's which areexchanged within the two interconnected networks ac-cording to their respective protocols. This approach is as-sumed in [8], 191, and [ 111. Various alternatives forTransport gateways, for instance, are discussed in [3 ] .

It is important to note that conversion at the PDU levelis generally more complex to specify and more difficult toimplement. The advantage of service adaptation is thatexisting protocol implementations can be used within thegateway; only an adaptation between the two service in-terfaces is to be provided. The latter can be quite simpleif the service interfaces of the respective protocol imple-mentations are similar.An architecture for PDU-level conversion is shown inFig. 20.The gateway includes separate implementationsof the lower layers protocols, up to and including layer( N = 1 , and the protocol adapter module which does thePDU conversion for the respective level N protocols.Adapters providing PDU conversion for several layers ofprotocols together can also be considered [101. The com-parison of Figs. 19and 20 yields the following importantfact about the protocol converter. The behavior of thisconverter module should satisfy all the properties definedby the behavior of the two respective protocol entities in-terconnected at their respective service interfaces throughthe service interface adapter as shown by the dotted boxin Fig. 19.

The above fact can be used to derive a specification ofthe protocol adapter from the two protocol specificationsfor which interworking is desired [4]. Such a specificationis simply given by the composition, as shown by the dot-ted part of Fig. 19, of the protocol specifications-defin-ing the behavior of the protocol entities at layer N-withthe specification of the service interface adapter.

In addition to the properties that follow from the spec-


9/10

20 I EEE J O U R N A L O N SELEC TED A R EA S I N COMMUNICATIONS. VOL 8. NO I. JANUARY 1490

- 2 -3 ...

Fig. 19. Service adaptation architecture.

- - - - - - - - - -

Fig. 20. Protocol conversion architecture

ifications of the interconnected protocols, a protocol con-verter may satisfy certain other properties which are re-lated to interworking strategies and optimizations.Different optimizations concerning acknowledgments arediscussed in [ 3 ] . Different ways to optimize the imple-mentation structure of the protocol adapters are discussedin [lo].

V . CONCLUSIONThe main conclusions from the discussion in this paper

are the following.1 Interworking is relatively straightforward for thesubset of communication services which are available inall interworking systems2 Interworking may be realized at different levelswithin the protocols hierarchy. Above the chosen level,the protocols of the interworking systems must be com-patible.3 ) Certain differences in the communication servicesfor which interworking is desired can be accommodatedthrough additional complementing protocol sublayerswhich are especially introduced in one of the networks toobtain a communication service equivalent to the oneavailable in the other one. This requires additional sub-layer entities in the gateway and the host computers par-ticipating in interworking activities.4) Those properties of the interconnected communica-tion services that do not have the so-called concatenationinvariance will not be preserved in the case of interwork-ing. If all properties are concatenation invariant the userprocesses using the service do not see any qualitative dif-ference between ''local'' communication and far dis-tance interworking.

5 ) Gateway construction is the simplest if a serviceconcatenation approach is used (service adaptation). Inthis case, it is assumed that access to the communicatioriservices of both systems is available within the gatewa)'through existing protocol implementations. The gatewa)design is particularly simple in the case of direct concat--enation which requires certain matching conditions for theservice interfaces.6) If the gateway considers in detail the PDU's ex--changed below the service level at which interworking issought (conversion at the PDU level), it may provide :Imore efficient and powerful adaptation function; but it i sin most cases more difficult to design and build.

7) In general, the specification of the protocol con--verter for PDU-level conversion can be obtained auto-matically from the two protocol specifications and the in--terface adapter.

It is interesting to note that only in points 2 , 6), and 7the detailed consideration of the respective protocols isimportant; all other points are related to the definition Othe communication services used in the interconnectedsystems. This emphasizes the importance of service specifications for the design of distributed systems. Whilemeaningful communication in a distributed system depends on compatible implementations of an agreed-uponprotocol, the possibility of building gateways that extenda communication service into adjacent distributed systemsdepends essentially on the compatibility of the commu-nication services used in the different systems.

If we consider, on the other hand, the direct interwork-ing (without gateways) between different computer sys-tems, the conditions for compatibility are related mainlyto the communication protocols. For example, the con-dition that a system can exchange and access files withanother OS1 FTAM system includes the following:

1 the OS1protocols for all layers must be implementedcorrectly, including all options required by FTAM; and2 the operation of the system as seen through theseprotocols must conform to the FTAM virtual file system.

While point 1) includes seven layers of protocols, point2 corresponds to the conformance with a (local) servicespecification, namely, the service provided by the file sys-tem.

It is important to note that service specifications are notonly essential for interworking considerations, but alsofor the design and validation of a hierarchy of protocoli[l] . In fact, the service specification is not only the ref-erence for interworking considerations but also for vali-dating the protocol which is intended to provide the ser-vice and for checking that it is sufficient for the operationof the user processes. The service specifications for thedifferent layers also provide the framework in which newprotocols may be introduced in a specific layer withoutaffecting other layers.

REF ERENCES\ I ] G,. v . Bochmann and C . A . Sunshi ne, Formal methods in comlnL-nication protocol dehign, lEEE Trtrf is. C o m m m . , v o l . COM-28. pp.


10/10

71O C H M A N N A N D M O N D A I N - M O N V A L . D E S I G N P R IN C I P L E S F O R C O M M U N I C A T I O N G A T E W A Y S

624-63 I . Apr. 1980: reprinted in Coi,i,,iioiic.trtic,rl Prorocol M o d e l -l ing. C. Sunshine. Ed.121 G. v . Bochmann. A. Jacques. and C. Kawa. Transport relays.Univ. Montreal, Tech. Rep.. 1986.131 G . v . Bochmann and A. Jacques, Gateways for the OS1 TransportService. in P r o < . . l E E E l N F O C O M 8 7 Conf. San Francisco. CA,1987.141 G . v. Bochmann, Deriving protocols converters for communicationgateways. IEEE T rans . Com m un. . to be published.[5] M. Gien and H. Zimmerman, Design principles for network intcr-connection, in P roc . VI Data Commun . Symp. ( l E E E / A C M ) . Nov.1979, pp. 109-119.161 P. E . Green. Protocol conversion. IEEE Truns. Commun . . vol.COM-34. pp. 257-268. Mar. 1986.171 - Network Interconnect ion and P r ot o co l C o n i ~ r s i o n . New York:IEEE Press, Apr. 1987.181 1. Groenback, Conversion between TCP and I S 0 transport proto-cols, IEEE Trans. Selec t . Areas C o m m u n . , vol. SAC-4. pp. 288-297, Mar. 1984.

[9] S . Lam, Protocol conversion, IEEE T rans . So f t ware Eng . , vol.13, pp. 353-362, Mar. 1988.[ I O ] Y. Ohara. S . Yoshitake. and T. Kawaoka, Protocol conversionmethod for heterogeneous systems interconnection in multi-profileenvironment, in Proc. IFIP Symp. P ro t oc o l Specification, Test ingand Ve r c a t ion: VI / , Zurich, May 1987. Amsterda m, The Neth-

New York: Artech, 1981.

erlands: North-Holland, pp. 405-418.K. Okumara, A formal protocol conversion method. in P r o c . A C MConf Com m un. P ro t oc o l s and Arc hi t e c t ure s . 1986.ISO, Addendum to the Network Service Specification covering Net-work Layer Addressing, ISODP 8348. Apr. 1984.ISO, Internal Organization of the Network Layer. ISOTC97ISC6N3141, Apr. 1984.ISO, Basic Reference Model for OSI , IS 7498. 1982.ISO, Connection Oriented Transport Protocol Specification, IS8073.ISO, Connection Oriented Transport Service Specification. IS8072.C. Vissers and L. Logrippo, The importance of the concept of ser-vice in the design of data communication prot ocols. presented at theIFIP Workshop on Protocol Specification, Verification and Testing.Toulouse, France. Amsterda m, The Netherlands: North-Holland,1985.CCITT Recommendations, Message handling systems: Access pro-tocol for Teletex terminals.

1191 S . Zatti and P. Janson. Interconnecting OS1 and non-OS1 networksusing an Integrated Directory Service. Coruput N t , / i w ~ r L ~117d ISDNS y s t . . vol. 15. pp. 269-283. 1988.

Gregor v. Bochmann (M82-SM8 5) received theDiploma degree in physics from the University o fMunich, Munich, West Germany, in 1968 and thePh.D. degree from McGill University, Montreal.P.Q., Canada, in 1971.He has worked in the areas of programminglanguages. compiler design, communication pro-tocols. and software engineering and has pub-lished many papers in these areas. He is currentlya Professor in the Departement dlnformatique etde Recherche Operationelle, Universite de Mon-treal. Montreal, P.Q., Canada. His present work is aimed at design modelsfor communication protocols and distributed s ystems. He has been activelyinvolved in the standardization of formal description techniques for OSI.From 1977 to 1978 he was a Visiting Professor at the Ecole PolytechniqueFederale. Lausanne, Switzerl and. From 1979 to 1980 he was a VisitingProfessor in the Computer Systems Laboratory, Stanford University. Stan-ford, CA. From 1986 to 1987 he was a Visiting Researcher at Siemens.Munich

Pierre Mondain-Monval received the Mditri\edegree in computer science from the Univer\ity otBordeaux. Bordeaux, France, in 1983 and theDoctor degree from the University of Toulou\e.Toulouse. France. in 1987From 1984 to 1987, he was at the LdboratoiredAutomatique et dAnaly\e des Syjtemes. Tou-louse, France In 1988 he was a Visiting Protess orat the University of DeldWdre. Newark, and I \currently a Professor in the Departement dlnfor-matique et de Recherche Operationelle. Universite de Montreal, Montreal. P Q Canada H i \ re\edrch topic\ includestandardized OS1 protocols design and specihcation, distributed \y\tem\and \oftware engineering

boch90b - from ieee library

Documents