http://www.microsoft.com/TechNet/boes/bo/winntas/technote/protocol.htm (PC Press Internet CD, 03/1996)
| Updated: March 12,1996 |  Go To TechNet Home Page |
Network protocols are the language of network systems. Typically, different network systems use different protocols. This is because specific protocol implementations are an important part of the services different network systems and applications provide. For example, Novell® NetWare® uses a protocol called IPX/SPX. Internetworking is commonly done with TCP/IP. IBM's mainframe and minicomputer environments use the SNA DLC protocol. And Macintosh® networks use AppleTalk®. The purpose of this Technology Brief is to discuss Microsoft's open philosophy toward protocols, the resulting protocol implementations, and how the Microsoft® Windows NT™ Server operating system functions in multi-protocol environments.
Today, customers need many different network services to help them do their jobs. Users must share files and printers, access important information through powerful client-server applications, communicate through electronic mail, access mainframe and minicomputer data, dial into the network from remote locations, and access information on the Internet. Typically, customers deploy a collection of technologies to meet these different needs. NetWare and IPX/SPX might be used for file and print, UNIX® and TCP/IP for Internet access and client-server applications, DLC for host access, and AppleTalk for Macintosh networking.
Until recently, it has been very difficult for customers to integrate the operation and management of these different services, all which use different protocols. NetWare file and print servers must be managed separately from UNIX application servers which are managed separately from Internet access servers. Similarly, end users must connect to all these different servers separately and understand different interfaces to use them.
Microsoft recognizes both the benefits and difficulties associated with different protocols. To help customers deploy services and manage their networks in a multi-protocol environment, Windows NT Server has the following protocol-related characteristics:
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 may choose IPX/SPX as the sole protocol to build a local, non-routed network. If the administrator has a larger, wide-area network to manage, TCP/IP may be the protocol of choice.
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 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, 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 correctly enter the necessary client information versus having a technician enter the information at a high hourly rate.
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 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.
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 the forthcoming Windows® 95 operating system. 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 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 manually enter TCP/IP addresses 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 clearly define DHCP. It is specified in the Internet Engineering Task Force's 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, the resolution of computer names with TCP/IP addresses is still required. The Windows Internet Name Service (WINS) is designed to relieve the 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 automatically register their names with the system. As a result, mappings between node names and their TCP/IP addresses are automatically entered 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 no 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 DNS servers not running Windows NT Server, the DNS server can simply use its ability to refer a request to another DNS server and 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. For additional information on DHCP and WINS, please refer to the Microsoft white paper Dynamic Host Configuration Protocol/Windows Internet Name Service or the Microsoft Windows NT Resource Kit.
NetBIOS is an Applications Programming Interface (API) that offers a namespace service to application developers. A namespace service provides a mapping between "friendly" machine names and their network addresses. Namespace services are used by applications so they can refer to machines via friendly names instead of complex network addresses. For example, it is the namespace service that makes it possible for users to connect to a network drive simply by typing that drive's friendly name. Microsoft uses NetBIOS as the namespace service to support processes such as connecting to network drives.
NetBIOS is not tied to a particular protocol. A Windows-based desktop computer can be run a variety of different protocols, such as TCP/IP, IPX/SPX, or NetBEUI, and still be able to connect to a network drive using a friendly name. NetBIOS is a service that is implemented on different protocols by different vendors using a published, standard set of specifications. Microsoft's implementation of NetBIOS over TCP/IP is based on specifications published in the Internet Engineering Task Force's Requests For Comment (RFCs) 1001 and 1002.
Microsoft's implementation of NetBIOS over the company's new, high performance TCP/IP stack is completely routable and offers fast, reliable naming services (such as WINS) in an easy to manage TCP/IP environment. By offering NetBIOS over TCP/IP (also known as NBT), Microsoft has extended TCP/IP capability to existing NetBIOS applications. And since NetBIOS adds only a small header to each NBT frame, performance remains exceptional. An important point to note, though, is that Microsoft's TCP/IP is an independent, native TCP/IP protocol stack separate from NBT. NBT is for use by NetBIOS applications in a TCP/IP environment.
Microsoft's TCP/IP also supports other naming services such as Windows® Sockets. Supporting other services maximizes application support for Microsoft operating systems. It also provides vendors with options so they can build the most powerful and efficient network applications.
The two most important aspects of naming activities are registration and resolution. Registration is the process used to acquire a unique name for each node on the network. A computer typically registers itself when it starts. Resolution is the process used to determine the specific address for a computer name. NBT supports the following registration and resolution modes:
NetBIOS is not exclusively dependent on broadcasts or any other
name resolution method. For example, WINS is a NetBIOS based
service. In a WINS environment, the default is
h-node. Name registration and resolution are both accomplished
via a directed send to the WINS server. Broadcasts are used rarely
and only as a last resort if the WINS server is unavailable.
The role of NetBEUI is considerably different from NetBIOS. NetBEUI is a wire level protocol that was developed in 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 Windows NT Server has no dependencies on NetBEUI, and provides organizations with many different protocol options. It provides maximum flexibility for deploying network services while integrating easily into today's existing heterogeneous network environments.
© 1995 Microsoft Corporation
Microsoft and Windows are registered trademarks and Windows NT is a trademark of Microsoft Corporation.
AppleTalk and Macintosh are registered trademarks of Apple Computer, Inc. IBM is a registered trademark of International Business Machines Corporation. NetWare and Novell are registered trademarks of Novell, Inc. UNIX is a registered trademark in the United States and other countries licensed exclusively through X/Open Company, Ltd.
 |
Click Here to Search TechNet Web Contents | TechNet CD Overview | |
Microsoft TechNet Credit Card Order Form At this time we can only support electronic orders in the US and Canada. International ordering information. |
| Go To TechNet Home Page |
©1996 Microsoft Corporation |  Go To Microsoft Home Page |