Pages

Tuesday 11 October 2011

The Seven Layers

{\rtf1\ansi\ansicpg1252\deff0\deflang16393{\fonttbl{\f0\froman\fcharset0 TimesNewRoman;}{\f1\fswiss\fcharset0 Arial,Bold;}{\f2\froman\fcharset0 TimesNewRoman,Bold;}{\f3\fnil\fcharset0 Calibri;}}
{\colortbl ;\red0\green0\blue0;\red0\green51\blue154;\red53\green66\blue120;}
{\*\generator Msftedit 5.41.21.2509;}\viewkind4\uc1\pard\cf1\lang9\f0\fs21 The OSI model is a useful way of thinking about networking. It's important not to confuse it with reality,\par
of course. The most commonly used networking protocols, such as TCP/IP, don't completely match the\par
model. But it is still a useful model. \cf2 Table 1-1 \cf1 shows this simple model in its usual form.\par
\cf3\b\f1 Table 1-1. The OSI model\par
\cf1\f2 Layer Name Uses Examples\par
\b0\f0 7 Application User and application data The reason for having a network in the\par
first place\par
6 Presentation Data formatting, encryption, character\par
encoding\par
ASCII versus EBCDIC, software\par
encryption of a data stream\par
5 Session Negotiates and maintains connections Name and address correlation, software\par
flow control\par
4 Transport End-to-end packet sequencing and\par
reliability UDP, TCP, SPX\par
3 Network Routing, flow control, translation\par
between different media types IP, IPX\par
2 Data Link\par
(MAC)\par
Basic framing of packets, error detection,\par
transmission control\par
Ethernet packets, including collision\par
mechanisms\par
1 Physical Electrical and optical media, signaling\par
and properties\par
Cabling, the electrical or optical pulses\par
sent through the cabling\par
\cf3\b\f1 1.2.1.1 Layer 1\par
\cf1\b0\f0 The Physical Layer is at the bottom. This includes the parts of the network that you can see, such as cables,\par
patch panels, jacks, and optical fibers. Specifications for the Physical Layer have to do with the differences\par
between categories of cables, the wavelength properties of optical fibers, the length restrictions, and\par
electrical specifications. This is extremely important stuff, but most network designers only think about it\par
briefly when they do the cable plant.\par
Other physical-layer issues, such as laser intensity, wavelength characteristics, attenuation, and so on, are\par
important to engineers who design the equipment and cables. But for the network design they appear only\par
in decisions to match the specifications of different pieces of hardware and cabling.\par
\cf3\b\f1 1.2.1.2 Layer 2\par
\cf1\b0\f0 The Data Link Layer is where things start to get a bit more abstract, so some examples might help. This\par
layer is where the difference between Ethernet, Fast Ethernet, and Token Ring exists. It includes all of the\par
specifications about how to build a packet. It describes how the different nodes on this network avoid\par
contention using collisions or token passing or perhaps some other algorithm. For broadcast media (as\par
opposed to point-to-point media where you know that if you send out a packet, it can only be received by\par
\pard\sa200\sl276\slmult1 one other device), it defines how to actually specify for which device or devices the packet is destined.\par
\par
\pard TCP, being a connection-oriented protocol, is inherently reliable. It ensures that all data sent from one end\par
to the other gets to its destination intact and in the right order. UDP, on the other hand, is inherently\par
unreliable. This doesn't mean it's bad; it just means that the application has to make sure that it has\par
received all of the data it needs.\par
The other important thing that happens at Layer 4 is the differentiation between different application\par
streams. In both TCP and UDP (as well as in IPX/SPX at the same layer) there is a concept called a port.\par
This is really nothing more than a number. But it is a number that represents an application. For an\par
application to work, there has to be not only something to send information, but also something on the\par
other end to listen. So a server will typically have a program running that listens for incoming packets on a\par
particular port (that is, packets that have the appropriate number in the port-number part of the packet).\par
The network also cares about port numbers because it is an easy way to differentiate between different\par
applications. The port number can be used to set priorities so that important applications can pass through\par
the network more easily. Or the network can reject packets based on port number (usually for security\par
reasons, but sometimes just to clean up artificially for ill-behaved application chatter).\par
\cf3\b\f1 1.2.1.5 Layer 5\par
\cf1\b0\f0 Layer 5 is not used in every protocol. It is where instructions for pacing and load balancing of different\par
clients will occur, as well as where sessions are established. As I mentioned previously, the TCP protocol\par
handles session establishment at Layer 4, and the UDP protocol doesn't really have sessions at all.\par
To make matters more confusing, the TCP/IP telnet and FTP protocols, for example, tend to handle the\par
session maintenance as Layer 7 application data, without a separate Session Management layer. These\par
protocols use Layer 4 to make the connection and then handle elements such as username and password\par
verification as application information.\par
Some protocols such as SNA can use a real Session Layer that operates independently from the Transport\par
Layer. This ability to separate the layers, to run the same Session Layer protocol over a number of possible\par
Transport Layers, or to build applications that have different options for session control, is what makes it a\par
distinct layer.\par
\cf3\b\f1 1.2.1.6 Layer 6\par
\cf1\b0\f0 The Presentation Layer, Layer 6, is also not universally used. In some cases, a data stream between two\par
devices may be encrypted, and this is commonly handled at Layer 6. But encryption can also be done in\par
some systems at Layer 2, which is generally more secure and where it can be combined with data\par
compression.\par
One common usae of Layer 6 is in an FTP file transfer. It is possible to have the protocol interpret the data\par
as either 7-bit or 8-bit characters. Similarly, some terminal-emulation systems use ASCII characters, while\par
others use EBCDIC encoding for the data in the application payload of the packet. Again, this is a Layer 6\par
concept, but it might not be implemented as a distinct part of the application protocol. In many cases,\par
conversions like these are actually made by the application and then inserted directly into Layer 4 packets.\par
That is to say, a lot of what people tend to think of as Layer 6 concepts are not really distinct protocols.\par
Rather, they are implementation options that are applied at Layers 4 and 7.\par
\cf3\b\f1 1.2.1.7 Layer 7\par
\cf1\b0\f0 And, finally, Layer 7 is called the Application Layer. This is where the contents of your email message or\par
database query live. The Application Layer is really the point of having a network in the first place. The\par
network needs to get information efficiently from one place to another. The Application Layer contains\par
that information. Maybe it needs to be chopped up into several packets, maybe it needs to be translated into\par
some sort of special encoding scheme, encrypted and forwarded through 17 different types of boxes before\par
\pard\sa200\sl276\slmult1 it reaches the destination. But ultimately the information gets there. This information belongs to Layer 7.\par
\par
1.2.2 Where the OSI Model Breaks Down\par
In a sense, the model doesn't break down. It's more accurate to say that it isn't always strictly followed.\par
And there are a lot of places where it is almost completely abandoned. Many of these examples involve\par
concepts of tunneling.\par
A tunnel is a protocol within a protocol. One of the most frequent examples is a Virtual Private Network,\par
or VPN. VPNs are often used to make secure connections through untrusted networks such as the Internet.\par
Taking this example, suppose the users of a corporate LAN need to access some important internal\par
application from out on the Internet. The information in the database is too sensitive to make it accessible\par
from the Internet where anybody could get it. So the users have to make an encrypted VPN connection\par
from their computers at home.\par
They first open a TCP connection from their home computers to the VPN server through the corporate\par
firewall. This prompts them for usernames and passwords, and they log in. At this point everything seems\par
to follow the OSI model. But then, through this TCP session, the network passes a special VPN protocol\par
that allows users to access the internal LAN as if they were connected locally (although slower). They\par
obtain a new IP address for this internal connection and work normally. In fact, they also can pass IPX\par
traffic through their VPN to connect to the corporate file server. So the VPN is acting as if it were a Layer\par
2 protocol because it is carrying Layer 3 protocols. But in fact it's a Layer 6 protocol.\par
Now, suppose the users' own Internet connection is made via a DSL connection. One of the most popular\par
ways to implement DSL in North America is to emulate an Ethernet segment, a Layer 2 protocol. But the\par
connection over this Ethernet segment is made using PPPoE (PPP over Ethernet), a Layer 3 protocol that\par
carries PPP, a Layer 2 protocol.\par
To summarize, there is a Layer 1 physical connection to the DSL provider. Over that the users run Ethernet\par
emulations (Layer 2). On top of the Ethernet is PPPoE, another Layer 2 protocol.[1] Over that they run IP to\par
communicate with the Internet at Layer 3. Then, using this IP stack, they connect to the VPN server with a\par
special Layer 4 connection authenticated at Layer 5 and encrypted at Layer 6. Over this is new Ethernet\par
emulation (back to Layer 2). The users can then run their normal applications (Layers 3-7) on top of this\par
new Layer 2. And, if you wanted to be really weird, you could start over with another PPPoE session.\par
[1] PPPoE is a particularly interesting protocol when studied on the OSI stack because it looks\par
like Layer 3 protocol to the Ethernet protocol on top of which it sits. But it presents a standard\par
Layer 2 PPP interface to the IP protocol that lives above it on the stack.\par
Things get very confusing if you try to map them too closely to the OSI model. But, as you can see from\par
the previous example, it is still useful to think about the various protocols by function and the layers that\par
represent those functions.\cf0\f3\fs22\par
}

No comments:

Post a Comment

Whether you like or dislike, please let us know.