RFC 1001
Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods
16. NetBIOS SESSION SERVICE The NetBIOS session service begins after one or more IP addresses have been found for the target name. These addresses may have been acquired using the NetBIOS name query transactions or by other means, such as a local name table or cache. NetBIOS session service transactions, packets, and protocols are identical for all end-node types. They involve only directed (point-to-point) communications.
16.1. OVERVIEW OF NetBIOS SESSION SERVICE Session service has three phases: Session establishment - it is during this phase that the IP address and TCP port of the called name is determined, and a TCP connection is established with the remote party. Steady state - it is during this phase that NetBIOS data messages are exchanged over the session. Keep-alive packets may also be exchanged if the participating nodes are so configured. Session close - a session is closed whenever either a party (in the session) closes the session or it is determined that one of the parties has gone down. 16.1.1. SESSION ESTABLISHMENT PHASE OVERVIEW An end-node begins establishment of a session to another node by somehow acquiring (perhaps using the name query transactions or a local cache) the IP address of the node or nodes purported to own the destination name. Every end-node awaits incoming NetBIOS session requests by listening for TCP calls to a well-known service port, SSN_SRVC_TCP_PORT. Each incoming TCP connection represents the start of a separate NetBIOS session initiation attempt. The NetBIOS session server, not the ultimate application, accepts the incoming TCP connection(s). Once the TCP connection is open, the calling node sends session service request packet. This packet contains the following information: - Calling IP address (see note) - Calling NetBIOS name - Called IP address (see note) - Called NetBIOS name NOTE: The IP addresses are obtained from the TCP service interface. When the session service request packet arrives at the NetBIOS server, one of the the following situations will exist: - There exists a NetBIOS LISTEN compatible with the incoming call and there are adequate resources to permit session establishment to proceed. - There exists a NetBIOS LISTEN compatible with the incoming call, but there are inadequate resources to permit
establishment of a session.
- The called name does, in fact, exist on the called node, but
there is no pending NetBIOS LISTEN compatible with the
incoming call.
- The called name does not exist on the called node.
In all but the first case, a rejection response is sent back over the
TCP connection to the caller. The TCP connection is then closed and
the session phase terminates. Any retry is the responsibility of the
caller. For retries in the case of a group name, the caller may use
the next member of the group rather than immediately retrying the
instant address. In the case of a unique name, the caller may
attempt an immediate retry using the same target IP address unless
the called name did not exist on the called node. In that one case,
the NetBIOS name should be re-resolved.
If a compatible LISTEN exists, and there are adequate resources, then
the session server may transform the existing TCP connection into the
NetBIOS data session. Alternatively, the session server may
redirect, or "retarget" the caller to another TCP port (and IP
address).
If the caller is redirected, the caller begins the session
establishment anew, but using the new IP address and TCP port given
in the retarget response. Again a TCP connection is created, and
again the calling and called node exchange credentials. The called
party may accept the call, reject the call, or make a further
redirection.
This mechanism is based on the presumption that, on hosts where it is
not possible to transfer open TCP connections between processes, the
host will have a central session server. Applications willing to
receive NetBIOS calls will obtain an ephemeral TCP port number, post
a TCP unspecified passive open on that port, and then pass that port
number and NetBIOS name information to the NetBIOS session server
using a NetBIOS LISTEN operation. When the call is placed, the
session server will "retarget" the caller to the application's TCP
socket. The caller will then place a new call, directly to the
application. The application has the responsibility to mimic the
session server at least to the extent of receiving the calling
credentials and then accepting or rejecting the call.
16.1.1.1. RETRYING AFTER BEING RETARGETTED
A calling node may find that it can not establish a session with a
node to which it was directed by the retargetting procedure. Since
retargetting may be nested, there is an issue whether the caller
should begin a retry at the initial starting point or back-up to an
intermediate retargetting point. The caller may use any method. A
discussion of two such methods is in Appendix B, "Retarget Algorithms". 16.1.1.2. SESSION ESTABLISHMENT TO A GROUP NAME Session establishment with a group name requires special consideration. When a NetBIOS CALL attempt is made to a group name, name discovery will result in a list (possibly incomplete) of the members of that group. The calling node selects one member from the list and attempts to build a session. If that fails, the calling node may select another member and make another attempt. When the session service attempts to make a connection with one of the members of the group, there is no guarantee that that member has a LISTEN pending against that group name, that the called node even owns, or even that the called node is operating. 16.1.2. STEADY STATE PHASE OVERVIEW NetBIOS data messages are exchanged in the steady state. NetBIOS messages are sent by prepending the user data with a message header and sending the header and the user data over the TCP connection. The receiver removes the header and passes the data to the NetBIOS user. In order to detect failure of one of the nodes or of the intervening network, "session keep alive" packets may be periodically sent in the steady state. Any failure of the underlying TCP connection, whether a reset, a timeout, or other failure, implies failure of the NetBIOS session. 16.1.3. SESSION TERMINATION PHASE OVERVIEW A NetBIOS session is terminated normally when the user requests the session to be closed or when the session service detects the remote partner of the session has gracefully terminated the TCP connection. A NetBIOS session is abnormally terminated when the session service detects a loss of the connection. Connection loss can be detected with the keep-alive function of the session service or TCP, or on the failure of a SESSION MESSAGE send operation. When a user requests to close a session, the service first attempts a graceful in-band close of the TCP connection. If the connection does not close within the SSN_CLOSE_TIMEOUT the TCP connection is aborted. No matter how the TCP connection is terminated, the NetBIOS session service always closes the NetBIOS session. When the session service receives an indication from TCP that a connection close request has been received, the TCP connection and the NetBIOS session are immediately closed and the user is informed
of the loss of the session. All data received up to the close indication should be delivered, if possible, to the session's user. 16.2. SESSION ESTABLISHMENT PHASE All the following diagrams assume a name query operation was successfully completed by the caller node for the listener's name. This first diagram shows the sequence of network events used to successfully establish a session without retargetting by the listener. The TCP connection is first established with the well- known NetBIOS session service TCP port, SSN_SRVC_TCP_PORT. The caller then sends a SESSION REQUEST packet over the TCP connection requesting a session with the listener. The SESSION REQUEST contains the caller's name and the listener's name. The listener responds with a POSITIVE SESSION RESPONSE informing the caller this TCP connection is accepted as the connection for the data transfer phase of the session. CALLER LISTENER TCP CONNECT ====================================> TCP ACCEPT <=================================== SESSION REQUEST ------------------------------------> POSITIVE RESPONSE <----------------------------------- The second diagram shows the sequence of network events used to successfully establish a session when the listener does retargetting. The session establishment procedure is the same as with the first diagram up to the listener's response to the SESSION REQUEST. The listener, divided into two sections, the listen processor and the actual listener, sends a SESSION RETARGET RESPONSE to the caller. This response states the call is acceptable, but the data transfer TCP connection must be at the new IP address and TCP port. The caller then re-iterates the session establishment process anew with the new IP address and TCP port after the initial TCP connection is closed. The new listener then accepts this connection for the data transfer phase with a POSITIVE SESSION RESPONSE. CALLER LISTEN PROCESSOR LISTENER TCP CONNECT =============================> TCP ACCEPT <============================= SESSION REQUEST ----------------------------->
SESSION RETARGET RESPONSE
<-----------------------------
TCP CLOSE
<=============================
TCP CLOSE
=============================>
TCP CONNECT
====================================================>
TCP ACCEPT
<====================================================
SESSION REQUEST
---------------------------------------------------->
POSITIVE RESPONSE
<----------------------------------------------------
The third diagram is the sequence of network events for a rejected
session request with the listener. This type of rejection could
occur with either a non-retargetting listener or a retargetting
listener. After the TCP connection is established at
SSN_SRVC_TCP_PORT, the caller sends the SESSION REQUEST over the TCP
connection. The listener does not have either a listen pending for
the listener's name or the pending NetBIOS listen is specific to
another caller's name. Consequently, the listener sends a NEGATIVE
SESSION RESPONSE and closes the TCP connection.
CALLER LISTENER
TCP CONNECT
====================================>
TCP ACCEPT
<===================================
SESSION REQUEST
------------------------------------>
NEGATIVE RESPONSE
<-----------------------------------
TCP CLOSE
<===================================
TCP CLOSE
====================================>
The fourth diagram is the sequence of network events when session
establishment fails with a retargetting listener. After being
redirected, and after the initial TCP connection is closed the caller
tries to establish a TCP connection with the new IP address and TCP
port. The connection fails because either the port is unavailable or
the target node is not active. The port unavailable race condition
occurs if another caller has already acquired the TCP connection with
the listener. For additional implementation suggestions, see
Appendix B, "Retarget Algorithms".
CALLER LISTEN PROCESSOR LISTENER
TCP CONNECT
=============================>
TCP ACCEPT
<=============================
SESSION REQUEST
----------------------------->
REDIRECT RESPONSE
<-----------------------------
TCP CLOSE
<=============================
TCP CLOSE
=============================>
TCP CONNECT
====================================================>
CONNECTION REFUSED OR TIMED OUT
<===================================================
16.3. SESSION DATA TRANSFER PHASE
16.3.1. DATA ENCAPSULATION
NetBIOS messages are exchanged in the steady state. Messages are
sent by prepending user data with message header and sending the
header and the user data over the TCP connection. The receiver
removes the header and delivers the NetBIOS data to the user.
16.3.2. SESSION KEEP-ALIVES
In order to detect node failure or network partitioning, "session
keep alive" packets are periodically sent in the steady state. A
session keep alive packet is discarded by a peer node.
A session keep alive timer is maintained for each session. This
timer is reset whenever any data is sent to, or received from, the
session peer. When the timer expires, a NetBIOS session keep-alive
packet is sent on the TCP connection. Sending the keep-alive packet
forces data to flow on the TCP connection, thus indirectly causing
TCP to detect whether the connection is still active.
Since many TCP implementations provide a parallel TCP "keep- alive"
mechanism, the NetBIOS session keep-alive is made a configurable
option. It is recommended that the NetBIOS keep- alive mechanism be
used only in the absence of TCP keep-alive.
Note that unlike TCP keep alives, NetBIOS session keep alives do not
require a response from the NetBIOS peer -- the fact that it was
possible to send the NetBIOS session keep alive is sufficient indication that the peer, and the connection to it, are still active. The only requirement for interoperability is that when a session keep alive packet is received, it should be discarded. 17. NETBIOS DATAGRAM SERVICE 17.1. OVERVIEW OF NetBIOS DATAGRAM SERVICE Every NetBIOS datagram has a named destination and source. To transmit a NetBIOS datagram, the datagram service must perform a name query operation to learn the IP address and the attributes of the destination NetBIOS name. (This information may be cached to avoid the overhead of name query on subsequent NetBIOS datagrams.) NetBIOS datagrams are carried within UDP packets. If a NetBIOS datagram is larger than a single UDP packet, it may be fragmented into several UDP packets. End-nodes may receive NetBIOS datagrams addressed to names not held by the receiving node. Such datagrams should be discarded. If the name is unique then a DATAGRAM ERROR packet is sent to the source of that NetBIOS datagram. 17.1.1. UNICAST, MULTICAST, AND BROADCAST NetBIOS datagrams may be unicast, multicast, or broadcast. A NetBIOS datagram addressed to a unique NetBIOS name is unicast. A NetBIOS datatgram addressed to a group NetBIOS name, whether there are zero, one, or more actual members, is multicast. A NetBIOS datagram sent using the NetBIOS "Send Broadcast Datagram" primitive is broadcast. 17.1.2. FRAGMENTATION OF NetBIOS DATAGRAMS When the header and data of a NetBIOS datagram exceeds the maximum amount of data allowed in a UDP packet, the NetBIOS datagram must be fragmented before transmission and reassembled upon receipt. A NetBIOS Datagram is composed of the following protocol elements: - IP header of 20 bytes (minimum) - UDP header of 8 bytes - NetBIOS Datagram Header of 14 bytes - The NetBIOS Datagram data. The NetBIOS Datagram data section is composed of 3 parts: - Source NetBIOS name (255 bytes maximum) - Destination NetBIOS name (255 bytes maximum) - The NetBIOS user's data (maximum of 512 bytes)
The two name fields are in second level encoded format (see section
14.)
A maximum size NetBIOS datagram is 1064 bytes. The minimal maximum
IP datagram size is 576 bytes. Consequently, a NetBIOS Datagram may
not fit into a single IP datagram. This makes it necessary to permit
the fragmentation of NetBIOS Datagrams.
On networks meeting or exceeding the minimum IP datagram length
requirement of 576 octets, at most two NetBIOS datagram fragments
will be generated. The protocols and packet formats accommodate
fragmentation into three or more parts.
When a NetBIOS datagram is fragmented, the IP, UDP and NetBIOS
Datagram headers are present in each fragment. The NetBIOS Datagram
data section is split among resulting UDP datagrams. The data
sections of NetBIOS datagram fragments do not overlap. The only
fields of the NetBIOS Datagram header that would vary are the FLAGS
and OFFSET fields.
The FIRST bit in the FLAGS field indicate whether the fragment is the
first in a sequence of fragments. The MORE bit in the FLAGS field
indicates whether other fragments follow.
The OFFSET field is the byte offset from the beginning of the NetBIOS
datagram data section to the first byte of the data section in a
fragment. It is 0 for the first fragment. For each subsequent
fragment, OFFSET is the sum of the bytes in the NetBIOS data sections
of all preceding fragments.
If the NetBIOS datagram was not fragmented:
- FIRST = TRUE
- MORE = FALSE
- OFFSET = 0
If the NetBIOS datagram was fragmented:
- First fragment:
- FIRST = TRUE
- MORE = TRUE
- OFFSET = 0
- Intermediate fragments:
- FIRST = FALSE
- MORE = TRUE
- OFFSET = sum(NetBIOS data in prior fragments)
- Last fragment:
- FIRST = FALSE
- MORE = FALSE
- OFFSET = sum(NetBIOS data in prior fragments)
The relative position of intermediate fragments may be ascertained
from OFFSET.
An NBDD must remember the destination name of the first fragment in
order to relay the subsequent fragments of a single NetBIOS datagram.
The name information can be associated with the subsequent fragments
through the transaction ID, DGM_ID, and the SOURCE_IP, fields of the
packet. This information can be purged by the NBDD after the last
fragment has been processed or FRAGMENT_TO time has expired since the
first fragment was received.
17.2. NetBIOS DATAGRAMS BY B NODES
For NetBIOS datagrams with a named destination (i.e. non- broadcast),
a B node performs a name discovery for the destination name before
sending the datagram. (Name discovery may be bypassed if information
from a previous discovery is held in a cache.) If the name type
returned by name discovery is UNIQUE, the datagram is unicast to the
sole owner of the name. If the name type is GROUP, the datagram is
broadcast to the entire broadcast area using the destination IP
address BROADCAST_ADDRESS.
A receiving node always filters datagrams based on the destination
name. If the destination name is not owned by the node or if no
RECEIVE DATAGRAM user operations are pending for the name, then the
datagram is discarded. For datagrams with a UNIQUE name destination,
if the name is not owned by the node then the receiving node sends a
DATAGRAM ERROR packet. The error packet originates from the
DGM_SRVC_UDP_PORT and is addressed to the SOURCE_IP and SOURCE_PORT
from the bad datagram. The receiving node quietly discards datagrams
with a GROUP name destination if the name is not owned by the node.
Since broadcast NetBIOS datagrams do not have a named destination,
the B node sends the DATAGRAM SERVICE packet(s) to the entire
broadcast area using the destination IP address BROADCAST_ADDRESS.
In order for the receiving nodes to distinguish this datagram as a
broadcast NetBIOS datagram, the NetBIOS name used as the destination
name is '*' (hexadecimal 2A) followed by 15 bytes of hexidecimal 00.
The NetBIOS scope identifier is appended to the name before it is
converted into second-level encoding. For example, if the scope
identifier is "NETBIOS.SCOPE" then the first-level encoded name would
be:
CKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.NETBIOS.SCOPE
According to [2], a user may not provide a NetBIOS name beginning
with "*".
For each node in the broadcast area that receives the NetBIOS
broadcast datagram, if any RECEIVE BROADCAST DATAGRAM user operations are pending then the data from the NetBIOS datagram is replicated and delivered to each. If no such operations are pending then the node silently discards the datagram. 17.3. NetBIOS DATAGRAMS BY P AND M NODES P and M nodes do not use IP broadcast to distribute NetBIOS datagrams. Like B nodes, P and M nodes must perform a name discovery or use cached information to learn whether a destination name is a group or a unique name. Datagrams to unique names are unicast directly to the destination by P and M nodes, exactly as they are by B nodes. Datagrams to group names and NetBIOS broadcast datagrams are unicast to the NBDD. The NBDD then relays the datagrams to each of the nodes specified by the destination name. An NBDD may not be capable of sending a NetBIOS datagram to a particular NetBIOS name, including the broadcast NetBIOS name ("*") defined above. A query mechanism is available to the end- node to determine if a NBDD will be able to relay a datagram to a given name. Before a datagram, or its fragments, are sent to the NBDD the P or M node may send a DATAGRAM QUERY REQUEST packet to the NBDD with the DESTINATION_NAME from the DATAGRAM SERVICE packet(s). The NBDD will respond with a DATAGRAM POSITIVE QUERY RESPONSE if it will relay datagrams to the specified destination name. After a positive response the end-node unicasts the datagram to the NBDD. If the NBDD will not be able to relay a datagram to the destination name specified in the query, a DATAGRAM NEGATIVE QUERY RESPONSE packet is returned. If the NBDD can not distribute a datagram, the end-node then has the option of getting the name's owner list from the NBNS and sending the datagram directly to each of the owners. An NBDD must be able to respond to DATAGRAM QUERY REQUEST packets. The response may always be positive. However, the usage or implementation of the query mechanism by a P or M node is optional. An implementation may always unicast the NetBIOS datagram to the NBDD without asking if it will be relayed. Except for the datagram query facility described above, an NBDD provides no feedback to indicate whether it forwarded a datagram. 18. NODE CONFIGURATION PARAMETERS - B NODES: - Node's permanent unique name - Whether IGMP is in use - Broadcast IP address to use
- Whether NetBIOS session keep-alives are needed
- Usable UDP data field length (to control fragmentation)
- P NODES:
- Node's permanent unique name
- IP address of NBNS
- IP address of NBDD
- Whether NetBIOS session keep-alives are needed
- Usable UDP data field length (to control fragmentation)
- M NODES:
- Node's permanent unique name
- Whether IGMP is in use
- Broadcast IP address to use
- IP address of NBNS
- IP address of NBDD
- Whether NetBIOS session keep-alives are needed
- Usable UDP data field length (to control fragmentation)
19. MINIMAL CONFORMANCE
To ensure multi-vendor interoperability, a minimally conforming
implementation based on this specification must observe the following
rules:
a) A node designed to work only in a broadcast area must
conform to the B node specification.
b) A node designed to work only in an internet must conform to
the P node specification.
REFERENCES [1] "Protocol Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed Specifications", RFC 1002, March 1987. [2] IBM Corp., "IBM PC Network Technical Reference Manual", No. 6322916, First Edition, September 1984. [3] J. Postel (Ed.), "Transmission Control Protocol", RFC 793, September 1981. [4] MIL-STD-1778 [5] J. Postel, "User Datagram Protocol", RFC 768, 28 August 1980. [6] J. Reynolds, J. Postel, "Assigned Numbers", RFC 990, November 1986. [7] J. Postel, "Internet Protocol", RFC 791, September 1981. [8] J. Mogul, "Internet Subnets", RFC 950, October 1984 [9] J. Mogul, "Broadcasting Internet Datagrams in the Presence of Subnets", RFC 922, October 1984. [10] J. Mogul, "Broadcasting Internet Datagrams", RFC 919, October 1984. [11] P. Mockapetris, "Domain Names - Concepts and Facilities", RFC 882, November 1983. [12] P. Mockapetris, "Domain Names - Implementation and Specification", RFC 883, November 1983. [13] P. Mockapetris, "Domain System Changes and Observations", RFC 973, January 1986. [14] C. Partridge, "Mail Routing and the Domain System", RFC 974, January 1986. [15] S. Deering, D. Cheriton, "Host Groups: A Multicast Extension to the Internet Protocol", RFC 966, December 1985. [16] S. Deering, "Host Extensions for IP Multicasting", RFC 988, July 1986.
APPENDIX A This appendix contains supporting technical discussions. It is not an integral part of the NetBIOS-over-TCP specification. INTEGRATION WITH INTERNET GROUP MULTICASTING The Netbios-over-TCP system described in this RFC may be easily integrated with the Internet Group Multicast system now being developed for the internet. In the main body of the RFC, the notion of a broadcast area was considered to be a single MAC-bridged "B-LAN". However, the protocols defined will operate over an extended broadcast area resulting from the creation of a permanent Internet Multicast Group. Each separate broadcast area would be based on a separate permanent Internet Multicast Group. This multicast group address would be used by B and M nodes as their BROADCAST_ADDRESS. In order to base the broadcast area on a multicast group certain additional procedures are required and certain constraints must be met. A-1. ADDITIONAL PROTOCOL REQUIRED IN B AND M NODES All B or M nodes operating on an IGMP based broadcast area must have IGMP support in their IP layer software. These nodes must perform an IGMP join operation to enter the IGMP group before engaging in NetBIOS activity. A-2. CONSTRAINTS Broadcast Areas may overlap. For this reason, end-nodes must be careful to examine the NetBIOS scope identifiers in all received broadcast packets. The NetBIOS broadcast protocols were designed for a network that exhibits a low average transit time and low rate of packet loss. An IGMP based broadcast area must exhibit these characteristics. In practice this will tend to constrain IGMP broadcast areas to a campus of networks interconnected by high-speed routers and inter-router links. It is unlikely that transcontinental broadcast areas would exhibit the required characteristics.
APPENDIX B This appendix contains supporting technical discussions. It is not an integral part of the NetBIOS-over-TCP specification. IMPLEMENTATION CONSIDERATIONS B-1. IMPLEMENTATION MODELS On any participating system, there must be some sort of NetBIOS Service to coordinate access by NetBIOS applications on that system. To analyze the impact of the NetBIOS-over-TCP architecture, we use the following three models of how a NetBIOS service might be implemented: 1. Combined Service and Application Model The NetBIOS service and application are both contained within a single process. No interprocess communication is assumed within the system; all communication is over the network. If multiple applications require concurrent access to the NetBIOS service, they must be folded into this monolithic process. 2. Common Kernel Element Model The NetBIOS Service is part of the operating system (perhaps as a device driver or a front-end processor). The NetBIOS applications are normal operating system application processes. The common element NetBIOS service contains all the information, such as the name and listen tables, required to co-ordinate the activities of the applications. 3. Non-Kernel Common Element Model The NetBIOS Service is implemented as an operating system application process. The NetBIOS applications are other operating system application processes. The service and the applications exchange data via operating system interprocess communication. In a multi-processor (e.g. network) operating system, each module may reside on a different cpu. The NetBIOS service process contains all the shared information required to coordinate the activities of the NetBIOS applications. The applications may still require a subroutine library to facilitate access to the NetBIOS service.
For any of the implementation models, the TCP/IP service can be located in the operating system or split among the NetBIOS applications and the NetBIOS service processes. B-1.1 MODEL INDEPENDENT CONSIDERATIONS The NetBIOS name service associates a NetBIOS name with a host. The NetBIOS session service further binds the name to a specific TCP port for the duration of the session. The name service does not need to be informed of every Listen initiation and completion. Since the names are not bound to any TCP port in the name service, the session service may use a different tcp port for each session established with the same local name. The TCP port used for the data transfer phase of a NetBIOS session can be globally well-known, locally well-known, or ephemeral. The choice is a local implementation issue. The RETARGET mechanism allows the binding of the NetBIOS session to a TCP connection to any TCP port, even to another IP node. An implementation may use the session service's globally well- known TCP port for the data transfer phase of the session by not using the RETARGET mechanism and, rather, accepting the session on the initial TCP connection. This is permissible because the caller always uses an ephemeral TCP port. The complexity of the called end RETARGET mechanism is only required if a particular implementation needs it. For many real system environments, such as an in-kernel NetBIOS service implementation, it will not be necessary to retarget incoming calls. Rather, all NetBIOS sessions may be multiplexed through the single, well-known, NetBIOS session service port. These implementations will not be burdened by the complexity of the RETARGET mechanism, nor will their callers be required to jump through the retargetting hoops. Nevertheless, all callers must be ready to process all possible SESSION RETARGET RESPONSEs. B-1.2 SERVICE OPERATION FOR EACH MODEL It is possible to construct a NetBIOS service based on this specification for each of the above defined implementation models. For the common kernel element model, all the NetBIOS services, name, datagram, and session, are simple. All the information is contained within a single entity and can therefore be accessed or modified easily. A single port or multiple ports for the NetBIOS sessions can be used without adding any significant complexity to the session establishment procedure. The only penalty is the amount of overhead incurred to get the NetBIOS messages and operation requests/responses
through the user and operating system boundary.
The combined service and application model is very similar to the
common kernel element model in terms of its requirements on the
NetBIOS service. The major difficulty is the internal coordination
of the multiple NetBIOS service and application processes existing in
a system of this type.
The NetBIOS name, datagram and session protocols assume that the
entities at the end-points have full control of the various well-
known TCP and UDP ports. If an implementation has multiple NetBIOS
service entities, as would be the case with, for example, multiple
applications each linked into a NetBIOS library, then that
implementation must impose some internal coordination.
Alternatively, use of the NetBIOS ports could be periodically
assigned to one application or another.
For the typical non-kernel common element mode implementation, three
permanent system-wide NetBIOS service processes would exist:
- The name server
- the datagram server
- and session server
Each server would listen for requests from the network on a UDP or
TCP well-known port. Each application would have a small piece of
the NetBIOS service built-in, possibly a library. Each application's
NetBIOS support library would need to send a message to the
particular server to request an operation, such as add name or send a
datagram or set-up a listen.
The non-kernel common element model does not require a TCP connection
be passed between the two processes, session server and application.
The RETARGET operation for an active NetBIOS Listen could be used by
the session server to redirect the session to another TCP connection
on a port allocated and owned by the application's NetBIOS support
library. The application with either a built-in or a kernel-based
TCP/IP service could then accept the RETARGETed connection request
and process it independently of the session server.
On Unix(tm) or POSIX(tm), the NetBIOS session server could create
sub-processes for incoming connections. The open sessions would be
passed through "fork" and "exec" to the child as an open file
descriptor. This approach is very limited, however. A pre- existing
process could not receive an incoming call. And all call-ed
processes would have to be sub-processes of the session server.
B-2. CASUAL AND RESTRICTED NetBIOS APPLICATIONS
Because NetBIOS was designed to operate in the open system
environment of the typical personal computer, it does not have the
concept of privileged or unprivileged applications. In many multi- user or multi-tasking operating systems applications are assigned privilege capabilities. These capabilities limit the applications ability to acquire and use system resources. For these systems it is important to allow casual applications, those with limited system privileges, and privileged applications, those with 'super-user' capabilities but access to them and their required resources is restricted, to access NetBIOS services. It is also important to allow a systems administrator to restrict certain NetBIOS resources to a particular NetBIOS application. For example, a file server based on the NetBIOS services should be able to have names and TCP ports for sessions only it can use. A NetBIOS application needs at least two local resources to communicate with another NetBIOS application, a NetBIOS name for itself and, typically, a session. A NetBIOS service cannot require that NetBIOS applications directly use privileged system resources. For example, many systems require privilege to use TCP and UDP ports with numbers less than 1024. This RFC requires reserved ports for the name and session servers of a NetBIOS service implementation. It does not require the application to have direct access these reserved ports. For the name service, the manager of the local name table must have access to the NetBIOS name service's reserved UDP port. It needs to listen for name service UDP packets to defend and define its local names to the network. However, this manager need not be a part of a user application in a system environment which has privilege restrictions on reserved ports. The internal name server can require certain privileges to add, delete, or use a certain name, if an implementer wants the restriction. This restriction is independent of the operation of the NetBIOS service protocols and would not necessarily prevent the interoperation of that implementation with another implementation. The session server is required to own a reserved TCP port for session establishment. However, the ultimate TCP connection used to transmit and receive data does not have to be through that reserved port. The RETARGET procedure the NetBIOS session to be shifted to another TCP connection, possibly through a different port at the called end. This port can be an unprivileged resource, with a value greater than 1023. This facilitates casual applications. Alternately, the RETARGET mechanism allows the TCP port used for data transmission and reception to be a reserved port. Consequently, an application wishing to have access to its ports maintained by the system administrator can use these restricted TCP ports. This facilitates privileged applications. A particular implementation may wish to require further special
privileges for session establishment, these could be associated with internal information. It does not have to be based solely on TCP port allocation. For example, a given NetBIOS name may only be used for sessions by applications with a certain system privilege level. The decision to use reserved or unreserved ports or add any additional name registration and usage authorization is a purely local implementation decision. It is not required by the NetBIOS protocols specified in the RFC. B-3. TCP VERSUS SESSION KEEP-ALIVES The KEEP-ALIVE is a protocol element used to validate the existence of a connection. A packet is sent to the remote connection partner to solicit a response which shows the connection is still functioning. TCP KEEP-ALIVES are used at the TCP level on TCP connections while session KEEP-ALIVES are used on NetBIOS sessions. These protocol operations are always transparent to the connection user. The user will only find out about a KEEP-ALIVE operation if it fails, therefore, if the connection is lost. The NetBIOS specification[2] requires the NetBIOS service to inform the session user if a session is lost when it is in a passive or active state. Therefore,if the session user is only waiting for a receive operation and the session is dropped the NetBIOS service must inform the session user. It cannot wait for a session send operation before it informs the user of the loss of the connection. This requirement stems from the management of scarce or volatile resources by a NetBIOS application. If a particular user terminates a session with a server application by destroying the client application or the NetBIOS service without a NetBIOS Hang Up, the server application will want to clean-up or free allocated resources. This server application if it only receives and then sends a response requires the notification of the session abort in the passive state. The standard definition of a TCP service cannot detect loss of a connection when it is in a passive state, waiting for a packet to arrive. Some TCP implementations have added a KEEP-ALIVE operation which is interoperable with implementations without this feature. These implementations send a packet with an invalid sequence number to the connection partner. The partner, by specification, must respond with a packet showing the correct sequence number of the connection. If no response is received from the remote partner within a certain time interval then the TCP service assumes the connection is lost. Since many TCP implementations do not have this KEEP-ALIVE function an optional NetBIOS KEEP-ALIVE operation has been added to the NetBIOS session protocols. The NetBIOS KEEP-ALIVE uses the properties of TCP to solicit a response from the remote connection
partner. A NetBIOS session message called KEEP-ALIVE is sent to the remote partner. Since this results in TCP sending an IP packet to the remote partner, the TCP connection is active. TCP will discover if the TCP connection is lost if the remote TCP partner does not acknowledge the IP packet. Therefore, the NetBIOS session service does not send a response to a session KEEP ALIVE message. It just throws it away. The NetBIOS session service that transmits the KEEP ALIVE is informed only of the failure of the TCP connection. It does not wait for a specific response message. A particular NetBIOS implementation should use KEEP-ALIVES if it is concerned with maintaining compatibility with the NetBIOS interface specification[2]. Compatibility is especially important if the implementation wishes to support existing NetBIOS applications, which typically require the session loss detection on their servers, or future applications which were developed for implementations with session loss detection. B-4. RETARGET ALGORITHMS This section contains 2 suggestions for RETARGET algorithms. They are called the "straight" and "stack" methods. The algorithm in the body of the RFC uses the straight method. Implementation of either algorithm must take into account the Session establishment maximum retry count. The retry count is the maximum number of TCP connect operations allowed before a failure is reported. The straight method forces the session establishment procedure to begin a retry after a retargetting failure with the initial node returned from the name discovery procedure. A retargetting failure is when a TCP connection attempt fails because of a time- out or a NEGATIVE SESSION RESPONSE is received with an error code specifying NOT LISTENING ON CALLED NAME. If any other failure occurs the session establishment procedure should retry from the call to the name discovery procedure. A minimum of 2 retries, either from a retargetting or a name discovery failure. This will give the session service a chance to re-establish a NetBIOS Listen or, more importantly, allow the NetBIOS scope, local name service or the NBNS, to re-learn the correct IP address of a NetBIOS name. The stack method operates similarly to the straight method. However, instead of retrying at the initial node returned by the name discovery procedure, it restarts with the IP address of the last node which sent a SESSION RETARGET RESPONSE prior to the retargetting failure. To limit the stack method, any one host can only be tried a maximum of 2 times.
B-5. NBDD SERVICE If the NBDD does not forward datagrams then don't provide Group and Broadcast NetBIOS datagram services to the NetBIOS user. Therefore, ignore the implementation of the query request and, when get a negative response, acquiring the membership list of IP addresses and sending the datagram as a unicast to each member. B-6. APPLICATION CONSIDERATIONS B-6.1 USE OF NetBIOS DATAGRAMS Certain existing NetBIOS applications use NetBIOS datagrams as a foundation for their own connection-oriented protocols. This can cause excessive NetBIOS name query activity and place a substantial burden on the network, server nodes, and other end- nodes. It is recommended that this practice be avoided in new applications.