The Functionality of the OSI Model

harhis23

For example, consider a case where a programmer develops a new TCP/IP protocol stack using the modular approach of the OSI Reference Model. He then decides, a year later, that there's a more efficient way to lay raw data out onto the network. Because of the modular design of his existing protocol, rewriting and recompiling the parts of the protocol stack that handle the Data Link and Physical layer responsibilities (usually the job of the network adapter driver) is very easy. However, if he had not followed the OSI Model and had created his protocol by writing one huge chuck of code, it would be much more difficult to update the protocol; it might even be necessary to completely rewrite it.

Protocol software based on the OSI Model includes a broad range of functionality, from the NIC driver, to the software that transports the information across the network and checks data integrity, and on to the program that interacts with the actual applications.

Not all software programs written for use with network protocols include all the functions defined in the OSI Model. For example, one company might manufacture only network cards. If this is so, then it will not want to be concerned with how one application speaks to another. The design of the OSI Model allows this company to focus on the development of the hardware and software at the bottom of the model while allowing someone else to design the software that will operate at a higher level of the model.

As OSI Analogy

The OSI Model works much like our modern postal service. Assume for a minute that you are an application running on a computer that needs to speak with another application that resides on a different computer across the network (in this case the network will be the many transports of the U.S. Postal Service). The first step in sending your information to the other application would be to write a letter; place it in an envelope with a name, address, and correct postage; and then drop it in the mailbox. At this point, you probably don't care (and may not know) how the letter gets to its final destination-your primary concern is only that it gets there somehow.

From there, the envelope is picked up by a postal worker and placed into a mail bag for delivery to the local post office. The letter is then routed to another post office by car, truck, van, rail, or air-depending on priority-and re-sorted. From there, it is usually placed in another postal worker's mailbag and delivered to the recipient's door. Again, you generally do not concern yourself with the exact means of transportation of your mail-you just know that when you follow the correct "protocols" and place the mail in your mailbox, it usually arrives at its destination.

In this way, only those responsible for a particular leg of the trip need to be concerned with how information gets from point A to point B. If part of the process needs to be changed to allow for newer technology or a better implementation of a process, only that piece needs to be changed. All the other processes and protocols in place do not need to be modified and can continue to run as normal.

Fortunately, Microsoft Corporation has developed its implementation of TCP/IP in accordance with the standards. Because TCP/IP follows a modular reference model much like the OSI, Microsoft's TCP/IP (MS TCP/IP) is modular as well. However, Microsoft has added some extra features and a couple of additional interfaces to its version of TCP/IP. Additions include extended support for NetBIOS (used extensively by Windows applications and services), TDI (Transport Driver Interface), and NDIS (Network Device Interface Specification) interfaces. These add-ins make it easier for independent software vendors (ISVs) and independent hardware vendors (IHVs) to write applications and drivers for MS TCP/IP.

130, 134