A computer network requires three major components: a transmission medium, an interface between the network station and the medium, and software to drive the network connection. In addition to controlling the connection, software provides support for the network user or application developer similar to the support the operating system provides in a single computer system.
In a single computer system, the role of the operating system is two fold. The operating system serves the user by providing access to systems resources while masking the complexity of many operations. Thus many users have little or no understanding of the tasks required to read and write to a disk, or to manage memory, for example. The operating system also protects the system from a careless or malicious user. Critical functions in the system operation can be executed only by the operating system -- users must issue requests through the operating system. This prevents users from accessing the areas in memory where system functions are stored, and the storage areas that belong to other users.
Computers connected to a network continue to function as independent, separate devices, but are also able to make explicit use of the network through operations such as electronic mail, file transfer, and remote login, among others. A user invokes these operations by running specific programs. The network software that allows processes running on a computer to interact with the network and to send and receive messages supplements the other operating system functions. Sending a message requires making a system call on the operating system module that forms the message into packets suitable for network transmission. The packets include the message, but also information about what process is sending the message and what process is to receive it.
The degree of difficulty involved in delivering the message to the intended destination depends on the nature of the network in use. Some networks require little effort to deliver the message, since every station on the network receives every transmission. All that is needed is that the destination node accept the message and pass it to the proper process (the electronic mail or file transfer process, for instance) and that other nodes disregard it.
Receiving a message is actually more difficult. A node that can receive messages has no way of knowing when a message will arrive. Thus its network software must always be listening to the network connection in case a message arrives. A process that expects to receive a message must coordinate itself with the daemon , or background, process that is always listening for incoming messages. The daemon must know which process to deliver the message to, if one should arrive. The destination process must execute statements of the form ``check for incoming messages; if any exist, proceed to process''.
In some networks, however, the separate systems are more closely tied together through software. Resources located on the network are accessed nearly as easily as the resources attached directly to the individual user station. Software provides a sense in such networks, that the whole collection of networked computers is a type of system. All the resources of this extended system are accessible to any process running on any station.
This degree of connectivity requires an extension of the operating system. The network operating system consists of a layer of software between the operating system and the application software on each computer in the network. The network operating system software captures calls for system resources, interprets them, and passes them to the usual operating system routines or to a network resource provider as needed. Hutchison88
Network operating systems most often connect personal computers or workstations and provide a file server and print server. To use network resources, the user must log in to the network, as he or she would log in to a multiuser computer system. The login identifies the user and determines what resources the user may access. The network operating system includes code that runs in the personal computer or workstation and other code that runs in the server. The user interacts with the code in the station, which in turn interacts with the code in the server. The net effect is increased resources for the user of each station.
The network operating system thus corresponds to a single system operating system. It assists the user in gaining access to resources, masking much of the complexity actually involved in such access. It also protects network resources from inappropriate use by authenticating users and restricting access.
Network operating systems provide access to network resources for user processes, but much more is needed to realize the goal of inter operability between processes running on separate systems. Inter operability means that distinct processes, each running on its own processor, cooperate in accomplishing some goal. They cooperate by exchanging information, by notifying each other as various tasks are completed, by requesting services from and granting services to each other. The processes run in separate and perhaps very different operating environments; they are related only in the cooperation. Their cooperative operation depends on a common understanding of how their interaction will proceed. They must agree on the format and the meaning of messages exchanged, and under what conditions the exchange will take place. The agreement about what messages will be sent and expected, under what conditions, in what format, and with what meaning is called a protocol .
For example, suppose we want to have the ability to send a message from one station in a network to another, have the receiving station confirm that the message arrived and then display the message on the screen. Sending the message is not sufficient, even if we are sure the message will be received by the destination machine. What is needed is an agreement, a protocol, that says
Why would such a situation arise and what can be done about it? The situation may have arisen because the idea of the mutual screen write by separate computers occurred to more than one person and each implemented it on the computers he or she wanted it on. Neither was aware of or even interested in the other's existence. Only later did someone recognize a reason to have the same facility on all the systems. What can be done about it? There are four potential solutions to the problem:
This very small example illustrates the current condition in network protocols. There are many reasons why there are a number of different protocols for accomplishing similar goals. Some of the differences result from requirements that demand specific features that are not consistent with other requirements. Others grew out of historic events and have become deeply ingrained in the products and practices of the industry. The various stations on a network come from different manufacturers, each with a long history of its own way of working. Allowing processes to interoperate, machines to communicate with each other, and to cooperate to share a common transmission medium requires another kind of cooperation -- the development of standards. The standards define protocols independent of individual manufacturers and applications.
Joining incompatible independent systems by agreeing to some common principles is not a new activity. In the 19th century, a railroad built for one region had a different width of track from a railroad in another region. As long as the regions remained separate, and the equipment was manufactured specifically for use in one region, the differences were immaterial. However, when the use of the railroads expanded, and the ability to travel and ship goods over long distances was recognized, the problem had to be solved. The solution was an agreement to build railroad equipment according to a common, or standard specification. Notice that agreeing on a standard gauge track did not allow trains to travel between narrow and wide gauge tracks. The original tracks and trains could still be used for transportation within the region; but when travel between regions occurred, only standard gauge track and trains built to run on it would do.
The incompatible personal computer systems initially built by IBM and Apple provide another example. A lot of development effort is expended in preparing programs to run in these different environments.
The situation is similar with the developing network standards. Older proprietary protocols can still be used between the systems that implement them. However, to interoperate with other systems, the global standards must be observed. As a result, more than one set of protocols may exist in many systems. As more and more systems adopt the global standards there will be less reason to use the older, more restricted, protocols. However, because of the investment in the current systems and the number of applications that depend on them, these older protocols will continue to be important for some time.
The interaction of application processes running on separate systems and communicating over a network is a complex task requiring a large number of operations. Since many of the operations are common to most processes, they can be grouped and provided as a library of functions called when needed. There are many ways to combine these operations, depending on the needs of the application processes calling them. Since the number of operations that may be required is large, and the number of possible combinations is much larger, some structure is needed to organize the options and the practical combinations. In networked applications, a layered structure best serves the requirement of grouping operations and finding combinations that work well together to meet a particular need.
The layers defined in a suite of network protocols isolate particular services and define the relationship among the services. For example, communication between processes on separate computers requires that messages sent from one computer arrive at the other. It is useless to consider message exchange between processes unless that capability exists. An application therefore invokes a service to facilitate communication with its peer application and that service in turn invokes a service to locate and establish contact with the machine where the peer application is running.
Layering does more than assist the application in selecting from a variety of services. By isolating the details of each service from the others, layering allows each service to be developed and revised as needed with minimal impact on the other components of the network software. Some services, such as sharing the communication medium, change as new technology becomes available. Others change with the needs of new applications, perhaps for time requirements or security.
The layers in a protocol suite identify the required components of each network communication between application processes. Within each layer a number of choices allow the processes to select the type of service most appropriate for their needs. Each service is defined in terms of its interaction with the layer above it and the layer below it and the net effect of its use. Within those constraints, its internal operation can be implemented in any way and can be revised when better techniques are found. Additional services can be added at each layer as needed, without affecting the services that are currently available.
A suite of network protocols consists of a collection of layers of services to support communication between application processes. Each of the layers consists of one or more options for the type of service provided at that layer. The layers are often referred to as a protocol stack .
In the sections that follow, we will see several different approaches to
layering network services and to the choices offered at each layer.
There are others. We begin with the OSI Reference Model, an attempt to
define a set of standards for network interaction that all network
applications can use. The OSI Reference Model is conceptual -- a
convenient packaging of the many operations needed for process
interoperation. Individual protocols developed to conform to the OSI
reference model provide a true layering of network operations.
The OSI Reference Model
To facilitate standardization of all aspects of communication and cooperation among systems, the OSI reference model identifies seven layers of interaction.
Programmers, managers, and application developers in a networked environment must particularly understand the layers that provide user-oriented services. These are layers seven through five, the layers most prominently featured in the chapters that follow. Layer four, the transport layer, presents the application with a number of options in addition to providing an interface to network layer services. We will emphasize the choices available at the transport layer and how to select appropriately. At the network layer, we will be concerned primarily with addressing. We will also look at the network services that are important in connecting local area networks together. Many of the details of the data link and physical layers are best suited to a course in data communications. We will restrict our attention to those parts of the data link layer that represent differences between the types of local area networks and that are significant in passing messages from one local area network to another.
The ARPA protocols, also called the DoD protocols because they were developed under support of the Department of Defense and the DDN protocols because they are used in the Defense Data Network, were developed for the ARPAnet, beginning in the 1960s under funding from the Advanced Projects Research Agency (ARPA). The ARPA protocols, developed well before the OSI protocols, do not conform to the OSI layering convention. Figure ARPAlayers shows the layering of the ARPA protocols. Systems that implement the ARPA protocols can interoperate with each other.
At the core of the ARPA protocols are a network protocol, called the Internet Protocol (IP), and a transport protocol, Transmission Control Protocol (TCP). IP is responsible for routing packets through interconnected networks and TCP is charged with breaking messages into network-size packets, handing them off to IP , putting the packets back to form the original message at the destination, and recovering from errors that may have occurred in the network operation. TCP provides the appearance of a reliable connection between processes running on separate systems. TCP in turn relies on IP to deliver the packets of data from the sending machine to the destination machine. The two combined allow processes on separate systems to interact as if they were in direct contact with each other. Because the services provided in the ARPAnet and its descendants rely heavily on the combined services of TCP and IP, the entire suite of protocols and services is often referred to as TCP/IP.
In the ARPA protocols, two protocols provide the network layer service. User Datagram Protocol (UDP) isan alternative to TCP at the transport layer. While TCP attempts to provide a very high-quality service, compensating for lost or reordered packets, this service comes at a relatively high cost in terms of processing required. UDP provides a much lighter service, sometimes characterized as``send it and pray'', and involves a much lighter processing price. The appropriate choice depends on the type of service the application requires. If speed is more important than perfect accuracy, then UDP delivers the needed service. If the processing overhead of TCP is not an undue burden and a very reliable service is required, TCP meets the need. Both TCP and UDP can set up a network connection using IP, as shown in Figure ARPAlayers
IP runs in many network environments, connecting systems over local area networks, wide area networks, and combinations of interconnections. There is no presentation or session layer in the ARPA suite. The principal application services are File Transfer Protocol (FTP), electronic mail support (SMTP, the Simple Mail Transfer Protocol), and TELNET (a form of virtual terminal facility for remote login).
TCP/IP has been widely available and used for more than 20 years. Consequently there is a large base of applications dependent on it and many application developers comfortable with it. Some proponents of TCP/IP contend that it is neither necessary nor desirable to abandon TCP/IP in favor of the OSI protocols. Though most people in the field believe that eventual domination by the OSI protocols is inevitable, TCP/IP will not disappear for the foreseeable future. It is likely that many systems will run both suites to provide the largest possible opportunity for connectivity and interaction with other systems.
ISODE consists of software ``developed as a research tool and represent(ing) an effort to promote the use of the International Organization for Standardization (ISO) interpretation of open systems interconnection (OSI), particularly in the Internet and RARE research communities''. This non-proprietary implementation of the OSI protocol stack is intended to facilitate and encourage experimentation and development of applications in the OSI protocol suite. The software can support several different network services below the transport layer; in particular, it can run on top of the ARPA protocols (TCP/IP). It also runs over the top of existing implementations of the OSI lower layers. ISODE thus allows development of applications independent of the replacement of TCP/IP by OSI network protocols. As the OSI protocols become more widespread, the applications developed in ISODE can move gracefully to the new environment.
The developers of ISODE contend that progress in the development of network applications will benefit from the combined experiences of the TCP/IP and the OSI groups: ``TCP/IP is here, works well, and enjoys a tremendous base of support. OSI is coming, and will work well, and when it eventually comes of age, it will enjoy an even larger base of support.'' isode
The last free, openly available release of ISODE (Version 8) was in 1992. The ISODE Consortium originated at that time, with the purpose of providing a regular support and development commitment to future ISODE work. Future releases of ISODE from the ISODE Consortium are not intended to be in the public domain, but to be available to non-commercial research and educational organizations under no-cost license. Current information about the consortium and its releases of the ISODE software can be obtained from ic-info@isode.com .
Work on IBM's System Network Architecture (SNA) began in the 1960s and SNA was announced in 1974. SNA allowed terminals to be shared by multiple programs in a single-host, tree-structured network. In 1976 enhancements allowed programs in two or more separate hosts, each using SNA, to communicate with one another and with the terminals.
SNA is a layered architecture, like the OSI stack, though the specific separation of duties varies somewhat between the two. SNA predates OSI. The layers of the SNA stack are shown in Figure snastack . Keukes90 The boundaries between layers in the two stacks do not match exactly, but the OSI stack was modeled in part on SNA and there are a number of similarities. An SNA network consists of nodes, each one of a particular type depending on its functionality. Type 1 nodes are terminals. Type 2 nodes are terminal controllers. Type 2.1 nodes, introduced in 1983, can establish and support direct, peer-to-peer sessions. There are no type 3 nodes. Type 4 nodes are communications processors, attached to hosts to relieve the host of the processing requirements associated with communications. Type 5 nodes are the hosts. SNA network architecture consists of the physical entities that comprise the network plus logical entities (software) related to them. Three types of logical entities make up the network addressable units(NAUs): logical units (LUs), physical units (PUs), and system services control points (SSCPs). End users, either human users at terminals or application processes, access the SNA network through the logical units. LUs establish a session, the logical connection through which the communication occurs. The physical units provide administrative and network operation services at a node in the network. A system services control point resides in a host computer and includes complete knowledge of the other nodes associated with the host. The SSCP is the focus of configuration management, problem determination and directory services. SSCP runs in either a host or a communications front end processor (type 5 or type 4 node). All the nodes known to an instance of SSCP comprise a domain . Each host or communications controller and its directly attached peripheral devices makes a subarea. A domain includes a single instance of SSCP and is made up of one or more subareas.
The hierarchical approach to networking is the dominant architecture for SNA backbone networks. Establishment of sessions between LUs requires that a session first be established with the local SSCP. SSCP maintains the directory services tables required to convert the name of the requested LU to an address that allows connection establishment. After resolving the LU, the SSCP determines whether the destination LU is able to participate in the requested session and issues instructions to attempt the session establishment.
The hierarchical nature of networking in subarea SNA uses manually established, static tables for name to address resolution and routing among subareas. Routing changes require major system adjustments, usually requiring that the affected hosts and communications front ends be taken out of service. Problems associated with static definition of network nodes, resources, and routes are burdensome in today's networks that involve hundreds of hosts and communications front ends; the prospect of adding large numbers of personal computers and workstations to the SNA networks makes the problem unreasonable. Pickens89 This system also does not lend itself well to dynamic response to changing network conditions.
General purpose networking, involving session establishment between any machines without the need to predefine network membership, is a basic tenet of Open System Interconnection and a growing demand of the user community. This peer-to-peer networking is a significant departure from the master-slave relationship central to the networking strategies of IBM's SNA and the proprietary systems of other companies as well. IBM's move toward meeting this demand is implemented in the Advanced Peer-to-Peer Network (APPN) protocols. Sackett90 Independent Logical Units using the APPN protocols reside in type 2.1 nodes. They can be the master or slave in a session, use a dynamic, distributed directory to find destination LUs, and use dynamic topology update and route-determination protocols.
Users of IBM's SNA have stated a requirement for communication and
inter operability between their SNA network nodes and non-SNA devices.
IBM has selected OSI as the vehicle to enable communication between SNA
and non-SNA nodes. Sackett90
IBM, like the other computer manufacturers, will continue to develop its
proprietary network systems to meet their customers' needs while at the
same time participating in the development and deployment of services
required in heterogeneous networks. Like TCP/IP, SNA has a large
installed base and a large group of satisfied and expert users. It will
not disappear in the near future. As the OSI solution to the needs of
inter operable systems evolve and spread, these older networking
solutions will continue to play an important role in the emergence of
network systems and applications.
Return to Chapter Overview
The application layer provides the services required for an application program running on one system to interact with an application program running on another system. The functions performed at this layer include establishing contact between the two processes, setting conditions of the interaction, providing means to execute a command on the other system, accessing each other's file systems, insuring reliable exchange of information, and other functions directly used by an application program. Only those parts of an application that are involved in communication with another system are part of the application layer. Those parts of the application process are called the application entity. Back to OSI RM Summary
The presentation layer of the OSI model is responsible for converting the information sent by the application layer into a stream of bits that retain the original semantics. The information exchanged is encoded in one, two, or three different ways -- at the two ends of the connection and in the path between the endpoints. The presentation layer provides data compression or encryption during transmission, or simply a common encoding scheme accessible to two systems that use different internal codes. Because the presentation layer maintains the semantics in information exchanged between application layer processes, representation of data types (for example, reals or strings) and questions about ASCII or EBCDIC do not arise. Back to OSI RM Summary
The session layer establishes and maintains a connection between application processes and manages the dialog between them. The session layer determines which side is talking and which is listening at any time, so the interaction proceeds in an orderly, comprehensible way. The session layer provides the mechanism to allow an application to establish checkpoints during a dialog. For example, a long file transfer that is interrupted can be resumed without having to retransmit much of the file. Back to OSI RM Summary
The transport layer is critical to networked applications in several different ways First, the transport layer is the one that deals with end-to-end communication between the cooperating systems, independent of specific network characteristics. The transport layer is charged with delivery of messages from one application process to another process. The transport layer masks any failures of the underlying network service from the communicating processes, somewhat as a surge protector guards an electrical appliance from some irregularities in the power supply. A number of service options exist for the transport layer. Depending on the request of the user, the transport layer will provide more or less in the way of reliable, ordered packet delivery. Back to OSI RM Summary
The transport layer is also the last that is under the control of the application user. The transport layer selects and interacts with the network service provider, which may be a utility such as the telephone company or a courier service. The user cannot control the internal operation of the utility, but can instruct the transport service to provide a required level of service and reliability. Back to OSI RM Summary
The network layer is the first to control communication between computers, rather than between processes. It is responsible for identifying and locating the device on which the remote process resides. The network layer is responsible for addressing, for finding routes through interconnected networks, for congestion control, and for any other aspect of communication between separated machines . The application programmer will not select the network services or influence the way they work. This choice is made by the transport layer in response to the requirements specified by the application and the network resources available to it. Back to OSI RM Summary
The data link layer deals with communication between adjacent computers. In this context, one computer is adjacent to another if they share a common communication link. Thus, the computers may be connected with a direct point-to-point link or may be attached to the same local area network. The data link layer is particularly important when we consider the protocols of local area networks and metropolitan area networks. In general, the application programmer will not know or care about how the data link layer functions. At the high layers, correct operation of the data link and physical layers is taken for granted, just as the correct operation of the arithmetic and logic unit is assumed in programming a single computer. Back to OSI RM Summary
The physical layer determines the nature of the interface between the computer and the transmission medium on which the bits move. The physical layer is not the cable or fiber that connects the computers, but is the set of rules and methods used to represent bits on the medium. Back to OSI RM Summary
