Protocol and Protocol architecture

Protocol and Protocol architecture

When computers, terminals, and/or other data processing devices exchange data,

the scope of concern is much broader than the concerns we have discussed in Sections

1.2 and 1.3. Consider, for example, the transfer of a file between two computers.

There must be a data path between the two computers, either directly or via a

communication network. But more is needed. Typical tasks to be performed are

1. The source system must either activate the direct data communication path or

inform the communication network of the identity of the desired destination

system.

2. The source system must ascertain that the destination system is prepared to

receive data.

3. The file transfer application on the source system must ascertain that the file

management program on the destination system is prepared to accept and

store the file for this particular user.

4. If the file formats used on the two systems are incompatible, one or the other

system must perform a format translation function.

It is clear that there must be a high degree of cooperation between the two

computer systems. The exchange of information between computers for the purpose

of cooperative action is generally referred to as computer communications.

Similarly, when two or more computers are interconnected via a communication

network, the set of computer stations is referred to as a computer network. Because

a similar level of cooperation is required between a user at a terminal and one at a

computer, these terms are often used when some of the communicating entities are

terminals.

In discussing computer communications and computer networks, two concepts

are paramount:

Protocols

Computer-communications architecture, or protocol architecture

A protocol is used for communication between entities in different systems.

The terms "entity" and "system" are used in a very general sense. Examples of entities are user application programs, file transfer packages, data-base management

systems, electronic mail facilities, and terminals. Examples of systems are

computers, terminals, and remote sensors. Note that in some cases the entity and

the system in which it resides are coextensive (e.g., terminals). In general, an entity

is anything capable of sending or receiving information, and a system is a physically

distinct object that contains one or more entities. For two entities to communicate

successfully, they must "speak the same language." What is communicated, how it

is communicated, and when it is communicated must conform to some mutually

acceptable conventions between the entities involved. The conventions are referred

to as a protocol, which may be defined as a set of rules governing the exchange of

data between two entities. The key elements of a protocol are

0 Syntax. Includes such things as data format and signal levels.

Semantics. Includes control information for coordination and error handling.

Timing. Includes speed matching and sequencing.

Having introduced the concept of a protocol, we can now introduce the concept

of a protocol architecture. It is clear that there must be a high degree of cooperation

between the two computers. Instead of implementing the logic for this as a

single module, the task is broken up into subtasks, each of which is implemented

separately. As an example, Figure 1.4 suggests the way in which a file transfer facility

could be implemented. Three modules are used. Tasks 3 and 4 in the preceding

list could be performed by a file transfer module. The two modules on the two systems

exchange files and commands. However, rather than requiring the file transfer

module to handle the details of actually transferring data and commands, the file

transfer modules each rely on a communications service module. This module is

responsible for making sure that the file transfer commands and data are reliably

exchanged between systems. Among other things, this module would perform task

2. Now, the nature of the exchange between systems is independent of the nature of

the network that interconnects them. Therefore, rather than building details of the

network interface into the communications service module, it makes sense to have

a third module, a network access module, that performs task 1 by interacting with

the network.

Let us try to summarize the motivation for the three modules in Figure 1.4.

The file transfer module contains all of the logic that is unique to the file transfer

application, such as transmitting passwords, file commands, and file records. There

is a need to transmit these files and commands reliably. However, the same sorts of

reliability requirements are relevant to a variety of applications ( e g , electronic

mail, document transfer). Therefore, these requirements are met by a separate communications

service module that can be used by a variety of applications. The communications

service module is concerned with assuring that the two computer systems

are active and ready for data transfer and for keeping track of the data that are

being exchanged to assure delivery. However, these tasks are independent of the

type of network that is being used. Therefore, the logic for actually dealing with the

network is separated out into a separate network access module. That way, if the

network to be used is changed, only the network access module is affected.

Thus, instead of a single module for performing communications, there is a

structured set of modules that implements the communications function. That structure

is referred to as a protocol architecture. In the remainder of this section, we

generalize the preceding example to present a simplified protocol architecture. Following

that, we look at more complex, real-world examples: TCPIIP and OSI.

A Three-Layer Model

In very general terms, communications can be said to involve three agents: applications,

computers, and networks. One example of an application is a file transfer

operation. These applications execute on computers that can often support multiple

simultaneous applications. Computers are connected to networks, and the data to

be exchanged are transferred by the network from one computer to another. Thus,

the transfer of data from one application to another involves first getting the data

to the computer in which the application resides and then getting it to the intended

application within the computer.

With these concepts in mind, it appears natural to organize the communication

task into three relatively independent layers:

Network access layer

Transport layer

Application layer

The network access layer is concerned with the exchange of data between a

computer and the network to which it is attached. The sending computer must provide

the network with the address of the destination computer, so that the network

may route the data to the appropriate destination. The sending computer may wish

to invoke certain services, such as priority, that might be provided by the network.

The specific software used at this layer depends on the type of network to be used;

different standards have been developed for circuit switching, packet switching,

local area networks, and others. Thus, it makes sense to separate those functions

having to do with network access into a separate layer. By doing this, the remainder

of the communications software, above the network access layer, need not be concerned

with the specifics of the network to be used. The same higher-layer software

should function properly regardless of the particular network to which the

computer is attached.

Regardless of the nature of the applications that are exchanging data, there is

usually a requirement that data be exchanged reliably. That is, we would like to be

assured that all of the data arrive at the destination application and that the data

arrive in the same order in which they were sent. As we shall see, the mechanisms

for providing reliability are essentially independent of the nature of the applications.

Thus, it makes sense to collect those mechanisms in a common layer shared

by all applications; this is referred to as the transport layer.

Finally, the application layer contains the logic needed to support the various

user applications. For each different type of application, such as file transfer, a separate

module is needed that is peculiar to that application.

Figures 1.5 and 1.6 illustrate this simple architecture. Figure 1.5 shows three

computers connected to a network. Each computer contains software at the network

access and transport layers and software at the application layer for one or

more applications. For successful communication, every entity in the overall system

must have a unique address. Actually, two levels of addressing are needed. Each

computer on the network must have a unique network address; this allows the network

to deliver data to the proper computer. Each application on a computer must

have an address that is unique within that computer; this allows the transport layer

to support multiple applications at each computer. These latter addresses are

 

known as service access points (SAPS), connoting that each application is individually

accessing the services of the transport layer.

Figure 1.6 indicates the way in which modules at the same level on different

computers communicate with each other: by means of a protocol. A protocol is the

set of rules or conventions governing the ways in which two entities cooperate to

exchange data. A protocol specification details the control functions that may be

performed, the formats and control codes used to communicate those functions,

and the procedures that the two entities must follow.

Let us trace a simple operation. Suppose that an application, associated with

SAP 1 at computer A, wishes to send a message to another application, associated

with SAP 2 at computer B. The application at A hands the message over to its transport

layer with instructions to send it to SAP 2 on computer B. The transport layer

hands the message over to the network access layer, which instructs the network to

send the message to computer B. Note that the network need not be told the identity

of the destination service access point. All that it needs to know is that the data

are intended for computer B.

To control this operation, control information, as well as user data, must be

transmitted, as suggested in Figure 1.7. Let us say that the sending application generates

a block of data and passes this to the transport layer. The transport layer may

break this block into two smaller pieces to make it more manageable. To each of

these pieces the transport layer appends a transport header, containing protocol

control information. The combination of data from the next higher layer and control

information is known as a protocol data unit (PDU); in this case, it is referred

to as a transport protocol data unit. The header in each transport PDU contains

control information to be used by the peer transport protocol at computer B. Examples

of items that may be stored in this header include

Destination SAP. When the destination transport layer receives the transport

protocol data unit, it must know to whom the data are to be delivered.

* Sequence number. Because the transport protocol is sending a sequence of

protocol data units, it numbers them sequentially so that if they arrive out of

order, the destination transport entity may reorder them.

Error-detection code. The sending transport entity may include a code that is

a function of the contents of the remainder of the PDU. The receiving transport

protocol performs the same calculation and compares the result with the

incoming code. A discrepancy results if there has been some error in transmission.

In that case, the receiver can discard the PDU and take corrective

action.

The next step is for the transport layer to hand each protocol data unit over to

the network layer, with instructions to transmit it to the destination computer. To

satisfy this request, the network access protocol must present the data to the network

with a request for transmission. As before, this operation requires the use of

control information. In this case, the network access protocol appends a network

access header to the data it receives from the transport layer, creating a networkaccess

PDU. Examples of the items that may be stored in the header include

Destination computer address. The network must know to whom (which computer

on the network) the data are to be delivered.

Facilities requests. The network access protocol might want the network to

make use of certain facilities, such as priority.

Figure 1.8 puts all of these concepts together, showing the interaction between

modules to transfer one block of data. Let us say that the file transfer module in

computer X is transferring a file one record at a time to computer Y. Each record

is handed over to the transport layer module. We can picture this action as being in

the form of a command or procedure call. The arguments of this procedure call

include the destination computer address, the destination service access point, and

the record. The transport layer appends the destination service access point and

other control information to the record to create a transport PDU. This is then

handed down to the network access layer by another procedure call. In this case, the

arguments for the command are the destination computer address and the transport

protocol data unit. The network access layer uses this information to construct a

network PDU. The transport protocol data unit is the data field of the network

PDU, and the network PDU header includes information concerning the source

and destination computer addresses. Note that the transport header is not "visible"

at the network access layer; the network access layer is not concerned with the contents

of the transport PDU.

The network accepts the network PDU from X and delivers it to Y. The network

access module in Y receives the PDU, strips off the header, and transfers the

enclosed transport PDU to X's transport layer module. The transport layer examines

the transport protocol data unit header and, on the basis of the SAP field in the

header, delivers the enclosed record to the appropriate application, in this case the

file transfer module in Y.

The TCP/IP Protocol Architecture

Two protocol architectures have served as the basis for the development of interoperable

communications standards: the TCPIIP protocol suite and the OSI reference

model. TCPIIP is the most widely used interoperable architecture, and OSI has

become the standard model for classifying communications functions. In the

remainder of this section, we provide a brief overview of the two architectures; the

topic is explored more fully in Lesson 15.

TCPIIP is a result of protocol research and development conducted on the

experimental packet-switched network, ARPANET, funded by the Defense Advanced

Research Projects Agency (DARPA), and is generally referred to as the TCPIIP protocol suite.

 This protocol suite consists of a large collection of protocols

that have been issued as Internet standards by the Internet Architecture Board I

(IAB). I

There is no official TCPIIP protocol model as there is in the case of OSI. However,

based on the protocol standards that have been developed, we can organize

the communication task for TCPIIP into five relatively independent layers:

Application layer

Host-to-host, or transport layer

Internet layer

Network access layer

Physical layer

The physical layer covers the physical interface between a data transmission

device (e.g., workstation, computer) and a transmission medium or network. This

layer is concerned with specifying the characteristics of the transmission medium,

the nature of the signals, the data rate, and related matters.

The network access layer is concerned with the exchange of data between an

end system and the network to which it is attached. The sending computer must

provide the network with the address of the destination computer, so that the network

may route the data to the appropriate destination. The sending computer may

wish to invoke certain services, such as priority, that might be provided by the network.

The specific software used at this layer depends on the type of network to be

used; different standards have been developed for circuit-switching, packet-switching

(e.g., X.25), local area networks (e.g., Ethernet), and others. Thus, it makes

sense to separate those functions having to do with network access into a separate

layer. By doing this, the remainder of the communications software, above the network

access layer, need not be concerned about the specifics of the network to be

used. The same higher-layer software should function properly regardless of the

particular network to which the computer is attached.

The network access layer is concerned with access to and routing data across

a network for two end systems attached to the same network. In those cases where

two devices are attached to different networks, procedures are needed to allow data

to traverse multiple interconnected networks. This is the function of the internet

layer. The internet protocol (IP) is used at this layer to provide the routing function

across multiple networks. This protocol is implemented not only in the end systems

but also in routers. A router is a processor that connects two networks and whose

primary function is to relay data from one network to the other on its route from

the source to the destination end system.

Regardless of the nature of the applications that are exchanging data, there is

usually a requirement that data be exchanged reliably. That is, we would like to be

assured that all of the data arrive at the destination application and that the data

arrive in the same order in which they were sent. As we shall see, the mechanisms

for providing reliability are essentially independent of the nature of the applications.

Thus, it makes sense to collect those mechanisms in a common layer shared

by all applications; this is referred to as the host-to-host layer, or transport layer.

The transmission control protocol (TCP) is the most commonly-used protocol to

provide this functionality.

Finally, the application layer contains the logic needed to support the various

user applications. For each different type of application, such as file transfer, a separate

module is needed that is peculiar to that application.

Figure 1.9 shows how the TCPIIP protocols are implemented in end systems

and relates this description to the communications model of Figure l.la. Note that

the physical and network access layers provide interaction between the end system

and the network, whereas the transport and application layers are what is known as

end-to-end protocols; they support interaction between two end systems. The internet

layer has the flavor of both. At this layer, the end system communicates routing

information to the network but also must provide some common functions between

the two end systems; these will be explored in Lessons 15 and 16.

The OSI Model

The open systems interconnection (OSI) model was developed by the International

Organization for Standardization (ISO) as a model for a computer communications

architecture and as a framework for developing protocol standards. It consists of

seven layers:

*Application

*Presentation

*Session

*Transport

* Network

Data Link

Physical

Figure 1.10 illustrates the OSI model and provides a brief definition of the functions

performed at each layer. The intent of the OSI model is that protocols be developed

to perform the functions of each layer.

The designers of OSI assumed that this model and the protocols developed

within this model would come to dominate computer communications, eventually

replacing proprietary protocol implementations and rival multivendor models such

as TCPIIP. This has not happened. Although many useful protocols have been

developed in the context of OSI, the overall seven-layer model has not flourished.

Instead, it is the TCPIIP architecture that has come to dominate. Thus, our emphasis

in this lesson will be on TCPIIP.

 

Figure 1.11 illustrates the layers of the TCPIIP and OSI architectures, showing

roughly the correspondence in functionality between the two. The figure also

suggests common means of implementing the various layers.