Evaluation of a Transport Protocol for its Implementation in Distributed Multimicrocomputer Control Systems

Copyright © IFAC Softwar" for Comput"r Control Madrid, Spain 1982

EVALUATION OF A TRANSPORT PROTOCOL FOR ITS IMPLEMENTATION IN DISTRIBUTED MUL TIMICROCOMPUTER CONTROL SYSTEMS

J.

Figueras* and A. Alabau**

*E. T . S.I .I.B . - Universidad Politecnica, Diagonal 647, Barcelona 28, Spain **E. T.S.I . T.B . - Universidad Politecnica, lorge Girona Salgado 31, Barcelona 28, Spain

Abstract.The possibility of using existing Host to Host standard protocoLs in the fieLd of Distributed ControL Systems is investigated. A subset of the NationaL Bureau of Standards Transport ProtocoL (Basic CLass) has been proposed and evaLuated with respect to some desirabLe requirements of Distributed ControL AppLications based on Low power (mini-microcomputer) nodes Linked by a LooseLy coupLed LocaL area network. Keywords. Transport ProtocoL; Distributed ControL Systems; ISO LEVEL 4 ProtocoL; LocaL Area Network.

entities of the same LeveL or Lower LeveLs.

INTRODUCTION

2. The entities Located at Level n cooperate among them according to protocoL ~.

In the fieLd of Distributed Systems Architecture a trend towards standardization foL Lowing the ISO Reference HodeL for Open System Interconnection [1], is currentLy attracting the attention of research and industriaL institutions [2], [3]. This standardization effort has been very succesfuL fostering the interconnection of heterogeneous and wideLy separated data-processing systems in computer networks.

3. The entities at LeveL n use the services (n-1) provided by the entities of Level n-1 and provide sevices to the entities at LeveL n+1 by weLL stabLished access communications interfaces.

The purpose of th is pape r has been the evaLuation of a Transport ProtocoL (fourth Layer in the OSI-Reference ModeL> for distributed controL systems based on architectures of LooseLy coupLed microcomputers. The services up to the network LeveL are being provided by an existing LocaL area network and the effort has been centered at the Transport LeveL.

P n+l EnTITY

ENTITY

ENTITY

EN", I T':'

THE ISO REFERENCE MODEL FOR OPEN SYSTEMS INTERCONNECTION

-

The InternationaL Standards Organization (ISO) as a consequence of the increased interest in Distributed Systems, created in 1977 a Subcommittee (SC16) in the TechnicaL Committee No. 97 in order to eLaborate a Reference ModeL for the Interconnection of Heterogeneous Information Processing Systems.

- .-. -_

. ._--- - _._--+---

Block n-2 Block n-l Block n

The approach foLLowed by ISO in the ModeL is a moduLar structure (fig. 1) using the foLLowing eLements:

Block n+l

1. The interconnecting system is based on a set of entities Located at different LeveLs and structured in bLocks incLuding the-------

Fig. 1.

165

Basic concepts of the Reference ModeL

J. Figueras and A. Alabau

166

4. The ent it i es at Leve L n perform the functions of LeveL n using services of LeveL n-1 and providing services to LeveL n+1. Now we wiLL define the basic functions of the different LeveLs of the r10deL keeping in mind that some of the LeveLs are not essentiaL and wiLL not be encountered in particuLar distributed systems. The NodeL provides a framework for the structuraL design of Distributed Systems. The possibLe functions of a Distributed System have been structured in seven LeveLs with cLear and weLL defined interfaces among them [1]. The top LeveL ca LLed APPLICATIotJ LEVEL (or LeveL 7) provides the mechanisms to communi cate user app Li cat i on processes (entities at LeveL 7) Located at different computers of the network. The next LeveL caL Led PRESENTATIon (or LeveL 6) provides for formatting of the information such as data compression and encryption. In the foL Lowing LeveL called SESSIOtJ (or LeveL 5) manages the connection (caLLed a session) between tOlO user processes (rigorousLy, betOleen tOlO presentation-LeveL entities) Located in different computers. At this LeveL the connection is negotiated and in case of agreement, estabLished. Furthermore the connection is monitored and orderLy disconnection procedures provided. The foLLOOling LeveL caLLed TRAtJSPORT (or LeveL 4) provides for the orderLy transport of information from Host to Host OIhere the communicating processes reside, irrespective of the underLying communicati0n mechanisms (transmission BLOCK) used. ALL the previous LeveLs are usuaLLy impLemented under the Operating System of the Computer (Host) where the AppLication Process resides. FinaLLy, the Lower three LeveLs caLLed rJETt.:ORK (LeveL 3), LINK (LeveL 2) and PHYSICAL (LeveL 1) provide for the needs of the transmission bLock i.e. the communication of information on the network, from node to node and on the physicaL media used to Link the information processing systems. A graphicaL representation of the r~eference r10deL described above is given in Fig. 2. The attentton of this paper OIiLL be focussed on the TRANSPORT LEVEL assuming that the needs of LeveLs 1,2 and 3 are provided by high quaLity (virtuaLLy error free) LocaL Area Network. In the following paragraphs a Transport ProtocoL OIiLL be described and evaLuated in the context of Distributed ControL Systems based on LocaL Area Network s.

(Hosts). The main funct ion performed by the Transport LeveL is to provide its users with transport services of information reLiabLy and transparently wlth regard to the communication resources used by the Lower LeveLs.

6

5

F:;:::J

I "'1';:S(.:>7A"!O~1

L £!.!!:.f'~tlo~rot.2£.ol _

I ~!':SSH·,~

~ ~l'i
I:",'"'."T

,11.E.'"'2?"_~~O'£!. _ J

r------.I

.

I !

~ .c;::!,:::~:;

7'X,>,"7

I'

~,l 8n9 I b:=:J ---~

~G

, 1""<

iI

1

"-,,"s-'C.'-.L

r-I

I

I

----,\t~} ~ H I-~

11

Fig. 2.

---·GJIT+" i

"7,,OaK

/'

The Distributed Systems Architecture of the ISO Systems Interconnection Reference ModeL

Services Provided to its Users The services provided by the Transport Service are of two types connection or transaction oriented. The most wideLy used at present is the connection type which consists in stabLishing a bidirectionaL transport connection point to point as a two way channeL among two transport addresses where the DATA UNITS are deLivered in the same order as they were sent. This type of sevice is ofered by a number of present standard proposaLs as ECMA-72 [6], RHIN [7] and NBS [8].

PROPOSED PROTOCOL In this section a subset of the Basic CLass Transport ProtocoL deveLopped by the U.S. NationaL Bureau of Standards [8] compatibLe OIith the ISO CLass 11 Transport ProtocoL is given. This subset provides services simiLar to the standard ECMA-72 CLass 2 [6] where the onLy connection oriented services are provided and transaction oriented services are not included.

THE TRANSPORT LEVEL The transport LeveL is the fi rst LeveL in the Reference ~lodeL (see Fig. 2) where the entities in different machines have end-toend protocoL. In other words the communication between peers is performed by the entities in the source and destination machines

The current standardization effort in LeveL 4 defines different cLasses of Transport ProtocoL in order to adjust to the needs of different systems. The subset seLected here provides connections ammong peer user entities with the objective of providing the foLLowing services:

167

Evaluation of a Transport Protocol

Bidirectional data flow on each connection. Flow control. "Tfierece;ver inforlls the sender of the amount of data he is willing to receive (the 'credit'). In this way the receiver controls the speed at which information is generated by the sender which guarantees that information will not overflow buffers. This method is the well known WINDOW MECHANISM.

ling ' the transport entity will be given. Only pertinent states and transitions of the phase wi II be represented in the graph. T?ANSPORT Q.s~q,

f ran U: EVEn'!

Expedited data and normaL data. This two types of dara-transport mecha~s allow the sender to send data without the explicit agreement of the receiver. The sender sends a fixed amount of data and waits for its acknowLedgement before sending another expedi ted data uni t. In order to guarantee its rapid deLivery neither queueing nor resource restri ct ions take pLace.

TP.A..t..;SPORT

ENTITY extended

autc.mato n

Error recovery is not provided to the user by the subset of CLass 2 protocoL. ALL error detection an recovery procedures will have to be performed in Levels 1, 2 and 3 and if the user is sti Ll unsatisfied he wi II have to provide his own error detection and recovery procedures. This approach is appropri ate in cases where these procedures are appLication dependent. The reasons and justification for the selection of this protocol in our distributed control network will be given in next section.

to U: EVENT

to S: EVEf:T SYSTE'1 ~. S:

EVENT

from N: EVENT

E~F'l':Y

Fig. 3.

The Transport Envi ronment

Entity

and

its

Stablishment Phase. PROTOCOL DESCRIPTION In order to i nt roduce conceptua lly the protocol proposed we wiLL give a model for the transport entity in an enviro~t~hich generates or receives ,nput and output events. This method of protocol speci fi cation ;s used in [8] and a similar approach can be found in [7]. The protocol is described as a set of finite state automata extended with variables and program segments which manipuLate this variables. Each state transition is caused by an event. A sequence of variable modifications and event generations can be associated ty means of a program segment. The environement of each automaton is the two adjoint entities (network (N) and user (U» and the system (S) performing tasks of timing, inicialization, event interpretation among others. This structure has been depicted in Figure 3. Two users of the Transport servi ce located in different computers of the network communicate point-to-point by means of a connection between two transport entities. These connections will be stablished or closed according to the needs of user entities. The phases of a point-to-point communication are: Establishing phase, Data transfer phase and Closing phase. In the following paragraphs the evolution of the automata model-

Before stablishing the connection the connection is closed and both automata wi II be in CLOSED state (see Fig. 4 for numbered branches of the automaton). When a user entity desires to stabLish a connection to another user entity it generates the event T CONNECT.request at the user interface (1). At the transport leveL a Connection Request (CR) ProtocoL Data Unit (PDU) is formed and transmitted. As a resuLt the state at the sending transport entity wilL change to CR_SENT. When the CR arrives at the other end, the rece, VH19 transport ent ity enters the state CR RCVD (Connection Request Received) and informs to the caLLed user with a T CONNECT.indication (2), who wi LL decide to accept or reject the requested connection with a T ACCEPT.request or a T DISCONNECT.request. If the caLL was accepted the called transport entity wil L enter the connection stabLished state (ESTAB)(3) and wiLL inform the caLLing end by a Connection Confi rm (CC>. If the caLL was not accepted it wiLL wait for the calling end to disconnect entering the DISCONNECT WAIT state (6). Now let us go back to the calling end. The transport entity after sending the CR, entered the state CR SENT (1). If the calLed user entity accepted the connection a Connection Confirm will be received and the state ESTAB entered (4). In this case the connection has been stabLished and the Data

J. Figueras and A. Alabau

168

Transfer phase starts. If the caLLed user entity did not accept the connection a Disconnect Request (OR) wi LL be received with the reason for not accepting the caLL. The transport entity wiLL inform the caLLing user entity and enter the CLOSED state (5). In case of a coLLision of caLLs or any other abnormaL condition the connection wiLL be cLosed and the users informed.

[3ranch 1)

from U: T DATA. request to N: t(DATA. request to tJ: N_DATA. request

to Branch

2)

N:

fl_DATA. request

from N: N DATA.indication [DT]

to

U: T DATA.indication (if a TSDU has been assembLed) to N: T DATA.indication [AK]

from U: T CONNECT.request to N: rrDATA. request ECR] (2)

from to

(3 )

DATA. request (eR] U: T CONNECT.indicator r~

:

Branch 3)

from U: T EXPEDITED DATA. request to fl: tCDATA.request (if none out st andi ng)

Branch 4)

from N: N DATA.indication cXTD] U: T EXPEDITED DATA.indication to N: fj-DATA. request to

r~

from U: T_ACCEPT.request N: tl DATA.request to

CXAK]

[CC]

(4)

from N: N DATA.indication [CC]

Fig. 5.

(5)

form N: N DATA.indication [OR] to U: T DISCONNECT.indication to tl: N_DATA.request [DC]

(6)

from U: T DISCvlmECT .request to tl: tl-DAT A. request [OR]

(7)

from N: N DATA. request [DC]

Fig.4.

EstabLishment Transitions.

At any end of the connection the user may i ni t i ate a request to send data to the user at the other end of the connection by a T_DATA.request whi ch contains a unit of data refered as Transport Servi ce Data Uni t (TSDW. On its reception the Transport entity fragments the TSDU suppLied by the user into Data Units used by the Transport entity (TPDU) if neccesary and pref i xes them wi th the appropiate header containing addressing information and the current sequence number. The Last TPDU contains an indication marked as EOT. The Transport entity attempts to send as many TPDU as it can within the flow cont ro L wi ndow (see branch 1 of Fig. 5).

Phase

State

Data Transfer Phase. To initiate this phase the two transport protocoL entities wiLL have a connection stabLished and both wiLL be in the ESTAB state (see Fig. 5)

Data Phase State Transitions.

When a TPDU arrives at the other end it wilL be acknowLedged as soon as the ffLow controL mechanism permits it and if a compLete TSDU has been aLready assembLed wiLL be passed to the receiving user by a T DATA.indication (see branch 2 of Fig. 5). -

Evaluation of a Transport Protocol

When a user desires to send urgent data a different mechanism in the same connection may be used. The sending user generates a T_EXPEDITED_DATA.request which passes to the Transport entity a fixed amount of data (8 bytes) which is to be sent regardless of any pending queue of normal data units. This urgent message wi II be sent if the previous urgent message has been already acknowledged (XAK) hence only one outstanding EXPEDITED DATA units will be allowed (see b ranc he s 3"" and 4 on Fig 5). Termination Phase. There are two types of termination of a connection: gracefully by consent of both communicating user entities or by disconnection due to abnormal conditions on the connection. The graceful termination may be requested by any user by issuing of a T CLOSE.request. As a consequence a Graceful Request (GR) will be enqueued and sent to the other end. In Figure 6 and 7 the transitions of the automata at the requesting and receiving ends are ilustrated. After the GR has been sent the automata enters the state G CLOSING waiting for AK of the GR. The receiving entity will enter the state G CLOSING P after receiving the GR and sendTng its AK. As soon as this AK arrives the requesting entity will enter the state GCLS1 to wait for a GR from the user at the other end which will close the connection. In case of a collision of graceful requests (GR) the requesting transport entity will enter the state GCLS2 waiting to close when knows that the other closed or when it receives the AK of his own GR sent. REQUIREMENTS AND SERVICES TO BE PROVIDED BY THE TRANSPORT PROTOCOL IN DISTRIBUTED CONTROL APPLICATIONS In this section we attempt to explore the specific nature of a wide class of Control Systems and how it afects on the Transport Layer of the computer network used in the implementation of the Distributed Control funct ions. The traffic nature on a Distributed Control System may b~fied in two broad classes: small delay, short messages, used to transfer contrCi"L"'COmmands ana critical measurements, and high throughput, time unconstrained messages used for fi le transfer and high volume data transmission. The protocol proposed similarly to the NBS 'Basic Class' Protocol (8J an the ECMA Classes 2, 3 and 4 offers two types of Data units: EXPEDITED DATA and DATA. The flow control mechanism used for Expedited Data assumes that only one unit of data at most may be outstanding for acknow ledge what assures that no queues wi II be formed anywhere on the network and the delay to receive an acknowledge of an expedited data sent will be minimized. The price paid for

169

this mechanism is low throughput, which is not a problem in bursty control commands or critical meausurements done when certain rare events occur. Using normal DATA (high throughput) the regular flow of data will be achieved. Another differential characteristic of the type of system under consideration is its known communications needs.!! design time. This fact wi II allow to have permanent (or quasi-permanent) network connections provided by the local area network used for the Distributed Control Data System. Only in rare ci rcumstances (expansions, fai lures) nodes wi II be added or removed from the system. For this reason, in order to simplify the implementation, we have based the protocol on the assumption that network connections were permanent and all new transport connections created would be multiplexed on the existing fixed network connections. Finally we have tipified the class of systems as those having low power nodes (usually mi ni-mi c rocomputersr w"'li"e'reaacrecr-protoco l implementation was restricted to be as small as possible as oposed to wide-area networks of large machines for which existing Transport Standards are intended. For this reason we have not included Error Detection and Recovery mechanisms at the transport level and we have lowered this functions to the network (Levels 1, 2 and 3). This phi losophy seems to be cost/effective due to the technology on local area networks which provide for highly reliabLe message communication from node to node. In order to enhance the robustness of the protocol, when any error is indicated by the network or when the transport entity encounters an abnormaL (not especified) condition it cLoses the transport connection and informs the users. APPLICATION The proposed transport protocoL is currentLy being impLemented on a distributed control system for a soLar heating experimentaL station which incLudes three 9900 microcomputers and a PDP-11/23 with 10Mb of disk storage. The four nodes of the network are communicated with a locaL area network using ChanneL Sense Multiple Access with ColLision Detection (CSMA-CD) on a coaxiaL cabLe as transmission medium (Ethernet type). On the PDP-11 is implemented as a privileged task under RSX-11M. On the 9900 the protocoL is implemented as a task running under a simple round robin scheduler. For each implementation there is a unique automata handler and each transport entity is represented by a data structure containing the state and associated variabLes.

J. Figueras and A. Alabau

170

(i,)

U: T CLOSE.reCluest

from N: N DATA. indication

,_cc=,

(GR)

(GR)

?

8

®

from N:

(CR)@

~N DATA.~from (AK)

@

~ from U: T CLOSE.renuest

(G~)

8

m'_'

>3

@I from 'f

0=) -

~

\

CLOS!=:O

N: !.J DATA. ind

from N: N DATA.ind

"

(!\K)

©

N: N

~ATA.indication

(AK)

from N: !.J DISCO!.JNECT. Fig. 6.

Transport Entity State Transitions for GracefuL CLose at the Requesting End.

Fig. 7.

Transport Entity State Transitions for a GracefuL CLose at the Receivin9 End.

CONCLUSIOI~

[2J

1'1 . t1edina and A. ALabau, 'Some Aspects of a Transport LeveL S e r v ice for 11 i c r 0 c 0 m put e r Distributed Systems', rJUll 82, r'larch 1982.

[3J

P. E. Green Jr., 'An Introduction to Network Architectures and ProtocoLs', IEEE Transactions on Communications, VoL. CO[1-28, Ilo 4, April 1980.

[4J

p. F. liainwright, Editor, 'Internetworking issues: LocaL tJetwork ProtocoL', IEEE 802 HILI Subcommittee Draft ProposaL, September, 15, 1981.

[5J

A. S. Tanenbaum, Computer Networks, Prentice HaLL, 1981.

[6J

ECMA-72 Transport ProtocoL, January 1981 •

[7]

J. P. Ansart et aL., '~10deLe PascaL du ProtocoLe de Transport RHIN', PROJET RHIN Rep. No. FDT 7502, Agence de L'lnformatique, LA DEFENSE, Juin 1981.

[8J

NationaL Bureau of Standards, 'Specification of the Transport ProtocoL', VoL 2 Basic CLass Protoco L, Report No. ICST/HLNP-8112, September 1981.

A transport LeveL protocoL has been proposed for Distributed ControL Systems based on LooseLy coupLed Low power (mini-microcomputer) nodes. This protocoL is a subset of the IJBS's Transport ProtocoL (Elasi c CLass). It offers the possibiLity of opening and cLosing the transport connections on assumed preexisting and muLtipLexabLe network connections. Two types of traffic: expedited data ( controL commands and criticaL meausureMents) and normaL data (high voLume, reguLar flow) are supported. No error detection and recovery has been offered at the transport LeveL since this functions are assumed to be more ef fect i ve Ly imp Lemented at Lower LeveLs (LocaL area network). FinaLLy, the distributed controL appLication which has motivated the proposed protocoL has been described. REFERENCES [1]

H. Zimmermann, 'OSI Reference ri odeL

- The ISO MODEL of Architecture for Open Systems Interconnection', IEEE Transactions on Communications, VoL. COM-28, No 4, ApriL 1980.