Windows NT Server Protocol Overview

(Applicable to Win 95)

 

Since Windows NT Server works with numerous protocols, network administrators can choose the protocols they need to support the connectivity and services they require. This array of choices also makes it easier for administrators to minimize the number of different protocols they must support and manage. For example, some administrators would prefer to manage only one protocol. From a functionality perspective, an administrator might choose IPX/SPX as the sole protocol around which to build a local, non-routed network. If the administrator has a larger, wide-area network to manage, TCP/IP might be the protocol of choice.

IPX/SPX: A High-Performance Default Protocol for Local Area Networking

Novell has had great success with NetWare. Since the early 1980s, NetWare has been extremely popular with organizations needing to share files and printers among their users. As a result, Novell’s IPX/SPX protocol is present in many organizations today and is an excellent, high-performance protocol for local area networking. IPX/SPX, therefore, is Windows NT Server’s default protocol choice for local area networking. Of course, NetBEUI is included for compatibility with existing NetBEUI-based networks such as Microsoft LAN Manager. Similarly, AppleTalk is included with Windows NT Server to guarantee Macintosh connectivity. But since it has the best balance of capability and ease of use, IPX/SPX is Microsoft’s recommended protocol for local area networking.

TCP/IP: Gaining the Benefits and Easing the Management

TCP/IP is a long tested, preferred protocol, particularly for wide area networking. Its routability, scaleable architecture, reliable delivery, and global use have made TCP/IP a necessity for any customer wishing to build wide area networks or access worldwide information networks such as the Internet. It is, however, inherently difficult to use and manage. Each computer running TCP/IP must have specific information to uniquely identify itself, the network that it is a member of, and the location for packets not bound for computers on the local network. This information is referred to as the TCP/IP address, subnet mask, and default gateway, respectively. Each of these addresses consists of a 32-bit number usually represented in dotted decimal format. For example, in a typical TCP/IP configuration, the TCP/IP address might be 101.200.42.101, the subnet mask 255.255.0.0, and the default gateway 101.200.42.1.

Such requirements can create serious administrative difficulties in large network environments. For example, suppose a department orders a new computer and it comes preinstalled with all of the necessary software and hardware to connect to the corporate network. However, the computer cannot be attached to the network, nor can it access any TCP/IP-based network resources until the network administrator provides the necessary client information. Furthermore, either a person from the "helpdesk" needs to physically go to the computer to enter the appropriate information or the user needs to dig through documentation and figure out how to do it himself. The key factor here is the ability of the user to enter the necessary client information correctly versus having a technician enter the information at a high hourly rate.

Accessing Network Resources

Complex TCP/IP addresses are not only difficult to manage, they are difficult to use. If a user needs to access information located on a network node other than his own, the user typically refers to that computer by its name, not its TCP/IP address. This is because a computer name, like "FINANCE", is much easier to use than a complex TCP/IP address. When the user refers to this name, the system then accesses a host table that contains a mapping between the computer’s name and it’s TCP/IP address.

The difficulty of the host table lies in its administration. It is a static document that requires manual maintenance and updates each time network nodes are added or moved. For typical clients using services such as Network File System (NFS), the host table resides on local computers. This means that either the users need to know enough about host files and TCP/IP addresses to update the host table information themselves or the administrator needs to maintain the information on a server and periodically download the updated file to the client machines.

Some organizations implement the Domain Name System (DNS). DNS keeps the host table on a server. Users only need to specify the address of the DNS server on their local machine. However, DNS does not alleviate the need to update the host table information manually. Although DNS is server-based, it is not dynamic and must be manually updated whenever a computer name or TCP/IP address is changed.

Solving the TCP/IP Problem: A 32-Bit TCP/IP, DHCP and WINS

To address the difficulties of managing TCP/IP networks, Microsoft includes several new TCP/IP technologies in it’s operating system products. The first of these is a new, 32-bit TCP/IP protocol stack that is available with Windows NT Server, Windows NT Workstation, Windows® for Workgroups, and Windows® 95. This new TCP/IP stack was built from the ground up as a fully native, virtual device driver implementation of TCP/IP. It is a high performance stack that consumes no conventional memory and performs well in both local and wide area networking configurations. As with other fully native TCP/IP implementations, it is completely routable.

Another powerful new technology we’ve added is the Dynamic Host Configuration Protocol (DHCP). DHCP allows for the automatic assignment of a TCP/IP address, subnet mask, and default gateway each time a network node is added or moved. Administrators simply specify a pool (or scope) of TCP/IP addresses on a Windows NT Server-based machine. That server machine then "leases" one of its available TCP/IP addresses to client machines and other servers when those machines connect to the network. Leasing eliminates the need for administrators or users to enter TCP/IP addresses manually at each node location and eliminates the possibility of address duplication and entry errors. Of course, administrators have the option to statically assign a specific TCP/IP address to a specific node if necessary. Microsoft has worked very closely with other vendors to define DHCP clearly. It is specified in the Internet Engineering Task Force’s Request For Comment (RFC)documents 1533, 1534, 1541, and 1542. Therefore, any vendor can implement DHCP and have it interoperate with Microsoft’s TCP/IP technologies.

Of course, reliable, automatic assignment of TCP/IP addresses to network nodes only solves half the TCP/IP management challenge. Since users still prefer to use "friendly" names to refer to computers on their networks, resolving computer names with TCP/IP addresses is still required. The Windows Internet Name Service (WINS) is designed to relieve administrators of host table maintenance. WINS allows WINS-aware network nodes, such as computers running Windows for Workgroups, Windows NT Workstation, Windows NT Server, or Windows 95, to register their names with the system automatically. As a result, mappings between node names and their TCP/IP addresses are entered automatically and maintained in a central WINS database. Host tables are no longer required and name/address resolution is performed automatically by the WINS server. In addition, WINS relies on point-to-point communications between network nodes and the WINS server so there are reduced numbers of broadcasts associated with WINS name registration and resolution.

One of the most powerful features of Windows NT Server-based name resolution is that it supports many name resolution techniques. For example, Windows NT Server supports both WINS and DNS. This means that non-WINS clients using DNS today for name resolution can continue to use DNS in a WINS environment. As a matter of fact, Microsoft offers DNS server extensions for WINS that allow a Windows NT Server-based DNS server to refer a name resolution request to a WINS server if the DNS server cannot resolve a name. For a DNS server not running Windows NT Server, the DNS server can simply refer that request to a Windows NT Server-based DNS server. This allows the administrator to configure the most efficient name resolution scheme possible with the least amount of management overhead. And if server-based name resolution is simply more than a site requires, HOST and LMHOST files can still be used in a Microsoft networking environment. The bottom line is that a network based on Microsoft technology can be configured to provide whatever name resolution scheme works best for that organization.

NetBEUI: Limitations Greater Than Benefit

The role of NetBEUI is considerably different from NetBIOS. NetBEUI is a wire level protocol that was developed in the early days of local area networking. As a result, NetBEUI has some limitations. For example, while it is a small and fast protocol, NetBEUI achieves performance at the expense of function. NetBEUI lacks the frame size to support routing information, greatly limiting its effectiveness within an organization. For these reasons, many organizations are eliminating NetBEUI on their networks.

Microsoft has no dependencies on NetBEUI, and provides organizations with many different protocol options. Windows NT Server provides maximum flexibility for deploying network services while integrating easily into today’s existing heterogeneous network environments.

Date last updated: 12/04/04