tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 1001

 
 
 

Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods

Part 2 of 3, p. 16 to 48
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 16 
10.  NetBIOS END-NODES

   End-nodes support NetBIOS service interfaces and contain
   applications.

   Three types of end-nodes are part of this standard:

     -  Broadcast ("B") nodes
     -  Point-to-point ("P") nodes
     -  Mixed mode ("M") nodes

   An IP address may be associated with only one instance of one of the
   above types.

   Without having preloaded name-to-address tables, NetBIOS participants

Top      Up      ToC       Page 17 
   are faced with the task of dynamically resolving references to one
   another.  This can be accomplished with broadcast or mediated point-
   to-point communications.

   B nodes use local network broadcasting to effect a rendezvous with
   one or more recipients.  P and M nodes use the NetBIOS Name Server
   (NBNS) and the NetBIOS Datagram Distribution Server (NBDD) for this
   same purpose.

   End-nodes may be combined in various topologies.  No matter how
   combined, the operation of the B, P, and M nodes is not altered.

   NOTE: It is recommended that the administration of a NetBIOS
         scope avoid using both M and B nodes within the same scope.
         A NetBIOS scope should contain only B nodes or only P and M
         nodes.

10.1.  BROADCAST (B) NODES

   Broadcast (or "B") nodes communicate using a mix of UDP datagrams
   (both broadcast and directed) and TCP connections.  B nodes may
   freely interoperate with one another within a broadcast area.  A
   broadcast area is a single MAC-bridged "B-LAN".  (See Appendix A for
   a discussion of using Internet Group Multicasting as a means to
   extend a broadcast area beyond a single B-LAN.)

10.2.  POINT-TO-POINT (P) NODES

   Point-to-point (or "P") nodes communicate using only directed UDP
   datagrams and TCP sessions.  P nodes neither generate nor listen for
   broadcast UDP packets.  P nodes do, however, offer NetBIOS level
   broadcast and multicast services using capabilities provided by the
   NBNS and NBDD.

   P nodes rely on NetBIOS name and datagram distribution servers.
   These servers may be local or remote; P nodes operate the same in
   either case.

10.3.  MIXED MODE (M) NODES

   Mixed mode nodes (or "M") nodes are P nodes which have been given
   certain B node characteristics.  M nodes use both broadcast and
   unicast.  Broadcast is used to improve response time using the
   assumption that most resources reside on the local broadcast medium
   rather than somewhere in an internet.

   M nodes rely upon NBNS and NBDD servers.  However, M nodes may
   continue limited operation should these servers be temporarily
   unavailable.

Top      Up      ToC       Page 18 
11.  NetBIOS SUPPORT SERVERS

   Two types of support servers are part of this standard:

     -  NetBIOS name server ("NBNS") nodes
     -  Netbios datagram distribution ("NBDD") nodes

   NBNS and NBDD nodes are invisible to NetBIOS applications and are
   part of the underlying NetBIOS mechanism.

   NetBIOS name and datagram distribution servers are the focus of name
   and datagram activity for P and M nodes.

   Both the name (NBNS) and datagram distribution (NBDD) servers are
   permitted to shift part of their operation to the P or M end-node
   which is requesting a service.

   Since the assignment of responsibility is dynamic, and since P and M
   nodes must be prepared to operate should the NetBIOS server delegate
   control to the maximum extent, the system naturally accommodates
   improvements in NetBIOS server function.  For example, as Internet
   Group Multicasting becomes more widespread, new NBDD implementations
   may elect to assume full responsibility for NetBIOS datagram
   distribution.

   Interoperability between different implementations is assured by
   imposing requirements on end-node implementations that they be able
   to accept the full range of legal responses from the NBNS or NBDD.

11.1.  NetBIOS NAME SERVER (NBNS) NODES

   The NBNS is designed to allow considerable flexibility with its
   degree of responsibility for the accuracy and management of NetBIOS
   names.  On one hand, the NBNS may elect not to accept full
   responsibility, leaving the NBNS essentially a "bulletin board" on
   which name/address information is freely posted (and removed) by P
   and M nodes without validation by the NBNS.  Alternatively, the NBNS
   may elect to completely manage and validate names.  The degree of
   responsibility that the NBNS assumes is asserted by the NBNS each
   time a name is claimed through a simple mechanism.  Should the NBNS
   not assert full control, the NBNS returns enough information to the
   requesting node so that the node may challenge any putative holder of
   the name.

   This ability to shift responsibility for NetBIOS name management
   between the NBNS and the P and M nodes allows a network administrator
   (or vendor) to make a tradeoff between NBNS simplicity, security, and
   delay characteristics.

   A single NBNS may be implemented as a distributed entity, such as the
   Domain Name Service.  However, this RFC does not attempt to define

Top      Up      ToC       Page 19 
   the internal communications which would be used.

11.1.1.  RELATIONSHIP OF THE NBNS TO THE DOMAIN NAME SYSTEM

   The NBNS design attempts to align itself with the Domain Name System
   in a number of ways.

   First, the NetBIOS names are encoded in a form acceptable to the
   domain name system.

   Second, a scope identifier is appended to each NetBIOS name.  This
   identifier meets the restricted character set of the domain system
   and has a leading period.  This makes the NetBIOS name, in
   conjunction with its scope identifier, a valid domain system name.

   Third, the negotiated responsibility mechanisms permit the NBNS to be
   used as a simple bulletin board on which are posted (name,address)
   pairs.  This parallels the existing domain sytem query service.

   This RFC, however, requires the NBNS to provide services beyond those
   provided by the current domain name system.  An attempt has been made
   to coalesce all the additional services which are required into a set
   of transactions which follow domain name system styles of interaction
   and packet formats.

   Among the areas in which the domain name service must be extended
   before it may be used as an NBNS are:

     -  Dynamic addition of entries
     -  Dynamic update of entry data
     -  Support for multiple instance (group) entries
     -  Support for entry time-to-live values and ability to accept
        refresh messages to restart the time-to-live period
     -  New entry attributes

11.2.  NetBIOS DATAGRAM DISTRIBUTION SERVER (NBDD) NODES

   The internet does not yet support broadcasting or multicasting.  The
   NBDD extends NetBIOS datagram distribution service to this
   environment.

   The NBDD may elect to complete, partially complete, or totally refuse
   to service a node's request to distribute a NetBIOS datagram.  An
   end-node may query an NBDD to determine whether the NBDD will deliver
   a datagram to a specific NetBIOS name.

   The design of NetBIOS-over-TCP lends itself to the use of Internet
   Group Multicast.  For details see Appendix A.

Top      Up      ToC       Page 20 
11.3.  RELATIONSHIP OF NBNS AND NBDD NODES

   This RFC defines the NBNS and NBDD as distinct, separate entities.

   In the absence of NetBIOS name information, a NetBIOS datagram
   distribution server must send a copy to each end-node within a
   NetBIOS scope.

   An implementer may elect to construct NBNS and NBDD nodes which have
   a private protocol for the exchange of NetBIOS name information.
   Alternatively, an NBNS and NBDD may be implemented within the same
   device.

   NOTE: Implementations containing private NBNS-NBDD protocols or
         combined NBNS-NBDD functions must be clearly identified.

11.4.  RELATIONSHIP OF NetBIOS SUPPORT SERVERS AND B NODES

   As defined in this RFC, neither NBNS nor NBDD nodes interact with B
   nodes.  NetBIOS servers do not listen to broadcast traffic on any
   broadcast area to which they may be attached.  Nor are the NetBIOS
   support servers even aware of B node activities or names claimed or
   used by B nodes.

   It may be possible to extend both the NBNS and NBDD so that they
   participate in B node activities and act as a bridge to P and M
   nodes.  However, such extensions are beyond the scope of this
   specification.

12.  TOPOLOGIES

   B, P, M, NBNS, and NBDD nodes may be combined in various ways to form
   useful NetBIOS environments.  This section describes some of these
   combinations.

   There are three classes of operation:

     -  Class 0:  B nodes only.
     -  Class 1:  P nodes only.
     -  Class 2:  P and M nodes together.

   In the drawings which follow, any P node may be replaced by an M
   node.  The effects of such replacement will be mentioned in
   conjunction with each example below.

12.1.  LOCAL

   A NetBIOS scope is operating locally when all entities are within the
   same broadcast area.

Top      Up      ToC       Page 21 
12.1.1.  B NODES ONLY

   Local operation with only B nodes is the most basic mode of
   operation.  Name registration and discovery procedures use broadcast
   mechanisms.  The NetBIOS scope is limited by the extent of the
   broadcast area.  This configuration does not require NetBIOS support
   servers.

   ====+=========+=====BROADCAST AREA=====+==========+=========+====
       |         |                        |          |         |
       |         |                        |          |         |
    +--+--+   +--+--+                  +--+--+    +--+--+   +--+--+
    |  B  |   |  B  |                  |  B  |    |  B  |   |  B  |
    +-----+   +-----+                  +-----+    +-----+   +-----+

12.1.2.  P NODES ONLY

   This configuration would typically be used when the network
   administrator desires to eliminate NetBIOS as a source of broadcast
   activity.


   ====+=========+==========+=B'CAST AREA=+==========+=========+====
       |         |          |             |          |         |
       |         |          |             |          |         |
    +--+--+   +--+--+    +--+--+       +--+--+    +--+--+   +--+--+
    |  P  |   |  P  |    |NBNS |       |  P  |    |NBDD |   |  P  |
    +-----+   +-----+    +-----+       +-----+    +-----+   +-----+


   This configuration operates the same as if it were in an internet and
   is cited here only due to its convenience as a means to reduce the
   use of broadcast.

   Replacement of one or more of the P nodes with M nodes will not
   affect the operation of the other P and M nodes.  P and M nodes will
   be able to interact with one another.  Because M nodes use broadcast,
   overall broadcast activity will increase.

12.1.3.  MIXED B AND P NODES

   B and P nodes do not interact with one another.  Replacement of P
   nodes with M nodes will allow B's and M's to interact.

   NOTE: B nodes and M nodes may be intermixed only on a local
         broadcast area.  B and M nodes should not be intermixed in
         an internet environment.

Top      Up      ToC       Page 22 
12.2.  INTERNET

12.2.1.  P NODES ONLY

   P nodes may be scattered at various locations in an internetwork.
   They require both an NBNS and an NBDD for NetBIOS name and datagram
   support, respectively.

   The NetBIOS scope is determined by the NetBIOS scope identifier
   (domain name) used by the various P (and M) nodes.  An internet may
   contain numerous NetBIOS scopes.

                   +-----+
                   |  P  |
                   +--+--+              |    +-----+
                      |                 |----+  P  |
                      |                 |    +-----+
                /-----+-----\           |
   +-----+      |           |  +------+ |    +-----+
   |  P  +------+  INTERNET +--+G'WAY |-+----+  P  |
   +-----+      |           |  +------+ |    +-----+
                /-----+-----/           |
              /       |                 |    +-----+
            /         |                 |----+  P  |
     +-----+       +--+--+              |    +-----+
     |NBNS +       |NBDD |
     +-----+       +--+--+

   Any P node may be replaced by an M node with no loss of function to
   any node.  However, broadcast activity will be increased in the
   broadcast area to which the M node is attached.

Top      Up      ToC       Page 23 
12.2.2.  MIXED M AND P NODES

   M and P nodes may be mixed.  When locating NetBIOS names, M nodes
   will tend to find names held by other M nodes on the same common
   broadcast area in preference to names held by P nodes or M nodes
   elsewhere in the network.

                         +-----+
                         |  P  |
                         +--+--+
                            |
                            |
                      /-----+-----\
         +-----+      |           |      +-----+
         |  P  +------+  INTERNET +------+NBDD |
         +-----+      |           |      +-----+
                      /-----+-----/
                    /       |
                  /         |
           +-----+       +--+--+
           |NBNS +       |G'WAY|
           +-----+       +--+--+
                            |
                            |
   ====+=========+==========+=B'CAST AREA=+==========+=========+====
       |         |          |             |          |         |
       |         |          |             |          |         |
    +--+--+   +--+--+    +--+--+       +--+--+    +--+--+   +--+--+
    |  M  |   |  P  |    |  M  |       |  P  |    |  M  |   |  P  |
    +-----+   +-----+    +--+--+       +-----+    +-----+   +-----+


   NOTE: B and M nodes should not be intermixed in an internet
         environment.  Doing so would allow undetected NetBIOS name
         conflicts to arise and cause unpredictable behavior.

13.  GENERAL METHODS

   Overlying the specific protocols, described later, are a few general
   methods of interaction between entities.

13.1.  REQUEST/RESPONSE INTERACTION STYLE

   Most interactions between entities consist of a request flowing in
   one direction and a subsequent response flowing in the opposite
   direction.

   In those situations where interactions occur on unreliable transports
   (i.e. UDP) or when a request is broadcast, there may not be a strict
   interlocking or one-to-one relationship between requests and
   responses.

Top      Up      ToC       Page 24 
   In no case, however, is more than one response generated for a
   received request.  While a response is pending the responding entity
   may send one or more wait acknowledgements.

13.1.1.  RETRANSMISSION OF REQUESTS

   UDP is an unreliable delivery mechanism where packets can be lost,
   received out of transmit sequence, duplicated and delivery can be
   significantly delayed.  Since the NetBIOS protocols make heavy use of
   UDP, they have compensated for its unreliability with extra
   mechanisms.

   Each NetBIOS packet contains all the necessary information to process
   it.  None of the protocols use multiple UDP packets to convey a
   single request or response.  If more information is required than
   will fit in a single UDP packet, for example, when a P-type node
   wants all the owners of a group name from a NetBIOS server, a TCP
   connection is used.  Consequently, the NetBIOS protocols will not
   fail because of out of sequence delivery of UDP packets.

   To overcome the loss of a request or response packet, each request
   operation will retransmit the request if a response is not received
   within a specified time limit.

   Protocol operations sensitive to successive response packets, such as
   name conflict detection, are protected from duplicated packets
   because they ignore successive packets with the same NetBIOS
   information.  Since no state on the responder's node is associated
   with a request, the responder just sends the appropriate response
   whenever a request packet arrives.  Consequently, duplicate or
   delayed request packets have no impact.

   For all requests, if a response packet is delayed too long another
   request packet will be transmitted.  A second response packet being
   sent in response to the second request packet is equivalent to a
   duplicate packet.  Therefore, the protocols will ignore the second
   packet received.  If the delivery of a response is delayed until
   after the request operation has been completed, successfully or not,
   the response packet is ignored.

13.1.2.  REQUESTS WITHOUT RESPONSES: DEMANDS

   Some request types do not have matching responses.  These requests
   are known as "demands".  In general a "demand" is an imperative
   request; the receiving node is expected to obey.  However, because
   demands are unconfirmed, they are used only in situations where, at
   most, limited damage would occur if the demand packet should be lost.

   Demand packets are not retransmitted.

Top      Up      ToC       Page 25 
13.2.  TRANSACTIONS

   Interactions between a pair of entities are grouped into
   "transactions".  These transactions comprise one or more
   request/response pairs.

13.2.1.  TRANSACTION ID

   Since multiple simultaneous transactions may be in progress between a
   pair of entities a "transaction id" is used.

   The originator of a transaction selects an ID unique to the
   originator.  The transaction id is reflected back and forth in each
   interaction within the transaction.  The transaction partners must
   match responses and requests by comparison of the transaction ID and
   the IP address of the transaction partner.  If no matching request
   can be found the response must be discarded.

   A new transaction ID should be used for each transaction.  A simple
   16 bit transaction counter ought to be an adequate id generator.  It
   is probably not necessary to search the space of outstanding
   transaction ID to filter duplicates: it is extremely unlikely that
   any transaction will have a lifetime that is more than a small
   fraction of the typical counter cycle period.  Use of the IP
   addresses in conjunction with the transaction ID further reduces the
   possibility of damage should transaction IDs be prematurely re-used.

13.3.  TCP AND UDP FOUNDATIONS

   This version of the NetBIOS-over-TCP protocols uses UDP for many
   interactions.  In the future this RFC may be extended to permit such
   interactions to occur over TCP connections (perhaps to increase
   efficiency when multiple interactions occur within a short time or
   when NetBIOS datagram traffic reveals that an application is using
   NetBIOS datagrams to support connection- oriented service.)

14.  REPRESENTATION OF NETBIOS NAMES

   NetBIOS names as seen across the client interface to NetBIOS are
   exactly 16 bytes long.  Within the NetBIOS-over-TCP protocols, a
   longer representation is used.

   There are two levels of encoding.  The first level maps a NetBIOS
   name into a domain system name.  The second level maps the domain
   system name into the "compressed" representation required for
   interaction with the domain name system.

   Except in one packet, the second level representation is the only
   NetBIOS name representation used in NetBIOS-over-TCP packet formats.
   The exception is the RDATA field of a NODE STATUS RESPONSE packet.

Top      Up      ToC       Page 26 
14.1.  FIRST LEVEL ENCODING

   The first level representation consists of two parts:

     -  NetBIOS name
     -  NetBIOS scope identifier

   The 16 byte NetBIOS name is mapped into a 32 byte wide field using a
   reversible, half-ASCII, biased encoding.  Each half-octet of the
   NetBIOS name is encoded into one byte of the 32 byte field.  The
   first half octet is encoded into the first byte, the second half-
   octet into the second byte, etc.

   Each 4-bit, half-octet of the NetBIOS name is treated as an 8-bit,
   right-adjusted, zero-filled binary number.  This number is added to
   value of the ASCII character 'A' (hexidecimal 41).  The resulting 8-
   bit number is stored in the appropriate byte.  The following diagram
   demonstrates this procedure:


                         0 1 2 3 4 5 6 7
                        +-+-+-+-+-+-+-+-+
                        |a b c d|w x y z|          ORIGINAL BYTE
                        +-+-+-+-+-+-+-+-+
                            |       |
                   +--------+       +--------+
                   |                         |     SPLIT THE NIBBLES
                   v                         v
            0 1 2 3 4 5 6 7           0 1 2 3 4 5 6 7
           +-+-+-+-+-+-+-+-+         +-+-+-+-+-+-+-+-+
           |0 0 0 0 a b c d|         |0 0 0 0 w x y z|
           +-+-+-+-+-+-+-+-+         +-+-+-+-+-+-+-+-+
                   |                         |
                   +                         +     ADD 'A'
                   |                         |
            0 1 2 3 4 5 6 7           0 1 2 3 4 5 6 7
           +-+-+-+-+-+-+-+-+         +-+-+-+-+-+-+-+-+
           |0 1 0 0 0 0 0 1|         |0 1 0 0 0 0 0 1|
           +-+-+-+-+-+-+-+-+         +-+-+-+-+-+-+-+-+

   This encoding results in a NetBIOS name being represented as a
   sequence of 32 ASCII, upper-case characters from the set
   {A,B,C...N,O,P}.

   The NetBIOS scope identifier is a valid domain name (without a
   leading dot).

   An ASCII dot (2E hexidecimal) and the scope identifier are appended
   to the encoded form of the NetBIOS name, the result forming a valid
   domain name.

Top      Up      ToC       Page 27 
   For example, the NetBIOS name "The NetBIOS name" in the NetBIOS scope
   "SCOPE.ID.COM" would be represented at level one by the ASCII
   character string:

        FEGHGFCAEOGFHEECEJEPFDCAHEGBGNGF.SCOPE.ID.COM

14.2.  SECOND LEVEL ENCODING

   The first level encoding must be reduced to second level encoding.
   This is performed according to the rules defined in on page 31 of RFC
   883[12] in the section on "Domain name representation and
   compression".  Also see the section titled "Name Formats" in the
   Detailed Specifications[1].

15.  NetBIOS NAME SERVICE

   Before a name may be used, the name must be registered by a node.
   Once acquired, the name must be defended against inconsistent
   registration by other nodes.  Before building a NetBIOS session or
   sending a NetBIOS datagram, the one or more holders of the name must
   be located.

   The NetBIOS name service is the collection of procedures through
   which nodes acquire, defend, and locate the holders of NetBIOS names.

   The name service procedures are different depending whether the end-
   node is of type B, P, or M.

15.1.  OVERVIEW OF NetBIOS NAME SERVICE

15.1.1.  NAME REGISTRATION (CLAIM)

   Each NetBIOS node can own more than one name.  Names are acquired
   dynamically through the registration (name claim) procedures.

   Every node has a permanent unique name.  This name, like any other
   name, must be explicitly registered by all end-node types.

   A name can be unique (exclusive) or group (non-exclusive).  A unique
   name may be owned by a single node; a group name may be owned by any
   number of nodes.  A name ceases to exist when it is not owned by at
   least one node.  There is no intrinsic quality of a name which
   determines its characteristics: these are established at the time of
   registration.

   Each node maintains state information for each name it has
   registered.  This information includes:

     -  Whether the name is a group or unique name
     -  Whether the name is "in conflict"
     -  Whether the name is in the process of being deleted

Top      Up      ToC       Page 28 
   B nodes perform name registration by broadcasting claim requests,
   soliciting a defense from any node already holding the name.

   P nodes perform name registration through the agency of the NBNS.

   M nodes register names through an initial broadcast, like B nodes,
   then, in the absence of an objection, by following the same
   procedures as a P node.  In other words, the broadcast action may
   terminate the attempt, but is not sufficient to confirm the
   registration.

15.1.2.  NAME QUERY (DISCOVERY)

   Name query (also known as "resolution" or "discovery") is the
   procedure by which the IP address(es) associated with a NetBIOS name
   are discovered.  Name query is required during the following
   operations:

   During session establishment, calling and called names must be
   specified.  The calling name must exist on the node that posts the
   CALL.  The called name must exist on a node that has previously
   posted a LISTEN.  Either name may be a unique or group name.

   When a directed datagram is sent, a source and destination name must
   be specified.  If the destination name is a group name, a datagram is
   sent to all the members of that group.

   Different end-node types perform name resolution using different
   techniques, but using the same packet formats:

     -  B nodes solicit name information by broadcasting a request.

     -  P nodes ask the NBNS.

     -  M nodes broadcast a request.  If that does not provide the
        desired information, an inquiry is sent to the NBNS.

15.1.3.  NAME RELEASE

   NetBIOS names may be released explicitly or silently by an end- node.
   Silent release typically occurs when an end-node fails or is turned-
   off.  Most of the mechanisms described below are present to detect
   silent name release.

15.1.3.1.  EXPLICIT RELEASE

   B nodes explicitly release a name by broadcasting a notice.

   P nodes send a notification to their NBNS.

   M nodes both broadcast a notice and inform their supporting NBNS.

Top      Up      ToC       Page 29 
15.1.3.2.  NAME LIFETIME AND REFRESH

   Names held by an NBNS are given a lifetime during name registration.
   The NBNS will consider a name to have been silently released if the
   end-node fails to send a name refresh message to the NBNS before the
   lifetime expires.  A refresh restarts the lifetime clock.

   NOTE: The implementor should be aware of the tradeoff between
         accuracy of the database and the internet overhead that the
         refresh mechanism introduces.  The lifetime period should
         be tuned accordingly.


   For group names, each end-node must send refresh messages.  A node
   that fails to do so will be considered to have silently released the
   name and dropped from the group.

   The lifetime period is established through a simple negotiation
   mechanism during name registration:  In the name registration
   request, the end-node proposes a lifetime value or requests an
   infinite lifetime.  The NBNS places an actual lifetime value into the
   name registration response.  The NBNS is always allowed to respond
   with an infinite actual period.  If the end node proposed an infinite
   lifetime, the NBNS may respond with any definite period.  If the end
   node proposed a definite period, the NBNS may respond with any
   definite period greater than or equal to that proposed.

   This negotiation of refresh times gives the NBNS means to disable or
   enable refresh activity.  The end-nodes may set a minimum refresh
   cycle period.

   NBNS implementations which are completely reliable may disable
   refresh.

15.1.3.3.  NAME CHALLENGE

   To detect whether a node has silently released its claim to a name,
   it is necessary on occasion to challenge that node's current
   ownership.  If the node defends the name then the node is allowed to
   continue possession.  Otherwise it is assumed that the node has
   released the name.

   A name challenge may be issued by an NBNS or by a P or M node.  A
   challenge may be directed towards any end-node type: B, P, or M.

15.1.3.4.  GROUP NAME FADE-OUT

   NetBIOS groups may contain an arbitrarily large number of members.
   The time to challenge all members could be quite large.

   To avoid long delays when names are claimed through an NBNS, an

Top      Up      ToC       Page 30 
   optimistic heuristic has been adopted.  It is assumed that there will
   always be some node which will defend a group name.  Consequently, it
   is recommended that the NBNS will immediately reject a claim request
   for a unique name when there already exists a group with the same
   name.  The NBNS will never return an IP address (in response to a
   NAME REGISTRATION REQUEST) when a group name exists.

   An NBNS will consider a group to have faded out of existence when the
   last remaining member fails to send a timely refresh message or
   explicitly releases the name.

15.1.3.5.  NAME CONFLICT

   Name conflict exists when a unique name has been claimed by more than
   one node on a NetBIOS network.  B, M, and NBNS nodes may detect a
   name conflict.  The detection mechanism used by B and M nodes is
   active only during name discovery.  The NBNS may detect conflict at
   any time it verifies the consistency of its name database.

   B and M nodes detect conflict by examining the responses received in
   answer to a broadcast name query request.  The first response is
   taken as authoritative.  Any subsequent, inconsistent responses
   represent conflicts.

   Subsequent responses are inconsistent with the authoritative response
   when:

        The subsequent response has the same transaction ID as the
        NAME QUERY REQUEST.
     AND
        The subsequent response is not a duplicate of the
        authoritative response.
     AND EITHER:
             The group/unique characteristic of the authoritative
             response is "unique".
          OR
             The group/unique characteristic of the subsequent
             response is "unique".

   The period in which B and M nodes examine responses is limited by a
   conflict timer, CONFLICT_TIMER.  The accuracy or duration of this
   timer is not crucial: the NetBIOS system will continue to operate
   even with persistent name conflicts.

   Conflict conditions are signaled by sending a NAME CONFLICT DEMAND to
   the node owning the offending name.  Nothing is sent to the node
   which originated the authoritative response.

   Any end-node that receives NAME CONFLICT DEMAND is required to update
   its "local name table" to reflect that the name is in conflict.  (The
   "local name table" on each node contains names that have been

Top      Up      ToC       Page 31 
   successfully registered by that node.)

   Notice that only those nodes that receive the name conflict message
   place a conflict mark next to a name.

   Logically, a marked name does not exist on that node.  This means
   that the node should not defend the name (for name claim purposes),
   should not respond to a name discovery requests for that name, nor
   should the node send name refresh messages for that name.
   Furthermore, it can no longer be used by that node for any session
   establishment or sending or receiving datagrams.  Existing sessions
   are not affected at the time a name is marked as being in conflict.

   The only valid user function against a marked name is DELETE NAME.
   Any other user NetBIOS function returns immediately with an error
   code of "NAME CONFLICT".

15.1.4.  ADAPTER STATUS

   An end-node or the NBNS may ask any other end-node for a collection
   of information about the NetBIOS status of that node.  This status
   consists of, among other things, a list of the names which the node
   believes it owns.  The returned status is filtered to contain only
   those names which have the same NetBIOS scope identifier as the
   requestor's name.

   When requesting node status, the requestor identifies the target node
   by NetBIOS name  A name query transaction may be necessary to acquire
   the IP address for the name.  Locally cached name information may be
   used in lieu of a query transaction.  The requesting node sends a
   NODE STATUS REQUEST.  In response, the receiving node sends a NODE
   STATUS RESPONSE containing its local name table and various
   statistics.

   The amount of status which may be returned is limited by the size of
   a UDP packet.  However, this is sufficient for the typical NODE
   STATUS RESPONSE packet.

15.1.5.  END-NODE NBNS INTERACTION

   There are certain characteristics of end-node to NBNS interactions
   which are in common and are independent of any particular transaction
   type.

15.1.5.1.  UDP, TCP, AND TRUNCATION

   For all transactions between an end-node and an NBNS, either UDP or
   TCP may be used as a transport.  If the NBNS receives a UDP based
   request, it will respond using UDP.  If the amount of information
   exceeds what fits into a UDP packet, the response will contain a
   "truncation flag".  In this situation, the end- node may open a TCP

Top      Up      ToC       Page 32 
   connection to the NBNS, repeat the request, and receive a complete,
   untruncated response.

15.1.5.2.  NBNS WACK

   While a name service request is in progress, the NBNS may issue a
   WAIT FOR ACKNOWLEDGEMENT RESPONSE (WACK) to assure the client end-
   node that the NBNS is still operational and is working on the
   request.

15.1.5.3.  NBNS REDIRECTION

   The NBNS, because it follows Domain Name system styles of
   interaction, is permitted to redirect a client to another NBNS.

15.1.6.  SECURED VERSUS NON-SECURED NBNS

   An NBNS may be implemented in either of two general ways:  The NBNS
   may monitor, and participate in, name activity to ensure consistency.
   This would be a "secured" style NBNS.  Alternatively, an NBNS may be
   implemented to be essentially a "bulletin board" on which name
   information is posted and responsibility for consistency is delegated
   to the end-nodes.  This would be a "non-secured" style NBNS.

15.1.7.  CONSISTENCY OF THE NBNS DATA BASE

   Even in a properly running NetBIOS scope the NBNS and its community
   of end-nodes may occasionally lose synchronization with respect to
   the true state of name registrations.

   This may occur should the NBNS fail and lose all or part of its
   database.

   More commonly, a P or M node may be turned-off (thus forgetting the
   names it has registered) and then be subsequently turned back on.

   Finally, errors may occur or an implementation may be incorrect.

   Various approaches have been incorporated into the NetBIOS-over- TCP
   protocols to minimize the impact of these problems.

      1.   The NBNS (or any other node) may "challenge" (using a NAME
           QUERY REQUEST) an end-node to verify that it actually owns a
           name.

           Such a challenge may occur at any time.  Every end-node must
           be prepared to make a timely response.

           Failure to respond causes the NBNS to consider that the
           end-node has released the name in question.

Top      Up      ToC       Page 33 
           (If UDP is being used as the underlying transport, the
           challenge, like all other requests, must be retransmitted
           some number of times in the absence of a response.)

      2.   The NBNS (or any other node) may request (using the NODE
           STATUS REQUEST) that an end-node deliver its entire name
           table.

           This may occur at any time.  Every end-node must be prepared
           to make a timely response.

           Failure to respond permits (but does not require) the NBNS
           to consider that the end-node has failed and released all
           names to which it had claims.  (Like the challenge, on a UDP
           transport, the request must be retransmitted in the absence
           of a response.)

      3.   The NBNS may revoke a P or M node's use of a name by sending
           either a NAME CONFLICT DEMAND or a NAME RELEASE REQUEST to
           the node.

           The receiving end-node may continue existing sessions which
           use that name, but must otherwise cease using that name.  If
           the NBNS placed the name in conflict, the name may be re-
           acquired only by deletion and subsequent reclamation.  If
           the NBNS requested that the name be released, the node may
           attempt to re-acquire the name without first performing a
           name release transaction.

      4.   The NBNS may impose a "time-to-live" on each name it
           registers.  The registering node is made aware of this time
           value during the name registration procedure.

           Simple or reliable NBNS's may impose an infinite time-to-
           live.

      5.   If an end-node holds any names that have finite time-to-
           live values, then that node must periodically send a status
           report to the NBNS.  Each name is reported using the NAME
           REFRESH REQUEST packet.

           These status reports restart the timers of both the NBNS and
           the reporting node.  However, the only timers which are
           restarted are those associated with the name found in the
           status report.  Timers on other names are not affected.

           The NBNS may consider that a node has released any name
           which has not been refreshed within some multiple of name's
           time-to-live.

           A well-behaved NBNS, would, however, issue a challenge to-,

Top      Up      ToC       Page 34 
           or request a list of names from-, the non-reporting end-
           node before deleting its name(s).  The absence of a
           response, or of the name in a response, will confirm the
           NBNS decision to delete a name.

      6.   The absence of reports may cause the NBNS to infer that the
           end-node has failed.  Similarly, receipt of information
           widely divergent from what the NBNS believes about the node,
           may cause the NBNS to consider that the end-node has been
           restarted.

           The NBNS may analyze the situation through challenges or
           requests for a list of names.

      7.   A very cautious NBNS is free to poll nodes (by sending NAME
           QUERY REQUEST or NODE STATUS REQUEST packets) to verify that
           their name status is the same as that registered in the
           NBNS.

           NOTE:  Such polling activity, if used at all by an
           implementation, should be kept at a very low level or
           enabled only during periods when the NBNS has some reason to
           suspect that its information base is inaccurate.

      8.   P and M nodes can detect incorrect name information at
           session establishment.

           If incorrect information is found, NBNS is informed via a
           NAME RELEASE REQUEST originated by the end-node which
           detects the error.

15.1.8.  NAME CACHING

   An end-node may keep a local cache of NetBIOS name-to-IP address
   translation entries.

   All cache entries should be flushed on a periodic basis.

   In addition, a node ought to flush any cache information associated
   with an IP address if the node receives any information indicating
   that there may be any possibility of trouble with the node at that IP
   address.  For example, if a NAME CONFLICT DEMAND is sent to a node,
   all cached information about that node should be cleared within the
   sending node.

15.2.  NAME REGISTRATION TRANSACTIONS

15.2.1.  NAME REGISTRATION BY B NODES

   A name claim transaction initiated by a B node is broadcast
   throughout the broadcast area.  The NAME REGISTRATION REQUEST will be

Top      Up      ToC       Page 35 
   heard by all B and M nodes in the area.  Each node examines the claim
   to see whether it it is consistent with the names it owns.  If an
   inconsistency exists, a NEGATIVE NAME REGISTRATION RESPONSE is
   unicast to the requestor.  The requesting node obtains ownership of
   the name (or membership in the group) if, and only if, no NEGATIVE
   NAME REGISTRATION RESPONSEs are received within the name claim
   timeout, CONFLICT_TIMER.  (See "Defined Constants and Variables" in
   the Detailed Specification for the value of this timer.)

   A B node proclaims its new ownership by broadcasting a NAME OVERWRITE
   DEMAND.

                       B-NODE REGISTRATION PROCESS
   <-----NAME NOT ON NETWORK------>   <----NAME ALREADY EXISTS---->

   REQ. NODE                      NODE                     REQ.NODE
                                 HOLDING
                                  NAME

   (BROADCAST) REGISTER                        (BROADCAST) REGISTER
   ------------------->                        <-------------------

        REGISTER                                     REGISTER
   ------------------->                        <-------------------

        REGISTER                         NEGATIVE RESPONSE
   ------------------->             ------------------------------>

          OVERWRITE
   ------------------->               (NODE DOES NOT HAVE THE NAME)

   (NODE HAS THE NAME)

   The NAME REGISTRATION REQUEST, like any request, must be repeated if
   no response is received within BCAST_REQ_RETRY_TIMEOUT.  Transmission
   of the request is attempted BCAST_REQ_RETRY_COUNT times.

15.2.2.  NAME REGISTRATION BY P NODES

   A name registration may proceed in various  ways depending whether
   the name being registered is new to the NBNS.  If the name is known
   to the NBNS, then challenges may be sent to the prior holder(s).

15.2.2.1.  NEW NAME, OR NEW GROUP MEMBER

   The diagram, below, shows the sequence of events when an end-node
   registers a name which is new to the NBNS.  (The diagram omits WACKs,
   NBNS redirections, and retransmission of requests.)

   This same interaction will occur if the name being registered is a
   group name and the group already exists.  The NBNS will add the

Top      Up      ToC       Page 36 
   registrant to the set of group members.

                       P-NODE REGISTRATION PROCESS
            (server has no previous information about the name)

              P-NODE                            NBNS
                          REGISTER
                --------------------------------->

                        POSITIVE RESPONSE
                <---------------------------------

   The interaction is rather simple: the end-node sends a NAME
   REGISTRATION REQUEST, the NBNS responds with a POSITIVE NAME
   REGISTRATION RESPONSE.

15.2.2.2.  EXISTING NAME AND OWNER IS STILL ACTIVE

   The following diagram shows interactions when an attempt is made to
   register a unique name, the NBNS is aware of an existing owner, and
   that existing owner is still active.

   There are two sides to the diagram.  The left side shows how a non-
   secured NBNS would handle the matter.  Secured NBNS activity is shown
   on the right.

                       P-NODE REGISTRATION PROCESS
               (server HAS a previous owner that IS active)


   <------NON-SECURED STYLE------->  <---------SECURED STYLE------->

   REQ. NODE           NBNS       NODE         NBNS         REQ.NODE
                                 HOLDING
                                  NAME

         REGISTER                                      REGISTER
   ------------------->                         <-------------------
                                       QUERY
    END-NODE CHALLENGE              <------------
   <-------------------                QUERY
                                    <------------
             QUERY
   ----------------------------->
                                     POSITIVE RESP
             QUERY                   ------------>
   ----------------------------->                 NEGATIVE RESPONSE
                                                  ----------------->

         POSITIVE RESPONSE
   <----------------------------

Top      Up      ToC       Page 37 
   A non-secured NBNS will answer the NAME REGISTRATION REQUEST with a
   END-NODE CHALLENGE REGISTRATION RESPONSE.  This response asks the
   end-node to issue a challenge transaction against the node indicated
   in the response.  In this case, the prior node will defend against
   the challenge and the registering end-node will simply drop the
   registration attempt without further interaction with the NBNS.

   A secured NBNS will refrain from answering the NAME REGISTRATION
   REQUEST until the NBNS has itself challenged the prior holder(s) of
   the name.  In this case, the NBNS finds that that the name is still
   being defended and consequently returns a NEGATIVE NAME REGISTRATION
   RESPONSE to the registrant.

   Due to the potential time for the secured NBNS to make the
   challenge(s), it is likely that a WACK will be sent by the NBNS to
   the registrant.

   Although not shown in the diagram, a non-secured NBNS will send a
   NEGATIVE NAME REGISTRATION RESPONSE to a request to register a unique
   name when there already exists a group of the same name.  A secured
   NBNS may elect to poll (or challenge) the group members to determine
   whether any active members remain.  This may impose a heavy load on
   the network.  It is recommended that group names be allowed to fade-
   out through the name refresh mechanism.

15.2.2.3.  EXISTING NAME AND OWNER IS INACTIVE

   The following diagram shows interactions when an attempt is made to
   register a unique name, the NBNS is aware of an existing owner, and
   that existing owner is no longer active.

   A non-secured NBNS will answer the NAME REGISTRATION REQUEST with a
   END-NODE CHALLENGE REGISTRATION RESPONSE.  This response asks the
   end-node to issue a challenge transaction against the node indicated
   in the response.  In this case, the prior node will not defend
   against the challenge.  The registrant will inform the NBNS through a
   NAME OVERWRITE REQUEST.  The NBNS will replace the prior name
   information in its database with the information in the overwrite
   request.

   A secured NBNS will refrain from answering the NAME REGISTRATION
   REQUEST until the NBNS has itself challenged the prior holder(s) of
   the name.  In this case, the NBNS finds that that the name is not
   being defended and consequently returns a POSITIVE NAME REGISTRATION
   RESPONSE to the registrant.

Top      Up      ToC       Page 38 
                       P-NODE REGISTRATION PROCESS
             (server HAS a previous owner that is NOT active)


   <------NON-SECURED STYLE----->  <----------SECURED STYLE-------->

   REQ. NODE           NBNS     NODE           NBNS         REQ.NODE
                               HOLDING
                                NAME

         REGISTER                                    REGISTER
   ------------------->                         <-------------------
                                       QUERY
    END-NODE CHALLENGE             <------------
   <-------------------                QUERY
                                   <------------
         NAME QUERY REQUEST                        POSITIVE RESPONSE
   ---------------------------->                 ------------------>
              QUERY
   ---------------------------->

       OVERWRITE
   ------------------->

    POSITIVE RESPONSE
   <------------------

   Due to the potential time for the secured NBNS to make the
   challenge(s), it is likely that a WACK will be sent by the NBNS to
   the registrant.

   A secured NBNS will immediately send a NEGATIVE NAME REGISTRATION
   RESPONSE in answer to any NAME OVERWRITE REQUESTS it may receive.

15.2.3.  NAME REGISTRATION BY M NODES

   An M node begin a name claim operation as if the node were a B node:
   it broadcasts a NAME REGISTRATION REQUEST and listens for NEGATIVE
   NAME REGISTRATION RESPONSEs.  Any NEGATIVE NAME REGISTRATION RESPONSE
   prevents the M node from obtaining the name and terminates the claim
   operation.

   If, however, the M node does not receive any NEGATIVE NAME
   REGISTRATION RESPONSE, the M node must continue the claim procedure
   as if the M node were a P node.

   Only if both name claims were successful does the M node acquire the
   name.

   The following diagram illustrates M node name registration:

Top      Up      ToC       Page 39 
                       M-NODE REGISTRATION PROCESS

   <---NAME NOT IN BROADCAST AREA--> <--NAME IS IN BROADCAST AREA-->

   REQ. NODE                       NODE                     REQ.NODE
                                  HOLDING
                                   NAME

   (BROADCAST) REGISTER                         (BROADCAST) REGISTER
   ------------------->                         <-------------------

        REGISTER                                     REGISTER
   ------------------->                         <-------------------

        REGISTER                        NEGATIVE RESPONSE
   ------------------->             ------------------------------->


                 !                     (NODE DOES NOT HAVE THE NAME)
    INITIATE     !
    A P-NODE     !
    REGISTRATION !
                 V

15.3.  NAME QUERY TRANSACTIONS

   Name query transactions are initiated by end-nodes to obtain the IP
   address(es) and other attributes associated with a NetBIOS name.

15.3.1.  QUERY BY B NODES

   The following diagram shows how B nodes go about discovering who owns
   a name.

   The left half of the diagram illustrates what happens if there are no
   holders of the name.  In that case no responses are received in
   answer to the broadcast NAME QUERY REQUEST(s).

   The right half shows a POSITIVE NAME QUERY RESPONSE unicast by a name
   holder in answer to the broadcast request.  A name holder will make
   this response to every NAME QUERY REQUEST that it hears.  And each
   holder acts this way.  Thus, the node sending the request may receive
   many responses, some duplicates, and from many nodes.

Top      Up      ToC       Page 40 
                         B-NODE DISCOVERY PROCESS


   <------NAME NOT ON NETWORK------>  <---NAME PRESENT ON NETWORK-->

      REQ. NODE                    NODE                     REQ.NODE
                                  HOLDING
                                   NAME

       (BROADCAST) QUERY                           (BROADCAST) QUERY
   ---------------------->                    <---------------------

      NAME QUERY REQUEST                          NAME QUERY REQUEST
   ---------------------->                    <---------------------

           QUERY                        POSITIVE RESPONSE
   ---------------------->           ------------------------------>

   Name query is generally, but not necessarily, a prelude to NetBIOS
   session establishment or NetBIOS datagram transmission.  However,
   name query may be used for other purposes.

   A B node may elect to build a group membership list for subsequent
   use (e.g. for session establishment) by collecting and saving the
   responses.

15.3.2.  QUERY BY P NODES

   An NBNS answers queries from a P node with a list of IP address and
   other information for each owner of the name.  If there are multiple
   owners (i.e. if the name is a group name), the NBNS loads as many
   answers into the response as will fit into a UDP packet.  A
   truncation flag indicates whether any additional owner information
   remains.  All the information may be obtained by repeating the query
   over a TCP connection.

   The NBNS is not required to impose any order on its answer list.

   The following diagram shows what happens if the NBNS has no
   information about the name:

                      P-NODE DISCOVERY PROCESS
            (server has no information about the name)

              P-NODE                            NBNS
                        NAME QUERY REQUEST
                --------------------------------->

                        NEGATIVE RESPONSE
                <---------------------------------

Top      Up      ToC       Page 41 
   The next diagram illustrates interaction between the end-node and the
   NBNS when the NBNS does have information about the name.  This
   diagram shows, in addition, the retransmission of the request by the
   end-node in the absence of a timely response.  Also shown are WACKs
   (or temporary, intermediate responses) sent by the NBNS to the end-
   node:

                     P-NODE QUERY PROCESS
           (server HAS information about the name)

        P-NODE                                 NBNS
                       NAME QUERY REQUEST
        /---------------------------------------->
       /
       !          (OPTIONAL)   WACK
       !  <- - - - - - - - - - - - - - - - - - - -
       !         !
       !timer    !
       !         ! (optional timer restart)
       !         !
        \        V           QUERY
         \--------------------------------------->
                              .
                              .
                              .
                            QUERY
        /---------------------------------------->
       /
       !          (OPTIONAL)   WACK
       !  <- - - - - - - - - - - - - - - - - - - -
       !         !
       !timer    !
       !         ! (optional timer restart)
       !         !
        \        V           QUERY
         \--------------------------------------->
                              .
                              .

                    POSITIVE RESPONSE
         <-----------------------------------------


   The following diagram illustrates NBNS redirection.  Upon receipt of
   a NAME QUERY REQUEST, the NBNS redirects the client to another NBNS.
   The client repeats the request to the new NBNS and obtains a
   response.  The diagram shows that response as a POSITIVE NAME QUERY
   RESPONSE.  However any legal NBNS response may occur in actual
   operation.

Top      Up      ToC       Page 42 
                           NBNS REDIRECTION

              P-NODE                            NBNS
                         NAME QUERY REQUEST
                --------------------------------->

                    REDIRECT NAME QUERY RESPONSE
                <---------------------------------

       (START FROM THE
        VERY BEGINNING
        USING THE ADDRESS
        OF THE NEWLY
        SUPPLIED NBNS.)
                                                NEW
              P-NODE                            NBNS
                         NAME QUERY REQUEST
                --------------------------------->

                   POSITIVE NAME QUERY RESPONSE
                <---------------------------------

   The next diagram shows how a P or M node tells the NBNS that the NBNS
   has provided incorrect information.  This procedure may begin after a
   DATAGRAM ERROR packet has been received or a session set-up attempt
   has discovered that the NetBIOS name does not exist at the
   destination, the IP address of which was obtained from the NBNS
   during a prior name query transaction.  The NBNS, in this case a
   secure NBNS, issues queries to verify whether the information is, in
   fact, incorrect.  The NBNS closes the transaction by sending either a
   POSITIVE or NEGATIVE NAME RELEASE RESPONSE, depending on the results
   of the verification.

                 CORRECTING NBNS INFORMATION BASE

              P-NODE                            NBNS
                       NAME RELEASE REQUEST
                --------------------------------->
                                                        QUERY
                                                  ---------------->

                                                        QUERY
                                                  ---------------->

                                      (NAME TAKEN OFF THE DATABASE
                                       IF NBNS FINDS IT TO BE
                                       INCORRECT)

                    POSITIVE/NEGATIVE RESPONSE
                <---------------------------------

Top      Up      ToC       Page 43 
15.3.3.  QUERY BY M NODES

   M node name query follows the B node pattern.  In the absence of
   adequate results, the M node then continues by performing a P node
   type query.  This is shown in the following diagram:

                       M-NODE DISCOVERY PROCESS


   <---NAME NOT ON BROADCAST AREA-->  <--NAME IS ON BROADCAST AREA->

   REQ. NODE                       NODE                     REQ.NODE
                                  HOLDING
                                   NAME

       (BROADCAST) QUERY                           (BROADCAST) QUERY
   --------------------->                    <----------------------

     NAME QUERY REQUEST                           NAME QUERY REQUEST
   --------------------->                    <----------------------

           QUERY                           POSITIVE RESPONSE
   --------------------->           ------------------------------->

                   !
       INITIATE    !
       A P-NODE    !
       DISCOVERY   !
       PROCESS     !
                   V



15.3.4.  ACQUIRE GROUP MEMBERSHIP LIST

   The entire membership of a group may be acquired by sending a NAME
   QUERY REQUEST to the NBNS.  The NBNS will respond with a POSITIVE
   NAME QUERY RESPONSE or a NEGATIVE NAME QUERY RESPONSE.  A negative
   response completes the procedure and indicates that there are no
   members in the group.

   If the positive response has the truncation bit clear, then the
   response contains the entire list of group members.  If the
   truncation bit is set, then this entire procedure must be repeated,
   but using TCP as a foundation rather than UDP.

Top      Up      ToC       Page 44 
15.4.  NAME RELEASE TRANSACTIONS

15.4.1.  RELEASE BY B NODES

   A NAME RELEASE DEMAND contains the following information:

     -  NetBIOS name
     -  The scope of the NetBIOS name
     -  Name type: unique or group
     -  IP address of the releasing node
     -  Transaction ID

   REQUESTING                                     OTHER
   B-NODE                                         B-NODES
                     NAME RELEASE DEMAND
              ---------------------------------->

15.4.2.  RELEASE BY P NODES

   A NAME RELEASE REQUEST contains the following information:

     -  NetBIOS name
     -  The scope of the NetBIOS name
     -  Name type: unique or group
     -  IP address of the releasing node
     -  Transaction ID


   A NAME RELEASE RESPONSE contains the following information:

     -  NetBIOS name
     -  The scope of the NetBIOS name
     -  Name type: unique or group
     -  IP address of the releasing node
     -  Transaction ID
     -  Result:
          -  Yes: name was released
          -  No: name was not released, a reason code is provided

   REQUESTING
   P-NODE                                         NBNS
                     NAME RELEASE REQUEST
              ---------------------------------->

                     NAME RELEASE RESPONSE
              <---------------------------------

15.4.3.  RELEASE BY M NODES

   The name release procedure of the M node is a combination of the P
   and B node name release procedures.  The M node first performs the P

Top      Up      ToC       Page 45 
   release procedure.  If the P procedure fails then the release
   procedure does not continue, it fails.  If and only if the P
   procedure succeeds then the M node broadcasts the NAME RELEASE DEMAND
   to the broadcast area, the B procedure.

   NOTE: An M node typically performs a B-style operation and then a
         P-style operation.  In this case, however, the P-style
         operation comes first.

   The following diagram illustrates the M node name release procedure:

   <-----P procedure fails-------> <-------P procedure succeeds--->

   REQUESTING               NBNS    REQUESTING             NBNS
   M-NODE                           M-NODE

       NAME RELEASE REQUEST               NAME RELEASE REQUEST
     -------------------------->       ------------------------>

       NEGATIVE RELEASE RESPONSE        POSITIVE RELEASE RESPONSE
     <--------------------------       <-------------------------

                                                           OTHER
                                                           M-NODES

                                           NAME RELEASE DEMAND
                                        ------------------------>

15.5.  NAME MAINTENANCE TRANSACTIONS

15.5.1.  NAME REFRESH

   Name refresh transactions are used to handle the following
   situations:

      a)   An NBNS node needs to detect if a P or M node has "silently"
           gone down, so that names held by that node can be purged
           from the data base.


      b)   If the NBNS goes down, it needs to be able to reconstruct
           the data base when it comes back up.


      c)   If the network should be partitioned, the NBNS needs to be
           able to able to update its data base when the network
           reconnects.

   Each P or M node is responsible for sending periodic NAME REFRESH
   REQUESTs for each name that it has registered.  Each refresh packet
   contains a single name that has been successfully registered by that

Top      Up      ToC       Page 46 
   node.  The interval between such packets is negotiated between the
   end node and the NBNS server at the time that the name is initially
   claimed.  At name claim time, an end node will suggest a refresh
   timeout value.  The NBNS node can modify this value in the reply
   packet.  A NBNS node can also choose to tell the end node to not send
   any refresh packet by using the "infinite" timeout value in the
   response packet.  The timeout value returned by the NBNS is the
   actual refresh timeout that the end node must use.

   When a node sends a NAME REFRESH REQUEST, it must be prepared to
   receive a negative response.  This would happen, for example, if the
   the NBNS discovers that the the name had already been assigned to
   some other node.  If such a response is received, the end node should
   mark the name as being in conflict.  Such an entry should be treated
   in the same way as if name conflict had been detected against the
   name.  The following diagram illustrates name refresh:

   <-----Successful Refresh-----> <-----Unsuccessful Refresh---->

   REFRESHING               NBNS   REFRESHING               NBNS
   NODE                            NODE

       NAME REFRESH REQUEST             NAME REFRESH REQUEST
     ------------------------>        ----------------------->

         POSITIVE RESPONSE                NEGATIVE RESPONSE
     <------------------------        <-----------------------
                                    !
                                    !
                                    V
                              MARK NAME IN
                                CONFLICT

15.5.2.  NAME CHALLENGE

   Name challenge is done by sending a NAME QUERY REQUEST to an end node
   of any type.  If a POSITIVE NAME QUERY RESPONSE is returned, then
   that node still owns the name.  If a NEGATIVE NAME QUERY RESPONSE is
   received or if no response is received, it can be assumed that the
   end node no longer owns the name.

   Name challenge can be performed either by the NBNS node, or by an end
   node.  When an end-node sends a name claim packet, the NBNS node may
   do the challenge operation.  The NBNS node can choose, however, to
   require the end node do the challenge.  In that case, the NBNS will
   send an END-NODE CHALLENGE RESPONSE packet to the end node, which
   should then proceed to challenge the putative owner.

   Note that the name challenge procedure sends a normal NAME QUERY
   REQUEST packet to the end node.  It does not require a special
   packet.  The only new packet introduced is the END-NODE CHALLENGE

Top      Up      ToC       Page 47 
   RESPONSE which is sent by an NBNS node when the NBNS wants the end-
   node to perform the challenge operation.

15.5.3.  CLEAR NAME CONFLICT

   It is possible during a refresh request from a M or P node for a NBNS
   to detects a name in conflict.  The response to the NAME REFRESH
   REQUEST must be a NEGATIVE NAME REGISTRATION RESPONSE.  Optionally,
   in addition, the NBNS may send a NAME CONFLICT DEMAND or a NAME
   RELEASE REQUEST to the refreshing node.  The NAME CONFLICT DEMAND
   forces the node to place the name in the conflict state.  The node
   will eventually inform it's user of the conflict.  The NAME RELEASE
   REQUEST will force the node to flush the name from its local name
   table completely.  This forces the node to flush the name in
   conflict.  This does not cause termination of existing sessions using
   this name.

   The following diagram shows an NBNS detecting and correcting a
   conflict:

   REFRESHING NODE                                 NBNS

                     NAME REFRESH REQUEST
           ----------------------------------------->

               NEGATIVE NAME REGISTRATION RESPONSE
           <-----------------------------------------

                     NAME CONFLICT DEMAND
           <-----------------------------------------

                             OR

                     NAME RELEASE REQUEST
           <-----------------------------------------

               POSITIVE/NEGATIVE RELEASE REQUEST
           ----------------------------------------->

15.6.  ADAPTER STATUS TRANSACTIONS

   Adapter status is obtained from a node as follows:

      1.   Perform a name discovery operation to obtain the IP
           addresses of a set of end-nodes.

      2.   Repeat until all end-nodes from the set have been used:

           a.   Select one end-node from the set.

           b.   Send a NODE STATUS REQUEST to that end-node using UDP.

Top      Up      ToC       Page 48 
           c.   Await a NODE STATUS RESPONSE.  (If a timely response is
                not forthcoming, repeat step "b" UCAST_REQ_RETRY_COUNT
                times.  After the last retry, go to step "a".)

           d.   If the truncation bit is not set in the response, the
                response contains the entire node status.  Return the
                status to the user and terminate this procedure.

           e.   If the truncation bit is set in the response, then not
                all status was returned because it would not fit into
                the response packet.  The responder will set the
                truncation bit if the IP datagram length would exceed
                MAX_DATAGRAM_LENGTH.  Return the status to the user and
                terminate this procedure.


3.   Return error to user, no status obtained.

   The repetition of step 2, above, through all nodes of the set, is
   optional.

   Following is an example transaction of a successful Adapter Status
   operation:

   REQUESTING NODE                                 NAME OWNER

                       NAME QUERY REQUEST
           ----------------------------------------->

                   POSITIVE NAME QUERY RESPONSE
           <-----------------------------------------

                       NODE STATUS REQUEST
           ----------------------------------------->

                      NODE STATUS RESPONSE
           <-----------------------------------------



(page 48 continued on part 3)

Next RFC Part