1.2.4 NetBIOS

In 1984 IBM released its first LAN, the IBM PC Network. It was similar in concept to an Ethernet, but ran at 2 Mbps, whereas most Ethernets operate at 10 Mbps. The interface card for the IBM PC (called an "adapter card" by IBM) was developed by Sytek, Inc., and contained on it the first implementation of NetBIOS. The name NetBIOS is derived from the name BIOS for the "basic input output system" for the IBM PC. The BIOS was contained in read-only memory on the PC and provided an interface between a pro­gram on the PC and the actual hardware. Similarly, NetBIOS provides an interface between a program and the actual hardware on the interface card.

When IBM introduced its token ring LAN in 1985, it provided an implementation of NetBIOS for the token ring. The original PC Network implementation of NetBIOS was implemented in read-only memory on the interface card, while the token ring version was a software module. Despite the implementation differences, the token ring version pro­vided the same interface to an application program as was provided by the original PC network.

The third implementation of NetBIOS by IBM occurred when the IBM PS/2 systems were introduced and the IBM LAN Support Program was available. This software pack­age consists of device drivers and interface support for all of IBM's LAN interfaces.

NetBIOS is a software interface, not a network protocol. For example, the data packets that are exchanged across the IBM PC Network differ from those on a token ring network. The actual frame that is transmitted by two different data-link layers is expected to be different, since the data link header and trailer are different for each type of data link (token ring, Ethernet, SDLC, etc.). But the packet that is passed to the data-link layer should not change for a given protocol. For example, in the TCP/IP protocol suite, the IP datagram that starts with the IP header is the same, regardless of the data link being used. With NetBIOS this packet equivalency is not true. Nevertheless, the inter­faces provided by all IBM implementations of NetBIOS are equivalent, providing a con­sistent software interface that has become a de facto standard for personal computers. In addition, there exist implementations of NetBIOS that use TCP and UDP as the underly­ing transport protocols, and standards exist for this in the Internet (RFC 1001 and RFC 1002). Overview

NetBIOS was designed for a group of personal computers, all sharing a common broad­cast medium (the IBM PC Network, like an Ethernet). It pro­vides both a connection-oriented service (virtual circuit) and a connectionless (datagram) service. It supports both broadcast and multicast. Four types of service are provided by NetBIOS:

• name service,

• session service,

• datagram service,

• general commands.

Figure 25 shows the relationship of these four services. In most implementations, a single box providing some form of datagram delivery (similar to the IP layer in the TCP/IP suite) is probably used.

Figure 25. Relationship of NetBIOS services

But unlike the IP layer, with NetBIOS the user process has no access to any services other than the ones described in the following sections, so the actual implementation need not concern us.

In many PC environments the application that NetBIOS is being used for is file shar­ing. In this case, another protocol interface exists above NetBIOS. This interface is called the Server Message Block protocol (SMB) and it is shown in Figure 26.

Figure 26. Relationship of NetBIOS and SMB to OSI model

Dunsmuir [1989] shows the format of the SMB header and gives a listing of all the SMB functions: create directory, open file, read from file, and so on. Line printer access is automatically handled by this software interface by providing three SMB operations that are for print files, not regular files. These open, write, and close a print spool file. Name Service

Names are used to identify resources in NetBIOS. For example, for two processes to participate in a conversation, each must have a name. The client process identifies the specific server by the server's name, and the server can determine the name of the client. The name space is flat (that is, it is not hierarchical) and each name consists of from 1 to 16 alphanumeric characters. Upper case is different from lower case and names cannot start with an asterisk or with the three characters "IBM".

There are two types of names: unique names and group names. A unique name must be unique across the network. (As stated earlier, NetBIOS was designed for a LAN, so the name must typically be unique on the local network.) A group name does not have to be unique and all processes that have a given group name belong to the group.

There are four commands pertaining to name service.

ADD_ NAME Add a unique name

ADD_GROUP_NAME Add a group name

DELETE_NAME Delete name

FIND_NAME Determine if a name is registered

To obtain a unique name or a group name, a process must bid for the use of the name. This is done by broadcasting a notice that the process wants to use the name, as either a unique name or a group name—by issuing either the ADD_NAME command or the ADD_GROUP_NAME command, respectively. If no objections are received from any other NetBIOS node, the name is considered registered by the requesting node. An objection occurs for an ADD_NAME if some other node responds that the name is currently in use on that node as either a unique name or a group name. The only restric­tion on the ADD_GROUP_NAME command is that no other node can be using the name as a unique name.

Implied in the NetBIOS specification is that each NetBIOS node maintains a table of all names that processes on that node currently own. These names continue to be owned by the NetBIOS node, until the names are specifically deleted, or until the node is powered off or reset. Realize that names are handled by two different entities: name registration is done by NetBIOS for a process that issues a ADD_NAME command, but it is NetBIOS that maintains the name table. Even though the process that registered the name might cease to exist, unless the name is specifically deleted with the DELETE_NAME command, the node's NetBIOS name table continues to know the name.

Both the ADD_NAME and ADD_GROUP_NAME commands return a local name num­ber that is a small integer identifying the name. This number is used for the datagram commands and for the RECEIVE_ANY command (both described below).

By default, the IBM PC LAN Support Program transmits a name registration request six times, at half-second intervals, until it considers the name registered by itself. This implies a 3-second delay every time an application that requires a new name is started for the first time.

The FIND_NAME command was added with the token ring implementation of Net­BIOS and determines if a particular name has been registered by any other NetBIOS node. Session Service

The NetBIOS session service provides a connection-oriented, reliable, full-duplex mes­sage service to a user process. The data is organized into messages and each message can be between 0 and 131,071 bytes. NetBIOS does not provide any form of out-of-band data.

The following commands provide session service:

CALL Call—active open

LISTEN Listen—passive open

SEND Send session data

SEND_NO_ACK Send session data, no acknowledgment

RECEIVE Receive session data

RECEIVE_ANY Receive session data

HANG_UP Terminate session

SESSION_STATUS Retrieve session status

NetBIOS requires one process to be the client and another to be the server. The server first issues a passive open with the LISTEN command. The client then connects with the server when the client executes the CALL command.

The LISTEN command requires the caller (typically a server process) to specify both the local name (which must be in the local NetBIOS name table) and the remote name. The local name is the well-known address that the server is known by. The remote name is the name of the specific client with which a session can be established. The caller can specify the remote name as an asterisk, allowing any remote process that specifies the local name to establish a connection. Since most servers are willing to accept a connection from any process (perhaps doing some form of authentication once the session is established), specifying the remote name as an asterisk is the typical scenario. Both ends of the session can access the name of the other end.

Both the LISTEN command and the CALL command return a local session number to the calling process. This small integer is then used for SEND and RECEIVE com­mands to specify a particular session (since a process can have more than one session active at any time). The local session number is also used by the HANGUP command to specify which session is to be terminated. When a session is terminated, all pending data is first transferred.

In the normal SEND operation, the NetBIOS module waits for a positive acknowl­edgment frpm the other system before returning to the caller. Similarly, the RECEIVE command sends an acknowledgment to the other system before passing the received data to the caller. This provides an end-to-end verification that the data was received. When the token ring implementation of NetBIOS appeared, IBM introduced the SENDNOACK command, which does not perform the acknowledgments between the NetBIOS modules. The reason for this is that the data-link layer of the token ring net­work performs acknowledgments between the two data-link layers.

The IBM PC implementations provide a CHAINSEND command that combines two user buffers into a single message. The reason for this command is that the count associ­ated with a normal SEND command is a 16-bit integer, which allows values between 0 and 65535. By combining two sends into a single operation, messages up to 131,071 bytes can be exchanged. This command, however, is an interface issue between the Net­BIOS implementation and the user process.

The RECEIVE command receives data for a particular session that the process has open. The local session number that was returned by the CALL or LISTEN specifies the session. The RECEIVE_ANY command allows a process to receive the next message from any of its current session partners. NetBIOS returns the actual session number corresponding to the received data. Datagram Service

NetBIOS supports datagrams up to 512 bytes in length. Datagrams can be sent to a specific name (either a unique name or a group name) or can be broadcast to the entire local area network. As with other datagram services, such as UDP/1P, the NetBIOS data­grams are connectionless and unreliable. There are four datagram commands.

SEND_DATAGRAM Send datagram

SEND_BROADCAST_DATAGRAM Send broadcast datagram

RECEIVE_DATAGRAM Receive datagram

RECEIVE_BROADCAST_DATAGRAM Receive broadcast datagram

The SEND_DATAGRAM command requires the caller to specify the name of the destina­tion. The name can be either a unique name or a group name. If the destination is a group name, then every member of the group receives the datagram. The caller of the RECEIVE_DATAGRAM command must specify the local name for which it wants to receive datagrams. Datagrams addressed to this name are received by the caller. The RECEIVE_DATAGRAM command also returns the name of the sender, in addition to the ' actual datagram data. If NetBIOS receives a datagram (i.e., the NetBIOS module has previously registered the name to which the datagram was addressed), but there are no RECEIVE_DATAGRAM commands pending, then the datagram is discarded.

The SEND_BROADCAST_DATAGRAM command sends the message to every NetBIOS system on the local network. When a broadcast datagram is received by a Net­BIOS node, every process that has issued a RECEIVE_BROADCAST__DATAGRAM com­mand receives the datagram. If none of these commands are outstanding when the broadcast datagram is received, the datagram is discarded. As with a normal datagram, the name of the broadcast datagram source is also returned to the receiver. General Commands

There are four general commands.


CANCEL Cancel an asynchronous command

ADAPTER_STATUS Fetch adapter status

UNLINK Unlink from bootstrap server

The RESET command clears the NetBIOS name and session tables, and also aborts any existing sessions.

The CANCEL command assumes that NetBIOS commands can be issued asynchronously by a user process. That is, the user process starts a command but does not wait for it to complete. Some method is required for the process to be notified when the command completes or for the process to check if a specific command is done or not. If asynchronous commands are supported by the NetBIOS implementation, then the CANCEL command cancels a specific outstanding command. If the command being can­celled is a SEND, then the associated session is aborted.

The STATUS command returns interface-specific status associated with either a local name or a remote name. Additionally, it returns the NetBIOS name table for that Net­BIOS node (either the local node or a remote node). Unfortunately, for the IBM PC implementations of NetBIOS, the actual contents of the adapter status information that is returned to the caller depends on the adapter type (PC Network or token ring).

The UNLINK command was used with the original PC Network interface when a diskless workstation was bootstrapped from a remote disk drive. NetBIOS Summary

In Figure 27 the two NetBIOS services are added to the table that is being built. The terms NbS is used for the NetBIOS session services and NbD is used for the datagram ser­vices. Note that the NetBIOS session service is like LU 6.2—both assume the underly­ing data link provides reliability.

Figure 27. Comparison of protocol features: Internet, XNS, SNA, and NetBIOS

Using our definition of an association from the previous chapter, for the NetBIOS session service it consists of

• the protocol (NetBIOS session service),

• the source name,

• the source session number,

• the destination name,

• the destination session number.

An example could be


For the NetBIOS datagram service, only the protocol and the names are required, as there is no concept of a session for a datagram. Note also that the name of a partner process implies both the host name and the server's name.