Wide-Area windows Networking
Are NT and Windows for Workgroups truly LAN-savvy?

The networking that's built into Windows NT and Windows for Workgroups enables machines to share each other's files, printers, and clipboards on a LAN. This set of features, which Microsoft refers to as Windows networking, comes in very handy. (Cynics might prefer the term Windows and OS/2 networking since Microsoft has to date shipped more OS/2-based networks than Windows-based ones.)

A WFW or NT user on BYTE's Ethernet LAN can, for example, browse for and then connect to a shared directory on my Silicon Graphics Mips R4400-based Magnum running NT; a shared printer that's attached to my Everex 486DX2/50. also running NT; or a shared clipboard item on my WFW machine. Windows networks also interoperate with LAN Manager and LAN Server networks.

What Windows networks don't do by default, however, is talk to other Windows networks. Can Windows networks be WANs (wide-area networks)? That's a fascinating question that Microsoft is now trying to answer in several different ways.

Windows networking belongs to a larger family of networking products that use two protocols--NetBIOS and SMB to enable workstations to communicate with each other and with servers. NetBIOS provides both connection-oriented services (ie., sessions) and connectionless services (ie., datagrams or messages); SMB provides a higher level of service that workstations use to for example, connect to servers, open and read files, lock records, and queue print jobs.

Endless confusion surrounds NetBIOS. You often hear people say that Widows networking, or other SMB/NetBIOS based network products, can't run on WANs because NetBIOS "isn't a routable protocol." That's a red herring. NetBIOS is not a transport protocol, so it makes no sense to say that it can or cannot be routed through an internetwork. The NetBIOS protocol instead serves as an interface to a transport protocol, and it' s that transport that might or might not be routable.

The default transport for LAN Manager, LAN Server, and Windows networking is NetBEUI, a purely LAN-oriented protocol that is, in fact, unroutable. You can build campus-size NetBEUI networks (like Microsoft' s) using bridges, but you can't build global NetBEUI networks using routers.

So how does your Windows client in Canada talk to your Windows server in Sweden? Microsoft took the first step with LAN Manager 2. 1 . That product provided TCP/IP as an alternate NetBIOS substrate. TCP/IP, which is the foundation of the worldwide Internet, is eminently routable and well supported by vendors of WAN communications gear. It has also been anointed as Microsoft' s "strategic" networking protocol. But there' s more to NetBIOS-over-TCP than meets the eye.

B-nodes, P-nodes, and M-Nodes

A :pair of Internet RFCs (requests for comment) numbered 1001 and 1002 propose standards for NetBIOS- over-TCP networking. In the LAN Manager implementation, which carries forward to NT, workstations are b-modes (broadcast nodes). A NetBIOS-over-NetBEUI station calls a session partner by broadcasting to all nodes on the local network. A NetBIOS-over-TCP b-node works the same way, using UDP (User Datagram Protocol) to effect the broadcast.

But TCP/IP broadcasts don't cross routers; if they did, all that extra traffic would bring the Internet to a screeching halt. The RFC 1001/1002 documents therefore define a completely different scheme for wide-area NetBIOS-over-TCP. P-nodes (point-to-point nodes) use directed UDP datagrams and TCP sessions to emulate NetBIOS-:l multicast and broadcast services. M-nodes (mixed nodes), a further refinement, combine the convenience of broadcasting on the local network with the efficiency point-to-point communication across the WAN.

How do p-nodes and m-nodes establish off-LAN conditions? They rely on a pair of services called the NetBIOS Name Server, or NBNS, and the NetBIOS Data-@n Distribution Server, or NBDD. These agents learn L cache mapping's between NetBIOS names and IP Addresses, and they intelligently manage naming (ie Registration, discovery, and defence) and massaging (ie multicast and broadcast). A commercial implementation of NBNS/NBDD from Network Telesystems is in use today at some very large NetBIOS-over-TCP sites.

Do the LAN Manager and NT implementations of NetBIOS- over-TCP use p-node and m-node technology coupled with NBNS/NBDD services? No. They rely instead on a table of NetBIOS-name/IP-address mapping's (the LMHOSTS file) stored on each participating workstation. Microsoft calls this technique a modified b-node approach.

To make things more concrete, see the figure "Alternative Windows Networking Scenarios" below. In the first part, "Local TCP/IP," my two NT machines act as b-nodes, sharing files, printers, and clipboards using TCP/IP alone (there is no NetBEUI present); they can also telnet to Bytepb, BYTE' s UUCP host. In the second part of the figure, "Routed TCP/IP," I've split the network in two. The router is Everex, which uses the basic IP routing capability of NT to join the 192. 1 .2 and 192.1. 1 class-C networks.

Because Everex's Windows networking is configured on the 192. 1 .1 .84 adapter but not the 192.1 .2.1 adapter (NT supports Windows networking over just one TCP/IP interface at a time), Magnum and Everex cannot by default share each other' s files, printers, and clipboards. NT's internal IP router stands between them. To enable Windows networking across the router, I had to add the line EVEREX 192.1.1.84 to Magnum's LMHOSTS file and also add the line MAGMUM 192.1.2.2 to Everex's LMHOSTS file. (I also had to configure Magnum's default IP gateway to be 192 .1.2.1.) Then everything worked--except browsing. In the local TCP/IP case, Magnum and Everex could browse each other's shared resources, but in the routed TCP/IP case they couldn't. With an LMHOSTS reference to Everex, Magnum could NET USE a known share c drive on Everex but couldn' t browse (or NET VIEW) Everex to discover what resources it was sharing.

Why not? Workgroup browsing requires broadcasting, which is, as we've seen, strictly local in TCP/IP. According to J. Allard, Microsoft's program manager for TCP/IP technology and the author of a document on NT's TCP/IP (available by ftp from rhino.microsoft.com), browsing does work with in NT Advanced Server domains that span TCP/IP subnetworks. It works because browse masters on each subnetwork communicate with a domain's primary controller using directed, point-to-point links (which, however, must be described in LMHOSTS files). Workstations, in turn, query local browse masters for share information.

What about TCP/IP support in the new WFW 3. 1 1 ? Although the product will probably have shipped by the time you read this, its much-anticipated 32-bit NDIS 3.0 TCP/IP stack isn't yet ready. Microsoft says you'll be able to use a (separately available) real-mode NDIS 2.0 TCP/IP stack as the sole substrate for Windows networking on WFW 3. 1 1 , but I haven't had a chance to try that yet.

The IPX/SPX Option for NT and WFW

I repeated these experiments using NT's NetBIOS-over-IPX. In the Third part of the figure, "Local IPX," Magnum and Everex conduct mutual Windows networking on lPX network 1, which also reaches Ourtown, a NetWare server, ann the rest of BYTE' s editorial LAN. In the fourth part of the figure, "Routed IPX," Magnum shares IPX network 666 with a stand-alone NetWare router that's also joined to IPX network 1

Windows networking between Magnum and Everex was instant and fully functional, requiring no administrative intervention as in the routed TCP/IP scenario. Further, because IPX propagates broadcasts through routers, Magnum and Everex could browse off-LAN to locate each other' s shares. The same situation prevailed when I rebooted Everex to DOS and launched the, beta version of WFW 3.1 1 . Its IPX transport can substitute for I NetBEUI as the sole substrate for Windows networking. Both IP)6( and NetBEUI can now run as j2-bit VxDs (virtual device drivers) in WFW 3. 11 ,incidentally.

Other new VxD components include a selection of NDIS 3.0 network adapter drivers and a VxD-based FAT (file allocation table) file-system driver. This accumulation of VxD components makes WFW 3.11 an intriguing preview of the forthcoming lightweight 32-bit version of Windows known as Chicago. Of particular note is the fact that the NDIS 3.0 drivers for both WFW 3 . 1 1 and NT are built from common sources, according to Microsoft. This sharing of driver code will be a key synergy between Chicago and NT.

Which Strategic Protocol?

Let's recap. TCP/IP, Microsoft's strategic networking protocol, enables wide-area Windows networking, but the current implementation leaves a lot to be desired. Due to the lack of a dynamic NetBIOS Name Server, the mapping of NetBIOS names to IP addresses requires cumbersome manual maintenance of LMHOSTS files. That's the sort of Labor-intensive, error-prone activity that network administrators desperately want to avoid. (LAN Manager 2.2 introduced a stopgap measure--TCP/IP extensions that enable broadcast domains to span selected subnetworks-but it doesn't carry forward to NT.)

Even with correct LMHOSTS mapping's, Workgroup browsing can't cross subnetworks. And while TCP/IP comes with NT, it won't be bundled with the most advanced version of DOS-based Windows, WFW 3 . 1 1 .

IPX/SPX looks pretty attractive by comparison. It works seamlessly on routed IPX networks. and it is bundled with both NT and WFW 3. 1 1 . Moreover, IPX/SPX can simultaneously handle both Windows-to-Windows and Windows-to-NetWare connectivity.

When IPX/SPX appeared late in the development of NT under the name NWLink, the absence of a NetWare redirector for NT (which is now, by the way, available in beta) made NWLink's role unclear to many people. Microsoft's own marketing pitch tended to focus on NWLink's ability to integrate SQL Server into NetWare environments. In reality, it's a fully functional Windows networking protocol. If you operate a routed IPX internetwork, you can do local- and wide-area Windows networking using NWLink.

Given these options, you might wonder which routable protocol complements NetBEUI on Microsoft's own worldwide Windows network. Amazingly, it's a protocol that Microsoft doesn't offer to its customers. The folks in Redmond connect to Microsoft's satellite offices using XNS (Xerox Network Services), an older protocol from which IPX/SPX inherited its routable properties. The anointed wide-area Windows protocol, TCP/IP, can't yet support Microsoft's own mission-critical wide-area networking. If Microsoft doesn't use it, should you?

Whats in a Name?

While this all looks mighty suspicious, Microsoft's Allard is candid about the situation. "XNS solved a problem for us years ago and became entrenched here," he says, "but that doesn't mean it's the right solution for us or our customers." Microsoft is now developing an NBNS-like service called WINS (Windows Intemet Name Service) that is, as Allard points out, a requirement for efficient use of any routable protocol on WANs.

NetBIOS is a dynamic, distributed name service that works well when bandwidth is essentially free. But LANs and WANs are polar opposites in this regard. Propagating broadcasts through routers can work, but Microsoft pays dearly in tariffs for its extravagant worldwide use of XNS. Users of IPX/SPX WANs can control those tariffs only to the extent that administrators can configure routers to filter the broadcast traffic.

Ultimately, no matter what the protocol, you need efficient management of a distributed namespace that encompasses users, devices, and network services. That's the real problem WINS will tackle. If it works, you'll see Microsoft (and its customers) doing wide-area networking over a choice of protocols.

Will WINS be a full-blown RFC 1001/1002 NBNS/NBDD service? No, says Allard, precisely because it shouldn't be tied to TCP/IP or any other protocol. (WINS will use p-node technology, for example, but it won't depend on it.) TCP/IP--because it' s more scalable and robust than IPX/SPX-will often be the preferred choice, but it shouldn't be required. If you have an IPX/SPX infrastructure, you ought be able to leverage it.

Should WINS, or Windows networking in general, be tied to the kind of flat distributed namespace that NetBIOS uses? Again, the answer is no. A structured namespace will likely serve the needs of the distributed enterprise much better.

There's an interesting opportunity for convergence here. Windows wide-area networking requires advanced name support. So do Windows distributed objects in the forthcoming Cairo. Killing these two birds with one stone would make a lot of sense, and that' s what I predict will happen. Meanwhile, I'll be watching network developments in Redmond with interest. When Microsoft' s wide-area Windows networking over TCP/IP is good enough for those folks to use, it ought to be good enough for us.