Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1001

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

Pages: 68
Internet Standard: 19
Errata
STD 19 is also:  1002
Part 1 of 3 – Pages 1 to 16
None   None   Next

Top   ToC   RFC1001 - Page 1
Network Working Group
Request for Comments: 1001                                March, 1987




             PROTOCOL STANDARD FOR A NetBIOS SERVICE
                     ON A TCP/UDP TRANSPORT:
                      CONCEPTS AND METHODS




ABSTRACT

This RFC defines a proposed standard protocol to support NetBIOS
services in a TCP/IP environment.  Both local network and internet
operation are supported.  Various node types are defined to accommodate
local and internet topologies and to allow operation with or without the
use of IP broadcast.

This RFC describes the NetBIOS-over-TCP protocols in a general manner,
emphasizing the underlying ideas and techniques.  Detailed
specifications are found in a companion RFC, "Protocol Standard For a
NetBIOS Service on a TCP/UDP Transport: Detailed Specifications".
Top   ToC   RFC1001 - Page 2
                       SUMMARY OF CONTENTS


1.  STATUS OF THIS MEMO                                             6
2.  ACKNOWLEDGEMENTS                                                6
3.  INTRODUCTION                                                    7
4.  DESIGN PRINCIPLES                                               7
5.  OVERVIEW OF NetBIOS                                            10
6.  NetBIOS FACILITIES SUPPORTED BY THIS STANDARD                  15
7.  REQUIRED SUPPORTING SERVICE INTERFACES AND DEFINITIONS         15
8.  RELATED PROTOCOLS AND SERVICES                                 16
9.  NetBIOS SCOPE                                                  16
10.  NetBIOS END-NODES                                             16
11.  NetBIOS SUPPORT SERVERS                                       18
12.  TOPOLOGIES                                                    20
13.  GENERAL METHODS                                               23
14.  REPRESENTATION OF NETBIOS NAMES                               25
15.  NetBIOS NAME SERVICE                                          27
16.  NetBIOS SESSION SERVICE                                       48
17.  NETBIOS DATAGRAM SERVICE                                      55
18.  NODE CONFIGURATION PARAMETERS                                 58
19.  MINIMAL CONFORMANCE                                           59
REFERENCES                                                         60
APPENDIX A - INTEGRATION WITH INTERNET GROUP MULTICASTING          61
APPENDIX B - IMPLEMENTATION CONSIDERATIONS                         62
Top   ToC   RFC1001 - Page 3
TABLE OF CONTENTS


 1.  STATUS OF THIS MEMO                                            6

 2.  ACKNOWLEDGEMENTS                                               6

 3.  INTRODUCTION                                                   7

 4.  DESIGN PRINCIPLES                                              8
  4.1  PRESERVE NetBIOS SERVICES                                    8
  4.2  USE EXISTING STANDARDS                                       8
  4.3  MINIMIZE OPTIONS                                             8
  4.4  TOLERATE ERRORS AND DISRUPTIONS                              8
  4.5  DO NOT REQUIRE CENTRAL MANAGEMENT                            9
  4.6  ALLOW INTERNET OPERATION                                     9
  4.7  MINIMIZE BROADCAST ACTIVITY                                  9
  4.8  PERMIT IMPLEMENTATION ON EXISTING SYSTEMS                    9
  4.9  REQUIRE ONLY THE MINIMUM NECESSARY TO OPERATE                9
  4.10  MAXIMIZE EFFICIENCY                                        10
  4.11  MINIMIZE NEW INVENTIONS                                    10

 5.  OVERVIEW OF NetBIOS                                           10
  5.1  INTERFACE TO APPLICATION PROGRAMS                           10
  5.2  NAME SERVICE                                                11
  5.3  SESSION SERVICE                                             12
  5.4  DATAGRAM SERVICE                                            13
  5.5  MISCELLANEOUS FUNCTIONS                                     14
  5.6  NON-STANDARD EXTENSIONS                                     15

 6.  NetBIOS FACILITIES SUPPORTED BY THIS STANDARD                 15

 7.  REQUIRED SUPPORTING SERVICE INTERFACES AND DEFINITIONS        15

 8.  RELATED PROTOCOLS AND SERVICES                                16

 9.  NetBIOS SCOPE                                                 16

 10.  NetBIOS END-NODES                                            16
  10.1  BROADCAST (B) NODES                                        16
  10.2  POINT-TO-POINT (P) NODES                                   16
  10.3  MIXED MODE (M) NODES                                       16

 11.  NetBIOS SUPPORT SERVERS                                      18
  11.1  NetBIOS NAME SERVER (NBNS) NODES                           18
     11.1.1  RELATIONSHIP OF THE NBNS TO THE DOMAIN NAME SYSTEM    19
  11.2  NetBIOS DATAGRAM DISTRIBUTION SERVER (NBDD) NODES          19
  11.3  RELATIONSHIP OF NBNS AND NBDD NODES                        20
  11.4  RELATIONSHIP OF NetBIOS SUPPORT SERVERS AND B NODES        20
 12.  TOPOLOGIES                                                   20
  12.1  LOCAL                                                      20
Top   ToC   RFC1001 - Page 4
     12.1.1  B NODES ONLY                                          21
     12.1.2  P NODES ONLY                                          21
     12.1.3  MIXED B AND P NODES                                   21
  12.2  INTERNET                                                   22
     12.2.1  P NODES ONLY                                          22
     12.2.2  MIXED M AND P NODES                                   23

 13.  GENERAL METHODS                                               23
  13.1  REQUEST/RESPONSE INTERACTION STYLE                         23
     13.1.1  RETRANSMISSION OF REQUESTS                            24
     13.1.2  REQUESTS WITHOUT RESPONSES: DEMANDS                   24
  13.2  TRANSACTIONS                                               25
     13.2.1  TRANSACTION ID                                        25
  13.3  TCP AND UDP FOUNDATIONS                                    25

 14.  REPRESENTATION OF NETBIOS NAMES                               25
  14.1  FIRST LEVEL ENCODING                                       26
  14.2  SECOND LEVEL ENCODING                                      27

 15.  NetBIOS NAME SERVICE                                          27
  15.1  OVERVIEW OF NetBIOS NAME SERVICE                           27
     15.1.1  NAME REGISTRATION (CLAIM)                             27
     15.1.2  NAME QUERY (DISCOVERY)                                28
     15.1.3  NAME RELEASE                                          28
       15.1.3.1  EXPLICIT RELEASE                                  28
       15.1.3.2  NAME LIFETIME AND REFRESH                         29
       15.1.3.3  NAME CHALLENGE                                    29
       15.1.3.4  GROUP NAME FADE-OUT                               29
     15.1.3.5  NAME CONFLICT                                       30
     15.1.4  ADAPTER STATUS                                        31
     15.1.5  END-NODE NBNS INTERACTION                             31
       15.1.5.1  UDP, TCP, AND TRUNCATION                          31
       15.1.5.2  NBNS WACK                                         32
       15.1.5.3  NBNS REDIRECTION                                  32
     15.1.6  SECURED VERSUS NON-SECURED NBNS                       32
     15.1.7  CONSISTENCY OF THE NBNS DATA BASE                     32
     15.1.8  NAME CACHING                                          34
  15.2  NAME REGISTRATION TRANSACTIONS                             34
     15.2.1  NAME REGISTRATION BY B NODES                          34
     15.2.2  NAME REGISTRATION BY P NODES                          35
       15.2.2.1  NEW NAME, OR NEW GROUP MEMBER                     35
       15.2.2.2  EXISTING NAME AND OWNER IS STILL ACTIVE           36
       15.2.2.3  EXISTING NAME AND OWNER IS INACTIVE               37
     15.2.3  NAME REGISTRATION BY M NODES                          38
  15.3  NAME QUERY TRANSACTIONS                                    39
     15.3.1  QUERY BY B NODES                                      39
     15.3.2  QUERY BY P NODES                                      40
     15.3.3  QUERY BY M NODES                                      43
     15.3.4  ACQUIRE GROUP MEMBERSHIP LIST                         43
  15.4  NAME RELEASE TRANSACTIONS                                  44
     15.4.1  RELEASE BY B NODES                                    44
Top   ToC   RFC1001 - Page 5
     15.4.2  RELEASE BY P NODES                                    44
     15.4.3  RELEASE BY M NODES                                    44
  15.5  NAME MAINTENANCE TRANSACTIONS                              45
     15.5.1  NAME REFRESH                                          45
     15.5.2  NAME CHALLENGE                                        46
     15.5.3  CLEAR NAME CONFLICT                                   47
  15.6  ADAPTER STATUS TRANSACTIONS                                47

 16.  NetBIOS SESSION SERVICE                                      48
  16.1  OVERVIEW OF NetBIOS SESSION SERVICE                        49
     16.1.1  SESSION ESTABLISHMENT PHASE OVERVIEW                  49
       16.1.1.1  RETRYING AFTER BEING RETARGETTED                  50
       16.1.1.2  SESSION ESTABLISHMENT TO A GROUP NAME             51
     16.1.2  STEADY STATE PHASE OVERVIEW                           51
     16.1.3  SESSION TERMINATION PHASE OVERVIEW                    51
  16.2  SESSION ESTABLISHMENT PHASE                                52
  16.3  SESSION DATA TRANSFER PHASE                                54
     16.3.1  DATA ENCAPSULATION                                    54
     16.3.2  SESSION KEEP-ALIVES                                   54

 17.  NETBIOS DATAGRAM SERVICE                                     55
  17.1  OVERVIEW OF NetBIOS DATAGRAM SERVICE                       55
     17.1.1  UNICAST, MULTICAST, AND BROADCAST                     55
     17.1.2  FRAGMENTATION OF NetBIOS DATAGRAMS                    55
  17.2  NetBIOS DATAGRAMS BY B NODES                               57
  17.3  NetBIOS DATAGRAMS BY P AND M NODES                         58

 18.  NODE CONFIGURATION PARAMETERS                                58

 19.  MINIMAL CONFORMANCE                                          59

 REFERENCES                                                        60

 APPENDIX A                                                        61

 INTEGRATION WITH INTERNET GROUP MULTICASTING                      61
  A-1.  ADDITIONAL PROTOCOL REQUIRED IN B AND M NODES              61
  A-2.  CONSTRAINTS                                                61

 APPENDIX B                                                        62

 IMPLEMENTATION CONSIDERATIONS                                     62
  B-1.  IMPLEMENTATION MODELS                                      62
     B-1.1  MODEL INDEPENDENT CONSIDERATIONS                       63
     B-1.2  SERVICE OPERATION FOR EACH MODEL                       63
  B-2.  CASUAL AND RESTRICTED NetBIOS APPLICATIONS                 64
  B-3.  TCP VERSUS SESSION KEEP-ALIVES                             66
  B-4.  RETARGET ALGORITHMS                                        67
  B-5.  NBDD SERVICE                                               68
  B-6.  APPLICATION CONSIDERATIONS                                 68
     B-6.1  USE OF NetBIOS DATAGRAMS                               68
Top   ToC   RFC1001 - Page 6
             PROTOCOL STANDARD FOR A NetBIOS SERVICE
                     ON A TCP/UDP TRANSPORT:
                      CONCEPTS AND METHODS


1.  STATUS OF THIS MEMO

   This RFC specifies a proposed standard for the Internet
   community.  Since this topic is new to the Internet community,
   discussions and suggestions are specifically requested.

   Please send written comments to:

           Karl Auerbach
           Epilogue Technology Corporation
           P.O. Box 5432
           Redwood City, CA   94063

   Please send online comments to:

           Avnish Aggarwal
                   Internet: mtxinu!excelan!avnish@ucbvax.berkeley.edu
                   Usenet:   ucbvax!mtxinu!excelan!avnish

   Distribution of this document is unlimited.

2.  ACKNOWLEDGEMENTS

   This RFC has been developed under the auspices of the Internet
   Activities Board, especially the End-to-End Services Task Force.

   The following individuals have contributed to the development of
   this RFC:

   Avnish Aggarwal       Arvind Agrawal        Lorenzo Aguilar
   Geoffrey Arnold       Karl Auerbach         K. Ramesh Babu
   Keith Ball            Amatzia Ben-Artzi     Vint Cerf
   Richard Cherry        David Crocker         Steve Deering
   Greg Ennis            Steve Holmgren        Jay Israel
   David Kaufman         Lee LaBarre           James Lau
   Dan Lynch             Gaylord Miyata        David Stevens
   Steve Thomas          Ishan Wu

   The system proposed by this RFC does not reflect any existing
   Netbios-over-TCP implementation.  However, the design
   incorporates considerable knowledge obtained from prior
   implementations.  Special thanks goes to the following
   organizations which have provided this invaluable information:

   CMC/Syros      Excelan        Sytek          Ungermann-Bass
Top   ToC   RFC1001 - Page 7
3.  INTRODUCTION

   This RFC describes the ideas and general methods used to provide
   NetBIOS on a TCP and UDP foundation.  A companion RFC, "Protocol
   Standard For a NetBIOS Service on a TCP/UDP Transport: Detailed
   Specifications"[1] contains detailed descriptions of packet
   formats, protocols, and defined constants and variables.

   The NetBIOS service has become the dominant mechanism for
   personal computer networking.  NetBIOS provides a vendor
   independent interface for the IBM Personal Computer (PC) and
   compatible systems.

   NetBIOS defines a software interface not a protocol.  There is no
   "official" NetBIOS service standard.  In practice, however, the
   IBM PC-Network version is used as a reference.  That version is
   described in the IBM document 6322916, "Technical Reference PC
   Network"[2].

   Protocols supporting NetBIOS services have been constructed on
   diverse protocol and hardware foundations.  Even when the same
   foundation is used, different implementations may not be able to
   interoperate unless they use a common protocol.  To allow NetBIOS
   interoperation in the Internet, this RFC defines a standard
   protocol to support NetBIOS services using TCP and UDP.

   NetBIOS has generally been confined to personal computers to
   date.  However, since larger computers are often well suited to
   run certain NetBIOS applications, such as file servers, this
   specification has been designed to allow an implementation to be
   built on virtually any type of system where the TCP/IP protocol
   suite is available.

   This standard defines a set of protocols to support NetBIOS
   services.

   These protocols are more than a simple communications service
   involving two entities.  Rather, this note describes a
   distributed system in which many entities play a part even if
   they are not involved as an end-point of a particular NetBIOS
   connection.

   This standard neither constrains nor determines how those
   services are presented to application programs.

   Nevertheless, it is expected that on computers operating under
   the PC-DOS and MS-DOS operating systems that the existing NetBIOS
   interface will be preserved by implementors.

   NOTE: Various symbolic values are used in this document.  For
         their definitions, refer to the Detailed Specifications[1].
Top   ToC   RFC1001 - Page 8
4.  DESIGN PRINCIPLES

   In order to develop the specification the following design principles
   were adopted to guide the effort.  Most are typical to any protocol
   standardization effort; however, some have been assigned priorities
   that may be considered unusual.

4.1.  PRESERVE NetBIOS SERVICES

   In the absence of an "official" standard for NetBIOS services, the
   version found in the IBM PC Network Technical Reference[2] is used.

   NetBIOS is the foundation of a large body of existing applications.
   It is desirable to operate these applications on TCP networks and to
   extend them beyond personal computers into larger hosts.  To support
   these applications, NetBIOS on TCP must closely conform to the
   services offered by existing NetBIOS systems.

   IBM PC-Network NetBIOS contains some implementation specific
   characteristics.  This standard does not attempt to completely
   preserve these.  It is certain that some existing software requires
   these characteristics and will fail to operate correctly on a NetBIOS
   service based on this RFC.

4.2.  USE EXISTING STANDARDS

   Protocol development, especially with standardization, is a demanding
   process.  The development of new protocols must be minimized.

   It is considered essential that an existing standard which provides
   the necessary functionality with reasonable performance always be
   chosen in preference to developing a new protocol.

   When a standard protocol is used, it must be unmodified.

4.3.  MINIMIZE OPTIONS

   The standard for NetBIOS on TCP should contain few, if any, options.

   Where options are included, the options should be designed so that
   devices with different option selections should interoperate.

4.4.  TOLERATE ERRORS AND DISRUPTIONS

   NetBIOS networks typically operate in an uncontrolled environment.
   Computers come on-line at arbitrary times.  Computers usually go
   off-line without any notice to their peers.  The software is often
   operated by users who are unfamiliar with networks and who may
   randomly perturb configuration settings.

   Despite this chaos, NetBIOS networks work.  NetBIOS on TCP must also
Top   ToC   RFC1001 - Page 9
   be able to operate well in this environment.

   Robust operation does not necessarily mean that the network is proof
   against all disruptions.  A typical NetBIOS network may be disrupted
   by certain types of behavior, whether inadvertent or malicious.

4.5.  DO NOT REQUIRE CENTRAL MANAGEMENT

   NetBIOS on TCP should be able to operate, if desired, without
   centralized management beyond that typically required by a TCP based
   network.

4.6.  ALLOW INTERNET OPERATION

   The proposed standard recognizes the need for NetBIOS operation
   across a set of networks interconnected by network (IP) level relays
   (gateways.)

   However, the standard assumes that this form of operation will be
   less frequent than on the local MAC bridged-LAN.

4.7.  MINIMIZE BROADCAST ACTIVITY

   The standard pre-supposes that the only broadcast services are those
   supported by UDP.  Multicast capabilities are not assumed to be
   available in any form.

   Despite the availability of broadcast capabilities, the standard
   recognizes that some administrations may wish to avoid heavy
   broadcast activity.  For example, an administration may wish to avoid
   isolated non-participating hosts from the burden of receiving and
   discarding NetBIOS broadcasts.

4.8.  PERMIT IMPLEMENTATION ON EXISTING SYSTEMS

   The NetBIOS on TCP protocol should be implementable on common
   operating systems, such as Unix(tm) and VAX/VMS(tm), without massive
   effort.

   The NetBIOS protocols should not require services typically
   unavailable on presently existing TCP/UDP/IP implementations.

4.9.  REQUIRE ONLY THE MINIMUM NECESSARY TO OPERATE

   The protocol definition should specify only the minimal set of
   protocols required for interoperation.  However, additional protocol
   elements may be defined to enhance efficiency.  These latter elements
   may be generated at the option of the sender, although they must be
   accepted by all receivers.
Top   ToC   RFC1001 - Page 10
4.10.  MAXIMIZE EFFICIENCY

   To be useful, a protocol must conduct its business quickly.

4.11.  MINIMIZE NEW INVENTIONS

   When an existing protocol is not quite able to support a necessary
   function, but with a small amount of change, it could, that protocol
   should be used.  This is felt to be easier to achieve than
   development of new protocols; further, it is likely to have more
   general utility for the Internet.

5.  OVERVIEW OF NetBIOS

   This section describes the NetBIOS services.  It is for background
   information only.  The reader may chose to skip to the next section.

   NetBIOS was designed for use by groups of PCs, sharing a broadcast
   medium.  Both connection (Session) and connectionless (Datagram)
   services are provided, and broadcast and multicast are supported.
   Participants are identified by name.  Assignment of names is
   distributed and highly dynamic.

   NetBIOS applications employ NetBIOS mechanisms to locate resources,
   establish connections, send and receive data with an application
   peer, and terminate connections.  For purposes of discussion, these
   mechanisms will collectively be called the NetBIOS Service.

   This service can be implemented in many different ways.  One of the
   first implementations was for personal computers running the PC-DOS
   and MS-DOS operating systems.  It is possible to implement NetBIOS
   within other operating systems, or as processes which are,
   themselves, simply application programs as far as the host operating
   system is concerned.

   The NetBIOS specification, published by IBM as "Technical Reference
   PC Network"[2] defines the interface and services available to the
   NetBIOS user.  The protocols outlined by that document pertain only
   to the IBM PC Network and are not generally applicable to other
   networks.

5.1.  INTERFACE TO APPLICATION PROGRAMS

   NetBIOS on personal computers includes both a set of services and an
   exact program interface to those services.  NetBIOS on other computer
   systems may present the NetBIOS services to programs using other
   interfaces.  Except on personal computers, no clear standard for a
   NetBIOS software interface has emerged.
Top   ToC   RFC1001 - Page 11
5.2.  NAME SERVICE

   NetBIOS resources are referenced by name.  Lower-level address
   information is not available to NetBIOS applications.  An
   application, representing a resource, registers one or more names
   that it wishes to use.

   The name space is flat and uses sixteen alphanumeric characters.
   Names may not start with an asterisk (*).

   Registration is a bid for use of a name.  The bid may be for
   exclusive (unique) or shared (group) ownership.  Each application
   contends with the other applications in real time.  Implicit
   permission is granted to a station when it receives no objections.
   That is, a bid is made and the application waits for a period of
   time.  If no objections are received, the station assumes that it has
   permission.

   A unique name should be held by only one station at a time.  However,
   duplicates ("name conflicts") may arise due to errors.

   All instances of a group name are equivalent.

   An application referencing a name generally does not know (or care)
   whether the name is registered as a unique or a group name.

   An explicit name deletion function is specified, so that applications
   may remove a name.  Implicit name deletion occurs when a station
   ceases operation.  In the case of personal computers, implicit name
   deletion is a frequent occurrence.

   The Name Service primitives are:

      1)   Add Name

           The requesting application wants exclusive use of the name.

      2)   Add Group Name

           The requesting application is willing to share use of the
           name with other applications.

      3)   Delete Name

           The application no longer requires use of the name.  It is
           important to note that typical use of NetBIOS is among
           independently-operated personal computers.  A common way to
           stop using a PC is to turn it off; in this case, the
           graceful give-back mechanism, provided by the Delete Name
           function, is not used.  Because this occurs frequently, the
           network service must support this behavior.
Top   ToC   RFC1001 - Page 12
5.3.  SESSION SERVICE

   A session is a reliable message exchange, conducted between a pair of
   NetBIOS applications.  Sessions are full-duplex, sequenced, and
   reliable.  Data is organized into messages.  Each message may range
   in size from 0 to 131,071 bytes.  No expedited or urgent data
   capabilities are present.

   Multiple sessions may exist between any pair of calling and called
   names.

   The parties to a connection have access to the calling and called
   names.

   The NetBIOS specification does not define how a connection request to
   a shared (group) name resolves into a session.  The usual assumption
   is that a session may be established with any one owner of the called
   group name.

   An important service provided to NetBIOS applications is the
   detection of sessions failure.  The loss of a session is reported to
   an application via all of the outstanding service requests for that
   session.  For example, if the application has only a NetBIOS receive
   primitive pending and the session terminates, the pending receive
   will abort with a termination indication.

   Session Service primitives are:

      1)   Call

           Initiate a session with a process that is listening under
           the specified name.  The calling entity must indicate both a
           calling name (properly registered to the caller) and a
           called name.

      2)   Listen

           Accept a session from a caller.  The listen primitive may be
           constrained to accept an incoming call from a named caller.
           Alternatively, a call may be accepted from any caller.

      3)   Hang Up

           Gracefully terminate a session.  All pending data is
           transferred before the session is terminated.

      4)   Send

           Transmit one message.  A time-out can occur.  A time-out of
           any session send forces the non-graceful termination of the
           session.
Top   ToC   RFC1001 - Page 13
           A "chain send" primitive is required by the PC NetBIOS
           software interface to allow a single message to be gathered
           from pieces in various buffers.  Chain Send is an interface
           detail and does not effect the protocol.

      5)   Receive

           Receive data.  A time-out can occur.  A time-out on a
           session receive only terminates the receive, not the
           session, although the data is lost.

           The receive primitive may be implemented with variants, such
           as "Receive Any", which is required by the PC NetBIOS
           software interface.  Receive Any is an interface detail and
           does not effect the protocol.

      6)   Session Status

           Obtain information about all of the requestor's sessions,
           under the specified name.  No network activity is involved.

5.4.  DATAGRAM SERVICE

   The Datagram service is an unreliable, non-sequenced, connectionless
   service.  Datagrams are sent under cover of a name properly
   registered to the sender.

   Datagrams may be sent to a specific name or may be explicitly
   broadcast.

   Datagrams sent to an exclusive name are received, if at all, by the
   holder of that name.  Datagrams sent to a group name are multicast to
   all holders of that name.  The sending application program cannot
   distinguish between group and unique names and thus must act as if
   all non-broadcast datagrams are multicast.

   As with the Session Service, the receiver of the datagram is told the
   sending and receiving names.

   Datagram Service primitives are:

      1)   Send Datagram

           Send an unreliable datagram to an application that is
           associated with the specified name.  The name may be unique
           or group; the sender is not aware of the difference.  If the
           name belongs to a group, then each member is to receive the
           datagram.
Top   ToC   RFC1001 - Page 14
      2)   Send Broadcast Datagram

           Send an unreliable datagram to any application with a
           Receive Broadcast Datagram posted.

      3)   Receive Datagram

           Receive a datagram sent by a specified originating name to
           the specified name.  If the originating name is an asterisk,
           then the datagram may have been originated under any name.

           Note: An arriving datagram will be delivered to all pending
           Receiving Datagrams that have source and destination
           specifications matching those of the datagram.  In other
           words, if a program (or group of programs) issue a series of
           identical Receive Datagrams, one datagram will cause the
           entire series to complete.

      4)   Receive Broadcast Datagram

           Receive a datagram sent as a broadcast.

           If there are multiple pending Receive Broadcast Datagram
           operations pending, all will be satisfied by the same
           received datagram.

5.5.  MISCELLANEOUS FUNCTIONS

   The following functions are present to control the operation of the
   hardware interface to the network.  These functions are generally
   implementation dependent.

      1)   Reset

           Initialize the local network adapter.

      2)   Cancel

           Abort a pending NetBIOS request.  The successful cancel of a
           Send (or Chain Send) operation will terminate the associated
           session.

      3)   Adapter Status

           Obtain information about the local network adapter or of a
           remote adapter.

      4)   Unlink

           For use with Remote Program Load (RPL).  Unlink redirects
           the PC boot disk device back to the local disk.  See the
Top   ToC   RFC1001 - Page 15
           NetBIOS specification for further details concerning RPL and
           the Unlink operation (see page 2-35 in [2]).

      5)   Remote Program Load

           Remote Program Load (RPL) is not a NetBIOS function.  It is
           a NetBIOS application defined by IBM in their NetBIOS
           specification (see pages 2-80 through 2-82 in [2]).

5.6.  NON-STANDARD EXTENSIONS

   The IBM Token Ring implementation of NetBIOS has added at least one
   new user capability:

      1)    Find Name

           This function determines whether a given name has been
           registered on the network.

6.  NetBIOS FACILITIES SUPPORTED BY THIS STANDARD

   The protocol specified by this standard permits an implementer to
   provide all of the NetBIOS services as described in the IBM
   "Technical Reference PC Network"[2].

   The following NetBIOS facilities are outside the scope of this
   specification.  These are local implementation matters and do not
   impact interoperability:

     -  RESET
     -  SESSION STATUS
     -  UNLINK
     -  RPL (Remote Program Load)

7.  REQUIRED SUPPORTING SERVICE INTERFACES AND DEFINITIONS

   The protocols described in this RFC require service interfaces to the
   following:

     -  TCP[3,4]
     -  UDP[5]

   Byte ordering, addressing conventions (including addresses to be
   used for broadcasts and multicasts) are defined by the most
   recent version of:

     -  Assigned Numbers[6]


   Additional definitions and constraints are in:
Top   ToC   RFC1001 - Page 16
     -  IP[7]
     -  Internet Subnets[8,9,10]


8.  RELATED PROTOCOLS AND SERVICES

   The design of the protocols described in this RFC allow for the
   future incorporation of the following protocols and services.
   However, before this may occur, certain extensions may be required to
   the protocols defined in this RFC or to those listed below.

     -  Domain Name Service[11,12,13,14]
     -  Internet Group Multicast[15,16]

9.  NetBIOS SCOPE

   A "NetBIOS Scope" is the population of computers across which a
   registered NetBIOS name is known.  NetBIOS broadcast and multicast
   datagram operations must reach the entire extent of the NetBIOS
   scope.

   An internet may support multiple, non-intersecting NetBIOS Scopes.

   Each NetBIOS scope has a "scope identifier".  This identifier is a
   character string meeting the requirements of the domain name system
   for domain names.

   NOTE: Each implementation of NetBIOS-over-TCP must provide
         mechanisms to manage the scope identifier(s) to be used.

   Control of scope identifiers implies a requirement for additional
   NetBIOS interface capabilities.  These may be provided through
   extensions of the user service interface or other means (such as node
   configuration parameters.)  The nature of these extensions is not
   part of this specification.



(page 16 continued on part 2)

Next Section