The OSI reference model is the product of two independent development projects undertaken by the International Standards Organization (ISO) and the CCITT (which translates from the French as the International Telegraph and Telephone Consultative Committee), beginning in the late 1970s. Two separate documents were produced, each defining a seven-layer model for network communications, but in 1983 the two were combined and eventually published as the ISO 7498 standard. The same document is also available from the Telecommunications Standardization Sector of the International Telecommunications Union (ITU-T0), which is the new name given to the CCITT in 1992. Documents published by this body are known as recommendations, and the OSI model recommendation, officially known as The Basic Reference Model for Open Systems Interconnection, is called X.200.
The OSI reference model is a structure that was designed as a general guideline to the various levels of communication that take place in a data network. The model's origins stem from a desire to move away from proprietary implementations of network architectures and develop a set of openly defined protocols that could be used as the components of actual network products. The idea was that by defining in detail the requirements for networked data communications, stratifying those requirements, and then specifically delineating the services provided by each of the strata to the others, a development environment could be realized in which independent teams would work on individual layers, all of which would function properly as a whole when assembled. Thus, in theory, the development time required for such a protocol suite should be far shorter than that of a single, unified effort, providing at the same time a fully documented product. This part of the effort, however, has not materialized exactly as planned. The OSI protocols themselves are still under development, which will very likely continue for many years to come, and products utilizing them are few. The reference model, however, has come to be a widely known learning tool for the basic building blocks of computer networking.
The OSI model is not intended to be a generalization of any particular network type or product, nor are many specific network structures or products designed to conform precisely to the model. Comparisons of the model with the actual network implementations in popular use today are rife with exceptions, discrepancies, and caveats. Its primary value is as a template of the relationships between the various elements needed to transmit data from one computer to another. Systems designed with this template as a general guide are more likely to be able to communicate with each other than if each was created from an entirely independent architecture. The existence of the OSI model thus promotes interoperability between network systems.
At the top of the model, as shown in figure 3.1, is the user interface, that is, the application or process that initiates a request for access to a resource located somewhere else on the network. At the bottom of the model is the actual physical medium that serves to connect the various entities that comprise the network. A request, generated at the top, or application layer, travels down seven layers to the bottom, or physical layer. During this process, it is ultimately converted from an API call within the originating application to a series of impulses encoded in such a manner so as to transmit binary information over the network medium to another machine.
Figure 3.1
The OSI networking reference model splits the communications processes of computer
networks into seven distinct layers.
The impulses transmitted over the physical layer can be electrical, optical, magnetic, microwave, or radio carrier frequencies. In traveling downward through the layers of the OSI model, the application request undergoes a number of different encoding processes that are designed to allow specific layers of the model to communicate with their counterpart layers in the destination machine. These processes are called protocols. Once having arrived at the destination machine, the impulses undergo the exact same process in reverse, traveling upwards through the model and being decoded until they arrive at the functional equivalent of the topmost layer at the other machine. In this manner, the top operational layers of both computers can interact transparently, functioning as though the networked resources that they are accessing are no different from those available within the local machine. This is the basis for networking compatibility. An application running on a network workstation need not be aware that the files it is accessing are located elsewhere on the network. The functionality of the OSI model is thus completely invisible to the user interface.
The different protocols used by a single computer network may be proprietary products of a single manufacturer, or they may be open standards, developed and governed by committees composed of employees of many different companies, or they could be a mixture of the two. Such committees, like the Institute of Electrical and Electronics Engineers (IEEE), the American National Standards Institute (ANSI), and even ISO exist for no other purpose than to define and publish standards by which competing manufacturers can develop products that are capable of operating with each other.
In the early days of computer networking proprietary systems were recognized as inherently counter-productive. The computer industry is a highly volatile one, and for a consumer to invest large sums of money on networking equipment that is the product of a single corporation, which cannot be used with the products of any other corporation, is very risky. There are relatively few firms that have the resources to manufacture all of the hardware and software components that comprise a computer network. Interoperability fosters healthy competition and encourages users to purchase equipment that they know will continue to be viable, even if the original manufacturer does not remain so.
The OSI reference model makes no distinctions concerning the actual protocols used to transmit data over the network medium or the equipment used to do it. It is intended to be an illustration of computer networking in its most abstract form, and networks composed of computers using radically different microprocessors, operating systems, and communications protocols can all conform to the model to some degree. Therefore, the purpose of this chapter is not to define the protocols or the hardware used in any great detail beyond identifying the layers at which they operate, although it would be quite possible to use the OSI model as the basic outline for this entire book. Many of the components and protocols mentioned here are examined more thoroughly elsewhere, in other chapters, and references will be provided directing the reader to the appropriate locations for further reading.
This chapter is designed to provide an overview of the way in which the often disparate elements of this book can be linked together to provide a functional model for today's business-oriented LAN. We will cover each layer of the OSI reference model, discuss its function in general, and illustrate how it is realized in the actual networking products in use today.
One of the greatest problems in discussing the layers of the OSI model and the role that each one plays in network communications is in the nomenclature used to describe the elements formed by each layer. It is often said, for example, that frames are generated by the data link layer, datagrams by the network layer, messages by the application layer, and so on with the term packet being used for the communications at almost any layer. These terms often end up being confused and interchanged at will, so I will attempt to set a precedent and define the terms that will be used throughout this book in the hope that others will follow.
In its most basic, overly simplified form, network communications can be broken down into requests and replies. Most of the traffic found on a typical network will consist of requests generated by users at workstations, and the replies from the resources to whom the requests were directed. The fundamental unit of data that is transmitted over the network is a packet. Packets can be of different sizes, depending on their function and on the network type, but it is essential that data be transmitted in some form of discrete unit so that there is a measure of empty space on the network medium between transmissions. This is necessary because, by definition, any station on the network must be allowed to transmit its own data at some time. If communications took the form of an uninterrupted stream of data, there could be no opportunity for multiple stations to utilize the same bandwidth. The only way that this would be possible would be if every station on the network had a dedicated link to every other station. This is called a mesh network, and it is virtually never used, due to its obvious impracticality. (Imagine 50 workstations, each with 49 network interface cards installed in it and 49 wires extending out to each of the other stations).
Therefore, every request and reply generated by a station on the network will be composed of one or more packets. Within each packet, at its core, is a request or the reply to a request. For example, an application at a workstation generates a request to open a file that is stored on a server volume. The server, receiving the request, honors it and replies by sending the file to the workstation. The packets sent by both the server and the workstation contain the actual request for the file and the file itself, sent in reply, but there is also a great deal more data included within those packets. The network must have some means of addressing the packet so that it arrives at the proper destination. There is also usually a means by which the packet can be acknowledged as having been received at its destination, a method for checking that the packet has arrived in the same condition in which it was sent, and a mechanism to ensure that packets are not sent to the destination too quickly. These last three features are known as guaranteed delivery, error checking, and flow control, respectively.
These additional functions are provided by information contained within frames, generated by the various layers of the OSI model, which surround the actual request or reply. For our purposes, the term frame does not refer to any specific layer of the model. Frame is used in its most literal sense, as a structure that surrounds and contains the original data being transmitted. As we examine the various frames required to get a simple file request from one place to another, you may be surprised to find out that this network overhead, or control information, often comprises more actual bytes of data than the request itself. One of the marks of a particular network's efficiency is the amount of communications overhead that is necessary for the transmission of normal network traffic.
As a request travels down the layers of the OSI model, several different frames are added, with each one applied to the outside of the existing structure. In other words, the original request is at the heart of the packet. A succeeding layer then applies its frame, and the request is included as the data field of that frame. A field is a discrete group of contiguous bytes within a packet that is used to perform a particular function. For example, the address of the destination node on the network will be in its own field, and each of the network control functions described earlier may also be realized by the inclusion of information in separate fields.
Each one of the frames within a packet, therefore, consists of a header, which is a series of fields added to the front of the packet, followed by the data field which, in this case, consists of the original request generated by the top layer. Depending on the layer and the network type involved, there may or may not be a footer, which is another series of fields appended to the end of the packet. The packet is then sent down to the next layer of the model, which may apply its own frame to the structure, including the existing packet with the previous frame already applied, as its data field.
Once a frame is applied to a packet, nothing disturbs the arrangement of the bytes inside that frame, until the packet reaches its destination. Later manipulations may add additional fields to the outside of the existing structure only. Thus, by the time the packet arrives at the bottom of the model, it consists of the original request, surrounded by a frame, which is surrounded by another frame, and another, and so on, as shown in figure 3.2. Therefore, when discussing the data link layer, at which the last possible frame is applied, what is referred to as its data field actually contains the original request, plus several other upper-layer frames arrayed around it. This framing data, exclusive of the actual request data being carried by the packet, is called the protocol control information.
Another way of looking at this process is to approach the construction from the bottom. Picture the lowest data-oriented layer of the model, the data link layer, as producing a data header and a footer, with an empty hole in between, which is its data field. The next layer up, the network layer, provides its own frame that fills the hole, but which contains its own hole within it. Each successive layer fills the hole left by the previous layer until, at the top of the model, the original request generated by the application plugs the final hole, thus creating a single uninterrupted stream of data, which is a packet.
Figure 3.2
A typical network packet consists of an original request, surrounded by several frames,
which are applied by successive OSI layers; each frame is composed of several distinct
fields.
This concept of applying multiple frames to a single packet leads to further naming problems. Packets are sometimes referred to by the name of the data link frame, such as an Ethernet packet or an 802.5 packet. This is the one frame that is absolutely required for every packet transmitted over a network, and a reference such as this is usually made when an internetwork combines multiple data link types that must be distinguished. However, packets are more often referred to by the frame that defines their primary function, as in an IP, a SAP, or an SPX packet. In nearly all cases, a reference such as this refers to a particular frame that is carried within one or more other frames, including one of the data link frame types mentioned above. Thus, a NetWare SAP packet, for example, may also be called an IPX packet, an 802.2 packet, or an Ethernet packet, with equal validity.
Nowhere is this type of confusion more evident than in the case of NetWare frame types, one of which must be selected when configuring a server for network access. Two of the possible choices, 802.3 and Ethernet II, describe data link frame formats. The two others, 802.2 and Ethernet SNAP, actually refer to higher-level frame types, both of which are carried within an 802.3 frame. Thus, three of the four possible NetWare frame types can actually be correctly referred to as 802.3 frames. This matter is dealt with in greater detail in chapter 8, "Novell NetWare."
The point being made here is that references to specific protocols being used in a particular packet are not necessarily exclusive of all other protocols. Indeed, this is nearly never the case. Virtually every packet being transmitted over the network utilizes at least two different communications protocols, and many use four or five. One of the main purposes of the OSI reference model, and of this chapter, is to identify the layers at which the most commonly used protocols operate and define the ways in which they interact with the other protocols that may be in use at the same time. This knowledge brings the administrator a greater awareness of the nature of the traffic on his network. With the addition of a protocol analysis tool such as LANalyzer or Sniffer, adjustments can be made to the network operating system (NOS) and router parameters that will maximize the efficiency of the network in precisely the areas that need to be addressed.
The physical layer of the model, as shown in figure 3.3, consists of the actual medium through which bits are transmitted from one location to another, in other words, the fabric of the network itself. The connection between two network stations may be in the form of copper or some other electrically conductive cable, fiber optic, radio signals, microwaves, lasers, infrared, or any other medium practically suited to the environment. The OSI model makes no distinctions concerning the actual hardware involved, but the physical layer comprises every component that is needed to realize the connection. This includes any and all connectors, hubs, transceivers, network interfaces, and ancillary hardware, as well as the physical medium or cable itself, if any. This layer also includes the environmental specifications necessary to maintain the validity of the medium, as well as the method of signaling used to transmit bits to a remote location.
Figure 3.3
The physical layer of the OSI model is usually realized in the form of a cable network
connecting separate computers.
Therefore, what we have at the physical layer is the most fundamental element of the communications process. The upper layers of the model reduce the data to be transmitted down to binary code, and it is the sole function of the physical layer to see that those ones and zeroes are transmitted from one location on the network to the next. The physical layer is completely oblivious of the nature of the data that it is transmitting. It is not concerned with packets, frames, addressing, or the ultimate destination of the data. It cannot read the binary code that it is transmitting, beyond a basic awareness of the difference between a zero and a one, which it converts into suitable impulses of electricity or light that can be sent over the network medium. Each transmitting device on the physical layer is aware of nothing but its adjacent neighbors on the network, from whom it receives and to whom it is responsible for sending these impulses, in whatever form they may take.
Each station on the network contains the functional equivalent of a transceiver as part of the network interface. As the name implies, a transceiver both receives signals from its nearest upstream neighbor and transmits them to its nearest downstream neighbor. Depending on the nature of the network, these neighbors may be one and the same, but the function is identical.
As with all of the protocols used in networking, the standard by which the physical layer of the network is constructed can be an open or a proprietary one. The physical layer is more likely to utilize open standards as a guideline for its fabrication, however, for several reasons. The first and most practical, is that the physical realization of a network is usually installed at a site by a contractor who will have little or no involvement with the assembly or maintenance of the rest of the LAN. Even large organizations with extensive in-house network support resources will often outsource large cabling tasks. It is therefore necessary to have an agreed set of standards by which such work is to be done.
The second and more obvious reason is that the utilization of an open standard for the physical layer is more likely to provide alternative uses for the same medium, should substantial changes to the network have to be made. Many office data networks have been constructed using existing telephone cabling, and most new office construction today consolidates the telephone and data networks into a single cable installation. The use of a cabling standard like 10BaseT (detailed in the IEEE 802.3 specification), which is designed to take advantage of the existing skills of telephone cable installation personnel, is clearly a practical and economical advantage.
Because of the wide array of media that can be used at the physical layer, there are a great many published standards used as guidelines for the design and construction of network systems. These may be the product of bipartisan committees like the ISO, or they may be published by individual corporations that advocate the use of particular media. Many of the most common media types used in PC networking today are covered in this book, particularly in chapter 7, "Major Network Types," but this coverage is not meant to be a guide by which a network medium is to be installed.
It is extremely important that the people installing a cabling or transmission system for a data network be fully acquainted with the exact specifications by which that medium should be installed. Aside from the familiar limitations such as segment length and distance between nodes, factors such as proximity to lighting fixtures, electrical, and other services; compliance with local building and safety codes; and licensing with federal agencies must be taken into account.
There are a great many factors involved in a proper physical layer installation, no matter what the medium type. Failure to comply with the appropriate specifications can cause, at the very least, poor network performance, and at most, an extreme safety hazard. Both of these can be very costly to correct after the installation is completed. This is why such installations are frequently outsourced.
If you are attempting to perform such an installation yourself, you should be familiar both with the documents defining the limitations of the data link layer that will be running over the physical medium, such as IEEE 802.3 or 802.5, and with the ANSI/EIA/TIA-568-1991 document, also known as the American National Standards Institute/Electronic Industry Association/Telecommunications Industry Association "Commercial Building Telecommunications Wiring Standard." There are also two technical bulletins with which familiarity may be advised, called "Additional Cable Specifications for Unshielded Twisted Pair Cables," (EIA/TIA Tech Sys Bulletin TSB-36, November 1991), and "Additional Transmission Specifications for UTP Connecting Hardware," (EIA/TIA Tech Sys Bulletin TSB-40A, December 1993). Other standards may apply, depending on the physical medium being installed, and familiarity with local building codes is also advised. These standards documents can be obtained by contacting your local ANSI branch.
Perhaps now the reasons are more obvious for outsourcing physical layer installation work. However, even if you are contracting someone else to do the job for you, you should be sure that they are familiar with the requirements documented in these standards. Compliance with the appropriate specifications should be agreed upon by both parties and included in any contractual agreement. Choosing a subcontractor with adequate insurance is also a good idea.
Amidst the discussion of all of the other complex protocols used in computer networking, the one that is most often neglected is the most fundamental--that is, the signaling method by which binary code is transmitted over the physical layer. The basic concept is simple: variations in electrical voltage, radio carrier attributes, microwaves, or pulses of light indicate the transition between a zero and a one. The actual construction of such a system presents a number of problems, however, that must be resolved before the communication can be considered reliable.
The first factor to be considered is whether network communications are conducted over an analog or a digital medium. Unbounded (that is, wireless) analog media, such as radio waves, are occasionally used for data networks in cases where physical access between two sites is limited and economic factors make unbounded and bounded digital links impractical. Analog signals can take any value within a specified range. Transition between two values is gradual, and cycles through the entire range, illustrated by the familiar sine wave signal pattern. The encoding of binary data into an analog signal involves the fluctuation of the signal's amplitude, frequency, or phase or a combination of these attributes, shown in figure 3.4. The distance (in signal strength) between the highest and lowest values of the sine curve is the amplitude. The distance (in time) between successive occurrences of the signal's highest value is its frequency, and two concurrent signals in which the highest values occur at different times are said to differ in phase. Regular variations in one or more of these attributes are used to signal the transition between values of zero and one, thus allowing binary data to be encoded. This is called modulation, and quite often, more than one of the three attributes is modulated to provide an additional measure of reliability.
Figure 3.4
Analog signals are used to transmit binary data by modulating one or more of their
three primary attributes.
Most computer networks use digital signaling, however, including the coaxial, twisted-pair, and fiber-optic media that comprise the vast majority of business LANs. Digital signals have discrete values (that is, voltages or light pulses) with transitions occurring almost instantaneously. Digital signaling systems can utilize multiple values, but most represent binary code through transitions between a positive and a negative value. A zero value is sometimes used as well.
The primary concern in the accuracy of digital signaling is timing. For the transitions between values sent from a transmitting station to a receiving station to have any significance, both stations must have some means of clocking the frequency of the transitions. Remember, most LAN communications are asynchronous--that is, they take the form of bursts of data separated by spaces when no activity occurs. This is done to allow multiple stations equal access to the same network medium. Some signaling types are self-clocking, in that the encoding method includes station synchronizing information as part of the signal, while others require an external timing signal.
For example, the simple signaling scheme illustrated in figure 3.5 utilizes two values, a positive and a negative, which could take the form of positive or negative voltages or the presence or absence of a beam of light. A positive value represents a zero, and a negative represents a one. Thus, binary code can be transmitted using this system, which is called polar signaling.
Figure 3.5
Polar coding is the simplest form of binary transmission, but it lacks a timing signal.
The problem with this system becomes evident, though, when two or more consecutive zeroes or ones must be sent. The bit stream is divided into cells, which are virtual divisions, each of which contains a single bit of data. When values alternate between zeroes and ones, the transitions delineate the boundaries of the cells. However, two or more cells in a row containing zero bits require no value transitions, and the receiving station has no precise method of tracking exactly how many zero bits are represented by a continuous value during a certain elapsed time.
These value transitions, of course, may be occurring hundreds or thousands of times per second, and the slightest speed fluctuation can turn a binary data stream of this type into mere noise. If an external clocking signal is supplied, indicating to both sender and receiver that bit transitions are to occur once every microsecond, for example, the signaling system is reliable. The cells are clearly delineated, and the recipient simply has to register the value of the signal each microsecond to be sure that the proper bit values are being transmitted.
Supplying an external clocking signal, however, is not a practical alternative for a baseband network (a baseband network is one in which a single signal occupies the entire bandwidth of the network medium). Other signaling systems, though, are able to supply a timing signal while they are transmitting data. In figure 3.6, the voltages themselves have no bearing on the values of the data being transmitted. This signaling system, called Manchester encoding, has a value transition in the middle of every cell. A transition from low to high indicates a binary value of one, and a high to low transition is equivalent to a zero. The other transitions made at the beginning of the cells exist only to adjust the voltage to the proper position to facilitate the correct mid-bit transition. Some Manchester systems may reverse these values, but this is the signaling scheme used by all Ethernet LANs. Even when several consecutive bits all contain the same binary value, a transition occurs at the midpoint of every cell. This regular and invariable occurrence of a transition is what supplies the timing signal to the receiving node. This type of signaling is also known as biphase signaling.
Figure 3.6
Manchester coding is the system used by all Ethernet networks.
Another variation on biphase coding is called Differential Manchester (see fig. 3.7). In this system, the voltage of the signal is even more remote from the actual bit value being represented. In this scheme, there is also a midpoint transition in every cell, but it is used only for timing purposes. The bit value of the cell is determined solely by the presence or absence of a transition at the beginning of the cell. The direction of the transition, up or down, is irrelevant. Its existence only denotes a bit value of zero. Its absence indicates a value of one. Differential Manchester encoding is used by token-ring LANs.
Figure 3.7
Differential Manchester encoding is used primarily by token-ring networks.
The physical layer is clearly the basis upon which the entire OSI reference model rests. It is treated differently from the other layers, in that it concerns matters concrete and visible. As a result, it is fairly common to see a distinct separation between people with extensive expertise in the physical layer, and those who have mastered the intricacies of the upper layer protocols.
As the interface between the network medium and the higher protocols, the data link layer is responsible for the final packaging of the upper-level binary data into discrete packets before it goes to the physical layer. Its frame is outermost on the packet and contains the basic addressing information that allows it to be transmitted to its destination. The data link layer also controls access to the network medium (see fig. 3.8). This is a crucial element of local area networking because dozens of workstations may be vying for use of the same medium at any one time. Were all of these stations to transmit their packets simultaneously, the result would be chaos. Protocols operating at this layer may also provide other services, such as error checking and correction and flow control.
Figure 3.8
The data link layer of the OSI model applies the outermost frame to every packet
transmitted.
The protocols used at the data link layer are sometimes incorrectly referred to as topologies. In actuality, a topology refers to the way that each station on the network is connected to the other stations. A single cable, stretched from one station to the next and terminated at each end is called a bus topology. Joining these two ends forms a ring topology. Connections extending from each workstation to a single access point, or hub, is known as a star topology. The mesh system described early in this chapter is another example of a topology. The actual protocols used at this layer of the model are frequently associated with specific topologies, hence the terminology confusion. Various combinations and hybrids of these topologies are also frequently used.
The most popular data link layer protocols in use today for local area networking are Ethernet and token ring. These are sometimes referred to (again, incorrectly) as media types. ARCnet and FDDI are also data link protocols, as are obsolete architectures like StarLAN and LattisNet. As is often the case, these protocols are available in various flavors that have different origins. Ethernet has always been based on open standard, the product of bipartisan committees, while Token Ring was originally developed by IBM, who continues to be its greatest champion.
The documents defining these protocols consist primarily of one or more physical layer specifications, a media access control mechanism, and a definition of the fields that comprise the protocol frame. This is just the first of many instances in which the functions of the various OSI model layers overlap. Cabling specifications seem to clearly belong to the physical layer, but in fact, the way that the cable is installed is a direct result of the limitations imposed by the data link protocol's media access control function and the nature (and particularly the length) of the frame being transmitted. These matters are more easily understood when a specific protocol is being discussed. The architecture and functionality of these protocols is dealt with specifically and at length in chapter 7, "Major Network Types." Here, it will suffice to explain only what is being done and not the precise manner it which it is accomplished.
Media access control (MAC) is the final task of the data link layer before passing the complete packet onto the physical medium of the network. As mentioned earlier, it is essential that every station on a LAN be given the opportunity to transmit its data in a timely manner. Otherwise, one station's request to open a file may be delayed extensively if other stations are monopolizing the network medium. Therefore, it is essential that a mechanism be realized to facilitate this sharing of a common resource. This is, of course, why data being sent over the network is divided into discrete packets instead of a continuous stream. The problem remains, however, as to when a station is to know at what time it is safe to transmit its packets.
This is most often done by one of two basic methods. Either a "token" packet is passed from station to station in turn and only the station possessing the token is permitted to transmit, or stations are allowed to transmit whenever they detect no other activity on the network and a mechanism is supplied to deal with the inevitable occasions when two stations transmit at the exact same moment. The first method is called token passing and is used by the token-ring, FDDI, and ARCnet protocols. The second is known as a contention method or, more specifically, Carrier Sense Multiple Access with Collision Detection (CSMA/CD). This is the MAC method used by Ethernet networks.
In both cases, the length of the packet being transmitted and the specifications by which the physical network medium is constructed are vital to the proper functioning of the MAC method. This is why these three functions are grouped into a single protocol standard document. They are functionally inseparable, and the neat dividing lines provided by the OSI model must be abandoned in the interests of logistical practicality.
It must, therefore, be understood that the functionality of the data link layer may theoretically end when it passes a packet to the physical layer, where it is encoded and transmitted to its destination, but a single protocol (such as Ethernet or token ring) defines the specifications for both layers.
The frame definition is also a vital aspect of the data link layer. It contains, among other things, the network and node addresses of the source and destination nodes on the network--that is, the most basic information needed to move the packet from one station to another. It should be noted that the data included in the frame supplied by one layer is available to all of the layers at another node. Just because a field in the data link frame supplies the network address of the packet's destination doesn't mean that only another data link layer can read that information. By the time the packet is transmitted over the network medium, it is a contiguous series of fields, and any destination process can utilize the data in any of those fields, without limitation.
Like the physical layer, the data link protocol is not responsible for the ultimate delivery of the packet to its destination. It is only concerned with moving the packet to the next consecutive station on the network. Each station checks to see if it is the intended recipient of the packet and passes it along to the next station. The packet is thus passed hand to hand until it reaches its destination. The more complicated elements of this travel are handled by the layers higher up in the OSI model.
Another field that is nearly always included in the data link frame is one that provides a means for error checking, which is a method of verifying that the packet arrives at its destination in the same condition as when it was transmitted. This is usually realized in the form of a cyclic redundancy check (CRC). A mathematical algorithm is applied to the contents of a packet, and the result of that algorithm is included within the packet, usually near the end. Once having been received at the destination, the same algorithm is again applied to the packet by the recipient, and the results compared with those enclosed within. Matching results indicate a proper transmission. Discrepancies cause a packet to be discarded.
In some cases, a mechanism is included to signal to the sender that the packet must be retransmitted, while in others, this function is left to the higher layers. The formation of a standardized unit length for error checking is another reason for imposing strict limitations on packet size. Larger packets are more difficult to verify and require a greater amount of data to be retransmitted for every error, lowering overall efficiency. The average number of transmission failures over a link is thus affected both by the underlying error rate of the signaling performed at the physical layer and the packet size imposed at the data link layer. For any given physical layer error rate, there exists a theoretical packet length that will cause all individual packet transmissions to fail. The maximum packet length for a data link protocol must, therefore, be one that accommodates both the needs of the MAC mechanism and the error checking algorithm.
The other fields of a data link frame generally contain information that is needed to facilitate the functionality of the MAC mechanism. These fields are highly specific to the mechanism being employed. For example, the overall packet length is included in an Ethernet frame, while control bits used for various housekeeping functions are part of a token-ring frame. The leading and trailing bytes of the packet usually contain some means of indicating to the rest of the network that a packet transmission is arriving and that it has ended. These are frequently realized as a series of bits that deliberately violate the physical layer's binary encoding scheme. This is treated as an unmistakable signal that a new transmission is beginning.
The data link layer also defies the organization of the OSI model in another significant way. The most commonly used family of data link protocols in network computing today are the specifications first published by the 802 committees of the IEEE in 1985. What has thus far in this chapter been referred to as Ethernet (a similar protocol that has existed since the late 1970s and thus predates the OSI model by several years) is actually the IEEE standard 802.3. The token-ring protocol has been published as document 802.5. The entire story about the development of these competing specifications is told in chapter 7, "Major Network Types." Other, lesser used, protocols were also defined by this organization, such as the 802.4 Token Bus network and the 802.6 Metropolitan Area Network standard.
Another, very crucial, document was produced by the IEEE's 802.2 committee. This specification defines a second frame that is still considered to be part of the data link layer. Also known as the logical link control (LLC) sublayer, this frame is a common construction utilized without modification by each of the other 802.x standards previously mentioned. Carried within the frame provided by the MAC sublayer, which varies for the different network types, it provides various services to the network layer protocol above it, including flow control and error recovery (as opposed to the error checking provided at the MAC sublayer). It is also used to establish connections at various levels (or classes) of reliability between sending and receiving stations, depending on the nature of the protocols used at the higher layers. The frame and the functions of this protocol are also examined in greater depth in chapter 7, in the discussion of Ethernet. It is mentioned here to illustrate the fluid dynamic between the theoretical constructions of the OSI reference model and practical networking considerations. As shown in figure 3.9, the MAC sublayer of the IEEE data link protocols can actually be thought of as extending from the middle of the data link layer down into the physical layer, to a certain degree. The LLC sublayer then comprises the upper half of the data link layer, providing services to and an interface with the network layer protocol, to be discussed next.
Figure 3.9
The IEEE 802 Standards cross the boundaries between layers of the OSI reference model.
The network layer is where the most crucial dividing line in network communications occurs (see fig. 3.10), for this is the only layer that is actually concerned with the complete transmission of packets, or protocol data units (PDUs), from source to destination. The functions provided by the physical and data link layers are local. They are designed only to move the packets to the next station on the network medium. The primary task of the network layer is to provide the routing functionality by which packets can be sent across the boundaries of the local network segment to a destination that may be located on an adjacent network or on one thousands of miles away. What's more, the route actually taken by the packet must often be selected from many possible options, based on the relative efficiency of each.
Figure 3.10
The network layer of the OSI model is concerned with the overall station to station
journey of the packet.
To the entire protocol stack above this level, the functionality of the network, data link, and physical layers must be totally transparent. The source and destination systems for a particular data transaction must be allowed to interact in an identical fashion, whether they are sitting next to each other or in different countries. As long as the proper lower-level protocols are in place and a uniform system for network addressing exists, the source may be the Ethernet node on my desk, running on 10BaseT, connected via satellite link to a Macintosh workstation on an FDDI network in Beijing; but to the applications on each of the machines, these technologies are completely irrelevant.
In addition to this service, several additional functions may take place at the network layer, including
These functions may look suspiciously like those frequently provided by data link layer protocols; in fact, they are. The difference is that these functions must now be provided for the entire end-to-end transmission from the source to the destination and not simply to the next adjacent node. This factor greatly complicates the performance of these functions, and indeed, in many systems, some or all of them are deferred to other layers of the model for that reason.
This complication is because an internetwork transmission involves not only the two end systems, which contain all seven layers of the OSI model and represent the sender and the recipient of the packet, but also one or more intermediate systems, or routers, whose functionality reaches no higher than the network, data link, and physical layers and through which the packets must pass in order to reach their destination (see fig. 3.11). Intermediate systems may also be known by many other names, such as packet switch nodes, data switching exchanges, or interface message processors (IMPs). The properties of the intermediate systems and the limitations imposed by them may vary widely, depending on the nature of the link that they provide. WANs may use links between remote locations that are far slower and place greater limitations on packet length than local area systems. In addition, complex networks may provide a multiplicity of possible paths to the destination, through various combinations of intermediate systems.
Figure 3.11
Network layer routing between networks forces packets to traverse the lower layers
of intermediate systems.
Also understand that packets from different sources and intended for different destinations will be passing through the same intermediate systems on a regular basis. This is the basic method of multiplexing used by data networks. Like a single-lane highway with many on- and off-ramps, packets are placed onto the network by individual workstations, through their appropriate MAC methods. Depending on the traffic patterns at any one moment and the type of protocol being used, the flow of packets may be redirected to take advantage of a lesser populated avenue. Thus, packets may arrive at their destination in a different order from that in which they were transmitted and by several different routes.
In light of these factors, the task of providing the functions discussed in the previous section is complicated enormously. For example, to provide flow control at this level--that is, some means of informing a sending system that it must temporarily cease its transmissions because the receiving station is being overwhelmed or suffering data loss--each possible path that might be taken from end system to end system must be treated as a separate entity. This is called a connection, which is established before the transmission and broken down afterwards.
This is because the station that is receiving too much data may be an end system or one of many intermediate systems. The request to cease transmitting must be directed only at the stations transmitting packets to that system or traffic may be halted at other locations unnecessarily. The flow control message must also be directed at all of the systems transmitting to the overwhelmed station or packets may be lost unnecessarily. The reaction of a sending station will be to cease transmitting for a time, until traffic conditions ease, after which it will resume. To provide this kind of functionality, logical channel identifiers are created for each connection before data is transmitted and destroyed when the connection is broken. These identifiers are used in flow control messages to indicate the exact process in need of attention.
What has just been described is known as a connection-oriented protocol (CO protocol). This is a protocol where a logical connection from source to destination is established before every transaction and an acknowledgment of successful transmission returned afterwards. A transaction may be defined as an exchange of binary messages, intended to accomplish a single purpose (such as a request that a file be sent from a server to a workstation and the subsequent return of the file), which has been split into a series of discrete packets to facilitate transmission over the network. Some protocols operating at the network layer, such as X.25 (created by the CCITT and the most widely implemented of the native OSI protocols), are connection-oriented, providing the full range of services listed earlier for the entire end-to-end transmission, as illustrated in the following steps:
In such transmissions, the accurate and timely transmission of data is absolutely guaranteed by the individual acknowledgment of every packet and the retransmission of any missing packets. The establishment of the logical connection also guarantees that the packets will arrive at the destination in the same order that they were sent. The classic simile likens a connection-oriented protocol to a telephone call, exchanging enough information between end systems to establish a connection before any information (that is, speech) is transmitted. Creating a protocol to enact such a transmission on a data network is an extraordinarily complex undertaking, and the amount of control data needed to perform all of the tasks necessary for every transaction adds significantly to the overall network traffic.
Because of this overhead, there are occasions when the flow control and error correction functions need not be performed by the network protocol. They may be undertaken by another layer in the OSI model (usually the transport layer), thus rendering them redundant here, or depending on the function of the packets being transmitted, they may not be needed at all. For example, a particular transaction may call for the regular transmission of only one packet every few minutes. Establishing a logical connection and leaving it open for occasional use such as this would be a waste of usable bandwidth.
The network layer protocol may then, at times, perform only the routing and framing functions needed for end-to-end transmission, as well as error detection (but not correction). When this is the case, the establishment of the logical end-to-end connection is unnecessary, as are the extra signals used to create it, break it down, and send flow control and retransmission instructions back to the source. In fact, the only packets that need be transmitted for this type of protocol are those containing the data itself.
This is called a connectionless protocol (CL protocol), and the price of its economy is a lesser degree of reliability. Packets, also called datagrams in a connectionless service, may be lost during transmission, due to corruption or traffic congestion, and the network layer will have no means of compensating for the loss or even, in some cases, of being aware of it. This means that incomplete transactions must be dealt with by the higher layers, thus introducing a greater penalty in time and traffic overhead, as a result, but only when packets are actually lost. In many of the cases where connectionless protocols are employed, this penalty amounts to less delay than would be entailed by the use of a CO protocol. If a CO protocol is akin to a telephone call, then a connectionless one is usually compared to a postal service. Packets are sent on their way with what is hoped to be a valid address, and the system takes over from there, providing the source with no indication of the packet's successful delivery, other than a possible complaint by the recipient at a later time. The Connectionless Network Protocol (CLNP) is the name of the OSI implementation of an unacknowledged network layer service.
The absence of a logical connection also means that individual packets belonging to a single transaction may take different routes to their destination, arriving at different times, and in a different order from that in which they were transmitted. In some cases, this can be an advantage, as datagrams can be dynamically rerouted to avoid network traffic delays in situations where a CO protocol would have to halt transmission entirely. The upper layers of the OSI model, however, will be required to have a mechanism that can compensate for this, reordering the packets at the end system and verifying that all of the required datagrams for a particular transaction have arrived, before that transaction is processed. Every datagram transmitted must also contain a complete address to the destination node, while CO packets need only contain a logical channel identifier, thus lowering the amount of overhead data carried by the individual packets. Still, however, a CO transaction will contain far more control overhead than a CL one.
Within the committees that were tasked to create the OSI model, the question of whether a connection-oriented or connectionless protocol should be used at the network layer was a heated one, that was never fully resolved. Facilities for both types of protocols are therefore included in the specifications. For the purposes of the LAN communications that are our primary concern, however, the most commonly implemented networks in use today utilize a connectionless protocol at the network layer. Novell's IPX (Internetwork Packet Exchange), IP (Internet Protocol), and AppleTalk's Datagram Delivery Protocol (DDP) are all connectionless protocols, but each is part of a suite that also includes higher-layer connection-oriented protocols of various types. Although the connection-oriented protocol itself may be very complex, it is a rather simple matter to implement one using the connectionless service at the network layer as a carrier. This allows the network operating system to select the appropriate level of reliability to suit the task at hand.
WAN links, on the other hand, are more likely to utilize a connection-oriented protocol. As a service usually provided to a privately owned network by an outside agency, WAN links trade on their reliability, and it is more practical for them to provide that reliability themselves, than to be dependent upon the higher-level equipment at each end of the link, over which they have no control. The conflict within the standards committees over the CO versus CL issue ended up primarily being a dispute between digital communications service providers, such as public telephone and telegraph companies (PTTs), and the manufacturers of the networking equipment linked by such services. Each preferred to rely on its own products for the higher-level functions like flow control and error correction. The outcome of this conflict was a very advantageous one, however. The two opposing camps essentially compromised, agreeing to include both CO and CL protocols into the specifications and continuing to develop and maintain their respective mechanisms for providing reliable service. There are now, therefore, mature and well-developed systems of both types available for use by the designers of networks.
The transport layer (see fig. 3.12), as its primary function, provides the balance of the essential services not provided by the network layer protocol. A full-featured CO protocol at the network layer results in a relatively simple transport layer protocol, but as the functionality at the network layer diminishes, the complexity of the transport layer increases. The transport layer's task, therefore, is to provide whatever functions are necessary to elevate the network's quality of service (QOS) to a level suitable for the communications required of it.
Figure 3.12
The transport layer of the OSI model, together with the network layer, provide the
functionality for a complete end-to-end transmission.
To perform this service, the transport layer, like the network layer, has the flexibility to utilize CO or CL protocols. The selection of the appropriate protocol to the task is referred to as mapping a transport service onto the network service, and any combination of service types is available. A CO transport protocol can be mapped onto a CO or a CL network protocol, and the same is true for a CL transport protocol (see fig. 3.13).
Figure 3.13
Protocol mapping in the network and transport layers allows for any combination
of CO and CL protocols to be used in combination.
However, whatever protocol the transport layer uses, it relies completely on the network and lower-layer protocols to carry the data to its destination. In fact, the transport layer, along with the session and presentation layers above it, are both literally and figuratively the center of the OSI model. They operate solely within the two end systems involved in any network transaction, independently from the communications techniques below and the application above. They service the latter and are serviced by the former but remain isolated in their functionality.
When defining the quality of service mentioned in the previous section, we are referring to a series of criteria that, when applied to the transport layer, comprise both the requirements of the application at the top of the OSI model and the features furnished by the layers below. The transport layer attempts to bring as many of these criteria, which are the same as those used by the network layer, up to the level of quality requested by the application as it can. QOS criteria do exist, however, over which the transport layer has no control. Inherent limitations of the network itself cannot be affected by the end systems which utilize it. No attempt is made by the transport layer, therefore, to address these deficiencies.
In the majority of transactions, the level of quality requested by the application amounts to the capabilities of what we have defined as a CO service. Applications do exist that require only the services of a CL protocol, and the OSI model does contain specifications for CL service all the way up to the top layer. However, these are comparatively rare, and the following material is concerned with the varying degrees of CO service that are more frequently requested. The main criteria used to evaluate a network's quality of service, which can be addressed by the transport layer, are as follows:
To address as many of these issues as possible, the transport layer, as defined in the OSI model, selects one protocol out of five classes of CO functionality for use with each transaction. Based upon a single generalized implementation, varying levels of service are provided by each class, thus avoiding the need for the development of five completely separate protocols while providing only the services needed for any particular transaction. The five classes of transport protocol are numbered from TP0 to TP4 and provide CO functions as follows:
The following sections clarify the functions and techniques used in these transport layer protocols, illustrating the ways in which they serve to address the QOS criteria.
Multiplexing--that is, a process by which several discrete signals can be combined for transmission over a single communications channel--is used to address both the cost of network communications and the amount of bandwidth available to the communicating entities.
Reducing the cost of communications is, logically, dependent on the way in which the network medium is tariffed. For a privately owned LAN, this is clearly a physical layer issue, but wide area links between remote sites can incur usage charges according to a number of different models. One of the most common ways of charging for such a link is to combine a fee for the actual amount of data transmitted with a charge for the amount of time that the connection remains open. The only way of affecting the amount of data transmitted is through compression, but this, strangely enough, is not considered to be a part of the transport layer, according to the OSI model. It is, instead, included with encryption as part of the presentation layer, dealt with later in this chapter, in the section "The Presentation Layer."
If the amount of data is to remain constant, then the only way of lowering communications costs is by reducing the time that the connection remains active. This is done so routinely on WANs that its advantages are often taken for granted. If multiple workstations at one location require access to resources at a remote site, a non-multiplexing system requires that a dedicated link be established for each and every workstation during the entire time that access is required. Multiplexing the data from all of the workstations into one link effectively lowers the connect time charges enormously, as long as all of the workstations require access at the same time.
This is a function of the logical channel identifiers introduced earlier in this chapter, in the section on the network layer. Each packet being sent over a single connection includes fields within its frame that identify the workstation and application processes from which it originates and to which it is destined. While on a LAN, individual connections are used for each workstation's transactions, a single wide area connection can be used to service dozens or even hundreds of workstations at each side of the link. This type of multiplexing, in which a single link is used to service several transactions simultaneously, is called upwards multiplexing (see fig. 3.14).
Figure 3.14
Upwards multiplexing combines several signals for transmission over a single connection.
Were you to look at figure 3.14 upside down, it would give you some idea of the opposite procedure used by the transport layer, called downwards multiplexing. This is a technique that can be used to maximize the bandwidth available to a particular process, thus addressing one of the other quality of service criteria. When the entire bandwidth of a link between two end systems is completely occupied by the transmission of a single transaction, the only way that an improvement can be realized (disregarding the use of compression, once again) is to utilize additional links. Downwards multiplexing is actually a process where a single signal is, in effect, de-multiplexed into several discrete data streams and then transmitted over multiple links to the destination end system, where it is re-multiplexed into a single transaction again.
The problem inherent in this technique is that packets arriving at the destination are almost sure to be in an order different from that in which they were transmitted. It is therefore necessary for each packet in a single transaction to be numbered so that it can be reassembled into the proper order at the destination. Fortunately, this process is completely identical to the packet sequencing that is needed when a CL network protocol is used for transmission. Therefore, no additional protocol development need be performed or control overhead added to take advantage of this technique.
Obviously, these two multiplexing techniques are mutually exclusive, with each one aiding in the increase of service quality in one criterion, while being directly detrimental to another. A selection must be made as to which is preferable, reduced operational cost or increased bandwidth, but with the proper facilities, this decision can conceivably be made dynamically in accordance with the needs of the individual data transaction.
Recovery from communications errors, in the form of retransmitted packets, is performed under several possible conditions at the transport layer. For CO protocols, the simplest of these procedures is the recovery from signaled errors. Signaled errors are dropped or corrupted packets whose absence or damage has already been detected by a lower-level protocol and relayed to the transport layer. To facilitate these recoveries, every packet must be numbered and stored at the source, only being discarded when a positive acknowledgment has been received from the destination end system.
Since the packets have already been identified by earlier processes, the transport layer must do nothing more than send a message back to the source listing the packets required and requesting their retransmission. When the X.25 protocol is used at the network layer, the process is even easier. A special delivery bit can be included in its frame that returns a receipt acknowledgment only if the packet has been checked and accepted by the transport layer of the destination end system. This allows successfully received packets to be erased from the source buffers without explicit messages from the destination instructing them to do so. The use of this bit, however, is optional, and provisions must always be made for the generation of the appropriate retransmission requests. The TP1 and TP3 protocols are both capable of providing this form of error recovery.
The recovery of unsignaled errors presents an entirely different and far more complex problem. Since the lost packets have not been detected by any previous process, their numbering and storage, as well as the generation of acknowledgment messages and retransmission requests and the reordering of out-of-sequence packets must all be performed by the transport layer protocol. In short, the entire complement of CO services must be provided by this one protocol, thus making it the only choice suitable for use with a connectionless network layer protocol when CO services to the application layer are required. Of the OSI transport protocols, only TP4 is capable of this service.
TP4 also contains an additional error checking capability. The standard CRC error checking calculation performed by the data link layer can only detect errors occurring during the transmission over an individual link. When a packet is received at its destination, and the CRC recalculated, a certain degree of discrepancy is expected, due to elements in the header that are routinely modified during transmission. IP, the connectionless Internet protocol, made some attempt to overcome this by altering the CRC value according to changes made to the packet frame, but the TP4 protocol goes a step farther by calculating the CRC value only on the packet contents that are supposed to remain consistent throughout the transmission, and then checking it upon receipt at the transport layer of the end system. This provides a level of end-to-end CRC checking above and beyond any that is provided at the lower layers.
It should be reiterated here that the OSI model only defines a framework for the development of a networking system. Many NOSs do not implement all of the layers and classes of protocols defined in the OSI specifications, providing instead only those needed for their own purposes. Indeed, a simplistic, monolithic NOS could be developed utilizing only a single protocol, although its usefulness would likely be quite limited. Many implementations of the actual OSI protocols themselves do not supply all of the classes of transport protocols previously outlined. Most include only TP0 and TP4, with the latter running over the CL network service, although it is capable of being used with a CO network layer as well.
In the same way, few other networking systems provide the assortment of transport layer options defined in the OSI specifications. The predominant transport layer service in the NetWare native protocol suite is Sequenced Packet Exchange (SPX) and the Transmission Control Protocol (TCP) is its counterpart in the Internet protocol suite. These are both CO protocols that generate quite large amounts of control traffic to guarantee the reliability of their transmissions. As a result, they are used only when the quality of service required by a particular application demands it.
We now arrive at the session layer and pass beyond all concerns for transmission reliability, error checking, flow control, and the like. All that can be done in these areas has been done by the time that the transport layer functions have been completed. The session layer is the most misunderstood service in the OSI model (see fig. 3.15), and a great deal of discussion has gone into the question of whether its functions even warrant a layer of their own. Because of its name, it is often thought (mistakenly) to be concerned with the network logon procedure and related matters of security. The other common description is that it is concerned with matters of "dialogue control and dialogue separation." This is actually true, but more often than not, these expressions are left undefined in such treatments.
Figure 3.15
The session layer of the OSI model is responsible for a multitude of frequently misunderstood
functions.
The session layer specification cannot be thought of as having a primary function or a single reason for its presence, as the lower layers do. It functions more as a "tool kit" for the upper layers, providing 22 different services, many of them quite obscure to anyone but application developers. In fact, due to a compromise between two committees creating rival session standards, there are in many cases two tools in the kit for each task that it can perform. Clever application developers have sometimes taken this opportunity to create different uses within their applications for the same tool.
We must, at this point, digress for a moment to discuss in more detail the way that the functions for each layer of the OSI model are actually documented in the specifications. Each layer in the model provides services to the layer immediately above it--services which are requested by the issuance of commands called service request primitives. Therefore, a request by a workstation's application layer for access to a particular network resource originates with the passing of the appropriate service primitive (plus any additional parameters required) to the presentation layer below it. The request is then relayed down the layers of the model, in each case utilizing the appropriate primitive for that layer, thus causing the appropriate frame to be added to the packet. After transmission to the destination, the packet is decoded into indication primitives that are passed up the model to the receiving application.
These primitives are the tools of the toolkit, which in the session layer are broken down into a number of subsets containing primitives associated in their functionality, the use of which are negotiated during the establishment of the session connection. Apart from the Kernel Function Unit (KFU), containing basic primitives that are always available for use, there are 12 other functional units, among them the Basic Activity Subset (BAS), the Basic Combined Subset (BCS), and the Basic Synchronization Subset (BSS). When matters of compatibility with other systems caused a conflict between two proposed session layer standards, the primitives from both were, in many cases, adopted into the one final standard. This causes no inherent harm, except for a bit of confusion and the occasional argument between developers as to which set of primitives should be used.
But to return to the actual functions of the session layer, it is true, as mentioned earlier, that of its many functions, the most important are dialogue control and dialogue separation. "Dialogue," in these instances, refers to the exchange of data between two end systems linked by a logical connection. The session layer controls the way in which this dialogue is conducted during the connection. This is not to say, however, that it is concerned with the nature of the data being transmitted. Instead, its province is the flow of messages back and forth between the two end systems, and the impact that the functions requested by the application may have on that flow.
In other words, when one end system receives a message from the other end system to which it is connected, it has no way of knowing whether or not that message is based on the data that it has most recently transmitted. The message being received could have been transmitted by the other station while a packet was still in transit in the other direction. Collision cases such as this can present numerous problems, particularly when one end system requests that the connection between the two systems be broken, or when one of the two end systems attempts to perform a checkpoint operation. Check-pointing is a process in which an application writes the entire state of its current status to disk, as a safety measure. For an application running on a single, isolated PC, this is a simple affair, but for a distributed network application, a reliable checkpoint must reflect the states of two or more machines at the same exact moment and account for any data in transit as well.
The process by which the session layer provides an orderly means of initiating the contact between end systems, exchanging messages between the two, and ultimately releasing the connection, all the while ensuring that both systems have received all of the data intended for them, is known as dialogue control. The method by which it can insert a reference point into the data stream that serves as a division marker at which the state of both end systems can be assessed (or other functions performed) is called data separation.
The basic alternatives that the session layer makes available to two end systems when initiating a dialogue are called two-way alternate mode (TWA) and two-way simultaneous mode (TWS). The mode selection made at the establishment of the session connection is an irrevocable one. The mode cannot be changed without terminating the connection and reestablishing it (and this is considered by some to be a considerable drawback to the session layer model). Two-way alternate mode allows only one of the two end systems to transmit data at any one time. At the conclusion of its transmission it sends a data token to the other system using the S-TOKEN-GIVE primitive, upon receipt of which, permission to transmit is transferred to the other system. Another primitive, called S-TOKEN-PLEASE, also exists, with which one system can request the token from another.
Two points must be made concerning these exchanges. First, it must always be remembered that we are now in the session layer. When we speak of connections, tokens, and dialogue, we are most definitely not referring to the similar concepts that exist at the lower layers. Permission to transmit at the session layer is in no way involved with MAC, nor is the token used here related to that of the IEEE 802.5 Token Ring specification. These lower layer processes are services that the session layer may make use of. Their operational efficiency is assumed by the session layer to be completely reliable. They are a fact and not a factor of the session service.
The second point is that the actions of mode selection and passing and requesting the data token are not to be seen as an automatic, transparent process, in the way that many of the lower-level functions are. It is not a matter of a higher-level process turning a figurative ignition key and setting an elaborate hidden machine into operation without knowing how it actually works. These functions are rather to be thought of as explicit processes that must be specifically requested by the application layer (and relayed through the presentation layer). A particular application may utilize the S-TOKEN-PLEASE primitive, for example, or it may rely solely on S-TOKEN GIVE, depending on the whim of the developer. This is why the concept of service primitives has been introduced here, and these services referred to as tools.
The token-passing method adequately resolves the problem of messages being left in transit while action is already being taken by its intended recipient. It also provides a means for breaking down the session connection, through a process called orderly termination. To avoid any confusion between systems, each session connection is assigned a unique identifier composed of the following four parts:
When one end system of a particular connection signals its desire to terminate its communications session, it passes the data token and stops transmitting data but remains open to incoming messages. The other end system then receives the token, transmits any outstanding data it may still have in its buffers, and acknowledges the request to terminate by sending the S-RELEASE primitive. The original end system then confirms the release and is free to issue the S-DISCONNECT command, secure in the knowledge that there is no data currently in transmission or waiting to be transmitted. There are two special situations worth noting in which problems arise with this method. One is when both end systems request a release at once, causing a collision (once again, not to be confused with a MAC collision). To prevent this instance, the session layer specification also provides a negotiated release feature, by which an end system can refuse the other system's request, and the capability to utilize a special release token, which prevents both systems from issuing the S-RELEASE command simultaneously. The other is when a session layer option is used that results in the orderly termination of the session layer connection (through the normal method shown previously), while leaving the transport layer connection open for use by another application.
A problem can arise if the second application chooses to make use of a service primitive called S-EXPEDITED, which is designed to deliver data to its destination faster than a normal transmission would. In some cases, this could result in the expedited data arriving at the other end system before the release negotiation has been completed and therefore being delivered to the wrong application. To prevent this, the transport connection cannot be left open during a release negotiation when data is being expedited. This instance is indicative of the way that the designers of standards and protocols must attempt to anticipate the actions taken by application developers. Situations such as these often arise after a standard has been completed, forcing the creation of an amendment to the existing document. The task of standard development is one that is never truly completed.
With all of these mechanisms in place, the whole release negotiation process functions very nicely and is not terribly difficult to implement, from a protocol designer's perspective. The problem is that neither is it terribly efficient. If the round trip transmission time between the two end systems is of any significant length, such as when connected by a WAN link, two-way alternate mode communications can be very tedious and unsuitable for some applications. This is why the capability for the selection of two-way simultaneous mode communications is provided by the session layer, although it provides no mechanism facilitating the actual performance of these communications, as it does with TWA mode. In fact, from the session layer perspective, TWS is a "do nothing" protocol. Like TP0 at the transport layer, it indicates that the specifics of the process are being handled elsewhere.
We have seen that dialogue control is enacted by allowing the application layer a choice of communications modes upon establishing a session connection. (As an aside, it should be mentioned the repeated references to the application layer requesting services of the session layer actually include the intervention of the presentation layer in between. A process can only make requests to the layer immediately beneath it, and the presentation layer contains duplicate primitives that serve to relay the requests down to the session layer.) To approach the matter of dialogue separation, we will again see a difference in functionality provided by the selection of TWA or TWS mode. The dialogue separation mechanisms for both modes, however, are conducted here, at the session layer, and the way in which they differ is sufficiently illustrative of the way that two-way simultaneous transmission complicates these processes enormously.
We have previously defined dialogue separation as a mechanism by which an application can be checkpointed--that is, its current status at any one time saved to disk in case of systems failure. At the time when the session layer was being developed, such failures were far more common than they are today and checkpointing was a crucial aspect of any distributed application. It must be emphasized, however, that the checkpointing operation is most definitely part of the application. The session layer knows nothing about it, per se. It simply provides, in dialogue separation, a service to the application developer, another tool that she can use.
Performing any activity on two different systems at precisely the same moment is a virtually impossible task, especially in computing, where thousands of activities can be performed every second. Even the prospect of transmitting a signal meaning "NOW" would entail a certain amount of transmission delay before it reached its destination. Synchronization between two end systems cannot, therefore, be achieved by any method that relies on one system for control or individual clocking by each of a previously scheduled event, and even if it could, the problem still remains of how to account for any packets that may be in transit between the two machines when the event occurs.
Some means must then be provided by which the two machines can mark a particular unified point, not in time, but in the exchange of data between the two. For end systems between which data is flowing in only one direction at any particular time, such as in TWA mode, the process is quite simple. A particular service primitive, called S-SYNC-MINOR, is transmitted by one system, essentially placing a point of separation into the data stream. When used for checkpointing, the sending system saves its status upon transmitting this primitive and the receiving system performs its own checkpoint upon receiving it. Thus, it can be certain that no unprocessed data is left in the channel at the synchronization point. This is called a minor synchronization because it only involves one exchange of control information and accounts for data flowing in only one direction at a time.
This technique is not limited to use in TWA connections, however, and accommodations have been made for the possibility of a collision between two S-SYNC-MINOR commands sent at the same time by the two end systems. A special token, distinct from the data token mentioned earlier, and called the minor synchronization token, is used to control which of the two end systems has permission to transmit the S-SYNC-MINOR request at any one time. The need for this additional token could be eliminated if the session layer allowed a connection to switch between two-way alternate and two-way simultaneous modes. In that case, the TWA data token could be used, but since this doesn't exist in TWS mode, an additional token is needed.
The use of two-way simultaneous communications, of course, complicates matters. Not only must transmissions from both end systems reach their respective destinations before a separation point can be determined, but the potential for expedited data from both sides must also be taken into account. Data that is transmitted using the S-EXPEDITED primitive can be thought of as having a separate high-speed pipeline to its destination, independent of the channel used by normal communications. Both of these must be flushed in sequence for a proper dialogue separation to occur.
This is called a major synchronization, and it begins with the transmission of the S-SYNC-MAJOR command by one end system. Clearly, the application cannot perform a check-pointing operation at the time of the primitive's transmission, as data may still be on its way to the system originating the request. In this case, it is the recipient of the primitive that first establishes a separation point, at the moment when S-SYNC-MAJOR is received. Meanwhile, the sender has stopped transmitting but continues to listen, awaiting a response to its request. The receiver of the primitive, therefore, establishes its own separation point, confident that all traffic from the sender has been received (including expedited traffic, which would have arrived before the SYNC primitive). At the same time, it transmits its confirmation of the SYNC primitive through the normal data channel, as well as a special PREPARE message back to the sender, through the expedited data pipe. The function of the PREPARE message, which will arrive before the SYNC confirmation, is to instruct the sender to buffer any expedited traffic arriving after the PREPARE for use by the second dialogue, which begins after the separation point is established at the sender's end system by the arrival of the SYNC confirmation. There is also, not surprisingly, yet another token, called the major/activity token (so-called because it has another use as well), which prevents collisions of two S-SYNC-MAJOR primitives from occurring.
In light of such affairs, it is perhaps no longer much of a secret why the session layer is so misunderstood. This seems like a terribly elaborate procedure to perform what should be a fairly innocuous task, but it is only one of many. For example, the handshake for the resynchronization that must be performed to restart the session connection using saved checkpoints is even more complex, requiring two PREPARE messages. This is what networking is all about, though. Simple-sounding problems often require enormously complex solutions that must remain totally transparent to other processes. At the beginning of this book, it was observed that the best running networks are those on which the users are unaware that they are even accessing a network resource. This same philosophy also holds true at every layer of the OSI model. Each layer is a "user" of the layer below, requesting services of it with little or no knowledge of how those services are performed.
Real world protocols that function at the session layer frequently overlap into areas that more strictly belong in the other information handling layers, presentation and application, as well as into the realm of the transport layer. Strict delineation of functions according to the OSI model is not a priority for most developers, as we have seen, but some of the protocols that can be said to provide session layer services are as follows:
As a contrast to the numerous and varying functions of the session layer, the presentation layer provides only one additional service (see fig. 3.16), embodied in the P-ALTER CONTEXT primitives. Aside from this one, the only other primitives that it contains are exact correlatives of the session layer primitives, used to pass requests for services from the application layer to the session layer, via the Presentation Service Access Point (PSAP) and the Session Service Access Point (SSAP).
Figure 3.16
The presentation layer of the OSI model performs only a single function: the translation
of different types of system syntax.
The PSAP and SSAP functions are not necessarily "do nothing" functions, however. While they do not affect the nature of the application requests or the services being requested, some of them do perform a vital translation function. A request from the application layer necessarily utilizes the native syntax of the application to generate that request. The application for which it is destined, at the other end system, may utilize a completely different syntax or bit-coding format. For example, a connection between a PC and a mainframe may require a conversion from the EBCDIC character encoding format to ASCII and many other factors may have to be considered as well. For this translation to occur, the presentation layer on both end systems is responsible for converting the system's native application layer syntax, also known as the abstract syntax, to a common transfer syntax, suitable for transmission to the other end system through the network medium.
Other factors are also considered when a transfer syntax is chosen, based on the nature of the individual presentation layer connection. Functions like data compression and encryption can be chosen, based upon the limitations of the link between the two end systems. For example, a high-speed secure FDDI link between two buildings requires little in the way of compression or encryption. These features only require additional processing time and clock cycles by both end systems, providing little real value as a result. A dialup connection using modems and public phone lines, on the other hand, is a situation in which the additional processing overhead more than offsets the savings in transmission time and additional security, should compression and encryption be used to their fullest. The negotiation by which the appropriate transfer syntax is selected for a particular connection is where the P-ALTER-CONTEXT primitives enter the picture.
For the presentation layers of the two end systems to negotiate the proper syntaxes to be used in their communications, a series of presentation contexts are sent, along with the P-CONNECT primitive, by the system initiating the connection. A presentation context is an association, identified with a unique odd-numbered integer called the presentation context identifier, between an abstract syntax and a particular transfer syntax. The sending machine is essentially informing the intended recipient of its translating capabilities. Several transfer syntaxes may be specified for any single abstract syntax. The receiving system passes the list of contexts up to the application layer, which decides on the use of a particular transfer syntax for every abstract syntax on the list (assuming that both systems can support at least one of the transfer syntaxes listed).
This list, now containing either a single transfer syntax or an error message for each abstract syntax, is passed down again to the presentation layer of the receiving system for transmission back to the sender. Once returned, this list becomes the defined context set for that connection. If any of the abstract syntaxes cannot be supported by a common transfer syntax, an error message is supplied containing the reason for the failure. Additional presentation contexts can then be proposed for addition to the defined context list, using the P-ALTER-CONTEXT primitive.
This primitive can also be used to remove contexts from the defined set, leaving the presentation protocol open to the same collision problems that afflicted the dialogue separation procedures at the session layer. That is, the possibility exists for a message requiring a particular presentation context to arrive at a system where that context has already been removed from the defined context set. It took over a year for the standards committees to agree on an implementation that resolved most (but not quite all) of these problems. The solution is based on a context restoration procedure (from a pre-existing checkpoint) that is similar to the resynchronization mechanisms of the session layer. After all of this work, however, virtually no application designers have made use of the context restoration mechanism supplied by the standard.
A similar situation exists as far as the notation schemes and encoding rules for the abstract and transfer syntaxes are concerned. Great pains were taken to create a standard that allows the use of different types of encoding, but years later, there still remains only one object naming standard that is used for abstract syntaxes, ASN.1 (Abstract Syntax Notation One, also known as ISO 8824), and one encoding scheme for transfer syntaxes, the Basic Encoding Rules (ISO 8825). This has actually caused a certain amount of consternation to some because minor attributes of these standards are particularly suitable for use with the OSI presentation layer (such as the restriction of their field lengths to multiples of eight bits), and yet these attributes are not included as part of the 7498 or X.200 standards. Issues like these are rapidly progressing to the point at which they are of interest to the standards committees and to virtually no one else. As we have seen, the realities of practical business networking often have only a limited relationship to the theories of the OSI model. We may well have arrived at the time when it is best to abandon hope of creating a practical networking system that is completely compliant with the OSI model and leave these minor points until an actual need to resolve them arises.
Finally, we arrive at the top of the OSI model, and the reason for its existence in the first place. The application layer, as shown in figure 3.17, is of course, the actual interface used by every application that requires network access for any reason. The application may be a word processor attempting to open a file that just happens to be stored on a file server volume. This involves a basic local function that is being redirected to the application layer and the rest of the OSI stack to access remote resources. The application may also be one that exists solely for the purpose of providing an interface to a network resource, functioning like an executable protocol, such as Telnet or FTP. In either case and many others in between, including e-mail, database access, and file and network management, the application layer of the model provides the tools needed to access those network resources. It is, essentially, a window between application functions located on remote systems.
Figure 3.17
The application layer of the OSI model provides the actual interface between the
workstation application and the network.
Because of the immense array of applications requiring network access, the application layer is, necessarily, the most diverse in its capabilities. Protocols running at this level can be extremely complex, requiring entire chapters or even books of their own for a full exploration, or relatively simple, performing a small set of tasks for a highly specific purpose. Many of the protocols also tend to span the boundaries of the top three layers in the OSI model in their capabilities. Once the communications issues of the lower subnet are dealt with, the barriers between layers become more fluid, and entities like Novell's NetWare Core Protocols, which account for the bulk of the communications on a NetWare network, tend to span all of the information handling layers.
For a well-defined OSI-based protocol stack, the application layer should account for up to 90% of the bits actually transmitted over the network. The efficiency of the overall network is therefore more dependent on the application layer than on any other. Application layer function protocols may request services provided by the presentation layer, below, or they may access libraries of commonly used functions that are codifed into what are known as application service elements (ASEs), which group together related functions or tools. Either of these resources may be called upon by the application programmer at will. Originally, the ASEs were divided into common application service elements (CASEs), which contained more generic sets of services, usable by many different applications, and specific application service elements (SASEs), which are more likely to apply to a single application or type of application and which make use of the infrastructure created with the CASEs. The distinction between these two has become somewhat indistinct over the years, however, and the use of these terms was officially abandoned in the late 1980s, although they still remain useful for tutorial purposes.
All of the basic standards of the application layer are now referred to simply as ASEs, which have no component parts and which do not make use of other ASEs. Instead, the concept of the application service object (ASO) was introduced by the Extended Application Layer Structure (XALS) document, which was published as an amendment to ISO standard 9545 in 1992. An ASO is a collection of (other) ASOs or ASEs, bound together by a control function, which determines how the different elements interact. This was done to reconcile the possibility for conflicts that could arise between the properties of different ASEs in use at the same time, such as the use by one of the session layer TWA mode, while another uses the TWS mode. Access to these is still provided by application program interface calls (APIs), however, which are the tools used by application developers to call upon specific functions from within their programs.
It must be noted that there is some trepidation on the part of the OSI standards committees as to whether the changes in the preceding paragraph should be formally integrated into their standard as well. Once again, from a practical level, it probably doesn't matter. We are dealing with questions of architecture here; more in terms of how processes are documented than of how they are constructed. These changes will not have a profound effect on actual network communications. They are merely an attempt to recognize a problem with the existing standard and provide as cogent a remedy as possible.
Some of the more important ASEs are discussed in the following sections.
This is an ASE that is used by all applications requiring network access. It allows an association to be made between two application processes (APs) located on different end systems. At the application layer, we speak of associations between applications and not connections. Technically, a connection is defined as an interface between corresponding layers of the OSI model on two end systems, which provides an association between the next higher layers on both systems. Since the application layer is at the top of the model, the term connection is inappropriate, but an association may be said to exist, as a result of the efforts of the presentation layer. In other words, an application developer may choose to employ the A-ASSOCIATE primitive defined in the ACSE standard to make contact with an application running on a remote end system. As a result, a P-CONNECT command is issued at the presentation layer, and an association between the two applications ensues. Once the association is established, the ACSE is not used until termination of the association is requested or occurs for another reason. Loss of the presentation connection also entails the loss of the association, and the ACSE contains primitives to compensate for the abnormal termination.
Originally created for use by the X.400 e-mail application protocol (an enormous subject worthy of a book in itself), ROSE and RTSE are exceptional in that they are simple, basic, and functional, with no major developmental problems that protocol developers need to address. ROSE is an ASE that is designed to facilitate the sending of messages that invoke a specified function on a remote system and is often used in remote procedure calls (RPCs). The function itself is not a part of the ASE. ROSE is simply a support service for the delivery of the request or reply. It can function in synchronous or asynchronous mode, with the reply, when in synchronous mode, to a request being sent as part of a single association. Asynchronous mode is analogous to connectionless communications, in which a reply may or may not be returned and no guarantee of reliability is given. ROSE is commonly used by LAN operating systems for brief transactions that do not require the retention of large amounts of state information.
RTSE is guaranteed delivery service utilized by ROSE, as well as by other application processes. It is the mechanism by which the application layer retries a communication process that has failed irrevocably at the lower layers, either through resending of messages or through the reestablishment of lost connections. It also provides transparent access to the full functionality of the presentation and session layers to an application without exposing it to their underlying complexities. Checkpointing, connection recovery, and like services can be provided without the need for the application to address specific primitives to the PSAP directly. RTSE (through ROSE) is the delivery mechanism used at the application layer for the MHS message handling system.
The CCRSE is used to coordinate multiple application processes that are intended to be performed as a single transaction. For example, database updates that require writes to multiple records can use CCRSE to ensure that either all or none of the individual updates are performed during the transaction. This is done through a two phase commitment in which each application entity must signal its ability to complete the required task before any of the updates are applied and the transaction deemed successful.
All of the preceding ASEs are examples of what would, in the past, have been correctly called CASEs. The following are examples of the more application-specific ASEs, formerly known as SASEs:
These examples attempt to portray the wide range of services that are demanded of the application layer (and by proxy, of the entire OSI model), but the full listing would be as long as a list of all of the features in all of the network applications now in use. Although the technicalities of the physical layer may seem complex, the scope and the functionality of the application layer dwarfs these concerns.
The OSI model is a construction that attempts to make an incredibly complicated system understandable to a greater audience. It can be approached even by the novice networker, to gain the most basic idea of what goes on between networked computers, or it can be used by the most advanced engineer, as an organizing tool for studies of extraordinary detail and complexity.
The OSI reference model is often illustrated in the form of a pyramid, with the application layer at the tip. This may be considered a valid metaphor, in light of the way in which each layer, from the top down, is packaged within the functionality of the next layer. But I think that a truer representation would be to show the pyramid upside-down, with the wide base of the application layer at the top, distilling its essence down to the trickle of pulses being emitted from a single pinhole at the bottom. This, to me, is a truer picture of the OSI model, and if you were to collect the printed documents detailing all of the standards involved in this immense undertaking, I daresay that such a model could be proportionately constructed out of them which would closely resemble figure 3.18.
Figure 3.18
In the true OSI pyramid, enormously complex tasks are boiled down to a thin stream
of impulses.
© Copyright, Macmillan Computer Publishing. All rights reserved.