The OSI Layer Model

We can qualify response times and flexibility using the OSI layer model, shown in Figure
8.2. The OSI model (Open System Interconnection, also known as Open Standard
Interconnection) was developed by ISO (International Standards Organization) in 1984
as a standard for data networking. The growth of distributed computing—that is, computers
networked together—has, however, made the OSI model increasingly relevant
as a means for assessing software performance.

At the Application layer, the software has to be very flexible. This means it must be
able to respond to a wide range of unpredictable user requests. Although the execution
of particular tasks may be real time (as defined earlier in the chapter), the tasks vary in
complexity and may require a number of interactive processes (semaphores and
alarms, for example) before the task can be considered as completed (a high degree of
interrupt latency).
As we move down the protocol stack, task execution becomes more deterministic.
For example, at the Physical layer, things are happening within very precise and predictable
time scales. Returning to our reference model, following are descriptions of
each protocol layer and the types of tasks performed:
Application layer (7). Windows CE, Symbian, or Java, for example, will look
after the user (the MMI and the housekeeping tasks associated with meeting the
user’s requirement), organizing display drivers, cursors, file transfer, naming
conventions, e-mail, diary, and directory management.
Presentation layer (6). This layer does work that is sufficiently repetitive to justify
a general solution—page layout, syntax and semantics, and data management.
HTML and XML are examples of Presentation layer protocols (for Web
page management).
Session layer (5). This layer organizes session conversations: The way our dialogue
is set up, maintained, and closed down. Session maintenance includes
recovery after a system crash or session failure—for example, determining how
much data needs resending. RSVP and SIP (covered later) are examples of Session
layer protocols.

Transport layer (4). This layer organizes end-to-end streaming and manages data
from the Session layer, including segmentation of packets for the Network layer.
The Transport layer helps to set up end-to-end paths through the network.
Transmission Control Protocol (TCP) is usually regarded as a Session layer protocol.
(SIP is also sometimes regarded as a Session layer protocol.)
Network layer (3). This layer looks after the end-to-end paths requested by the
Transport layer, manages congestion control, produces billing data, and resolves
addressing conflicts. Internet Protocol (IP) is usually considered as being a Network
layer protocol.
Data Link layer (2). This layer takes data (the packet stream) and organizes it
into data frames and acknowledgment frames, checks how much buffer space a
receiver has, and integrates flow control and error management. ATM, Ethernet,
and the GSM MAC (Media Access Control) protocols are all working at the Data
Link layer. GSM MAC, for example, looks after resource management—that is,
the radio bandwidth requirements needed from the Physical layer.
Physical layer (1). This layer can be wireless, infrared, twisted copper pair, coaxial,
or fiber. The Physical layer is the fulfillment layer—transmitting raw bits
over a wireless or wireline communication channel.
Any two devices can communicate, provided they have at least the bottom three
layers (see Figure 8.3). The more layers a device has, the more sophisticated—and
potentially the more valuable—it becomes.
As an example, Cisco started as a hardware company; most of its products (for
example, routers and switches) were in Layer 3 or 4. It acquired ArrowPoint, IPmobile,
Netiverse, SightPath, and PixStream—moving into higher layers to offer end-to-end
solutions (top three layers software, bottom four layers hardware and software). Cisco
has now started adding hardware accelerators into routers, however, to achieve acceptable
performance.

There is, therefore, no hard-and-fast rule as to whether software or hardware is used
in individual layers; it’s just a general rule of thumb that software is used higher up in
the stack and hardware further down. As we will see in our later chapters on network
hardware, the performance of Internet protocols, when presented with highly asynchronous
time-sensitive multiple traffic streams, is a key issue in network performance
optimization. We have to ensure the protocols do not destroy the value (including
time-dependent value) generated by the Application layer; the protocols must preserve
the properties of the offered traffic. 190