Network Bulls
www.networkbulls.com
Best Institute for CCNA CCNP CCSP CCIP CCIE Training in India
M-44, Old Dlf, Sector-14 Gurgaon, Haryana, India
Call: +91-9654672192
When networks first came into being, computers could typically communicate only with
computers from the same manufacturer. For example, companies ran either a complete
DECnet solution or an IBM solution—not both together. In the late 1970s, the Open Systems
Interconnection (OSI) reference model was created by the International Organization
for Standardization (ISO) to break this barrier.
The OSI model was meant to help vendors create interoperable network devices and software
in the form of protocols so that different vendor networks could work with each other.
Like world peace, it’ll probably never happen completely, but it’s still a great goal.
The OSI model is the primary architectural model for networks. It describes how data
and network information are communicated from an application on one computer through
the network media to an application on another computer. The OSI reference model breaks
this approach into layers.
In the following section, I am going to explain the layered approach and how we can use
this approach to help us troubleshoot our internetworks.
The Layered Approach
A reference model is a conceptual blueprint of how communications should take place. It
addresses all the processes required for effective communication and divides these processes
into logical groupings called layers. When a communication system is designed in this manner,
it’s known as layered architecture.
Think of it like this: You and some friends want to start a company. One of the first things
you’ll do is sit down and think through what tasks must be done, who will do them, the order
in which they will be done, and how they relate to each other. Ultimately, you might group these
tasks into departments. Let’s say you decide to have an order-taking department, an inventory
department, and a shipping department. Each of your departments has its own unique tasks,
keeping its staff members busy and requiring them to focus on only their own duties.
In this scenario, I’m using departments as a metaphor for the layers in a communication
system. For things to run smoothly, the staff of each department will have to trust and rely
heavily upon the others to do their jobs and competently handle their unique responsibilities.
In your planning sessions, you would probably take notes, recording the entire process to facilitate
later discussions about standards of operation that will serve as your business blueprint,
or reference model.
Once your business is launched, your department heads, each armed with the part of the
blueprint relating to their own department, will need to develop practical methods to implement
their assigned tasks. These practical methods, or protocols, will need to be compiled
into a standard operating procedures manual and followed closely. Each of the various procedures
in your manual will have been included for different reasons and have varying
degrees of importance and implementation. If you form a partnership or acquire another
company, it will be imperative that its business protocols—its business blueprint—match
yours (or at least be compatible).
12 Chapter 1 Internetworking
Similarly, software developers can use a reference model to understand computer communication
processes and see what types of functions need to be accomplished on any one layer.
If they are developing a protocol for a certain layer, all they need to concern themselves with
is that specific layer’s functions, not those of any other layer. Another layer and protocol will
handle the other functions. The technical term for this idea is binding. The communication
processes that are related to each other are bound, or grouped together, at a particular layer.
Advantages of Reference Models
One of the greatest functions of the reference model specifications is to assist in data transfer
between disparate hosts—meaning, for example, that they enable us to transfer data between
a Unix host and a PC or a Mac. The reference models aren’t physical models, though. Rather,
they’re sets of guidelines that application developers can use to create and implement applications
that run on a network. They also provide a framework for creating and implementing
networking standards, devices, and internetworking schemes.
The Open Systems Interconnection (OSI) model is a hierarchical model, and the same
benefits and advantages you gain from implementing OSI standards can apply to any layered
model. The primary purpose of all such models, especially the OSI model, is to allow different
vendors’ networks to interoperate.
Advantages of using the OSI layered model include, but are not limited to, the following:
It divides the network communication process into smaller and simpler components, thus
aiding component development, design, and troubleshooting.
It allows multiple-vendor development through standardization of network components.
It encourages industry standardization by defining what functions occur at each layer of
the model.
It allows various types of network hardware and software to communicate.
It prevents changes in one layer from affecting other layers, so it does not hamper hardware
or software development.
The OSI Reference Model
Basically, the ISO is pretty much the Emily Post of the network protocol world. Just as Ms.
Post wrote the book setting the standards—or protocols—for human social interaction, the
ISO developed the OSI reference model as the precedent and guide for an open network protocol
set. Defining the etiquette of communication models, it remains today the most popular
means of comparison for protocol suites.
The OSI reference model has seven layers:
Application layer (layer 7)
Presentation layer (layer 6)
Session layer (layer 5)
Transport layer (layer 4)
The OSI Reference Model 13
Network layer (layer 3)
Data Link layer (layer 2)
Physical layer (layer 1)
The OSI layers are divided into two groups. The top three layers define how the applications
within the end stations communicate with each other and with users. The bottom four
layers define how data is transmitted end to end. Figure 1.6 shows the three upper layers and
their functions, and Figure 1.7 shows the four lower layers and their functions.
FIGURE 1 . 6 The upper layers
When you study Figure 1.6, understand that the user interfaces with the computer at the
Application layer and also that the upper layers are responsible for applications communicating
between hosts. Notice that none of the upper layers knows anything about networking or network
addresses. That’s the responsibility of the four bottom layers.
In Figure 1.7, you can see that it’s the four bottom layers that define how data is transferred
through a physical wire or through switches and routers. These bottom layers also determine
how to rebuild a data stream from a transmitting host to a destination host’s application.
In this chapter I’ve discussed hubs, bridges, switches and routers, but where are these devices
in relation to the OSI model? Hubs/repeaters are Physical layer devices, Bridges/Switches work
at the Data Link layer, and Routers work at the Network layer. None of the network devices
work at all seven of the OSI model’s layer. The following network devices operate on all seven
layers of the OSI model:
Network management stations (NMSs)
Web and application servers
Gateways (not default gateways)
Network hosts
• Provides a user interface
• Presents data
• Handles processing such as encryption
• Keeps different applications’
• data separate
Application
Presentation
Session
Transport
Network
Data Link
Physical
14 Chapter 1 Internetworking
Figure 1.8 shows a summary of the functions defined at each layer of the OSI model. With
this in hand, you’re now ready to explore each layer’s function in detail.
FIGURE 1 . 7 The lower layers
FIGURE 1 . 8 Layer functions
The Application Layer
The Application layer of the OSI model marks the spot where users actually communicate to the
computer. This layer only comes into play when it’s apparent that access to the network is going
to be needed soon. Take the case of Internet Explorer (IE). You could uninstall every trace of networking
components from a system, such as TCP/IP, the network interface card (NIC), and so
on, and you could still use IE to view a local HTML document—no problem. But things would
definitely get messy if you tried to do something like view an HTML document that must be
• Combines packets into bytes and bytes into frames
• Provides access to media using MAC address
• Performs error detection not correction
• Provides logical addressing,
• which routers use for path determination
• Provides reliable or unreliable delivery
• Performs error correction before retransmit
• Moves bits between devices
• Specifies voltage, wire speed,
• and pin-out of cables
Transport
Network
Data Link
Physical
The OSI Reference Model 15
retrieved using Hypertext Transfer Protocol (HTTP) or nab a file with File Transfer Protocol
(FTP) or Trivial File Transfer Protocol (TFTP). That’s because IE will respond to requests such
as those by attempting to access the Application layer. And what’s happening is that the Application
layer is acting as an interface between the actual application program—which isn’t at all
a part of the layered structure—and the next layer down by providing ways for the application
to send information down through the protocol stack. In other words, IE doesn’t truly reside
within the Application layer—it interfaces with Application layer protocols when it needs to deal
with remote resources.
The Application layer is also responsible for identifying and establishing the availability
of the intended communication partner and determining whether sufficient resources for the
intended communication exist.
These tasks are important because computer applications sometimes require more than
only desktop resources. Often, they’ll unite communicating components from more than one
network application. Prime examples are file transfers and email, as well as enabling remote
access, network management activities, client/server processes, and information location.
Many network applications provide services for communication over enterprise networks, but
for present and future internetworking, the need is fast developing to reach beyond the limits
of current physical networking.
It’s important to remember that the Application layer is acting as an interface
between the actual application programs. This means that Microsoft Word,
for example, does not reside at the Application layer but instead interfaces
with the Application layer protocols. Chapter 2 will present some programs
that actually reside at the Application layer—for example, FTP and TFTP.
The Presentation Layer
The Presentation layer gets its name from its purpose: It presents data to the Application layer
and is responsible for data translation and code formatting.
This layer is essentially a translator and provides coding and conversion functions. A successful
data-transfer technique is to adapt the data into a standard format before transmission.
Computers are configured to receive this generically formatted data and then convert the data
back into its native format for actual reading—for example, from Extended Binary Coded
Decimal Interchange Code (EBCDIC) to American Standard Code for Information Interchange
(ASCII). By providing translation services, the Presentation layer ensures that data
transferred from the Application layer of one system can be read by the Application layer
of another one.
The OSI has protocol standards that define how standard data should be formatted. Tasks
like data compression, decompression, encryption, and decryption are associated with this
layer. Some Presentation layer standards are involved in multimedia operations too.
16 Chapter 1 Internetworking
The Session Layer
The Session layer is responsible for setting up, managing, and then tearing down sessions between
Presentation layer entities. This layer also provides dialogue control between devices, or nodes.
It coordinates communication between systems and serves to organize their communication by
offering three different modes: simplex, half duplex, and full duplex. To sum up, the Session layer
basically keeps one application’s data separate from other applications’ data.
The Transport Layer
The Transport layer segments and reassembles data into a data stream. Services located in the
Transport layer segment and reassemble data from upper-layer applications and unite it onto
the same data stream. They provide end-to-end data transport services and can establish a logical
connection between the sending host and destination host on an internetwork.
Some of you are probably familiar with Transmission Control Protocol (TCP) and User
Datagram Protocol (UDP) already. (But if you’re not, no worries—I’ll tell you all about them
in Chapter 2.) If so, you know that both work at the Transport layer and that TCP is a reliable
service and UDP is not. This means that application developers have more options because
they have a choice between the two protocols when working with TCP/IP protocols.
The Transport layer is responsible for providing mechanisms for multiplexing upper-layer
applications, establishing sessions, and tearing down virtual circuits. It also hides details of any
network-dependent information from the higher layers by providing transparent data transfer.
The term reliable networking can be used at the Transport layer. It means that
acknowledgments, sequencing, and flow control will be used.
The Transport layer can be connectionless or connection-oriented. However, Cisco is
mostly concerned with you understanding the connection-oriented portion of the Transport
layer. The following sections provide the skinny on the connection-oriented (reliable) protocol
of the Transport layer.
Flow Control
Data integrity is ensured at the Transport layer by maintaining flow control and by allowing
users to request reliable data transport between systems. Flow control prevents a sending host
on one side of the connection from overflowing the buffers in the receiving host—an event that
can result in lost data. Reliable data transport employs a connection-oriented communications
session between systems, and the protocols involved ensure that the following will be achieved:
The segments delivered are acknowledged back to the sender upon their reception.
Any segments not acknowledged are retransmitted.
Segments are sequenced back into their proper order upon arrival at their destination.
A manageable data flow is maintained in order to avoid congestion, overloading, and
data loss.
Some types of flow control are buffering, congestion avoidance, and windowing.
The OSI Reference Model 17
The purpose of flow control is to provide a means for the receiver to govern
the amount of data sent by the sender.
Connection-Oriented Communication
In reliable transport operation, a device that wants to transmit sets up a connection-oriented
communication with a remote device by creating a session. The transmitting device first establishes
a connection-oriented session, called a call setup or a three-way handshake, with its peer
system. Data is then transferred; when the transfer is finished, a call termination takes place
to tear down the virtual circuit.
Figure 1.9 depicts a typical reliable session taking place between sending and receiving systems.
Looking at it, you can see that both hosts’ application programs begin by notifying their
individual operating systems that a connection is about to be initiated. The two operating
systems communicate by sending messages over the network confirming that the transfer is
approved and that both sides are ready for it to take place. After all of this required synchronization
takes place, a connection is fully established and the data transfer begins (this virtual
circuit setup is called overhead!).
While the information is being transferred between hosts, the two machines periodically
check in with each other, communicating through their protocol software to ensure that all is
going well and that the data is being received properly.
FIGURE 1 . 9 Establishing a connection-oriented session
Synchronize
Negotiate connection
Synchronize
Acknowledge
Connection established
Data transfer
(Send segments)
Sender Receiver
18 Chapter 1 Internetworking
Let me sum up the steps in the connection-oriented session—the three-way handshake—
pictured in Figure 1.9:
The first “connection agreement” segment is a request for synchronization.
The second and third segments acknowledge the request and establish connection
parameters—the rules—between hosts. These segments request that the receiver’s
sequencing is synchronized here as well so that a bidirectional connection is formed.
The final segment also is an acknowledgment. It notifies the destination host that the connection
agreement has been accepted and that the actual connection has been established.
Data transfer can now begin.
Sounds pretty simple, but things don’t always flow so smoothly. Sometimes during a transfer,
congestion can occur because a high-speed computer is generating data traffic a lot faster
than the network can transfer. A bunch of computers simultaneously sending datagrams
through a single gateway or destination can also botch things up nicely. In the latter case, a
gateway or destination can become congested even though no single source caused the problem.
In either case, the problem is basically akin to a freeway bottleneck—too much traffic for
too small a capacity. It’s not usually one car that’s the problem; there are simply too many cars
on that freeway.
Okay, so what happens when a machine receives a flood of datagrams too quickly for it to
process? It stores them in a memory section called a buffer. But this buffering action can solve
the problem only if the datagrams are part of a small burst. If not, and the datagram deluge
continues, a device’s memory will eventually be exhausted, its flood capacity will be exceeded,
and it will react by discarding any additional datagrams that arrive.
No huge worries here, though. Because of the transport function, network flood control
systems really work quite well. Instead of dumping resources and allowing data to be lost, the
transport can issue a “not ready” indicator to the sender, or source, of the flood (as shown in
Figure 1.10). This mechanism works kind of like a stoplight, signaling the sending device
to stop transmitting segment traffic to its overwhelmed peer. After the peer receiver processes
the segments already in its memory reservoir—its buffer—it sends out a “ready” transport
indicator. When the machine waiting to transmit the rest of its datagrams receives this “go”
indictor, it resumes its transmission.
In fundamental, reliable, connection-oriented data transfer, datagrams are delivered to the
receiving host in exactly the same sequence they’re transmitted—and the transmission fails if
this order is breached! If any data segments are lost, duplicated, or damaged along the way,
a failure will transmit. This problem is solved by having the receiving host acknowledge that
it has received each and every data segment.
A service is considered connection-oriented if it has the following characteristics:
A virtual circuit is set up (e.g., a three-way handshake).
It uses sequencing.
It uses acknowledgments.
It uses flow control.
No comments:
Post a Comment