Mr. Packet Goes to Washington

OSI for the rest of us

A brief history of OSI:

In the mid 1980's, there were several vendors with their own way of doing networking. We had networks like Banyan Vines, Mainframes, Novell, Microsoft, Digital not to mention the Department of Defense network (ARPANET) and what has become known as the Internet. One problem we faced was "how do we get each type of network to talk to each other?" To solve this problem, the International Standards Organization (you know them for ISO 9001, 9002, etc.) proposed a standard, called Open Systems Interface, that if followed by everyone would allow each proprietary network to communicate with each other. The only problem was, each vendor had hundreds of thousands of dollars invested in their way of doing things. The end result, was that no one really followed the model to its exact specifications. But, today each vendor tends to compare their way of doing things to the OSI model. As such, it has become a "standard" for all network discussions and comparisons.

The original model contained 7 layers. Each layer with a specific function assigned to it. But, since most vendors simply kept their own "stack", you will usually see only 4-5 layers for the stack. The Internet (TCP/IP) for instance uses only four layers. Novell Netware only uses four layers as does Microsoft. As a result, some layers were discarded or combined by different vendors.

To add to the confusion, no matter what I read, it seems that everyone interprets OSI through the eyes of their own product. As best as I can, I will try to describe what I understand ISO originally was described to do, but will add the Microsoft flavors, since that is what you will have to know for the exams.

The analogy:

A good way to think of OSI is to think of gathering all of your friends together and car pooling to the Smithsonian in Washington, DC. If you live near Washington, DC, you might change the destination to Disneyland in Los Angeles, California. As with any trip, you are going to have to consider how many people can drive a car, does everyone have insurance, how many can fit in each car and you will probably want to make reservations at a hotel before leaving. In a network, you have the same kinds of issues and OSI was created to help networks accomplish these tasks. Below are the seven layers and what they are responsible for. An acronym that many people use to help remember the layers is "All People Seem To Need Data Processing." A more humorous acronym is "All People Should Try Novell Data Products." I hope this helps.

Application

Have you ever wondered if WordPad or Notepad know what a network is? Are you willing to take a guess? Try creating a document using Notepad, (I will assume you are using Windows XP, 2000, NT or 95/98 with Remote Administration enabled) and saving it. However, instead of typing a normal name in the File: Save As... dialog, try this instead "\\my computer name\C$\demo.txt." Substitute the name of your computer for "my computer name" and of course remove the quotes. Now close notepad.

Go to the root of your "C:" drive and see if you have the file you just saved. You should. How is that? Does that mean that Notepad knows what a network is? Well, kind of. Let me give you another illustration before I tell you how Notepad "knew" about your network. If you have ever programmed a macro in Microsoft Excel or another Microsoft product, you may have issued a statement like this msgbox("Are you sure you want to format your hard drive?",vbyesno,"Warning"). If you click on the button below, you can see a similar example. Don't worry, it doesn't format your hard drive.

When this line executes in Excel, I will receive a dialog box, centered in the screen and using the users' choice of colors. Should the user choose to change their system colors, our dialog box will change its colors to reflect the change. Now what's interesting, is that I can copy this to Microsoft Word or Microsoft Access and I'll get the same result. I could even copy it to a Windows 3.x machine, and instead of your typical Close, Restore, Minimize icons we have in the Windows 95/NT interface, we get the old up/down arrows for these options. Now, let me take this further and copy it to a Macintosh, running FoxPro, or to Paradox, or DBase and I get exactly the same results. Why? Because the warning dialog box is not part of the applications, it is stored as part of the operating system in a set of libraries.

Think about how often a programmer would have to write code to do a File: Save As... or a File: Print dialog box. Dozens if not hundreds of times in a given application. Fortunately for the programmer, they don't have to because the operating system contains libraries of with hundreds (maybe even thousands) of preset routines that they can call to do the majority of their work. We call these libraries Application Programming Interfaces (API's for short) or Dynamic Link Libraries, or just DLL's. I just used one to create the dialogue box you saw if you click on the button above.

You see, what the File: Save As... dialog box that you used to save your document does, is not really a part of Notepad, but is an API. Specifically, it's comdlg32.dll (this is the dll that provides Open, Print, Print Setup, Save As... for most of your applications in Windows). It is this API that ultimately knows about the network.

There are two major APIs in Microsoft's networking that we need to consider: Net BIOS and Sockets. Both of these APIs simply act as an interface to the core of the network components of the operating system. We'll look at each one individually but first let's address one more issue.

Think about how many services or processes a computer runs. It can be file server, a print server, a fax server, a mail/messaging server, a database server... the list goes on and on. Now think about the number of requests that come in to the computer for those services. They could all go into a giant box and each service/process could dig through all of the messages to see if there were any messages specific to that them, but that would be inefficient. On the other hand, we could put an address of the service that we wanted to communicate with on each message and deliver them to specific mail boxes for that service. The computer could be the Post Office and service name could be the mail box for the service. This would be much more efficient. This is what Net BIOS and Sockets are all about.

Net BIOS

Let's suppose you want to map a drive to a remote computer, and let's say its name is "Server1". You could issue the command "NET USE X: \\SERVER1\MYSHARE" and you would map a drive to the shared folder "myshare". But how does that command vary say from sending a message with "NET SEND SERVER1 'I will be logging off in 10 minutes'"?  Both of these commands get to the server, but each one of these commands goes to an entirely different server process/service or accomplishes a different task.  The first goes to the Server service which shares files. The second goes to the Messenger service which handles the receipt of messages. The difference in addressing is in the Net BIOS name.

Net BIOS names actually have two parts to their names - the post office or the computer name, and the post office box or the service name. Just as when you address a letter you must provide both the zip code (the post office) and the post office box, so when you issue any Net BIOS related command, it addresses the destination with both a zip code and a post office box. You can see your post office boxes by typing "nbtstat -n". You should see several columns. The first is the name you are familiar with (a 15 character or less name like "Server1", the second column <03>,<20>, <2B> all identify the post office box or the service. These two columns combined, make up a Net BIOS name.  Net BIOS names are simply an end point for communication - a post office and a post office box. And the Net BIOS API is simply a library routine that knows how to use this naming convention on a network so you and I don't have to.

So what does this all mean? What's great about the Net BIOS API is that you know when you are using it, because of the commands you execute. For instance, all the following command use the Net BIOS API to get access to the network: NET ... (any command that begins with net), all \\Universal Naming Convention commands, Logins, Password Changes, Domain Synchronization, Directory Synchronization.

Sockets

Socket is a UNIX way of providing an end point for communication. You use sockets every time you browse the Internet. You are even using sockets right now as you view this web page. You type "http://www.rtnetworks.com" to get to this site. But how did your computer know it wanted to talk to my Internet service as opposed to my email service? Simple. It used sockets.

You may have noticed that after you type in a web address such as mine, an message stating that you are connection to "124.80.10.56" or some similar number across the bottom of your browser. That is the server's IP (Internet Protocol) address. An IP address is nothing more than a number that represents the street and house number my computer lives on. When you typed in my web address, a DNS (domain name server) translated the "www.rtnetworks.com" to my servers IP address. That IP address is the first part of a socket. There are two other parts to a socket.

Normally we type "HTTP://" in front of the web address. The http simply identifies which service "post office box" on my server you are trying to communicate with. In this particular case that corresponds to a number, the number 80. Every post office in UNIX has 65,535 of these ports, of which the first 1024 have been reserved for particular uses. For example, FTP (File Transfer Protocol) uses 20 and 21, SMTP (where you send your mail) uses 25, POP3 (where you get your mail from) uses 110. This is the second part of your socket.

The third part chooses the delivery mechanism. When you send mail or packages, there are several vendors providing delivery services. Some are okay if you are not worried about the package getting there in a timely manner, but other times you choose a more reliable service if you are not convinced the package will get there with the other vendors. When we are talking about sockets, there are two delivery mechanism available - Transmission Control Protocol (TCP) and User Datagram Protocol (UDP a datagram usually means non guaranteed). In the case of your browser, it chose TCP because that is what web pages are transmitted with.

So your browser asked for a computer with a post office address of 124.80.10.56, a post office box (port) of 80 and asked TCP to get it there for you. That is the destination socket. Just like mail has both a return address and a destination address, so sockets send messages with a return and destination address. Your return address is your IP address (assigned to your modem when you dialed into the Internet by your ISP or to your network card by your computer people in your company), a return port number (a number between 1025 and 6535) and you are using TCP as your communication mechanism.

TCP/IP Port graphic
Image #1.

Again, just like Net BIOS, you know when you are using Sockets because of the command you use. Commands like PING, Tracert, Telnet, FTP, HTTP, HTTPS, LPD all use sockets.

To see how Microsoft resolves names for both of the these two methodologies see...

In the end, simply remember that both of these APIs are simply a programmers interface that programmers can use to get access to networks that either use Net BIOS or networks that use Sockets.

So, how does the Application layer relate to our car pool analogy? The application layer is where we are all going to meet to go on our trip. It is a common interface/location that everyone can agree upon.

Now that we have agreed where we will meet, we have some other travel arrangements to make.

Back to top

Presentation

One of the challenges we face when we send information across computers, is the language we will speak. What I mean is this. Everything on a computer is nothing more than a number to the computer. So, if I send you the letter "A" versus the letter "a", how does the computer tell them apart. Well, they are different numbers. If you are using a PC to read this, an upper case "A" is represented by the number 65, but the lower case letter "a" is represented by the number 97. That's what ASCII is all about. You may remember in times past when you wanted to add a special symbol to a word processing document where you would hold down your ALT key and press say 0233 on your numeric key pad to create the letter "é". Try it with the numbers 65 and then 97.

The ASCII language that most desktop computers use counts from one to 255, or in an ascending order. We can all understand what each others computers are saying because we've all agreed that when we send messages, we will interpret the numbers we send by translating them using the ASCII character set. But, if I'm using an IBM mainframe, instead of counting from one to 255, I count from 255 to one. Now what am I going to do? Sixty-five used to mean the letter "A". Now the letter "A" is representative of the number 190 and the letter "a" is now representative of the number 158. IBM calls this EBCDIC (pronounced eb-see-dik).

This is kind of like when we were kids. I used to pretend that I would make up my own secret code and that I could send secret messages back and forth with my friends. My code wasn't too impressive. A was 1, B was 2, C was 3, etc. Of course, my friends and I would have to know the "secret code" ahead of time. Guess what, that's what the Presentation Layer is all about. Choosing what numbers will represent what characters. I call it "Choosing a Character Set".

Since most computers use ASCII, the presentation layers is one of those layers that has not been used by that many vendors for it original intent. But, let's suppose you and I want to still have our secret little code? What would happen if we made up our own little character numbering scheme and didn't tell any one? That's right - we would be encrypting our data. That's what Point to Point Tunneling Protocol does, or many of the other encryption mechanisms.

So back to our analogy. Basically, we've agreed where we will all meet at, and that we are sending people to Washington. How the Presentation Layer fits into this is it acts as a translator for those of us who don't understand the language of our tour guide.

Back to top

Session

Like any major trip, if you don't plan a little bit ahead, you will probably end up wishing you had. If you are a detail minded person, you will probably want some place to sleep when you reach Washington. So, you call the Washington DC Sheraton and tell them you'd like to have 100 (remember, you did invite all of your friends) people stay there next week. Unfortunately, there's no one to take your call and so you get voice mail. During the course of the day, the Sheraton calls you back and of course you're out when they call, and the Sheraton leaves a message that they only have room for 80 people. Not to panic, you make another call to the Sheraton and tell them you'll take the 80 and figure out what to do with the other 20.

Now, count the number of phone calls made. 1- You made the initial call to the hotel. 2 - They returned your call to inform you of how many guests they could accommodate. 3- You returned the hotel's call to accept their accommodations. We call this process a 3 way handshake. For a trip you use it to make reservations. For a network, we use it to find out how much data I can send the destination at once. In most networks, this is called a "session window". Did you ever listen to your modem when you where dialing your Internet Service Provider? That squealing noise you here is the modem, making a three way handshake with modem on the other end. You are telling it, I'd like to send you this much data and I can receive this much at once, whatever "this much" is. The destination modem responds by saying, "I can handle 'this much' data at a time." At this point, your modem simply acknowledges the destination modem's window or buffer. You have gone about establishing a connection oriented session.

The Session layer is responsible for both connection oriented and connectionless communication. A connection-based protocol makes a 3-way handshake whenever it wants to send data, and both the sender and receiver exchange their buffer sizes. A connectionless protocol simply starts sending data. Where this become confusing is that in the real world, most vendors combined the Session Layer with the Transport Layer. Read on and see if you can tell why.

Back to top

Transport

Well, we still have some other arrangements to deal with. If we were simply driving to work, we probably would not be too worried about getting there. On the other hand, driving across the country to Washington D.C. is not the easiest of trips for some of us. Ask yourself, "When was the last time you called home when you got to the office to tell someone you made it to work okay?" It has probably been awhile, if ever. Why? Because for most of us, traveling to work is no big deal, (unless you commute to the Silicon Valley as I do). But, I'd be willing to bet, that if you drove to Washington from most parts of the country, you'd probably call someone when you got there wouldn't you? Why? Because the trip is less predictable than your commute. There are more problems, more chances that you might not make it.

Well, networks have the same problems. Some networks are very reliable, others are not so. Some of the messages you send, aren't that important, so you don't check to see if it got there safely. Others, you want to be sure they got there intact. To handle this, networks have "Guaranteed" and "Non-Guaranteed" ways of getting there. Guaranteed methods use "Acknowledgments" to phone home and let the sender know the message got there intact. Non guaranteed, simply trusts that someone else will worry about whether or gets there intact, or simply doesn't care because it is not that important. Developers choose where to send data using guaranteed or non-guaranteed based on the importance of the message (such as a logon), the reliability of the data reaching its destination intact, and the cost of having to phone home when the data reaches its destination. After all, the acknowledgments cost us time that could be used to send data.

There are several agreed upon standards for whether we should acknowledge data and how we should do this. These agreed upon standards, are called "Protocols".  There are actually protocols for every layer of the OSI stack, because if we didn't agree, then we couldn't communicate very well.

One of the protocols used at the Transport layer are Transmission Control Protocol (TCP). Microsoft's implementation of TCP sends an acknowledgment after it receives two pieces of data in a row. Another common protocol is Novell's SPX, SPX sends an acknowledgment, after every piece of data it receives. And then there are the non guaranteed protocols like User Datagram Protocol. A "datagram" is a piece of data with no guarantee of being delivered because it doesn't use acknowledgments.

The Transport Layer has another job too. It handles breaking the data down so that there will not be too many people for each car. Let's say that you are one of the drivers. One of the questions I would need to ask you would be, "How many people can you take in your car?" Now we might have a couple of dozen people who are going with us, and they can't all go in your car. Let's suppose that your drive a sedan and you say, "I can take 5." Well "Thank you.", but does that include you or should we subtract one from that to leave room for the driver?

The Transport Layer does the same job for the network. If we were to send all of our data across the network as one big 40MB document, if there was an accident along the way, we would have to resend all of that document again. That would kill our network, as accidents happen quite often on the road. The Transport Layer asks the Data Link layer what type of car it is driving, and how many people it can take, leaving room for the driver. This is known as the Maximum Transmission Unit, often referred to simply as the MTU. It then breaks down our document into pieces the size of the MTU.

You might ask, "How does it know how to put all the data back together again?" That's a good question, we wouldn't want a Humpty-Dumpty network now would we? The Transport Layer uses a sequence numbering process where it gives each car a number. As each piece of data is broken down to an MTU unit, it is placed in an envelope. On the outside of the envelope, there is a mailing label. This mailing label contains the sequence number as well as the protocol the Transport Layer is using. This sequence number is really just the number of bytes that I've sent to anyone. In other words, if I've sent 10,000 bytes out onto my network, then the next sequence number will be 10,001. If my MTU plus my driver size is 1600, then my next sequence number will be 10,001 + 1600, or 11,601.

When the cars (called packets) all reach Washington, no matter what order they get there in, the Transport Layer will use the sequence number of the packets to rearrange and reassemble each packet back into the original document. This sequence number has another purpose. If the Transport Layer protocol identified in the mailing label is a guaranteed delivery protocol, it can use this sequence number to send an acknowledgment to the client. If we were using TCP, after every other packet, the destination's Transport Layer would send a message back to the client saying "The next sequence number I expect to receive from you is xyz." Now let's suppose that number is 2000, when the client receives this packet, it looks at the number and says, "Hey, I thought I was supposed to send sequence 2100 next. They must have lost 2000-2099, so I'm going to resend them that data." This is how acknowledgments are done and how we guarantee delivery.

Aren't you glad you have a life and didn't have to design this yourself?

Two little side notes. One, the original purpose of the Session Layer was for measuring the amount of time a client had a session to a server. In some environments, there is a charge made for all usage of the server/mainframe/supercomputer. The session layer was designed to accommodate this. Secondly, after having said that, most networks, actually combine the Session Layer and the Transport Layer. Remember, that many vendors had their designs well laid out by the time the International Standards Organization proposed OSI. For this reason, it become difficult to really distinguish between the two layers.

Image #2 below shows some of the fields added to the outside/front of the segment when it is broken into pieces at the Transport layer. Note the Sequence number used to reassemble the packet, the acknowledgement number to confirm delivery, and window size to exchange buffer sizes.

Transport Packet Image

Image #2

Back to top

Network

Would you believe me if I told you that networks are really very dumb? If you were to ask any one person how to get to Washington D.C., they couldn't tell you.  Here's how you would get there. You don't have a map and you have to ask everyone along the way. So, you walk out of your house, and outside you house you meet the mailperson, and you ask them, "How do I get to Washington D.C.?" Well, they don't know how to get there, so they suggest you go down the street to the next intersection and ask the traffic cop sitting there. So, you go down and ask the traffic cop the same question, "How do I get to Washington D.C.?" They don't really know much either, but they can at least point you in the right direction. From where I live, that would be East. The local traffic cop points me down the street going east from where they are to the next traffic cop. This process continues, intersection by intersection until I get to Reno, Nevada. In Reno, the traffic cop says, "Hey, I'd normally recommend that you just stay on Interstate 80 until you reach Salt Lake City, Utah, but with the recent snow storm, you need to take this other route to Denver." At Denver, Colorado, I get sent back north to Interstate 80.

Now, if you think about it, this is actually a good thing. If part of your network goes down, you still want your data to be able to get there. Or if there is a road problem ahead, you would like to know the available detours. This is how the Internet works. That is why it is sometimes called a "web", because there are so many different ways to get there, and every intersection, you stop and ask for directions. Remember Sputnik? It was the first Russian satellite. With the advent of Sputnik, the U.S. military immediately equated satellite with nuclear warhead. If the Russians could launch a nuclear weapon on a rocket, what would happen to the military's network if it were hit by a missile? As a result, they along with several universities, developed this switching network known now as a "packet switched network."

So, what hardware works here? Well routers of course. A router has the job of the traffic cop. It knows all of the routes to a specific destination, which ones are down, and which routes are the most efficient to get there.

Image # 3 below shows some of the fields added at the Network Layer. Note the destination and source software address. In TCP/IP that would be the TCP/IP address. In the event that a router has to break a segment into smaller pieces, the Identification # and Fragment Offset are used to reassemble the pieces at the final destination.


Image #3.

Back to top

Data Link

Hey, we're getting closer getting on the road. One more major job still lies in front of us. Whose car are we really going in? Remember at the Transport Layer we asked how many people could fit in the cars we were using (the Maximum Transmission Unit). Now we have to put the people in the cars.

In networking, the cars are called frames. If the word "frame" seems odd, thing of a picture frame. It "frames" or defines the boundaries of what is really important. For a network, a frame defines where our data begins and ends, remember that for most networks, data simply flows down a line in a continuous flow of zeroes and ones. A frame, helps us put this data into manageable units, that we can direct on the network. But, we also have a task of defining what type of car we will be riding in. Think about it. We can't send electrical pulses down a fiber optic line now can we? Nor, can we send light pulses down a copper wire. When we send electricity down a copper wire, how many volts will signal a zero? How many volts will signal a one? Will it be +3 volts for one and -3 volts for zero? If we are using fiber optic, what wavelength of light will we use? Will we use different colors to signify zeroes versus ones, or will we use different lengths of time? In other words, a frame defines for us the media we will be using, how we will packaging the data, and the signaling scheme we will be using.

Another issues the Data Link layer handles for us is addressing. Some networks rely on simply yelling out a message and hoping that the recipient can hear it. It's a lot like the stock market floor. Other networks have very specific destinations that they send there messages to. In order to make this work, the Data Link layer adds addressing information to the front of the frame to specify, not only the frame type, but also its destination and return address.

Originally, networks were primarily point to point communications, i.e.-they were connected by serial cables much like when you dial into the Internet with your phone. With only two computers connected who the message was going to wasn't a big deal, after all there were only two people talking. But as networks grew, so did the need to have more than two computers in the communication stream. One of the solutions to this dilemma was Ethernet. Ethernet uses an address hard-coded into the network cards' read only memory that is unique to every network card in the world (at least they are supposed to be). When one computer needs to speak to another computer, it waits its turn for a break in the conversations and then sends a message to the destination computer by using this hardware address stamped in the network cards memory. But, the Data Link layer wasn't designed for this kind of communication, so the OSI's Data Link layer was divided into two layers. A Media Access Control layer and below it, a Logical Link layer. (This is where we get the term MAC address from-Media Access Control layer) The difference in the these two layers is primarily in how we address their frames. Ethernet uses the Media Access Control layer whereas IPX/SPX primarily uses the Logical Link layer.

Image #4 below identifies some of the fields added at the Data Link Layer. The source and destination hardware address are also known as the Ethernet or Media Access Control (MAC) address on Ethernet networks. Note also the frame type. The original OSI model specified a checksum at the Data Link Layer. Some protocol stacks implement this at higher layers (i.e. - Transport).

Data Link Packet Image Image #4.

Back to top

Physical

Well, your in your car, your now on the road to Washington. Your road might be copper, it might be fiber, infrared or radio wave. This is the physical layer. This is where your network card exists, your passive hubs, your patch panels and your cabling.

Back to top

There has been a lot of preparation along the way. We had to agree where to get started. That took us to the Application Layer. Then we had to agree on the character set we would use at the Presentation Layer. Once we had done that, we made reservations at the Session Layer hotel. At the Transport Layer we divided everyone up into groups called the Maximum Transmission Unit. When we reached the Network Layer of our preparation, we determined the route we would travel, and found that we would probably only know the next intersection we were going to at any one time. The Data Link Layer packaged us into frames where we were sent out using different signaling methods and given a destination hardware address. Finally, we were sent on the road and now we're off. We hope you have a good trip free from collisions and that you reach your destination before your time to live expires.

If you have found this illustration helpful, please let us know by emailing us at RTNetworks.

©Copyright 2006

You may copy this paper, as long as you give proper credit.