TCP/IP, OSI, AND OTHER COMMUNICATION PROTOCOL MODELS
The communication takes the form of a message or a group of messages between an application or service at one end node and a corresponding application or service at a second end node. The message can be a file being transferred between computers, a voice conversation from a cell phone to a friend 1500 miles (or, if you prefer, 2400 kilometers) away, a Web request, streaming video from YouTube to your tablet—in fact, anything that can be communicated in digital form. The message will be broken into packets, transmitted through the network, and restored at the receiving node into the original message. For one thing, we have specifically indicated the presence of the network interface controller, or more commonly, NIC, from that serves as the hardware interface between a computer and the network. This also serves to remind you that communicating with the network is still a form of I/O. We have also clearly marked some individual node-to-node links, as well as the multilinked end-to-end connection. These additions will help with the upcoming discussion. It is possible to implement the simplest forms of data communication with nothing more complicated than a message format that both ends agree on and a means to access the channel. Realistically, this simple approach is inadequate in most real-world situations. First and foremost, it is rare that there is a direct, single link, unshared channel between the hosts. Suppose that two or more computers are to communicate via a communication channel.
What
are the requirements for them to communicate successfully? As we already noted,
they must agree on the signaling methods and the means used to access the
connecting channel, but in addition there is much more. Even the format of the
message is more complicated than it first appears. How long is the message?
Which part of the message is actual data and which part is overhead information
such as the address of the sender and the address of the recipient? How should
the message be divided into packets for transmission through the network?
Each end of the communication
must recognize all of the commands and requests of the other and be able to
respond in a reasonable way. For example, if one computer speaks ASCII and the
other speaks Unicode or some other code, successful communication will not
occur unless they are aware of the difference and are prepared to perform the
translations back and forth. E-mail messages will become garbled or not reach
their destination if there isn’t agreement on the meaning of the name and
address on the “envelope”. What if there is no obvious communication path
between the sender and the receiver or one link of the path is missing? How do
the packets that contain the message get relayed appropriately through
intermediate nodes toward the receiving node?
How are errors to be detected by the receiver, and what will be done about them? How does the receiver know that it has received a complete message, and how does it reassemble a message from its packets, with the possibility that the packets may arrive in the wrong order? There are many more such issues, and it’s easy to see that communication is not trivial. Indeed, a substantial number of ground rules are required to satisfy all the conditions necessary to communicate successfully.
The ability to communicate between dissimilar computing and channel resources, the efficient use of channel resources, the ability to identify, associate, and locate specific addresses to which the messages are to be sent, and the ability to deliver messages through a complex system of channels are essential requirements for a successful message delivery system. Perhaps, most amazingly, it all works! Two slightly different, but overlapping, standard models address these goals and concerns.
The
Open Systems Interconnection Reference Model (OSI) is a theoretical
model, developed over many years as a standard by the International Standards
Organization (ISO). It is used primarily for research. TCP/IP is an
older and more practical model, independently developed to meet the needs of
the original Internet design, and regularly modified and updated to meet current
needs. Our focus is almost entirely on TCP/IP, but a comparison of OSI and
TCP/IP appears in Section.
Each model is conceived and
implemented as a hierarchical protocol stack, in which each layer of the
stack at the sending node contributes information that will be used by the
corresponding peer layer at the receiving node. (You can see the
similarity between the behavior of a protocol stack and the last-in, first-out
nature of other types of computer stacks that we have already discussed and
that you’ve also seen in programming courses.) As you will see, there are many
similarities between the OSI and TCP/IP models, despite the fact that they were
developed independently. A simplified view of the layered communication process
is shown in Figure. In each model, there is a suite of different protocols that
are designed to work together and to guide all aspects of network
communication.
As long as the interfaces between
layers are well defined, it is possible to separate the tasks. An individual
layer needs to be concerned only with the interfaces of the layers immediately
above it and below it. Ideally, the operation of a particular layer is
transparent to other layers and could be modified or replaced without affecting
other layers, provided that the layer continues to provide its required
services to the communication process and that there is agreement between the
equivalent, or peer, layers at the sending and receiving end nodes. Separating
the tasks involved in communication adds flexibility, simplifies design of the
protocols, makes it possible to modify protocols
or substitute alternative
protocols without affecting unrelated tasks, and allows a system to select only
the protocols that it needs for a particular application.
TCP/IP
is, by far, the prevalent protocol suite. Although the name suggests two
protocols, TCP/IP is actually a name encompassing an integrated suite
consisting of numerous protocols that control various aspects of data
communication, including end-to-end message handling, link management, routing
and link-to-link communication, error reporting, global address resolution, and
many other functions. The suite also includes a number of perhaps familiar
application protocols, including HTTP, SSH, FTP, SMTP, POP3, and many more.
Unofficially, the TCP/IP model consists of five layers.
PROGRAM APPLICATIONS VERSUS NETWORK APPLICATIONS
The TCP/IP protocol suite offers a large number of applications for use on a network. These include familiar ones such as HTTP, FTP, SSH, and MP4, but there are also applications for voice over IP telephony, video conferencing, IM, RSS news feeds, remote program execution, and much more. (Surprisingly, SMS, the mobile texting protocol standard, is not part of the TCP/IP protocol suite, but is maintained by a separate mobile phone standards organization.) Of all the TCP/IP applications, three applications: Web services, e-mail, and music and video sharing account for the vast majority of the traffic on the Internet. IP-based telephony is also increasingly important.
As
you will see later, it is also possible to add proprietary or nonstandard
network applications for use, provided that they are designed to interface
properly to the remainder of the protocol stack and provided that there is peer
agreement between the end nodes as to the meanings of the messages. The network
applications that we just discussed are members of the application layer,
which is the top level of the suite, sometimes referred to as layer 5.Amessage
from an application program, such as the Firefox web browser is passed to the
appropriate network application, in this case HTTP, to start the communication
process.
THE PHYSICAL AND DATA LINK LAYERS
The great majority of
communication links are based on Ethernet; most of those links are also
ultimately tied in to local area networks. There is no compelling technical
relationship between Ethernet and the concept of local area networks, although
they do work well together. Rather, they are closely related by the coincidence
of history. It is not difficult to envision other protocols that could be
implemented successfully in a local area network, nor is it difficult to
illustrate uses for Ethernet outside the local area network environment.
Accident or not, most individual communication links ultimately connect into
local area networks and Ethernet is the standard set of protocols of choice for
these connections. Ethernet comprises layers 1 and 2 of the TCP/IP protocol
suite, the physical layer and data link layer, respectively. Because the data
link layer directly controls the physical layer, we will consider them
together. Other protocols can and do occur at the physical and
data link layers, and coexist and interface with TCP/IP at the upper layers. As
an important example, cellular technology is often used as the initial link
between an end user and the network-at-large. Some public wide area network
suppliers also provide links that are based on alternatives to Ethernet. We
discuss some of these alternatives in Section 13.10. For now, though, we limit
the discussion to Ethernet. Let’s begin with a simple scenario: we’ll consider
what is required to move the bits of an Ethernet packet, called a frame,
through a single link from one node to another in a basic local area network.
(Non-Ethernet packets are also called frames at the data link layer.) As you will
see, the expansion of this discussion to encompass networks in general will be
relatively straight-forward. For now, we are not concerned about messages, nor
about routing; only about what it takes to move the frame from one node in the
network to another.
Even
for this simple scenario, there are a number of factors to consider:
2. The logical topology of the local area network, usually star or hub, is an important consideration. However, we remind you that the hub, switch, or Wi-Fi access point is not considered a node, since it is ultimately transparent to the data being moved through the network. The local area network may contain several nodes, so there must be an addressing system that identifies the destination, to indicate which node will receive the frame. The destination node will also need to know where the packet came from—its source address.
3. The properties of the frame are important because the nature of the frame can set limits on the design of the network itself. For example, under certain circumstances, the size of the frame, measured in bits, can determine the maximum distance between the nodes.
The Physical Layer
Regardless of protocol suite or
communication configuration, level 1 is defined as the physical layer.
The physical layer is the layer at which the communication actually takes
place. Communication at the physical layer consists of a bare stream of
bits moving through a medium from one node to another. The physical
access protocol includes definition of the medium, the signaling method
and specific signal parameters, voltages, carrier frequencies, lengths
of pulses, and the like; synchronization and timing issues; and the method used
to physically connect the computer to the medium. An example of a
physical access protocol is the specification describing the specifics
of the communication between an 802.11n wireless network card and a
corresponding access point. The physical layer protocol defines the frequency
of the carrier signal, data modulation and demodulation technique,
bandwidth, strength of the transmitted signal under different
conditions, and more. Physical communication between computers, routers,
and other devices takes place only at the physical layer. The physical layer
is implemented primarily in hardware by a network interface controller,
which generates the particular voltages, light pulses, radio waves,
clock and synchronizing signals, and the like appropriate to a
particular specification. Of course, there are a number of different
technologies within the Ethernet “umbrella”, including “twisted pair”
wire, cable service, Wi-Fi, and fiber optic, each with its own physical
layer requirements. The various options are defined by International
standards, primarily IEEE 802.3 for wired Ethernet and 802.11 for Wi-Fi. The
technical details of the various options is a major topic in itself.
The Data Link Layer
The primary definition for
Ethernet resides in layer 2, the data link layer. The data link layer is
responsible for the reliable transmission and delivery of packets across the
communication link between two adjacent nodes. Because the data link layer must
be specific to the characteristics of the network or link and medium to which
the node is attached, there are many different standards in use. Most data
communication practitioners divide the data link layer into two separate sub layers:
the hardware medium-access control (MAC) sub layer, which defines
procedures for accessing the channel and detecting errors, and a software logical
link control (LLC) sub layer, which offers traffic flow control, error
correction, and the management of IP packet/frame conversions, retransmission,
and packet reconstruction, when necessary.
Hub-Based Ethernet
Ethernet
was originally based on a bus topology. Hub-based Ethernet provides a simple
means of wiring a bussed Ethernet together, but the hub does not affect the
operation logically. Any node may use the bus to send a message to another node
any time the bus is not in use; there is no specific timing control on the bus.
When a node has a message to send, it listens to see if the bus is in use. If
not, it begins to send its packet. If the bus is already in use, the node waits
until the bus is available. This is the “CSMA” part of CSMA/CD. CSMA/CD does
not try to prevent the occurrence of collisions. As the node sends its frame,
it continues to listen to the bus. If network traffic is light, the node will
usually complete sending the frame and will then return to listening mode.
Occasionally, two (or more) nodes may sense that the bus is free and initiate
transmission simultaneously. A collision occurs, and the data on the bus becomes
scrambled, due to the interference between the two signals. Since each node
continues to listen as it transmits, it can recognize that the data is
scrambled—the signal on the bus is not the same as the data it is transmitting.
When a node detects a collision, it immediately stops transmitting, waits for a
short time, then returns to listening mode, and tries again when the bus is
free. The amount of time each node waits after a collision is random for each
node. If both nodes waited the same length of time, collisions would continue
to recur indefinitely.
Switched Ethernet
The desire to operate local area
networks at higher speed and with longer ranges also makes hub-based Ethernet
unusable in many circumstances. Instead, switched Ethernet permits the point-to-point
connection of any pair of nodes. Multiple pairs can be connected
simultaneously. Modern switches even provide a buffer to hold frames destined
for a receiver already in use. Switching thus prevents collisions, and there is
no need to implement CSMA/CD in switched Ethernet systems. Switched Ethernet
has two additional advantages:
(1) it is possible
to connect nodes together in full-duplex mode, which is not possible with a
single bus connection, and
(2) each pair of
connections can operate at the maximum bit rate of the network, since the media
are unshared. For many years, hub-based Ethernet was preferred because of the
cost of switches. This is no longer the case; at this point in time, switches
are inexpensive. Hub-based networks are rarely considered for new designs.
Wireless Ethernet (Wi-Fi)
There
are two types of Wi-Fi in use, designated as ad hoc mode and infrastructure
mode. Ad hoc Wi-Fi assumes direct connections between Wi-Fi nodes, and
is based on a partial mesh network topology. Because ad hoc mode Wi-Fi depends
on a network of available cooperative stations, it is rarely used. The
more common, infrastructure mode Wi-Fi, is based on a shared access
point, and is of more interest to us here. Wireless Ethernet is similar
to hub-based Ethernet in many respects because of the nature of the
medium. A variation on CSMA/CD is used for infrastructure Wi-Fi. Since the
medium effectively has the characteristics of a hub, collision handling
is required. The standard specifies two techniques, one mandatory, the
other elective. Collisions in a wireless network are harder to detect
than in a wired network and the consequences are greater. The hidden node and
out-of-range conditions mean that it is possible that some stations can never
detect collisions from each other. Each wireless station is dependent on the
access point. Furthermore, once a sender begins to transmit a frame, it will be
transmitted to its conclusion, even if a collision has occurred, because the
power of the transmitted signal overwhelms the receiver, so that continuous
listening is not possible. This means that delays due to collisions are much
longer than those on a wired hub.
Instead,
the 802.11 standard specifies the use of a collision avoidance MAC protocol, Carrier Sense Multiple Access
with Collision Avoidance (CSMA/CA). As with CSMA/CD, a station is always
listening when it is not transmitting. When a station wishes to transmit a
packet it waits until the channel is clear, plus an additional short random
amount of time. It then transmits its frame to the access point, which
retransmits the frame to the destination node. Retransmission by the access
point is required, to handle the hidden node and out-of-range problems. The
wireless Ethernet frame contains a field that states the time duration of the
packet, which assists other stations in knowing how long the transmission will
take. When the frame reaches its destination, the receiver checks for errors,
then sends a short acknowledgment packet to indicate satisfactory receipt of
the frame. The requirement for receivers to acknowledge the receipt of frames
is the reason for the extra delay in starting transmission. The acknowledgment
is the only sure way to know that a collision has not occurred. An optional
enhancement uses a reservation system to improve collision avoidance between hidden
nodes. Instead of transmitting a frame, a sender will send a short “request to
send”(RTS) packet to the access point, including the time duration that it
needs to send a frame. If the channel is clear, the access point will return a
“clear to send” (CTS) packet, at which time the sender begins transmission of
its frame. Even if a hidden node cannot receive the original RTS packet, it
will be able to receive the CTS packet that was sent from the access point, and
thus know that it must wait before starting its own transmission.
THE NETWORK LAYER
Hopefully,
you now understand how the data link layer and physical layer move an Ethernet
frame of data from one specific node to the next. Other data link protocols and
physical connections work similarly. The remaining layers of the stack are
official TCP/IP protocols.
Continuing
up the protocol stack to the next layer, the network layer, layer 3, is
responsible for the addressing and routing of packets from the source end node
through intermediate nodes, step-by-step, to their proper final destination.
The TCP/IP network layer is also called the internetworking layer or IP
layer. IP is the single standard protocol for this layer, although there
are two versions of IP, IPv4 and IPv6, in current use. There are also several
additional support protocols for matching IP addresses to the physical
addresses that are used by the data link layer, for error reporting, for making
information requests, and other auxiliary tasks. For communications confined to
a local area network, the task is usually simple. IP builds an Ethernet frame
by copying the IP packet (at the IP level, packets are known as IP datagrams)
and appending a header to the frame with a node-specific physical MAC address
to each packet, and passes the frames on to the data link layer. There is no
routing to do, since all the nodes on a local area network are connected
together and directly addressable. If the datagram address is in the form of an
IP address, as one would normally expect, the software looks up the
corresponding physical address in a table. When the message is being sent to a
node outside a local network, for example, to the Internet, the network layer
is responsible for moving the message from sender to receiver, packet by
packet, from one intermediate node to another through router packet switches.
At each intermediate node, the network layer removes the current node’s
physical address and establishes an address for the next node, using various
tables and algorithms. The new physical address is added to the packet and the
packet is passed to the data link layer, which handles the actual connection
between nodes. It is not possible to store the address of every location at
each node. Instead, the network layer has access to tables at various sites
that assist in routing the message. Because routing takes place at the network
layer, routers and gateways are sometimes called layer 3 switches to
indicate the layer at which routing takes place. The topic of datagram routing
is dependent on a number of different mathematical algorithms and sophisticated
statistical techniques that are outside the scope of this text. We will not
consider this topic further. Remember that the IP datagram may pass through
different types of links. For certain types of physical layer connections, it
is necessary to further divide the IP datagrams into smaller packets before
they are delivered as frames to the data link layer. IPv4 has this capability,
although it is rarely needed in modern systems, where the vast majority of
linkages are based on Ethernet, and the packets were designed to fit Ethernet
frames when they were originally created. These smaller packets are called fragments.
IP datagram fragments are reassembled by IP when the final destination is
reached, using header information that is stored with each fragment. IPv6
eliminated this capability as too complicated and time-consuming; instead, IPv6
simply rejects the packet, with an error message back to the sending node.
0 Comments