Internet Draft F. Noon
UB
March 1992
HYBRID NETBIOS END-NODES
STATUS OF THIS MEMO
Implementations of NetBIOS-over-TCP may choose to adopt the
procedures discussed, but not doing so will not meaningfully
affect interoperability. Distribution of this memo is unlimited.
1. CHARACTERISTICS OF B, P, AND M NODES
STD-19/RFC-1001/RFC-1002 defines a "Protocol Standard for a NetBIOS
Service on a TCP/UDP Transport," or "NetBIOS-over-TCP" for short.
STD-19 defines NetBIOS end-nodes as stations which "support NetBIOS
service interfaces and contain applications." It describes three
types of end-node:
- Broadcast nodes (B nodes)
- Point-to-point nodes (P nodes)
- Mixed mode nodes (M nodes)
The B node relies upon IP broadcasts to effect parts of the NetBIOS
Name and Datagram Services (and so, indirectly, the Session Service
as well). For example, to discover the owner of a NetBIOS name it
must broadcast a Name Query Request packet over UDP. The chief
limitation of the B node is that it is limited to the range of its
broadcast area, not being able to arbitrarily cross IP routers.
Also, many sites only reluctantly allow a protocol on their network
which regularly engages in broadcast traffic.
The P node has no such limitations, as it never broadcasts UDP
datagrams; instead it contacts special NetBIOS servers directly. It
utterly relies upon these stations, which implement a NetBIOS Name
Service (NBNS) server and a NetBIOS Datagram Distribution (NBDD)
server. If either server becomes unavailable NetBIOS services are
crippled or stop. For example, if the NBNS server fails or is
unreachable, a booting P node cannot register its own name; for a
microcomputer this often means that it must abort loading its network
operating system until it can be restarted.
The M node is basically a P node which can transmit UDP broadcasts to
locate owners of NetBIOS names. This is allowed under the assumption
that end-nodes will be searching for "local" resources most of the
time, so broadcasts could prove efficient. Otherwise the M node
Noon [Page 1]
Internet Draft Hybrid NetBIOS End-Nodes March 1992
remains as dependent upon NBNS and NBDD servers as is the P node.
For example, an M node cannot register a NetBIOS name unless it can
contact its NBNS server; until it registers its name it cannot engage
in other NetBIOS transactions. This severely limits the robustness
of such systems.
2. MOTIVATION FOR A FOURTH END-NODE TYPE
Previous specification of NetBIOS-over-TCP creates a deployment
dilemma for implementers of sizable TCP/IP networks which incorporate
IP routers. B nodes are not really suited for such an environment,
which leaves P and M nodes. But these are quite dependent upon NBNS
and NBDD servers for their continued operation on the network.
On the one hand one wishes to have many of these critical servers in
the network; say between every pair of routers, bridges, or other
links which may occasionally fail. On the other hand the costs of
deploying that many servers, the small amount of work each one would
probably be fielding at one segment each, and the additional
headaches of maintaining the whole operation, is discouraging.
The end-node specified by this RFC has a style of operation assuring
greater robustness than P or M nodes, while remaining suitable for
large internetworks and minimizing use of IP broadcasts. It uses the
same NetBIOS servers as do P and M nodes, and is therefore fully
interoperable with these other end-node types.
3. THE H NODE TRANSACTION STYLE
This RFC specifies a fourth end-node type: a Hybrid (H) node. The H
node is similar to an M node in that it maintains both B node
characteristics (use of IP broadcasts) and P node characteristics
(use of NBNS and NBDD servers). Unlike the M node, however, the
emphasis is placed upon the robustness of the NetBIOS Services
offered to applications on the end-node. If an NBNS or NBDD server
becomes unavailable connectivity may be reduced (the network has been
partitioned) but all NetBIOS services will continue to function
properly.
Unless otherwise specified below, the behavior of the H node is
identical to that of the M node.
The H node always listens for IP broadcasts on both the NetBIOS Name
and Datagram Service UDP ports. This is to maintain connectivity
with fellow H nodes which can, under conditions specified below, use
UDP broadcasts for these services.
For convenience I assume that the H node maintains two boolean
variables: NBNS-AVAILABLE and NBDD-AVAILABLE. These are initially
both TRUE, meaning that the H node will try to use its NBNS and NBDD
servers whenever possible. NBNS-AVAILABLE is toggled to FALSE
whenever an attempt to contact the NBNS server fails. With the flag
Noon [Page 2]
Internet Draft Hybrid NetBIOS End-Nodes March 1992
in this state the H node uses the B node transaction style, which
doesn't use NBNS servers, for all protocol used for the NetBIOS Name
Service. The H node periodically attempts to contact the NBNS server
and, if ever successful, sets NBNS-AVAILABLE back to TRUE and begins
using the NBNS server once more. (Attempting to contact the NBNS
server on every transaction, involving retries then finally timing
out, would cause much delay on a busy end-node.)
Analogously, NBDD-AVAILABLE becomes FALSE whenever the NBDD server
cannot be contacted, and returns to TRUE when polling reveals its
return. While FALSE the H node uses the B node transaction style for
passing Datagram Service protocol.
The mechanism used to poll the servers is irrelevant. For polling an
NBNS server a Name Query Request will work (use one of the station's
unique names: otherwise the NBNS server may be wasting time gathering
up a group name list). For polling an NBDD server a Datagram Query
Request is most reliable.
3.1 Name Registration
Like the M node, the H node registers names using a two-step
procedure. First a Name Registration Request is broadcast so that
any conflicts with H nodes having NBNS-AVAILABLE FALSE may be
recognized. If this is successful the H node sends the request to
an NBNS server. If the NBNS server accepts the name the H node
owns it; if not, the name registration has failed.
The key difference between the M node and the H node is exhibited
when no NBNS server can be reached or NBNS-AVAILABLE is FALSE: the
M node registration fails; the H node registration, provisionally,
succeeds. At this point the H node continues on as best it can:
NBNS-AVAILABLE is made FALSE (if it has been TRUE) and all NetBIOS
Name Service protocol becomes that of the B node; no NBNS server
is used. The H node periodically tries to contact the NBNS
server, and if ever it succeeds sets NBNS-AVAILABLE TRUE and
resumes use of the NBNS server for the Name Service. At this time
all names claimed by the H node on the basis of broadcasts alone
must be registered at the NBNS server. Any registration that
fails results in the H node marking that name's entry "in
conflict," and the usual name conflict rules apply.
3.2 Name Release
H nodes release names just like M nodes. (There is an M node
specification problem which I will attempt to unravel below.) A
Name Release Request is sent to the NBNS server (if NBNS-AVAILABLE
is TRUE). If the NBNS server responds with a Positive Name
Release Response then the H node broadcasts a Name Release Demand
and deletes the name from its local table. If the NBNS server
responds with a Negative Name Release Response the H node does not
issue the Demand; it retains ownership of the name unless the
Noon [Page 3]
Internet Draft Hybrid NetBIOS End-Nodes March 1992
result code in the response was ACT_ERR (active error). If an
NBNS server cannot be reached, or NBNS-AVAILABLE is FALSE, the H
node does not issue the Demand; it must retry the request when an
NBNS server is again reachable.
Because RFC 1001 does not model the NetBIOS interface itself it is
unclear whether the NetBIOS service provider should retry the Name
Release Request in the background, or whether the user of NetBIOS
should retry the request. The first case can be awkward for the
provider to implement, and does not conform to the usual procedure
of returning an error code to the user whenever problems develop.
The second case is difficult because there is no appropriate error
code defined for this situation and it is probably not a condition
which a NetBIOS user would anticipate. If one assumes that names
registered on the NBNS server will be given a finite time-to-live
value (this should be standard procedure), then an implementation
which simply issues the Demand and deletes the name from its table
is little worse than a station which goes down before it can
orderly release all the names it owns. This procedure allows the
implementation to return the expected completion code (success),
keeping application complexity down, and also eliminates awkward
backfilling by the service provider.
3.3 Name Query
The M node tries to find the owners of a name first by
broadcasting; only if this fails does it query the NBNS server.
In contrast, the H node sends a Name Query Request to the NBNS
server whenever NBNS-AVAILABLE is TRUE. Only if NBNS-AVAILABLE is
FALSE, if the NBNS server does not respond (NBNS-AVAILABLE is made
FALSE), or if the NBNS server replies with a Negative Name Query
Response, does the H node broadcast the request.
3.4 Datagram Service
The H node uses an NBDD server whenever NBDD-AVAILABLE is TRUE.
Only if NBDD-AVAILABLE is FALSE, or the NBDD server becomes
unavailable (NBDD-AVAILABLE is made FALSE) does it resort to
broadcasting UDP packets containing NetBIOS multicast or broadcast
datagrams.
3.5 Mixing End-Node Types
Similar problems arise when mixing B and H nodes in an internet
environment as when mixing B and M nodes. The rule here is: B and
H nodes should not operate in the same IP broadcast area. However
P, M, and H nodes may be freely mixed in any combination.
4. PACKET ENCODING
RFC 1002 defines the packet formats for NetBIOS-over-TCP. Since H
nodes operate so similarly to other end-node types, these can be used
Noon [Page 4]
Internet Draft Hybrid NetBIOS End-Nodes March 1992
as-is except for those places where the end-node type is itself
encoded. Only encodings for B, P, and M nodes are defined;
preferably one would designate a fourth value to denote H nodes.
Unfortunately other end-node types are not foreseen by RFC 1002, so
there aren't always enough bits allocated to hold this new value.
This occurs in three places: the encoding of the ONT (owner node
type) bits of the NB_FLAGS and NAME_FLAGS fields, and in the SNT
(source end-node type) bits of the FLAGS field of the datagram
header. In each case there are 2 bits allocated, which would be
enough to represent 4 end-node types, except that the SNT bits also
have a value defined which denotes "NBDD."
Because of this space problem, and because of the limited use for the
end-node type information in the first place, the encoding which
denotes "M node" should be used to refer to H nodes as well. This is
appropriate, for both M and H nodes operate using IP broadcast as
well as NBNS and NBDD servers. Hence the essential characteristics
of the two end-node types, from the perspective of the protocols, are
the same.
5. SECURITY CONSIDERATIONS
There are no new security considerations beyond those of STD-19/
RFC-1001/RFC-1002. As specified above, M and H nodes must be
segregated from B nodes.
6. AUTHOR'S ADDRESS
Fredrik Noon
Ungermann-Bass, Inc.
P.O. Box 58030
(3900 Freedom Circle)
Santa Clara, CA 95052-8030
USA
Phone: (408) 562-5632
Fax: (408) 970-7389
EMail: fcn@ubvax.ub.com
Noon [Page 5]