We take it for granted that the entire world uses the TCP/IP protocol suite on their LANs. I know I did until I ran into a customer who chooses not to run TCP/IP on his Windows 2000 network of about 50 computers. The proprietor told me his employees don’t need to connect to the Internet at their workstations because the business they do doesn’t require Internet applications. The employees do need to send messages to each other and access company databases. For this reason, he chooses to run only the NetBIOS Extended User Interface (NetBEUI) protocol on his Windows 2000 machines.
The fellow made a good point. If you don’t need to connect to the Internet, and you don’t have applications or services that require TCP/IP, there’s no reason to run it. In fact, the Windows 2000 NetBEUI protocol performs better than TCP/IP, and there’s no risk of a hacker getting into your network from an Internet connection. In this Daily Drill Down, I’ll go over the features and some of the internals of the Windows 2000 NetBEUI protocol and compare it with the TCP/IP protocol suite through the discussion.
Introduction to the NetBIOS Frame Format Protocol (NBFP)
NetBEUI was one of the earliest protocols put into use on workgroup-sized LANs of less than 200 computers. It was designed as an extension of the NetBIOS (Network Basic Input/Output) networking command set. NetBIOS, and therefore NetBEUI, uses a flat name and address space and isn’t appropriate for multisegment LANs. The flat address space doesn’t include provisions for network IDs that can be used to support network routing.
The Windows 2000 implementation of NetBEUI (version 3.0) is referred to as the NetBIOS Frame Format Protocol (NBFP). The NBFP uses NetBIOS Frame (NBF) as its transport protocol. NBFP is completely compatible with earlier versions of NetBEUI; it also has added features that give it an advantage over earlier versions of NetBEUI (NBF was first introduced with Windows NT 3.1):
- It takes advantage of the Windows Transport Driver Interface (TDI).
- It uses the Windows Network Device Interface Specification (NDIS).
- It removes the old NetBIOS 254-session limit.
These improvements in the NetBEUI protocol make it lean and mean and allow fast and reliable network communications for a small workgroup LAN.
History of NetBIOS
Sytek developed the NetBIOS networking command set for IBM in 1993. The NetBIOS networking command set defined a session layer interface and a data transport protocol. NetBIOS is not a transport protocol but a set of definitions that can be used to create a transport protocol. NetBIOS Frame represents such a transport protocol.
NBFP takes advantage of the Microsoft networking model, at the top of which are the services and applications that are accessible to users and applications. To gain access to network protocol drivers, Microsoft has provided the TDI, which allows programmers to code to a single common interface to gain access to network protocols. Protocol developers also take advantage of the TDI because they don’t need to expose the protocol stack to user-level processes (which could make the protocol implementation unstable). All a developer needs to do is code to the TDI, which acts as a go-between for the applications and network protocol drivers.
A second interface provided by the Microsoft networking model is the NDIS, which allows network interface developers to code to a single interface between the hardware layer components that drive the Network interface and the Data-Link layer functions that lie above it.
NBFP and the OSI model
The NBFP is a relatively simple protocol when you look at it from the perspective of the OSI model for network protocols. Only two layers of the OSI model are represented by NBFP:
- The NBF protocol sits at the Transport layer.
- The Logical Link Control (LLC) 802.2 Protocol sits at the Data-Link layer.
The NBF protocol provides features that are common to transport protocols of all types. These include:
- Session establishment
- Message segmentation
- Frame sequencing
- Reassembly of frames at the destination computer
The NBF protocol directly interfaces with the (TTI) TDI. The LLC 802.2 components interface with NDIS.
Applications and services that are written to use the NetBIOS interface can either access this interface directly by communicating with the transport protocol driver or they can use the TDI. Windows 2000 provides a 32-bit TDI to prevent applications from directly communicating with the transport protocol. When a NetBIOS application sends a network command (via a network control block—NCB), the command is sent to the NetBIOS driver, Netbios.sys. Netbios.sys maps the NetBIOS command to a TDI command. The command is then passed down from the TDI to the NBF transport protocol.
Network applications and the TDI
All 32-bit network-aware applications use the TDI to interface with the network protocol drivers. All 16-bit Windows network-aware applications communicate directly with the NetBIOS interface and do not use the TDI. This explains the poorer performance and relative instability of 16-bit Windows network-aware applications.
The NBFP doesn’t have a Network layer component because its address space doesn’t allow for network routing. Addressing is handled by the Data-Link layer component. The LLC layer handles network addressing similarly to the way Internet Protocol (IP) handles addressing on TCP/IP networks. The layer handles duties such as:
- Link establishment
- Reliable and unreliable communications
- Frame sequencing
- Flow control
Instead of the ports that are used on TCP/IP networks, LLC uses link stations. The link station provides an access point that network services use to connect to one another. TCP/IP uses the socket concept to define a particular port and address. The LLC counterpart of the socket concept is the Service Access Point (SAP). Just like with the well-known TCP ports, there are well-known SAPs: Source Service Access Points (SSAPs) and Destination Service Access Points (DSAPs). Clients and servers send frames on the network based on source and destination SAPs.
How NBF implements connectionless communications
Like TCP/IP, NBF can carry out connectionless communications with other computers on an NBFP network. The connectionless communication can be either reliable or unreliable. Like UDP on TCP/IP network, reliability is dependent on the configuration of higher-level functions. The Windows 2000 NBF protocol provides only unreliable connectionless communications.
NBF carries out several types of connectionless communications. Two of the most common are:
- Name registration and name discovery
- NBF datagrams
Name registration takes place when an NBF computer starts up and requests to use a particular NetBIOS name on the network. Name discovery is name resolution, where the client attempts to locate a computer by a specific name and obtain its hardware address. The specific hardware address is required for any subsequent connection-oriented communications. Note the similarity with DNS queries, where the DNS name query message is sent via a connectionless UDP message. NBF datagrams are similar to UDP datagrams in that they can be sent to a particular host or multicast address and do not require session establishment and acknowledgments.
A connectionless communication doesn’t require session establishment between the client and server. When frames are sent out over the network in a connectionless communication using NBF, the frames aren’t numbered (sequenced) and the client doesn’t expect or wait for an answer. The server may or may not receive all the frames, but this is unimportant to the client in a connectionless communication.
An example of a connectionless NBF communication is the NetBIOS name registration process. The NetBIOS client machine multicasts its name to the hardware broadcast address. The client doesn’t care if there’s a response to the broadcast or not. The NBF client is hardwired to send out a certain number of name registration requests separated by a fixed period. If it doesn’t get a response, it registers its name on the network. If it does get a response from another network host that already owns the name, the name will be denied and the network protocol will not be bound to the interface.
How NBF implements connection-oriented communications
NBF also supports connection-oriented communications. These are similar to TCP sessions that are created by the TCP protocol. To carry out a connection-oriented session, the source SAP, the destination SAP, and the hardware addresses of the participating computers are required. Again, this is similar to the socket and destination sockets required to carry out a TCP session.
When two NBF machines set up a logical session, they exchange a local session number (LSN), a number used to denote a particular session between two NBF computers. Both Netbios.sys (the NetBIOS emulator) and Nbf.sys (the NBF protocol driver) use the LSN. Netbios.sys uses the LSN together with a process ID to create a TDI handle. The Nbf.sys protocol driver uses the LSN and the destination network address to create its own TDI handle. These TDI handles bind a particular process to a particular session with a specific computer on the network. They also make it possible for the system to easily identify which processes are associated with which session.
Note that LSNs can be reused. For example, suppose the NBF client machine connects to computer 1 using an LSN of 10. It can also connect to computer 2 using an LSN of 10. The reason the sessions don’t get mixed up is that the session (for each process) is determined by the TDI handles. Since the Nbf.sys TDI handle includes both the session number and the network address of the destination host, the sessions don’t get “mixed up” and are sent to the correct destination computer. However, the same LSN cannot be used by two sessions (and therefore two processes) for the same destination computer because each process must have a different LSN to create a different TDI netbios.sys TDI handle.
A connection-oriented communication
When a NetBIOS command is issued by a NetBIOS application, the following sequence of events takes place:
- NBF generates a Find Name frame. This frame is unnumbered and is part of a connectionless communication. This is how the client finds the destination host and obtains that host’s hardware address.
- When the destination host is found and the client has obtained its hardware address, the client and server begin the session establishment process, which is similar to the “three-way handshake” used by TCP to establish a session. Session parameters are determined by the use of link timers and sliding windows.
- The client sends a Set Asynchronous Balance Mode Extended frame. The server acknowledges this frame by sending back an unnumbered ACK frame.
- After the client receives the ACK frame from the server, the client sends to the server a Ready To Receive (RR) frame, which tells the server that it’s ready to receive Information (I) frames. The I frames will begin with a sequence number of 0 (zero). Note that unlike TCP sequence numbers, the NBF sequence numbers always begin with zero. The Server sends an ACK message indicating it received the RR frame.
- This establishes the LLC-layer session, and a corresponding LSN is created for the link. Application layer data can begin transfer after the LLC-layer session is established.
Like TCP, NBF uses the concept and implementation of sliding windows to improve protocol performance. There are two window definitions: a send window and a receive window. The send window determines how many frames are sent by the sender before waiting for an ACK from the destination host. The receive window determines how many frames the destination computer receives before returning an ACK to the sending computer. The Windows 2000 NBF doesn’t use a receive window. Instead, it uses polling frames to determine the status of the client. The last frame sent by a client always has the polling bit turned on so that the server sends back an ACK after receiving the last frame. The send window is dynamically adjusted by Windows 2000 to optimize network communications based on link speed and number of required retransmits.
Link timers are used for flow control and retransmits. NBF uses three link timers:
- The response timer (T1)
- The ACK timer (T2)
- The inactivity timer (Ti)
Note that similar timers are used by TCP. The NBF client computer uses the response timer to determine how long it should wait before assuming that a frame has been lost in transit. If the link timer expires, the client will send an RR frame to the server and double the value of the response timer. If the server doesn’t respond with an ACK to the RR message, the link is dropped.
The ACK timer kicks in when an Information frame cannot be sent immediately. This starts the ACK timer, which has a default value of 150 milliseconds. The inactivity timer is used to determine whether a link has gone down. It has a default value of 30 seconds. When the activity timer value is exceeded, the NBF client sends a frame with the polling bit turned on, and the server responds with an ACK to maintain the link. If the ACK is not received, the link is dropped.
As are most protocols, NetBEUI is a complicated issue. For more information on this topic, take a look at the following:
- TechNet article: Chapter 16 — NetBEUI
- Microsoft Support: “Slow Network Performance Using NetBEUI Across Bridges”
- ZDNet whitepaper:“Protocol Standard for a NetBIOS Service on a TCP/UDP Transport”
If you work with LANs that do not require connection to the Internet or the use of TCP/IP-based applications and services, consider using only NetBEUI on your network.