A Computer Network: Structure and Protocols of the RPCNET

Caneschi, F.

IIASA Professional PaperDecember 1978

Caneschi, F. (1978) A Computer Network: Structure and Protocols of the RPCNET. IIASA Professional Paper.

Copyright © December 1978 by the author(s). http://pure.iiasa.ac.at/912/ All rights reserved. Permission to

make digital or hard copies of all or part of this work for personal or classroom use is granted without fee

provided that copies are not made or distributed for profit or commercial advantage. All copies must bear this

notice and the full citation on the first page. For other purposes, to republish, to post on servers or to redistribute

to lists, permission must be sought by contacting repository@iiasa.ac.at

PP-78-12

A COMPUTER NETWORK: STRUCTURE AND PROTOCOLS OF THE RPCNET

Fausto Caneschi

December 1978

ProfessionalPapersare not official publicationsof the InternationalInstitutefor Applied SystemsAnalysis, but are reproducedand distributed by theInstitute as an aid to staff membersin furthering their professionalactivities.Views or opinionsexpressedherein are thoseof the authorand shouldnot beinterpretedas representingthe view of either the Institute or the NationalMemberOrganizationssupportingthe Institute.

PREFACE

This manual was written with a well definedgoal: to collect all the technical specificationsand protocols of the RPCNET, the Italian ComputerNetwork. Since now, these technical specificationswere described in a number of papers, and most ofthem were obsolete. In fact, one thing is a newprotocol before its implementation, and,veryoften, different after the implementation.Anyway, the principles on which RPCNET wasestablished remained untouched, so that theauthor's work was made easier by consulting andusing the material contained in those old papers.

Nothing could be done, however, without thehelp of the RPCNET people, both at CNUCE and atthe IBM scientific center of Pisa, Italy. Myspecial thanks go to Luciano Lenzini, FabioTarini, Claudio Menchi, Marco Sommani, MaurizioMartelli and Erina Ferro at CNUCE, and to LivioLazzeri, Alessandro Fusi, Carlo Paoli andRaffaello Porinelli at the IBM scientific center.

The author admits that this work can belargely improved and thus will appreciateall thesuggestionsand contributions, both from the abovementioned specialists and from any otherinterestedreader.

-iii-

ABSTRACT

A brief description of the RPCNETarchitecture is given in the beginning of thismanual, then, the protocols and the packet formatsof RPCNET are described.

More precisely, Chapter 1 deals with ageneral descriptionof the RPCNET, Chapter 2 dealswith the 1st level protocol (Line andReconfiguration protocols), Chapter 3 deals withthe 2nd level protocol (End-to-End protocol), andChapter 4 deals with User-Level protocols,including the description of RNAM, the generalizedAccess Method supplied by RPCNET.

Appendix A is the hardware scheme of theBSC-modified line connection, Appendix B gives anexample of how the reconfigurationprotocol works,and finally Appendix C describes the packetformats.

-v-

LIST OF CONTENTS

page

1 1 INTRODUCTION

2 2 RPCNET ARCHITECTURE

2 2.1 General Information.

2 2.2 The Communication Layer

3 2.3 The Interface Functions Layer

4 2.4 Application Layer

5 3 THE COMMUNICATION LAYER

5 3.1 General Information

6 3.2 The Packet Switcher

8 3.3 The Communication Network Manager

8 3.3.1 The NETCHANGE protocol

14 3.4 The Network Connection Handler (NCH)

14151920

3.4.13.4.23.4.33.4.4

General considerationsHow the protocol worksBlock name managementProtocol specification

27 4 THE INTERFACE FUNCTIONS LAYER

27 4.1 General Information

29 4.2 The SessionHandler

2930

4.2.1 Operation4.2.2 Internal Protocols

-vii-

3341455256

4.2.34.2.44.2.54.2.64.2.7

PresentationServicesData Length AdapterData Flow ControlSessionException HandlerA final remark

57 4.3 The Network Services Manager

59606166

4.3.14.3.24.3.34.3.4

The Logical unit HandlerThe Logical Network Control PointThe Multiple SessionHandlerThe Network ServicesSwitcher

77 4.4 The Network Access Controller

78 5 THE APPLICATION LAYER

78 5.1 Introduction

79 5.2 RNAM

79 5.2.1 Characteristicsof RNAM

86 5.3 Improved Access Method based on RNAM

86

8688117

5.3.1Method5.3.25.3.35.3.4

General characteristics of the

Macro instruction structureMacro InstructionsMacro instruction return codes

Access

121 5.4 User Application Protocols

121122131

5.4.15.4.25.4.3

IntroductionFile Transfer ProtocolVirtual Terminal Protocol

-viii-

page

7

10

15

16

17

18

18

21

21

25

31

37

39

43

46

52

53

67

68

73

81

81

82

85

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

LIST OF FIGURES

Packet Switcher activity

Distance and Routing tables for node C

Logical Channelsand Byte Structure

Example of a Sender Node

Example of a Receiver Node

Example of ACKM Structure

Blocks Situation

Block Structure

Channel 2 is nacked

Status Message

Logical Channel between two Applications

Chain Sender and Chain Receiver

Change Direction Control

TH structure

The Dynamic Window

Data Flow Control: Sender side

Data Flow Control: Receiver side

NSM Sender

NSM Receiver

SessionService Protocol

Synchronousrequestshandling

Asynchronous request with ECB

Asynchronous requestwith Exit-routine

RNAM handling of the operations

-ix-

89 Figure 25 LUCB macro instruction

92 Figure 26 RPL macro instruction

97 Figure 27 GENCB macro instruction

99 Figure 28 MODCB macro instruction

1121121 Figure 29 OPENID macro instruction

11211 Figure 3121 CLOSELU macro instruction

11212 Figure 31 BIND macro instruction

11214 Figure 32 INVITE macro instruction

11215 Figure 33 UNBIND macro instruction

11216 Figure 34 SEND macro instruction

11218 Figure 35 RECEIVE macro instruction

11219 Figure 36 BREAK macro instruction

III Figure 37 CHECK macro instruction

III Figure 38 CANCEL macro instruction

112 Figure 39 EXECRPL macro instruction

113 Figure 4121 TESTLC macro instruction

115 Figure 41 MAIL macro instruction

124 Figure 42 NET format for spool blocks

125 Figure 43 BIU format for File Transfer

132 Figure 44 statesof a Virtual Terminal Protocol

133 Figure 45 State diagram for the Virtual Terminal

-x-

I INTRODUCTION

This technical manual describesthe various layers andprotocols of RPCNET, the italian computer network, and isintended for computer personnelwho wish to implement theRPCNET architectureon their own existing systems.Althoughthe RPCNET architecture is independent on the computingsystems on which it can be implemented, the originalpartnersof the REEL project (REte di ELaboratori) allemployed IBM computing systems, so that the RPCNET softwarefor IBM 370s, running OS/VS2, MVS or VM/370, and for IBM S/7was developed and tested in the course of the project. Thissoftware is available at CNUCE, C.N.R.; via S. Maria 36,Pisa, Italy.

- 2 -

2 RPCNET ARCHITECTURE

Although it is assumed that the reader of this manualis already familiar with the RPCNET architecture,(1) , (2),(3), (4), a brief descriptionof it follows here as abackground for the material presented in subsequentchapters.

2.1 General Information.

RPCNET is a packet switching, distributed control,computer network; automatic re-configurationand a generalAccess Method are distinguishing charactersof its design.

RPCNET is logically divided into three layers:

a) The Communication Layer

b) The Interface Functions Layer

c) The Application Layer,

which correspondto the three addressinglevels of thenetwork.

One function of the Communication Layer is the sendingof packets on the line(s) according to a well defined lineprotocol. It also performs the routing and re-configurationfunctions, using the NETCHANGE protocol.

The software componentwhich pertains to this layer isthe Common Network Manager (CNM), which is the firstaddressableunit in RPCNET. This means that a networkaddresslike n00 (where n is an integer number between 1 and65536) is a CNM address.

Any computer on which the Communication Layer isimplemented is consideredto be an RPCNET Node, and as suchit can perform the line-driving and the re-configurationfunctions. The packets are required to be fixed-length,formatted fields ,the RPCNET packet length being 255 bytes.

- 3 -

The Interface Functions Layer facilitates the networkusers' (Applications) work, by:

a) hiding the packeting activity, theretransmissionsand the reconfigurations;

b) handling the logical RPCNET channel, notifyingthe Application in case of errors.

The Interface Functions Layer is composedof two mainmodules: the SessionHandler (SH) and the Network ServicesManager (NSM). The SH is in turn composed of 3 modules andperforms the in-session functions of assemblingand dis-assembling the application buffers (Basic Information unitor BIU) in packets for the Comm_nication Layer. The SH has awindow oriented protocol, which allows the discarding ofduplicate packets and the recognition of BIU loss. The 3 SHmodules are designatedas: the Presentation Services, theData Length Adapter and the Data Flow Control, which aredescribed later in this manual.

The NSM regulates the opening and closing of theLogical Channel and provides services as the transmissionof"mail".

All the NSMs in the network are connectedby means of aNSM protocol which has a fixed length window. The presenceof an NSM characterizesa computer as a RPCNET Host, makingthe NSM as the second addressableunit in the network. Anetwork addresssuch as nm0 (where n is the Node CNMaddress, and m is the Host NSM address) designatesthe m-thHost in the n-th Node.

The Logical RPCNET Channel mentioned previously asbeing handled by the Interface Functions Layer, has thefollowing characteristics:

a) it is driven with an half-duplex technique

b) it does not provide an error-free connection

c) it detectsand signals, at both Logical Channelsides, errors in the form of BIU losses.

However, with little effort the facilities of theLogical Channel could be extended by making it a full-duplexconnection. This should be kept in mind during theimplementationphase.

- 4 -

In the RPCNET, the term Application is used to indicatethe generic network end-user: an Application is defined asany processor set of cohordinated processes, that accessthe Communication System (Communication Layer and InterfaceFunctions Layer) in order to obtain network services. AnApplication is identified by the third addressfield in thenetwork address.

A network address such ｡ ｾ Ｇ nmk identifies the k-thApplication of the m-th Host in the n-th Node. In thenetwork addressspace, the nmk unit is known as the nmk LCT(Logical Channel Termination).

- 5 -

3 THE COMMUNICATION LAYER

3.1 General Information

The Communication Layer is composed of three modules:

a) The Packet Switcher (PS)

b) The CommunicationNetwork Manager (CNM)

c) The Network Connection Handler (NCH)

It must be noted, at this point, that a RPCNETconnection is a full-duplex channel: this means that the NCHis in charge of providing a full-duplex connection for itsusers (namely, the PS and the CNM) , and to hide to them thedetails of the protocol(s) used. As the initial RPCNETpartnershave IBM computers, a BSC full-duplex protocol (2)was designed and implemented which allows, by means of aspecial "Y" cable (see Appendix A), to use a BSC line as afull-duplex line.

If in the decision phaseof the project the BSC linewill not be chosen, the line protocol must be re-designed.

In the first section of this chapter we will describethe PSi the second section is dedicated to the CNM, and thethird to the BSC full-duplex NCH.

- 6 -

3.2 The Packet Switcher

The PS is in charge of routing packets towards theirdestination, using the Routing Table, which is maintainedand updated by the CNM (see 3.3). The PS has an input queue,which is used by:

a) the upper level of the network (SH or NSM)

b) the NCH

For every packet in the input queue, the DestinationAddress Field (OAF) is tested, and the packet is:

a) enqueuedon the NCH input queue correspondingtothat address (as indicated in the Routing Table)

or

b) enqueuedon the upper level input queue

The PS activity can be sketched in a flowchart, seeFigure 1.

- 7 -

WAIT

IS THE

QUEUE

EMPTY ?

GET THE FIRST

PACKET IN THEQUEUE

YES

NOIS TEIS

ｾＭＭＭＭＭＭＭｾＺＮＭＭＭ ...DIRECTED

HERE?

Figure 1

YES

PUT IT ON THE

UPPER LEVEL

INPUT 0UEUE

-

Packet Switcher activity

LOOK AT THE ROUTING

TABLE TO KNOW THE

NCH INPUT QUEUE

PUT IT ON THE

'INPUT QUEUE

....

- 8 -

The CNM is a component which keeps up-to-date thosetables which are necessary for describing the networktopology (Distance Table) and also for deciding to whichadjacent node a packet must be forwarded to, in order toreach its destination (Routing Table) .

The CNM is also in charge of preparing and sending re-configuration messages (used to make the nodes of thenetwork aware about the topology changes).

The only other componentwhich interactswith the CNMis the NCH. The NCH makes the CNM aware about the going downand the coming up of the links it controls: in addition, itgives to the CNM the reconfigurationmessagesit receives,and sends over the links the reconfiguration messagespreparedby the CNM.

We will describe the protocol used by the CNM (theNETCHANGE protocol) in the following section: this protocolis introduced in (2) and a proposal for the introduction ofthe traffic load, defining the VRP (Virtual ReconfigurationProtocol) was presentedin (3).

The VRPbut it isimplementerintroduction

is not implementedfully compatibleshould know it,of it in RPCNET.

in this versionwith NETCHANGE,in view of

ofso

a

RPCNET,that thepossible

3.3.1

In the actual implementation of the RPCNET, theNETCHANGE protocol has been a little modified, in order togain in speed: the modification consists on sending forevery reconfiguration message, the entire Routing Table(only the distance column, of course) and not the modifiedrow only.

All the terms which are not well defined now will beexplained in the following. For an implementationexamplesee (4).

The routing algorithm performed by the NETCHANGEprotocol is a deterministicone: in fact, it computes thebest route to reach a node by taking into account only thetopology of the network; a route can change only if thetopology changes.

- 9 -

The NETCHANGE protocol assumes that the routingalgorithm is based on the shortestdistancecriterion, i.e.packets in transit are returned towards the adjacent nodewhich is located on the shortestpath to their destination.Such a routing algorithm does not need to know the entiretopology of the network; it is sufficient to know thedistance between the adjacentnodes and all the other nodesin the network.

Let us assume, for instance, that the node A has tosend a packet to the node X, not adjacent to A. If B is anadjacentnode, all that A needs to know is the distancebetween B and X: the distance from A to X via B can becomputed as the distance between B and X plus one, so that Awill route the packet to the neighbour declaring theshortestdistance.

The algorithm requires two tables: the Distance Tableand the Routing Table. The Distance Table has a column forevery neighbour and a row for every node in the network. TheRouting Table has an entry (row) for every node in thenetwork, which contains the shortestdistance to reach thisnode, and the name of the first node in the route (theneighbour to which the packets are to be sent for thatpath) .

An example of a network topology,Table and the Routing Table for aFigure 2.

withnode,

theis

Distancegiven in

The Distance and the Routing Tables are present inevery node, they also contain a row for each node in thenetwork. The Distance Table has as many columns as the linksgoing out from its node; every column has, for every row,the distance between the node the table refers to and thenode correspondingto the row.

The Route Table has two columns, referring to:

I The shortestdistance

2) The node to which messagesare routed

The Routing Table for NETCHANGE is determined in thefollowing way: at the beginning, the Routing Table isdeduced from the Distance table by simply selecting theminimum distance in each row. Later, messagesare exchangedfrom node to node, carrying information about the network'stopology. They have the form of the Routing Table of thenode sending the message.

- 10 -

A

B nu.__,, "1 D

CB CD CE

A 2 2 3 2 B

B 1 3 3 1 B

C - - - - -D 3 1 2 1 0

E 3 2 1 1 E

Distance (left part)

and Routing Tables for node C

Figure 2 Distance and Routing tables for node C

In a node, one of the following events can occur:

1 an adjacent link comes up;

2) an adjacent link goes down;

3) a reconfigurationmessageis received.

These three events correspond to three differentalgorithms that must be performed by the node. To illustratethe algorithms, the following notations are used:

A is the node carrying out the algorithms

B is a neighbor of A

C is any other node different from A and B

N is the number of the nodes in the network

The number N has a special meaning for the protocol;because the longest path between any two nodes cannot passthrough more than N-l different nodes, the protocol makesthe following assumptions:

if N is contained inthe node correspondingcannot be reached passingthe column;

- 11 -

any field of the Distance Table,to the row in which it is locatedthrough the link represented by

if N is contained in the Routing table the node cannotbe reached at all (for example, the node is down) .

- 12 -

ｾＡＮｾｾ ｩＮｾｨｭ ｾ

An adjacent link AB (or a neighbor node B) comes up.

1 The entry, row B, column AB of the Distancetable is set to 1.

2) Then, row B of the Routing table is set to 1,B(distance column 1, node column B)

3) A copy of A's Routing Ｎ ｴ ｾ ｢ ｬ ･ (distancecolumn) issent to all the neighborsof A (including B).

Algorithm ｾ

An adjacent link AB (or a neighbor B) goes down.

All the entries in the column AB of the Distance Tableare set to N; then, for each node X except for A do:

1 Examine row X of the Distance table; calculatethe new shortestdistance (procedureCALC); ifit is not different, end for X

2) If it is, make the appropriatechanges toentry X of the Routing table, and sendreconfigurationmessageto all the neighbors

thea

A reconfigurationmessageis received

Let K the new value for the distanceof the node X: forevery row of the Distance Table except for A:

1 Entry X of the Distance Table is set toMIN(K+l,N)

2) The new shortestdistance for X is calculated(CALC)

3) If any row of the Routing table has beenchanged, send it to all the neighbors(reconfigurationmessage).

- 13 -

ProcedureCALC

All the entries in the table refer to row X

1 For all the links (Distance Table columns) whichdo not have the distance equal to N, thedistance is picked up

2) If the set is empty, the node X cannot bereached, and the Routing Table entry is changedto I no route' (N) .End.

If the set isare chosen;the Distanceselected. Thethe route part

3) not empty, the smallest elementsfrom these, the first distanceonTable from left to rigth iscorresponding link is placed in

of the Routing table.

An example is given in Appendix B, using the topologydepicted in Figure 2.

- 14 -

As explained before, since now the RPCNETimplementation made use of asc lines, so that a BSC full-duplex protocol was designedand implemented for the NCH.For what follows, the reader is assumedto have a goodknowledge of the BSC control characters, and also of thestandardBSC protocol in general.

3.4.1

In order to take advantageof the procedureability totransmit a stream of data in both directions at the sametime, an overlapping between the block acknowledgementsandthe transmission of a subsequent block is provided.Generally speaking, it is possible to say that as soon asone block is transmittedas a result of a write operation,the next block is sent, regardlessof whether or not theprevious transmissionwas completed without error.

According to this protocol, every block of informationis shipped out by the computer on the line as a transparenttext. It will be assumed that all padding and framecharacters are provided implicitly; it is not importantwhether from hardware and/or software. Transmissioncheckingis provided in the form of CRC when the normal end oftransmissionis detected.

According to the protocol, each physical line is brokenup into a number of logical ｨ ｣ ｨ ｡ ｮ ｮ ･ ｬ ｳ ｾ Ｌ in the presentimplementationeight channels in each direction.

Negative (NACK) and positive (ACK) acknowledgmentsrequired by a BSC transmissionare now replaced by a controlmessageBSCM which includes both positive and negativeacknowledgments. All new definitions will be given below.The control message BSCM is shipped out onto the linetogether with a text, if there is one; consequently, BSCMuses the same framing charactersas the text does. A BSCM isalways referred to one channel, but it carries a string ofbits (a byte called ACKM) describing the binary state (ACKor NACK) of all the receiving channels. It follows that BSCMconsumesan insignificant portion of line band width attimes of heavy load. Both BSCM and text carry several bitsof control information as will be describedlater.

Before describing how the protocol works, the followingconventionsare introduced:

- 15 -

a one to one correspondence between thetransmitting channelsand the eigth sectionsofa circle;

a one to one correspondence between the eigthbits of a byte and the receiving channels,as itis possible to see in Figure 3.

a transmitting(b) or in awhether or notblock.

channel can be either in a "busy""free" (f) state, depending on

it is currently associatedwith a

Further, a receiving channel can be in a noerror (g) or in an error (b) reading statedepending on whether or not a block which refersto that channel has been received correctly.

Chan o 1 2 3 4 5 6

---------------_.-._-_._-._--_._----_.._-_._----_.- - -----

Figure 3 Logical Channels and Byte Structure

3.4.2

Each block going in one direction is associatedwith aname and transmittedonto a channel. While the associationbetween block and name is made in a very naive way, the wayin which a link between block and channel is made is morecomplicated, and has to be explained in details. Thefollowing strategy is used: blocks are transmitted onsequential "free" channels in order to keep track of thetime order of the transmit operation. As soon as one blockis transmitted, the correspondingchannel is marked busy.The state of the channel is changed only when a BSCM isreceived from the other side carrying information connectedwith that channel.

At the receiving side, blocks are expected in the samechannel order as they were sent. Any time that this order is

that computer S sends blockson the channelsm-2, m-l andthe graphic ｲ ･ ｰ ｲ ･ ｳ ･ ｾ ｴ ｡ ｴ ｩ ｯ ｮ

will be what we can see in

- 16 -

broken, it is logical to require the re-transmission(s) ofthe block(s), associatedto the channel(s),which has (have)been received out of sequence.

For example, let's assumeto computer R named a, b, and cm respectively. According toabove, the situation in SFigure 4.

sm ｾＲ ｾｉ

p2

g

m

pI

g g

m-2 m-I

Figure 4 Example of a Sender Node

Channels between pointers pI and p2 will be associatedto blocks that have already been transmitted but for whichno BSCM has yet been received.

In the example just mentioned, p2 will point to channelm and pI to channel m-2, if no BSCM has yet been receivedafter the transmissionof m. At the receiving end, if noerrors occur, blocks a, b, and c, on the channelsm-2, m-land m respectively, will be received sequentially. BSCMswill be sent back to S, reporting for the receiving channelsof R the situation in Figure 5.

Presuming that S receives the BSCMs back correctly,channelsm-2, m-l and m will be set "free" gradually one byone. Thus, they can be re-used for other blocktransmissions.In terms of pointers, pI will tend to p2.

- 17 -

g

m m-2 m-l

g g

m m-2 m-l

g g g

m

Figure 5

m-2 m-l

Example of a Receiver Node

It is worthwhile emphasizingthat, due to the ACKM bytein the BSCM structure, it isreturned to S. The most recentthe state of the channelsconstruction.

not necessarythat 3 BSCMs beBSCM is capableof describing

up to the moment of its

In this example, if R receivesa BSCM belonging to them-th channel, R is capableof reaching the same final resultthat it should be achieved if it had received one BSCM at atime, the only difference being the time in which everychannel will be set free.

Let's now supposethat R receives correctly blocks aand c belonging to channelsm-2 and m respectively. As theyare acceptedby R, the blocks are properly acknowledged.Assuming that the BSCM correspondingto channel m-2 reachesS, the procedure to be followed at S for channel m-2 is thesame as describedabove. On the other hand, as soon as theblock associated to channel m is received, the bytedescribing the portion ACKM of BSCM will have the structuredescribed in Figure 6.

The channel m-l will be put into the error readingstate because according to the algorithm with which blocksare sent to S, the block connectedwith channel m-l should

- 18 -

g g b

m m-2 m-l

Figure 6 Example of ACKM structure

have been received, from the time view point, between theblocks related to m-2 and m respectively. presuming that Sreceives the byte shown in Figure 6, the following procedurewill be performed:

a) channel m-2 will be set IIfree" if its BSCM hasnot yet reached side S;

b) channel m-l will be set "free" and block b willbe transmitted with the same name but on channelm+l if this channel is free (available);

c) channel m will be set "free"

At the end of these operationswe have the situationshown in Figure 7.

f f f

Figure 7

m m+l

Blocks Situation

m-2 m-l

BSCM is always referred to the channel number of thelast block received correctly.

- 19 -

Finally, it is worth noting that the Sender must nothave more than 7 blocks outstanding, i.e. blocks transmittedand about which no news have been received (ACK or NACK).This is to avoid confusion in the interpretationof the BSCMmessage.

3.4.3

As specified before, each block going in one directioncarries a name with other information. As, at the most, itis possible to have as many different names as the number ofchannels, names going from 0 up to 7 are needed now.

Accordingis describedunavailabilityside, anothersides.

to this protocol, the availability of a nameby a bit which is called availability-bit. To detect duplicates at the receivingbit, called parity bit, is neededat both

Consequently, the message name space used by thisprotocol is 16, and it is managed in 8 pairs as follows:

the unavailability-availability bits indicatewhether or not the name has already been used.The parity bit is kept at both sides for eachpossible name.

at the receiving side, if the parity bit of thereceived block does not match the parity bitassociated with the appropriate name, thereceived parity bit is complemented, otherwisethe block is a duplicate and discarded.

when the transmitting side receives a block, theBSCM bits are examinatedone by one, and thefollowing procedurewill be adopted for eachchannel marked (g) in the ACKM bits:

a) for each free transmitting channel, no action istaken becauseonly one of these two alternativesis possible:

1 a block has never been transmitted on thislogical channel;

2) the channel has been set free by a previousBSCM;

b)

- 20 -

for each busy transmitting channel, thecorresponding channel is marked free, the nameis marked available, and the parity bit iscomplemented. In other words, both the channelnumber and the name are available for otherblock transmissions.

3.4.4

The block structureactually implemented was defined bykeeping in mind the following points as being the mostimportant requirements:

in order to consume as little line bandwidth aspossible BSCM and the text (if there is one)must be transmitted together by making use ofthe same framing characters.

due to the channel structure used by thisprotocol, at any time the number of the blockswaiting for acnowledgment at the transmittingside cannot be higher than the total number ofchannels (now eight); therefore, ACKM can berepresentedby one byte.

Once specified that, as far as the BSC transmissiontechnique is concerned, the block structure believed to bethe simplest is as in Figure 8,

where:

ACKB (8 bits)

0-2 Channel number of last received block

3 Not used

4 Parity indicator of last received block

5-7 Block name of last received block

ACKM (8 bits)

ａ ｾ ｴ ｒ ｯ ｷ ｬ ･ ､ ｧ ･ mask. Bits 0-7, from rigth to left,refer to the blocks sent immediately before the blockidentified by ACKB. If the bit is set to 1, the blockis in error, if it is set to 0, the block is positivelyacknowledged.An example is given in Figure 9.

ACKBC and ACKMC (8 bits)

Figure 8

Figure 9

- 21 -

D S A A A A C C L L D E B B

L T C C C C H H U U TEXT L T C C

E X K K K K I I P P E X C C

B M B M D D R R 1 2

C C C C

Block structure

o ====-000011111I

Channel 2 is nacked

These two bytes are the one's complement of ACKBand ACKM, respectively. They are used to verifythe validity of ACKB and ACKM, even if the blockof which they are part has a CRC error.

CHID (8 bits)

- 22 -

0-2 Channel number of the block (if this is a non-local block

3 Local/non-local indicator (see later)

4 Parity indicator (non-local blocks)

5-7 Block name (non-local blocks)

CHIDC (8 bits)

This byte is the one's 'complementof CHID. It isused to verify the validity of CHID only whenthe CRC is incorrect.

LUPR (8 bits)

This byte denotesthe number of the last receivedupdate concerning the Routing table (see later).

LUPRC (8 bits)

This byte is the one's complementof LUPR.

In order to clarify this implementation, the followingexample is given. Let us assume to have received a blockhaving for BSCM the following bit structure:

ACKB = X'5C' = B'01011100'ACKM = X'4A' = B'01001010'

Bits 0-2 and 5-7 of ACKB define the base block having thechannel number 2 and the block name 4.

From the definition of ACKM it follows thatat the ACKM bit pattern from rigth to left andthat the received block has been transmitted onthe block transmitted on channel

1 is negative acknowledged

0 is positive acknowledged

7 is negative acknowledged

6 is positive acknowledged

5 is positive acknowledged

4 is negative acknowledged

3 is positive acknowledged

(by lookingrememberingchannel 2)

- 23 -

3.4.4.1 Connection Maintenance Protocol. The Linkstatushas to bemonit-o-ied-;-""In-orde"r to know at any time ifit is active or if it has to be considered down. For thisreason: the full-duplex protocol has to be completed with aconnection protocol that is able to detect the '"going down"and the "coming up" of a Link.

We shall discuss the ,I coming up" in the next section.Here let us emphasi ze how the ,I going down" is detected. As afirst approach, we can realize that a Link went down when wetry to use it: in such a case, we do not receive any ACK forthe blocks we began to send. If we want to take a fasteraction, we must detect that a Link is down at the time itactually goes down. This aim is achieved by maintainingalways a certain amount of bi-directional traffic on theLink. The two adjacent FEPs are always listening to theirreceiving lines with a certain timeout: if the timeoutelapsesand no block is received in the meanwhile, the Linkis considereddown. This means that, if there is no block ofdata to send, fictitious traffic must be provided. ｉ ｴ ｈ ･ ｬ ｬ ｯ ｾ

messagesare preparedspecifically for this.

Since the purpose of the Hello messagesis to providethe fictitious traffic, they do not necessarelyneed anacknowledgment.In this way channelsand block names wouldnot be used, avoiding system overhead. In addition, acertain kind of acknowledgmentwould still be provided bythe timeout.

The possibility of transmitting blocksfirst level protocol seems to be usefulcircumstances.Some other examples are:

outside thein many other

the transmissionof ACKs alone (in order toavoid a certain kind of loop of ACKs)

the initialization of the Link (when the firstlevel protocol is not yet available, etc).

In this view, it is worthwhile to introduce a specialtype of block, the "local" block. Local blocks are definedas those blocks carrying an ACK and transmittedoutside thefirst level protocol, that is without requiring anacknowledgment.Local blocks do not involve any module otherthan the NCH, becausethey are born and they die inside theNCHs. In order to identify this type of block, bit 3 of CHIDis used.

3.4.4.2 The Initialization of the Link. It is clearthat -when -a---r:ionk--Is-Trithe-{nactIve stater not even theminimum amount of bi-directional traffic can be mantained.This does not mean that no activity is performed on that

- 24 -

Link. In fact, if a Node has an inacti ve Link, it must bekept listening to that Link, in order to be able to switchto the active state upon receiption of the appropriateinitialization sequence.

The purpose of the initialization sequence is toperform some checks in order to verify if the active statecan be entered. Among the points to be checked are:

the working of both the sendingreceiving line;

and the

the compatibility of the software running onboth the adjacentNodes

the Node identification, etc.

In view of this, let us introduce the "status" as theamount of information exchangedbetween two adjacentNodesduring the initialization. It is clear that in thispreliminary exchange of information, the first levelprotocol is not involved at all.

In order to allow status exchange, let us introduceanother type of local block, the "status" message.There arethree types of "status" messages:

I requestof status

2) transmissionof status

3) requestand transmissionof status

Whenever an attempt is made to start a Link, a requestof status is sent to the adjacentNode. If the request isreceived correctly, the adjacent Node will answer bysupplying its own status. The status information is checkedby the local Node, and if it is rigth, a Hello message issent. The reception of a Hello messageis the triggeringevent: at the receiving side the active state of the Linkis entered, and therefore the Hello messagesregime isestablished.

3.4.4.3 Local- - - - ----block are alwaysDLE, STX, ACKB,distinguish local(local block), the

ｾ ｬ ｯ ｣ ｾ ｆ ｯ ｲ ｾ ｾ ｾ Ｎ The first four bytes of thethe same for every block type. They are:

ACKM. Bit 3 of the fifth byte is used toand non-local blocks. When bit 3 is on

byte structure is as follows:

- 25 -

0-2 channel number on which the next non-local blockwill be transmitted

3 local/non-local indication (set to 1)

4 request of synchronization indicatorstart or restart)

(after

5 stop request indicator

6 status request indicator

7 status included ｩ ｮ ､ ｩ ｣ ｡ ｾ ｯ ｾ

When bits 4,5,6 and 7 are all zero, the local blockcontains an Hello message.

The status field,information necessarymaintenanceprotocol. Theafter the LUPRC byte, see

when included,to initializestatus field isFigure 10.

contains all thethe connection

placed immediately

NODEID LINKID FLAGS LENR

AVAIL SPARTY RPARTY UPN

SOFLV NUMNOD

I-I- ROUTING TABLE :rT _

Figure 10 Status Message

where:

- 26 -

NODEID is the number identifying the Node of theSender

LINKID is the number identifying,side, the Link over whichtransmitted

at the sendingthe block is

in

in

Prepare

SendingProgress/NoinSending

reservedSending Line Active/Not ActiveReceiving Line Active/Not ActiveLink Active/Not ActiveLink in Prepare State/Not in

FLAGS allbit 0:bit 1:bit 2:bit 3:Statebit 4:Progressbit 5: Receiving in Progress/No ReceivingProgressbit 6: writing required/No Writing Requiredbit 7: update Required/No Update Required

LCHR last channel number received correctly

AVAIL availability of the names (a bit set to 1indicates that the correspondingname is busy)

SPARTY parity of the names for the nexttransmission

RPARTY parity of the names after the lastreceiption

UPN routing table update number in this block

SOFLV software level

NUMNOD number of nodes supposed to be in thenetwork

4

- 27 -

THE INTERFACE FUNCTIONS LAYER---- --_._----_.- -_.__.- -- -_._-

4.1 General Information

The Interface Functions Layer provides the interfacebetween the Common Network (Connection Network plusCommunication Functions Layer), and the Application Layer,that is the layer in which the Network Users (Netusers)reside.

The Interface Functions Layer basically provides:

a) the defining and undefining of ports (Logicalunits) on the Communication System

b) extemporaneous services,mailing

such as query and

c) setting up and closing down of Logical Channelsbetween the Applications.

Once established, Logical Channelsare maintained by asoftware component of the Interface Functions, calledSession Handler (SH). Along the Logical Channel,Applications exchange units of information, called BIU(Basic Information Unit).

The combination of the Interface Functions Layer andthe Common Network constitutesthe CommunicationSystem.

The characteristics of a Logical Channel can besummarizedas follows:

a) it is driven with an half-duplex technique:

b) it does not provide an error-free connection;

c) error (loss of aIU) is signalled at both ends ofthe Logical Channel.

It is worth noting at this point that a possible,little effort improvement of the characteristics of aLogical Channel could be a full-duplex protocol. One mustkeep this in mind, when implementing RPCNET, to reserve thispossibility for the future.

A third componentof the Interface Functions Layer isthe CALL/RETURN interface (in the VM and OS implementations

- 28 -

called NAC, Network Access Controller) r which performs anumber of tests on the operations issued by the user (theApplication) before passing the request to the othermodules.

In the following we will describe in detail theoperations and the protocols of the three componentsof theInterface Functions Layer r namely:

a) the SessionHandler (SH)

b) the Network ServicesMahager (NSM)

c) the Network Acces Controller (NAC) , orCALL/RETURN Interface.

In Appendix C the formats of the packets used by theNSM and the SH are illustrated.

- 29 -

4.2 The SessionHandler

The SessionHandler (SH) provides a mechanismby whichtwo Applications can communicate each other during asession.

4.2.1

The SH receives, from an Application, units ofinformation called Request Units (RU), together withadditional control information. The SH uses the controlinformation to build a Request Header (RH), which is pre-fixed to each RU sent and which is interpreted by the SHreceiving the RH-RU combination. This combination is calledBIU (Basic Information Unit).

During a session, the two Applications are connectedthrough a Logical Channel, which, in turn, can be consideredas an half- duplex connection, with these characteristics:

a) no error free connection

b) error detection and signalling at both sides ofthe Logical Channel

c) RU limited in size

d) RU data integrity maintained

e) RU sequentialitymaintained

f) RU duplication impossible

These characteristicsare to be mapped on the CommonNetwork characteristics,which are:

a) packet length limited

b) order of packets not maintained

c) loss or duplication of packetspossible

d) packet data integrity preserved

e) changes in the Common Networknotified.

connectivity

- 30 -

4.2.2 Internal Protocols

In order to build the LC characteristicson the CommonNetwork, the SH has to use some internal protocols, whichare completly transparent to the interconnectedApplications.

Becauseof the complex SH structure, some functionalunits can be distinguished,as show in the functional schemeof Figure II.

Ａ Ｎ ｾ Ｎ ｾ Ｎ Ａ ｾ ｅ ｅ Ａ ｩ ｾ ｡ ｴ ｾ ｯ ｾ The two Applications exchangedata(RU) through the Logical Channel following the LC rules (seeRNAM macros). Becauseof the possibility of RU loss, theApplications have to provide an agreementupon the recovery.The type of the recovery depends on the Applicationcharacteristics,and should be defined at that level.

4.2.2.2 PresentationServices. In order to facilitatethe Appllcatlon-s about' Ehe--LC- usage some presentationServices are provided:

a) handling of the Flip-Flop driving of the LC;

b) providing a logical data entity considered atthe Application level as an unit, set up by anRU chain;

c) providing three types of responseon the singleLC operation: no-response, exception responseand definite response.

Ａ Ｎ ｾ Ｎ ｾ Ｎ ｬ ｄ ｡ ｴ ｾ ｌ ･ ｮ ｾ ｨ ｾ ｧ ｾ ･ ｲ Ｎ Becauseof the unrelateddata length limitations of the LC, and of the PacketSwitching System, an RU data length adaptation becomesnecessary. For this reason, a segmenting/reassemblingservice has to be provided.

The unit of information destinated to the packetSwitching System and built up with a BIU or BIU segmentprefixed with addressingand reconstructioninformation (TH,TransmissionHeader), is called Path Information unit (PIU).So that, this SH section, besides providing the BIUsegmenting/reconstruction,has to preserve the BIU dataintegrity, discarding the BIU that cannot be completed, andnotifying the related exception.

4.2.2.4 Data Flow Control. In order to realize the LCcharacterIsticsｾ Ｍ ｴ ｨ ･ Data'-plow Control has to provide:

· '

- 31 -

RU11 ChI.RUI

og1ca anneAPPLICATION

I IIAPPLICATION

ｓｾ SH

PRESENTATION ;:::: ;:::= PRESENTATIONSERVICES SERVICES

Virtual ConnectionBIll BIllDATA LENGTH

ｾ ｾDATA LENGTH

ADAPTER ADAPTER

I PIll Virtual Connection PIllDATA FLOW DATA FLOW

CONTROL I n CONTROL

ｾｕｾ -lUMULTIPLEXING/DEMULT. I

r== MULTIPLEXING/DEMULT.

r- -

....--

COMMON NET\-!ORK

Figure 11 Logical Channel between two Applications

a) the maintenanceof the BIU sequentiality;

- 32 -

b) the recognition and the discarding of theduplicate PIU;

c) the recognition of the PIO loss;

d) the syncronisationof the two Applications onthe LC.

!. ｾ Ｎ ｾ Ｎ ｾ ｌ ｃ ｾ ｵ ｬ Ａ Ｚ ｩ Ｒ Ｑ ｾ ｾ ｩ ｾ Ｎ ｧ Ｏ ｄ ･ Ｍ ｾ ｾ ｬ ｴ ｩ ｅ Ｎ Ｎ Ａ Ｎ ･ Ａ ｩ ｾ Ｎ The activi tyof all the LCs is multiplexed on the connectionwith theCommon ｎ･ｴｷｯｲｾＬ and the ｩ ｮ ｣ ｯ ｭ ｩ ｲ ｾ traffic is distributedamong the actIve LCs.

From the functional point of view, the SH can beconsidered subdivided in four sections (consideringas aseparatesection that provides the error handling), whichwill be described in detail in the following sections.

4.2.3

are:

33 -

PresentationServices

The presentationServicesprovided to the Applications

a) handling of the Flip-Flop discipline of the LC:

b) RU chain control:

c) responsetype control.

In the Flip-Flop discipline the Sender/Receiverrelationshipon the half duplex LC is fixed at any time, andcan be reverted only on initiative of the Sender. Theprotocol is based on the status of an indicator (ChangeDirection), associatedto each data transfer requestat theSender side. The rules governing the PresentationServicesare very simple and regard the following controls:

a) Chain Control:

b) Change Direction Control:

c) Responsetype Control.

The most part of the control is carried on at theSender side, in order not to send data affected by a ruleviolation. However, some security checks are made also bythe Receiver, and where a violation of the rules isrecognized, the appropriateexception is generated.

All the information necessary to the PresentationService control are carried by the BIUs exchangedduring thesession.The field that contains this information is theRequest Header (RH), and this is the first field of eachBIU.

ｾ Ｎ ｾ Ｎ ｬ Ｎ ｬ ｒ ･ ｧ ｾ ･ ｳ ｴ ｾ ｾ ｡ ､ ･ ｲ Ｈ ｾ ｧ Ｉ Ｎ The Request Header (RH),which is attached to each RU as the RU passesthrough thePresentationService Control, contains all the indicatorsfor the PresentationService Protocol. The RH is two bytesin length, and the information carried by it is thefollowing:

a) Action Code Field (ACF)

b) Action Modifier Indicator (AMI)

- 34 -

c) Change Direction Indicator (COl)

d) Chain Control Field (CCF)

The above control fields are defined as follows:

a) specifies the action to be performed on theinformation which follows;

b) contains the indicators that modify the actioncode meaning;

c) this controlsession, byLC data flowrole;

indicator can be used, during athe Sender in order to reverse the

direction, to assume the Receiver

d) this field establisheswhich element of a chainof RUs this RU is: first, middle, last, or onlymember of a chain. RUs that are chained togetherform a unit. Two indicators, "begin chain" and'end chain" provide the chain controlinformation.

4.2.3.2 Chain Control A;' Chain" consistsof a set of- - _. _. ---- ----related RUs which are recognized as an entity through thenetwork. A chain has an RU which is the ·first of the chain(marked "begin chain"), which may be followed by one or moreMiddle Chain RU (s) (marked "middle"), and ended by an RUthat is the last in chain (marked "end chain"). A chain mayconsist of many RUs, or only one RU; the chain as an entityis the basic unit for the recovery.

In the following scheme the rules for processingchainsare given. These rules are based on the assumptionthat the·'begin chain" and "end chain"indicators are checkedseparately first the "begin chain" r then the "end chain",every time following the appropriaterules.

4.2.3.2.1 Chain Control at the Sender side..- - - - --_ .. ---- - -- - - -- --- - ｾＭ

The first RU in chain is marked "begin chain",and puts the Sender into the "in chain" state.

If a negative responseto the current chain isreceived while in the "in chain" state, the"between chain state" is entered.

- 35 -

The last RU in a chain is marked "end chain". Itreturns the Sender into the "between chain"state. Middle RUs in chain do not affect thechain state.

If in the ;'between chainll state the Applicationprogram tries to send "middleu or \/last" inchain RU, an error indication is returned to theApplication program and the RU is not sent. TheChain control status remains unchanged.

If in the "between chain" state a response isreceived, the chain' 'control status is not｣ ｨ ｡ ｮ ｧ ･ ､ ｾ and the responseis forwarded to theApplication program.

If in the " in chain" state the Applicationprogram tr ies to send a I, begin chain" RU: anerror indication is returned to the Applicationprogram, the chain control state is not changed,and the RU is discarded.

4.2.3.3.2 Chain Control at the Receive side.

If in the "between chainll state, a 'begin chain"RU puts the chain control into the "in chain'lstate.

If in the "between chain" state, middle in chainor end chain RUs are discarded, a negativeresponse (when required) with a sense indicationof chaining error is given, and the "purgingchain" state is entered.

If in the "in chain" state, middle in chain RUsdo not affect the chain control state.

If in the lIin chain" state, and an end chain RUis received, the chain control returns to the'between chain" state.

If in the ,I in chain" state, and a sequenceerroris recognized, the "purging chain" state isentered.

If in the II purging chainll state! purging isstopped by the receipt of an "end chainlo

• Whenpurging stops, the chain control enters the., between chain" state. The end chain ind icatorhas to be examinatedon all chain elements,eventhose elementswhich caused the "purging chain"state to be entered.

- 36 -

If in the "purging chain" state, purging isstopped by the receipt of a "begin chain" RU.When purging stops, the chain control enter the"in chain" state.

If in the "purging chain" state a "middle inchain" RU is recei ved, the chain controldiscards the RU, no responseis generated, andthe state remains unchanged.

As a general rule, a negative response isgenerated when a sequenceerror is recognized,in whatever state the chain control is.

The situation can be summarized in the flowcharts ofFigure 12.

4.2.3.3 ｃ ｨ ｡ ｮ Ｙ Ｎ ｾ ｄ ｩ ［ Ｚ ｾ ｾ ｾ ｩ ｯ ｮ COf.ltro:!. The Change Direction(CD) -indIcator is used in the PresentationServices toexchange the Send-Receive role between two Applicationsduring a session. Only a requeston the normal (Sender toReceiver) flow which is also marked "end chain" or "definiteresponse" may carry a CD. When the sender includes CD in arequest, it indicates that the sending Application isprepared to receive/ and that the other Application cansend. The receiver is required to control the CD. In thefollowing the rules for processing the Change DirectionIndicator are given.

The Sender when receives a SEND request withCD, enters the "exchanging role" state. In thisstate (Pseudo - Receiver) only RECEIVE requestsare accepted.

If a RU is received without error while in the"exchanging role" state the "receive" state isentered.

If a RU is., exchangingunchanged.

received inrole" state,

errorthe

whilestate

in theremains

If an error indication carrying CD not acceptedor just negative acknowledging the last requestis received while in the "exchanging role"state, the "sender" state is entered, and thepending RECEIVE request (if any) is closed withthe "CD not accepted" exception.

middor b

- 37 -

begin chain or neg. response

CHAIN SENDER

CHAIN RECEIVER

Figure 12 Chain Sender and Chain Receiver

If the CD indicator is received and recognized,while in the 'receiver" state, the "exchangingreceive role" is entered. In this state, themode of the responseis forced as adefinite".

- 38 -

If the CD indicator is received together with anexception indication on the requestcarrying CD,the state is not affected, and a negativeresponseis issued, with a sensecode of CD notaccepted.

While in the "exchanging receive role" state, aSEND operation terminates without error, the"send·· state is entered.

While in the "exchanging receive role" state, ifthe SEND operation ter'minateswith error, thestate remains unchanged, and the operation isclosed with error to the Application.

To be noted that, due to this mechanism, the Sender, incase of CD, will not be notified until the first RECEIVEoperation will be closed. The exception (if any) will bereflected only on the "old" Receive side. This is the onlycase in which the LC operationsare unbalanced.

The above operationsare depicted in the flowchart ofFigure 13.

Ｑ Ｎ ｾ Ｎ Ｑ ..1 ｂ･ｳｰｯｮｳｾ Ａｙｅｾ ｾｯｮｴｲｾｬＮ The "Form of responserequested" field is used to establish the responseaction.There are three options with regard to requesting responses:the Sender may request no responses (No Response), aresponseonly if an error occurs (Exception Response), or aresponsewhether or not an error occurs (Definite Response).As far as the data flow control is concerned, when nNoResponse"or "Exception Response" is choosen, the Sender cancontinously send requests. Instead, when the "DefiniteResponse" is choosen, the Sender must wait for the responseto a request before sending another one. At the Receiverside, the ·'Form of ResponseRequested" field is used only toestablishthe responseaction, but no data flow control isinvolved. These rules are affected by the existenceof RUchains: each "chain" is treated by the Sender and theReceiver as a single request. This high level requestcan besent in one of the three possible modes: No-Response,Exception Response, Definite Response.In order to handlethis high level request, each RU in the chain is sent in theappropriatemode:

for "No Response"chain, each element of thechain is sent in No Responsemode;

SE

Figure 13

- 39 -

withouter or

orerror

Change Direction Control

for "Exception Response" chain, each element ofthe chain is sent in Exception Responsemode;

- 40 -

for "Definite Response"chain, the last elementof the chain is sent in Definite Responsemode,the others are sent in Exception Response mode:this to have only one responsefor the chain,consideredas an entity.

Only these types of chains are allowed to be sent. TheSender of a chain has the responsibilityof the appropriatesetting of the .1 Form of ResponseRequested" field for eachelement of the chain. The Receiver of a chain is required,as responsetype control, to examine the 0' Form of ResponseRequested" field only on the' last element of the chain,unless an error occurs earlier in the chain.

For security purpose, the "Form of ResponseRequested"field is associatedto each BIU or BIU segment, and for thisreason, it is carried by the TransmissionHeader (TH).

4.2.4

The length of the data unit (RU) which can be exchangedon the Logical Channel is limited, but that limitation isunrelated to the data unit length limitation, which is acharacteristic of the Common Network used, generally morerestrictive.

pratically, there is the need to adapt the BIU length(RH+RU) to the Common Network characteristics. Thisnecessitycan be satisfied having a mechanismto segment theoutgoing BIUs (when ｮ ･ ｣ ･ ｳ ｳ ｡ ｲ ｾ ｙ Ｌ and to reassemble theincoming BIU segments.Each outgoing BIU is segmented (whennecessary)and prefixed with addressability, identificationand sequentialorder information (TransmissionHeader, TH).A TH plus a BIU or a BIU segment is called a PathInformation unit (PIU), that is the data unit accepted bythe Common Network. The TH contains all the information toidentify the BIU and the BIU segment inside the BIU. ThePIUs are passed to the Common Network in order to beforwarded to their destination. Each PIU pertaining to asegmented BIU is sent separatelyand the next in sequencesegment is not sent until the previuos one has not beenpositively handled by the local transmission subsystem(Common Network). This rule has been introduced in order tomultiplex the local LC outgoing traffic at the PIU level,and to control the BIU segmentsequentiality at the firststep of the transmissionpath, reducing the probability ofout of sequencearrivals at the destination (the CommonNetwork does not maintain the PIU sequentiality).

The identification of each PIU is accomplishedby meansof three fields of the Transmission Header (TH), andprecisely:

the PIU number, which is an incremental andcyclic counter, identifying the order number ofthe PIU within the session;

the BIU number, which is an incremental andcyclic counter, identifying the order number ofthe BIU within the session;

the Segment Mapping Field, which is a twoindicator field that identifies the relativeposition of the segmentwithin the BIU: first,middle, last or only BIU segment.

All the PIUs marked ;lfirst II or "middle" BIU segmentarefixed in length (the length being the maximum length allowedby the Common Network); the PIUs marked "last·1 or i'only" BIU

- 42 -

segment are variable in length up to the maximum allowed.

The incoming PIUs, filtered by the Data Flow Control(DFC) section, are to be reassembledin order to reconstructthe original BIU. Becauseof the possible out-of-sequencearrival of the BIU segments (PIU), the BIU data integrityhas to be controlled during the reconstruction. When thereconstruction cannot be completed, because the DFC hasrecognized a PIU loss, the BIU is declared in exception anddiscarded.

The segment identification is organized in such a waythat it is possible to put the single segment in the correctposition inside the reconstruction buffer whichever thearrival order is.

4.2.4.1 TransmissionHeader. The Transmission Header(TH) -is -that--par"r-61a PIU-which provides addressability,identification and sequential order of the BIU or BIUsegment carried by the PIU as its text part. The networkaddressesare carried as Destination Address Field (DAF) andOrigin Address Field (OAF) by the TH. The identification andsequentialorder are carried by three fields, as mentionedbefore:

the BIU sequencenumber (BSN)i

the PIU sequencenumber (PSN)i

the Segment Mapping Field (SMF).

The Data Count Field (DCF) contains a binary count ofthe text (BIU or BIU segment) carried by the PIU. The schemeof the TH is depicted in Figure 14,

wherePTY Priority (1 byte): contains the priority with

which this PIU will be handled within the CommonNetwork. In the first implementationthis fieldis unused.

DAF Destination Address Field (3 bytes): containsthe network addressto which the associatedPIUhas to be forwarded.

OAF Originator Address Field (3 bytes): contains thenetwork addressof the originator of this PIU.

Figure 14

- 43 -

PTY DAF

OAF PSN

FLAGS BSN DCF

TH structure

PSN PI U Sequence Number (1 byte): contains thesequence number of the PIU. This incrementalnumber is cyclic, and represents the ordernumber of the PIU within the session.

FLG Flags (1 byte):SMF (Segment Mapping Field) B'000000111 thisfield representsthe relative position of thisPIU inside the BIU to which it pertains. Twoindicators, "First" (B I 00000001'), and "Last"(3'00000010 ), give the possibility to definefour states: first segment, middle segment,last segment and only segment.RRC (RequestedResponseControl) B ' 01000000'It defines the form of the requestedresponse.The possible types are: No response, Exceptionresponse (B ' 00100000') and Definite response(8 '01000000") .LOC (SH Internal Message): The internal messageis a protocol message: this is signalled bythis flag (B'10000000').

BSN BIU Sequence Number (1 byte) contains thesequence number of the BIU to which this PIUpertains. This number is cyclic and it is neverreset. The Break count is merged into thisfield.

- 44 -

DCF Data Count Field (2 bytes) contains a binarycount (in bytes) of the text carried by the PlU.

- 45 -

4.2.5 Data Flow Control

The Data Flow ControlHandler has to provideactive logical channel:

(DFC) section of the Sessionthe following functions for each

1 maintenanceof the BIU sequentiality;

2) recognition and discarding of duplicate PIUs;

3) recognition of PIU loss;

4) syncronisationbetween the two Applications onthe Logical Channel during the session;

and moreover it has to:

5) avoid the buffer congestion;

6) prevent the deadlocks.

The DFC to DFC protocol that performs the previouslystated characteristicsof the data flow is described in whatfollows.

Basically, the DFC to DFC protocol uses the well-knownwindow strategy, and acts on the PIU flow. Supposing thatthe PIU sequencenumber field in the TH allows sequencenumbers to range from 0 to n-l, the Sender will not transmitmore than W PIUs, without receiving an acknowledgment,the Wbeing the window. Of course, W must be less than n.

The basic rules for the Sender and the Receiver aredescribed in the following. The structure of the window issketched in Figure 15.

SENDER: Let M be the sequencenumber associated withthe window left edge.

a) The Sender transmits only PIUs whose sequencenumber lies between M and up to M+W-l. If therigth edge of the window is reached withoutreceiving any acknowledgement, the activity isholded waiting for a "receiver's acknowledgestatus" (from now on briefly "status").

b) On receiptReceiver'swidth, theover thePIUs, and

of a "status" consisting of thecurrent window left edge and window

Sender'sleft window edge is advancedacknowledged (positive or negative)the rigth window edge is adjusted

Figure 15

- 46 -

a M M+W N-1 a- 1

The Dynamic Window

consistently. The "status" may be received atany time. No recovery is provided for thenegative acknowledgedPIUs.

RECEIVER:.. _---_. --the left edgeedge is definedwidth.

Let M be the sequencenumber associatedwithof the current Receiver'swindow. The rigth

as M+W-l, where W is the current window

a) Every PIU received with a sequencenumber insidethe "dynamic window" is acceptedor discarded ifalready received. As "dynamic window", theReceiver considers the window defined by thelast "status" sent.

b) PIUs arriving with a sequencenumber outside the" dynamic window' edges are discarded asduplicates.

c) The "status" is sent to the Sender every "halfwindow" that is when the PIU with sequencenumber M+W/2-1 or over and M+W-l or over havebeen received. The "status" contains the"dynamic window' left edge and width. The widthis calculated according to the memoryavailability. This information is dynamicallyupdated on PIU receipt, considering that part ofthe window which contains only the PIUs receivedor declared loss.

d) The receipt of a PIU with a sequencenumber overthe r igth edge of the "cur rent window" isconsideredas an indirect acknowledgmentof the'status" sent, so that the current window isupdated following the 11 status" information, andthe acknowledged"status" is purged.

- 47 -

ＡＮｾＮｾＮＡ How ｴｨｾ ｅｲｯｴｯｾｯＡ ｾｯｲｾＮ Before to precise theDFC protocol, some general considerationsare to be made. Nomechanism is provided by the Common Network to avoid abuffer congestion at the SessionHandler level. SH has toprotect itself against the possible buffer congestioninduced either by out-of-sequencePIU arrival and by a poorApplication synchronisation.

In both the cases, a certain amount of storage is keptbusy waiting for BIU completion or for a RECEIVE requestfrom the Application. Moreover, there is the possibility ofPIU loss during its journey through the Common Network, thatmeans an infinite out-of-sequence for the last PIU, andconsequentlythe SH, on the related Logical Channel, may bekept waiting indefinitely for BIU completion or to providethe correct BIU sequentiality.

In the hypothesisof no PIU loss, the DFC protocolcould avoid buffer congestion, controlling the window width(W), considering the buffer availability and the Applicationsynchronisation. The out-of-sequence causes delay in BIUdelivering, and in window advancing, pratically reducing theLogical Channel bandwidth.

The same happens in case of poor synchronisationbetween the two Applications. Clearly, no precautionscan betaken by the OFC against a bad synchronisation between theApplications, because this is out of the OCF control. Theonly possibility to improve the Logical Channel bandwidth,assuming at the best the buffer availability is to reject,as an error: long out-of-sequence, where with long out-of-sequence is intended an out-of-sequencewith very littleprobability to happen, practically out of the range of themost part of the observedout-of-sequencefrequencies. Inthis case,if the Logical Channel bandwidth is improved, thereliability is reduced, becausea PIU is declared in errorwithout an objective prove of the error itself. When thepossibility of PIU losting is considered, deadlocksituations are to be resolved. Such situations are due bothto Application PIU loss and to Ｂ ｳ ｴ ｡ ｴ ｵ ｳ ｾ PIU loss. The OFCprotocol, as it has been described, is unable to avoid orrecover these deadlock situations, so that it has to becompleted in order to consider also the possibility ofinformation losting.

The following hypothesis, basedon the Common Networkcharacteristics,can be made: a PIU loss is always connectedwith a reductive change in the Common Network topology; inother words, only when a Node of the Common Network passesfrom the active to the inactive state (due to a software ora hardware failure), there is the possibility of a PIU loss.

- 48 -

Because in RPCNET the logical Network Control Point (theNetwork Services Manager) becomes acquainted with everychange in the Common Network active topology, the DFCprotocol mechanism to avoid deadlock situations may betriggered by the knowledge of a reductive reconfiguration inthe Common Network.

To summarizer there is a number (M) that representsthemaximum out-of-sequence acceptable by the ｄ ｆ ｃ ｾ when thisnumber is exceededby a long out-of-sequence, the relatedPIU is considered lost, and the window is updatedconsistently. In case of a reductive reconfigurationof theCommon Network, DFC provides a recovery mechanismto avoiddeadlock situations, that is, every Logical Channel which atthe moment is in the "waiting for status·1 state (the onlystate in which there is a deadlock possibility), sends a" Information for status" to its counterpart, to solic it the"status" and to resynchronizethe session.At the Receiverside of the concernedLogical Channel(s), the receipt of an.. Information for status" freezes the window stateconsidering in error (lost) all the PIUs not arrived at themoment, and whose number lies between the left window edgeand the number reported in the"Information for status"(last PIU sent). In any case, no deadlock is possible,becauseeither all the missing PIUs arrive soon or later, ora reductive reconfiguration is signalled, starting therecovery mechanism (in case of Definite Responserequested,or end of window reached), or new activity on the LogicalChannel allows to clarify the situation.

In order to use the DFC protocol, three parametersareto be defined: the number (N) of the PIU numbering cycle,the width (W) of the window, and the number (M) of themaximum end-of-sequenceaccepted.

(N) is defined by the maximum bynary numberdefinable in the PIU SequenceNumber Field (SNF)of the TH. The PIU SNF is one byte width, thatmeans a numbering cycle of 256 (from 0 to 255).As a matter of the fact, the PIU identificationcycle, as far as the duplicate recognition isconcerned, may be considered higher, becausebeside the PIU SNF· there is also the BIU SNF tocomplete the PIU identification. These twosequencenumbers (unrelatedeach other) may risethe cycle up to 65.536.

(W) Its value is mainly related to the receiving SHbuffer availability, becauseall the PIUs insidethe window not pertaining to the BIU presentlyunder reassembling or waiting for a RECEIVErequest, have to be maintained in memory.

- 49 -

Clearly, (W) is not univocally and staticallydefinable, because its value dependson manyfactors: on the dynamic SH buffer availability,on the type of the Logical Channel activity, andon the Common Network crossing delay (this toavoid, when possible, stops on the sendingactivity due to the fact that the end-of-the-window is reached before receiving the half-window II status"). Anyway a relation among (N)and (W) can be fixed: W < N/2 to avoid that thearrive of an old PIU may appear as a newtransmission (N/2 should be a convenientnumber). Just to make a guess (to be revisedafter a test period) , in the firstimplementation it was adopted: W = 16 (as firstvalue at the sessionopening time: this valuewill be recomputed dynamically during thesession).

(M) Its possible value is a therothical mystery;there has been a first attempt to evaluate thisnumber using the simulation approach. The modelused is referred to a static Common Network (noreconfigurationconsidered) using the "optimalpath" as routing technique. The result is a verylittle probability of out-of-sequence and amaximum observed out-of-sequence of the sameorder of the number of the crossed nodes. Thisinformation is not sufficient to establishamean value for (M); a relationship wasestablished between (M) and (W): M < W/2 toavoid that, using the long out-of-sequencetechnique, the uncertainity on the PIU arrivalshall be over half window. In the firstimplementation, a value was assumedfor (M): M =4

ＡＮｾＮｾＮｾ ｾｯｭｰｬ･ｴ･ DFC ｦｲｯｴｾｾｑｬＮ The complete DFCprotocol can be describedusing the state diagram technique:

SENDER control

a) When in IDLE state, and a request to send a PIUis received, the SENDING PIU state is entered.

b) When in IDLE state, a receipt of a "status" putsthe SENDER control in UPDATING WINDOW state.

- 50 -

c) When in SENDING PIU state the PIU sentacknowledged from the Common Network of a PIUwhose sequence number is inside the window,returns the SENDER control in the IDLE state.

d) When in SENDING PIU state the PIU sentacknowledged from the Common Network of a PIUwhose sequencenumber is the last permitted bythe current window or of a PIU that is the lastsegmentof a BIU requesting Definite Response,puts the SENDER control in WAITING FOR STATUSstate.

e) When in WAITING FOR STATUS state the receipt ofa "status" puts the SENDER control in UPDATINGWINDOW state.

f) When in WAITING FOR STATUS state, the receipt ofa "status' which does not reset the DefiniteResponserequest. does not change the SENDERcontrol state.

g) When in UPDATING WINDOW state, the windowupdated condition puts the SENDER control in theIDLE state, or, if the updated window width is0, the control returns to the WAITING FOR STATUSstate

h) When in WAITING FOR STATUS state, the signallingof a reductive reconfiguration of the CommonNetwork puts the SENDER control in SENDINGREQUEST FOR STATUS state.

i) When in SENDING REQUEST FOR STATUS state. therequest sent condition returns the SENDERcontrol to the WAITING FOR STATUS state.

1) When entering the WAITING FOR STATUS state, theexistenceof a reconfigurationsignal inside theactual window puts the SENDER control in SENDINGINFORMATION FOR STATUS state, and clears thesituation, then the Sender control returns tothe IDLE state.

RECEIVER control

a) When in IDLE state, the receipt of a request for"status" puts the RECEIVER control into theCLEAR WINDOW state.

b)

- 51 -

When in IDLE state, the arrival of athe RECEIVER control in the CHECKNUMBER state.

PIU putsSEQUENCE

c) When in CHECK SEQUENCE NUMBER state, a PIU witha sequence number out of the "dynamic window"causesthe PIU to be discarded,and the RECEIVERcontrol returns into the IDLE state.

d) When in CHECK SEQUENCE NUMBER state. a PIU witha sequence number inside the "dynamic windowh

(and not yet received) causes the PIU to beaccepted, and the RECEIVER control enters intothe UPDATE WINDOW state.

e) When in UPDATE WINDOW state, the receipt of aPIU whose sequence number is at the SENDER"status" trigger point causes the RECEIVERcontrol to enter the SENDING STATUS state.

f) When in UPDATING WINDOW state, the receipt of ageneric PIU causes, after the window updating,the RECEIVER control to enter the IDLE state.

g) When in SENDING STATUS state, the dynamic windowis updated, and the new statusmessageis sent.The RECEIVER control returns into the IDLEstate.

h) When in UPDATING WINDOW state, if the left edgeof the updateddynamic window falls into a PIUwhich is the last segmentof a BIU requestingDefinite Response, the RECEIVER control entersthe SENDING STATUS state.

i) When in UPDATING WINDOW state, the receipt of an"information for status" updates the windowstatus, using the "information for status"information, and if status point has beenreached, the control passes to the SENDINGSTATUS state, otherwise the control passestothe IDLE state.

1) When in CLEAR WINDOW state, all not receivedPIUs, until the last PIU sent (in the "status"message), are declared lost. The control ispassedto the SENDING STATUS state.

The situation is depicted in theFigure 16 and Figure 17.

flowcharts of

- 52 -

window updated & def. resp. reset

status received

requestsentconditi n

igurationthe window

sp.et

Figure 16 Data Flow Control: Sender side

4.2.6

Due to the layered structure of the Session Handler,the exceptions, like the data flow, have to cross all thelayers, in order to collect the appropriate error condition

- 53 -

Figure 17

arrival

PIU out of window

Data Flow Control: Receiver side

request forstatus received

(to be reflected to the Application), and to put the singlelayer functions in their appropriatestates.Moreover, as ina sessionthere are two Applications linked together, bothhave to be notified of eventual exceptions, wherever theexception has been recognized. Practically, the only errorcondition is the PlU loss, recognized by the Data Flow

- 54 -

Control layer. The PIU loss exception induces the exceptionfor the BIU to which this PIU pertains: this is recognizedby the SessionException Handler (SEH), which provides:

a) the insertion of this exception in themessage in order to forward theexception" information to thecountert?art;

"status·,I BIU insession

b) the signalling of the exception to the DataLength Adapter (DLA) layer and to thePresentationService Handler (PSH) layer, whenthe BIU in exception becomes (as sequencenumber) the "actual" BIU, that means when thisBIU is explicitly requestedby the Applicationvia a RECEIVE operation;

c) the reflection of the exceptionthe eventually collected errorthe Application (closing inRECEIVE operation).

together withconditions, toexception the

Analogously,exception via theprovide:

when thei'statustl

SEH is informedmessagemechanism,

of a BIUit has to

a) the signalling of the exception to the DLA andPSH layers;

b) the reflection of the exception together withthe eventually collected error conditions to theApplication. This reflection may be synchronousor asynchronous, depending on the way ofproceedingchosen by the Application for itsrequests (synchronous means Definite Response,asynchronousmeans Exception Response).

The exceptions recognized directly by the PSH onrequests that are semantically incorrect, do not proceedthrough the other layers, but are immediately reflected tothe Application originating the request.

The possible error condition are:

Basic error:

BIU data integrity failure (the loss of one (ormore) PIU(s) pertaining to the BIU causesthisfailure; and the BIU is discarded).

Induced error:

- 55 -

BIU chaining failure (the loss of a BIU that ischained invalidates all the chain of BIUs).

Change Direction not accepted (the failure of aBIU carrying the Change Direction request causesthe rejection of the Change Direction, and thereturn of the control to the original Sender).

Warning Information (not considerederror):

BIU data overflow ( the received BIU is longerthan the buffer allocated by the RECEIVEoperation; this exception is presentedonly tothe Application at the RECEIVE closing time).

4.2.7 A final remark

• .56 -

In the actual implementation, the Hsend status"triggering event is the memory availability. In fact, ifthere is no memory available when a status has to be sent,the preparationof the statusmessageis delayed until whenthere is memory availability. This condition was establishedto prevent the sending of a statuswith window width equalto zero, and then another status when the window width maybe enlarged.

- 57 -

4.3 The ｾ ･ ｴ ｷ ｯ ｾ ｾ ｾ ｾ ｲ ｶ ｩ ｣ ･ ｾ ｾ ｡ ｮ ｡ ｧ ･ ｲ

The Network Services Manager (NSM) is an InterfaceFunctions component which provides for the control of theLogical units (LUs) and the Logical Channel Terminations(LCTs), and supplies a set of services to the LUs and LCTswhich it controls.

The NSM maintains knowledge of the statesof all LUs,LCTs, and of the sessionswhich the LCTs are participatingto. The NSM itself is a system LCT, and it maintainspermanent sessions with all the other NSMs, sharing theInterface Function Layer control. The NSM is in permanentcontact with the CNM of the node to which it belongs, inorder to have an up-to-date knowledge of the real networkconfiguration.

The set of servicesused to control the Logical Networkare called Network Services. The NSM may send NetworkServices requeststo other NSMs in order to perform thefunctions requested.Every request for service to the NSM bythe Application has to be made through an LU. In case wherethe service is requested by another NSM, the NSM isresponsiblefor its execution and subsequentnotification ofthe originator.

Network servicesare divided into categories accordingto the functions being performed. The categoriesdefinedare:

a) Measurementservices

b) Network Operator services

c) Sessionservices

d) Mailing services

e) Inquiry services.

The Network Services functions may be invoked only by arequest containing coded information. The codes are detailedin Appendix C.

The NSM, as system LCT, mantainsmultiple sessionswithall the other NSMs in the Network. Each Multiple sessionishandled by the Multiple SessionHandler. The data unit (8IU)exchanged between NSMs are monosegment, i.e. the maximumsize of a data unit is equal to the maximum size of the PIUin the Common Network. The Logical Channel related to each

- 58 -

one of the sessionwith the other NSMs can be considered asa full-duplex connection with the following characteristics:

a) Error free connection.

b) Data units limited in size (same limit as theCommon Network) •

c) Data integrity mantained.

d) Data unit sequentialitynot mantained.

e) Data unit duplication impossible.

In a NSM, a number of functional units can berecognized; they are:

a) Logical unit Handler (LUH): Each Logical Unitrepresent a port on the CommunicationSystemthrough which an Application can access theNetwork environment. The LUH is that part of NSMwhich handles and controls all the LUs activity.

b) Logical Network Control Point (LCP) : LCPprovides for the control of the configuration ofthe Logical Network, that is, it knows at anymoment the statusof each Network Station, asfar as the connectivity is concerned (reachableor unreachable). Every change in the NetworkStation is notified to LCP by the PhysicalNetwork Control Point (CNM). Moreover, LCPprovides for the control of the validity of theactive sessions, every time a reductivereconfiguration is signalled. LCP routes thisinformation to the SessionHandler (SH) in orderto trigger the sessionrecovery mechanism.

c) Multiple Session Handler (MSH): The NSMmaintains permanentsessionswith all the otherNSMs in the network. All the sessionsare to bemaintained and controlled, and moreover arecovery has to be provided for the BIUsignalled in exception. These functions areperformed by the MSH.

d) Network ServicesSwitcher (NSS): All the requestfor service are presentedto the NSS which inturn switches the request to the appropriatecomponent of the Services Processor.NSS actsalso as an interface between the ServicesProcessorand the Multiple SessionHandler.

Processor isthe Service

e)

1

2)

3)

4)

5)

- 59 -

Services Processor: The Servicescomposed of as many modules asfunctions are:

The SessionService provides the initiation andtermination of the Sessionsbetween the LUs. ALU may request a sessioneither as a primary LU,via the BIND request, or as a secondaryLU, viathe INVITE request. Both LUs in a Session mayrequest the termination of the Sessionvia anUNBIND request.

The Network Operator Service provides the localoperator with the ability of monitoring theNetwork activity.

MeasurementService provides for measurement ofthe utilisation of the Network resourcesin thedomain of the control of the NSM. Measurementresults are collected for further statisticaland/or accountingpurposes.

Inquiry service provides the possibility toinquire about the structure and the resourcestatus of the Network environment. A LU mayrequest information about the Networkenvironment via an INQUIRE request.

Mailing Service provides a LU with thepossibility to send and to receive messages(letters) to and from another LU in the Network.A LU may use the MAIL request to send a message(letter) or to set up a mailbox in order to beable to receive messages(letters).

4.3.1

The Logical Unit (LU) may be consideredthe port on theCommunicationSystem through which an Application can accessthe Network environment. The activity of the LU is composedof the coded (and formatted) requests for the servicesavailable in the Network environment.

An Internal Address (a binary number in the range fromo to 255) is assignedto each LU for internal addressingpurposes between the Application and its CommunicationSystem, namely the NSM. When a Session is established, aNetwork Address is associatedto the LU together with aLogical Channel Termination (LCT). The LU, through its LCT,becomesdirectly addressablein the Network and its controlpassesto the SessionHandler (SH), which handles every in-

- 60 -

sessionrequest. When the Session is closed, the LCT isreleased,and the LU returns under the direct NSM control.

The maximum number of LUs opened at the same time(theoretically 256) is a local parameter, and it is chargeof the LUH to respect this limit. A LU is assigned to anApplication on direct Application request, and it isreleasedon Application request. No more than one requestata time can be presenton the same LU. The LUH has to controlthe flow of the requestson the single LU, and to enforcethat limit. When a request is completed, a completion codewith the eventually requested data is returned to theApplication. The LUH is now ready to receive the nextrequest. Asynchronousactivity may be possible on a LUthroughout the LU like exception signalling or asyncronousdata (mail) arrival.

The LUH is responsiblefor the execution of the OPENLUand CLOSELU requestsissued by the Application (actually, inthe VM implementation, the OPENLU request is carried on bythe NAC, which will be described in the next section, whilein the OS implementation it is carried on by the NSM, butthis is absolutely transparent to the user, that is theApplication: it dependson the operating system under whichRPCNET is implemented).

Moreover, the LUH has to handle the, in case, abnormalend of an Application signalled by the system (operatingsystem, or anything similar), informing the CNS of theforced closing of the associatedLUs. The CLOSELU request isthe only requestwhich can be ｩ ｳ ｳ ｾ ･ ､ by an Applicationwhichever the LU status shall be (free or busy). On CLOSELUrequest the NSM has to cancel eventually pending operationsor has to close an opened session (at the moment). TheOPENLU request is the only requestwhich does not refer toan existing LU

4 3. 2 ｾＡＺＡｾ ｾｑｧＮＡｾｾｬ ｎ･ｴｾｯＡＢＡＮ ｾｏＡＡｾｊ［ｑｾＮ ｾｧＮＡｮｴ

The Logical Network Control Point (LCP) is the activecontrol point of the Interface Layer as far as the localNetwork activity is concerned

The LCP is in permanentcontact with its Node CommonNetwork Manager (CNM) , in order to be updated on the Networkconnectivity. Every change in the Network connectivity willbe handled by the LCP, checking the local Sessionvalidityand starting tne, in case, recovery mechanism.

When a Network station becomesunreacheable, due to aHost, a Node or a Link failure, all the (local) sessions

- 61 -

opened at a moment with the now unrecheableNetwork stationare forced to close. and all their pending activity iscancelled. The Applications are informed of the failure, theLCTs are released, and the correspondingLUs are reset totheir basic state.

When a possible Node failure (Node unreachability) isrecognized, the Session Handler is alerted, in order tostart the recovery mechanism for the perhaps blockedsessions(see SH Data Flow Control) .

The LCP may be informed by the LUH of System(Application failure), or Application immediate closedownofthe active sessions (LCTs). In this case, the LCP forcesUNBIND request for the sessionand releasesits LCT whilethe correspondingLU will be releasedby the LUH.

4.3.3

The NSM provides permanent sessions with all thereacheable NSMs in the Network. The NSM, as systemaddressableunit, has an unique address, the zero address,in every Address Space (Network station) of the Network.

All the NSM to NSM sessionsare implicitly establishedat the starting time, so there is no need to explicitlyestablish the single session.Every NSM to NSM session isidentified, as every sessiondoes, by the couple of Networkaddressesidentifying the two sessionpartners.

During a session the two NSMs can be consideredconnected through a Logical Channel. This Logical Channelcan be viewed as a full-duplex connectionwith the followingcharacteristics:

a) error-free connection

b) data unit limited in size (the same limit as theCommon Network)

c) data integrity maintained

d) data unit sequentialitynot mantained

e) data unit duplication impossible.

In order to build the previous characteristics usingthe Common Network (see SH Data Flow Control), the NSM hasto use an internal protocol. The Multiple Session Handler(MSH) has to provide the following functions for each activeNSM to NSM connection:

- 62 -

a} recognition and discarding of the duplicatePIOs;

b} recognition and recovery of PIU loss;

and moreover it has to:

c} avoid the buffer congestion;

d} prevent deadlocks.

The protocol used to build thefunctions is described in what follows.

previous stated

Basically the protocol uses the window strategy andacts on the PIU flow (no multisegmentdata unit between NSMsare allowed). Supposing that the PIU sequence number fieldin the TH allows sequencenumber to range from (0) to (n-l),the Sender will not transmit more than (w) PIUs withoutreceiving an acknowledgment, the (w) being the window.ClearlYt (w) must be less than (n), and equal for all theNSMs in the network.

Each data unit exchanged between NSMs cannot bemultisegment, that is, the restriction in size valid in theCommon Network is to be respectedby the NSM to NSM datatraffic. No control on the data unit sequentiality isrequired, becauseeach data unit is independentfrom all theothers, and no data limit numbering is required. The dataunits received and accepted are routed to the NetworkServicesSwitcher, which in turn will provide the switchingto the appropriateService Processormodule. In the protocoldescription the term PIU will be used to indicate the dataunit exchangedbetween NSMs.

The basic rules for the Sender and the Receiver are asfollows:

3ENDER:

a} the Sender transmits only PIUs whose sequencenumbers lies between M and up to M+W-l (where Mis the window left edge, and W is the windowwidth). If the rigth edge of the window isreachedwithout receiving any acknowledgement,the activity is suspended waiting for aReceiver's acknowledge status (briefly" s tatUS") •

- 63 -

.b) On receipt of a "status", consisting of the

Receiver's current window left edge, theSender'swindow left edge is advanced over theacknowledgedPIUs, and the window right edge isadjusted consistently (the window width is afixed number). The acknowledged PIUs may befreed.

c) If a reductive reconfiguration is signalled bythe Common Network, a recovery mechanismisstarted. All the not acknowledged PIUs areresent

d) Every sent PIU carries as first information thenumber of the last received in sequencePIU.This number may be used at the other side tofree all the pending PIUs whose number is lessthan or equal to the acknowledgednumber.

RECEIVER:

a) Every PIU received with a sequencenumber insidethe window and not yet arrived (duplicate) isaccepted.

b) PIUs arriving with a sequencenumber outside thewindow edge are discardedas duplicates.

c) The "status" is sent to the counterpart everyhalf ｷ ｩ ｮ ､ ｯ ｷ ｾ Ｌ that is. when the relative "half

window· table has been completely filled.

d) When the II status" is sent, the window isconsistently updated (the window width is fixedand, of course, equal for all the NSMs in theNetwork) .

e) If a reductive reconfiguration is signalled bythe Common Network Manager, and the window isempty (no PIU with a sequencenumber inside thewindow has been received) the last Ustatus" isresent.

We will describe the complete NSM to NSM protocollater; now, let us consider an aspectof the Common Networkstructure.

As it can be seen in Chapter 3, it can happen that anode fails (hardware or software crash) without notifyingthe partners. In fact, if the node restarts before thetimeout on the lines, the CNM on the opposite side is notnotified of the partner'sfall, so that all continues as

- 64 -

befor e. On t he 0 ther hand I at the "c r ashe d o. side , all thesessionsare closed in error, while the sessionpartnersarenot notified of the fact. It can happen, depending on theApplication protocol, that deadlock situationsarise. If werealize that an Application can be (and normally will be) asystem program, and that a deadlock situation means also aloss of memory (all the tables must be preserved), it isobvious that a special recovery for this situation must bedeveloped. In RPCNET, every NSM PIU brings a number (modulo255) called NSM Restart Number. At the arrival of any PIU,the NSM Restart Number is comparedwith the local one, andif they are not equal, all the LU with that partner areclosed, and the SH is alerted, to shut all the sessions.TheNSM Restart Number is then set according to the receivedone. It must be clear that, in case of fault, the last NSMRestart Number must be saved (as a suggestion,on disk).

Now, we can detail the NSM to NSM protocol.

SENDER

a) When in IDLE state, and a request to send a PIUis received the SENDING state is entered.

b) When in IDLE state, the receipt of a "status"puts the Sender control into the UPDATING WINDOWstate.

c) When in IDLE state, the signalling of areductive reconfiguration puts the Sendercontrol into the RESENDING state.

d) When in SENDING state, a PIU sentacknowledgementfrom the Common Network of a PIUwhose sequence number is inside the windowreturns the Sender control to the IDLE state

e) When in SENDING state, a PIU sentacknowledgementfrom the Common Network of a PIUwhose sequencenumber is the last permitted bythe current window, puts the Sender control intothe WAITING FOR STATUS state.

f) When in WAITING FOR STATUS state, the receipt ofa'statuso. puts the Sender control in theUPDATING WINDOW state.

- 65 -

g) When in UPDATING WINDOW state, the windowupdated condition returns the Sender control tothe IDLE state.

h) When in WAITING FOR STATUS state, the signallingof a reductive reconfigurationputs the Sendercontrol into the RESENDING state.

i) When in IDLE state, the signallingreductive reconfiguration puts thecontrol into the RESENDING state.

of aSender

1) When in RESENDING state, the recovery completecondition puts the Sender control into theWAITING FOR STATUS state, or IDLE state,depending on the control arrival.

RECEIVER:

a) When in IDLE state, the arrival of a PIU putsthe Receiver control into the CHECK SEQUENCENUMBER state.

b) When in IDLE state, the signalling of areductive reconfiguration puts the Receivercontrol into the RESEND PENDING MESSAGE state.

c) When in CHECK SEQUENCE NUMBER state, an out-of-window condition or an already arrived conditionreturns the control to the IDLE state.

d) When in CHECK SEQUENCE NUMBER state, a PIUaccepted condition puts the Receiver controlinto the CHECK WINDOW state.

e) When in CHECK WINDOW state, and the sendingstatus condition has been revealed, the Receivercontrol is put into the SENDING STATUS state.

f) When in CHECK WINDOW state, and the sendingstatus condition has not been reached, theReceiver control is returned to the IDLE state.

g) When in SENDING STATUS state, the status sentcondition together with the window updatedcondition returns the Receiver control to theIDLE state.

- 66 -

h) When in RESEND PENDING MESSAGE state, the windowempty condition returns the Receiver control tothe SENDING STATUS state.

The situation is depicted in theFigure 18 and Figure 19.

4.3.4 The Network ServicesSwitcher

flowcharts of

All the requestsfor service are presentedto the NSS,which in turn forwards the requests to the appropriatecomponentof the Service processor.The requestsmay arriveboth from the Logical unit Handler that is, from the localNSM activity, and from the remote NSMs activity. Eachrequest for service has to be presented appropriatelyformatted, becauseunformatted requestsare not allowed. TheNetwork Servicesare divided in categoriesaccording to thefunctions being performed. The defined categories are (atnow) :

1 SessionServices

2} Mailing Services

3) Inquiry Services

4} Network Operator Services

5} MeasurementServices

4.3.4.1 SessionServices. The Session Service is incharge of-initiating ｡ ｮ ､ ｾ ･ ｲ ｲ ｮ ｩ ｮ ｡ ｴ ｩ ｮ ｧ sessionsbetween LUs. ALU may initiate a sessioneither as a primary LU, via theBIND request, or as a secondaryLU, via the INVITE request.

When the session is established: the LU becomes anetwork addressable unit, being the termination of theestablishedlogical channel (LCT). Both LUs in a sessionmayrequest the termination of the sessionitself via an UNBINDrequest. The LCT is releasedand the LU returns under thedirect NSM (LUH) control. The session is always establishedbetween a primary LU (sessionrequest via a BIND) and asecondaryone (sessionrequestvia an INVITE).

In order to set up the session, there is anmessages between the NSMs (SessionServices),the involved LUs. This exchangeof messageshaswell defined protocol. The basic rules ofServicesProtocol are as follows:

exchangeofcontrolling

to observeathe Session

- 67 -

Figure 18 NSM Sender

a) the INVITE request puts the LU in •• INVITE"state. The LU is identified by the name of theApplication to which it pertains, and it isprotected by a password; a network addressisassigned,and a LeT is arranged.

reductivereconfig.

- 68 -

PIU outof windo

Figure 19 NSM Receiver

b) The BIND requestputs the LU in "BIND REQUESTSTATEd. The requested LU is identified by thelocation (Node and Host) where it resides, andby the name of the Application to which itpertains. Moreover, the BIND request has toprovide the password to ｾ ｣ ｣ ･ ｳ ｳ the ｲ ｾ ｱ ｵ ･ ｳ ｴ ･ ､ LU

- 69 -

and, in case, a message for the Applicationowing the LU (for a further check of theconnectionpossibility).

c) When a LU enters the "BIND REQUESTa st'ate, anetwork addressis assigned A LCT is arranged,and a messageis built for the NSM (SessionService) of the location where the requestedLUis. This "BIND message" has to contain theidentifier of the requesting LU (networkaddress) and owing Application (name), thesymbolic identifier of the requested LU(Appl ication name), the' authorization password,and, in case, a message for the requestedApplication.

d) When receiving a "BIND message", the NSM(SessionServices) has to check if there is a LUin "INVITE" state, with the requestedidentifier. If no one is found, a negativeresponse is prepared and sent back to theoriginating NSM (SessionServices). Otherwise,the authorizationpassword is checked. If theprovided password is incorrect, a negativeresponseis prepared, and sent back to theoriginating NSM (Session Services). If theprovided password is correct, the sessioncan beestablished.A further control has to be made onthe eventual requestof an authorizationmessagefor the Application owing the LU. If thismessageis required, and if it is provided bythe "BIND message", the requestedLU enters intothe "BINDING" state. the INVITE request isclosed and the authorization message isforwarded to the Application If noauthorization message is required, a positiveresponseis prepared, and sent back to theoriginating NSM, and the requestedLU entersinto the "LCT ACTIVE" state.

e) When in ｾ ｂ ｉ ｎ ｄ ｉ ｎ ｇ state, the LU is waiting forthe Application response to the authorizationmessage. If the connection is rejected, anegative response is preparedand sent back tothe originating NSM; the LU returns to the"INVITE" state, or the "IDLE" state, dependingon the Application reject code. If theconnection is accepted, a positive responseisprepared (including the, in case Applicationresponse message), and sent back to theoriginating NSM (SessionServices) and the LUenters into the "LCT ACTIVE" state.

- 70 -

f) When in "BIND REQUEST" state/ the receipt of anegative response causes the releasingof thereserved network address, and LCT, and theclosing in exception of the BIND request. The LUreturns to the "IDLE" state.

g) When in "BIND REQUEST" state, the receipt of apositive response closes successfullythe BINDrequest (passing to the Application the, incase, responsemessage), completes the LCT andputs the LU in the "LCT ACTIVE" state.

h) When in "LCT ACTIVE" state, the LU to LU sessionis established, and the activity will be madeunder the direct SH control.

i) When in "LCT ACTIVE" state, the UNBIND requestcauses the releasing of the LCT, and of thecorresponding network address. An "UNBINDmessage" is prepared to be sent to thecounterpartNSM (SessionService) in order toclear the Logical Channel. The LU returns to the" IDLE state under the direct NSM control.

1) When in "LCT ACTIVE" state, the receipt of an'UNBIND message"causesthe releasing of the LCTand of the corresponding network address, theclearing of the pending activity on the logicalchannel, and the signalling to the Applicationowing the LU of the SessionClose-down. The LUreturns to the \;IDLE" state under the direct NSMcontrol.

When two Applications want to establish a session,first of all they have to agree on the role the singleApplication has to play primary (BIND request) or secondary(INVITE request), in order to avoid contention (bothprimary) or indefinite wait (both secondary). Furthermore,there is the problem of the synchronization, that is, thesecondaryLU has to be set up before the arrival of theprimary LU requestmessage, otherwise the BIND requestwillbe refused for counterpart unavailability. Thesynchronization recovery could be in charge of theApplication that wants to play the primary role, but thereis not a criterium which may help in recovering such asynchronizationlock. The only possibility is to try and totry again until the BIND operation is successfullyclosed.

In order to make the synchronization in opening asession easier for the Application, two options have beenassociatedto the BIND and INVITE operations.

- 71 -

For the INVITE operation, there is the possibility tospecify the BROADCAST option. When the LU enters into the"INVITE" state, if the BROADCAST option is in effect, abroadcast messageis sent to all the NSMs (or to a specificNSM) in the network, carrying the information of the presentavailability of the LU. For the BIND operation, there is thepossibility to specify the WAIT option, that is, in case ofBIND failure due to counterpartunavailability, the LU isput into the "BIND WAITING' state, and where a IIbroadcastmessaged arrives with the indication that the previousrequestedLU is now available, the BIND requestmessage isautomatically resent, and the LU returns to the "BINDREQUEST" state. .

The complete SessionService Protocol can be described,as usual, using the state diagram technique.

a) When in IDLE state, and a BIND request isreceived, the LU is put into the "BIND REQUEST"state, a LCT is reserved, a network addressisassigned, and a IIBIND requestll messageis sentto the NSM where the requestedLU resides.

b) When in IDLE state, and an INVITE request isreceived, the LU is put into the IIINVITE" state,a LCT is reserved, a network address isassigned, and the LU is identified by the ownerApplication name.

c) When in BIND REQUEST state, a negative response(including the counterpartunavailability withthe NOWAIT option) puts the LU into the IDLEstate. The BIND request is closed in exception.

d) When in BIND REQUEST state, a positive responseputs the LU into the "LCT ACTIVE II state. The LCTcontrol passesto the SHe The BIND request isclosed successfully.

e) When in BIND REQUEST state, an unavailabilityresponse (if the BIND option WAIT has beenspecified) puts the LU into the "BINDWAITING IIstate. The BIND request is not closed.

f) When in BIND WAITING state, a broadcastmessagereferred to the previously requestedLU puts theLU back into the "BIND REQUESTII state.

g)

- 72 -

When in "INVI'rE" state,received, the LU isstate.

and a BIND message isput into the "BINDING"

h) When in BINDING state, and the request isinvalid (bad password, no IlBIND message" for theowing Application) a negative response is sentback and the LU returns into the INVITE state.The INVITE operation is not closed.

i) When in BINDING state, and the request is valid,the "BIND message"carried by the BIND requestis forwarded to the Application (if required).The LU remains in the BINDING state, waiting foran Application response, and the INVITEoperation is closed.

1) When in BINDING state, and a reject responsehasarrived from the owning Application a negativeresponseis sent back to the requestingNSM, andthe LU is put into the IDLE state, or into theINVITE state depending on the reject optionchosen by the Application (RESET or CONFIRM,respectively). If the LU returns into the INVITEstate, the INVITE operation is reopened.

m) When in BINDING state, and the request is valid,and no more "BIND message;' is required, the LUis put into the "LCT ACTIVE" state. The LCT iscompleted and activated, and the LCT controlpassesto the SH. The INVITE request is closedsuccessfully. A positive responseis sent backto the requestingNSM.

n) When in BINDING state and an Accept responsehasarrived from the owing Application, a positiveresponseis sent back to the requestingNSM, theLU is put into the "LCT ACTIVE" state. The LCTis completed and activated, and the controlpassesto the SH.

This state diagram is depicted in the flowchart ofFigure 2lL

ｾ Ｎ ｬ Ｎ Ａ Ｎ ｦ ｾ ｡ ｩ ｬ Ａ ｾ ｓ ｾ ｲ ｾ ｬ ｾ ｾ Ｎ The Mailing Service provides aLU with the possibility to send and to receive messages(letters) to and from another LU in the Network.

The Mailing Service is accessedvia the MAIL request. ALU may use the MAIL request to send a message (letter), orto set up a mail box, in order to be able to receive a(some) message(s).Every mail box is identified by the name

re.iectconfi

orinvalreque

- 73 -

Invite req.

validrequest

negative resp.no WAIT opt.

resp.opt.

Figure 20 SessionService Protocol

of the Application owing the related LU, and by a furtheridentifier (optional). No more than one mail box may beassociated to a particular LU. A mail box remains activeuntil a mail message arrives, closing themail receiveoperation.

- 74 -

When used to send a message, the MAIL request has tobesides the message text, provide the full addressidentifier (location, Node and Host, and the mail boxidentifier, short or extended). The delivery of the messagemay be guaranteedor not, depending on the MAIL requestoptions The message delivery is guaranteedwhen the MAILrequest is considered closed only when the messageacknowledge (positive or negative) is received back. Themessagedelivery is not guaranteedwhen the Mail request isconsidered closed as soon as the message leaves theoriginator Node and no acknowledge is expected. For what wesaid, it is clear that a MAIL Service protocol (a verysimple protocol) had to be designed. The basic rules of thisprotocol are in what follows.

Through a LU, two kinds of requestsmay be presentedtothe Mailing Service: the Mail-Send request and the Mail-Receive request. Between the Mailing Services, two kinds ofinformation may be exchanged: a mail messageor a mailacknowledgement.

a) When a mail messageand no mail box with therequired address is present, a negativeacknowledgementis sent back or the message issimply ignored, depending on the mail messageoption (guaranteedor not). In both cases, themail messageis discarded.

b) When a mail message arrives and the requiredmail box is found, the mail receive operation isclosed, and a positive acknowledgementis sentback, if required (mail messageguaranteed).

c) When the Mailing Service is unable to forwardthe message, because the destination isunreachable or invalid, a negative responsecloses the mail-send request.

d) When a mail messageleaves the originator node,and no guarantee has been required, the mailsend request is closed positively

e)

4 3LU withstatus ofaccessed

When a mail acknowledgement arrives, the mailsend request (if guaranteed) is closednegatively or positively, depending on theacknowledgementcode.

ｾ Ｂ ｾ Ｎ Ａ Ｎ Ａ Ａ ｓ ｉ ｾ Ａ ｾ ｹ ｓ ･ ｲ Ｎ ｶ ｩ Ｎ ｣ ｾ The Inquiry Service provides athe ability to inquire about the structure and thethe network environment. The Inquiry Service isvia the INQUIRE request. A LU may use the INQUIRE

a)

- 75 -

request to inquire about:

the status (reachable or unreachable) of thespecified Host and, if reachable,the number ofintermediateNodes on the presently shortestｰ ｡ ｴ ｨ ｾ

b) the status (reachable,unreachable,available ornot available) of a specified Application. Ifreachable, the number of the intermediateNodeson the presently shortestpath. If available,the total number of opened ports (LUs) of theApplication, its total number of LUs in INVITEstate and in session (LCTs).

c) the status (reachable or unreachable) of thespecified Host. If reachable, the number ofintermediateNodes on the presently shortestpath, the total number of opened ports (LUs),the number of LUs under NSM control, the totalnumber of sessions, the number of sessionsbetween the requiring Host and the addressedHost, the presently exchange rate (number ofbytes sent and received per second).

The Inquiry Service is not implementedat the presentstate of RPCNET, but the software is full-compatible withsuch a service, in all the RPCNET implementations.

Ａ Ｎ ｾ !.! ｾ ｾ ｾ ｷ ｾ ｲ ｾ ｏ ｰ ･ ﾣ ｡ ｾ ｾ ｾ ｾ ｾ ｾ ｾ ｩ ｣ ･ Ｎ The Network OperatorService provides the local operator with the ability tomonitor the Network activity. The way in which such aservice can be implementeddependsmainly on the OperatingSystem" under which the RPCNET software has to beimplemented, so that we can only suggesta set of commandswhich should be made available for the Network Operator:

Start of Node Network activity

Shut down of Node Network activity

Activation or de-activationof Network lines

Inquiry about Network link(s) status

Inquiry about LUs status

Inquiry about Sessionstatus

- 76 -

Inquiry about Network topology status

Forcing a Sessionclose down

Forcing a LU release

Sending of messagesto other Network operators

77 -

4.4 The Network Access Controller

The Network Access Controller is the most externalsub-layer of the Communication software, so that its designdependsmainly on the Operating System in which it has torun.

The Network Access Controller (which is also calledCall and Return Interface) performs a first set of controlson the user issued operation, before passing it down to theNSM, or to the SH· dependingon the operation code.

The NAC can be called by Netusersvia a branch-and-linkinstruction, or a Supervisor Call instruction dependingonthe Operating System For example, in the VM implementation,the NAC call is performed by a set of routines which arecalled by the Netuser via a branch-and- link instruction,while in the OS implementation, a new SVC code has beenadded to the system, to perform the NAC call

The NAC call is, usually, the last istruction of anyRNAM macro, as it will be mentioned later.

- 78 -

5 THE APPLICATION LAYER

5.1 Introduction

The Application Layer is the most external layer of theRPCNETi it communicates with the other layers by using anaccessmethod, called RNAM (Reel Network Access Method)which consists on a set of macros, and/or a set of high-level language subroutines.We will speak about RNAM later,now, let us say something about Applications, in general.

An Application is a program, or a set of programs,splitted in two parts, which reside on different computers,and communicateeach other using RNAM. An Application can bea user-written program or an already existing systemprogram, which has to be modified in order to introduce theNetwork concepts. For example, a system »spool" handler canbe modified in order to take into account the possibility tosend ｾ ｳ ｰ ｯ ｯ ｬ Ｂ files not only to the local output devices, butalso to different remote computer devices. A typical user-written Application could be simply a program which needsdata residing on another computer: if there is anotherprogram, and a protocol of communicationwas established,the two programs can communicateeach other.

As it is impossible to see that a computer networkexists. without providing any facility, such as a spool filetransfer, or something like this, it is obvious that someApplications should be developed by the systemistswhodevelop the Network software, so that two aims can beachieved:

a) testing of the Network software (the best way totest a software is to make it working)

b) providing a first kind of "service", whichallows users to enter the Network philosophy,and stimulates the study and the developing ofother Applications.

- 79 -

5.2 RNAM

RNAM, the Reel Network Access Method, is a functionalunit that enables an Application program to establishanduse ports (LUs) on the Communication System (CommunicationLayer, plus Interface Functions Layer).

The services provided by RNAM are:

a) macro function services;

b) data flow control services;

c) Logical unit handling services.

The macro function services are all the servicesnecessary to analize and execute the Application programrequestsmade via a one of the supportedmacro intructions.

The data flow control servicesare provided by the dataflow control protocol support (SH). This protocol is used tohandle data structuresas a chain, or to manipulate thestate conditions such as "send" or "receive" state of theassociateLogical unit.

The Logical Unit handling servicesconsist in:

a) Logical Unit set-up and release

b) Logical unit BIU traffic handling

c) Logical Unit exception condition handling.

5.2.1 Characteristicsof RNAM-_._- -- -----,- - - - .- --

The RNAM characteristicsare:

a) application program basic interface

b) synchronoushandling of the requests

c) asynchronoushandling of the requests

d) application program macro instructions

e) operation and asynchronousactivity handling

- se -

f) data flow control

ｾ Ｎ ｾ Ｎ Ａ Ｎ Ａ ｾ ｅ ｐ Ｑ Ａ ｾ ｡ ｾ ｩ ｯ ｮ ｅ ｾ ｑ Ｙ ｾ ｡ ｾ ｢ ｡ ｾ ｩ ｾ ｩ ｮ ｾ ･ ｲ ｦ ｡ ｣ ｾ Ｎ The RNAMinterface versus the Application programs is a BAL (BasicAssemble Language) type interface. The program access RNAMeither via a Branch and Link instruction or a SupervisorCall, depending on the implementationand/or the OperatingSystem.

All the requestsare made using a request code and aparameter list, that specifies the characteristicsof therequest itself. An Application program using RNAM can bedescribed as a "single-thread" program, that is a programcapableof handling only one port (LU) at a time, or as a"multi-thread" one, that is, capable of processingtherequestsof many LUs concurrently. So that, in general, aＢｳｩｮｧｬ･Ｍｴｨｲ･｡､ｾ program requestssynchronousoperationsandwaits until each synchronousoperation is completed, while a"multi-thread" program requestsasynchronousoperations,andcontinuesprocessingon behalf of other LUs while waitingfor an operation in a particular LU to be completed.

ｾ Ｎ ｾ Ｎ ｬ Ｌ ｾ ｓ ｹ ｮ ｣ ｨ ｲ ｯ ｮ ｾ ｵ ｳ handling ｾ ｾ the ｲ ･ Ｙ ｾ ･ ｳ ｴ ｳ Ｎ In asynchronous program, the operations are performed in aserial pattern. A request for a single operation (forexample a SEND or a RECEIVE) means that RNAM returns controlto the next sequential instruction in the program only afterthe requested operation is completed. This means that theexecution of the Application program is halted until RNAMdetermines that the operation has been completed. Asynchronousoperation is depicted in Figure 21.

5.2.1 3 ｾｾｹｮ｣ｾｾｯｮｾｾｾ ｨｾｰ､ｬＡｮｧ ｾＡ ＡｾｧｵｾｳｴｳＮ In anasynchronous operation, RNAM returns control to the nextsequential instruction as soon as RNAM has accepted therequest, not when the requested operation has beencompleted. Accepting a request consists on screening therequest for logical errors, and scheduling the requestedoperation. While the operation is being completed, theApplication program is free to initiate other LUprocessings.

When an asynchronousoperation is specified, there aretwo ways in which RNAM can notify the Application programthat the operation has been completed. If the Applicationprogram associates an Event Control Block (ECB). with therequest, RNAM posts the ECB when the operation has beencompleted.

Alternatively the Application program can associateanexit-routine with the request. When the operation iscompleted. RNAM schedulesthe routine. In Figure 22 and

- 81 -

RNAM

1- - - - - - - -. - - - - - - - -II

ApplicationII

SEND--------.--------------1

,requestJacceptedIJIIISEND completed,_____oJ

Figure 21 Synchronousrequestshandling

Application RNAM,I

SEI'ID..... _----- - -+---- - - ---- -- --, request: accepted

,- - - - - - - - - -.- - - - - - - - - - - - - - - - - ....,. I .

J.nte.I£1ryiJ..2£- - - - - ... - - - - - - - - - - - - - - -,SEND completed

'ECB postedI

ｲＭＭＭＭＭＭＭＭＭＭｾＭＭＭＭＭＭＭＭＭＭＭＭＭＭＭＭＭII

check ECB or WAIT

Figure 22 Asynchronous request with ECB

Figure 23 it is possible to see examples of asynchronousprocessing in an Application program using ECB or an exitroutine.

ｾ Ｎ ｾ Ｎ ｬ Ｎ Ａ ｾ Ｎ ｅ Ｎ ｅ Ａ ａ ﾣ ｾ ｴ ｩ ｯ Ａ Ａ ｉ ＿ Ａ Ｚ Ｎ ｑ Ｎ ｧ ｾ ｡ ｾ ｾ ｡ ｣ Ａ Ｚ Ｎ ｾ instructions. RNAMprovides the Application program ｷ ｩ ｴ ｨ Ｍ Ｍ ｡ Ｍ Ｍ Ｍ ｳ ･ ｾ of macroinstructions to perform all the allowed Network activitiesBasically, the macro instructions can be divided in fiveclasses,as follows:

Application

- 82 -RNAM

EXITROUTINE

SENIl_ - - - - - - - - ..- - - - - - - - - - - - - - -1 r eques t

I acceptedｲ Ｍ Ｍ Ｍ Ｍ Ｍ Ｍ Ｍ Ｍ Ｍ ﾷ Ｍ Ｍ Ｍ Ｍ Ｍ Ｍ Ｍ Ｍ Ｍ Ｍ Ｍ Ｍ Ｍ Ｍ ｾII

i n t e:torｾｬＲＮＮｴ i ＨｾＮＮｮ • _I SEND completedI Exit Routine

f---- JScheduled

Figure 23

---- - - .,-'Icontrol

r- - - - - - - - - - -. - - - - - - - - - - _L r eturne d

IJ

Asynchronous requestwith Exit-routine

a) macros to set-up and releaseLUsOPENLU The OPENLU macro instruction acquiresport(s) on the CommunicationSystem.CLOSELU The CLOSELU macro instruction releasesthe LUs acquired

b) connectionmacrosBIND The BIND macro instruction is a requestfor connecting the referred LU to a LU of thespecified Application (in the Networkenvironment), in order to establisha session.INVITE The INVITE macro instruction is used toplace the corresponding LU in INVITE state,waiting for the connectionwith another LU thatwants to establisha sessionissuing the BINDmacro instruction.UNBIND The UNBIND macro instruction is arequest to break-up the connectionbetween thereferred LU and its counterpart in theestablishedsession.

c) I/O macrosSEND The SEND macro instruction is a request totransfer data from the requestingLU to itscounterpart in the establishedsession.RECEIVE The RECEIVE macro instruction is arequest to transfer into the Applicationprogram area data coming, on the referred LU,from the counterpartLU during the sessionBREAK The BREAK macro instruction enables theApplication program to break-up the send-

- 83 -

receive data flow, allowingsend asynchronous data tothe session, whatever itsreceiver) may be.

the Application toits counterpartinrole (sender or

d) support macrosTESTLC The TESTLC macro instruction enables theApplication program to test and to getinformation on the logical path from thereferred LU to its counterpart LU in theestablishedsession.CANCEL The CANCEL macro instruction enablestheApplication program to cancel (under certainconditions) the operation pending on thereferred LU.

e) Network ServicesmacrosINQUIRE The INQUIRE macro instruction enablesthe Application program to inquiry about theNetwork environment, using the servicesofferedby the CommunicationSystem.MAIL The MAIL macro instruction enables theApplication program to send messagesto anotherNetuser, using the mailing servicesoffered bythe CommunicationSystem.

ｾ Ｎ ｾ Ｎ Ａ Ｎ ｾ ｑ ｅ ･ ｲ ｡ ｴ Ａ ｾ ｮ and ｾ ｾ ｾ ｣ ｨ ｲ ｯ ｮ ｯ ｵ ｳ ｾ ｣ ｴ ｩ ｶ ｩ ｴ ｩ ･ ｳ ｾ ｾ ｾ ｾ Ａ ｩ ｾ ｧ ＮAs far as RNAM is concerned, every operationmight beconsideredcompleted as soon as it has been scheduled forthe execution on the CommunicationSystem. Although due tothe particular nature of the utilized system (a ComputerNetwork), some of the operation must be consideredcompletedonly when a feed-back information is provided to RNAM by oneor more of the Communication System components

A distinction can be made between immediate and non-immediate operations like in a standard I/O system. Inparallel with a standard I/O system, RNAM may considercompleted either the operation (for immediate operationrequest), or its role (for non-immediateoperation request),as soon as it receives a positive condition code on itsoperation execution request (the SIO instruction for the I/Osystem). At this point, the operationcontrol passesto theCommunicationSystem component (Channel, Control Unit andDevice for the I/O system).

One or more of these components will subsequentlyprovide the ending statusof the operation to the requestingmodule (RNAM). Depending upon the type of the request, theending condition might be an unique collection ofintermediateending status (Channel end, Control Unit endand Device end for the I/O system), or can appear as

- 84 -

subsequentand separateending states (for instance, firstChannel end then Control Unit end, and finally Device endfor the I/O system).

In the following Figure 24 a scheme of the handling ofthe single operations, as far as the ending conditions isconcerned, is presented.The only immediate operations arerelated to the MAIL and UNBIND macros. In the figure onlynormal completion is considered.

Besides the standard operation activity, anasynchronousactivity versus the Application program must beconsidered in RNAM. The asynchronousactivity is introducedin RNAM, through the LUs, by the CommunicationSystem, andcan be divided in four classes:

a) Exception messages:not directly required by theApplication program, the exception messagerepresentsthe new logical statusof a LU, or aLU to LU logical path, when modified by anexception condition.

themacrocase,

b) Exception responses: directly required byApplication program when it uses the SENDinstruction and wants to have only the, innegative feed-back of the operation.

c) Break data: not directly required by theApplication program, break data representaninformation, coming from the connectedApplication during a session,that breaks-upthepresentsender-receiverdata flow.

d) Mail: becauseof the mailing service offered bythe CommunicationSystem, it is possibleat anytime to receive mail messagesfrom other Networkusers. This activity is not directly required bythe Application program, and can be suspendedondirect Application program request.

5.2.1.6 Data flow control. The data flow controlservice- ｯ ｦ ｦ ･ ｲ ･ ､ ｾ ｹ RNAM is limited to the implementationofa data flow control protocol based on the service offered bythe Communication System to each LU. This protocol is usedto handle such data structuresas "chains", or to manipulatestate conditions such as "send" or ｾ ｲ ･ ｣ ･ ｩ ｶ ･ Ｂ stateof theassociatedLUs during a session.

The data flow control protocol does not perform anytransformation function on the "end user" request, butassists"end users" in controlling the flow of the requests.

- 85 -

---

-data-

----

---.--------

Ｍ Ｍ Ｍ ｴ ｾ ... -_.- - - _

-+- ---

- - -b nd--resp nse--

CommunicationSystem

LU Interf. Common Interf. LU RNAM pplicat.

- -- .II

RNAM

- ＭＺ｡ＺＭｾｾ- - -_ L_

Applic.

INVITE

UNBIND -- - - --,op. com 1..

BREAK

SEND i(no res.op. Ior exc. sched. L

ope:-Com 31.

MAIL

SEND(resp.)

Figure 24 RNAM handling of the operations

building andand parameterchecking and

be provided byand might be

- 86 -

Normally, every access method for data transferhandling provides not only a set of basic macros as RNAMdoes, but also a set of support macros for building andhandling of control blocks and parameter list.

This set of macros could be operating system dependentat least at the implementation if not at the formal level.An improved accessmethod based on RNAM is presentedin thissection, in which only a few macros have been added in orderto achieve, at least at the formal level, an operatingsystem independence. The fact that an Access Method had tobe implemented on different operating systemswas taken inconsideration.

Beside this, a different implementationmigth requiresome new macros beside the basic set presentedin thissection, or a different use of the describedmacros. In anycase, the following description must be consideredonly asuggestionon how to implement an RNAM basedAccess Method.

5 3.1 General characteristicsof the Access Method

All the RNAM characteristicshave to be maintained inthe Access Method moreover the macro function servicesofthe Access Method have to be improved.

The new servicescomprise an authomatichandling of all the necessarycontrol blockslists, as well as on user oriented operationerror handling. All these functions have tothe Access Method via macro instructionstailored to the particular operating system.

5.3.2 Macro instruction structure

In the following paragrapha formal structure of theAccess Method supportedmacro instruction is given.

All the macro instructions are divided in six classes:

a) Declarative macrosRPL RequestParameterListLueB Logical unit Control BlockEXLST Exit-routines List

- 87 -

b) Manipulative macrosGENCB Generatea Control BlockMODCB Modify a Control Block

c) LUCB based macrosOPENLU Open Logical UnitCLOSELU Close Logical Unit

d) RPL based macros

Connection macrosBINDINVITEUNBIND

Data transfer macrosSENDRECEIVEBREAK

e) Macros that support connectionor I/OCHECKCANCELEXECRPLTESTLC

f) Macros for the Network environmentINQUIREMAIL

- 88 -

5.3.3 Macro Instructions

Each macro instruction description contains a threecolumn table that shows how the macro intruction has to becoded. Since macro instructions are coded in the same formatas assembleintructions, the three columns correspondto anassembler intruction label, operating code and operandfields. All the operands are keyworded or positionaloperands,depending on the particular implementation.

Keyword operandsconsist in a first character string(the operand keyword), an equal sign, and a single ormultiple operand value. Keyword operandsdo not have to becoded in the order shown in the operand column, and must beseparatedby commas. If more than one value can be codedafter a keyword, the parenthesesare required.

A notation scheme is illustrated in theshow how, when and where operands cannotational symbols are never coded.

following,be coded.

toThe

an exclamationpoint (1) means "exclusive or"

vertical arrows C') are used toalternative operand values One ofalternative values enclosed within themust be chosen.

groupthe

arrows

a value enclosed between two plus signs (+)means that if no value is selectedfor thatoperand, that value is assumedas default value.

percentages(%) denote optionals operands.

an ellipsis ( ... ) indicates that whateverprecedes it (either an operandvalue, or anentire operand) can be repeated any number oftimes.

parentheses, equal signs and uppercasecharactersmust be coded exactly as shown in theoperands column. Lowercase words representvalues that the user must supply.

- 89 -

LUCB ｾｯｧｩ｣ｾｬ ｕｮｾｴ ｦｾｮｴｾｯｬ ｾＡｑ｣ｾ

The LUCB identifies the Logical Unit to be obtainedfrom the communication system. Every Application port musthave a LUCB; an Application may have more than one LUCB. ALUCB macro instruction causesa LUCB to be built during theprogram assembly. The LUCB can also be built during programexecution using the GENCB macro instruction, and can bemodified during program execution by means of the MODCBmacro instruction, see Figure 25.

ｲ Ｍ ［ Ｚ Ｚ Ｍ Ｍ ｲ ［ Ｚ ｾ Ｚ ｴ ［ ｯ Ｍ ｾ Ｍ ｉ Ｍ ｯ ｾ ･ ｲ ｡ ｮ ､ ｾ Ｍ Ｂ Ｍ1_ ..__. ... /. .. . ..._.._. . ._._. __ Ｎ ｾ Ｎ _

! label I LUCB %,BREAKLN= break area length%,DATALEN= max data transfer%A,ECB= event contr. block addr.

A,EXIT= Exit routine address%,EXTLST= Exit routine list addr.

Figure 25 LUCB macro instruction

the area (inthe incoming

BREAK macrosession.Theis 128. Iffield is setbe accepted.

BREAKLEN = break area lengthIndicates the length (in bytes) ofLUCB) destinated to accomodateasynchronous data generated by aissued by the counterpartduring amaximum number which can be specifiedthis operand is omitted, the BREAKLENto 0, and no incoming break data will

DATALEN = max record length for data transferIndicates the maximum length (in bytes) that willbe specified for data transfer requestsrelated tothis LU (during a session).

ECB = event control block addressIndicates the location of an event control blockto be posted by RNAM when a not requestedasynchronous activity (break data coming orexception responsearrived) has to be signalled onthe Logical unit related to this LUCB. The ECB canbe any word of addressablestorage. The ECB fieldand the EXIT field share the same LUCB field. TheECB-EXIT field is used in this manner:

- 90 -

If ECB = addresshas been specified, RNAM usesthe field as the addressof an external ECB.

If EXIT = addresshas been specified,this field as the address of theroutine and schedulesthe routine asbelow (under EXIT operand).

RNAM usesLUCB Exit-indicated

If neither ECB = address,nor EXIT = addresshasbeen specified, RNAM uses this field as aninternal ECB. RNAM does not clear the ECB. Usersof ECB must be sure to clear the ECB once theECB itself has been posted.

EXIT = LUCB Exit-routine addressIndicates the addressof a routine to be scheduledwhen an asynchronousactivity has been required onthis LU When the routine receives control, somegeneral purpose registers will contain thefollowing:

Reg X: the addressof the LUCB associatedwiththe LU whose asynchronousactivity has causedthe LUCB Exit-routine to be entered;

Reg Y : the address in RNAM program to which theLUCB Exit-routine must branch when it hasfinished (return address);

Reg z: the addressof the LUCB Exit routineitself. No register save area is provided uponinvocation of the LUCB Exit-routine.

EXTLST = exit routine list addressIndicates the addressof a list of Exit-routinesto be entered when particular events arerecognized on the LU by RNAM.

All the LUCB fields above are fields set by theApplication program. The fields describedbelow are set byRNAM, and can be tested by the Application program.

CONTROL After an asynchronousinformation has beenreceived, CONTROL is set to one of the followingvalues:

BRKREC Break data received. See BRKAREA andASYLEN fields.LUSTAT Logical unit status indicator received,check LUSENSEI.EXCRESP Exception response received. SeeRESPNUM field for the number of requestwhich

- 91 -

this responseis referred to; and the LUSENSEIfield for further information.

ASYLEN The ASYLEN field is set by RNAM when anasynchronous input operation is finished, toindicate the length of the data just received.

RESPNUM The RESPNUM field is set by RNAM when anasynchronous response (exception response ornetwork inquiry response) is received. Thisfield contains the sequence number of therequest the responseis referred to.

LUSENSEI Whenstatus) orthe LUSENSEIsystem error

an exception message (Logical unitan exception responseis received,field indicates the presence of acode.

LUSENSEM The LUSENSEM field contains the systemindicator modifier bits.

BRKAREA This field, whose length (in bytes) isspecified in the BREAKLN field, will contain theincoming break data address.

- 92 -

RPL Request ｐ ｾ ｲ ｡ ｭ ･ ｴ ･ ｲ List ｦ ｯ ｾ ｾ Logical ｾ ｮ ｩ ｾ

Every request that an Application program makes forconnection, data transfer or Network servicesoperations,must refer to an RPL. A Request ParameterList (RPL) is acontrol block used by the Application program to describethe request it makes to RNAM, and it is related to aparticular Logical Unit by the LUCB field. The RPL macroinstruction builds an RPL during assembly. An RPL can begeneratedalso during program execution with the GENCB macroinstruction Request for RPL modification can be made aspart of a requestmacro, or by the MODCB macro instruction,see Figure 26.

-----,...----_._---------------OperandsOperationIｎ｡ｭｾ

..._-------_..- .,_._. . .._.._- ---.-- "'---'" .._--_..._-----label RPL LUCB= LUCB address

%,AREA= data area address%,AREALEN= data area lengthＥ ｾ ｒ ｅ ｃ ｌ ｅ ｎ ］ data length$,OPTION= +SYN+!ASY%A,ECB= event contr. block addr.

A,EXIT= Exit routine address%,CHNGDIR= YES!+NO+

%,REQRESP= !EXC!DEF!+NO+%,DESTID= destinationidentifier%,APPLID= application identifier%,PASSW= authorizationkeyword

Figure 26 RPL macro instruction

LUCB = LUCB address.Associatesthe request that willuse this RPL to a LUCB

AREA = data area address. When used by a SEND orRECEIVE macro instruction, AREA indicates the addressof anarea in program storage from which data is to be written orinto which data is to be read. When used by an INVITE macroinstruction, with option BINDMSG = YES, AREA indicates theaddress of an area where the data obtained by the LU whichwants to connect the Application, is to be placed. When thisoperand is omitted, AREA field is set to ｾ Ｎ

AREALEN = Data Area Length (only for RECEIVE) .Indicates the length (in bytes) of the data area identifiedby the AREA operand. The AREALEN operand is meaningful onlyfor input operations. For the RECEIVE macro instruction,AREALEN = ｾ means that no input data area is available. If

- 93 -

omitted, AREALEN is set to 0. RECLEN = Data Length (only forSEND). When used by a SEND or BREAK operation, RECLENindicates the length (in bytes) of the data to betransferred. For RECEIVE operation, the RECLEN operand hasno meaning, but this field is set by RNAM when the inputoperation is completed, to indicate the length of datareceived. When a RECEIVE operation is completed and excessdata is detected, RECLEN contains the total length of theoriginally available data. If omitted, this field is set too•

OPTION = Option Code. Indicates options that are toaffect the requestmade using this RPL.

SYN!ASY Indicates whether RNAMsynchronously or asynchronouslyrequestmade using this RPL.

shouldhandle any

SYN Synchronoushandling means that, when a requestis made, control is not returned to theApplication program until the requestedoperation has been completed (successfullyorotherwise). The Application program should notuse the CHECK macro instruction for synchronousrequests; RNAM automatically performs thischecking (which includes clearing the ECB). Whencontrol is returned to the Application program,a general purpose register will contain thecompletion code.

ASY Asynchronous handling means that after RNAMschedules the requestedoperation, control isimmediately passed back to the Applicationprogram. When the event has been completed, RNAMmakes one of the following actions:

If the ECB addressis specified for the RPL,RNAM posts a completion indicator in the eventcontrol block indicated by this operand. Ifneither an ECB nor an EXIT addressis specifiedin the RPL, the ECB field itself is used as anevent control block. The Application programshould issue a CHECK (or a system WAIT) macro todetermine whether the ECB has been posted.

If the EXIT operand is in effect, RNAM schedulesthe Exit-routine indicated by this operand.

- 94 -

Note: After an asynchronous request has beenaccepted, and before that request has beencompleted, the RPL being used by the requestmust not to be modified. A modification duringthis interval could cause RNAM to be unable tocomplete the request in a normal manner, whichin turn would cause RNAM to terminate theApplication program.

ECB = event control block address Indicates thelocation of an event control block to be posted by RNAM whenthe request associatedwith this RPL is completed The ECBfield and the EXIT field share the same RPL field. Ifasynchronoushandling of the request has been specified (ASYoption in the RPL) the same happensas it did for the ECBparameter in LUCB. If synchronoushandling (SYN option inthe RPL) has been specified, the ECB-EXIT field is used asfollows:

If ECB = addresshas been specified, RNAM usesthat field as an the addressof an external ECB.

If EXIT = addresshas been specified, RNAM usesthe field as an internal ECB, thus destroyingthe Exit routine address.

If neither ECB = addres, nor EXIT = addresshasbeen specified, RNAM uses this field as aninternal ECB.

RNAM clears internal ECBs when it begins processinganyRPL-based macro, and when the RPL is checked. RNAM clearsexternal ECBs only when the RPL is checked. RPL checking ismade by RNAM at requestcompletion for synchronoushandling,and it is made by the user issueing CHECK for asynchronousrequest handling). Users of external ECBs must therefore besure that the external ECB is cleared before the next RPL-based macro is issued.

EXIT = RPL Exit Routine Address. Indicates the addressof a routine to be scheduledwhen the request representedbythis RPL is completed. If the SYN option has been specified,the Exit-routine is not used; if specified, the addressisoverwritten before the synchronousrequest completes (RNAMuses this field as an internal ECB in this situation). TheRPL Exit-routine is scheduledonly if asynchronous handlingof the request has been specified. When the routine receivescontrol, three general purpose registers contain thefollowing:

to which thisit is through

- 95 -

Rx the address of the RPL associated with therequest whose completion has caused the RPL Exitroutine to be entered.

Ry the address (in RNAM program)routine must branch whenprocessing (return address).

Rz the addressof the RPL Exit-routine itself.

REQRESP = (EXC1DEF1+NO+) When a SEND macro is issued,the REQRESP field designatesthe type of responsedesiredfor this request.

EXC Only exception responseexpected. Only in caseof a Network error a responsewill be sent tothis request.

DEF Definite response expected. A response isexpected in any case to complete the request.

NO Neither positive nor negativeexpected for this request.

response is

CHNGDIR = (YES1+NO+). When a SEND macro is issued, theCHNGDIR field designatesif the Change Direction Indicatoris to be set on (YES) or off (NO).

YES the Change Direction Indicator is set to signalthe port that the transmitting LU ceasestransmitting on its own initiative, and preparesto receive.

NO no change in the actual role of the transmittingLU.

DESTID = Destination Identifier. This field is used bythe BIND macro instruction to indicate the Network locationwhere the Application to be bound is. The DESTID operandcontains either the address of the identifier, or theidentifier itself. The DESTID field contains directly theidentifier.

APPLID = Application Identifier. This field is used bythe BIND macro instruction to indicate the identifier of theApplication to be bound. The APPLID operand contains eitherthe addressof the identifier, or the identifier itself TheAPPLID field contains directly the identifier.

PASSW = Authorization Keyword. This field is used bythe BIND macro instruction to indicate the keyword necessaryto access the requested Application. The PASSW operand

- 96 -

thethe

directlydirectly

contains either the addressof the keyword orkeyword itself. The PASSW field containskeyword.

All the RPL fields describedabove are fields set bythe Application program. The fields describedbelow are setby RNAM at the completion of the request.

RTNCD A general return code returned by all of theRPL based macro instructions

FDBK (Feedback): Specific error return code returned byall the RPL based nacros that are acceptedby RNAM but arenot completed successfully.

REQ: A value returned by all of RPL based macros,except EXECRPL and CHECK, that identifies the type of macroinstruction.

CHAIN: When a RECEIVE macro has been completed, theCHAIN field indicates the message'srelative position in theChain. The possible settingsare: FIRST, MIDDLE, LAST orONLY.

RESPONSE: Thewhen a SEND orexception responserequired).

RESPONSE field indicates further detailsBREAK operation has been ended with an(SEND operation with Definite Response

GENCS Generatea control block

The GENCS macro instruction builds a LUCS or an RPL.The advantage of using the GENCS macro is that the controlblocks are generatedduring the program execution. GENCB notonly builds the control block during program execution, butcan also build the control block in dynamically allocatedstorage.

The GENCS user specifies the type of control block tobe built, and the contentsof its fields. The operandsusedto specify the field contentsare exactly the same as thoseused in the macro instruction that builds the control block,see Figure 27.

r--" --_._..,.,-- A f--·--······_-_···_--

I Name IOperation Operands! _-- "- -._-' _ '--"'.' _.- -..__.__.._._.._---_.. ..-----

label GENCB BLK= r-RPLILUCBf,'ＥＬｋｅｙｾｏｒｄ］ value%...%,COPIES= auantity%,WAREA= work area address%,LENGTH= work area length

Figure 27 GENCS macro instruction

SLK= RPLILUCB: indicates the type of control block tobe generated.

KEYWORD= Value: indicates a control block fieldvalue that is to be contained or representedwithin.keywordO. can be coded any keyword that can be used

macro instruction correspondingto the SLK operand.

COPIES= Quantity: indicates the number ofblocks to be generated.The copies are identical incontents; they are placed contigously in storage.operand is omitted, one control block is built.

and theit. Forin the

controlform andIf this

WAREA= Work Area Addres: indicates the location of thestorage area in the Application program where the controlblock is to be built. If this operand is specified, theLENGTH operand must be specified too. If the WAREA andLENGTH operandsare omitted, storagearea can be dynamicallyobtained (it depends on the operating system) via somesystem facility, and the control block is built.

- 98 -

LENGTH= Work Area Length: indicates the length (inbytes) of the storagearea designatedby the WAREA operand.

ALVCB= LUCB addressARPL= RPL address%,Field name= new value%,..•

- ｾＹ -

MODCB modifies the contentsof one or more fields in acontrol block. MODCB works with control blocks createdeither by declarativemacros, or by the GENCB macro. Theuser of the MODCB macro instruction indicates the locationof a LUCB or RPL, the fields within that control block to bemodified and the new values that are to be placed orrepresentedin these fields. Any field whose content can beset by the LUCB or RPL macro instructions, can be modifiedby the MODCB macro. The operandsused to do this are thesame as those used when the ｣ ｯ ｾ ｴ ｲ ｯ ｬ block_is created, seeFigure 28. .r--- ..·····_·_···_·__··_·_·_··· Ｍ＾ＭＭｊＮＭＭＭＭｾＮＭ｟ ....--...-,..------.""-"""I ｎ｡ｾ･ IOperation Operands1, ...-.- . 1_ ··---·-·-··--·-----1-........ -_._. _ ..'-.'...-"- ..- ...--.---- _.', . Ｍｾ ＭＭＭＭｾＮＭＬＮ｟ＮＭ

. II label I r.1ODCB

I I

Figure 28 MODCB macro instruction

LUCB= LUCB address

RPL= RPL Address: indicates the type and location ofthe control block whose fields are to be modified. FieldName= New Value: indicates a field in the control block tobe modified, and the new value that is to be consideredorrepresentedwithin it

- 100 -

OPENLU

The OPENLU macro instruction requires RNAM to acquireone or more Logical units on the CommunicationSystem.

The characteristicsof the required Logical Units arecontained in the referred LUCB! see Figure 29.

ｲ ｾ ｡ ｾ Ｚ ］ Ｍ ｲ ｯ ｰ ｾ ｾ ｾ Ｚ ｔ ｾ ｾ ｾ ｲ ｾ ｾ ｾ ｳ ｟ ｾ Ｇ Ｍ Ｍ ｾ ｾ ］ ］ Ｚ __. .._I

i label OPENLU LUCB= LUCB addressi %, •••

Figure 29:-oPENID macro instrUctlOn

LUCB= Address: indicates the addressof the LUCB thatcontains the characteristics if the Logical Unit to beactivated.

- 101 -

CLOSELU

The CLOSELU macro instruction requires RNAM to releaseone or more Logical units previously acquired.

The LUs to be releasedare indicated by the referredLUCB, see Figure 30.

ｲ Ｍ Ｍ Ｍ Ｍ Ｍ Ｍ ｾ Ｍ -- '---T-'- ..-.---..ＭＭＮＭＭＭＭＭｾ ._..__...-.-I Naree IOperation I Operandsi .. _ -.-- ---1-- ·.._.. ··_-_·_····..·,' ---- , --.. _._ _.,.__..｟Ｇ｟ＮｾＭＭＭ｟Ｎ｟Ｎ｟ＭＭＭ｟Ｎ

label CLOSELU LUCB= LUCB addressI %, •••

Figure 38 CLOSELU macro instruction

LUCB= Address: indicates the addressof the LUCB of theLogical Unit to be releasedand de-activated.

- 102 -

BIND

The BIND macro instruction is a request for connectingthe referred LU to a LU of the specified Application, inorder to establish a session. The LU involved in theoperation is identified by the LUeB field of the RPL.

The amount of data that can be transferred with theBIND message is limited. This limit is fixed by theCommunicationSystem and, in any case, it can not overcomethe maximum length permitted for a packet by theCommunicationSystem, see Figure 31.

,'_.•.•. -.... ....__..,....__... -.__..__.-: ..__._-_....-._..,--_..•.....

I Naree i operation! Operandsr- .. T" - . ··----'1'·.. ·' _--_ ..-. ...'- _'_.,__ＮｾＧｊ｟Ｂ _ ..

• label I BIND : RPL= RPL address, Ii %,RPL field naree= new value

%, •••

III

Figure 31 BIND macro instruction

RPL= RPL Address: indicates the location of the RPLthat describesthe BIND operation.

RPL Field Name= New Value: indicates an RPL field to bemodified, and the new value that is to be containedorrepresentedwithin it.

Although any RPL operand can be specified, thefollowing operandsapply to the BIND macro instruction.

DESTID= Destination Identification: indicates theNetwork location where the Application to be bound is. TheDESTID operand contains either the addressof the identifieror directly the identifier itself The DESTID field containsdirecly the identifier.

APPLID= Application Identification: indicates theidentifier (1 to 8 alphanumeric characters) of theApplication to be bound. The APPLID operand contains eitherthe address of the identifier or directly the identifieritself. The APPLID field contains directly the identifier.

- 103 -

PASSW= Authorization Keyword: indicates the keyword (1to 8 alphanumeric characters) necessary to access thedesiderateApplication. The PASSW operand contains eitherthe addressof the keyword, or directly the keyword itself.The PASSW field containsdirectly the keyword,

BINDMSG= YES!+NO+: indicates whether or not theApplication program wants to send a binding messageto thedesideredApplication.

AREA= Data Area Address: data containedat the locationindicated by this field is to be used in the operation.

RECLEN= Data Length: indicates the length (in bytes) ofthe data to be transferred.

ACTION= +BIND+!REJECTIACCEPT: indicates how theApplication program wants to use the BIND macro instruction:to request a connectionor to accept or refuse a connection.

BIND. The Application program wants to request aconnection, the DESTID and APPLID fields areused to determine the counterpart in thedesidered connection, the PASSW and BINDMSGfields are used to collect authorizationinformation to be presented to the requiredApplication

REJECT. The Application program wants to rejectthe connection requestpresentedvia a bindingmessage. The BINDMSG indicates if theApplication wants to send further informationexplaining the connection rejection.

ACCEPT. The Application program wants to acceptthe connection requestpresentedvia a bindingmessage.The BINDMSG field is used to establishwhether or not the Application wants to sendfurther information about the acceptedconnection.

- 104 -

INVITE

The INVITE macro instruction enables the Applicationprogram to place the referred Logical unit in "INVITE"state, waiting for the connectionwith another Logical unitthat wants to establish a session with the Applicationissueing the INVITE macro instruction. The involved Logicalunit is indicated by the referred RPL, see Figure 32.

ｉ ｾ ｎ ｡ ｲ ｯ Ｇ ｾ ｾ Ｎ ﾷ Ｑ Ｍ ｟ ｾ ｰ ｾ ｾ ｾ ｟ ｾ ｾ ｾ __ ｌｾｾＺｾｾ､ｾＭﾷＭ -- ..-Ｍ］ｾＮ］］ ,-.,! label il INVITE I RPL= RPL addressI, I 1%,RPL field name= new va ue

I I %, •••

I

Figure 32 INVITE macro instruction

RPL= RPL Address: indicates the location of the RPLthat describesthe INVITE operation.

RPL Field Name= New Value: indicates an RPL field to bemodified; and the new value that is to be containedorrepresentedwithin it

Although any RPL operand can be specified, thefollowing operandsapply to the INVITE macro instruction:

AREA= Data Area Address: the area at the locationindicated by this field is to be used to place the comingbinding message (if required).

AREALEN= Data Area Length: indicates the length (inbytes) of the data to be transferred.

---_._._-_._-

- 105 -

UNBIND

The UNBIND macro instruction is a request to break-upthe connection between the referred Application Logical Unitand its counterpart in the established session.

The involved LU is indicated by the referred RPL, seeFigure 33.r- ._. '--' --- -- -.----.-..- -.---.-- ｾＭ

! Name Operation Operands1·_·······.. . - _ - .._.. '--'-'--' --------..,.-.,.. -.- __._._--I I

I label I UNBIND RPL= RPL addressI 'iI

I

Figure 33 UNBIND macro instruction

RPL= RPL Address: indicates the location of the RPLthat describes the UNBIND operation.

- HJ6 -

SEND

The SEND macro instruction isdata from the requesting LU toestablishedsession.

a request to transferits counterpartin the

The SEND macro instruction can be used only when thesessionhas been established and only by the part to whichthe CommunicationSystem has assignedthe ., senderII role inthe use of the Logical Channel.

The " sender" role is assigned, at the opening of thesession, to that part which played the active role in theconnection (using the BIND macro instruction) and can beexchanged only on initiative of the "senderll itself, thatcan pass this role using the Change Direction Indicatorfield. The involved LU is indicated by the referred RPL, seeFigure 34.

r-----I Name

I'·label

I

Figure 34 SEND macro instruction

RPL= RPL Address: indicates the location of the RPLthat describesthe SEND operation.

RPL Field Name= New Value: indicates an RPL field to bemodified, and the new value that is to be containedorrepresentedwithin it.

Although any RPL operand can be specified, thefollowing operandsapply to the SEND macro instruction:

AREA= Data Area Address: the data contained at thelocation indicated by this field are Sent to the connectedLU.

RECLEN= Output Data Length: the number of bytesindicated in this field is sent to the connectedLU.

- 107 -

REQRESP= EXC!DEF!+NO+: this field designatesthe typeof responsedesideratedfor this request.

EXC Only exception responseexpected.

DEF Definite responseexpected.

NO No responseexpected.

CHNGDIR= YESl+NO+: this field designatesif the ChangeDirection Indicator is to be set on (YES) or off (NO).

CHAIN= FIRSTIMIDDLEILASTl+0NLY+: indicates the relative'position of the message within the chain currently beingtransmitted. ONLY means that the messageis the sole elementof the chain.

108 -

RECEIVE

The RECEIVE macro instruction is a request toin the Application program area, data corning,referred LU, from the connectedLU during a session.

transferon the

%, •••

RPL= RPL address%,RPL field name= new value

The RECEIVE macro instruction can be used only when thesessionhas been established, and only by the part to whichthe CommunicationSystem has assignedthe ｾ ｲ ･ ｣ ･ ｩ ｶ ･ ｲ Ｂ role inthe Logical Channel utilization. The "receiver" role isassigned, at the opening of the session, to that part thatplayed the passive role in the connection (using the INVITEmacro instruction). The Ｂ ｲ ･ ｣ ･ ｩ ｶ ･ ｲ ｾ role can be exchangedonly on initiative of the "sender" (see the SEND macroinstruction). The involved LU is indicated by the RPL field,see Figure 35.

.. ", ﾷｔＭｾﾷﾷﾷﾷｾﾷＭＭﾷﾷ ,,_.-r- ｎＺｾＭ Operation I OperandsI ' !• '7'0' _ .. , __ ,__ • __ _l _ ....., ＬＬ｟ﾥ｟ｾＮ __.' _N._ ._ Ｎｾ｟Ｎ __... , " Ｎｾ｟Ｎ ,--.-_._ .' .' -"...-.. -..•-_._....•.::.-........ ---,-._...... ｾ .._-_........,---

" I ;i ! II label I RECEIVE II. [ I

I I

Figure 35 RECEIVE macro instruction

RPL= RPL Address: indicates the location of the RPLthat describesthe RECEIVE operation.

RPL Field Name= New Value: indicates an RPL field to bemodified, and the new value that is to be contained orrepresentedwithin it.

Although any RPL operand can be specified, thefollowing operandsapply to the RECEIVE macro instruction:

AREA= Inputreceived must befield.

Area Address: the data that will beplaced at the location indicated by this

AREALEN= Input Data Area Length: indicates the length(in bytes) of the data area identified by the AREA operand.

- 109 -

BREAK

The BREAK macro instruction enables the Applicationprogram to break-up the send-receivedata flow, allowing theApplication to send asynchronousdata to its counterpart inthe session,also if its role is "receiver"

The BREAK macro instruction can be used only when thesessionhas been established.The amount of data that can betransferred is limited to the maximum length permitted by.the Common Network. The involved LU is indicated by the LueBRPL field, see Figure 36.

label RPL= RPL address%,RPL field ｮ ｡ ｾ ･ ］ new valueCf10 , •••

Figure 36 BREAK macro instruction

RPL= RPL Address: indicates the location of the RPLthat describesthe BREAK operation.

RPL Field Name= New Value: indicates an RPL field to bemodified, and the new value that is to be containedorrepresentedwithin it.

Only the following RPL operandscan be specified:

AREA= Data Area Address:location indicated by thisoperation.

the datafield are

contained at theto be used in the

RECLEN= Data Length: indicates the length (in bytes) ofthe data to be transferred

- llf' -

CHECK

The CHECK macro instruction enables the Applicationprogram to check the statusof a requestedoperation, and,in case. waits for the completion of the operation itself.

When asynchronoushandling has been specified for arequest (ASY option in effect), the Application programreceivescontrol when the requested operation has beenscheduled. A CHECK macro instruction must be issued for theRPL used for the request. CHECK should not be issued forsynchronousrequests.

When CHECK is used, the following action occurs:

If the requestedoperation is not yet completed,CHECK suspends program execution until it iscompleted. If the RPL indicates an external ECB,or if the ECB-EXIT field is not set, CHECKreturns the control to the Application program,when RNAM posts the ECB complete. CHECK clearsthe ECB before returning control. Users ofexternal ECBs with asynchronousrequest handlingmust clear the external ECB (with CHECK or withassembler instructions) before the next RPLbased macro is issued.

If the operation completed with a logical orother error. CHECK causes the LERAD or ERADexit-routine to be invoked, assuming that one isavailable.

This action also occurs when CHECK is issued in any RPLExit-routine, see Figure 37.

RPL= RPL Address: indicates the location of the RPL towhich the CHECK macro is to be referred.

- 111 -

RPL= RPL addresslabel

ｎ ｡ ｭ ｾ Ｍ Ｍ ｲ Ｍ Ｍ ｯ ｾ Ｚ Ｇ Ｚ Ｚ ｾ ｾ ｯ ｮ ｲ Ｍ ｾ Ｇ ｾ ｰ ･ ｲ ｡ ｾ ､ ｳ Ｇ Ｂ -------..

.....L _.., ._. _.__ ;-.. _._._ _ _. --_.. --_.--- --_.-_ .

I II CHECK

Figure 37 CHECK macro instruction

CANCEL

The CANCEL macro instruction enables the Applicationprogram to cancel the operation pending on the referred LU.Only the operationsthat require local (at CommunicationSystem level) execution and for which data transfer has notyet begun, can be cancelled.

The CANCEL macro instruction can be issued only whenthe asynchronous handling has been specified (ASY optioncode in effect), see Figure 38.

Operands

RPL= RPL address

--------r---------------r;,....e ] Operationr"---- ---...-----...

1abe1 CANCEL

.;1

Figure 38 CANCEL macro instruction

RPL= RPL Address: indicates the address of the RPLassociatedwith the request that is to be cancelled.

- 112 -

EXECRPL

The EXECRPL macro instruction permits the Applicationprogram to re-issue a previously issued request withoutmodifying the related RPL.

---_._.. ｾ ..._._.'-

.. __.- _.-._---

The EXECRPL macro instruction can beany RPL based request except CHECK,EXECRPL macro, see Figure 39.

ｲ Ｇ ｾ Ｚ Ｚ Ｍ Ｇ Ｍ ｬ ｾ ｾ ｾ ｾ ｾ Ｚ ｩ Ｚ ｮ Ｍ ｉ ［ ［ ･ Ｚ Ｇ ｾ ､ Ｚ Ｍ Ｍ Ｇ ｾ Ｂ Ｍ Ｇ; _". '.' ! __ 0-."_' .- :-._ _. -" '. __••_.

label I EXECRPL RPL= RPL addressi

usedCANCEL

to executeor another

Figure 39 EXECRPL macro instruction

RPL= RPL Address: indicates the address of the RPL tobe executed.

113 -

TESTLC

The TESTLC macro intruction enables the Applicationprogram to test and to get information on the statusof itsLU, or, if a sessionhas been established, on the statusofthe logical path connecting the LUs in session, seeFigure 40.

r---"-' --,.' ---- Ｍ ﾷ ﾷ Ｍ Ｍ Ｍ ｲ Ｍ Ｍ Ｍ Ｍ Ｍ Ｍ Ｍ ﾷ Ｍ Ｇ Ｍ Ｍ Ｍ ﾷ ｾ ﾷ Ｍ ﾷ ｾI Narr.e I Operation I Operands

r..·.. ."_.__.--- _.\.-_.. _. -. _...._.. "-" ,,!....-.-.-- ..--- -- --_._-- -_._-_.. ｾＮ -----...-..---.-

I Ii label I 'l'ES'l'LC I :RPL= RPL addressi I Ｅｾｌｕｾ ｾＫｌｏｃａｌＫｾｒｅｍｏｔｅｾｐａｔｈ

II

IFigure 40 TESTLC macro instruction

RPL= RPL Address: indicates the location of the RPLthat describesthe TESTLC operation

LU= LOCAL!REMOTE!PATH: indicates the LU to be tested:

LOCAL: Only the local LU has to return its logicalstatus

REMOTE: only the connectedLU (in a session) hasto return its logical status.

PATH: the full logical path status has to bereturned.

- 114 -

The INQUIRE macro instruction enables the Applicationprogram to enquiry about the Network environment, using theservicesoffered by the CommunicationSystem. This macro hasnot been implemented in RPCNET, until now.

- 115 -

MAIL

The MAIL macro instruction enables the Applicationprogram to send and receive messagesto and from anotherNetwork user or Network operator, utilyzing the mailingservice offered by the RPCNET CommunicationSystem.

The MAIL macro instruction can be used only referred toan already opened LU. When used to receive messages, theMAIL macro instruction sets up a "mail box;' that remainsactive until a mail message arrives, closing the mailrequestoperation. When used to send a message, the MAILmacro instruction enablesthe Application program to specifythe addressed identifier and the message text. TheCommunication System, on RNAM request, preparesthe mailmessage,and forwards it to the appropriatedestination. Themail request operation is consideredclosed as soon as themessageBIU leaves the node. The information carried by themail message as text can not be more than 128 bytes long,see Figure 41.

ｲ ｾ Ｇ .._- .I Name I. .

Operation

- 1-···· Ｂ Ｇ ｟ Ｇ Ｇ Ｇ ｟ Ｇ Ｇ Ｇ Ｇ Ｇ ｾ Ｇ Ｇ Ｍ Ｍ Ｇ Ｇ Ｇ Ｌ Ｎ __ _- .."..--_ _-'---' Ｍ Ｍ Ｍ ｾ Ｎ

Operands,....I

I label

II

I

ｽＧｉｾｉｌ RPL= RrL addressr-rRPL field name= new valuertf/0 I •••

Ｅ Ｌ ｾ ｾ ｉ ｌ ｏ ｐ ｔ ］ lSENDlRECEIVE%,BOXLAB= mail box identifier

Figure 41 MAIL macro instruction

RPL= RPL Address: indicates the location of the RPLthat describesthe MAIL operation.

MAILOPT= Option Code: indicatesoptions that are toaffect the mail request.

SEND!RECEIVE: indicates whether the Applicationprogram wants to send a mail message (SEND), orto set-up a mail box (RECEIVE).

RPL Field Name= New Value: although any RPL operand canbe specified, the following operandsapply to the MAIL macroinstruction:

- 116 -

AREA= Data Area Address: the area at the locationindicated by this field is to be used to extractthe messagetext or to place the incoming mailmessage.

AREALEN= Data Area Length: indicates the length(in bytes) of the data to be transferred.

LOCID= Location Npme: this field is used toindicate the Network location where the messageis to be sent. The LOCID operand contains eitherthe addressof the identifier, or the identifieritself.

APPLID= this field indicates the name of theApplication which the mail messageis addressedto. The APPLID operand contains either theaddress of the identifier, or the identifieritself.

- 117 -

5 3.4 Macro instruction return codes

RNAM posts return code information in a general purposeregister and for the RPL basedmacros, in certain fields ofthe requestedRPL.

These fields are referred to as "feedback" fields. Themanner in which the general register and the feedback fieldsare posted dependson whether synchronousrequest handling,asynchronous request handling with a ECB, or asynchronousrequest handling with an RPL exit-routine is used. RNAMalways sets the general register to zero if a request hasbeen acceptedor has completed normally. When a request isnot accepted, or it is completed abnormally, RNAM schedulesthe LERAD or ERAD exit-routine. If LERAD or ERAD exitroutine is executed, upon return of control to the nextsequential instruction, the general register containswhatever value was placed in it by the exit-routine. If RNAMcannot find an exit to schedule, then it sets the generalregister, and returns control to the next sequentialinstruction. RNAM, at now, uses only one non-zero returncode in the general register: 4. This is termed a generalreturn code. The errors are organized in 6 classes,according to the program recovery action that is appropriatefor each error. TO summarize:

There are 2 general return codes: 0 (normal), 4(abnormal).

There are 6 recovery action codes that apply forabnormal completion. These are posted in theRTNCD field of the RPL. If LERAD or ERAD areinvoked, the exit-routine can return its owngeneral register value to the next sequentialinstruction.

There are numerous specific error return codes,that apply for abnormal completion. These areposted in the FDBK field of the RPL.

ｾ Ｎ ｬ Ｎ ｬ Ｎ ｬ ｾ ｾ ｾ ｩ ｦ ｩ ｣ ･ ｲ ｲ ｾ ｾ ｾ ｾ ｾ ｵ ｲ ｾ ｣ ｯ ｾ ｾ (FDBK): The returncode set in the FDBK field is meaningful only when it isconsideredtogether with the recovery action return code inthe RTNCD field. The specific error return codes apply onlywhen RTNCD contains a non-zero recovery action code.

RTNCD = 4 Special condition

- 118 -

FDBK:l Cancel issued with I/O in progress. ACANCEL macro instruction has been completedabnormally, because data transfer is inprogressNo effect on the referred Application.2 Cancel issued successfully.The operationhas been terminateddue to a CANCEL request.3 Unknown Network destination specified.The request addressesa destinationunknown tothe Network.4 Required binding message not sent. TheBIND messageis abnormally terminated, due tothe absenceof the binding message.S Password incorrect. The authorizationkeyword is incorrect.6 BIND refused by the requestedApplication. The requestedApplication, afterchecking the bind message, has refused theconnection.7 Referred LU not in session.An in sessionrequest has been made to a LU not in session.8 LU not in "send" state. A SEND requesthas been made to a LU not in "received state.9 LU not in "receive;; state. A RECEIVErequest has been made to a LU not in "receive"state.ｬ ｾ Inquiry incorrect. An incorrect INQUIRYrequest has been made (reserved for futureuse) .11 Inquiry information not available. Therequired information is not available (reservedfor future use).

RTNCD = 8 Retry

FDBK 1 Temporary storage shortage. RNAM istemporary unable to receive enough storage toprocess the request. The request can be re-issued (for ex. via a EXECRPL).2 No LU available. The LU request has notbeen accepteddue to a temporary unavailabilityof the Communication system to assign a LU. Therequest can be re-issued.3 No Application port available. The BINDrequest has been refused due to a temporaryunavailability of a port (LU) on the requestedApplication. The request can be re-issued.

RTNCD = 12 Data integrity damaged

The referredshut-down. Allsessions and

- 119 -

FDBK 1 Input area too small. The issued inputrequest specified an input area that is toosmall RNAM has placed the required length (inbytes) in the RPL s RECLEN field. Only a partof the data has been placed in the area.2 Incoming response indicates exceptioncondition, A negative responseto the send datarequest has been received.3 Exception condition for incoming data.Data has been received for which an exceptioncondition exists.

RTNCD = 16 Environment error.

FDBK 1 Session partner unreacheable. TheCommunication System is unable to reach theother session partner. The session can beconsideredclosed or suspended.2 Network in shut-down.Network interface has decided tothe Application could close itsreleaseall LUs.3 RequestedApplication not available. Therequested Application (for bind) is notavailable at the indicated Network location.

RTNCD = 20 Logical Error

FDBK 1 Control block invalid. The RPL's LUCBfield does not contain the addressof a validLUCB.2 Zero EXIT field The RPL indicates thatthe ECB-EXIT field is being used as an EXITfield, but the RPL Exit routine address iszero. No RPL Exit routine has been scheduled.3 Zero ECB field. The RPL indicates thatthe ECB-EXIT field is being used to point to anexternal ECB, but the address in the relatedfield is zero. No ECB has been posted.4 Inactive RPL checked. CHECK was issuedfor an inactive RPL (an RPL that had beenposted complete, and for which CHECK was issuedsuccessfully). All RPL based macros, however,must use an active RPLi an RPL cannot bechecked twice.5 Active RPL referred. A request has beenmade for an active RPL (a RPL that has anoperation pending). All RPL based macros,except CHECK, must use an active RPL.6 CANCEL issued for an inactive RPL. ACANCEL request has been issued for an inactiveRPL (a RPL that had been posted complete, and

- 120 -

for which CHECK has been issued successfully.7 Invalid option. The request failedbecauseof an incorrect setting of the involvedoption.8 Invalid data area. Either all or part ofthe output area lies beyond the addressablerange of the Application program.9 Invalid data or length. For an inputoperation either an input area addressbeyondthe addressable range of the Applicationprogram has been supplied, or the area lengthhas been invalidly indicated as zero10 Max. number of ports for the Applicationexceeded. with this OPENLU request, thespecified max. number of ports for theApplication has been exceeded.11 Invalid destination identifier. Theidentifier for the Network location to beaddressedhas been invalidly specified.12 Invalid Application identifier address.The identifier for the Application to beaddressedhas been invalidly specified.13 Invalid password or password address.The authorization keyword to be utilized inaddressingthe Application has been invalidlyspecified.14 Application identifier unacceptable.Thespecified Application identifier is alreadyactive or not valid.15 Invalid BIND or INVITE request. Thespecified request is unacceptablebecausethereferred LU has Network requests (MAIL orINQUIRY) pending.16 Network service request unacceptable.The specified Network service request (MAIL orINQUIRY) is unacceptablebecause the referredLU has a sessionactive.

- 121 -

5.4 User ｾ ｰ ｅ ｊ ｩ ｣ Ｚ ｾ ｾ ｩ Ｒ ｾ ｰ ｲ ｯ ｴ ｾ ｣ Ｒ Ｑ Ｎ ｾ

5.4.1 Introduction

The introduction in the RPCNET of a general accessmethod like RNAM; makes it possible to write programs (inAssembler language), which can communicateeach other usingthe CommunicationSystems.

These programs, in the RPCNET! were calledApplications: every user can write -an Application, but thereexist some special Applications. that we could call SystemApplications, which have to perform more general functionsand/or services.

These Applications must have their own, well definedprotocol, and very often they require an operating systemmodification.

In RPCNET, two System protocols were studied andimplemented as System Applications:

a) the Virtual Terminal Protocol

b) the File Transfer Protocol.

- 122 -

5.4.2 File Transfer Protocol

One can consider a File Transfer in two different ways:

in the first way files are transmitted from a"spool system" to another one, wi thout any otherintervention of the user than the first command(for ex. SEND).

in the second way,statically stored indisk), and they can bea local device.

files are considereda remote device (tape oraccessedas they were in

The first kind of File Transfer was called Spool-to-Spool Transfer Protol, while the second one is called RemoteFiles Access Protocol. In the RPCNET, the Spool-to-Spoolwasdesigned and implemented, while the Remote File AccessProtocol is in course of final definition, and wasimplemented only in one particular environment, the VM!370environment. So that, we will describe in the following onlythe Spool-to-SpoolProtocol.

5 ＴＮｾＡ The ｾ ｰ ｯ ｾ Ａ Ｍ ｾ ｾ Ｍ ｾ ｐ Ｒ ｾ ｬ ｰ ｲ ｯ ｾ ｾ ｣ ｯ ｬ Ｎ Some of theproblems to be solved for such a protocol were:

Type of Logical Channel to be used

Rules for opening and closing communication

Coded information describing files (File Tag)

User Data Unit (UDU) incommunication

a Spool-to-Spool

Acknowledgment and error recovery

Since a spool file exchange is typically a one-waycommunication, simplex Logical Channelsare used.

A Channel is opened each time a Spool System (Sender)has to send a spool file (or a set of spool files) toanother Spool System (Receiver). The Channel is releasedwhen the transmissionhas been successfullycompleted. ThisChannel is the normal vehicle for transmissionof File Tagsand data.

Other kinds of information, however, need to beexchangedbetween Sender and Receiver. These are: connectionrequests (the channel does not yet exists; messages ofacknowledgmentand requestsfor error recovery. These latter

- 123 -

must be sent in the opposite direction to the main flow.

For connecting purposes, RPCNET offers the uBINDmessage" facility, which allows the Sender to send also alittle amount of information to its Receiver. The RPCNETBREAK will be used for messageswhich must go from Receiverto Sender. The underlaying hypothesis is that Break packetscannot get lost. In other words, the subnetwork is supposedto guaranteethe arrival of this type of messages.

As a very first approach, card image and print linesseem to be the natural transmissionunits for spool files.It must be considered, however, that the percentage oftrailing blanks in spool lines or cards is generally veryhigh. Considering also that the physical unit oftransmission (packet) in the subnetwork may be much longerthan lines or cards, the disadvantagesin performance thatsuch a choice could bring is easily seen:

Logical Channel overhead: whatever amount ofdata is contained in a packet, it needs a fixedlength amount of protocol information. Thisimplies that the percent of data informationbeing transferredon a Logical Channel could bevery low;

System overhead: checking protocol must be doneon every packet, independentlyon the amount ofuseful data it may contain;

resource overhead: along all the path fromSender to Receiver, there could be anoverallocationof buffers in the intermediateNodes.

Some of these disadvantages could be eliminated bypacking printer lines or cards into packets. However, thissolution would have a non-negligible CPU time cost, andwould be dependent on the packet length. So, in order tomantain independencefrom subnet packet length, and in orderto minimize the percentageof control information, we haveto use spool disk blocks as User Data Units (UDUs) or BIUs,in RPCNET notation.

A spool block however, cannot be considered as astandardunit. In fact, the various operating systemswhichcan be present in a Network, will generally have differentspool systems. This implies, in particular, differentlengths and different logical structures (formats) ofblocks. As far as format is concerned, a nnetwork spoolformat" was to be decided upon, which is unique in theNetwork. Every spool system shall be made able to send and

- 124 -

receive files using this standardformat.

However, in each particular spool-to-spool activity,Spool Systems have been given the possibility to choose someother format that seems to be more suitable for thatparticular activity. This will happen of course, when bothSender and Receiver run under the same operating system; butit can be useful, also in other cases, that only one of thetwo partnersadapts to the other's format, instead that bothof them adapt to the standardnet format.

Standardnet format is shown in Figure 42. In the lastblock of the file, the end-of-block character.FFis replacedby the end-of-file characterEF.

LEN CCW DATA

LEN CCW DATA I LEN I.....- - --. · . · ··· . . . . . . . . . . . . . .

1--- - - - - -- -- - - - - - - -· ·. ··· . . . . . . . . . .

--- - - -- - ---- - - - - - --· . · . · · ·

1FF I100- - - - -

Figure 42 NET format for spool blocks

As far as output files are concerned, some informationis necessaryat the receiving station, concerning name, typeand birthdate of files, and, possibly, about the outputdevice to which they must be addressed.All these parameters(File Tag) are grouped at the beginning of the first BIU(block), as shown in Figure 43. At present time, the FileTag area is left empty for input files. For batch-orientedSpool Systems, FILENAME will mean jobname, and FILETYPE canbe replaced by programmer's name. OUTDEVID denotes aparticular remote or local output device.

The size of the BIUs is decided while establishing theLogical Channel, according to the rule that the systemhaving the larger block size shall adapt to the "smaller"one. In fact, it is more difficult to handle core bufferslarger than those normally used in the System, than sending

Figure 43

- 125 -

FILENAM FILETYPE DATE

HOUR OUTDEVID

LEN CCW DATA LEN

CCW . . . . . . . . . . . . . . . . . . . . .-------------.......... i

IｾＭＭＭＭＭ FF

BIU format for File Transfer

or receiving a block splitted in two or more BIUs.

A sessionfor opening a communication is made up ofthree steps: INVITE, BIND and BIND RESPONSE.

Since no information can be received if it has not beenrequested, the Receiver must notify to the Network itsavailability to perform Network operations.This is done bymeans of the INVITE function, that is, a request to thelocal CommunicationSystem to receive a message from theNetwork. Information supplied by INVITE contains:

Receiver identification (SPOOL)

Address of a fixed size coremessage from a partnercommunication.

areaasking

toto

storeopen

aa

The Sender spool system asks to open theby sending a BIND to its partner. BINQfollowing information:

communicationcontains the

Type of file(s) to be sent (input, punchprint);

Spool block length;

Spool block format(s) .

In order to use the BIND, the user must supply thefollowing information:

- 126 -

Destination Node;

Destination Host;

Destination Application Name (SPOOL).

It is assumed, in any case, that a BIND must receive ananswer, which specifies the statusof the Receiver. Thisstatusmay be one of the following:

Ready and allocated;

Busy;

Not active (not presentat the moment in theNetwork);

Invalid destinationaddressing.

In the first case,in the last case, thewill be notified. In thefollowing procedurescan

Retry later;

a communicationcan be established;operator or the originating process

intermediate cases, one of thebe used:

Retry after an operator command;

Retry immediately;

Retry when another file has to be sent to thesame destination;

Retry when a Network re-configurationoccurs;

Etc.

According to its own parametersand to those of itspartner, the Receiver decides length and format of the BIUto be used. After that, it sends back a BIND RESPONSE to theSender; this is an acceptanceof connection and contains thefollowing information:

BIU length to be used;

BIU format to be used. According to thementioned before hypothesisof BREAK facility,no error recovery procedurewill be implementedconcerning the BIND RESPONSE.

It can happen that a block sent by the Sender does notreach the Receiver, and gets lost. This happens, for

- 127 -

example, when a packet gets lost because a Node hasacknowledgedthe packet, and fails before sending it.

In order to guarantee to the receiving process thecompleteness of the file, both Sender and Receiver need tobe involved. The Receiver should be able of recognizing thelack of blocks, the Sender of sending them again, and theReceiver of reconstructingblock sequencewithin the file.

First of all, each block needs a sequenceidentification number, which must be generated by theSender. This number will be used'both by the Receiver, forcheck and response, and by the Sender, for any possibleretransmission.The Sender has to keep pointers to theblocks just sent until it is made aware that a certainnumber of them is successfullyarrived. Otherwise, it shouldread again the whole spool file, looking for thoseparticular blocks.

Therefore, at the Sender side, this protocol requires atable of pointers to the blocks. The size of the table is tobe decided during the connectionphase, with an algorithmwhich will be discussedlater. Each entry is composedof:

the sequence (or identification) number of theBIU;

the complete disk address which allows theSender to resend the BIU when necessary.

At the Receiver side, the sequenceof received blocksis controlled before writing them on disk. When the normalsequenceis broken becauseof the absence of one or moreblocks, this fact is registered in a Hhole table". Thistable will be used both for asking the Sender to resendlacking blocks, and for writing these blocks in the properarea of disk when they finally arrive. In fact, space isreserved in every case in the receiving buffer or on disk,and the receiving processgoes on. Each element of the tablecontains complete information about every missing block,that is to say, each entry is composedof:

sequenceidentification number of the missingblock;

complete addressof the disk area reserved forthe block

- 128 -

pointer to the next block on disk, which will bewritten with the block for chaining purposes.

When the Receiver realizes that the normal sequence isinterrupted by one block whose sequence identificationnumber is less than it was supposedto be, a scan of the"hole table" is made. If that sequenceidentification numberis registeredon the table, the block is written in thereserveddisk area, and the respectiveentry is erasedfromthe table. If, on the contrary, the sequenceidentificationnumber is not in the table, the block is consideredas aduplicate, and for this reason ignored.

The "hole table" has the same number of entries as thecorrespondingSender table. The size of the table is choosenin such a way that one recovery is possible before the spacein the table is exhausted.That is to say that failures, asa rule, are supposedto be recoveredat the first attempt.

Let 2N be the number of entries in the table. Whenevera received block has a sequenceidentification number equalto (or greater than) N, 2N, 3N ... , the Receiver sends amessage to its Sender for signalling the state of theprevious N blocks. If all N blocks have been receivedproperly, the Sender releasesthe correspondinghalf tableIn case of loss of one or more of these blocks, the Senderstops normal sending sequence for resending the missingblocks.

The integer N must be chosen in such a way to allow thearrival of an acknowledgmentabout the N blocks pointed inthe first half of the table, before the second half has beencompletely filled in. In order to comply with thisrequirement, it is sufficient that the shipment time of NBIUs is greater than, or equal to the time requestedtorepeat twice the following sequence:

one BIU from Sender to Receiver;

one control block from Receiver to Sender.

Let be:

2N number of blocks in buffer

La number of charactersper control block

Lb number of charactersper BIU

- 129 -

S line speed in charactersper second

n number of links between Sender and Receiver.

Then, the time requestedfor sending N blocks will be:

T = N * Lb/S

and the time requested for repeating twice the sequenceabove described is:

T' =,2n * La/S + 2n * Lb/S

We want to find N in such a way that T>= T'. That is:

N>=2n*(1+ La/Lb)

As La is supposed to be not greater than Lb, N=4n seems tobe a good solution for our purposes.

The number n of links between Sender and Receiver canbe obtained during the Connecting phase.

It may happen that the Sender fills up one half of itstable before the other half can be released.This happens intwo cases:

The Sender has sent 2N BIUsfeedback.

without any

Some resent blocks have been lost again.

In the first case, the Sender starts a timeout, and ifnothing arrives within a fixed time, the Sender closes theconnection. In the second case, the last received holes areresent again, and a timeout mechanism is started; if thetimeout expires without replies, the Sender closes theconnection.

On the other side, the Receiver starts a timeoutmechanism each time a block arrives; when the timeoutexpires, a break messageis sent, containing the presentsituation of received blocks, and a second timeout isstarted. If also the second timeout expires, the connectionis closed.

After a whole file has been successfully sent, theSender can begin the transmissionof another file. If thereare no more files of the same type for the same destination,the Sender issues a CLOSE, that is to say, a request toclose the Logical Channel used until that time. Then theSender expects no more messagesfrom the Network.

- 130 -

When a Receiver got an entire file, it expects toreceive an UNBIND or another file. If nothing arrives, theReceiver uses the same procedure as in the case ofinterruption of communicationduring file transmission.

- 131 -

5.4.3 Virtual Terminal Protocol

The Terminal Application is made up of a line driverthat maps a real terminal into an idealized terminal (herecalled a Virtual Terminal, or VT), a Network CommandProcessor, and a module for communicatingwith the HostApplication via the RPCNET Logical Channel.

The Host Application maps the Virtual Terminal Protocolinto actions meaningful to the Host computer. As far as theHost and Terminal Applications were concerned,a full-duplexfacility was easier to work with. In RPCNET the LogicalChannel provides a full-duplex facility (if we use the BREAKfacility), with error detection in case of loss of messages,or out-of-sequence messages between the components. Theerror recovery is the same as for both loss and out-of-sequence.

. It is worth noting that the first implementation ofRPCNET was intended to insure that the messageloss occurredonly with a loss of a Network Node containing the message.Thus, although the error recovery is necessary,it is seldominvoked, except to prevent "hang;' conditions, in the rarecase of a crash of a node holding a messagerelevant to theHost and Terminal intercannection.

Relevant to this discussion areBREAK and TESTLC RPCNET operations.DueLogical Channel, it is necessary tobefore a Receiver can send and a Sender

the SEND, RECEIVE,to the nature of the

oj change directionIIcan receive.

In the RPCNET VTP, the terminal side is always kept inRECEIVE mode, while the Host side is always kept in SENDmode. This producesonly minor restrictionson the terminalside, which has to stop its current RECEIVE, in order tosend its messageby BREAK.

Other functions for controlling the Logical Channel ofinterest here are those used for making and breakingconnectionsbetween the Applications. Typically, the HostApplication will have as many INVITEs in action as there arefree ports (emulated terminals) available for connection toits Host. When a user of a terminal requestsa connection toa Host, a BIND is done, and if there is a correspondingINVITE at the Host, then the connection is made.

Since the IIdirection·· of the Log ical Channel isinitially not as desired (the terminal is the Sender, theHost is the Receiver), the terminal Application issues aSEND with change direction, to turn the channel around. Atany time, either Application can do an UNBIND to break the

- 132 -

connection. This is normally done either at the request ofthe terminal user, or when the Host computer "crashes". TheFigure 44 illustrates the statesin which a virtual terminalcan be.

A "line down" puts any State into the DISABLE State

Figure 44 statesof a virtual Terminal Protocol

The write state is when the terminal is writing to theterminal user, and the read state is when the user can typeinput on the terminal. The prepare state is used to watchfor asynchronous attentions, or the disconnectionof theterminal. The prepare, the write and the read state arehaltable by the program driving the VT.

The virtual terminal characterset is the EBCDIC.

The behaviour of the two Applications when contactingeach other is illustrated in Figure 45.

There is a state diagram for each Application,indicating how the BIND and INVITE operationsare used. TheBIND messageused by the Terminal and Host Applications isdescribed later. If the BIND request is acceptedby theHost, a BIND message is sent by the Host Application.Finally, the terminal BIND request operationends, with anindication of the successor failure of the connectionmaking attempt.

TERMINAL ApPLICATION

- 133 -

HOST ApPLICATION

BindRejec&Rese

Cancel

Figure 45 state diagram for the Virtual Terminal

The BIND messagecan be up to almost a packet inlength, allowing a very long protocol message.In the RPCNETimplementation, the first byte is used to specify the typeof protocol to be used. i.e. the type of the Host to beconnectedwith. At now, the hexadecimalvalue 140' is usedto specify a VM/370 Host, 180' is a 5/7, and'20' is anOS/TSO. Other values are free. According to the first byte,the length of the BIND message can be different: forexample, in the VM/370 implementation, there are 5 bytesmore, to describe the device type, the device class, etc.

Read, write, halt, attention and related activitiesproceed until one of four situationsarise, signalling theend of the session. If the terminal is disconnected, or theHost goes down, or if the Host disables the terminal, thesession is ended. in addition, behavior of the Network

- 134 -

itself can end the session, as when accessis lost betweenthe Application due to Network failure.

All the messages,during the session,are "data", withrespect to RPCNET facilities that support Logical ChannelsThese messagescompose the elementsof VTP. The first bytereflects the four classes of messagesin bits 0 and 1. Avalue of 00 designatesterminal and Host action messages,such as write, read, halt, attention, and acknowledgmentsthereof. A value of 01 designatesterminal and Host orientedcontrol messages, such as type-aheadcontrol. A value of 10designatesa Network oriented action message, such as theｾ ､ ｯ TESTLC" message. A value of 11 designatesNetworkoriented control messages, such as disable, host down, orterminal down.

Bit 2 of the first byte indicateswhich Application isthe Sender. A value of 0 designates the Host, and 1designatesthe terminal. Bits 3-7 are used to furtherdistinguish the message.

byte 1000000000000000100000010000000110010000000100001001000100010001101100000

XY=00XY=01XY=10CCCC=

101000001100000011100000

byte 2 byte 3n------n halt nn------n read request nn------n data.... write request nm------m acknowledgeattention mn------n acknowledgewr. or ht nn------n data.... read reply nn------n m------m wr. n ended by attn. mm------m attention mXY00CCCC wr. ahead mode control

no write ahead; no messagesaveno write ahead; messagesaved for error recoverywrite ahead allowedcount of messagesthe Host Application can writeahead.

do TESTLCdisableterminal disconnected

The Host Application does not need a queue formessages. It needs only a counter to record the number ofunprocessedattentions, and a variable to hold the latestattention sequence number. The terminal Application willneed queues for both input and output, to communicate withthe Host Application. The output queue is to hold itemsdelayed becausethe current RECEIVE could not be cancelledsince it was busy receiving a message.The input queue holdsread write and halt requestsfrom the Host. There is asecond queue between the terminal and' the input queue; it isused for processingterminal Application control messages,and it is otherwise empty.

- 135 -

The Host Application assignsnumbers sequentially andcyclically running from 0,1, ... ,255,0,•. to read, write andcertain halt requestsof the host computer.

A halt is assigneda number if it halts a read orwrite, otherwise it is not counted and is ignored. Notice ofeach such halt, read or write is sent to the terminalApplication, where each is enqueuedfor presentationto theterminal handler

As each is processedby the' 'terminal handler, it isacknowledgedby a messagesent back to the Host Application.The messagecontains the messagenumber assignedby the HostApplication originally. The acknowledgment mechanism isnecessaryto prevent the Host from flooding the Network witha series of write messages.The acknowledgmentsmessagesareof several sorts: normal write or halt acknowledgments,write ended with attention, and read reply (which includesthe data that was requestedto be read from the terminal).

Successiveattentionsare designated in the messageformats by successiveattention numbers, running cyclicallyfrom 0,1,... ,255,0,... The terminal Application assigns thesequencenumbers for attention.

When an attention is presentedto the Host computer, bythe Host Application, a messageacknowledging the attentionis returned to the terminal application.

Two messagesdesignatean attention, one normal (notinterrupting a read or write), and one ending a write.Attentions ending a read are not included in the attentionmechanism described here, since by convention they aredesignatedby a read reply message, that lacks a "new line"character as its last character. One messageis used todesignatethat an attention has been presentedto the Host.Such presentationis done by ending the current (if one) orthe next read, write or preparewith an appopriateattentionindication. No more than two attentionscan be sent from theterminal to the Host at any time which have not yet beenacknowledged. Note that attentions ending a read are notcounted in this figure.

- 136 -

APPENDIX A

Y Cable Hardware Connections

137 -

CABLE ADAPTOR: CA1A

2705 BSC TSTM.female connection

protective groundtransmit datareceive datarequest to sendclear to senddata set readysignal grounddata carrier detect.transmit timingreceive timingdata terminal ready

2703 BSC RCV.ｦ･ｾ｡ｬ･ connection

protective groundtransmit datareceive datarequest·to sendclear to senddata set readysignal grounddata carrier detect.transmit timingreceive timingdata terminal ready

1----2----3----4----4----6----7----8----15---17---20---

1----2-----3----4----5----6----7----8----'15---17---20---

----1----2----3----4----5----6----7----8----15----17----20

protective groundtransmit datareceive datarequest to sendclear to senddata set readysignal grounddata carrier detectortransmit timingreceive timingdata terminal ready

- 138 -

APPENDIX B

An Example of the NETCHANGE Protocol

- 139 -

In this ａ ｰ ｾ ･ ｮ ､ ｩ ｸ B we give an example of how the protocol works fora particular network.

The network is the one describedin Figure 2.

Initial configuration

A ABIA.D

A - - - -

.,] 1 3 1 B

C 2 2 2 B

n 3 1 1 0

E 3 2 2 0

B BA BC

A 1 3 1 ｾ

R - - - -C 3 1 1 C

n 2 2 2 ｾ

E 3 2 2 ｾ

C CB ｾｄ roE

A 2 2 3 2 ;B

R 1 3 3 1 B

C - - - - -.

n 3 1 2 1 0

E 3 2 1 1 E

D bA DC )E

A 1 3 3 1 A

R 2 2 3 2 A

C 3 1 2 1 C

n - - - - -E 3 2 1 1 E

E EC D

A 3 2 2 D

R 2 3 2 C

C 1 2 1 C

-n 2 1 1 D

E - - - -

The link EC goes down. Changesoccur in nodes C and E.

A AB ｾｄ

A - - - -

B

C

n

E

B BA 3C

A

R - - - -C

n

E

C CB D E

A 2 2 5 2 B

R 1 3 5 1 B

C - - - - -.

n 3 1 5 1 0

E 3 2 5 2 0

D DA DcbE

A

R

C

n - - - - -E

E EC D

A 5 2 2 D

R 5 3 3 D

C 5 2 2 D

-n 5 1 1 D

E - - - -

After the changes, the node C sends its Routing Table (distancecolumn)to B and Dr the node E sends its Table to Dr the Tables are changed.

A AB I\D

A - - - -

R

C

n

E

B BA BC

A 1 3 1 A

R - - - -C 3 1 1 C

n 2 2 2 A

E 3 3 3 A

C CB ｾｄ roE

A

R

C - - - - -.n

E

D bA DcbE

A 1 3 3 1 A

.R 2 2 L! 2 A

C 3 1 3 1 C

n - - - - -

E 3 3 1 1 E

E EC D

A

R

C

-n

E - - - -

- 140 -

The Routing Table for the node D has not been changed, so that onlya sends its Routing Table to C and A.

A AB it\D

A - - - -R

1 3 1 a

C 2 2 2 C

n 3 1 1 D

E 4 2 2 D

B BA acA

R - - - -C

n

E

C CBCD E

A 2 2 5 2 a

R1 3 5 1 a

C - - - - ｾ

n 3 1 5 1 D

E 4 2 5 2 D

D DA DC bE

A

R

C

n - - - - -E

E EC D

A

R

C

-n

E - - - -

As the Routing Tables of A anc C have not been changed, the processends.Now, let's see what happensif the link EC comes up again.

Changesoccur in C anc E.

A AB f\D

A - - - -B

C

n

E

B BA ｾｃ

A

R - - - -C

n

E

C ｃｂｾｄｾｅ

A 2 2 5 2 B

R 1 3 5 1 ｾ

C - - - - -.n 3 1 5 1 0

E 4 2 1 1 E

D DA DebE

A

R .C

n - - - - -E

E EC D

A 5 2 2 D

R 5 3 3 D

C 1 2 1 C

on 5 1 1 D

E - - - -

C sends its Routing Table to a, D and E. E sends its Routing Table to Cand D.

A AB1AD

A - - - -R

C

n

E

B BA BC

A 1 1 1 A

R - - - -C 3 1 1 C

n 2 2 2 A

E 3 2 2 C

C CB D E

A 2 2 3 2 a

R 1 3 4 1 a

C - - - - -.n 3 1 2 1 D

E 4 2 1 1 E

D bA DCbEA 1 3 3 1 A

R 2 2 4 2 A

C 3 1 2 1 C

n - - - - -

E 3 2 1 1 E

E EC D

A 3 2 2 D

R 2 3 2 C

C 1 2 1 C

-n 2 1 1 D

E - - - -

- 141 -

E, D and B modify their Routing Tables, which are sent to the neighbors.

A AB AD

A - - - -R 1 3 1 B

C 2 2 2 B

n 3 1 1 D

E 3 2 2 D

B BA BCA

R - - - -C

n

E

C CB D E

A 2 2 3 2 Ie

B 1 3 3 1 IE

C - - - - -n 3 1 2 1 10

E 3 2 1 1 IE

D bA DC JE

A 1 3 3 1 A

R 2 2 3 2 A

C 3 1 D 1 C

n - - - - -

E3 2 1 1 E

E EC D

A 3 2 2 D

B2 3 2 C

C 1 2 1 C

-n 2 1 1 D

E - - - -

None of the Routing Tables has been modified. The processends, and theconfiguration is the same as the beginning of our example.

- 142 -

APPENDIX C

Protocol Packets Formats

- 143 -

Protocol PacketsFormats

As we saw, for every Network request, there is a packetwith a well specified packet format. Here we will describethe formats of all the packets for all the requests.

First of all,operations (note:exadecimal format).

we must specify the codes describing thefrom now on, all the codes are in

X 40' BIND wait

X 41 Bad Password

X'48 BIND response

X 80' INVITE general broadcast

X ' 40' INVITE single broadcast

X'80' MAIL send

X'00" SEND

X'l0 RECEIVE

X ' 20' BREAK

X'30' TESTLC

X'50' CANCEL

X'58' REJECT

X'70' UNBIND

X'B0' INQUIRE

X'C0' OPEN

X'F0' CLOSE

- 144 -

In the following, there are the messagesexchanged bythe Interface Functions Layer components.

MAIL

+--+----+----+----------------+!LR! RH ! LU ! ORID !+--+----+----+----------------+! DESTID ! BOXLAB !+--+---------+----------------+!TL! TEXT != =

ＫＭＭＭＭＭＭｾＭＭＭＭＭＭＭＭＭＭＭＭＭＭＭＭＭＭＭＭＭＭＫ

where:

LR Last packet received in sequence (1 byte)

RH Request Header (code of the request) (2 bytes)

LU LU Identificator (2 bytes)

ORID Originator identification (8 bytes)

DESTID Destination identification (8 bytes)

BOXLAB Boxlabel name (8 bytes)

TL Text length.

- 145 -

BIND RESPONSE

+--+----+----+--+------+------+!LR! RH !MAXL!MW! OAF! OAF!+--+----+----+--+------+------+!TL! TEXT != =

+-----------------------------+, ,

where:

LR Last packet received in sequence(1 byte)

RH Request Header (operation code) (2 bytes)

MAXL Maximum BIU length (2 bytes)

MAXW Maximum window width (1 byte)

DAF Destination Address Field (3 bytes)

OAF Originator Address Field (3 bytes)

TL Text length (1 byte)

- 146 -

UNBIND

+--+----+------+--+--+!LS! RH ! OAF !LB!LP!+--+----+------+--+--+

where:

LS Last packet received in sequence (1 byte)

RH RequestHeader (operation code) (2 bytes)

OAF Originator Address Field (3 bytes)

LB Last BIU sent (1 byte)

LP Last PIU sent (1 byte)

- 147 -

BIND

+--+----+----+--+-------+!LR! RH !MAXL!MW! LCT!+--+----+----+--+-------+! DESTID ! !+-------+-------+-------+! PASSW! ORID !+-------+-------+-------+!TL! TEXT != =

+-----------------------+where:

LR Last packet Received in sequence(1 byte)

RH RequestHeader (operation code)

MAXL Maximum BID length (2 bytes)

(2 bytes)

MW Window width (1 byte)

LCT Logical Channel Termination id. (3 bytes)

DESTID Destination identification (8 bytes)

PASSW Authorization keyword (8 bytes)

aRID Originator identification (8 bytes)

,TL BIND messagetext length (1 byte)

- 148 -

INVITE

+--+----+----------------+!LR! RH ! aRID !+--+----+-------+--------+! APPLID !+---------------+

where:

LR Last packet received in sequence(1 byte)

RH RequestHeader (operation code) (2 bytes)

aRID Originator ide (8 bytes)

APPLID Application ide (8 bytes)

149 -

STATUS (NSM)

+-----+-----+LS ! ST !

+-----+-----+

where:

LS Last packet received in sequence (1 byte)

ST NSM Restart Number (1 byte)

- 150 -

STATUS (SH)

+--------+--------+--------+--------+--------+--------+----! SHCD ! WLF ! WW ! NER ! PER ! TER !

+--------+--------+--------+--------+--------+--------+----where:

SHCD SessionX' 80'X'40'X'20'X ' 01'

Handler Status MessageStatus messageRequestFor statusInformation MessageReconfigurationFlag

Code:

If the messageis not a status message (X'80'), onlythree fields are used:

SHCD with the meaning describedabove

WLF Last PIU sent

WW Last PIU sent before a reconfiguration.

If the messageis a statusmessage (X'80'):

SHCD Status Message (X'S0 ' )

WLF Dinamic window left edge (1 byte)

WW Dinarnic window width (1 byte)

NER Number of error

PER PIU in error

TER Type of error

- 151 -

REFERENCES--------- ._--

(1) Caneschi F., Ferro E., Lenzini L., Martelli M.,Menchi C., Sommani M., Tarini F. "TheArchitecture and the Service Facilities providedby RPCNET An Italian Computer Network forEducational and Research Institutions", ICCCConferenceKyoto 1978.

(2) Fusi A. Editor: "CNS/VM Computer NetworkSubsystem for VM/370. General Information",RPCNET internal document No. UG019-00 Pisa, May1976.

(3) Gori G. A., Maier M.: "The OS/VS Network Station(CNS-VS) in a RPCNET nodell

, RPCNET internaldocument No. UG010-01 pisa, Jan. 1976.

(4) Guidotti P., Lazzeri L., Lenzini L., MartelliM. : "Network Manager implementation onSystem/7", RPCNET internal dicument No. U1023Pisa Oct. 1975.

( 5) Laz ze r i L. , Len zin i L . , Mar tell i M.: "Aproposal for the introduction of traffic load inNETCHANGE protocol", RPCNET internal documentNo. IG015-00 Pisa Jan 1975.

(6) Springer A., Lazzeri L., Lenzini L.: "Theimplementation of RPCNET on a minicomputer",Computer Communication Review, Cambridge Ma.,Jan 1978.

(7) Tajibnapis W. D.: " The design of a TopologyInformation MaintenanceScheme for a DistributedComputer Network, ACM Conference,S. Diego Ca.,Nov. 1974.