Lesson 05 (printer-friendly version)

INSTRUCTIONS:

• To print this page, wait for the page to fully load. Once the document is ready to print, simply click your browser's File menu and choose Print.
• To save this page, click your browser's File menu and choose Save As. Select a disk drive and folder to receive the file, and change the name of the file to less05.htm. To view the file while you are offline, just go to the drive and folder you selected when you saved the file and double-click the file named less05.htm. Your browser will start and you will have access to the file.

---

Chapter 1

Introduction

The OSI model strikes fear into the hearts of many novice network techs, who may at first imagine nightmare scenarios in which they’re forced to spend hours on end selecting individual protocols for each layer. Fortunately, all of this pain, suffering, and gnashing of teeth are unnecessary, thanks to something called protocol suites.

The Protocol Suites

A protocol suite is a set of protocols which are designed to work together. While Lesson 4 discussed individual protocols operating at specific layers in the OSI model, network techs in the real world deal most directly with the protocol suites.

The three major protocol suites—NetBEUI, IPX/SPX, and TCP/IP—offer varying degrees of ease of use, efficiency, and flexibility. Programmers delve into the nitty-gritty of the individual protocols to create protocol suites, and techs install and troubleshoot the protocol suites given to them by the programmers.

The name of each protocol suite refers to one or more of the major protocols used in that suite. The TCP/IP suite, for example, includes Transmission Control Protocol, or TCP; Internet Protocol, or IP; File Transfer Protocol, or FTP; and Internet Control Message Protocol, or ICMP, among others.

Each of the major protocol suites provides a different mix of efficiency, flexibility, and scalability—the ability to support network growth. NetBEUI works best for small networks without routers; IPX/SPX provides support for integrating with Novell NetWare; and TCP/IP provides a complex, robust, and open solution for larger networks.

Chapter 2

NetBEUI

NetBEUI provides a fast, simple set of network protocols appropriate for use in smaller LANs. Although OS/2, LANtastic, and few other Network Operating Systems—also known as NOSs—support NetBEUI, this protocol exists primarily to support Microsoft networking using Windows NT or Windows 9x. You’ll learn more about the various NOSs in Lesson 7.

NetBEUI’s speed and ease of use make it a good choice for small networks that do not require advanced features such as routing. The NetBEUI protocol suite consists of two main protocols, NetBIOS and NetBEUI, which operate at the Session layer and the Transport layer, respectively.

Fig. 05-01. NetBIOS operates at the Session layer, and
NetBEUI operates at the Transport layer.

Note that the term NetBEUI can refer either to the NetBEUI protocol suite, or more specifically to the NetBEUI Transport layer protocol.

NetBIOS

NetBIOS handles the Session layer functions for NetBEUI networks. As I described in Lesson 4, the Session layer manages connections between machines. A server often communicates with several machines simultaneously, and must employ some system to track each of the conversations in which it participates.

Because of its role in Microsoft networking, NetBIOS often handles the Session layer in other protocol suites as well, as you’ll learn when we cover IPX/SPX and TCP/IP in the following chapters. NetBIOS manages connections based on the names of the computers involved.

Machines using NetBIOS take on a name for every function that they perform. In a Windows 98 system, for example, the Network Control Panel applet lists the network name of the system, as shown in Figure 5-2.

Fig. 05-02. The Network Control Panel applet in Windows 98 displays the computer’s name.

Although this looks like a single name, a machine running the NetBIOS Session layer protocol takes this name and uses it as the basis for its NetBIOS names. A NetBIOS name is a special name that identifies both a specific machine and a particular function that it performs.

NetBIOS names consist of the name entered in the Control Panel Network applet, with a special suffix added to the end. The name entered in the Control Panel can contain up to 15 characters. Each character represents a single 8-bit ASCII code.

For example, the 8-bit ASCII code 01100101—often represented in hexadecimal format as 65h—represents the capital letter A. NetBIOS limits the name to 15 bytes, or characters, because it reserves the 16th byte for a special code that defines the role the machine will play on the network.

The two most common roles played by computers on a network are client and server. A client is a machine that can access resources being shared by other computers on a network. A server is a machine that can share its resources with other machines on a network.

Table 5-1 lists the common 16th bit codes used to define the server and client functions of a machine. Don’t worry about memorizing all of the functions and 16th byte codes listed in the table, as they won’t appear on the Network+ exam. We’ll be taking a look some of the most commonly used extensions to understand how NetBIOS manages connections between machines.

16th Byte	Function
<00>	Workstation Service name; the name registered by clients on the network
<03>	Messenger Service Name; used by applications such as WINPOPUP and NET SEND to deliver messages
<1B>	Domain Master Browser
<06>	RAS server
<1F>	NetDDE Service
<20>	File and Print Server
<21>	RAS client
	Network Monitor agent
	Network Monitor utility

Hannah, a friendly neighborhood network tech, installs three machines on her network: a single Windows NT Server named FRED and two Windows 98 systems named BARNEY and DINO. Hannah configures FRED and BARNEY to act as both clients and servers, and configures DINO as simply a client. FRED has at least two names: FRED<00> identifies FRED as a client, and FRED<20> identifies FRED as a file and print server.

Barney also has two names: BARNEY<00> identifies BARNEY as a client, and
BARNEY<20> identifies BARNEY as a file and print server.

DINO, in contrast, simply registers as a client, DINO<00>.

Any real machine using NetBIOS on a Microsoft Network will actually register several more names that support additional, less obvious functions. Those additional names have been left out of this discussion for the sake of simplicity.

Hannah does not specifically set the machines to use these names; she simply installs the server or client software, and a NetBIOS program operating in the background determines the names automatically based on the name Hannah enters in the Identification tab of the Network Control Panel applet. On FRED, the Windows NT system, Hannah specifies the NetBEUI protocol on the Protocols tab of the Network Control Panel applet.

Fig. 05-03. The Protocol tab of Windows NT’s Network Control Panel applet

She also specifies the computer name FRED on the Identification tab, as shown below.

Fig. 05-04. The Identification tab of Windows NT’s Network Control Panel applet

Notice that she does not install the NetBIOS Session layer and NetBEUI Transport layer functions separately—she simply installs NetBEUI. On this screen, Microsoft has made the unfortunate decision to title the tab Protocol instead of Protocol Suite, and refers to the NetBEUI protocol suite as simply NetBEUI.

Hannah isn’t fooled by this terminology blunder, however; she knows that when she adds NetBEUI, she’s actually installing two protocols: NetBIOS at the Session layer and NetBEUI at the Transport layer. By default, Windows NT installs both Server and Workstation—that is, client—components, displayed on the Services tab in Figure 5-5, and FRED is ready to rock and roll.

Fig. 05-05. The Network Services installed on FRED

The tradition in the industry of referring to entire protocol suites by the name of one or two of its constituent protocols has caused lots of unnecessary confusion, pain, suffering, and gnashing of teeth. Unfortunately, we can’t just hop back to the early 1980s using Mr. Peabody’s Way-Back Machine and force the networking industry to adopt clearer terminology. Read carefully whenever the word protocol comes up; the writer could be referring to either a protocol or a protocol suite.

The process of setting up BARNEY as both a client and a server involves roughly the same steps, with the addition of specifically adding the server function. While Microsoft assumes that all installations of Windows NT Server should be servers and installs the Server component by default, there’s also an assumption that network techs will install Windows 9x systems as clients only.

On BARNEY, Hannah installs the Client for Microsoft Networks, File and printer sharing for Microsoft Networks, and NetBEUI.

Fig. 05-06. Various components installed under the Network Configuration tab in Windows 9x

Notice that NT calls its server component Server, while Windows 98 calls its server component File and Print Sharing for Microsoft Networks. While the names and the layout of the Control Panel may change from one operating system to the next, the essential functions do not: FRED and BARNEY function as both clients and servers.

After configuring DINO as simply a client by installing NetBIOS and the Client for Microsoft Networks, Hannah has a three-node network; she and her coworkers can now sit down to do some work.

Some techs make a distinction between the term protocol suite, meaning a set of protocols used together, and protocol stack, which refers to the actual software that implements the suite on a particular operating system. For example: “Windows NT and Windows 98 can both use the NetBEUI suite, but they use different NetBEUI stacks.” In many contexts, however, people who write or talk about such things ignore the distinction and use the terms interchangeably.

When Hannah sits at BARNEY and accesses a file on FRED the NT server, both BARNEY and FRED must keep track of and manage the connection. To open the connection, BARNEY the client, a.k.a. BARNEY<00>, opens up a connection with FRED the server, a.k.a. FRED<20>.

Fig. 05-07. BARNEY opens a connection with FRED.

As FRED begins to send the requested file to BARNEY, another user, Barbara, sits down at DINO and opens another file on FRED, as shown in Figure 5-8.

Fig. 05-08. DINO opens a connection with FRED.

Each of the computers keeps track of the conversations taking place using the NetBIOS names, as shown in Figure 5-9.

Fig. 05-09. FRED, BARNEY, and DINO use NetBIOS names to track their connections.

By using a different NetBIOS name for each function, machines can better track multiple connections between the same two machines. When Barbara sits at FRED and opens a file on BARNEY, FRED<00> establishes a connection with BARNEY<20>. Note that even though FRED runs the Windows NT Server operating system, it still can function as a client computer.

At the same time, Hannah sits at BARNEY and opens a file on FRED, causing BARNEY<00> to establish a connection with FRED<20>. The use of NetBIOS names that correspond to the server and client functions enables FRED and BARNEY to hold two—or more—simultaneous conversations.

Fig. 05-10. A single machine can function in more than one capacity at the same time.

A machine requires a NetBIOS name for each function it performs; without the name, the other nodes cannot establish a connection. When Hannah sits at BARNEY and attempts to open a file on DINO, BARNEY cannot establish the connection. DINO has no server function, since it acts as a client only.

When DINO receives a request for a connection with DINO<20>, DINO does not even bother to send a refusal message back to BARNEY. DINO<20> does not exist—DINO responds to DINO<00> or nothing at all.

Fig. 05-11. DINO ignores BARNEY because DINO<20> is not one of its NetBIOS names.

While NetBIOS provides an adequate means for managing connections on a small network, it does not scale well for larger networks. The base NetBIOS name for each computer must be unique; in other words, there cannot be two machines named DINO. NetBIOS uses a flat namespace, meaning that every machine has a single name drawn from a single pool.

To fully grasp what that means, try imagining a world without last names. No two people could have the name Mike, or Bob, or Johnny. Instead, people would have to come up with unique names like Johnny5, Fonzie, and Bluto.

Given a dozen people, finding unique names presents no problem. Placing a few thousand people in the same flat namespace, however, creates a big problem. In real life, most people have as a many as three or four names, preventing duplication from becoming a concern. In the world of NetBIOS, unfortunately, the designers made no provision for the equivalent of last names.

The flat namespace frequently requires administrators to use bizarre, nondescriptive names and creates administrative headaches. NetBIOS names cannot be terribly descriptive. Bob’s network has a single server, so calling that machine SERVER makes sense. But Wally’s network has 20 servers, including 10 accounting servers, 5 web servers, 4 file servers, and an e-mail server.

Wally usually refers to one of his servers as Accounting Server 7 in conversation, but he cannot use that as the NetBIOS name for the machine. Remember, NetBIOS names must contain 15 or fewer characters, to leave room for that special 16th character that designates the machine’s function. Instead of Accounting Server 7, then, Wally ends up naming the server ACCOUNTSERV7.

The problem of coming up with unique names becomes more extreme in large WAN environments run by multiple administrators. While Wally could easily keep track of his 20 servers and guarantee that he never assigns two machines the same name, ensuring name uniqueness in a large WAN becomes an administrative nightmare.

In a large WAN run by 40 different administrators, guaranteeing that no two administrators ever assign the same name to any two of the 5000+ machines requires extensive planning and ongoing communication. Once a network becomes large enough, network architects prefer a more scaleable naming scheme, such as the TCP/IP protocol suite’s Domain Name Service, or DNS, which you’ll discover in Lesson 6.

Within the NetBEUI protocol suite, NetBIOS handles the Session layer function of managing connections. Its reliance on a flat namespace makes it difficult to use in large WAN environments, but its simplicity makes it an ideal choice for smaller LANs.

As long as the network tech assigns every computer a unique name, NetBIOS does a fine job. Once NetBIOS establishes a connection, it passes the packet down to the NetBEUI protocol, operating at the Transport layer.

NetBEUI

NetBEUI functions at the Transport layer within the NetBEUI protocol suite, breaking larger chunks of data into smaller pieces on the sending machine and reassembling them on the receiving end.

Fig. 05-12. NetBEUI breaks the file into smaller pieces for transmission and reassembles the pieces on the receiving end.

NetBEUI requires no setup by the network tech other than installing the protocol. While this simplicity makes NetBEUI attractive for smaller networks, it deprives NetBEUI of an ability vital to larger networks: routing.

NetBEUI skips the Network layer and communicates directly with the Data Link layer, depriving itself of routing capability. As you learned in Lesson 4, routing occurs at the Network layer. Network layer protocols place additional addressing information onto each data packet. This extra Network layer address tells a router how to find the destination network. When a router receives a NetBEUI packet, it cannot find the information it requires and discards the packet.

Fig. 05-13. Routers discard NetBEUI packets.

NetBEUI can work with bridges, however, which operate at the Data Link layer.

Fig. 05-14. Bridges operate at Layer 2, the Data Link layer, and can filter and forward NetBEUI packets using the MAC addresses contained in the data packet.

In the early 1980s, network architects frequently used NetBEUI because of its simplicity. As the typical network grew and came to include routers, NetBEUI—both the individual Transport layer protocol and the protocol suite—became an increasingly less common choice, supplanted by more scaleable protocol suites such as IPX/SPX and TCP/IP.

The NetBEUI protocol suite’s lack of any Network layer protocol illustrates the key weakness of the OSI model: not everyone follows it.

Chapter 3

IPX/SPX

Novell’s IPX/SPX protocol suite, used primarily by Novell NetWare-based networks, provides a more scaleable solution for networks than NetBEUI. Lesson 7 will include an overview of Novell NetWare.

While the NetBEUI protocol suite provides services at the Transport and Session layers, IPX/SPX includes a wide variety of protocols operating at layers 3 through 7, the Network through Application layers. Although it’s more scaleable than NetBEUI, in very large networks IPX/SPX bogs down due to excessive traffic.

Figure 5-15 shows some of the IPX/SPX protocols in relation to the OSI model. At the Network layer, the Internetwork Packet eXchange, or IPX, protocol handles routing data packets between networks. At the Transport layer, Sequenced Packet eXchange, or SPX, handles the process of breaking data into smaller chunks on the sending machine and reassembling the data on the receiving machine. Service Advertising Protocol, or SAP, handles the Session layer, and the NetWare Core Protocol, or NCP, handles a variety of Presentation and Application layer issues.

Fig. 05-15. IPX/SPX includes protocols operating at OSI layers 3-7.

The Network+ exam does not require knowledge of the individual protocols that make up the IPX/SPX suite.

Although IPX/SPX is strongly associated with Novell, Microsoft also supports it through its own version of the protocol, called NWlink. Rather than add routing support to NetBEUI, Microsoft simply adopted a proven routable protocol that already existed. Microsoft-based clients and servers can use IPX/SPX for communicating with both Microsoft and Novell NetWare servers.

Fig. 05-16. Microsoft calls its version of the IPX/SPX protocol suite either IPX/SPX-compatible Transport or NWlink.

Microsoft NOSs, including Windows 95, Windows 98, and Windows NT, use IPX/SPX for two purposes: to connect to NetWare servers and to provide Transport and Network layer functions for Microsoft networking. Microsoft does not use the IPX/SPX protocol suite’s Application, Presentation, or Session layer protocols; instead, communication between two Microsoft-based systems relies on traditional Microsoft networking protocols such as NetBIOS.

Fig. 05-17. Microsoft clients and servers use only a subset of the IPX/SPX protocol suite.

Unlike NetBEUI, which requires no configuration beyond assigning each computer a name, IPX/SPX requires the network tech to configure IPX properly. IPX packets, created at the Network layer, can use several formats that vary depending on the Data Link layer protocol used.

IPX running on top of Ethernet, for example, can use one of four data structures, called frame types: Ethernet 802.3, Ethernet II, Ethernet 802.2, or Ethernet SNAP. If two nodes use different frame types, they cannot communicate.

Fig. 05-18. Two nodes using IPX ignore each other’s packets if configured to use different frame types.

In the days of DOS-based network clients, network techs set the frame type manually for each system on the network. Windows 9x or Windows NT systems simplify the process by automatically detecting IPX traffics by default, configuring each machine to use whichever frame type it detects on the network first.

Fig. 05-19. Windows 9x and NT systems automatically detect the frame type in use on the network.

Problems arise, however, when a network uses more than one frame type. Each Windows 9x or NT system automatically configures itself to use the first frame type that it detects, resulting in mismatched frame types.

Fig. 05-20. Windows 9x and NT systems sometimes detect different frame types.

To ensure that every system uses the same frame type, use the Network Control Panel applet, shown in Figure 5-21. The structural details of the different frame types do not affect the network tech; you should simply configure all systems to use the same frame type.

Fig. 05-21. Setting the frame type manually

IPX/SPX, though routable, does not scale well for large WANs. Novell designed IPX/SPX to support its NetWare operating system, which treats NetWare servers as the ultimate focus of the network. In a NetWare environment, servers are servers, clients are clients, and never the twain shall meet.

Unlike NetBEUI, which assumes that a machine can function as both a client and a server, IPX/SPX assumes that a proper network consists of a few servers and a large number of clients. The servers use the Server Announcement Protocol, or SAP, to create and maintain connections. This configuration works well on small and medium-sized networks, but as a network grows to include hundreds of servers and thousands of clients, SAP traffic increases, slowing down the network.

Until recently, the danger of excessive SAP broadcasts did not affect the typical network tech—most networks simply didn’t have enough servers for SAP broadcasts to cause congestion. As large networks become common, however, IPX/SPX’s reliance on SAP broadcasts becomes more of a problem, leading most WAN designers to adopt a more scaleable alternative: TCP/IP.

Chapter 4

TCP/IP

The TCP/IP protocol suite offers a more scaleable solution, but requires significantly more configuration on the part of the network tech. Although it was originally a UNIX networking protocol suite, its use as the protocol suite of the Internet has prompted both Microsoft and Novell to embrace TCP/IP. Unlike NetBEUI and IPX/SPX, TCP/IP is an open standard, not controlled by any one company.

A series of documents called Requests for Comment, or RFCs, defines each protocol within the TCP/IP suite. These documents, freely available on the Internet, provide all the information needed to write programs that conform to the TCP/IP standard. The open nature of these protocols makes TCP/IP an attractive environment for developing new protocols. If TCP/IP has no protocol that provides a desired function, any skilled programmer can write a new protocol, publish an RFC, and add it to the TCP/IP suite.

This flexibility enabled the evolution of the Internet from a simple, geographically dispersed network for transferring e-mail and data files into the Internet of today, with its World Wide Web of web pages, real-time audio broadcasts, instant messaging, secure credit card transactions, and more wonders to come. The ability to add new protocols to meet new needs gives TCP/IP a flexibility that the other protocols cannot match. Lesson 6 will cover TCP/IP configuration in detail.

Chapter 5

Summary

Protocol suites serve to arrange the protocols of the OSI model into more manageable pieces by placing them in groups that work together, or otherwise complement one another. Among the many protocol suites, the three major ones—NetBEUI, IPX/SPX, and TCP/IP—offer varying degrees of ease of use, efficiency, and flexibility.

All of the Microsoft OSs will at some time or other use the NetBEUI suite to communicate with other Microsoft OSs, and Novell and Microsoft can communicate in IPX/SPX, but the most widely used and most scalable suite is TCP/IP—the open standard suite which is behind the growth of the Internet as we know it. In the next lesson, you’ll learn about the TCP/IP suite in detail.

Supplementary Material

NetBEUI Definition from PC Webopaedia http://www.webopedia.com/TERM/N/Netbeui.html

This definition of NetBEUI from PC Webopaedia includes links to relevant information.

NetBIOS, NetBEUI, NBF, SMB, CIFS Networking http://ourworld.compuserve.com/homepages/timothydevans/contents.htm

This is an online paper by Timothy D. Evans concerning NetBIOS, NetBEUI, NBF, SMB, and CIFS Networking.

NetBEUI Definition from Whatis.com http://whatis.techtarget.com/definition/0,289893,sid9_gci212632,00.html

This definition of NetBEUI comes from whatis.com.

IPX/SPX basics http://www.wown.com/j_helmig/ipxspx.htm

These IPX/SPX basics are from J. Helmig's World of Windows Networking.

IPX Definition from PC Webopaedia http://www.webopedia.com/TERM/I/IPX.html

This definition of IPX from PC Webopaedia includes links to relevant information.

Introduction to TCP/IP http://www.yale.edu/pclt/COMM/TCPIP.HTM

This is a rather old introduction (1995) from Yale university.

Warriors of the Net http://www.warriorsofthe.net/

This computer-animated short movie describes how TCP/IP makes the Internet work by showing the network journey of one little data packet.

Copyright 2003 by ed2go.com. All rights reserved.
No reproduction or redistribution without written permission.