A Tutorial on Protocols
PROTOCOL OVERVIEW Basic Protocol Functions
In the first subsection, we introduced the intuitive
not~o~ . of a protocol and provided a simple working defimtIOn. To the newcomer, it is necessary to understand intuitively the ingredients which comprise a protocol in order to acquire a general mental model
of
~ts structure and its raison d' etre. We proceed by gIvmg an analogy with the interaction between organizatiops in a b~siness context. Admittedly, this analogy wIll only gIVe a macroscopic view of the~ature of protocols. Terms and concepts are used and llltended to be understood generally without the need for introducing very precise definitions at this point.
We have made obvious approximations and omissions for the sake of achieving clarity in presentation.
Let us assume that two corporations, SIXOUNS and SNAPSE, are considering some joint business. They both produce whisky (of course). One of the two presidents will presumably invite his colleague for lunch (no martinis, please), and agree upon a business strategy. They will then turn the matter over to their marketing vice-presidents who will arrange a meeting.
Later on, plant managers may get together, etc. For our model, we assume regular discussions take place between opposite numbers, i.e., between people at the same level (or layer) in the corporate hierarchy.
However, these discussions are highly informal and also time-consuming during the initial stages. Since the strategy is now shaping up, SIXOUNS and SNAPSE feel that they should streamline their
interact.ion~ .. To that effect, they design procedures for mallltalllmg a mutual exchange of information between the various participants, without the need for actually meeting. These procedures might include such elements as rules, message or document formats, frequency of interaction, etc., which are established by a particular layer of the corporate hierarchy. They constitute the protocol to be used by that layer.
SIXOUNS and SNAPSE have created a common distillery. Each corporation uses its own network of retail stores to market its own brand. Orders are collected separately by SIXOUNS and SNAPSE, and transmitted to the distillery. On the other hand,
:~\ 1979 DATAPRO RESEARCH CORPORATION. DELRAN. NJ 08075 USA REPRODUCT!ON PROHIB!TED
JULY 1979
A Tutorial on Protocols deliveries are carried directly from the distillery to the
retailers. Occasional mixups may happen, such as delivering a SNAPSE whisky, instead of a SIX-OUNS, or miscounting the number of bottles, or dropping a carton of whisky on the floor with shattering consequences. In order to prevent disputes from arising, each corporation acknowledges each order received from its retailers, and retailers have to sign delivery vouchers. Thus, discrepancies may be traced back to their origin and corrected. We may say that order and delivery protocols include error control.
The volume of orders may at times vary substantially.
This fluctuation causes inefficient operation for the distillery because its production capability is limited.
Sometimes, orders must be delayed because of overload, while at other times there is unused distillery capacity. Thus, it was decided that SIXOUNS and SNAPSE should place production orders by anticipation, in order to regulate the amount of whisky produced. Of course, some care must be exercised, since the distillery has also a limited space for inventory. This tricky balance is a matter of flow control.
Even though considerable care is taken in handling properly the orders, deliveries and inventory, some errors may slip through, due possibly to human factors. An occasional discrepancy is acceptable so long as it has no cumulative effect. To prevent that, the books are balanced once a month, at which time all figures must be reconciled. This accounting is not completely straightforward, as there are orders or acknowledgements in the mail, and filled trucks on the road. In fact, it is not possible for all accounts to be settled simultaneously and, as a result, there is a need for a specific set of accounting rules so that all outstanding orders, deliveries, and production be clearly accounted for each month. This protocol may be called synchronization.
Another requirement always appears whenever an exchange of information is to occur, viz, providing the address of the intended recipient. In the whisky business, an order may be sent by mail to the following address:
SIXOUNS Corp.
Order Dept.
4/5 Bourbon St.
DOWN HATCH 70127 YU Or the retailer may dial 435-2217, ask for extension 652, and say: Hello Sally ... This is Louis. I would like . . . etc. Or he may send a TWX message, or something else. In these examples, the composite address is actuallv a concatenation of several address elements. Some ~lements are meaningful to the Post
Office or the public telephone system. Other elements are only meaningful within the SIXOUNS corpora-tion. The retailer must learn them beforehand.
A different example illustrates another addressing possibility. A friend of mine happens to be in town and has previously advised me that he will be staying at the DALTON hotel. (Of course, he had to know me and my address). How can I send him a message?
I may call the DALTON, and leave a message for Mr. Jim DOLITTLE with the operator. I could also ask the hotel operator for my friend's room number, and the next time I may just leave a message for room 625. Now, there could be more than one Jim DOLITTLE in the DALTON, or he may have moved to a different room, or checked out. If I really want to be sure that my message gets to the right person, I have to check further.
Things would be simpler if every person in the whole world had one portable telephone (or TWX) number which only he can use. When it answers, then we know the right person is at the other end.
The previous examples illustrate three typical methods used for conveying information to its destination. The first example corresponds to a hierarchical addressing strategy, the second example denotes a method based on dynamic allocation of temporary names, and the third example illustrates mapping. In the protocol jargon we often use the term naming to designate methods of composing addresses and selecting a proper correspondent. Each of the above three naming approaches, namely hierarchy, allocation and mapping will be discussed in the second section along with the other key ele-ments of protocols, namely, error control, flow con-trol and synchronization.
Distributed Systems
So far, our examples have been taken from a common business setting without any reference to computer systems. In fact, there are definite similarities between the function~l o:ganizati~n of a computer system and an orgamzatIOn. A pIece of software, often called an executive, allocates system resources (memory, files, channels, processor time, etc.) to subsystems (or programs) in charge of specific services. In turn, these sub-systems allocate their own resources, and control the execution of their tasks, and so on. There is some difference, however. When drawing a corporation chart, the president is normally placed at the top. When drawing a computer system functional diagram, the executive is normally at the bottom, but this is immaterial for our purposes.
JULY 1979 © 1979 DAT.A.PRO RESEARCH CORPORATION, DELR.AN, NJ 08075 USA REPRODUCTION PROHIBITED
Protocols
A Tutorial on Protocols When two or more computer systems are
intercon-nected for a common purpose, they are said to make up a distributed system. As we have seen .a~r~ady ?y analogy, cooperation ~etween these entItles WIll normally be formalized mto a number of protocols
interaction protocols by fl!n~tionallay~rs (market.mg, production, etc.). ?stabhshmg ~ busmess relatIOn-ship between a whIsky corporatlon and a corn farm would require a different model, because these two organizations exhibit totally different structures.
Perhaps the most sensible solution would be a
Even though most computer systems .ar~ .structur~d
along similar lines, there are a multIplIcIty of dIf-ferences between systems from various turers. It is also common that a single manufac-turer produces several famili~s of computer syste~s,
with distinctive structural dIfferences. In thls case, computer systems are terJ?ed heterogeneous.
Nevertheless, it is usually possIble to work out some sensible interconnection scheme between any two computer systems.17 One must decide how layers of each system are to be paired, and what protocols are to be used.
The development of an inte~co.nnecti?n scheme between computers is often a sIgmficant .mvestment, as it requires skilled computer professIOnals who know the intricacies of both systems. On the other hand, if most computer systems w?u!d contain v~ry
similar or even identical layers, theIr mterconnectIOn could become a simple routine task. This. is the ca~e with computer systems of the same famIly. In thIS case they are termed homogeneous.
Many technical problems en~ountered i~ building distributed systems would dIsappear wI~h homo-geneous computer systems. But homogeneIty cann?t be a general solution. We can expect that there wIll always be a variety of suppliers. Even with a sing.le supplier computer systems evolve, due to changes m technology and in user needs. On the other hand, as we have mentioned earlier, heterogeneity may introduce technical incompatibilities and require ad hoc adaptations. Is this dilem~a ~rreconcilable?
Experimental developments of dIstrIbuted syste~s
have led to a middle of the road approach, whIch
aims to take full account of heterogeneity in the real world, while making interconnection more or less straightforward. This approach is presented below.
We call it a reference architecture.
Reference Architecture
Let us assume we want to connect a cassette recorder and a radio set of arbitrary makes. We may study the electrical diagrams of both devices, and try to determine appropriate points where we ~ight plan an electrical coupling, so that sounds receIved by the radio set become recorded on a cassette tape. It may be a little difficult to locate these appropriate coupling points, if th.e diagrams are n?t well-documented. Electrical sIgnals may also reqUIre some adjustment to be performed by an .intermediate black box, which we would have to buIld. Then, we may connect external wires with a soldering iron. If things do not work satisfactorily, we will need metering instruments and possibly some professional advice.
Interconnecting a cassette recorder and a radio set becomes much easier if both manufacturers have anticipated the need, and install~d s~me pluggin.g socket carrying well-defined electrIcal SIgnals. In thIS case, we do not have to study the inner workings of a whole device. We only have to understand how to use the pins of the socket. These pins are th.e. ~l!ly peepholes into the device. We call them VISIbIlIty points.
Computer systems are more complex than cassette recorders. Thus, interconnecting them requires more than the definition of a simple socket. As we mentioned earlier, computer systems are layered structures. Interconnecting layers requires the definition of protocols, which are the set of rules followed within each layer by the interactions between interconnected systems. Furthermore, protocol definitions assume some interactions between layers within each computer system. For example, in the SIXOUNS-SNAP?E agreement described earlier, protocols establIshed for the marketing layer and the production layer assume some interactions between marketing and production within SIXOUNS and SNAPSE. We call an interface the set of rules followed by the interactions between two layers within a single computer system.
Once interfaces and protocols are defined between interconnected systems, they may work in coopera-tion to achieve a common purpose. They become a distributed system. If there exists a common set ?f definitions of all interfaces and protocols used m distributed systems, it is no longer necessary to study the inner workings of each system. Interfaces and protocols are analogous to sockets in the connection
@ 1979 DATAPRO RESEARCH CORPORATION. DELRAN, NJ 08075 USA REPRODUCTION PROHIBITED
JULY 1979
A Tutorial on Protocols of a cassette recorder and a radio set. They make
interconnection much easier.
If the construction of distributed systems required that all interconnected systems follow rigidly a precise model defining systems in their entirety, then distributed systems would only comprise computer systems of the same family. Indeed, not many manufacturers, if any, would accept being con-strained to such an extent in the design of their own products. But if the constraints are limited to interfaces and protocols necessary for building a model distributed system, it may become com-mercially attractive for many manufacturers to accept these constraints as the counterpart of a wider market. For easy reference to the set of interfaces and protocols of a distributed system model, we introduce the term reference architecture. Then, we may say that a system conforms to the reference architecture when it contains the visibility points of the distributed system model, i.e., the interfaces and protocols necessary for interconnection.
Basic Protocols Layers
Most business organizations are structured along similar lines. Below the president, one can find a number of departments: finance, marketing, pro-duction, purchasing, etc. There is no proof that this structure is the best, but in practice it seems to be satisfactory. The same rationale applies to layers of a distributed system. Even though the choice of appropriate protocol layers is not yet supported by a rigorous demonstration, a certain consensus has emerged from experience. The basic protocol layers consist of transmission, end to end transport, and application oriented functions. Among the latter, the virtual terminal and file transfer protocols are the most commonly used.
The tranmission layer includes functions pertaining to the transfer of data between geographically distinct locations. In the example of the whisky business, transmission is analogous to the transportation of whisky botties. Whether transportation is carried out by truck, train, or helicopter, is immaterial, as long as whisky is delivered as ordered. Similarly, whether data are carried through wires, microwaves, or satellites is immaterial, as long as they are delivered without alteration at the proper destinations. New transmission techniques such as packet switching require some specific packaging of the data. This packaging is analogous to the practice of putting goods into containers for shipping. The transmission protocol consists of using properly any available transmission system.
The end to end transport layer (or transport for short) is in charge of checking the integrity of the transmission layer. Indeed, no transmission system is totally reliable, and some are far less than perfect.
When data must travel through more than one transmission system (e.g., for international traffic), it is not unusual that each public carrier will blame the other in case of trouble. Thus, the transport protocol includes error control for assuring that data are delivered correctly, or else for having them corrected or retransmitted. In addition, the transport layer acts as a transportation bureau for the benefit of application layers.
It receives transport requests from other layers and makes the best use of available transmission systems.
A similar function is carried out in the distillery.
Packages for the retailers are prepared for shipment, but they are not delivered separately. Indeed, several packages may be destined to the same retailer, and delivery trucks follow established routes. Thus packages must be assigned to some trucks, depending on their route and their available capacity. The set of mechanisms carrying out the transport protocol in a distributed system is called a transport station .
... ~-~ ... \
Y
he virtual terminal layer performs various adapta-I
ions between the characteristics of physical terminals r
nd application prowamsJTnoeeo;reaT1ermm.aIS available on the market"" may use different codes, keyboards, formats, etc. and new varieties of terminals are popping up constantly. Thus it is practically impossible for every application program to work properly with any terminal. For example, let us assume that an application program outputs series of lines having a length of 120 characters. Each character is binary coded in the specific code used by the computer, say EBCDIC. How can we use a display terminal working with ASCII coded characters and having a width of 80 character positions? We may define some adaptation rules:
• Translation of EBCDIC characters into ASCII characters
• Reformatting 120-character lines into 80-character lines.
There is no universal solution for shrinking lines. A first option is to select a subset of 80 positions out of 120. Some fields will be truncated, but this may be acceptable if they contain redundant informa-tion. A second option is to fold lines, i.e. each output line will be displayed as an 80-character line followed by a 40-character line. This presentation may be acceptable for program listings. A third option is to use 3 lines on the display for 2 output lines. This is acceptable for plain text.
JULY 1979 © 1979 DATAPRO RESEARCH CORPORATION, DELRAN. NJ 08075 USA REPRODUCTION PROHIBITED
Protocols
A Tutorial on Protocols Assuming that we can select the most suitable
adaptation the application program works as if it were in communication with a 120-character wide EBCDIC terminal, which is not really there. This is why we call it a virtual terminal.
Actually, a virtual terminal does not have to be identical with an existing real terminal. Rather, it is a model of an ideal terminal with enough adjustable parameters so that it can look like a large number of real terminals. The virtual terminal protocol is ~
~t of rules for setting the parameters and exchanging
~ta with a virtual terminal.
The file-transfer layer is in charge of moving or copying files across computer systems. Ideally, in a distributed system, the location of a file should be immaterial. In practice, it is not so, for a number of reasons such as the following. Access is faster when file and application program are located in the same computer system. Storage costs may vary with systems. Security may not be good enough on certain systems. Thus, file transfer is frequently used in distributed systems. The file transfer protocol includes rules for opening and closing sender and receiver files, for data transfer, and for error recovery. If data translation is required, it may be performed by a specific user-provided routine, or it may be invoked as a protocol option.
In the above, we have introduced an intuitive presentation of the basic protocol layers of a distributed system. At this point, we would like to warn the reader that there is so far no universal agreement about the names and the number of layers. There is some analogy with geology. Where some people would identify only a sand layer, others would find a sand layer, a gravel layer, and a thin clay layer. No one is wrong, it is just a matter of defining sand.
Concepts in Distributed Systems
Some basic protocol concepts, such as error control, synchronization, etc., have been introduced informal-ly earlier in this section. We shall have occasion to draw upon a few more conceptual terms in the body of this article. Thus, a short presentation, without rigorous definition, is included below to convey a sufficient understanding of these additional concepts, before proceeding to the next sections.
Process: A program running on a computer. It could be microcode running on a microprocessor or conventional software running on a mainframe processor. The term is most frequently used to distinguish among several running programs in time-sharing systems.
Resource: When a program is executed on a computer, it needs some area of memory, some processor time, and usually access to some
Resource: When a program is executed on a computer, it needs some area of memory, some processor time, and usually access to some