rfc1001.txt

中、英文RFC文档大全打包下载完全版 .

   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



NetBIOS Working Group                                          [Page 18]

RFC 1001                                                      March 1987


   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.






NetBIOS Working Group                                          [Page 19]

RFC 1001                                                      March 1987


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.





NetBIOS Working Group                                          [Page 20]

RFC 1001                                                      March 1987


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.







NetBIOS Working Group                                          [Page 21]

RFC 1001                                                      March 1987


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.























NetBIOS Working Group                                          [Page 22]

RFC 1001                                                      March 1987


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.



NetBIOS Working Group                                          [Page 23]

RFC 1001                                                      March 1987


   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