http://www.microsoft.com/TechNet/boes/bo/winntas/prodfact/movetcp.htm (PC Press Internet CD, 03/1996)
PostedDate: May 8, 1995
Go To TechNet Home Page
ABSTRACT: Case Study. Microsoft Corporation's migration from the obsolete XNS protocol to TCP/IP is addressed, with emphasis on business reasons for the change and on the architectural challenges of corporate-wide implementation. Also discussed are TCP/IP's advantages, the obstacles DHCP and WINS help network administrators overcome, routing considerations, compatible third party connectivity tools, and tips for efficient migration.
The task of migrating a worldwide internet ('internet' without the capital "I" denotes a private internetwork) of over 35,000 nodes to any standard network operating system, topology, or protocol is undoubtedly complex. The Microsoft Information Technology Group (ITG), based in Redmond, Washington knows the challenges involved in ensuring that requirements on its expanding wide-area network are effectively met. Over the past two years a major effort has been underway to upgrade the Microsoft worldwide network using new, more reliable technologies. This overhaul included the implementing of FDDI local rings on its Corporate Campus and replacing LAN Manager with Windows NT Server on over 1500 servers. However, a major phase of the reconstruction is only now in motion: to migrate the corporation from an obsolete, broadcast-based protocol, XNS, to an open industry standard, routeable, reliable protocol that provides direct node-to-node connections.
Microsoft's integrated voice and data network links more than 14,000 employees around the world, allowing people on different continents to communicate and share information with each other as easily as if they were located just down the hall. By helping Microsoft employees work together efficiently despite time and distance barriers, the network ultimately reduces the time to market for Microsoft products and contributes to the company's competitive advantage. Today, Microsoft's worldwide voice and data network is used for voice communications, electronic mail, file and device sharing, and running mission-critical distributed applications, ranging from manufacturing to accounting. This document explores why and how a company might migrate to Microsoft TCP/IP and dependent services such as Dynamic Host Configurable Protocol (DHCP) and Windows Internet Protocol Service (WINS) by describing the deciding factors and processes that Microsoft used in its own migration.
The objectives of this case study are to:
Describe the business reasons for migrating to Microsoft TCP/IP, DHCP, and WINS.
Introduce specific efficiencies DHCP and WINS add to the TCP/IP wide-area network management environment.
Provide important migration information and tips to administrators who are contemplating a move to TCP/IP.
There are, of course, a number of other network transport protocols that Microsoft ITG did investigate as a potential solution. While the specific reasons for selecting TCP/IP over IPX/SPX, OSI or SNA are numerous, it is important to single out a few up front:
Open - Over 100 organizations contribute to the evolving TCP/IP protocol specifications through the Internet Engineering Task Force (IETF).
Scaleable - TCP/IP was designed for internetworking and provides the infrastructure for the two million node Internet.
Proven - TCP/IP has withstood the test of time, over a decade has passed since initial commercial products.
Inter-operable - TCP/IP is the key to heterogeneous internetworking, virtually all operating systems support it, making it a common-denominator networking protocol.
In fact, statistics from Network World and Datamation show that while TCP/IP and IPX/SPX run neck-in-neck for LAN protocol dominance, TCP/IP is clearly favored as the 'protocol of choice' on the corporate backbone. Additional reasons why companies may find TCP/IP a better protocol solution include a routeable, internetworking protocol for scaleable networks; a basis for connectivity to foreign systems such as UNIX®, VMS®, and mainframes; and because it provides a foundation for scaleable client-server application development, namely via Windows Sockets and DCE-compatible Remote Procedure Calls.
Now that the information highway is moving from a political ideal to a useable, open information resource, the reasons for moving to TCP/IP become as infinite as the information available on it. In fact, the Internet, the primary artery on the information highway, is currently growing at exponential rates. The networks in the Internet use either the TCP/IP protocol suite or the OSI protocol suite. Gateways exist that translate between the two protocols. Worldwide information from public sources, book and magazine publishers, census tracking organizations, universities, and financial, manufacturing, and technology companies abound on the Internet. Direct access to these information sources can clearly make it easier and faster for Internet users to find comprehensive information on almost any topic.
These reasons, coupled with many others, have made TCP/IP a strategic protocol direction for Microsoft both internally and technologically. However, before discussing the migration to TCP/IP, DHCP, and WINS in detail, it's necessary to examine the history of the Microsoft Corporate Network and what business needs were factors in migrating to this new protocol.
The Microsoft Corporation is the world's largest software development company with over 14,000 employees spread across 51 countries worldwide, all heavily dependent on the reliability and support of the corporate internetwork. As of today, there are over 35,000 nodes distributed among 140 subnets on the internetwork. Each subnet may support anywhere between 50 and 5,000 nodes. The largest area of node concentration is Redmond, Washington, which has over 20,000 nodes on 18 different subnets.
In 1985, Microsoft began the awesome task of connecting its countless disjointed local area networks (LANs) scattered throughout the company. At that time, the vision of total connectivity was pretty bold. "A lot of people thought it couldn't be done. But, to realize the full power of networking, we knew that we had to give every individual the ability to electronically access whomever or whatever they needed, anywhere in the company," says Dave Leinweber, Microsoft director of worldwide networks. Another critical step was the early establishment of network architecture standards, which made it possible to expand the network rapidly. For LAN topology, the company chose Ethernet, which was the most mature technology then available.
The Information Technology Group (ITG) set up each building with its own Ethernet network and then bridged them together to act as one large, flat LAN, so that a user in any building could easily access any user, file, or resource in any other building. The company also established a standard office wiring configuration, with offices connected to cable rooms via unshielded twisted pair wiring and cable rooms connected to each other via fiber-optic cable. Today, Microsoft's LANs still use Ethernet, but the company has migrated from its initial thick Ethernet to 10Base-T Ethernet. In addition, to handle the growth in network traffic, the company now uses Fiber Distributed Data Interface (FDDI) technology both to bridge Ethernet LANs together and for peer-to-peer networking. With a bandwidth of 100 megabits, FDDI can handle ten times the volume of Ethernet.
By 1988, Microsoft was becoming a strong international company. Aware of the communication difficulties created by time zone and geographical distances, the company decided to expand its LAN infrastructure to a wide area network (WAN). Its goal was to allow employees located anywhere in the world to communicate with each other and exchange information without regard for location. Microsoft created a WAN with a very flat, open design so users could easily get from their own LAN to any Microsoft location in the world. The design featured a hub-and-spoke arrangement, with the corporate campus as the primary hub, a regional hub for each broad geographical area (for example, Europe), and a national hub within each country. For physical connectivity, Microsoft used dedicated leased lines and bridge routers. By 1992, the last international subsidiary had been brought on board and Microsoft's worldwide voice and data network was fully in place.
Figure 1 The Microsoft Worldwide Network
In addition to a physical infrastructure, Microsoft has used the domain functionality of network operating systems, initially Microsoft LAN Manager, then Windows NT Advanced Server, to create a logical infrastructure. Domains provide a centralized method of administering groups of workstations and servers, thus simplifying the administrator's management tasks. For Microsoft, the concept of domains was introduced in the 1980s with Microsoft LAN Manager. However, the full benefit of single network logon access and central management of all servers regardless of location was not realized until the company moved to Windows NT Advanced Server and utilized the principle of Trust Relationships between servers in 1993.
Trust relationships are an administration and communications link between two domains. A trust relationship between two domains enables user accounts and global groups to be used in a domain other than the domain where these accounts are actually defined. Domains use established trust relationships to share account information and validate the rights and permissions of users and global groups residing in the trusted domain. Trusts, therefore, simplify administration by combining two or more domains into a single administrative unit.
There are two basic types of trust relationships, one-way and two-way. In a one-way trust relationship only one domain trusts the other. They do not both trust each other. In a two-way trust, both domains trust each other equally. This allows users to log on from either domain to the domain that contains their account. Building on these two types of trust relationships, there are four basic domain models. Each Advanced Server network, no matter how simple or how complex, originates from one of these four basic models:
Single Domain Model - A configuration where the entire network only consists of a single domain.
Master Domain Model - In this multiple domain arrangement, several domains all trust a single domain that maintains the complete set of user accounts.
Multiple Master Domain Model - In the Multiple Master domain model, there are several master account domains, each containing a subset of the user account database. A complete trust relationship between these master account domains will ensure that users may log on anywhere on the network.
Complete Trust Model - This model consists of multiple domains with each domain performing its own administration and trusting all other domains in the enterprise.
The development of a domain structure for the Microsoft worldwide network required a hybrid of two of these models: the Multiple Master Domain Model and the Complete Trust Model. ITG needed to administer all network logon IDs, passwords, and permissions and have physical proximity to the servers performing these tasks, while the user community required global access from any one computer to any other computer on the network. To accomplish this, the group developed a geographically designated, multiple-tier configuration. In this configuration, all user accounts and authentication are administered in one of many tier-1 domains. All of the servers in this tier are located on the Redmond campus for hardware and backup maintenance. All machine accounts (required for Windows NT servers and workstations) are administered in a domain on the second tier, typically located near the end-user community. Each tier-2 domain has a one-way trust relationship with a corresponding master domain where the tier-2 domain trusts the tier-1 domain. This allows resources in each geographic location, or operational or development group to be administered using the account policies determined by the tier-1 account servers. Because all of the tier-1 domains trust each other, any user on the corporate network (usually granted 'user' privileges) can access resources anywhere on the network to which user access has been granted. The following diagram depicts the hierarchical configuration of the Microsoft domains. For more information on Windows NT Advanced Server domain configurations, read the Whitepaper entitled Enterprise Planning Guide: Domains and Domain Strategies (in the Enterprise Planning Guides section of your CD).
Figure 2 The Microsoft Worldwide Domain Structure
When the LANs were independent of one another, NetBEUI was an obvious choice due to its speed and ease of administration. Not to mention that Microsoft LAN Manager, the primary server platform at the time, was optimized for NetBEUI. However, NetBEUI was not a routeable protocol, and therefore could not be considered for WAN connectivity. At the time, no real LAN-based e-mail packages were available, even from Microsoft. However, constant communication among groups was essential and Microsoft had selected Xenix e-mail servers to do the job for them. To use the mail system, most users would have to go to a VT-100 terminal for access to the system. A PC-based solution called VTP was available for PC users, but it required PC connectivity to the Xenix servers. A solution was purchased from Ungerman-Bass that was based on a proprietary transport called XNS (Xerox Networking System). Ungerman-Bass's solution provided both the network cards and the transport to get to the Xenix server and it was routeable. As a result, XNS was selected as the temporary solution until a standard, open transport protocol was available.
Actually, other transports were considered including TCP/IP. However, in the early phases of TCP, it was considered a stepping stone to a complete OSI stack that was expected within a few years. "Microsoft made the decision to skip TCP/IP and wait for the full OSI stack so as to avoid the extra costs of distribution, configuration, and administration of TCP/IP addresses," says Leslie Paup, Manager of Network Engineering for ITG. "Besides, it [XNS] was faster, required less conventional memory, and provided a turn-key solution."
As Microsoft grew, XNS proved to have a number of inherent problems that made it increasingly more expensive to use and manage. XNS is a broadcast-based protocol, meaning that when a node on the network needs to connect to another node, it will send a broadcast packet out over the net asking every other node if it is the one for which it is looking, even through a router. When working with 500 clients and 20 servers, the issue isn't that great, but when you grow to an environment in the tens-of-thousands of nodes, which in a peer-to-peer environment are all servers, the problems can be monumental and expensive. This issue moved to the forefront of ITG when the cost of leased lines kept increasing due to the need for additional bandwidth. As new offices and users came on line, the amount of bandwidth overhead could be as much as 10 percent to 15 percent; expensive just for broadcast packets.
Figure 3 Ethernet cable or Async line
In 1991, faced with the reality of an unmaterialized OSI stack, increasing telecommunication costs, and a technological commitment to TCP/IP on the development side, Microsoft's Executive Staff met with ITG management. A strategic decision was made to move away from XNS to TCP/IP. However, ITG, having thoroughly investigated the issue, made some convincing arguments against available implementations of TCP/IP:
LMHOST files in a large disparate network are unmanageable.
TCP/IP address distribution and administration causes costly resource overhead.
Current TCP/IP Stacks were slow and required too much conventional memory.
B-Node clients would still be broadcasting over the network.
Microsoft was not alone in dealing with the shortcomings of TCP/IP. Numerous LAN Manager and later Windows NT Advanced Server customers were clamoring that the investment in the protocol was much higher than any measurable return. What ITG and customers required was a smaller, faster, manageable TCP/IP environment. Consequently, Microsoft tapped the expertise of J. Allard, Program Manager for Microsoft's TCP/IP technologies and his team to develop a new and improved TCP/IP that met the requirements of large corporations, including Microsoft.
The TCP/IP protocol grew out of research done by the Defense Advanced Projects Research Agency (DARPA) in the early 1970s. In reality, TCP/IP is a suite of protocols which, when used together, make up two defining standards:
Transmission Control Protocol (TCP) - specifies the method by which two nodes on a single network communicate.
Internet Protocol (IP) - dictates how a node on one network inter-operates with a node on another.
Late in the 1980s private companies began developing an interest in using the TCP/IP protocol within their organizations to solve inter-operability problems. Today, TCP/IP has become the world's most accepted multi-vendor LAN protocol. The transport protocol suite can be broken down further into its smaller components which include the Transmission Control Protocol (TCP), Internet Protocol (IP), User Datagram Protocol (UDP), Address Resolution Protocol (ARP), and Internet Control Message Protocol (ICMP).
TCP/IP standards are defined in Requests for Comments (RFCs), which are published by the Internet Engineering Task Force (IETF) and other working groups. A member organization requiring a specific service that is not yet supported must submit an RFC to other members of the IETF. Once all members agree on the proposal, and there is a shipping product that supports it, it becomes part of the TCP/IP standard. The key RFCs supported in Microsoft TCP/IP (and for Microsoft Remote Access Service) are described in the following table.
Key Requests for Comments (RFCs) Supported by Microsoft TCP/IP
RFC Title
768 User Datagram Protocol (UDP)
783 Trivial File Transfer Protocol (TFTP)
791 Internet Protocol (IP)
792 Internet Control Message Protocol (ICMP)
793 Transmission Control Protocol (TCP)
826 Address Resolution Protocol (ARP)
854 Telnet Protocol (TELNET)
862 Echo Protocol (ECHO)
863 Discard Protocol (DISCARD)
864 Character Generator Protocol (CHARGEN)
865 Quote of the Day Protocol (QUOTE)
867 Daytime Protocol (DAYTIME)
894 IP over Ethernet
919, 922 IP Broadcast Datagrams (broadcasting with
subnets)
959 File Transfer Protocol (FTP)
1001, NetBIOS Service Protocols
1002
1034, Domain Name System (DOMAIN)
1035
1042 IP over Token Ring
1055 Transmission of IP over Serial Lines (IP-SLIP)
1112 Internet Gateway Multicast Protocol (IGMP)
1122, Host Requirements (communications and
1123 applications)
1134 Point to Point Protocol (PPP)
1144 Compressing TCP/IP Headers for Low-Speed Serial
Links
1157 Simple Network Management Protocol (SNMP)
1179 Line Printer Daemon Protocol
1188 IP over FDDI
1191 Path MTU Discovery
1201 IP over ARCNET
1231 IEEE 802.5 Token Ring MIB (MIB-II)
1332 PPP Internet Protocol Control Protocol (IPCP)
1334 PPP Authentication Protocols
1533 DHCP Options and BOOTP Vendor Extensions
1534 Inter-operation Between DHCP and BOOTP
1541 Dynamic Host Configuration Protocol (DHCP)
1542 Clarifications and Extensions for the Bootstrap
Protocol
1547 Requirements for Point to Point Protocol (PPP)
1548 Point to Point Protocol (PPP)
1549 PPP in High-level Data Link Control (HDLC)
Framing
1552 PPP Internetwork Packet Exchange Control
Protocol (IPXCP)
1553 IPX Header Compression
1570 Link Control Protocol (LCP) Extensions
Draft NetBIOS Frame Control Protocol (NBFCP); PPP over
RFCs ISDN; PPP over X.25; Compression Control
Protocol
An exhaustive, up-to-date list of all RFCs can be found on the Internet via ds.internic.net.
According to IP addressing standards, a host is any device attached to the network that uses TCP/IP. To receive and deliver packets successfully between hosts, TCP/IP relies on three pieces of information:
IP Address - Identifies a computer with a 32-bit address that is unique across a TCP/IP network. IP addresses are broken down into four decimal-delimited octets. Each octet has a maximum decimal value of 255. For example 11.103.40.86.
Subnet Mask - Much like an IP address, the subnet mask is comprised of four decimal-delimited octets. A subnet mask distinguishes the network ID portion of the IP address. So, in the example above, if a user with the IP address of 11.103.40.86 had a subnet mask of 255.255.0.0, their network ID would be 11.103. But if they had a subnet mask of 255.255.255.0, their network ID would be 11.103.86.
Default Gateway.- Otherwise known as IP routers, which understand the networks connected in their internet, Gateways are used by network nodes to find remote destination nodes (not on the same subnet). The default gateway parameter is required for computers that play a part in an internetwork.
So, to establish a new node on an internetwork, one may configure the TCP/IP parameters like this:
IP Address: 11.103.40.86
Subnet mask: 255.255.0.0
Default Gateway: 11.103.0.1
Assigning and maintaining IP address information can be an administrative burden for network administrators responsible for internetwork connections. Contributing to this burden is the problem that many users do not have the knowledge necessary to configure their own computers for internetworking and must therefore rely on their administrators. Moreover, in today's business community, a laptop computer may be taken, halfway around the world overnight. Without DHCP, that computer would have to be reassigned a new IP address, subnet mask, and default gateway.
The Dynamic Host Configuration Protocol (DHCP) was established to relieve this administrative burden. DHCP provides safe, reliable, and simple TCP/IP network configuration, ensures that address conflicts do not occur, and helps conserve the use of IP addresses through centralized management of address allocation. DHCP offers dynamic configuration of IP addresses for computers. The system administrator controls how IP addresses are assigned by specifying lease durations, which indicate how long a computer can use an assigned IP address before having to renew the lease with the DHCP server. The DHCP client and server services for Windows NT are implemented under Requests for Comments (RFCs) 1533, 1534, 1541, and 1542.
In order for a client to obtain an IP address, it must go through an interactive process on the network consisting of four states:
Initializing state - a DHCP client computer sends a discover message that is broadcast to the local network and may be relayed to all DHCP servers on the private internetwork. Each DHCP server that receives the discover message responds with an offer message containing an IP address and valid configuration information for the client that sent the request.
Selecting state - the DHCP client collects the configuration offerings from the servers. At this time, one or more DHCP servers on the internetwork can have outstanding offers for this client.
Requesting state - the client chooses one of the configurations and sends a request message that identifies the DHCP server for the selected configuration. The selected DHCP server sends a DHCP acknowledgment message that contains the address first sent during the discovery stage, plus a valid lease (length of time for which that IP address configuration is valid for that client) for the address and the TCP/IP network configuration parameters for the client.
Figure 4 DHCP client state transition during system startup
Bound state - after the client receives the acknowledgment, it enters a bound state and can now participate on the TCP/IP network and complete its system startup. Client computers that have local storage save the received address for use during subsequent system startup. As the lease approaches its expiration date, it attempts to renew its lease with the DHCP server, and is assigned a new address if the current IP address lease cannot be renewed.
Microsoft Windows NT Server has incorporated graphical utilities and troubleshooting tools to make the administration and setup of DHCP servers easy. DHCP Manager defines local policies for address allocation, leases, and other options. Now, with DHCP, network administrators no longer need to worry about visiting each machine on the network to configure their TCP/IP parameters. In fact, an administrator can establish one or more DHCP servers that maintain TCP/IP configuration information to be provided to clients that make requests. Furthermore, with DHCP enabled, when a PC moves from subnet to subnet, there is no reconfiguration needed. The client and DHCP server work together to determine a new IP address configuration valid for that subnet. For more information on DHCP, see Chapter 3, "Networking Concepts for TCP/IP" and Chapter 4, "Installing and Configuring DHCP Servers" in the manual Microsoft TCP/IP included with Microsoft Windows NT Server 3.5.
Computers use IP addresses to identify each other, but users usually find it easier to work with computer or user names. A mechanism must be available on a TCP/IP network to resolve names to IP addresses. To ensure that both name and address are unique, the Windows NT computer using TCP/IP registers its name and IP address on the network during system startup. Then, when a certain computer wants to register itself or locate another using the machine name, it must use one or more of four ways a computer on the Windows network can locate another:
WINS Servers contain a dynamic, replicable database that maps IP addresses to computer names.
WINS provides a distributed database for registering and querying dynamic computer name-to-IP address mappings in a routed network environment. If you are administering a routed network, WINS is your best first-choice for name resolution, because it is designed to solve the problems that occur with name resolution in more complex internetworks.
WINS reduces the use of local broadcasts for name resolution and allows users to easily locate systems on remote networks. Furthermore, when dynamic addressing through DHCP results in new IP addresses for computers that move between subnets, the changes are automatically updated in the WINS database. Neither the user nor the network administrator needs to make manual accommodations for name resolution in such a case.
Broadcast name resolution or queries for registration, a b-node NetBIOS over TCP/IP mode of operation where a computer makes IP-level broadcasts to register its name by announcing it on the internetwork. In query mode, the broadcast goes across the network to locate the desired host.
Domain Name System (DNS) provides a way to look up name mappings when connecting a computer to a foreign host using NetBIOS over TCP/IP or Windows Sockets. DNS employs a distributed database used by the Internet.
LMHOSTS files are text-based files containing lists of IP addresses and corresponding machine names. With Windows networking, the LMHOST file can exist either on the local machine or on a server in the network.
An internetwork that uses TCP/IP with Windows networking can include computers using Windows NT, Windows for Workgroups 3.11 (Windows 4.0 in the future), and LAN Manager as well as non-Microsoft systems. In a TCP/IP network, computer names can be resolved using any combination of WINS, name query broadcasts, the LMHOSTS file, and DNS.
WINS consists of two components: the WINS server, which handles name queries and registrations, and the client software, which queries for computer name resolution. Windows networking clients (WINS-enabled Windows NT or Windows for Workgroups 3.11 computers) can use WINS directly. Non-WINS computers on the internetwork that are b-node compatible as described in RFCs 1001 and 1002 can access WINS through proxies, which are network WINS-enabled computers that listen to name query broadcasts and then respond for names that are not on the local subnet or are p-node computers.
The following illustration shows a small internetwork, with three local area networks connected by a router. Two of the subnets include WINS name servers, which can be used by clients on both subnets. WINS-enabled computers, including proxies, access the WINS server directly, and the computers using broadcasts access the WINS server through proxies. Proxies only pass name query packets, and only verify that registrations do not duplicate existing systems in the WINS database. Proxies, however, do not register b-node systems in the WINS database.
Figure 5 Example of an internetwork with WINS servers
The proxy communicates with the WINS server to resolve names (rather than maintaining its own database) and then caches the names for a certain time. The proxy can serve as an intermediary, by either communicating with the WINS server or supplying a name-to-IP address mapping from its cache. The following illustration shows the relationships among WINS servers and clients, including proxies for non-WINS computers and the replication between WINS servers.
Figure 6 Example of clients and servers using WINS
In the preceding illustration, Client A can resolve names by first querying the WINS server and, if that fails, then using broadcast name queries. Client B, which is not WINS-enabled, can only resolve names using broadcast name queries, but when Client C receives the broadcast, it forwards the request to the WINS server and returns the address to Client B.
WINS removes many of the burdens that administrators encounter with other forms of name resolution. Broadcasts are kept to a minimum and are rarely routed outside of a clients own subnet. LMHOST files, which require extensive administrative resources to keep current, are no longer required. The result is a dynamic replicating database of IP addresses and names that allow computers to be seamlessly moved from location to location without any administrative intervention.
Remote Access Service (RAS) provides remote networking for telecommuters, mobile workers, and system administrators who monitor and manage servers at multiple branch offices. Users with RAS on a Windows NT (or Windows for Workgroups 3.11) computer can dial in and remotely access their networks for services such as file and printer sharing, electronic mail, scheduling, and SQL database access.
Windows NT RAS works with IP routing for RAS servers so that RAS clients can use TCP/IP networks. (RAS can also work with IPX routing for clients that want to use NetWare networks.) Windows NT also uses the industry-standard Point to Point Protocol (PPP) and Serial Line IP (SLIP) standards. These standards ensure that Windows NT is inter-operable with third-party remote access server and client software. RAS clients can use DNS and WINS for name resolution services.
Figure 7 Network access with RAS in Windows NT
The RAS server provides a pool of IP addresses that are allocated using DHCP for automatic configuration or reserved for static configuration during RAS installation. The IP addresses are automatically assigned to RAS clients using PPP when they dial in. If the administrator sets up the RAS server to use a static pool of addresses, each client dialing into a particular RAS server is assigned the same network ID as the RAS server plus a unique host ID. (Of course, the network administrator must also reserve that range of static addresses on the DHCP server, if present, to make sure that those addresses are not assigned.)
RAS clients can connect to multiple TCP/IP networks that are logically joined and share the same address space, even though they are physically separate) networks.. When using multiple connections, the RAS client still has the same use of DNS and WINS for name resolution.
Microsoft TCP/IP for Windows NT also includes support for Windows Sockets 1.1. The Windows Sockets API is a networking API used by programmers creating applications for both the Microsoft Windows NT and Windows operating systems.
Windows Sockets is an open standard that is part of the Microsoft Windows Open System Architecture (WOSA) initiative. It is a public specification based on Berkeley UNIX sockets, which means that UNIX applications can be quickly ported to Microsoft Windows and Windows NT. Windows Sockets provides a single standard programming interface supported by all the major vendors implementing TCP/IP for Windows systems. The Windows NT TCP/IP utilities use Windows Sockets, as do 32-bit TCP/IP applications developed by third parties. Windows NT also uses the Windows Sockets interface to support Services for Macintosh and IPX/SPX in NWLink. Under Windows NT, 16-bit Windows-based applications created under the Windows Sockets standard will run without modification or recompilation. Most TCP/IP users will use programs that comply with the Windows Sockets standard, such as ftp or telnet or third-party applications.
The Windows Sockets standard allows a developer to create an application with a single common interface and a single executable that can run over many of the TCP/IP implementations provided by vendors. The goals for Windows Sockets are the following:
Provide a familiar networking API to programmers using Windows NT, Windows for Workgroups, or UNIX.
Offer binary compatibility among vendors for heterogeneous Windows-based TCP/IP stacks and utilities.
Support both connection-oriented and connectionless protocols.
Typical Windows Sockets applications include graphic connectivity utilities (for example, to the Internet), terminal emulation software, Simple Mail Transfer Protocol (SMTP) and electronic mail clients, network printing utilities, SQL client applications, and corporate client-server applications.
Microsoft TCP/IP has paved the way for many organizations to adopt a truly open, scaleable, standards-based transport protocol. DHCP and WINS have alleviated many of the administrative obstacles that once stood in the way of moving to TCP/IP on corporate networks. With DHCP and WINS, from a single Windows NT Advanced Server box, an operator can successfully setup, administer, and troubleshoot literally every node on the internet. This new functionality has come about as a result of extensive efforts by the TCP/IP development team, by working with the IETF and other standards committees, and by listening to our customers.
The key to the success of any project is to establish clear requirements, objectives, criteria for success, and a fool-proof plan. When ITG's Network Engineering Group (NEG) was chartered with architecting the worldwide migration from XNS to TCP/IP, it was essential that each of these elements be well thought out. To ensure the success of the project, Les Paup, manager of NEG, brought the required expertise on board by hiring Krishnan Parameshwaran to lead the testing and roll-out team. This section will describe much of the work that Les, Krishnan, and their group have done to prepare for the implementation of TCP/IP on the Microsoft worldwide network.
It was essential that NEG have a qualified list of requirements for the worldwide network prior to any testing or pilots of TCP/IP. To this end, specific prerequisites were compiled encompassing client support, inter-operability with existing non-Microsoft systems, hardware support (including routers, switches, and servers), and network monitoring software. For migration purposes, it was necessary to install Windows NT Advanced Server 3.5 servers running both DHCP and WINS ("Rhino" Servers). The servers had to be able to dynamically discover servers running TCP/IP that were not Rhino Servers. This would allow ITG to isolate those servers that would later need to be upgraded. While the group does not expect to completely upgrade all of the servers on the Microsoft internet, its goal is to know about all of them.
NEG determined that, for total TCP/IP connectivity, the company would require client support for:
MS-DOS® with LAN Manager and/or Windows 3.1
MS-DOS® with Windows for Workgroups 3.1 and 3.11
Windows 95
Windows NT
OS/2 with LAN Manager
Interoperability among new Rhino servers and existing Windows NT servers as well as non-Microsoft systems was also an essential part of the project plan. Microsoft currently runs a number of mission-critical accounting and order entry systems on AS/400s. Decision support and executive personnel use information downloaded from these systems daily to determine market penetration, strategy, and pricing techniques. In order for the company to function normally, it is essential that these processes continue uninterrupted.
The Microsoft WAN relies heavily on routers between campus buildings, metropolitan Seattle locations, and national and international sites. It was therefore determined that router support and software compatibility was a must. NEG enlisted the early help of our router vendors to ensure that their hardware and software would support the necessary RFCs that DHCP and WINS would require. Additionally, it was determined that support for SNMP would be essential given that ITG uses NetView and other SNMP utilities to administer and troubleshoot the WAN.
Once NEG had a complete set of the router vendors's requirements and were assured that they could be adequately met, they moved to the second phase of the project: determining the TCP/IP architecture.
In reviewing the geographic and physical network infrastructure of the company, NEG came up with a plan to segment TCP/IP into logical subnets on the WAN. In addition, NEG worked to determine the appropriate Rhino server configuration among the subnets to reduce the amount of b-node broadcasts across routers. This subnet configuration follows closely the physical structure of the internetwork. A single IP subnet would serve as the backbone. Off the backbone, each physical subnet would maintain a separate IP subnet address.
Figure 8 Redmond metropolitan area network - Logical IL Layout
A single Rhino server would be installed on each subnet. Because Rhino servers can be administered remotely from any DHCP or WINS console, the physical location of the servers were not an issue. In this configuration, each Rhino server would function as the DHCP server with a defined number of IP addresses, with a specific subnet mask, and defined as the default gateway. The same box would also play the part of a WINS server, responding to name-to-address resolution requests from all other nodes on its subnet. By defining each WINS server as a 'partner' of a central server, NEG ensured that each WINS database would contain addresses for every node on the WAN.
Once a logical physical configuration was established, the Network Engineer Group began testing various aspects of the configurations, software, hardware, and inter-operability.
Considering that most of the software being used to configure TCP/IP was only in early beta, deployment was to begin with preliminary functionality testing of machines in an isolated lab. NEG developed a detailed list of each component and functional code that needed to be tested. The test team then configured two Rhino servers and three clients to begin the testing. Using a detailed project plan, the team was able to test each scenario and determine which requirements were being met and which required additional work. The test team worked very closely with the development team to iron out all of the issues encountered during isolated testing. Once the team had determined that its needs could be met and development supplied a stable version of the code, controlled pilots were deployed.
Three units were determined to be test pilots sites for the new Rhino server and client stacks. With an 'eat-your-own-dog-food' attitude, the NT group and the NEG group were the first to use the product in a quasi-production environment. In this first pilot phase, the main objectives were to ascertain the stability and performance of both the client and server components. In addition, tests were run to determine the ability of the Rhino server to dynamically discover non-Rhino servers running TCP/IP on the same subnet. Later, a small group in the Munich subsidiary was enlisted to do additional testing. In this phase each pilot group setup and administered their own Rhino servers. Towards the end of this first phase, ITG overtook the administration of all Rhino servers.
As the software became more and more stable and additional functionality was added to make internetwork administration easier, NEG move to its second phase of testing that expanded the pilots to include all of ITGs Worldwide Operations group. The specific goals of the group in this phase included:
Tuning the Rhino servers and client configurations for maximum efficiency.
Determining issues concerning interaction with the Windows NT Domain Model.
Ascertaining appropriate architecture balances for WINS on the WAN.
It was also during this phase that ITG training documentation and courses were implemented to bring all of ITG up to speed on the new environment.
In the third pilot phase, all other groups within ITG were upgraded to Rhino servers. However, a new method for upgrading servers and clients was also being tested using Microsoft Systems Management Server (SMS), which runs on Windows NT Advanced Server. SMS combines four functional operations:
Hardware and software inventory
Software distribution
Helpdesk troubleshooting
Server-based software license administration
With the use of SMS to do software upgrades, existing servers could be upgraded to Windows NT Server 3.5 and Rhino without requiring an administrator to physically visit the server. Moreover, upgrade packages could be distributed to each client so that on boot the client would be upgraded to the appropriate new TCP/IP stack. See the following section on SMS for more details. This phase was also used to tweak the architectural design of the Rhino servers on the WAN.
A key enabling technology of the Microsoft migration to TCP/IP was the use of System Management Servers (SMS). The use of SMS effectively eliminated the requirement for additional temporary staff to install and configure Windows NT Advanced Server 3.5, DHCP, and WINS. In addition, it helped to reduce the time required to perform the migration and made the client-side installation safer and easier for end-users. For this reason, it is appropriate to provide a brief overview of how SMS works.
SMS is a system management environment for corporate networks, which are composed of one or more LANs. SMS can manage remote computers across Microsoft Remote Access Service (X.25 and AsyncBEUI), Microsoft SNA Server (SNA LU 6.2), and supported Microsoft Windows NT protocols (such as NetBEUI, TCP/IP, IPX).
SMS enables you to centrally manage your entire enterprise. Using SMS you can distribute and install software to workstations and servers across your corporate network, set up network applications, automatically collect and maintain hardware and software inventory, and monitor your network.
SMS works with your existing networked environment to provide a complete resource management solution. SMS can work on many different networked environments such as Windows NT, Novell NetWare 3.x, Macintosh clients and/or a combination of environments. It's a very flexible system - you can implement SMS to fit your management, organizational, and/or functional requirements.
SMS lets you organize your existing enterprise structure into logical groupings of machines and domains called sites. Sites usually reflect the physical layout of the network. For example, a company with offices in Seattle, San Francisco, and Los Angeles would probably create three sites, one for each office.
Sites can be arranged into a hierarchy to reflect the management of your corporate network. From the top most site (Central Site) you can centrally administer your entire network. Sites can be arranged so that sites without administrators can be managed by sites with administrators.
Inventory Management
SMS automatically collects and maintains hardware and software inventory for your entire enterprise. Inventory is collected at each site and forwarded to the site above it in the site hierarchy. The database at the Central Site contains inventory information for the entire system. Using the SMS Administrator tool from the Central Site, you can view the inventory for any computer at any site in your SMS system.
You can execute queries against the SMS inventory to gather information you need. You can quickly view information about computers on your network (such as available disk space, processor type, operating system, installed software, etc.) to ensure that the computers where you install software meet the software installation requirements.
Software Management
SMS enables you to distribute and install software on workstations and servers. Using the SMS Administrator tool you can install software directly on a workstation or on a server for shared-application use
When you distribute software to a site, the software is distributed to designated servers at sites called distribution servers. From these distribution servers, users can manually access and install the software onto their workstations or they can specify additional commands to automatically run or install the software on the workstations.
When you set up a network application for shared use by groups of users, you distribute software to the servers you want users to access network applications from. You also specify which groups of users have access to this network application. When you set up the network application, the program item for the software program is automatically set up on the users's workstations. When users click on the application, the network application is run off of that server.
You can specify scheduling times for distributing software to maximize the efficiency of your system.
Diagnostics
SMS provides several features for monitoring the status of your system:
Alerts - You can define alerts to detect specific conditions on your system and the actions that should be taken if the alert occurs.
Events - SMS automatically monitors SMS system information, errors, and warnings and logs them into both the site database and the Windows NT event log. You can also define alerts to generate specific events.
Remote Control - SMS provides the HelpDesk and Diagnostics utilities that allow you to directly control and monitor remote workstations running MS-DOS, Windows 3.1, and Windows for Workgroups. The Diagnostics utilities enable you to view the workstation's current configuration. The HelpDesk utilities provide direct access to a workstation. SMS supports remote control across a RAS connection and across IPX and IP routed networks.
Network Monitor - SMS also provides a powerful diagnostic component that enables you to monitor and identify problem areas of your network and appropriately tune the performance. You can also use the Network Monitor on remote computers.
The use of SMS and other network management tools for Windows NT has made the setup of the Microsoft worldwide network more efficient and less costly, and has increased the ability of ITG staff to diagnose and preempt potential bottlenecks.
When TCP/IP is used as a transport protocol, computers can communicate with other kinds of systems without additional networking software. Microsoft TCP/IP in combination with other parts of Windows NT provides a scaleable solution for enterprise networks that includes a mix of system types and software on many platforms. This section will summarize how TCP/IP works with Windows NT to provide enterprise networking solutions.
Microsoft TCP/IP provides Windows networking with a set of transport protocols based on open standards. TCP/IP delivers a scaleable internetworking technology widely supported by hardware and software vendors. When TCP/IP is used as the enterprise networking protocol, the Windows networking solutions from Microsoft can be used on an existing internetwork. Each of these solutions uses a transport-independent architecture to provide client and server support for TCP/IP and connectivity utilities. These solutions include:
Microsoft Windows NT Workstation 3.5, with enhancements for wide area network (WAN) support, extended LMHOSTS support, Windows Sockets support, and DHCP and WINS client software.
Microsoft Windows NT Advanced Server Workstation 3.5, including FTP Server service software plus DHCP server and WINS server software to support implementation of these new protocols.
Microsoft Windows for Workgroups 3.11, with Windows Sockets support. Microsoft TCP/IP-32 for Windows for Workgroups can be used in larger networks to provide access for Windows for Workgroups computers through TCP/IP to Windows NT, LAN Manager, and other TCP/IP systems.
Microsoft LAN Manager, including both client and server, support for Windows Sockets, and MS-DOS-based connectivity utilities.
The current version of TCP/IP for Windows NT also supports IP routing in systems with multiple network adapters attached to separate physical networks (multi-homed systems).
Microsoft TCP/IP for Windows NT includes many common connectivity applications such as ftp, rsh, and telnet that support file transfer, remote process execution, and terminal emulation for communication on the Internet and between foreign systems. Other TCP/IP applications created by researchers and other users, such as Gopher and NCSA Mosaic, are in the public domain or are available through other vendors as both 16-bit and 32-bit Windows-based applications. Any of these applications that follow the Windows Sockets standard are compatible with Windows NT. Such applications allow a Windows NT computer to act as a powerful Internet client while using only basic networking components and public-domain viewers and applications to access Internet resources.
Figure 10 Microsoft TCP/IP connectivity
Because most modern operating systems (in addition to Windows NT) support TCP/IP protocols, an internetwork with mixed system types can share information using simple networking applications and utilities. With TCP/IP as a connectivity protocol, Windows NT can communicate with many foreign systems, including:
Internet hosts
UNIX® systems
Apple® Macintosh® systems
VMS® systems
Printers with network adapters connected directly to the network
Microsoft TCP/IP provides a framework for inter-operable heterogeneous networking. The modular architecture of Windows NT networking contributes to the strength of this framework. For example, Windows NT supports these transport protocols, among many others:
NetBEUI as the protocol for fast local area networking
IPX/SPX for NetWare users, through the Windows NT NWLink product
AppleTalk, through the Windows NT Advanced Server feature called Services for Macintosh.
TCP/IP for internetworks based on IP technologies
Other transport protocols provided by third-party vendors, such as DECnet and OSI, can also be used by Windows NT networking services. Windows NT provides standard network programming interfaces through the Windows Sockets, RPC, and NetBIOS interfaces. Developers can take advantage of this heterogeneous client-server platform to create applications that will run on any system in the enterprise. An example of such a service is Microsoft SQL Server, which uses Windows Sockets to provide access to NetWare, MS-DOS-based, Windows NT, and UNIX clients.
TCP/IP is a common denominator for heterogeneous networking, and Windows Sockets is a standard used by applications developers. Together they provide a framework for cross-platform client-server development. TCP/IP-aware applications from vendors that comply with the Windows Sockets standards can run over virtually any TCP/IP implementation.
The Windows Sockets standard ensures compatibility with Windows-based TCP/IP utilities developed by more than 30 vendors. This includes third-party applications for the X Window System, sophisticated terminal emulation software, NFS (client and server), electronic mail packages, and more. Because Windows NT offers compatibility with 16-bit Windows Sockets, applications created for Windows 3.x Windows Sockets will run over Windows NT without modification or recompilation.
For example, third-party applications for X Window provide strong connectivity solutions by means of X Window servers, database servers, and terminal emulation. With such applications, a Windows NT computer can work as an X Window server platform while retaining compatibility with applications created for Windows NT, Windows 3.1, and MS-DOS® on the same system. Other third-party software includes X Window client libraries for Windows NT, which allow developers to write X Window client applications on Windows NT that can be run and displayed remotely on X Window server systems.
Many organizations use hardware or software routers to connect one subnet to another. If you are considering migrating to TCP/IP and you use IP routers, it is important that you verify support for the IETF RFCs 1533, 1534, 1541, and 1542. These RFCs specify the use of DHCP and its extensions. A number of router companies including Cisco, Wellfleet, Proteon, 3Com, and Ungerman-Bass have announced support for these RFCs. You should contact your router vendor(s) to determine their support for DHCP.
At Microsoft, the migration to TCP/IP, DCHP, and WINS continues. In December 1994 more than 10,000 Redmond machines were running TCP/IP and worldwide migration to the protocol surpassed 20,000. "Realistically we planned to have most of the worldwide network converted by late 1994," said Krishnan Parameshwaran, who lead the migration team for ITG. "This is not something you can expect to happen overnight." Nonetheless, benefits are being seen from both the end user community and from ITG. The major returns on investment can be categorized in three areas:
Addition of an open, scaleable, robust transport protocol with access to the Internet.
Use of management tools to reduce typical administrative overhead in moving to TCP/IP.
Ability to use and develop cross-platform distributed applications on TCP/IP such as Windows Sockets and SMTP.
The administrative power of Windows NT Server with the use of trusted domains, SNMP agents, and other third-party tools has increased the efficiencies of the corporate network drastically. With the addition of the DHCP and WINS services to configure and manage IP addresses and name resolution, a move to Windows NT Server becomes even more logical.
As a supported, open standard TCP/IP has fast become the worldwide internetworking protocol standard. The ability to connect to information sources and users throughout the globe is yet another step in realizing the Microsoft vision of 'Information at your fingertips.' With the introduction of this new IP stack and server management tools, Microsoft is quickly establishing itself as a leader in the TCP/IP industry. It is our goal to make internetwork management and access to information regardless of location and source a reality in network computing.
For more information about Microsoft products and Solution Providers, in the United States call Microsoft Inside Sales at (800) 227-4679. In Canada, call the Microsoft Canada Customer Support Centre at (800) 563-9048. If you require Text Telephone (TT/TDD) services for people who are deaf or hard of hearing, call (800) 892-5234 in the United States and (416) 568-9641 in Canada. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. Or you can access Microsoft's FTP server on the Internet thru ftp.microsoft.com.
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.
Microsoft and MS-DOS are registered trademarks and LAN Manager, Windows and Windows NT are trademarks of Microsoft Corporation.
Novell and Netware are registered trademarks of Novell, Inc.
IBM is a registered trademark of International Business Machines, Corp.
XNS is a trademark of Xerox Corp.
DECNet is a trademark of Digital Equipment Corp.
UNIX is a registered trademark of UNIX SYSTEMS Laboratories.
VMS is a registered trademark of Digital Equipment Corporation.
Macintosh is a registered trademark of Apple Computer Corporation.
©1994 Microsoft Corporation. All rights reserved.
Go To Microsoft Home Page