Return to Table of Contents

Chapter 1

TCP/IP Overview

Introduction

TCP/IP’s “Net” Worth

More Power, More Flexibility—and More Potential for Problems

What’s Ahead in This Chapter

TCP/IP: Where It Came From, and Where It’s Going

History of the TCP/IP Protocols

The Role of the U.S. Department of Defense

From ARPAnet to the Internet

Another Contender for the Title: The OSI Protocol Suite

The Future of TCP/IP

Looking Ahead to IPv6

Networking Models

The Purpose of the Models

Why Use Layered Models?

The ISO OSI Model

Seven Layers of the Networking World

Layer 7: The Application Layer

Layer 6: The Presentation Layer

Layer 5: The Session Layer

Layer 4: The Transport Layer

Layer 3: The Network Layer

Layer 2: The Data Link Layer

Layer 1: The Physical Layer

The DoD Model

The Application/Process Layer

The Host-to-Host (Transport) Layer

The Internetworking Layer

The Network Interface Layer

The Microsoft Windows 2000 Networking Model

The Application and User Mode Services Component

The API Boundary Layer

The File System Drivers

The TDI Boundary Layer

The Network Transport Protocol Component

The NDIS Boundary Layer

The NDIS Wrapper

A Family of Protocols: The TCP/IP Suite

Application Layer Protocols

FTP

SNMP

Telnet

SMTP

HTTP

NNTP

Transport Layer Protocols

TCP

UDP

Network Layer Protocols

IP

ARP and RARP

ICMP

IGMP

TCP/IP Utilities

Basic Network Design

Planning as Preventative Medicine

Testing and Implementation

Prototyping

Pilot Programs

Rollout

Summary

FAQs

Solutions in this chapter:

           History of TCP/IP (ARPAnet); The Future of TCP/IP (IPv6)

           The TCP/IP Protocol Suite

           The OSI, DoD, and Windows Networking Models

           Basic Network Design Issues

Introduction

The Transmission Control Protocol/Internet Protocol (also referred to as the TCP/IP protocol stack, or just plain TCP/IP) is a familiar—if poorly understood—networking component to most modern network administrators and Information Technology (IT) professionals.

Note: Administrators and users may also be familiar with the higher-level protocols used on the Internet, such as File Transfer Protocol (FTP), Hypertext Transfer Protocol (HTTP), and Telnet. These, along with other protocols, are often packaged with TCP/IP as part of the “suite.”

If you work in any but the smallest networked environment, chances are you’ve encountered TCP/IP. However, it wasn’t always that way. Just a few short years ago, TCP/IP was regarded as a somewhat sluggish, difficult-to-configure protocol used primarily by university or government networks participating in an exotic wide area networking project called ARPAnet. It was considered too slow and complex to be an appropriate choice for most private organizations’ local area networks (LANs).

Microsoft and IBM workgroups ran fine on NetBEUI, a fast and simple transport protocol that could be set up easily and quickly by someone without a great deal of expertise. Novell NetWare LANs used the IPX/SPX stack, which was routable and thus could be used with larger server-based networks. Few business networks had any need for a powerful but high-overhead set of protocols like TCP/IP.

Then something happened: the Internet.

TCP/IP’s “Net” Worth

The obscure worldwide network of networks had formerly been used by only a handful of elite groups until it was discovered by the corporate world—and then by individual computer users. An online population explosion erupted. Everyone rushed to get connected to the global Net, and TCP/IP, on which it was based, catapulted to the top of the protocol popularity polls.

Note:

Request for Comments (RFC) 1180, available on the Web, provides an authoritative tutorial on the TCP/IP protocol suite.

There have been occasional attempts to usurp its position at the top. The Open Systems Interconnection protocol suite, based on the famous (or infamous) seven-layer OSI networking model, was conceived with the idea of unseating the incumbent and replacing TCP/IP as a universal standard for internetworking communications. In fact, in the late 1980s the U.S. Government, which had played an important part in creating and developing TCP/IP, made plans to phase it out in favor of the OSI suite. It didn’t quite work out that way. TCP/IP turned out to be the protocol stack that refused to go quietly into that good night.

In fact, TCP/IP has flourished. It is available as a standard protocol included with all Windows operating systems and is installed by default in Windows 2000.

Note:

Although TCP/IP is a “universal” protocol stack, which allows communication between machines running different operating systems or even running on different platforms, be aware that different vendors’ implementations of the protocols may differ slightly. This book focuses on Microsoft’s implementation of TCP/IP in Windows 2000, although we also discuss interoperability with NetWare and UNIX networks.

UNIX machines, the original cornerstones of Internet communication, have been running on TCP/IP since the early days of its development, and TCP/IP support is a part of every popular Linux distribution. Apple Macintosh computers and IBM’s AS/400 machines use TCP/IP. Even NetWare, long a holdout for its Internet Packet Exchange/Sequenced Packet Exchange (IPX/SPX) stack, has finally come over to the TCP/IP camp; NetWare 5 is the first version designed to run on “pure” IP.

On the other hand, as you scroll through the list of protocols that can be installed from the Windows 2000, NT, or 9x CD-ROM, you won’t see “OSI protocol suite” among them. The OSI model is an accepted standard for networking implementation, and the OSI suite mapped to the model more elegantly than other protocol sets already in use, However, TCP/IP was too firmly engrained to be easily dethroned as king of the internetworking world.

It was as if someone announced that he had discovered a replacement for dirt and suggested that we uproot all the trees and plants and then “reinstall” them in the new, superior substance. Restructuring the huge, sprawling global Internet to plant it in a different protocol environment—regardless of any advantages that new environment might offer—is just too overwhelming an undertaking.

TCP/IP may have to adapt as computer communications continue to evolve (the expected transition to IPv6 is one example), but it is likely to be around for some time to come.

More Power, More Flexibility—and More Potential for Problems

TCP/IP had to be good to survive the challenges and attain the position it occupies today in computer networking, but that doesn’t mean its implementation is always free of problems. On the contrary, the complexity that makes it so flexible and capable of connecting large, diverse networks also makes it prone to configuration errors and difficult to troubleshoot.

Luckily for network administrators, necessity being the mother of invention resulted in the development of many tools and utilities for troubleshooting TCP/IP connectivity problems. Many of these are free, and several are included as part of Windows 2000’s implementation of the TCP/IP protocol suite.

Administrators of TCP/IP networks will also find the documentation of the TCP/IP protocol far more extensive than that for any other network/transport protocol. Because it is used on such a widespread basis, books, articles, courses, and Web resources for troubleshooting IP connectivity problems are plentiful.

What’s Ahead in This Chapter

In this chapter, we will look at both the history and the future of the TCP/IP suite, to better help us understand what it is and how it works today. We’ll examine in some depth the more generic OSI networking model and TCP/IP’s own  model, often referred to as the Department of Defense (DoD) model.

We will break down the components of the so-called “suite” of protocols that have taken up residence with the original TCP and IP stack. We’ll also examine how common connectivity devices, such as repeaters, bridges, routers, and switches, are used to expand or segment TCP/IP networks.

 Finally, we’ll discuss some general guidelines for planning, testing, and implementing a big change such as the setup or migration of a Windows 2000 TCP/IP network. Just as a physician is better able to treat a sick patient if he knows the person’s background, characteristics, and how the patient normally behaves when not ill, network administrators confronted with “sick” dysfunctioning networks will be at a big advantage if they know the network's’ “anatomy” or components well. The protocol on which the network depends for communication is one of its most important “body parts.” The objective of this chapter is to give you a detailed patient history and a quick review of TCP/IP physiology that will allow you to recognize symptoms, diagnose its illnesses, and select the most effective treatment. We know that a healthy network makes for a happy network administrator.

TCP/IP: Where It Came From, and Where It’s Going

Acronyms abound in the computer industry, and network administrators may think of TCP/IP as just another collection of mysterious letters used to refer to some obscure concept whose name they’ve long forgotten.

If pressed, most could tell you that it’s a protocol—and some even know that a protocol is a set of standardized rules for communicating. Maybe one or two could even tell you that the word comes from Greek word protocollon, which referred to a leaf of paper glued to a manuscript volume that described the volume’s contents.

But any basic networking text lists dozens or even hundreds of protocols: hardware protocols, routing protocols, remote access protocols, printing protocols, LAN and WAN protocols, encapsulation protocols. Why should we get all excited about TCP/IP? What makes it so special?

For the answer to that question, let’s consider the origins of the TCP/IP protocol suite, and what it’s used for today.

History of the TCP/IP Protocols

“The subject of history is the gradual realization of all that is practically necessary.” (Friedrich Schlegel, 1772–1829, German philosopher).

Practical necessity is the driving force behind most important inventions and developments, and the need for a reliable set of communications protocols suitable for connecting large networks led to the creation of the TCP/IP stack.

In the 1960s, computer networking was in its infancy. The benefits of connecting computers together so they could share resources were only beginning to become apparent. The equipment was expensive, and products from different manufacturers were, for the most part, incompatible. Few business entities had the money or inclination to bother with creating local networks, much less attempt to get their computers to “talk” to distant systems.

The Role of the U.S. Department of Defense

The U.S. Department of Defense recognized the value of establishing electronic communications links between major military installations. (Grim as it may seem, a primary motivation was the desire to maintain communication capabilities in the event of the mass destruction that would come with nuclear war.) Major universities were also involved in networking projects. The DoD-funded research sites throughout the United States, and in 1968, the Advanced Research Projects Agency (ARPA) contracted with a company called BNN to build a network based on packet-switching technology.

Tech Talk

Many people easily confuse the terms  packet switching and circuit switching. Even experienced network administrators, if they haven’t had much exposure to the conceptual and hardware sides of WAN technology, find them a little mysterious. They sound like the same thing, but they’re not.

Circuit switching technology is something we use all the time, whether we’re aware of it or not. The public telephone system (which is formally called PSTN, or Public Switched Telephone Network) is the more familiar example of switched circuit communication. An end-to-end communication link is established when you place a telephone call, and that same physical path from one end (your telephone) to the other (Aunt Mary’s telephone in Boise, Idaho, for example) is maintained for the duration of that call. The path is reserved until you break the connection by hanging up.

If you call Aunt Mary again next week, the pathway (also called the “circuit”) used may be completely different. That’s where the “switching” comes in, and that explains why sometimes when you talk to Aunt Mary, the connection is clear, while other times there’s so much noise and static on the line that you have to ask her to repeat herself when she tells you whose quilt won first prize at this year’s county fair.

Packet switching is different in that there is no dedicated pathway or circuit established. It is known as a “connectionless” technology for that reason. If you send data from your computer to your company’s national headquarters in New York over a packet-switched network, each individual packet, or chunk of data, can take a different physical route to get there. Most traffic sent across the Internet uses packet switching.

A type of digital packet switching network called X.25 can also support virtual circuits, in which a logical connection is established for two parties on a dedicated basis for a certain duration (a Permanent Virtual Circuit, or PVC, is an ongoing, dedicated logical connection, but the physical circuit can be shared by more than one logical connection).

The next year, the ARPAnet was born when its first node, or connection point, was installed at the University of California at Los Angeles. Within three years, the network had spread across the United States, and two years after that, to the European continent.

Remember that ARPAnet’s original purpose was to provide a network capable of surviving a devastating war. This meant redundancy and reliability took precedence over other considerations (like data transmission speed). Consequently, the first links were slow by today’s standards (56k leased lines).

Note:

An excellent detailed history of the creation of ARPAnet and its evolution into today’s Internet is available at the Web site of the international organization called the Internet Society (ISOC) at www.isoc.org/internet/history/brief.html.

It was important that the networking protocols be reliable and scalable to accommodate multiple redundant sites and anticipated growth (although no one at that time expected the rate of growth that was to come). Perhaps following the timeworn advice that “if you want it done right, you have to do it yourself,” the developers of the ARPAnet designed a new group of protocols that fit the bill. Their first attempt was the Network Control Protocol, but it proved to be unsuitable as traffic increased. By the mid-1970s, necessity had mothered invention again, and the TCP/IP protocol suite was implemented.

From ARPAnet to the Internet

The “network” continued to grow in population and popularity. It eventually split into two parts, with the military calling its part of the internetwork Milnet, with ARPAnet still being used to describe the network that connected research and university sites. In the 1980s, ARPAnet was replaced by the Defense Data Network (a separate military network) and NSFNet, a network of scientific and academic sites funded by the National Science Foundation.

In the 1990s, the global network (now called the Internet) went commercial in a big way. Corporations realized the advertising and marketing potential of a medium that spanned the whole world. Smaller businesses began to see the light—and the dollar signs—as well. Individuals wanted access to the vast amount of information (and entertainment) available on the World Wide Web. Internet Service Providers (ISPs) sprang up like weeds to satisfy the demand for connectivity.

Note:

Estimates vary, but according to the Internet Software Consortium, by July 1999 there were over 50 million host computers connected to the Internet.

As the year 2000 begins, the impact of the Internet on the computer industry and on lifestyles in general is being felt all across the planet. We have, to a large extent, networked the world. The Internet, still running on the TCP/IP protocol suite, has made it possible to do things that could not have been imagined by the average person just a decade ago.

School children have the equivalent of large libraries at their fingertips; business executives stay on top of what’s going on at the office from thousands of miles away; telecommuters do a full day’s work without ever leaving home. We can play the stock market via computer, do our banking online, or chat casually with close friends we’ve never met in places we might have never known existed except for the Net.

Few of those whose lives have been changed by the rapid development of computer networking technology realize that they owe it all (well, at least a lot of it) to TCP/IP.

Another Contender for the Title: The OSI Protocol Suite

The OSI protocol suite was intended to be TCP/IP’s replacement. In fact, a few years ago it was an accepted “fact” in many parts of the computer industry that the future of networking would be built on the OSI suite.

It seemed like a good idea at the time. The OSI suite consisted of a set of protocols that would map directly to the popular OSI networking model, and which would—at least in theory—make for less confusion and easier standardization of networking products among multiple vendors. The TCP/IP stack had been designed on the less finely tuned DoD networking model.

The OSI protocol suite was developed under the umbrella of a body called the ISO—making for an interesting conglomeration of initials. As if it weren’t already confusing enough, the full official name of the ISO is the International Organization for Standardization, which would seem to call for an acronym of IOS (which would be further confused with Cisco’s Internetworking Operating System, or IOS, used to command its fleet of routers). The organization is quick to point out that its short name—ISO—is not an acronym but a word, derived from the Greek isos, meaning "equal.” The ISO is, according to its own accounts, a worldwide federation of national standards bodies from 130 countries whose stated mission is the promotion of the development of standardization and related activities throughout the world.

The ISO’s role in establishing standards is not confined to the computer industry. For years, photographers have been familiar with the ISO film speed codes used by manufacturers of photographic film. The ISO, headquartered in Geneva, Switzerland, has been instrumental in developing standards for the format of telephone and banking cards, so that the cards can be used in different countries throughout the world. The international country and currency codes are another example of an ISO standard.

Note:

For more information about the organizational structure and mission of the International Organization for Standardization (ISO), visit their Web site at www.iso.ch/.

The idea of a carefully planned and implemented new set of protocols for connecting to the global Internet that could be standardized throughout the world was an attractive proposition. A great deal of work went into development of the OSI protocol suite, hailed as the heir to the Internet protocol crown.

But it turned out that the reports of TCP/IP’s death had been greatly exaggerated.

Survival of the Fittest?

In the late 1980s, the Department of Defense decreed that by August 1990 all its computer communications would use OSI protocols, and the U.S. federal government formed a set of specifications called GOSIP (Government OSI Profile) that defined standards for these protocols. The federal government had, in effect, planned the death of the TCP/IP suite.

TCP/IP was now considered a temporary solution to the problem of providing reliable internetworking protocols. The new proposed Internet standards included X.400 (for e-mail) and X.500 (for directory services).

The computer industry was gearing up to make the transition, but not everyone welcomed the change. So in 1990, the ISO Development Environment (ISODE) was created. The ISODE software allowed OSI applications to run over TCP/IP. The TCP/IP suite was already in wide use and was not going away as planned, so it was decided that GOSIP would incorporate TCP and IP, loosening its original “only OSI protocols” requirements.

The current goals of OSI proponents seem to be less ambitious, now focused on a convergence of TCP and OSI Transport Protocol Class 4, which would support both OSI applications and applications from the Internet Protocol Suite. IPv6 (sometimes called IPng for IP “next generation” is expected to be the big protocol player at the IP layer.

The Future of TCP/IP

Although the TCP/IP suite has proven its endurance and is likely to be with us for a while, it will undoubtedly undergo some changes. For protocols, as for people, a long life usually requires the ability to adapt to changing conditions. As the Internet continues to grow, the most pressing need is a way to overcome the limitations of the current version of IP in terms of the number of IP addresses available.

At the time IP’s 32-bit addressing scheme was designed, computers were still expensive devices used primarily by large companies. Many businesses were not yet computerized, and the idea of an individual owning a computer—much less setting up a home network—bordered on absurdity. It must have seemed that there would never be any danger of running out of addresses (and consequently, many usable addresses were “wasted” by the assignment method), but then at that time it was also inconceivable that computers would ever be as powerful and as inexpensive as they are today.

When it comes to making predictions about technological progress, the one constant has been a tendency to underestimate. After all, Thomas Watson, former chairman of IBM, is best remembered for the following statement, made in 1949: “I think there is a world market for maybe five computers.”

Looking Ahead to IPv6

IPv6, or IPng (the “ng” stands for “next generation”), is the new version of the Internet Protocol (IP). The Internet Engineering Task Force (IETF) designed it as the next step up from IPv4. It builds on IPv4 and is a natural progression. It is compatible with IPv4, which is currently used on the Internet and other TCP/IP networks. The specific intent of IPv6 is to work efficiently in high-performance networks such as ATM (Asynchronous Transfer Mode), while still working efficiently over low-bandwidth networks (which would include many of the wireless technologies).

Next Generation IP: A Luxury or a Necessity?

Why do we need a “next generation” of IP? The answer can be summed up in one word: growth. Internet connectivity has exploded, and it shows no sign of slowing anytime soon. Technology gurus predict that in the future, even our household appliances will be wired to the Internet so we can communicate with them from afar. (This conjures up images of typing in a few commands and sending them off to your microwave oven, instructing it to have dinner ready when you get home—an idea that may become reality sooner than you think.)

If we are to be prepared to assign an IP address to every refrigerator and toaster, we must think big in planning the next version of the protocol that will be used to accomplish these addressing feats. Perhaps the most important lesson to be learned from our experience with IPv4 is that the addressing and routing capabilities of the next generation’s Internet Protocol must be able to handle scenarios that may currently seem unlikely, based on seemingly exaggerated estimates of future growth.

How Many IP Addresses Are Enough?

IPv4 uses IP addresses that are 32-bit binary numbers (usually expressed in dotted decimal for convenience). Each IP address consists of two parts that identify the network ID and the host ID. This provides for approximately 4 billion individual unique addresses—at least, mathematically and theoretically, it works out to that number. If there were actually this many usable addresses, we might not have to worry about running out anytime soon. Unfortunately, that’s not the case.

Internet authorities do not assign IP addresses one at a time; rather, they are allocated as class A, B, or C networks, which consist of blocks of addresses of varying sizes. There are 126 usable class A networks, and each can have approximately 16 million hosts. There are far more class B networks: about 16 thousand, but each is limited to fewer hosts, about 65,000. As for class C networks, there can be around 2 million of them; however, they can have a maximum of 254 hosts.

In the early days of the Internet, IP addresses were plentiful, and many were handed out with abandon. For instance, the entire Class A Network ID 127.0.0.0 was reserved for use as a “loopback” address (more about that later) used to test the integrity of a computer’s TCP/IP stack. This resulted in 16,777,216 wasted addresses! Class A and B networks were given to organizations that had nowhere near the number of allowed hosts, wasting more addresses. They weren’t missed, because there were plenty more where those came from; the mentality was the same sort that led to current environmental problems, shortages of once-plentiful natural resources and near-extinction of some animal species.

In 1991, there were a little over 1 million hosts on the global Internet. By 1997, there were over 16 million. Today, according to the Internet Society, there is an estimated 50 million. If growth continues at this rate, the prospect of using up all the available addresses will become very real.

One way to solve the problem is to implement a new version of IP that uses a larger address space. IPv6 is based on 128-bit addresses. This provides for a total number of IP addresses which, represented exponentially, is 2 to the 128th power. The actual number would take up an entire line of space; it’s safe to say it definitely adds up to “a lot.”

However, IPv6 does more than provide for a greater number of IP addresses. It also adds several improvements to IPv4, which will make routing and network autoconfiguration easier. Another concern in creating the new version of IP is to use a more flexible way of organizing addresses that are not dependent on the class structure. Classless InterDomain Routing (CIDR,pronounced “cider”) can be used to overcome some of the problems encountered with the old method of network/address assignment.

The Market for IP Today

 IPv4 today serves what some have called the “computer market.” This market has driven the stupendous growth of the Internet over the last decade. It is based on the enormous number of private and public networks that have come into being, including computers of all types: business workstations and servers, home PCs, traditional mobile (laptop and notebook) computers, mini-mainframes, all the way up to supercomputers.

This market has grown at an exponential rate, and continues to do so. However, industry experts predict that it will not necessarily be the driving force behind the next phase of growth, and it is that phase for which the next generation of IP must prepare us.

The IP Marketplace of the Future

The computer market described previously is by no means going to disappear. It is logical to assume, however, that it will eventually reach a saturation point, and growth in that sector of the marketplace will stabilize. It is just as likely that other kinds of markets will develop, some of which we might not have imagined a few years ago.

These new markets could fall into several categories. The potential offered by new high-speed, low-cost connectivity technologies such as DSL and cable makes it feasible to envision innovations in the near future that were the stuff of science fiction in the recent past. The set-top box, combining television with the Internet, is already a reality. “Smart homes” with components strategically wired to the Net and capable of being managed from afar can be built (albeit at a cost too high for the average homebuyer) today. Wireless Internet access via cellular technology is here already. Automobiles that incorporate networked computers are reportedly just around the corner.

As impossible as it might seem today, it may be that 20 years from now, we’ll look back at the 1990s as a time when the Internet was small, “only” doubling in number of hosts every year. A new version of IP that will meet this challenge seems more and more of a necessity as we consider the possibilities.

Making the Transition

Don’t worry; it’s not likely you’ll wake up one day and suddenly see an announcement that on a particular date, at a particular time, the Internet is switching to IPv6. The new version is expected to replace IPv4 gradually, and the two will coexist for a number of years as the transition occurs. Meanwhile, the groundwork is being laid. All Winsock 2.0-compliant applications will automatically support the IPv6 protocol stack. Microsoft is hard at work developing an implementation of IPv6. Cisco is building routers that will take advantage of the next generation of IP.

Note:

Microsoft Research (MSR) is working on an IPv6 implementation based on the Windows NT/2000 platform. An alpha version of this implementation is publicly available in both source and binary forms. For more information, see www.research.microsoft.com/msripv6/.

Change is inevitable (except perhaps from vending machines), and network administrators may as well get ready to greet IPv6 with open arms. Like any major transition, there is sure to be some pain involved. The IETF has designed a migration strategy that defines IPv4 and IPv6 as two different protocols with two separate protocol stacks, and IPv6 was designed for compatibility with the older version so the upgrade could be done over time. DNS and DHCP servers will require updating, and the management of coexisting 32-bit and 128-bit addresses is expected to produce some problems. Resistance is futile; the next generation is upon us.

For IT Professionals

The IETF has created a new protocol called 6to4, the purpose of which is to encapsulate IPv6 packets inside IPv4 packets. This will allow networks that migrate to IPv6 early to be able to send their data across the Internet, even if the ISPs they use don’t yet support the new version of IP.

Many ISPs are now using Network Address Translation (NAT) to allow for the translation of multiple private IP addresses, which don’t have to be registered, to a lesser number of public assigned addresses. For this reason, those ISPs have not been in a hurry to implement IPv6 support. Reconfiguring all of their equipment to use IPv6 addresses would be a big project, requiring a great deal of time and effort.

The recent popularity of NAT devices and software implementations of NAT (along with inexpensive proxy software) has taken the edge off the urgency of upgrading, at least for some companies. NAT is built into Windows 2000 Server products, and a simple, “lighter” version of NAT called Internet Connection Sharing (ICS) is included in the Windows 2000 and Windows 98SE operating systems. Using one of these, all of the computers on a network can access the Internet using just one public registered IP address.

The new 6to4 protocol will solve the compatibility problem for those corporate networks that do wish to adopt IPv6 sooner rather than later, and may make migration more attractive to others, too. The 6to4 protocol is installed on a router that serves as a gateway from the IPv6 network to the Internet. It works by automatically assigning a prefix to each IPv6 address, which identifies it as a 6to4 address. Then it establishes a tunnel over IPv4, through which the IPv6 packets can travel to another IPv6 network.

Networking Models

As a network administrator, you are familiar with the common networking models You may have heard of both the OSI model and the DoD model (at the very least, you’ve seen references to them earlier in this chapter). You may even be able to recite from memory the seven layers of the OSI model, or tell how the four layers of the DoD model correspond to them.

But, do you really understand what the models represent? And do you know the functions of those layers you named? If not, keep reading. We will briefly visit the hallowed halls of Basic Networking Concepts 101 (or, in Microsoft parlance, Networking Essentials) and look at where the models fit into real-life network administration.

The Purpose of the Models

 A network protocol is a set of rules used by computers to communicate. Protocols had to be developed so that two computers attempting to transfer data back and forth would be able to “understand” one another. Some describe protocols as “languages,” but this isn’t entirely accurate and can cause confusion since computer languages are an entirely different concept. A protocol is more like the syntax of the language (the order in which the words are put together) than the language itself.

Note:

The words "data" and "information” are sometimes used interchangeably, but technically they are two different things. In computer communications, data is the series of electrical charges arranged in patterns that represent information. The “data" is not the information itself; it is the encoded form of the information. “Information” is the data in usable form, the decoded form of the data that can be displayed as a word processing document or an e-mail message or used to make a calculation in a spreadsheet.

The first networking protocols were proprietary; that is, each vendor of networking products developed its own set of rules. Computers using  a specific vendor’s protocol would be able to communicate with each other, but not with computers that were using the networking product of a different vendor. This had the effect of locking a business in; the business would need to always use the same vendor in order to maintain compatibility.

The solution to this problem was the development of protocols based on open standards. Organizations such as the ISO were charged with overseeing the definition and control of these standards and publishing them so that they would be available to any vendor that wanted to create products that adhered to them. The advantage to the consumer is that no longer is he forced to patronize a single vendor.  The advantage to the vendor is that its products are more widely compatible and thus can be used in networks that started out using a different vendor’s products.

A model provides an easy-to-understand description of the networking architecture and serves as the framework for the standards. The OSI model has become a common reference point for discussion of network protocols and connection devices.

Why Use Layered Models?

As we look at each of the popular networking models, you’ll see that all use layers to represent areas of functionality. In  OSI terms, each of the layered specifications uses the services of the layer below to build an ””enriched service.” The layered approach provides a logical division of responsibility, where each layer handles prescribed functions. This can be compared to the teamwork exhibited by a good assembly-line crew in building an automobile. One worker may be responsible for fitting a wheel onto the axis, another for inserting and tightening the screws, and so forth. There are several advantages to this type of working model:

Each worker only needs to be concerned with his or her own area of responsibility.

           Each worker becomes extremely proficient, through constant repetition, at his or her particular job.

           Working together in sequence, the team of workers is able to produce the final product much more quickly and efficiently than one person could, or than a group of people with no assigned responsibilities could.

           If something goes wrong (for instance, if a particular part was put on incorrectly), the supervisor knows who to blame for the problem.

Likewise, when the networking protocols are divided into layers, communication generally flows more smoothly, and when it doesn’t, troubleshooting is easier because you are better able to narrow down the source of the problem to a specific layer.

We will examine three networking models: the ISO’s OSI model, the Department of Defense (DoD) TCP/IP model, and Microsoft’s Windows NT model. We’ll start with the most generic and work our way toward the more specific.

The ISO OSI Model

The OSI model is used as a broad guideline for describing the network communications process. Not all protocol implementations map directly to the OSI model, but it serves as a good starting point for gaining a general understanding of how data is transferred across a network.

Seven Layers of the Networking World

The OSI model consists of seven layers. The number seven carries many historical connotations; it is thought by some to signify perfect balance, or even divinity. Whether this was a factor when the designers of the model decided how to break down the functional layers, it’s safe to say that within the technical community, the Seven Layers of the OSI Model are at least as legendary as the Seven Deadly Sins and the Seven Wonders of the World.

The data is passed from one layer to the next lower layer at the sending computer, until the Physical layer finally puts it out onto the network cable. At the receiving end, it travels back up in reverse order. Although the data travels down the layers on one side and up the layers on the other, the logical communication link is between each layer and its matching counterpart, as shown in Figure 1.1.

Figure 1.1 Communication takes place between corresponding layers.

Here’s how that works: As the data goes down through the layers, it is encapsulated, or enclosed within a larger unit as each layer adds its own header information. When it reaches the receiving computer, the process occurs in reverse; the information is passed upward through each layer, and as it does so, the encapsulation information is evaluated and then stripped off one layer at a time. The information added by the Network layer, for example, will be read and processed by the Network layer on the receiving side. After processing, each layer removes the header information that was added by its corresponding layer on the sending side.

It is finally presented to the Application layer, and then to the user’s application at the receiving computer. At this point, the data is in the form it was in when sent by the user application at the originating machine. Figure 1.2 illustrates how the header information is added to the data as it progresses down through the layers.

Figure 1.2 Each OSI layer except the Physical layer adds header information to the data.

Note that in the foregoing example, the header information that is added by the Application layer is called a “link header,” as is that added by the Data Link layer. These headers mark the first and last headers to be added. The Data Link layer also adds a Link Trailer. Many books teach the OSI layers “upside down”; that is, starting with the bottom layer. In fact, the Physical layer is often referred to as Layer 1, the Data Link as Layer 2, and so on. Other descriptions start (seemingly logically) at the topmost layer. Which way you look at it depends not on which hemisphere you live in, but on whether you’re addressing the communication process from the viewpoint of the sending or the receiving computer. We will examine the process from the top down, as the data is prepared by the sending computer to go out over the cable or other media. We will, however, stick with the standard numbering convention.

Layer 7: The Application Layer

Keep in mind that the model describes only the networking components. If you remember that, you won’t make the common mistake of thinking the Application layer represents the user application software. What the Application layer really does is provide the interface and govern the interaction between that user application  and the network protocols. The Application layer protocols accept user data for network transport.

The data is created by the user application, above the networking layers. For instance, if you want to send an e-mail message, your user application might be Microsoft Outlook (the user program is sometimes referred to as the “user agent”). The user sees only the application interface. You type your letter to Cousin Mary, perhaps you attach graphics files containing photos from your last family outing to Yellowstone National Park of the grizzly bear who almost ate Uncle Joe, and click Send. Assuming you typed the correct e-mail address in the “to” field, you have the software configured properly, your hardware is working, your phone lines aren’t down, and your ISP is on the ball (quite a lot of assumptions, to be sure), the message goes through and lands in Mary’s virtual mailbox.

Neither you nor Cousin Mary has to know anything about what the networking components of your respective operating systems are doing in order to communicate via e-mail. That’s because the application itself (Outlook)  sends the data (the message you typed) to the Application layer, which takes it from there. The Application layer adds header information, which will be used by the Application layer on the receiving end, and passes it down to the next layer.

Layer 6: The Presentation Layer

No, the Presentation layer doesn’t turn the data into PowerPoint slides. However, as the name suggests, it is responsible for the way in which the data is presented, or formatted. The Presentation layer handles such things as encryption (presenting the data in such a way as to keep it from being readable by unauthorized persons) and compression (packaging the data in such a way as to get more of it through at a time).

On the receiving side, the Presentation layer is responsible for translating the data into a format understandable by the application and presenting it to the Application layer.

Since the Presentation layer handles the very important task of protocol translation, this layer is where many gateways operate. Remember how we said earlier that in order to “talk” to one another, computers need to be running the same protocol? Well, a gateway lets you circumvent this rule. It acts as a translator and allows computers using different protocols to communicate with one another. Examples include:

E-mail gateway This software translates the messages from diverse, noncompatible e-mail systems into a common Internet format such as the Simple Mail Transfer Protocol (SMTP). Thus, Cousin Mary is able to read your letter even though you were using Microsoft Outlook with an Exchange server and she is on a NetWare network using Groupwise mail.

SNA gateway Systems Network Architecture (SNA) is a proprietary IBM architecture used in mainframe computer systems such as the AS/400. An SNA gateway allows personal computers on a local area network to access files and applications on the mainframe computer.

Gateway Services for NetWare (GSNW) This software is included with Windows 2000 (and Windows NT) Server operating systems to allow the Windows server’s clients to access files on a Novell NetWare server. It translates between the SMB (Server Message Block)  file sharing protocol used on  Microsoft networks and NCP (NetWare Core Protocol), the file sharing protocol used by the NetWare networks.

Note:

Although many gateways operate in the Presentation layer, different gateways operate at different layers. A gateway can perform functions seen in any layer of the OSI model.

There are almost as many gateway products available as there are different protocol combinations, and more are being developed all the time as interoperability becomes increasingly important in our connectivity-obsessed world.

Layer 5: The Session Layer

The Session layer handles the task of establishing a one-to-one session between the sending and the receiving computers. The Session layer sets up and tears down application-to-application dialogs, and provides for checkpointing to synchronize the data flow for the applications.

The Session layer also controls whether a transmission is established as half or full duplex. Full duplex is bidirectional communication in which both sides can send and receive simultaneously.  Half duplex is also bidirectional communication, but the signals can only flow in only one direction at a time.

To illustrate the difference, think of how a telephone conversation works. Both parties can talk at the same time, and you can still hear the other person’s voice while you’re talking. That’s full duplex. With most two-way radios, when you key the microphone to speak, you can’t hear anything the other person might be saying while you’re speaking. Only one of you can broadcast over the channel at a time. That’s half duplex.

Note:

When the communication can only flow in one direction, and can never flow back the other way (unidirectional), it’s called simplex.

Another important responsibility of the Session layer is to define the rules for data exchange between the applications. In this respect, you might think of the Session layer as a referee or mediator who makes sure both parties (the sending and receiving computers) are aware of and agree to follow the “rules of the game” for that particular session.

When two family members are at odds and seek counseling to help them communicate with one another, a good counselor or mediator will start the visit by getting both people to agree to certain rules. These might include who gets to talk first, and for how long, as well as the “format” of the communication (i.e., no yelling, screaming,  or name-calling).

Although computers aren’t known for getting emotional, before they can communicate effectively they also must negotiate communications guidelines. Otherwise, they may bombard each other with too much data to be processed, or both try to “talk” at the same time. The Session layer controls this flow of conversation so that the message will get through clearly. In this way, the Session layer provides for flow control. This usually works quite well. Family counselors undoubtedly wish their jobs were as easy as that of the Session layer protocols.

Other duties of the Session layer include providing for data expedition, class of service, and reporting of problems occurring in the Session layer and those above it.

Layer 4: The Transport Layer

The Transport layer’s primary responsibility is reliability. It  must verify that the data sent arrives at the intended destination, in good condition. It also must have a way to differentiate between the communications that may be coming to the same network address (the IP address) from or to different applications.

Port Numbers

Thanks to the multitasking capabilities of Windows 2000 and other modern operating systems, you can use more than one network application simultaneously. For example, you can use your Web browser to access your company’s homepage at the same time your e-mail software is downloading your e-mail. You probably know that TCP/IP uses an IP address to identify your computer on the network, and get the messages to the correct system, but how does it separate the response to your browser’s request from your incoming mail when both arrive at the same IP address?

That’s where ports come in. The two parts of an IP address that represent the network identification and the host (individual computer) identification are somewhat like a street name and an individual street number. In this analogy, the port number  would identify the specific apartment or suite within the building.

TCP and UDP, the Transport layer protocols, assign port numbers to each application so the data intended for the Web browser in Apartment A doesn’t get sent to the e-mail program living in Apartment B.

Connection Service Types

Two types of connection services are used at the Transport layer: connection-oriented and connectionless. Which is most appropriate for sending a given message depends on whether reliability or speed is of highest priority.

Note:

In TCP/IP communications, data is sent over the network as a sequence of datagrams. A datagram is a collection of data sent as a single message. Each datagram is sent across the network individually.

A connection-oriented protocol such as TCP offers better error control, but its higher overhead means a loss of performance. A connectionless protocol such as UDP, on the other hand, suffers in the reliability department but, unhampered by error-checking duties, is faster.

Connection Oriented Services. As a provider of connection-oriented services, TCP first establishes a virtual connection between the sending and receiving computers. This is done through the use of acknowledgments and response messages.

Note:

An acknowledgment message is sometimes referred to as an “ACK.”

The most commonly used analogy for differentiating between connection-oriented and connectionless communications compares different services available from the post office. If you need to send an important report to the manager of your company’s branch office in El Paso, you could put it in an envelope, affix the required amount of postage, and drop it in the corner mailbox. This would be the easiest, quickest way to take care of the task, but you would have no idea whether or when the report reached its destination.

On the other hand, you could go to the post office and fill out a card to send the report via registered, certified mail, with a return receipt requested. It would cost more and it would take more time and effort on your part, but it would be a more reliable form of communication. You would get back an acknowledgment when the package was delivered, showing that it was indeed received by the person to whom it was addressed.

Connection-oriented services are more like the second example, although they actually go one step further: They establish the connection before sending the data. This would be as if, before you sent your certified mail, you first got on the telephone with the El Paso manager and let him know the report was coming so he could be on the lookout for its arrival. If you’re really detail-minded (or paranoid), you could even ask that he call you back when it gets there, and let you know that all the pages are there in sequence and it wasn’t damaged along the way. You’ve taken pains to make sure your communication is as reliable as possible, but at a cost in time (and long distance charges) to both you and the intended recipient.

Connectionless Services. A connectionless transport protocol like the User Datagram Protocol (UDP) doesn’t provide the same acknowledgment of receipt process as the connection-oriented TCP does.  Since UDP doesn't sequence the packets that the data arrives in, an application program that uses UDP has to be able to make sure that the entire message has arrived and is in the right order. To save processing time, network applications that have very small data units to exchange, and thus very little message reassembling to do, may use UDP instead of TCP. For example, DNS hostname lookup messages that will always fit in a single datagram can effectively use UDP. For these very short queries, you don't need all the complexity of TCP; if you don't receive an answer after a few seconds, you can just ask again.

Note:

Examples of applications that use UDP for communication include Trivial File Transfer Protocol (TFTP), Routing Information Protocol (RIP), RADIUS accounting, and some implementations of Kerberos authentication.

UDP doesn't split data into multiple datagrams, as TCP does. It doesn't keep track of what it has sent,  data can be resent if needed, and it doesn’t guarantee delivery or protect against duplication. However, it is not completely irresponsible: It does provide for a checksum capability, to ensure that data arrives intact, and it provides port numbers to distinguish between the requests sent by different user applications.

The UDP header is shorter and simpler than the TCP header. It has the source and destination port numbers and a checksum, but it doesn’t include a sequence number, since UDP doesn’t do any sequencing.

Layer 3: The Network Layer

Both TCP and UDP, operating at the Transport layer, rely on IP, the Network layer protocol, to actually get the data from the sending to the receiving computer.  If you’ve studied the OSI model, you’ve probably heard hundreds of times that routing takes place at the Network layer.  Routing is all about recognizing addresses and mapping out the most efficient way to get from one address to another.

The Routing Function

You would be performing a function similar to that of the Network layer if you took on the job of navigator on a cross-country automobile trip. Just as TCP and IP, working together, have different responsibilities, you and the driver could divide the duties so that the journey goes more smoothly. It’s the driver’s job to get the car to the destination safely and all in one piece (somewhat like the Transport layer protocols). It’s the job of the navigator to consult a map, determine exactly which highways will take you there, where to turn off one road and onto another, and to take into consideration such factors as the size of each thoroughfare, known areas of congestion, and anything else that might make one route more desirable than another.

Likewise, this layer is responsible for finding a path through the network to the destination computer. It is also responsible for translating logical addresses (the IP addresses assigned by an administrator or a DHCP server) and names (like the destination computer’s NetBIOS name “EXCALIBUR”) into physical addresses. The physical, or Media Access Control (MAC),  address is burned into a chip on the network interface card by its manufacturer.

IP routes messages based on the network number of the destination address. Every computer has a table of network numbers, known as a routing table. If there is a an entry in the routing table for the destination network ID, the computer sends it to a “gateway” address, which represents the first router in the path to the destination. A default gateway address is included in the routing table to send packets to when a specific route to the destination network ID isn’t found in the routing table.  The default gateway must be on the same network as the source computer.  Each gateway, or router, that the message must go through is called a hop. You might say a journey of a thousand hops begins with a single step: the gateway address listed in the routing table for a particular network number.

Dynamic Routing

It’s easy to map out a route to a friend’s house four blocks away. However, if you’re trying to get to the home of a relative who lives in the backwoods in another state, you may need more than a good map. You may need to call ahead and get directions from someone who has traveled there recently.  As networks become larger and more complex, it becomes more difficult to manually maintain routing tables. When this happens, you will want to use a dynamic routing protocol. Dynamic routing protocols automatically update routes on all routers on the network.

We will discuss various routing protocols such as RIP and OSPF in a later chapter. Routers (whether dedicated devices or Windows NT or 2000 servers acting with IP routing enabled) work at the Network layer.

The X.25 Standard

Although IP is the best known protocol of the Network layer, another important inhabitant of this layer is the ITU X.25 standard, which specifies the interface for connecting computers on different networks through the use of an intermediate connection made through a packet-switched network. X.25 protocols also correspond to the Data Link and Physical layers of the OSI model.

Layer 2: The Data Link Layer

The Data Link layer takes the datagram passed down to it from the Network layer and repackages it into a unit called a frame. The frame includes error-checking information, which is processed by the Data Link layer at the receiving end. This layer is responsible for error-free delivery of the data frames. Figure 1.3 shows how a frame might be structured.

Figure 1.3 The Data Link layer adds a Cyclic Redundancy Check (CRC) for error-checking.

The Data Link layer is responsible for maintaining the reliability of the physical link, which is established at Layer One just below it.

This is the only layer of the OSI model that  is divided into sublayers: the LLC (Logical Link Control) and the MAC sublayers. We will look at each of these individually.

The Logical Link Control Sublayer

The LLC sublayer is charged with ensuring the reliability of the link, or connection.  IEEE 802.2 is an LLC standard that operates with the CSMA/CD (Carrier Sense Multiple Access/Collision Detection) and the Token -Ring media access standards. Point-to-Point Protocol (PPP) also operates at the LLC level.

The Media Access Control Sublayer

The MAC sublayer deals with the logical topology of the network. This may or may not be the same as the physical topology, or layout. For instance, IBM Token Ring networks are physical stars, as all computers connect to a central hub (called an MSAU, or MultiStation Access Unit). However, the logical topology is a ring, because inside the MSAU, the wiring is such that the data travels in a circle. A 10BaseT network connecting to an Ethernet hub, on the other hand, is logically a bus (which is why it is sometimes called a star bus).

Access Control Methods. MAC-level protocols govern the access control method, or how the data accesses the transmission media. The popular methods are grouped in three categories: contention methods, token passing, and polling methods.

Contention methods include CSMA/CD, used in Ethernet networks; and Carrier Sense Multiple Access Collision Avoidance (CSMA/CA), used in AppleTalk networks. In both cases, computers that wish to transmit data on the network must compete for the use of the wire or other media. A collision occurs if two stations attempt to send at the same time. CSMA/CD and CSMA/CA differ in their ways of addressing this collision problem. With CSMA/CD,  data collisions are detected and the data is sent again after a random amount of time. With CSMA/CA, an “intent to transmit” message is put out as a “feeler” before the computer transmits the actual data.

Token passing methods eliminate the possibility of collision by using a circulating signal called a token to determine which computer can transmit. A computer on a token passing network is more polite. Rather  than blurting out its transmission whenever it has something to say, it waits patiently for its turn (when the token gets around to it) and sends data only when it “has the floor.”

Polling methods are similar in some ways to token passing, except that instead of the group of computers policing themselves by passing around a token, there is a central unit that acts as a “chairperson.” This “presiding” unit asks members of the “committee” in turn whether they have something to say. Since the computers follow these “rules of parliamentary procedure,” data transmission proceeds in an orderly fashion.

MAC Addressing. Although the permanent address burned into the NIC is sometimes called the “physical address,” its proper name is Media Access Control address. The MAC sublayer of the Data Link layer also handles MAC addressing functions.

Note:

MAC addresses on Ethernet cards are expressed as  12-digit hexadecimal numbers, which represent 4- bit (6-byte) binary numbers. The first three bytes contain a manufacturer code, which is assigned by  the Institute of Electrical and Electronics Engineers (IEEE). The last three bytes are assigned by the manufacturer and represent that particular card.

Each computer must have a MAC address that is unique on the network. Higher-level protocols translate IP addresses (also called logical addresses) to the MAC address, which can be thought of as the real network location. Lower-level protocols cannot recognize or use IP addresses.

Think of it this way: A city or county may assign a street name and house number to a structure, but this is really only a “logical” address. Logical addresses can be more easily changed. A  neighborhood group will petition to have a street renamed, or the city council will change the numbering scheme to facilitate emergency response or to accommodate new construction. The location where the building stands also has a “physical” address: it’s geographic coordinates. When the land is surveyed, it will be identified by degrees of longitude and latitude, and these will remain constant regardless of changes to the street name and number. That physical address is like the NIC’s MAC address; it will (almost always) remain the same.

Note:

Some network card manufacturers have made NICs that allow you to change the MAC address by “flashing” the card with a special software program. This is a precaution in case you have duplicate MAC addresses on a network because those manufacturers have begun to “recycle” their addresses.

Data Link Layer Devices

There is some confusion among network administrators about the network connectivity devices called bridges that operate at the Data Link layer of the OSI model. Bridges can separate a network into segments, but they don’t subnet the network as routers do. In other words, if you use a bridge to physically separate two areas of the network, it will still appear to be all one network to higher-level protocols.

Bridges can cut down on network congestion because they can do some basic filtering of data traffic based on the MAC address of the destination computer. When a transmission reaches the bridge, it will not pass it across to the other side of the network if the MAC address of the destination computer is known to be on the same side of the network as the sending computer. The bridge builds tables indicating which addresses are on which side, and uses them to determine whether to let the transmission across.

The confusion comes in because there are different types of bridges. Although all work at the Data Link layer, some operate at the lower MAC sublayer and others at the higher LLC sublayer. There are some important differences. One practical question is whether you can use a bridge to connect network segments that use different media access methods (for instance, an Ethernet segment and a Token Ring segment). The answer is yes or no, depending on which type of bridge you’re referring to.

A bridge that operates at the Logical Link Control sublayer, sometimes called a translation bridge, can connect segments using different access methods. However, a lower-level bridge (one that operates at the MAC sublayer) cannot. Either type can connect segments using different physical media (that is, a segment cabled with thin coax and a segment running on unshielded twisted pair).

Another device that operates at the Data Link layer is the common switch, or switching hub, which has become very popular on Ethernet networks.

Note:

The switched hub is also called a Layer 2 switch. There are more sophisticated switches made by companies such as Cisco Systems that operate at the Network layer and can perform basic routing functions in addition to the type of switching described here.

Like hubs, these switches are central multiport units into which all the computers are connected. Like bridges, the switch keeps a table of MAC addresses, showing which computer is connected to which port. When data comes in, instead of sending it back out to all the computers as the hub does, the switch examines the destination address in the header, consults the table, and sends it only out the port to which the corresponding computer is attached. This cuts down overall network traffic considerably, and helps to prevent collisions.

Layer 1: The Physical Layer

To many, the Physical layer is the easiest to understand because it deals with devices and concepts that are more tangible. The Physical layer deals with such things as the type of signal transmission used, the cable type, and the actual layout or path of the network wiring. These are things we can see, touch, or at least easily represent with a drawing or diagram. The functions of the Physical layer devices (NICs, cables, connectors, hubs, and repeaters) are also relatively easy to understand.

Physical Layer Devices

Physical layer devices are the stuff of which a networking equipment catalog is made. The basics are deceptively simple: You insert a network card into an expansion slot on each computer, plug a piece of cable into each network card, and plug the other end of each cable into a hub. But leafing through the catalog will reveal that Physical layer issues are a little more complex. Some cable manufacturers offer literally thousands of different cables, and the variety of available network cards and connectivity devices is just as overwhelming. Getting a network up and running at the Physical level requires a good bit of knowledge about what works with what, and which hardware type is best for your particular situation.

The network interface card (NIC) is the hardware device most essential to establishing communication between computers. Although there are ways to connect computers without a NIC (by modem over the phone lines, or via a serial “null modem” cable, for instance), in most cases where there is a network, there is a NIC (or more accurately, at least one NIC for each participating computer).

Note:

The NIC is responsible for preparing the data to be sent out over the network media. Exactly how that preparation is done depends on what media is being used.  – A Token Ring NIC is different from an Ethernet NIC, for example. It logically would have to be, since they use different access methods. And even though 10Base2, 10Base5 and 10BaseT Ethernet networks all use CSMA/CD as their access method, they use different cable and connector types; however, it is possible to get a “combo” card that has connectors for all three.

Bottom line: The NIC must match the bus type for which you have an open slot in the computer, it must be of the correct media access type, it must have the correct connector for the cable your network uses, and it must be rated to transfer data at the proper speed (Ethernet normally transmits at either 10 or 100 Mbps, and Token Ring runs at 4 or 16 Mbps).

The Network Media is the cable or wireless technology on which the signal is sent. Cable types include thin and thick coaxial cable (similar to cable TV cable), twisted pair (such as used for modern telephone lines, available in both shielded and unshielded types), or fiber optic (which sends pulses of light through thin strands of glass or plastic for fast, reliable communication, but is expensive and difficult to work with). Wireless media include radio waves, laser, infrared, and microwave.

Hubs and Repeaters are connection devices. Repeaters connect two network segments (usually thin or thick coax) and boost the signal so the distance of the cabling can be extended past the normal limits at which attenuation, or weakening, interferes with the reliable transmission of the data. Hubs are used generally with Ethernet twisted pair cable, and most modern hubs are repeaters with multiple ports. Hubs also strengthen the signal before passing it back out to the computers attached to it. Hubs can be categorized as follows:

           Active hubs are the type just described. They serve as both a connection point and a signal booster. Data that comes in is passed back out on all ports.

           Passive hubs serve as connection points only; they do not boost the signal. Passive hubs do not require electricity and thus won’t have a power cord as active hubs do.

           Intelligent or “smart” hubs include a microprocessor chip with diagnostic capabilities, so that you can monitor the transmission on individual ports.

Recall that there is another type of hub, a switching hub, but it operates at the Data Link rather than the Physical layer.

Signal Transmission

Computers, at the machine level, are amazingly simple; they “think” only in binary, performing rapid calculations on combinations of 0s and 1s. Transferring these binary digits across network media requires a way of representing these 0s and 1s. Luckily, there are many ways to do this. An electrical signal or a pulse of light can indicate 1 when it’s on and 0 when it’s off. This is known as discrete state technology, and digital signaling works this way.

Note:

Analog signaling—the type used by common telephone lines—transmits by adding signals of varying frequency or amplitude to carrier waves of a particular frequency of alternating electromagnetic current. Unlike the absolute on/off state, it is represented by a waveform. When data is sent over regular phone lines, a modem must convert the computer’s digital signal to analog and back again at the receiving end.

Another consideration at the Physical layer is whether the signaling method will use the entire bandwidth of the cable to transmit the data, or will only use one frequency. When all frequencies are used, the transmission method is called baseband. If only part of the bandwidth is used (thus allowing other signals to share the bandwidth), it is referred to as broadband.

Traditionally, baseband transmission has been associated with digital signaling, and broadband with analog, but this does not always hold true. For instance, Digital Subscriber Line (DSL) is a high-speed technology being offered by many telephone companies for Internet connectivity. DSL is a broadband technology, because it uses only a part of the wire to transmit data. Voice  communication can take place simultaneously on the same cable, using a different frequency than is being used by the data communications. Cable television is another example of broadband transmission, bringing dozens of different channels into your home on just one coax cable.

Physical Topologies

Another important Physical layer issue is the layout, or topology, of the network. This refers to whether the cables are arranged in a line going directly from computer to computer (bus), in a circle going from computer to computer with the last connecting back to the first (ring), or in a spoke-like fashion with each connecting directly to a central hub (star). A fourth topology, the mesh, is used when every computer is connected to every other computer, creating redundant data pathways and high fault tolerance, at the cost of increasing complexity as the network grows.

Wireless communications can use a cellular topology such as is widely used for wireless telephone networks. In this case, an area is divided into slightly overlapping cells, representing connection points.

The physical layout of the network will influence other factors such as what media access method (and thus what cable type) is used. All the Physical layer factors (cable type, access method, topology, etc.), when considered together, define the architecture of the network. Popular network architectures include Ethernet, ARCnet, Token Ring, and AppleTalk.

The IEEE802 Standards

The Institute of Electrical and Electronics Engineers, like the ISO, develops standards. The IEEE 802 specifications address various Physical and Data Link layer issues. Those most pertinent for the average network administrator are:

           802.2 Establishes standards for the implementation of the LLC sublayer of the Data Link layer.

           802.3 Sets specifications for an Ethernet network using CSMA/CD, a linear or star bus topology, and baseband transmission.

           802.5 Sets standards for a token passing network using a physical star/logical ring topology; i.e., Token Ring.

           802.7 Establishes criteria for networks using broadband transmission.

           802.8 Sets specifications for using fiber optic as a network medium.

           802.11 Establishes standards for wireless networking.

The 802 Project was named after the year and month that the original committee met: February 1980.

The DoD Model

The Department of Defense networking model is older than the OSI, and was developed in conjunction with TCP/IP itself. It is sometimes called the TCP/IP model, but more often referred to as the DoD model. It consists of only four layers, but they can be roughly mapped to the seven layers of the OSI model. The DoD model is illustrated in Figure 1.4.

Figure 1.4 The four layers of the DoD model map roughly to the seven OSI layers.

The various protocols in the TCP/IP suite fit nicely into the layers of the DoD model. Remember that the DoD model was designed in the 1970s. The OSI model came along a decade later, with the goal of more specifically defining the layers of functionality for the network components.

The Application/Process Layer

The top layer of the DoD model encompasses all three OSI upper layers: Application, Presentation, and Session. Thus, when referring to TCP/IP, you may read that encryption of data or checkpointing and dialog control take place at the Application layer. Remember that this does not mean the OSI Application layer and you’ll avoid confusion.

The Host-to-Host (Transport) Layer

The Host-to-Host layer is sometimes labeled the Transport layer even on four-layer DoD diagrams, and it maps to the Transport layer on the OSI model. TCP, UDP, and DNS operate here.

The Internetworking Layer

This layer corresponds closely to the OSI Network layer. IP, ICMP, and ARP function at this layer. As we discussed earlier, IP deals with routing based on logical IP addresses. ARP (Address Resolution Protocol) translates logical addresses to MAC addresses. This translation is necessary because the lower layers can process only the MAC addresses.

The Network Interface Layer

The Network Interface layer maps to OSI’s Data Link and Physical layers. The TCP/IP suite itself has no protocols that operate at these lower layers, but uses the standard Ethernet and Token Ring Data Link and Physical layer protocols.

The Microsoft Windows 2000 Networking Model

While it’s easy to show the relationships between the OSI and DoD layers, the Microsoft implementation of the TCP/IP networking model is a bit different. It includes a new type of layer, a boundary layer, which interfaces between the actual networking component layers. The boundary layers are open specifications, while the component layers in between are operating-system specific. Figure 1.5 shows the Windows 2000 Networking Model.

Figure 1.5 The Microsoft Windows Networking Model uses boundary layers.

As you can see, a boundary layer acts as an interface between each pair of component layers. It’s no coincidence that the name of each boundary layer ends with the word “interface.” The three boundary layers are:

           Application Programming Interface

           Transport Driver Interface

           Network Device Interface Specification

Let’s discuss each of the component and boundary layers in a little more detail.

The Application and User Mode Services Component

This layer contains the supported types of user applications and services, including NetBIOS (Network Basic Input Output System), Remote Procedure Calls, Win32 and its subsystems, and Windows Sockets applications.

NetBIOS

NetBIOS specifies a group of network function calls that lets applications on different computers communicate with each other within a local area network. It was originally developed by IBM, then adopted by Microsoft, and has been the basis for Microsoft networking.

Note:

Windows 2000 is the first Microsoft operating system that allows for disabling of NetBIOS, although this is feasible only on a network that has fully migrated to Windows 2000 and uses no NetBIOS network-enabled applications. A hybrid network containing computers running older Microsoft operating systems or NetBIOS applications will still need to use NetBIOS.

NetBIOS communications use a destination name (called, appropriately enough, a NetBIOS name) and a message location to get the data to the correct destination. NetBIOS supports a session mode for establishing a connection and transfer of large messages, and a datagram mode for connectionless transmissions such as broadcast messages.

Winsock

A Winsock program handles input/output requests for Internet applications in a Windows operating system, using the sockets convention for connecting with and exchanging data between two Application-layer processes.

Note:

A socket, in TCP/IP communications, is the combination of an IP address and a port number, along with a protocol.

Winsock runs as a .dll file (dynamic link library). A .dll file is a collection of small programs, any of which can be loaded when an application needs to use it but it isn’t required to be included as part of the application.

The API Boundary Layer

The API boundary layer is where the Application Programming Interface (API) operates. An API is the specific method that is set by a computer operating system or an application, allowing a developer, when writing a program, to make requests of the operating system or application.

RPC

Remote Procedure Call is what it sounds like: RPC provides a service to application developers to allow for transparent use of a server to provide some action on behalf of the application. Remote procedure calls provide the programmer with a way of hiding an underlying message passing protocol.

Note:

The RPC protocol is documented in RFC 1831, which can be accessed on the Web at www.freesoft.org/CIE/RFC/1831.

The RPC protocol was designed to work with IP, but in a way that’s different from TCP. The TCP protocol is used to transfer large data streams (for example, file downloads). RPC was designed for writing network programs, to allow a program to make a subroutine call on a remote machine.

Win32 API

The Win32 API is a set of predefined Windows functions that are used to control the appearance and behavior of Windows elements. The API functions are stored as .dll files in the Windows system directory (in Windows 2000, the default system directory is /winnt).

The File System Drivers

In the Windows NT architecture, on which Windows 2000 is based, network redirectors are implemented as file system drivers. A redirector is a software component that does what its name implies: redirects a request (in this case, from the local machine out over the network). The Server service and the Workstation service are examples of redirectors. Named pipes and mailslots are also network redirectors. Named pipes is used for connection-oriented communication, and mailslots for connectionless data transfer.

The network redirectors allow all file systems to appear the same when accessed across the network, hiding their differences from the user. This is why a Windows 95 machine can read and manipulate files through a network share that are stored on an NTFS partition, even though the Windows 95 operating system does not include an NTFS file system driver and thus cannot itself read an NTFS file.

The TDI Boundary Layer

The Transport Driver Interface is another boundary layer. The primary purpose of TDI is to define a standard application programming interface for the transport protocol stacks. That is, the low-level kernel-mode driver implementation of protocols such as TCP/IP and NetBEUI TDI provides for standard methods of protocol addressing, sending and receiving datagrams, and other related actions.

TDI is an open specification, and programmers can develop TDI drivers written to the specification, which will make it possible for them to work within the Windows networking architecture.

The Network Transport Protocol Component

The Network Transport Protocol layer is easy to understand and to map to the other networking models. This is similar to a combination of the Network and Transport layers in the OSI model (or the Internetwork and Host-to-Host layers in the DoD model). TCP, UDP, IP, ICMP, IGMP, and ARP operate here.

The NDIS Boundary Layer

NDIS (Network Driver Interface Specification) is intended to define a standard API for NICs. All NICs made to be used with the same media access type (such as Ethernet or Token Ring) can be accessed using a common programming interface. The MAC device driver that hides the specifics of the hardware implementation is what makes this possible.

 The NDIS Wrapper

NDIS includes a library of functions (a wrapper) that can be used by MAC drivers and higher-level protocol drivers (such as TCP/IP). The wrapper functions make it easier to develop MAC and protocol drivers and to hide dependencies on a computer platform. The NDIS wrapper allows the higher-level protocols to work with such Data Link and Physical layer protocols as Ethernet, Token Ring, Frame Relay, FDDI, ATM, and X.25.

There is also an NDIS WAN miniport wrapper that interfaces with wide area networking protocols like PPTP and ISDN.

A Family of Protocols: The TCP/IP Suite

Although TCP and IP make up the protocol “stack” that gets the messages there, and ensures that they get there reliably, an entire suite of protocols has come to be associated with the name and are included in most vendors’ implementations.

Some of these are used to provide additional services, while others are useful primarily as information-gathering or troubleshooting tools. As we address various types of TCP/IP connectivity problems throughout this book, we will be using many of these. The following is just an overview of some additional protocols included with Windows 2000 TCP/IP.

Application Layer Protocols

The TCP/IP suite provides several protocols that operate at the Application layer to provide services such as news, mail and file transfer, and monitoring/diagnostics capability.

FTP

The File Transfer Protocol is used for copying files from one computer to another. Windows 2000 includes both a command-line FTP client program (see Figure 1.6) and the FTP server service that is installed as part of Internet Information Server 5.0.

Figure 1.6 Using the Windows 2000 command-line FTP client program to transfer files.

FTP will be available at the command line only if the TCP/IP transport protocol is installed.

SNMP

The Simple Network Management Protocol provides a way to gather statistical information. An SNMP management system makes requests of an SNMP agent, and the information is stored in a Management Information Base (MIB). The MIB is a database that holds information about a networked computer (for example, how much hard disk space is available).

Warning: You must be logged on as a member of the Administrators group in order to install the SNMP service.

The SNMP agent software is installed as a Windows Component and runs as a service. SNMP management software is not currently included with Windows 2000.

Telnet

Telnet is a TCP/IP-based service that allows users to log on to, run character-mode applications, and view files on a remote computer. Windows 2000 Server includes both Telnet server and Telnet client software. See Figure 1.7 for an example of a Windows 2000 Telnet session.

Figure 1.7 Using Windows 2000’s Telnet client to connect to the iris.irs.ustreas.gov Telnet server.

Telnet differs from FTP in that you cannot transfer files from one computer to another (upload or download). Telnet is often used to access a UNIX shell account on an ISP’s server and delete e-mail messages directly from the server without downloading them to the local machine. The Telnet protocol itself is used to establish the initial connection to FTP and SMTP servers from the host’s user agent.

SMTP

The Simple Mail Transfer Protocol is used for sending e-mail on the Internet. SMTP is a simple ASCII protocol and is nonvendor specific.

Note:

For more information about SMTP, see RFC 821 at www.cis.ohio-state.edu/htbin/rfc/rfc821.html.

Because SMTP has limited capability in queuing messages at the receiving end, most e-mail client programs use SMTP for sending e-mail, and either POP3 or IMAP for receiving the messages that come in and are stored on a server.

HTTP

The HyperText Transfer Protocol is perhaps the most familiar of the Application layer protocols because it is used on the World Wide Web, the most popular Internet service. HTTP allows computers to exchange files in various format (text, graphic images, sound, video, and other multimedia files) via client software called a Web browser.

A computer running a Web server program, such as Microsoft’s Internet Information Server, stores files in HyperText Markup Language (HTML) format that can be accessed by the client browser. These HTML “pages” often contain hyperlinks for quickly and automatically connecting to other files on the Internet, on an intranet, or on the local machine.

The current version is HTTP 1.1, which was developed by a committee of the IETF. It contains enhancements that allow for faster transfer of information.

Note:

The specifications for HTTP 1.1 are defined in proposed RFC 2068, which can be accessed on the Web at www.ics.uci.edu/pub/ietf/http/rfc2068.txt.

NNTP

Network News Transfer Protocol is used for managing messages posted to private and public newsgroups. NNTP servers provide for storage of newsgroup posts, which can be downloaded by client software called a newsreader.

Windows 2000 Server includes an NNTP server with IIS. Outlook Explorer version 5, which is part of the Internet Explorer software included with Windows 2000, provides both an e-mail client and a newsreader.

Transport Layer Protocols

The TCP/IP suite includes two Transport layer protocols, the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP).

TCP

As already discussed, TCP is the connection-oriented protocol that should be used when error control is of high priority. TCP provides highly reliable, full-duplex transport services, and supports sequence numbering so that large messages can be broken down and then reassembled at the receiving end.

UDP

UDP performs the same basic function as TCP—transport of datagrams—but does so in a “bare bones” manner. It does not acknowledge receipt of the messages, nor does it sequence the datagrams. UDP should be used when speed is of high priority and assured delivery of the messages is less critical.

Network Layer Protocols

The suite includes several protocols that operate at the Network layer of the OSI model, including one of the two “lead singers” of the suite: IP.

IP

The Internet Protocol handles addressing and routing at the Network level, relying on logical (IP) addresses. It can use packet-switching methods to route different packets, which are all part of the same message, via different pathways. It can use dynamic routing protocols to determine the most efficient routes on a per-packet basis.

IP is a connectionless protocol; it depends on TCP at the Transport layer above it to provide a connection if necessary. However, it is able to use number sequencing to break down and reassemble messages, and uses a checksum to perform error-checking on the IP header.

ARP and RARP

The Address Resolution Protocol (ARP) translates the logical IP addresses to physical MAC addresses. ARP discovers this information by way of broadcasts, and keeps a table of IP-to-MAC entries. This table is referred to as the ARP cache.

Reverse Address Resolution Protocol (RARP) is a similar protocol that does just the opposite: Instead of starting with an IP address and finding the matching MAC address, it uses the MAC address to find the IP address, somewhat like a “criss-cross” telephone directory.

ICMP

The Internet Control Message Protocol is known as a “maintenance” protocol and is required in TCP/IP implementations. It lets two computers on an IP network share IP status and error information. ICMP is used by the Ping utility discussed in Chapter 4, “Using Windows 2000 Network Monitoring and Troubleshooting Tools.”

Note:

The standards for ICMP are defined in RFC 792.

Computers and routers using IP can report errors, and exchange control and status information via ICMP.

IGMP

The Internet Group Management Protocol (IGMP) allows host computers on the Internet to participate in IP multicasting. A multicast address identifies a transmission session, instead of a particular physical destination. This allows for sending a message to a large number of recipients without the necessity for the source computer to know the addresses of all the recipients. The network routers translate the multicast address into host addresses.

Note:

IGMP was originally defined in RFC 1112. Extensions have been developed and are included in IGMP version 2, addressed in RFC 2236.

A computer uses IGMP to report its multicast group memberships to multicast routers. IGMPv2 allows group membership terminations to be reported promptly to the routing protocol. IGMP is required to be used in host computers that wish to participate in multicasting.

TCP/IP Utilities

In Chapter 4, we will be looking in detail at the following utilities, which are also included in the TCP/IP suite:

           IPCONFIG

           NETSTAT

           NBTSTAT

           NSLOOKUP

           ROUTE

           TRACERT

           PING and PATHPING

Basic Network Design

This book focuses on troubleshooting issues, and is not meant to be a comprehensive guide to designing a network. However, the best way to deal with trouble is to avoid it in the first place; thus, we will briefly discuss how thoughtful design can make your Windows 2000 TCP/IP network less prone to problems.

Planning as Preventative Medicine

Whether you are setting up a brand new network or migrating to Windows 2000 from an earlier Windows NOS or a non-Microsoft NOS, putting some extra time into planning and preparation is likely to pay off in a reduction in time (and frustration) expended on troubleshooting later. Some common problems are specific to particular migration scenarios, and are discussed in Chapter 2, “Setting Up a Windows 2000 TCP/IP Network.”

Some general network design issues, however, apply regardless of your situation and individual network characteristics. Let’s take a look at a few of those now.

Testing and Implementation

Before you make significant changes to your production network, it is extremely important that you test those changes in a controlled environment. This is true whether you are merely trying out a new TCP/IP-based application or rolling out a whole new Windows 2000 network. Prototyping is also the first step in troubleshooting networking problems. This refers to creating a test environment in which you recreate the problem and can try various solutions without fear that the “cure will be worse than the disease” and cause loss of data or network downtime on your “real” network.

Prototyping

Setting up a prototype environment, or test lab, can be your best troubleshooting tool. In this situation, you can test different installation procedures and options before deploying Windows 2000 to your production machines. This will help you to accurately predict any problems that may occur and find solutions to them.

The key to the prototype environment is that it should be:

           Completely independent of your company LAN

           As identical as possible to the company LAN environment

To create a realistic test environment, you should have a server running the same operating system and other software as your production server(s), and one or more client computers using the same operating system as your network desktop systems, again with all the same software installed. The hardware for the prototype and production machines should also be as close to the same as possible.

Prototyping allows you to uncover problems that might occur in an actual installation scenario, and address them beforehand. This prevents the loss of productivity and inconvenience to employees that would be a result of encountering “surprise” problems during the actual installation.

The test lab is useful long after you’ve completed the deployment of Windows 2000. It can be used for troubleshooting problems that occur later, in a controlled and “safe” environment that won’t affect the network’s productivity. It can also be used to plan future upgrades, and as a training ground where administrators can familiarize themselves with the new software.

Pilot Programs

After you have tested the new operating system in a prototype environment that is isolated from all of your production machines, you may still wish to implement the change on a limited basis first. This will allow you to evaluate the transition in a realistic setting, with actual network users, and uncover problems that may not have manifested themselves in the more controlled test lab.

In that case, a pilot program will add another layer of protection before you expose the entire network to potential upgrade problems.

It may be best to choose a specific department, or you may find it more beneficial to upgrade the machines of selected users throughout the organization. It is probably best not to do so on a random basis. You will want to consider several factors when deciding which machines to upgrade:

           One strategy is to choose a department or group that is not involved in mission-critical work, or one that is in a “slow period.” You would not want to select the Tax department for your pilot group if an important filing deadline is just around the corner, or if the company is currently being audited by the IRS.

           An alternate method is to compile a pilot group made up of users from different departments who are considered “power users”; that is, those who are more computer-savvy and thus unlikely to panic if problems arise. A group of users with some technical knowledge may also be better able to document problems they encounter and more accurately report them to you.

Rollout

Sooner or later, regardless of how little or how much testing you do, you must implement the new operating system throughout the organization. In a large company, you will probably want to do so in phases, and there may even be some users who by choice or due to budget considerations or other factors won’t be in the rollout list at all.

However you do it, you can anticipate that there will be some problems involved in upgrading any network that has more than a few computers. Things will go more smoothly if you follow a few basic guidelines:

Users should be trained prior to the implementation of the new operating system. This can be done through formal sessions in a classroom onsite or by sending them outside the company to classes in using the new operating system. Don’t deploy a brand new operating system that your users have never had an opportunity to use.

Plan the rollout to create as little disruption as possible. The actual upgrade could take place on the weekend or during a time when the offices are closed, or when fewer employees are working if the office occupied around the clock every day. If you can avoid interfering with users’ attempts to get work done, your job will go more smoothly.

Always inform users of the upgrade schedule. People don’t, as a rule, like surprises. Even those who are looking forward to the upgrade may not be happy to come in to work one Monday morning and find that their operating system has been replaced, without any prior notice or the chance for them to prepare psychologically for the change.

Proper planning is always worth the time it takes to do it. By mapping out your installation or upgrade strategy beforehand, and anticipating problems before they happen, you may find that they needn’t occur at all.

Summary

In the computer industry, time moves at a pace that’s different from the rest of the world. By those standards, the TCP/IP protocol suite has a (relatively) long and venerable history. We can expect it to stay with us for years to come. TCP/IP is the protocol stack of the global Internet. Until that changes, its “job security” is assured.

But IP must undergo changes to keep up with the extraordinary growth in the number of computers and networks that has been a hallmark of the 1990s, and is expected to continue well into the next millennium. One problem that must be addressed is the very practical one of providing for enough available IP addresses to ensure that we won’t run out anytime in the near future. IPv6, the “next generation” of the Internet Protocol, was designed with this goal in mind. It is already being implemented in some quarters, and is likely to enjoy a gradual but steady “takeover” until it finally replaces the current implementation, IPv4.

TCP/IP as we know it today consists of an entire suite of protocols. To understand how various protocols in the suite work together, we can use one of the popular networking models as a reference point. Models give us a way to graphically represent and better understand the process of communication between computers that share their resources with one another.

The Open Systems Interconnection (OSI) model is the current recognized standard. It was developed by the International Organization for Standardization and provides a set of common specifications to which networking components can be designed. Compliance with the standard ensures that products made by different manufacturers will still be able to interoperate.

The Department of Defense (DoD) model is the one on which TCP/IP was originally based. It is an older model, and functions are not as finely divided as in the OSI model, but its layers can easily be mapped to those of the OSI model. Microsoft uses a different model, the Windows networking model, which includes a concept that isn’t encountered in the others: boundary layers. Boundary layers are interfaces that are open specifications, and act as “glue” between the component layers of the network operating system software.

Understanding the networking models make it easier for administrators to troubleshoot problems with TCP/IP connectivity by helping to narrow down possible sources of the malfunction. The Windows 2000 TCP/IP suite also includes a virtual “toolkit” of  utilities, which an administrator can use to gather information and test connections.

The first step in troubleshooting is practicing “preventative medicine”; that is, ensuring that the setup of a new network or the migrating to a new operating system is done in a well-organized fashion. Testing and prototyping, pilot programs, and a thoughtfully planned rollout strategy will go a long way toward reducing the incidence of troubleshooting that will be required later on.

FAQs

Q: Why do some books specify that certain software components, such as redirectors, operate at the Application layer, while others say that redirectors work at the Presentation layer?

A: There are a few reasons for the discrepancy. First, there are many different types of network redirectors, some of which are part of the operating system, and others (such as the Novell Client 32 software for connecting a Windows machine to a NetWare network) made by third parties. Additionally, some books reference the OSI networking model, which consists of seven layers, while others are basing their statements on the DoD model, which only has four. A component that operates at the Presentation layer of the OSI model would be operating at the Application (or Application/Process) layer of the DoD model.

Q: It’s called TCP/IP. What are all those other protocols, and what are they for?

A: TCP and IP are the “core” protocols (sometimes called the “protocol stack”), but an entire suite of useful protocols has grown up around them. Some of these provide for basic functionality in performing such common network tasks as transferring files between two computers (FTP) or running applications on a remote computer (Telnet). Others are used for information gathering (SNMP, NETSTAT, IPCONFIG), and many are troubleshooting tools that also allow you to perform basic configuration tasks (ARP, ROUTE).

Q: What is the difference between TCP and UDP if they both operate at the Transport layer?

A: Although both TCP and UDP are Transport layer protocols and provide the same basic function, TCP is a connection-oriented protocol, which means a session is established before data is transmitted, and acknowledgments are sent back to the sending computer to verify that the data did arrive and was accurate and complete. UDP is connectionless; no session, or one-to-one connection, is established prior to data transmission. This makes UDP the faster of the two, and TCP the more reliable.

Q: What is the purpose of a networking model? How will knowing this theoretical stuff help me in administering my TCP/IP network?

A: The models give us a way to understand the process that takes place when computers communicate with each other across the network, the order in which tasks are processed, and which protocols are responsible for handling which duties. Understanding the models will help you to narrow down the source of your TCP/IP connectivity problems. For example, if you know that the data is being sent but is not arriving at the correct destination, you will know to start troubleshooting by examining what is happening at the Network layer, since that’s where addressing and routing takes place.

Q: Why do we need three different networking models? Why can’t everyone use the same one?

A: Actually, that was the plan when the ISO developed the Open Systems Interconnection model. It was to be the common standard used by all vendors and software developers in describing the network communication process. The DoD model actually predates the OSI, and the seven-layer OSI model builds on (and further breaks down) the components of the DoD model. However, individual vendors such as Microsoft still use their own models, which map more closely to their software (such as the Windows NT/2000 model), although they also use the OSI model as a guideline.

Q: What is a gateway, and why would I need one?

A: The word gateway has many different meanings in the IT world. A protocol translating gateway translates between different protocols. Think of it as the United Nations interpreter of the networking world. If the president of the United States needs to exchange information with the president of France, but neither speaks the other’s language, they can call in someone who is fluent in both to help them get their messages across. Similarly, if a mainframe system and a Windows 2000 computer need to communicate with one another—perhaps the mainframe has important files that need to be accessed by the PC—but they don’t know how to “talk” to each other, you can install a gateway to clear up the confusion. The gateway is even more skilled than the interpreter is; it actually fools the mainframe into believing it’s communicating with another mainframe, and makes the PC think it is having a “conversation” with a fellow PC. Gateway is also the term used to refer to the address of a router that connects your network to another, acting as the gateway to the “outside world.