Charles M. Kozierok The TCP-IP Guide

Подождите немного. Документ загружается.

History of the OSI Reference Model

Looking at the origins of the OSI Reference Model takes us back to several issues that

were discussed in the Networking Fundamentals chapter of this Guide; specifically, I am

talking about standards and standards organizations. The idea behind the creation of

networking standards is to define widely-accepted ways of setting up networks and

connecting them together. The OSI Reference Model represented an early attempt to get all

of the various hardware and software manufacturers to agree on a framework for devel-

oping various networking technologies.

In the late 1970s, two projects began independently, with the same goal: to define a unifying

standard for the architecture of networking systems. One was administered by the Interna-

tional Organization for Standardization (ISO), while the other was undertaken by the

International Telegraph and Telephone Consultative Committee, or CCITT (the abbreviation

is from the French version of the name). These two international standards bodies each

developed a document that defined similar networking models.

In 1983, these two documents were merged together to form a standard called The Basic

Reference Model for Open Systems Interconnection. That's a mouthful, so the standard is

usually referred to as the Open Systems Interconnection Reference Model, the OSI

Reference Model, or even just the OSI Model. It was published in 1984 by both the ISO, as

standard ISO 7498, and the renamed CCITT (now called the Telecommunications

Standardization Sector of the International Telecommunication Union or ITU-T) as standard

X.200. (Incidentally, isn't the new name for the CCITT much catchier than the old one? Just

rolls off the old tongue, doesn't it. ☺)

One interesting aspect of the history of the OSI Reference Model is that the original

objective was not to create a model primarily for educational purposes—even though many

people today think that this was the case. The OSI Reference Model was intended to serve

as the foundation for the establishment of a widely-adopted suite of protocols that would be

used by international internetworks—basically, what the Internet became. This was called,

unsurprisingly, the OSI Protocol Suite.

However, things didn't quite work out as planned. The rise in popularity of the Internet and

its TCP/IP protocols met the OSI suite head on, and in a nutshell, TCP/IP won. Some of the

OSI protocols were implemented, but as a whole, the OSI protocols lost out to TCP/IP when

the Internet started to grow.

The OSI model itself, however, found a home as a device for explaining the operation of not

just the OSI protocols, but networking in general terms. It was used widely as an educa-

tional tool—much as I use it myself in this Guide—and also to help describe interactions

between the components of other protocol suites and even hardware devices. While most

technologies were not designed specifically to meet the dictates of the OSI model, many

are described in terms of how they fit into its layers. This includes networking protocols,

software applications, and even different types of hardware devices, such as switches and

routers. The model is also useful to those who develop software and hardware products, by

helping to make clear the roles performed by each of the components in a networking

system.

Key Concept: The Open Systems Interconnection Reference Model (OSI Reference

Model or OSI Model) was originally created as the basis for designing a universal set

of protocols called the OSI Protocol Suite. This suite never achieved widespread

success, but the model became a very useful tool for both education and development. The

model defines a set of layers and a number of concepts for their use that make under-

standing networks easier.

General Reference Model Issues

Before getting into the details of how the OSI Reference Model works, I think it is a good

idea to first discuss some of the basic issues related to reference models. In part, I want to

explain why I place so much emphasis on the OSI model in this Guide, even going so far as

to organize much of the document on the basis of this model. I also want you to understand

why the model is important, and how it benefits networking not only on a conceptual level,

but in reality as well.

So, in this section I describe several issues that relate to reference models in general terms,

and of course, to the OSI Reference Model as well. I begin with some overview explanation

of why networking models are beneficial, and why it is important for you to understand how

the OSI model works. I then talk about how best to use the OSI Reference Model, and also

contrast it to some “real-world” network architectures and protocol stacks.

The Benefits of Networking Models

In my introduction to this Guide, I said that networking was complicated—in fact, I probably

said it too often. ☺ Well, I wouldn't lie to you—it is. And in fact, it is for that exact reason that

special pains must be taken to try to simplify it. One of the ways in which networking

technology is made easier to understand is by splitting it into pieces, each of which plays a

particular role, or is responsible for a specific job or function.

However, if this is to be done, we must have a way of ensuring that these various pieces

can interoperate; that is, each must know what is expected of it, and also what it can expect

from the other pieces. This is one of the important roles of networking models. They split

the multitude of tasks required to implement modern networks, into smaller chunks that can

be more easily managed. Just as importantly, they establish “walls” between those pieces,

and rules for passing information over those walls.

A good analogy of a networking model is to that of an assembly line at a manufacturer. No

company attempts to have one person build an entire car; even if they did, they wouldn't

expect that individual to be able to learn how to do it all at once. The division of labor offers

several advantages to a company that builds a complex product, such as an automobile.

Generally speaking, these include the following:

☯ Training and Documentation: It is easier to explain how to build a complex system

by breaking the process into smaller parts. Training can be done for a specific job

without everyone needing to know how everything else works.

☯ Specialization: If everyone is responsible for doing every job, nobody gets enough

experience to become an expert at anything. Through specialization, certain

individuals develop expertise at particular jobs.

☯ Easier Design Modification and Enhancement: Separating the automobile into

systems, and particular jobs required to build those systems, makes it easier to make

changes in the future. Without such divisions, it would be much more difficult to

determine what the impact might be of a change, which would serve as a disincentive

for innovation.

☯ Modularity: This is related to each of the items above. If the automobile's systems

and manufacturing steps are broken down according to a sensible architecture or

model, it becomes easier to interchange parts and procedures between vehicles. This

saves time and money.

Networking models yield very similar benefits to the networking world. They represent a

framework for dividing up the tasks needed to implement a network, by splitting the work

into different levels, or layers. Hardware and software running at each layer is responsible

for interacting with its corresponding hardware and software running on other devices at the

same layer. The responsibilities of each hardware or software element are defined in part

by specifically delineating lines that exist between the layers.

The result is that you get all of the benefits listed in the bullet points above: easier training,

specialized capabilities at each layer, improved capabilities for modification, and modularity.

Modularity is particularly important, as it allows you to interchange technologies that run at

different layers. While nobody would try to build a vehicle that is partly a compact sedan,

partly an SUV and partly a motorcycle, there are situations in networking where you may

want to do something surprisingly similar to this. Networking models help make this

possible.

Key Concept: Networking models such as the OSI Reference Model provide a

framework for breaking down complex internetworks into components that can more

easily be understood and utilized. The model defines networking functions not as a

large, complicated whole, but as a set of layered, modular components, each of which is

responsible for a particular function. The result is better comprehension of network opera-

tions, improved performance and functionality, easier design and development, and the

ability to combine different components in the way best suited to the needs of the network.

Why Understanding The OSI Reference Model Is Important To

You

A lot of networking books and other resources gloss over the OSI Reference Model,

including only passing mention of it, or relegating it to an appendix. The usual stated reason

for this is that the OSI model is “too theoretical” and “doesn't apply to modern networking

protocols like TCP/IP”.

I believe that this is a misguided notion. While it is certainly true the OSI model is primarily

theoretical, and that networking protocols aren't always designed to fit strictly within the

confines of its layers, it's not true that the OSI model has little applicability to the “real

world”. In fact, it is difficult to read about networking technology today without seeing refer-

ences to the OSI model and its layers, because the model’s structure helps to frame

discussions of protocols and contrast various technologies.

As just a few examples: the OSI Reference Model provides the basis for understanding how

technologies like Ethernet and HomePNA have some important similarities; it explains how

a PC can communicate using any of several different sets of protocols, even simulta-

neously; it is an important part of understanding the differences between interconnection

devices such as repeaters, hubs, bridges, switches and routers; and it also explains how

many WAN technologies interoperate.

Far from being obsolete, the OSI model layers are now showing up more than ever in

discussions of technology. In fact, some protocols are even named specifically in terms of

their place in the OSI Reference Model! For an example, consider the Layer Two Tunneling

Protocol. Also, switches are now commonly categorized as being layer 2, layer 3 or even

higher-layer switches.

In theoretical discussions, the OSI Reference Model helps you understand how networks

and network protocols function. In the “real world”, it also helps you figure out which

protocols and devices can interact with each other. So, I encourage you to read on. It's time

well spent.

Key Concept: While many people scoff at the notion of studying the OSI Reference

Model, understanding it is very helpful in making sense of networking protocols and

technologies. The model is theoretical, but its concepts are employed regularly to

describe the operation of real-world networks.

How To Use The OSI Reference Model

I have been trying to make the point in this section that the OSI Reference Model is a very

important tool in understanding how networks function. However, while some people tend to

play down the OSI model too much, suggesting that it really isn't very relevant today, there

are others who go to the other extreme. They use it too much, overanalyzing and trying to

use the model in a way that was never intended.

The most common mistake is attempting to try to “make everything fit” into the layered

structure of the OSI model. (I must confess to falling into this trap myself on occasion.)

When I first started laying out the structure of this Guide, I wanted to organize everything

based on where it fell in terms of OSI model layers. I quickly discovered that this was like

attempting to put pegs of various shapes into a board containing only round holes. I had to

change my approach. I ended up organizing the Guide based on the OSI layers where it

made sense, and using a different structure where it did not.

I recommend that you learn from my experience. A simple rule of thumb is this: refer the

OSI Reference Model if it helps you make sense of technologies and understand how they

work; don't use it if it makes things more complicated instead of more clear. In particular,

bear the following in mind:

☯ It can be very hard to even figure out where some technologies fall within the model.

Many protocols were designed without the OSI model in mind, and they may not fall

neatly into one layer or another. Some overlap two or more layers; other protocol

suites may have two protocols that share a layer.

☯ The boundaries between the upper layers (session, presentation and application) get

particularly fuzzy. Some protocols are clearly designed to fit at one of these layers,

while others may overlap all three. It is for this reason that I do not categorize higher-

level protocols by layer in this Guide. (The OSI Reference Model was in fact designed

to take into account the fact that differentiating between these layers might not make

sense.)

☯ The OSI Reference Model was designed primarily with LANs in mind. WAN technol-

ogies often fit very poorly into the OSI model, with lots of overlapping and partial layer

coverage. However, it's still useful in most cases to look at these protocols in terms of

their approximate fit in the OSI model, since parts of WAN technologies are sometimes

interchanged.

☯ The people who design products don't generally worry about ensuring that their latest

inventions implement only specific layers of the model. Thus, sometimes new products

come out that “break the rules” and implement functions across more than one layer

that used to be done by multiple devices at the individual layers. This is usually

progress, a good thing. ☺

Finally, an observation… I have noticed that people learning about networking—especially

those trying to memorize easy answers to difficult questions so they can pass exams—often

ask “at what layer does this piece of hardware operate?” The problem here is not the

answer but rather the question, which is simplistic. With the exception of simple physical

devices such as connectors and cables, pretty much all networking devices operate at

many layers. While a router, for example, is usually associated with layer three; it has two or

more device interfaces that implement layers two and one. A better question is what is the

highest layer at which a device functions.

The bottom line is that the OSI Reference Model is a tool. If you use it wisely, it can be

immensely helpful to you. Just remember not to be too inflexible in how you apply it, and

you'll be fine.

Key Concept: It is just as much a mistake to assign too much importance to the OSI

Reference Model as too little. While the model defines a framework for under-

standing networks, not all networking components, protocols and technologies will

necessarily fall into the model’s strict layering architecture. There are cases where trying to

use the model to describe certain concepts can lead to less clarity rather than more. One

should remember that the OSI model is a tool, and should be used accordingly.

Comparing the OSI Reference Model to Network Architectures

and Protocol Stacks

The OSI Reference Model is not the only model used to describe the structure of networks.

There are several other models and systems that are used to describe various sets of

networking technologies that work together. These are generally not theoretical models, but

rather describe groupings of protocols that are actively used in actual networks. They are,

therefore, more often called networking architectures and protocol suites than models.

As I mentioned in the previous topic, many technologies and protocols don't “fit” well into

the specific layers used in the OSI model. Similarly, most of the protocol suites used in the

“real world” don't fit the OSI model exactly. This happens, of course, because they were

developed independently of the OSI model. Still, most of these architectures and suites still

use layers—they are just different ones than the OSI model uses.

Since the OSI model is so often referenced, it can be very helpful in making sense of other

architectures, and even comparing them. Regardless of what the individual layers and

technologies are called, networking protocol suites all try to accomplish the same goals in

implementing a network. Thus, even though the layers are not the same, they are often

comparable.

In the case of TCP/IP, a special model called the DOD model or TCP/IP model is usually

used in discussions of the suite. This model has many similarities to the OSI model, but

also some important differences. In other areas in the field of networking, still other models

are used, such as the IEEE 802 networking architecture model. These too are similar in

some ways to the OSI model but have their own unique characteristics.

Even within the scope of some individual specific technologies, a layered structure of

related protocols can be seen. There are technologies that are generally considered to

implement a single level of the OSI model that actually have portions that overlap several

layers; examples include Ethernet and ATM. In fact, some protocols even have subpro-

tocols that are layered within the confines of what is considered a single layer under OSI; a

good example is the TCP/IP Point-to-Point Protocol (PPP), which, despite the name, is not

a single protocol but a protocol suite unto itself.

Key OSI Reference Model Concepts

The OSI Reference Model is valuable as a tool for explaining how networks function, and

for describing the relationships between different networking technologies and protocols. To

accomplish this, the model relies on a number of important concepts and terms. To under-

stand the model, then, I need to explain what these are and how they relate to the model as

a whole.

In this section, I describe the key concepts that define how the OSI Reference Model works.

I begin with a discussion of how the model uses layers, perhaps the single most important

model concepts. I then talk about some of the notation and jargon you are likely to see used

in general discussions of the model. I define in more detail what “interfaces” and “protocols”

are in the context of the model. I then explain the important concept of data encapsulation

and the terminology used to refer to messages in the OSI Reference Model: PDUs and

SDUs. Finally, I put together most of the preceding issues by describing how the various

layers work to handle the routing of messages on a theoretical basis.

Note: Many of the concepts discussed in this section are also used by many

people in describing the details of various individual technologies. The best

example is the word “protocol”, which is used just about everywhere to refer to just

about anything. My focus here is on the conceptual definitions of such terms. However, the

conceptual discussions here often also apply to real-world technologies. For example, data

encapsulation is performed as data is sent between protocols and technologies at various

OSI layers, pretty much as I describe it here.

OSI Reference Model Networking Layers, Sublayers and Layer

Groupings

The most important OSI Reference Model concept is that of networking layers. It’s not an

exaggeration to say that layers are really the heart of the OSI model—the entire point of the

model is to separate networking into distinct functions that operate at different levels. Each

layer is responsible for performing a specific task or set of tasks, and dealing with the layers

above and below it. The rest of this section will deal with many of the different nuances of

this layer orientation.

OSI Reference Model Layers

The OSI Reference Model is comprised of seven conceptual layers, each assigned a

“ranking” number from one to seven. The layer number represents the position of the layer

in the model as a whole, and indicates how “close” the layer is to the actual hardware used

to implement a network. The first and lowest layer is the physical layer, which is where low-

level signaling and hardware are implemented. The seventh and highest layer is the appli-

cation layer, which deals with high-level applications employed by users: both end users

and the operating system software.

You can see that as we proceed from the first layer to the seventh, we move up the layer

stack and in so doing, increase our level of abstraction. This means that the higher a layer

is in the stack, the more it deals with logical concepts and software, and the less it deals

with the hardware of a network and the “nuts and bolts” of making it work.

The first layer is the most concrete, as it deals with the actual hardware of networks, and

the specific methods of sending bits from one device to another. It is the domain of

hardware engineers and signaling experts. The second layer is a bit more abstract but still

deals with signaling and hardware. As you proceed through the third, fourth and subse-

quent layers, the technologies at those layers become increasingly abstract. By the time

you reach the seventh layer, you are no longer dealing with hardware or even operating

system concepts very much; you are in the realm of the user and high-level programs that

rely on lower levels to do the “heavy lifting” for them.

OSI Reference Model Layer Groupings

The OSI Reference Model does not formally assign any relationship between groups of

adjacent layers. However, to help explain how the layers work, it is common to categorize

them into two layer groupings:

☯ Lower Layers (Layers 1, 2, 3 and 4): The lower layers of the model—physical, data

link, network and transport—are primarily concerned with the formatting, encoding and

transmission of data over the network. They don't care that much about what the data

is or what it is being used for, just about moving it around. They are implemented in

both hardware and software, with the transition from hardware to software occurring as

you proceed up from layer 1 to layer 4.

☯ Upper Layers (Layers 5, 6 and 7): The higher layers of the model—session, presen-

tation and application—are the ones that are concerned primarily with interacting with

the user, and implementing the applications that run over the network. The protocols

that run at higher layers are less concerned with the low-level details of how data gets

sent from one place to another; they rely on the lower layers to provide delivery of

data. These layers are almost always implemented as software running on a computer

or other hardware device.

There are some who would not necessarily agree with how I have chosen to divide the

layers above. In particular, valid arguments can be made for including the transport layer in

the upper layer group, since it is usually implemented as software and is fairly abstract. I

believe it is better as part of the lower layer group since its primary job is still providing

services to higher layers for moving data, however. Really, layer 4 is somewhat of a

“transition zone” and is hard to categorize. Figure 11 shows how I divide the OSI Reference

Model layers into groups and indicates the special position of layer 4 in the stack.

Key Concept: The most fundamental concept in the OSI Reference Model is the

division of networking functions into a set of layers, from layer one at the bottom to

layer seven at the top. As you go up the layer stack, you move away from concrete,

hardware-specific functions to ones that are increasingly abstract, until reaching the realm

of user applications at layer seven. The seven layers are sometimes divided into groupings:

the lower layers (one, two and three) and the upper layers (four through seven). There is

some disagreement on whether layer four is a lower or upper layer.

Relationships Between OSI Reference Model Layers

There are also certain OSI layers that have “natural” relationships to each other. The

physical and data link layers, in particular, are closely related. For example, most people

talk about Ethernet as being a “layer two technology”, but Ethernet specifications really deal

with both layer 2 and layer 1. Similarly, layers three and four are often related; protocol

suites are often designed so that layer three and four protocols work together; examples

being TCP and IP in the TCP/IP protocol suite and IPX and SPX in the Novell suite.

Figure 11: OSI Reference Model Layers

The OSI Reference Model divides networking functions into a stack of seven layers, numbered 1 through 7

from the bottom up. To help illustrate the differing levels of abstraction between layers near the top and those

on the bottom, they are sometimes divided into two layer groupings—the lower layers and the upper layers. Of

course, not everyone agrees on exactly how the division should be accomplished. In particular, the transport

layer is sometimes considered an upper layer and sometimes a lower layer.

7 Application

6 Presentation

5 Session

4 Transport

3 Network

2 Data Link

1 Physical

Upper

Layers

Lower

Layers