ELEMENTS OF PROTOCOLS

A Tutorial on Protocols

The design of an automobile must take into account a minimum set of basic requirements: wheels, engine, body, steering, brakes, etc. The very same approach applies to protocols. They would be incomplete, or inappropriate unless they properly handled a number of basic functions. This section explains these basic functions, but does not describe any specific protocol.

Naming

Protocols involve communications and thus transfer of information. When a piece of information must be transferred from one domain into another, some un-ambiguous indication of the destination must be specified. In most circumstances, the sender does not perform the physical transfer of information by itself.

Typically, the sender invokes some common under-lying mechanism along with a set of parameters, including names or addresses, e.g., MOVE (data) FROM (A) TO (B).

.£' 1979 DATAPRO RESEARCH CORPORATION. DELRAN, NJ 08075 USA

REPRODUCT!O~-l PROH!8iTED

JULY 1979

A Tutorial on Protocols In homogeneous systems, names such as A or B

designate well-defined entities, e.g, core locations, files, processes physical or logical devices. Computer systems make use of various naming schemes, de-pending on the type of resource to which names are attached. Names may be of fixed or variable length, and follow specific conventions: alphabetic, numeric, special characters, and so on. Changing naming conventions in existing systems is an in-superable task because the conventions are usually so ingrained in the design that any change causes a major upheaval.

Thus networks of heterogeneous systems bring about new problems, as there is typically no commonly agreed naming scheme. A usual approach in such a situation is to superimpose a new network-wide scheme, while keeping existing ones inside each sys-tem. For example, telephone numbers are super-imposed on persons or companies names. We shall see now how these common names can be created.

For convenience, we shall refer to names which exist in each computer system as local names. Network-wide names will be called C-names (for common names). There are a number of ways to construct C-names and relate them to local names. Three most frequent methods are discussed below: hierarchical concatenation, allocation, and mapping.

Hierarchical Concatenation: We imagine that each computer system has a set of local names { Lj}. To each set is assigned a unique C-name, ~C~. The C-names, obviously must be assigned by global agree-ment to preserve their uniqueness. It is not ruled out that more than one C-name is assigned to a set { Li }of local names, but the same C-name would not be assigned to two different local name sets because of the potential ambiguities this would introduce. The network name space is obtained by concatenating local names with a C-name, i.e., { < Ci XL>}.

For example:

Local names in system

x:

JOHN.FILE3.TEXT TOM.LETTERS.MARY Local names in system Y:

SYS COBOL BIN LINK.3 FACTORY PARTS Local names in system Z:

53409 42121

The corresponding C -names might be X TOM.LEITERS.MARY

X JOHN.FILE3.TEXT Y SYS COBOL BIN LINK.3 Y FACTORY PARTS Z 53409

Z 42121

This scheme is similar to the international telephone numbering plan in which phone numbers are obtained by concatenation of a country number with an internally assigned national number.

Allocation: A second method is to permanently allocate C-names to only a few processes, for example, the "logger" process in time-sharing systems which validates remote user access to the system.

Another set of C-names is allocated to each local system for dynamic association with local processes.

At least one process in each local computer system is assigned a permanent C-name and the responsibility for dynamically assigning the others allocated to the system.

For example, suppose that C-names are simply inte-gers in the range of 1 to 9999. Let us further assume that system A has been assigned C-names 6100-6199 for its use and system B has been assigned 4300-4399. Let us further suppose that there is a network access process at system B whose permanent C-name is 4301. Finally, let a process in system A, with C-name 6192 attempt to access a process in system B whose local name in system B is ZOOM (see Figure 1).

r~91.(~S~ ZOOM

.. ---...

• 192

a;.. _ ... _ .... __ ~·.-_~1

~Jloc~t~ 4327 : ••••

&191 0-- - -

'-,xch~;.g."-···~3i;·-·-J:)

: ,,0

reluse 4317 : ""

G192

0--- --

---..cr4~Ol

Figure 1. Allocation

Process 6192 would send a request to access local process ZOOM to the network access process in system B whose C-name is 4301. The network access process locates or creates process ZOOM within system B and allocates an unused C-name for it, say,

""""'''"1 ___ 1 ____ ..1_ _ _ _ _ 1 __ ... _ _ ______ L to"l ••• L:_L 'f.JL.I, anu st::uus d !t;}Hy LV plVU:;~~ V17~ Wll1\,,1l

associates C-name 4327 with local process ZOOM.

Thereafter, process 6192 exchanges information with process 4327 until such exchanges are no longer necessary, at which time process 6192 reports to the network access process at system B that the C-name

Protocols

A Tutorial on Protocols 4327 can be freed again. Alternatively, the ZOOM

process could make this last report.

Plainly, the originating process (6192) needed a con-siderable amount of external knowledge to conduct this exchange. It needed to know that there was a network access process at system B and that its C-name was 430 I. It also needed to know the local name, ZOOM, at the process it wanted to com-municate with.

This strategy is closely related to the method used in the ARPANET initial connection protocol ^31,61 associated with the network control protocol (together they constitute the ARPANET transport protocol layer).

Mapping: An alternative to concatenation is to create a set of C-names

{C}

and statically assign them among all the processes, files, and other local entities which must be accessed on a network-wide basis (see Figure 2). The C-names assigned are mapped by each local system into the associated local name. The relationship between local and global naming mech-anisms is discussed further in this section. This strategy is used in the Cyclades network.⁶⁵

SYSTEM A SVSTE.M &

to ]."Ny--B---!~ _4~:~:~ --- 8--- ^-.'8'

t ;

... a~p\ng lTIa~pinf"

Local narn~ _ C-nalTtl!'

Figure 2. Mapping

Other strategies besides concatenation, allocation, and mapping are possible. Indeed, network designers have tended to invent ad hoc strategies that suit their implementation constraints rather than developing network naming techniques for every general use.

Discussion: Among the three methods described above, the hierarchical concatenation method is ap-parently the simplest one because a C-name may be parsed easily into a system name and local name, but it is only practical when local names are rather homogeneous. Otherwise, C-names take so many dif-ferent formats that protocols become unwieldy and inefficient. In particular, the introduction of a new set of local names may require modifications in a number of existing network access protocols when the characteristics of the new set have not been antici-pated.

The allocation method is favored by a number of operating system-minded people. It has the advantage of fitting within conventional single computer struc-tures. Most operating systems in use over the past ten years were designed as geocentric objects cen-tralizing all critical functions. Accessing entities is usually a multistep procedure beginning with a well-known log-in procedure. This vision of a rigidly partitioned universe is still taken for granted by a number of computer professionals.

An advantage of the allocation method is that users can access other computer systems almost as if there were no network. It is also contended that using a small number of C-names, for active entities only, saves overhead in network access machinery.

The deficiencies of this method are apparent from its advantages. Entities must be rigidly associated with specific computer systems and this puts a straitjacket on users who might prefer instead homogeneous access to all resources, with computer system boun-daries fading out. In other words, the proper vision is a network resources rather than a network of computers. In addition, the allocation method is more complex in implementation as it requires the manage-ment of changing associations between C-names and local entities. Indeed, it implies a dynamic modi~

fication of the structure of the naming mechanism.

Due to transit delays and fuzzy states associated with any distributed system, there appear transient conditions which require specific safeguards to prevent errors; e.g., a C-name may be accidentally released on one end and reassigned without the other cor-respondent being aware of this event. The elimination of inconsistent states takes additional mechanisms and delays the allocation of C-names.

The mapping method provides for a homogeneous name space for accessing any network entity. It is similar to a national telephone numbering plan.

Mapping C-names onto local names is a matter of local implementation. This allows both permanent and temporary associations between entities. This method is therefore more general than the allocation method, which provides only temporary associations.

Any desirable access control procedure can be trig-gered as part of the mapping machinery, depending on accessed entities or their correspondents.

Such a facility makes it possible to offer homo-geneous network-wide access protocols for specific services, which may be available on different com-puters, e.g., compilers, text editors, help, distributed data bases. This flexibility results from the ability to design and implement specific access protocols inde-pendently from the others, because they are attached to well-defined entities. I n principle, the allocation

r~: 1979 DATAPRO RESEARCH CORPORATiON, DELRAN, NJ 08075 USA REpnODUCT;Ot~ PROH;SfTED

JULY 1979

A Tutorial on Protocols method could offer an equivalent facility, but in

practice the logger machinery is too sensitive software to be frequently adapted to new classes of users.

A criticism of the mapping method is that it takes overhead in scanning large tables of C-names when they are permanently associated with local names.

However, this objection is not well substantiated.

Indeed, a search is always necessary whether the key is a C-name or a local name, and there is no reason why searching by C-names should be less efficient.

Space occupied by the C-name table is not critical, as it can be on secondary storage, like any file directory.

A few examples of the flexibility inherent in the mapping method are as follows.

• Users may choose local names according to their own symbolism, e.g., in their native tongue.

• Several local names may map into a single C-name, for the convenience of using at will ab-breviated or full local names.

• Since local names do not have to be known remotely, there cannot occur any ambiguity when identical local names are used by several computer systems.

• A resource may be moved to a different computer system without its users knowing it. Actually, this capability is truly effective only when the trans-mission system can use C-names as message des-tinations. Examples of such networks are CIGALE, DCS, and ETHERNET. 66, 29, ⁵⁸

Group Names: When the total space of network names becomes very large, C-names may become very long and may generate overhead or inconvenience. A countermeasure is to partition the name-space into a hierarchy of subsets designated by group names. 66 Communications taking place between correspon-dents belonging to the same group require only short names. Communications crossing group boundaries require full length names. Thus there are two or more C-name formats, depending on the number of partition levels crossed by communications. This is similar to telephone dialing for local and long distance calls. However, the analogy is only partial, because a group does not carry any geographicai connotation, as opposed to an area in the telephone system.

Entities of a single group may be geographically scattered throughout. On the other hand, it is ob-viously possible to define certain groups as having geographical boundaries, but not necessarily restricted to a single piece of land.

For this technique to be effective, there must exist natural clusters of correspondents establishing a signi,;.

ficant proportion of mutual exchanges. This is almost always the case when data communication is directly related to human users who are naturally clustered geographically (urban areas) or within a business structure (corporation, institution, affiliation).

Some refined techniques may be used for partitioning the network name space so that short names be also usable to communicate with neighbor groups.69 When groups are not geographical, the notion of neighbor-hood has to be defined within some space, e.g., the space of integers representing C-names.

Port Names: When two entities communicate, they exchange information in the form of messages, fol-lowing the rules of a certain protocol. It might appear sufficient that messages contain some destina-tion field designating unambiguously the receiving entity. Thence, the name of the receiving entity could be used in the destination field of a message. How-ever, this technique is not generally applied for the following reasons.

• Since computer systems are mainly heterogeneous, protocols are designed so as to make a minimum of assumptions about the characteristics of the communicating entities and of their environment.

In particular, they tend to use names which are independent of any entity.

• Information exchanged between two entities may pertain to several independent channels (or associa-tions).

Consequently, the notion of port name is com-monly used as a substitute for entity names. Port names present the following characteristics:

• They constitute a homogeneous network-wide name space. Therefore, they are C-names by definition.

• They are defined independently of any entity, but they may be assigned to anyone.

In the naming techniques presented earlier (allocation and mapping) C-names are in effect port names. A port name may be allocated temporarily to an entity in the allocation method, or permanently in the mapping method.

Communications protocols are then defined as op-erating from port to port. Each port to port association constitutes an independent information channel. An entity may use several port names in order to maintain simultaneously several independent channels with another entity.

Protocols

A Tutorial on Protocols Port n~~es may b~ cr~ated and distributed randomly

to entitles of a dIstnbuted system, but a possibly time-consuming table search would then be necessary to locate them. Customarily, some simple algorithm is used t~ relate p~rt na~e and computer system, e.g., contIguous senes of Integers are allocated to each system, or a port name is formed by concatena-tion of a computer system C-name and a local integer.

Many variants are acceptable, as long as resulting port names are homogeneous.

Associ(~.tion Names: When two entities exchange in-formatIOn, they make up an association. In some systems, any two entities may exchange information at any time without prior arrangement, e.g., the public m~il, or a message switching system. Actually, If traffic IS observed from the point of view of an end user, information exchanged is usually associated with an existing relationship which may be temporary or permanent, e.g., a business connection a com-plaint, an acquaintance. In order to interPret cor-rectly the arriving information, it is necessary to relate it to some other information kept into the receiver's memory. This information already in store is called a context. It may contain such items as the number of the last message correctly received, the number of errors encountered, the address of a buffer for the next message, etc. The context contents are specific to the communication protocol in effect between the corresponding entities.

Relating an arriving message to the appropriate context requires that some item of information con-tained in the message designate this context un-ambiguously. Such an information is called a context

ide~tifier. We will examine in the following some typical methods for choosing context identifiers. There are two cases.

1. ~I1t~tie~ ~nnote"est~?!~s.h. (!.nqope~'!t~~Qlqre than .qne a~sQclatlon ,3;t

"a:-

time. (Figyre."J). In this

-case:

there IS not really a need for a context identifier because the entity can easily locate its only existing context, if anv. However, in the absence of context identifier, any arriving message would be deemed related to the only existing association. Spurious messages might cause disruption. In order to tell valid m~ssages from others, the protocol1iseo

witb

the association . should include errorc.ontrol. Schemes ':stlch as c~rrying a password within each message, or encryptIng messages may be used as a form of error control.

2. Entities may establish and operate mUltiple con-current associations (Figure 4). In this case, messages must carry contexts identifier. Identification can be exchanged between entities when they set up an association. This is similar to the business practice of using file numbers to reference letters. It does not

matter whether an entity uses its own or its cor-respondent's identifier when it sends a message, as long as this convention is defined by the protocol used

~ith the association (Figure 5). An entity engaging simultaneously in several associations is in effect multiplexed. Logically this entity becomes visible as a set of independent instances. Thus context identifiers are extensions to the name of an entity for multi-plexing purposes. For example, Figure 5, entities 3612 and 4230 have set up an association. The association context identifier in entity 3612 is 11.

Thus messages sent by entity 4230 should carry 11 as context identifier. To that effect, the association context in entity 4230 contains 3612-11, i.e., the assigned by either entity.

Context identifiers can be assigned in the same way as C-names. For ~ simplicity, such identifiers may be integers which are assigned in monotonically in-creasing order. If the maximum value of the context

Figure 3. Single association

ContelCts Entity Associ~tions

§ ---[)--- -~.:.::.·-·-·-·--1-·

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

2 - -. . - --- .-" __ <~~~~~~~~-_~2.-.·.·.~~·

3 .. ---.--~-.- <':::~~~~.-.'.-~~~~~

Figure 4. Multiple association

4230 , Figure 5. Context identifiers

6185 '15

A Tutorial on Protocols identifier is large enough compared to the lifetime of

associations and the rate at which associations are created it should never happen that a new identifier is

assi~ed

while the same value is still

as~igned

^to

an existing association context. However, thIS cannot always be guaranteed.

On the other hand, context identifiers might be assigned, released, and reused dynamically, but since these identifiers are shared by two processes, there may be a risk of transient conditions in whi~h the interpretation of identifiers might become ambIguous (e.g., the crash of one compu~er syste~ may. cau~e

it to lose all knowledge of prevIously assIgned IdentI-fiers). The same problem can occur with the dynamic allocation of C-names.

In a distributed system, any dynamic allocation scheme comes with additional complexity and poten-tial for trouble. The complexity results from the need to synchronize allocation or release. T?~ po-tential for trouble derives ftom' the vulnerabIlIty to crashes or erratic working in which the current allocation status may be corrupted. Due to the technical realities, static allocation schemes offer simpler and more robust solutions.

Assuming that entities are ':lllocated C-names. in. a reliable way (e.g., by mappmg), one can .capIt.ahze on this by using C-names as. ~onte~t IdentI~ers

(Figure 6). Since there is

I!0

.additIOnal mfOrma~I?n,

there can only be one aSSOCiatIOn between two entItIes, however, a single entity may still .set up. multil?le associations with other distinct entitIes. ThIS restnc-tion is not as effective as it might appear. Indeed, the real limitation is only one association for a pair of C-names. Since port names act as substitutes for entities in communication protocols, one may allocate·

to an entity as many ports as it need~ for setting up parallel associations with another en~Ity. The ~ead~r

Im Dokument COMMUNICATIONS SOLUTIONS (Seite 117-142)

ELEMENTS OF PROTOCOLS

A Tutorial on Protocols