One of the greatest strengths of the Windows NT Server operating system is the variety of networking protocols it supports. But that variety can be a source of confusion when it's time to choose the protocol(s) to use for your network.
This chapter describes the transport protocols compatible with Windows NT. A protocol is a set of rules, implemented in software, that govern communication between two computers. Not all operating systems support all protocols, so you must select the appropriate networking protocols that you set up for Windows NT Server to accommodate all the client computers connected to the network, plus other servers now in use, if any. If this computer will connect to a larger network, such as the Internet or a WAN, you must accommodate this in your protocol choice as well.
Chapter 5, "Purchasing Networking Hardware," covers the various physical networks (Ethernet, Token Ring, and others) and provides a detailed discussion of the network cards, cables, and other hardware components that connect the computers. Making these hardware choices doesn't automatically determine the network protocol(s) you use, but your choice of network protocol(s) is likely to determine the network-related peripheral components you purchase, such as routers.
This chapter shows you the following:
Communication over a network is a complex task. To simplify the task of discussing and building networks, the OSI (Open Systems Interconnection) seven-layer networked model was developed by the International Standards Organization (ISO), a branch of the United Nations headquartered in Geneva. OSI applies to a great variety of networking situations. At the heart of OSI is the diagram shown in figure 4.1. The seven layers, numbered from the bottom to the top, represent the seven different aspects of networking. Layer 1, the physical layer, is the most concrete, consisting of components that can actually be touched. On the other hand, layer 7, the application layer, is the most abstract, consisting of high-level software.
The OSI model doesn't correspond precisely to commercial networking software products, some of which span several levels or break a level into several tasks. Instead, the model provides a useful way of discussing the complex task of arranging communication between computers.
4.1
The seven layers of the Open Systems Interconnection (OSI) model.
The physical layer sends bits over the wire or over another connection, such as a fiber-optic cable or wireless connection, between computers. It deals with the electrical signals that represent the 0 (off) or 1 (on) state of a bit traveling over the network cabling. The decision to use a particular type of network interface card or a choice between twisted-pair and coaxial cable is a decision about the physical layer, which is implemented in networking hardware.
The data-link layer deals with frames, groups of bits that are transmitted over the network. It relies on the physical layer to actually send the bits. The data-link layer ensures that frames sent over the network are received and, if necessary, resends them. Ethernet is an example of a data-link layer, as is Token Ring, and each has a different layout for a frame.
In the official terminology of the OSI model, the group of bits sent by the data-link layer is called a physical layer service data unit. In practice, people call it a frame or a data frame.
The IEEE networking model divides this layer into two sublayers: Logical Link Control (LLC) and Media Access Control (MAC), as shown in figure 4.2. The MAC sublayer handles interaction with the physical layer below, and the LLC sublayer handles interaction with the network layer above. The MAC layer provides standard interfaces for Carrier Sense Multiple Access with Collision Detection (CSMA/CD, Ethernet) networks, token-passing bus networks (similar to ArcNet), and Token Ring networks.
4.2
The IEEE 802 series standards for Logical Link Control and Media Access Control within the OSI data-link layer.
The network layer deals with packets, which may be larger or smaller than frames. If the packets are larger than frames, the network layer breaks the packet into frames to send them, and reassembles them on receipt. If the packets are smaller than frames, the network layer bundles frames into packets to send them and breaks them apart on receipt.
In either case, the network layer relies on the data-link layer to transmit the frames themselves. The network layer also deals with routing packets between computers (hosts) on the network, and it knows the addresses of the hosts on the network. Typically, the network layer can adjust the routing of packets to deal with network traffic and congestion. The network layer doesn't keep track of whether packets arrived at their destination or whether any errors occurred during transmission-that job is handled by the transport layer.
The transport layer deals with messages, which may be larger or smaller than packets. This layer ensures that messages travel between hosts without data loss and, if necessary, arranges for packets to be re-sent. The transport layer relies on the network layer to transmit the frames.
NetBEUI, TCP/IP, IPX/SPX, and other transport protocols handle the duties of the network layer and the transport layer. It's quite common for these two layers to be combined into a single protocol, and it is protocols that this chapter discusses.
Some people argue that TCP/IP, the transport protocol of the Internet, isn't a single protocol, but rather a suite of protocols that includes TCP, IP, UDP, and others. In the near future, IP will be changed to accommodate more addresses, but TCP probably won't need to change. Most ordinary users and network administrators tend to think of TCP/IP as a single element.
The session layer establishes and maintains a session between applications running on different computers. It knows the names of other computers on the network and handles security issues.
The session layer relies on the transport layer to transmit messages between the two computers. NetBIOS, the session layer for the Windows network, and Sockets, the session layer for TCP/IP, are examples of typical session-layer software. Windows NT uses the 32-bit Windows Sockets (Winsock) session layer.
Winsock is the specification developed by more than 20 cooperating vendors that describes implementations of sockets on Windows machines. The first release of the specification was for TCP/IP protocols only, but it was designed to work over other protocols in the future. Different vendors release their own DLLs that implement the Winsock specification; a 32-bit Winsock DLL is included with Windows NT and Windows 95.
The presentation layer provides services that a number of different applications use, such as encryption, compression, or character translation (PC ASCII to IBM's EBCDIC, for example, or PC/Intel's little-endian to Macintosh and Motorola's big-endian byte-ordering). The presentation layer relies on the session layer to pass on the encrypted, compressed, or translated material. One implementation of a presentation layer is XDR (External Data Representation) under RPC (Remote Procedure Call).
RPC is a service that allows programmers to create applications that consist of multiple procedures; some procedures run locally, whereas others run on remote computers over a network. RPC is especially useful because it takes a procedural, rather than transport-centered, view of network operations. RPC simplifies the development of distributed or client/server applications. RPC is used extensively by Microsoft BackOffice applications, such as Microsoft Exchange Server, and for communication between Automation client and Automation server applications.
The application layer handles requests by applications that require network communication, such as accessing a database or delivering e-mail. This layer is directly accessible to applications running on networked computers. It relies on the presentation layer to manipulate and transmit the communication. RPC is an example of an application-layer implementation.
Many important protocols span the presentation and application layers-for example, named pipes and FTP (the File Transfer Protocol, not the application itself). Clients use named pipes, for example, to communicate with Microsoft SQL Server. FTP is familiar to all UNIX and Internet users.
The networking architecture of Windows NT is built of layers that don't fully correspond to the layers of the OSI model. Windows NT's layers are shown in figure 4.3, which includes the OSI layers for reference.
4.3
A comparison of the Windows NT networking model (right) and the OSI model (left).
The keys to figure 4.3 are Windows NT's two new layers: the Transport Driver Interface (TDI) and the Network Device Interface Specification (NDIS). These layers allow Windows NT to use simultaneously a number of different transport protocols in the layer between TDI and NDIS, and to make the choice of transport protocol transparent to the session and data-link layers.
TDI sits between the transport protocols and the session layer, which may be NetBIOS, Winsock, RPC, or some other session layer, no matter what the transport protocol chosen. TDI isn't so much a program as it is a specification-that is, a set of rules for writing the layers above and below it.
The NDIS interface, which sits between network adapter cards and transport protocols, allows any of the transport protocols to run over any of the adapter cards, as long as the protocols are written to the NDIS interface and the adapter card supports NDIS. NDIS also allows multiple protocols to be used at the same time on the same network adapter card.
Whether you think of the protocols discussed in this chapter as spanning two levels of the OSI model, or as the thick central layer of the Windows NT model, the protocols serve the same purpose-to move chunks of information around the network based on the network address of the destination.
Windows NT Server provides built-in support for seven networking protocols:
Figure 4.4 shows how each protocol fits into the Windows NT network layer diagram shown earlier in figure 4.3. The following sections detail each of the seven protocols.
4.4
Windows NT's transport protocols between the Transport Driver Interface and the NDIS interface.
The NetBIOS Extended User Interface (NetBEUI) protocol, introduced in 1985, is an extension of the NetBIOS data-link layer. IBM developed NetBEUI to handle LANs of 20 to 200 workstations, such as those that a company might set up for a single department. IBM's assumption was that gateways between LANs would provide large-scale networking capability.
NetBEUI is a compact, fast protocol, but it's more than 10 years old and doesn't scale well to larger networks. NetBEUI isn't a routable protocol; routable protocols let you create a wide area network (WAN) by interconnecting LANs. A routable protocol is vital if your LAN is to be connected to anything but a small cluster of client PCs.
The NetBEUI Frame (NBF) protocol builds on NetBEUI to overcome some of these difficulties. In particular, NBF overcomes the session limit, which is 254 in NetBIOS. This makes it operable for larger networks that must retain compatibility with existing NetBEUI networks.
If you now have a NetBEUI network in operation, the commercial implementation of NetBEUI running on the PCs you plan to connect to your Windows NT server is likely one of the following:
NetBEUI networks are very simple to implement but are difficult to expand because the NetBEUI protocol isn't routable. To a great extent, the limitations of NetBEUI are responsible for the success of Novell NetWare in the network operating system market. If you're starting from scratch to build a network around a Windows NT Server machine, avoid NBF in favor of TCP/IP or, if you also must support NetWare, IPX/SPX (NWLink).
Transmission Control Protocol/Internet Protocol (TCP/IP) is the protocol of choice for WANs and is rapidly being adopted for LANs. TCP/IP, used for decades on the Internet and its predecessors, has been fine-tuned to maximize performance in extraordinarily large networks. Unlike NetBEUI, which is a proprietary IBM and Microsoft protocol, TCP/IP is in the public domain. The Internet Engineering Task Force (IETF) is the standards body that coordinates extensions and improvements to TCP/IP through a mechanism known as Requests for Comments (RFCs).
A number of Internet standards describe the TCP/IP protocol and related protocols. These are accessible using FTP in the directory ftp://ftp.merit.edu/documents/std/. An index to the Internet standards is at ftp://ftp.merit.edu/documents/std/INDEX.std.
TCP/IP is an incredibly robust and reliable protocol. It was designed to keep the Department of Defense's Advanced Research Projects Agency's network (ARPANET, the precursor to the Internet) functioning, even if many of the cities it connected had been wiped out in a nuclear war. During the early history of ARPANET, only defense contractors and university research facilities were connected. To encourage expansion of the network, commercial users were admitted; today, the vast majority of traffic on the Internet is commercial, not government-related.
The term commercial, in this case, includes individual users who connect to the Internet through commercial SPs or ISPs. SPs (service providers) lease high-speed connections to the Internet backbone and provide modem banks for individual dial-up access to the Internet. ISPs (Internet service providers) sell dial-up access and other Internet-related services (such as hosting Web pages) to individuals and small companies that don't need an intranet.
See "Choosing an Internet Service Provider," (Ch 19)
TCP/IP is a very flexible protocol that you can deploy in a small-scale LAN and later expand to accommodate hundreds or thousands of users. TCP/IP requires more knowledge to manage than other networks, because each machine must have a unique IP address and subnet mask. Tools (DHCP, WINS) are available in Windows NT Server to simplify these tasks, and experienced TCP/IP administrators are relatively easy to find and hire. If you're setting up a simple TCP/IP LAN with fewer than 100 or so client PCs, it's a reasonably simple job to administer the LAN if you learn how to use Windows NT Server's built-in administrative tools for TCP/IP.
The most important advantage of TCP/IP over NetBEUI is that TCP/IP is a routable protocol. A router is a device that forms a connection between a LAN and a WAN, or between two LANs. The router intercepts network packets and leaves the packets on the LAN if they are for a machine on the LAN; if not, the router passes the packets to another LAN or WAN. The structure of IP network addresses is designed specifically for efficient routing, and the price of dedicated routing hardware has decreased dramatically over the past few years.
See "Routers," (Ch 05)
Every machine on a TCP/IP network has an IP address, such as 205.210.40.3. An IP address-sometimes referred to as a dotted quad-consists of four numbers, each in the range of 0-255, separated by dots. When an entire LAN joins the Internet, it's common to assign IP addresses to the machines on the LAN that are easily distinguished from IP addresses on the rest of the Internet. Groups of related addresses are referred to as Class A, B, or C addresses:
Only a limited number of these classes are available. For example, first components with values between 1 and 126 are reserved for Class A addresses (in practice, fewer than 50 Class A addresses have been assigned, primarily to Internet builders such as the U.S. military and telecommunications companies). First components between 128 and 191 are available for Class B addresses, and between 191 and 223 for Class C addresses. First components above 223 are reserved; if your installation requires only a single IP address, it will be assigned from the Class B or C address of your ISP.
This structure makes routing simple to arrange. If you have a Class C address, for example, traffic destined to an IP address that varies in the first three components from that of your LAN is to be routed out to the rest of the Internet; traffic with the same first three components as your LAN stays on the LAN. This is coded in a value called a subnet mask. The subnet mask 255.255.255.0 codes this routing pattern for a Class C address.
You can split a single Class C address into several smaller pieces, each piece on its own LAN. The subnet mask is a bit-by-bit mask of the IP address, with each component representing eight bits. For example, the subnet mask 255.255.255.224 defines a 31-address subnet with the following properties:
A Class C address could be split into seven such subnets, allowing for great flexibility in combining small LANs. If large LANS are involved, a Class B address can be split in a similar manner.
The job of managing and assigning IP addresses and subnet masks can involve substantial effort. The Dynamic Host Configuration Protocol (DHCP) included with Windows NT Server reduces this effort significantly. To do it by hand, administrators must use Control Panel's Network tool; on the Protocols page select the TCP/IP protocol and click Properties, choose the IP Address page, and then fill in the IP address and subnet mask as shown in figure 4.5.
4.5
Setting the IP address and subnet mask manually.
See "Dynamic Host Configuration Protocol (DHCP)," (Ch 17)
Whereas administrators need to be comfortable with IP addresses, most users are not. The Domain Name System was introduced in the early 1980s to cope with the Internet's growth, which was considered to be very rapid then but has been eclipsed by the growth rates of the 1990s. Machines on the Internet have domain names such as que.mcp.com or ftp.merit.edu, made up of two or more short strings of letters and numbers separated by dots.
Domain names are far less structured than IP addresses but are easier for humans to interpret. For example, the domain names csri.utoronto.ca and psych.utoronto.ca are obviously related (in fact, they identify the Computer Science Research Institute and the psychology department, both at the University of Toronto).
See "Name Resolution and the Domain Name System," (Ch 19)
A computer running Windows NT Server that's on the Internet can have two names: one that it's known by on the Internet, and one that it's known by on the local network (the NetBIOS name defined during Setup). The job of managing names is made easier by the Windows Internet Name Service (WINS), which is included with Windows NT Server.
See "Windows Internet Naming Service (WINS),"(Ch 17)
TCP/IP implementations are available for UNIX systems, the Macintosh, and Windows 3.x, and are included in Windows 95 and Windows NT Server and Workstation 4.0. TCP/IP supports many session-layer implementations, including NetBIOS (called NetBIOS over TCP/IP), Sockets (Winsock), Streams, and RPC. TCP/IP is the most commonly used protocol to provide dial-up network access (RAS) for mobile users.
The Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX) protocol is the heart of Novell NetWare. Microsoft's implementation of the IPX/SPX protocol is called NWLink. The IPX/SPX protocol is based on the Xerox Network System (XNS) protocol developed by Xerox Corp. XNS, which is no longer in use, had two components: IDP (Internet Datagram Protocol) and SPP (Sequenced Packet Protocol). IPX is based on IDP; SPX is based on SPP.
See "Integrating Windows NT Server with Novell NetWare," (Ch 17)
IPX/SPX is a high-performance protocol for local area networking and is easier than TCP/IP to implement and administer. Like TCP/IP, IPX/SPX is a routable protocol, so it can be used to establish a WAN. Because of NetWare's commercial success, IPX/SPX is now the default network protocol installed when you set up Windows 95. Unless you're installing Windows NT Server within an existing NetWare environment, however, TCP/IP is a better protocol choice, especially if you intend to provide Internet or related intranet services to client PCs. To conserve resources, you should uninstall IPX/SPX if you won't be using it. Using Windows NT Server with Novell NetWare servers is one of the primary subjects of Chapter 17, "Integrating Windows NT with Heterogeneous Networks."
IBM's DLC (Data Link Control) protocol is used to communicate with mainframes as a component of IBM's System Network Architecture (SNA). On some LANs, DLC is used to communicate with printers that are connected directly to the LAN, rather than to a workstation or server. Several high-end Hewlett-Packard LaserJet printers offer DLC interfaces as an option.
AppleTalk is the primary network protocol used by Macintosh computers. It's supported by Windows NT Server's Services for Macintosh, which allows Macintosh users to share Mac-format files stored in Windows NT Server folders and use printers connected to a Windows NT server. Shared Windows NT folders appear to Mac users as conventional Mac folders. Mac file names are converted to FAT (8.3) and NTFS standards, including long file names (LFNs), as required. DOS and Windows client applications that support Mac file formats can share the files with Mac users.
Windows NT Server supports the Mac application fork, so Mac users can double-click a file stored on a Windows NT server and launch the associated application. The application fork of a Mac file serves the same purpose as Windows file extension associations. Mac users can drag and drop their files from a Mac folder directly to a Windows NT server folder.
See "Setting Up Macintosh Clients," (Ch 11)
Windows NT Server provides RAS (Remote Access Service) to enable temporary connections to systems that aren't on your LAN-typically, dial-up connections over a conventional telephone line. Windows NT Server includes built-in support for Integrated Services Digital Network (ISDN) modems. A single Windows NT server supports up to 255 simultaneous RAS connections. Chapter 18, "Managing Remote Access Service," covers the subject of dial-up RAS in more detail.
The RAS connection can use SLIP (Serial Line Internet Protocol) or, preferably, PPP (Point-to-Point Protocol) over a dial-up or dedicated phone line, or via the X.25 network communications protocol. When a PPP connection is made, your LAN and the remote site can communicate by using NetBEUI, TCP/IP, or IPX/SPX. PPP with TCP/IP is the most common protocol for connecting mobile users to intranets. The Microsoft Network Client included with Windows 95 uses dial-up PPP with TCP/IP to connect to MSN's bank of Windows NT servers and, through MSN, to the Internet.
The new PPTP (Point-to-Point Tunneling Protocol)-announced by Microsoft, 3Com Corp., Ascend Communications, ECI Telematics, and U.S. Robotics in March 1996-allows users to "tunnel" through the Internet to reach their secure networks from a local dial-up connection.
See "Using the Point-to-Point Tunneling Protocol," (Ch 18)
RAS clients are available for DOS and Windows 3.1+ and are included with Windows for Workgroups, Windows 95, and Windows NT. Windows 95 supports a single dial-in RAS connection if you buy the Windows 95 Plus! pack to obtain the Windows 95 RAS server upgrade.
Streams is a protocol specification that enables Windows NT to support third-party communications protocols. In effect, the third-party protocol is enclosed by an upper Streams layer and a lower Streams layer (see fig. 4.6). The upper Streams layer talks to the session layer and the third-party protocol; the lower Streams layer talks to the third-party protocol and the data-link layer.
4.6
Supporting third-party transport layers with the Streams layer.
Streams also is the name of a UNIX session-layer protocol that was developed by AT&T in 1984. AT&T's Streams was intended to serve the same purpose as Sockets, but Sockets and Winsock have been so successful that Streams is no longer implemented in most UNIX systems. It's not at all related to the Windows NT Streams protocol.
It's possible that you're installing an entire office full of computers, and you can choose the client PCs and operating systems that fit best with Windows NT Server. In this case, Windows NT Workstation 4.0 for desktop PCs and Windows 95 for laptop PCs (and desktop PCs with less than 16M of RAM) are the logical choices. It's more likely, however, that you're integrating a server into an environment that's now running one or more operating systems. The optimum protocol choice allows all your machines to talk to your server without spending large amounts of money and/or time.
Theoretically, any protocol can be implemented for any operating system. If you discover an obscure piece of third-party software that lets all the machines in your environment use the same protocol, such a product might seem a likely candidate. In this chapter, the assumption is that you're choosing from the generally available and popular implementations-and that means not every operating system can run every protocol. Integrating obscure third-party software into a network is a chancy proposition, at best.
It's possible for your server to support a number of different protocols at once; but to keep your workload to a minimum, choose your protocol(s) carefully so that you use as few as possible. In addition to making administration more complicated, running several protocols simultaneously consumes more memory on the server and client computers, and can have a deleterious effect on system performance. The following sections describe the types of clients commonly connected to Windows NT servers and the networking protocols individual clients support.
Not surprisingly, using clients running Windows NT Workstation 4.0 allows you to use almost any of the networking protocols supported by Windows NT Server, including
In many cases, your choice of protocol under Windows NT is determined not by your operating system, but by the software your Windows NT clients run. For example, most Windows Internet software (including Web browsers) runs over TCP/IP using Winsock, but not over NetBEUI.
See "Connecting Windows NT Workstation 4.0 Clients," (Ch. 11)
PCs running Windows NT Workstation 4.0 can participate in peer-to-peer (workgroup) networks, which operate independently of the Windows NT server(s) that support the primary (client/server) network. A maximum of 10 workgroup members can connect simultaneously to a Windows NT client that shares the workgroup files. NetBEUI (the Windows network) is the most common method of establishing peer-to-peer workgroups. Most network administrators discourage peer-to-peer file sharing because of security issues, including lack of coordinated access control to sensitive information and centralized backup procedures.
Windows 95 offers the same suite of 32-bit network protocols as Windows NT Workstation. One primary advantage of Windows 95 is the ease in which Plug-and-Play network adapter cards install. In general, software that runs under Windows NT Workstation also can run under Windows 95, thus users can choose their operating system without being concerned about networking issues. Another is that many new PCs are shipping with Windows 95 installed, saving the cost of another operating system. Windows 95 has been designed for less powerful PCs, but you should be aware of limitations (memory or disk space) on the client machines that preclude running Windows 95 efficiently. Chapter 10, "Configuring Windows 95 Clients for Networking," is devoted to optimizing the networking performance of Windows 95 PCs.
Because it's an older product than Windows NT or Windows 95, Windows for Workgroups (WfWg) 3.1x doesn't support as many protocols. WfWg 3.1x limits the workstation to running only two networks at once. You connect to a Microsoft network and one other network by running one of the following protocols:
Again, the software you're running will play a major part in your choice among these options. Some software runs only over certain network protocols; check your documentation.
See "Connecting Windows for Workgroups 3.11 Clients," (Ch. 11)
Windows versions before Windows for Workgroups don't support networking directly; instead, early releases of Windows used DOS-based networking. Like the DOS clients mentioned in the next section, Windows 3.1+ clients attached to your Windows NT server can use one of the following protocols:
It's not possible for one Windows 3.1+ client to use more than one network protocol at a time.
See "Connecting Windows 3.1 Clients," (Ch. 11)
Sometimes two applications on the same computer talk to each other by using a standard protocol as though they were running over a network. Choosing to install that protocol and to run those applications doesn't affect your choice of protocol for your actual network. If a developer on a NetBEUI LAN is testing an Internet (Winsock) application, for example, two Internet applications may be running on the developer's machine using Winsock to communicate. The developer isn't on a TCP/IP LAN.
Similarly, if you form a temporary connection to another workstation or server by using a networking protocol, the temporary connection doesn't imply that you're networked to that machine, and it doesn't affect your protocol choice. If the Internet developer dials up to an ISP by using a third-party stack such as Trumpet, that single machine is communicating with the ISP using TCP/IP but isn't connected to a TCP/IP LAN.
MS-DOS clients have a rather limited set of protocols available but can be connected to your Windows NT server by using one of these protocols:
It's not possible for one MS-DOS PC to run more than one network protocol simultaneously.
Just as Microsoft has improved PC networking capabilities with each new version of Windows, IBM has increased the networking features of OS/2, generally providing with the operating system access to protocols that in the past could be accessed only with third-party add-ons. OS/2 versions 1.x, 2.x, and Warp can all use any of these protocols:
You can connect PCs that don't run DOS or Windows to a Windows NT server. The protocols supported for Macs are
Choosing AppleTalk will make your life difficult if there are any non-Macintosh machines (other than your Windows NT server) on your network, and if you want the Macs to have peer-to-peer access to the files on non-Macintosh workstations. If possible, all Macs connected to a network served by Windows NT should use the TCP/IP protocol.
See "Connecting Macintosh Clients," (Ch. 11)
UNIX systems have even less in common with Windows and DOS systems than Mac systems do. However, TCP/IP is a protocol that was designed for use with various operating systems. Using TCP/IP lets UNIX workstations talk to your Windows NT server without difficulty. Interconnecting with UNIX networks is one of the subjects of Chapter 17, "Integrating Windows NT with Heterogeneous Networks."
Arranging for one or more client PCs to be networked to your server may be all you need on a relatively small network. On the other hand, there may be other servers in your installation that must be connected to your new Windows NT server. Each additional server can communicate by using one or more of the protocols supported by Windows NT.
As usual, when the machines to be connected are using the same operating system, you have the most flexibility in choosing a protocol. Interconnected Windows NT servers support the full range of protocols:
NetBEUI Frame (NBF) Data Link Control (DLC) NWLink (IPX/SPX) TCP/IP Streams AppleTalk
It wouldn't be wise to choose DLC, Streams, or AppleTalk in this case, because they're limited protocols that might not be supported by other clients on your network, but such a choice is technically possible.
To Windows NT Server, talking to a NetWare server isn't very different from talking to a NetWare client-you simply use the SPX/IPX protocol. Novell offers an implementation of TCP/IP for NetWare 3.x and 4.x; if you plan to install the TCP/IP protocol, using TCP/IP to interconnect NetWare and Windows NT servers is preferred.
UNIX servers, like UNIX clients, should be part of a TCP/IP network. Microsoft's version of TCP/IP is fully compatible with the UNIX implementations of TCP/IP.
One of the hottest developments in the networking world is intranetworking, using Internet software and protocols to communicate within a company. Intranetworking is discussed fully in Chapter 19, "Setting Up the Internet Information Server," and Chapter 20, "Administering Intranet and World Wide Web Sites." People within the company use Internet tools such as e-mail, Web browsers, and FTP file-transfer programs to deliver information over their own internal intranet. Typically, TCP/IP is the transport protocol of choice.
Microsoft Internet Information Server (IIS) 2.0 is a Web server for Windows NT Server 4.0. IIS builds on the strong background of third-party Internet servers previously available for Windows NT, including FTP, Gopher, and Web servers. IIS is fast, secure, and free, thus making it very popular for creating both intranet and Internet sites. Internet Information Server 2.0 is included with Windows NT Server 4.0.
Connecting to the Internet can be a very simple or very complex project, as discussed in Chapter 19, "Setting Up the Internet Information Server." Connecting one machine to the Internet through a PPP connection is a very different project from connecting an entire LAN through one server machine. If there are security issues that require that the connection pass through a firewall, it's an even more complex job. Chapter 18, "Managing Remote Access Service," addresses some of these issues.
The Internet greatly simplifies the choosing of network protocols. The I in TCP/IP stands for Internet, and TCP/IP is the only protocol that you can use on the Internet.
There are many different mainframes, but one of the most important players is the IBM AS/400, which uses System Network Architecture (SNA). SNA relies on DLC as its transport protocol. If you use the SNA Server component of Microsoft BackOffice, you can connect to a number of different mainframes, including
IBM AS/400s All IBM mainframes IBM plug-compatible mainframes running IBM host software (such as Amdahl, Fujitsu, or Hitachi) Tandem Fujitsu (using FNA) Hitachi (using HNA) OS/2 Comm Manager or Extended Services (using APPC) UNIX-based SNA gateway products (using APPC) IBM RS/6000 RISC computers
If all the workstations you plan to connect to your Windows NT server use the same protocol, life is simple. Assuming that you have a collection of machines to connect to your Windows NT server and that the collection uses two different protocols, the following options are available:
You can run two or more different protocols on the Windows NT server. You can change the protocol that one set of workstations is using, so that all are using the same protocol. You can replace one set of workstations with a set that runs the same protocol as the others. You can gather the workstations into two or more LANs with gateways to handle translation and interconnection.
Setting up Windows NT Server to use one protocol to talk to one set of machines and a different protocol for the rest involves the fewest changes to the workstations, the smallest investment, and the least disruption to your users. This approach has some performance penalties; network processes consume more of your system memory and might even cause paging, which slows your system down. There will be cases where you gladly accept these relatively minor performance penalties to connect previously incompatible workstations.
Changing the protocols the workstations run might allow you to keep the same workstations while running only one protocol. This approach simplifies administration and improves the performance of your server, but it likely will be costly to buy new licenses for the protocol to be implemented on the client workstations. Also, there may be disruption to your users as you change the software that joins them together in a network. If some of your workstations are using a specific protocol for significant security or performance reasons, it may not be wise to change the protocol.
You may think it's unlikely that two sets of workstations would use different protocols if it's so simple to make them the same, but it's a matter worth investigating. For example, a wide variety of systems can run TCP/IP, and TCP/IP is a good solution when combining Macintosh and Windows workstations. However, many administrators automatically assume that the protocol is NetBEUI or IPX/SPX for the Windows machines and AppleTalk for the Macs. Another approach for machines that use NetBIOS over NetBEUI is the simple change to running NetBIOS over IPX/SPX.
The most drastic solution, if the workstations can't switch to a common protocol, is to replace one set of workstations and their application software. The mildest version of this approach is to move to a more recent version of the operating system while keeping the same applications, such as upgrading from Windows for Workgroups to Windows 95 or to Windows NT Workstation. The more dramatic approach is to change the systems completely, such as replacing Macintosh workstations with Windows 95 machines. Changing from Macs to PCs is very likely to meet with strong resistance from your users, but many firms are eliminating Macs in order to standardize user support on a single client platform. Remember, it's not enough for the operating systems themselves to support the transport protocol; the software that your users utilize must also support the protocol, either by trusting the operating system to handle all networking or by supporting the protocol directly.
If none of these solutions seems palatable, perhaps the two sets of workstations should be on two separate LANs. A gateway can transfer traffic between the two LANs while making any necessary translations between the network transport formats.
There's often some confusion about the name for a device (a combination of hardware and software) that sits between two networks. Here are some definitions:
Bridge. Connects two similar LANs, usually running the same protocol, and passes the data on essentially unchanged. Gateway. Connects dissimilar networks and translates frame format, byte order for addresses, or similar low-level protocols. Router. Sits between networks and directs traffic to the appropriate network. If the networks are dissimilar, they need a gateway as well as a router. Proxy server. As part of a firewall, intercepts requests between networks and refuses them or passes them on according to the proxy server's own security rules.
Bear in mind that decisions can change with time. For example, you might choose to run two protocols at first, and then slowly migrate to a single protocol as new workstations replace the old ones. Be sure to choose a solution that will work with your future needs as well as your current requirements. These issues, and the mechanics of setting up a network of different workstations, are covered in more detail in Chapter 5, "Purchasing Networking Hardware," and Chapter 17, "Integrating Windows NT with Heterogeneous Networks."
Perhaps as you've read this chapter, it has become clear that only one protocol fills the bill. You may be combining Macintosh and UNIX workstations and have chosen TCP/IP, so only one protocol is necessary. Or you may have an existing network that uses IPX/SPX and see no reason to change protocols.
But if you're building a network from scratch, or need to change the protocol of one of two sets of workstations and aren't sure which one to change, the following are some important issues to consider:
How big is your LAN? NetBEUI can't handle more than 200 or so workstations. Even NBF isn't the best choice for a large LAN. Are there WANs or other LANs you want to connect to? A routable protocol (TCP/IP or SPX/IPX) is vital in that case. If you're not connected to a WAN, do you plan someday to connect to the Internet (an enormous WAN running TCP/IP)? The Internet is becoming vital to many businesses for research, advertising, and customer support, and the Internet or an intranet should be included in your networking plans. What software are your users running? What protocols does it support?
This may make it sound as though TCP/IP is the one-size-fits-all solution to all your networking needs. Of course, it's not that simple. Managing a TCP/IP server and assigning IP addresses to each machine on the network aren't simple tasks. If your organization has a staff of experienced SPX/IPX administrators, their knowledge and experience are assets that might sway you to choose SPX/IPX for your Windows NT 4.0 servers. Otherwise, choose TCP/IP.
Having chosen a network transport protocol or protocols, you must get the protocol(s) installed and working, and then manage the resulting network. Not surprisingly, a large part of the rest of this book covers these tasks. The following chapters relate directly to networking protocols:
Chapter 10, "Configuring Windows 95 Clients for Networking," discusses connecting Windows 95 workstations to your server. Chapter 11, "Connecting Other PC Clients to the Network," discusses connecting DOS, Windows 3.x, Windows for Workgroups, and Macintosh workstations to your server. Part III, "Administering a Secure Network," contains chapters 12 through 15 and covers all the details of how to be a network system administrator. Part IV, "Wide Area Networking and the Internet," contains chapters 16 through 20 and covers issues such as heterogeneous networks, the Internet, and intranets. Chapter 24, "Administering Clients with System Management Server," shows you how to make your administration tasks easier.
© 1996, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.
