`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".
`
`NetBIOS Working Group
`
`[Page 1]
`
`Petitioner Riot Games, Inc. - Ex. 1018, p. 1
`
`Petitioner Valve - Ex. 1018, Page 1
`
`
`
`RFC 1001
`
`March 1987
`
`SUMMARY OF CONTENTS
`
`STATUS OF THIS MEMO
`1.
`ACKNOWLEDGEMENTS
`2.
`INTRODUCTION
`3.
`DESIGN PRINCIPLES
`4.
`OVERVIEW OF NetBIOS
`5.
`NetBIOS FACILITIES SUPPORTED BY THIS STANDARD
`6.
`REQUIRED SUPPORTING SERVICE INTERFACES AND DEFINITIONS
`7.
`RELATED PROTOCOLS AND SERVICES
`8.
`NetBIOS SCOPE
`9.
`10.
`NetBIOS END-NODES
`NetBIOS SUPPORT SERVERS
`11.
`TOPOLOGIES
`12.
`GENERAL METHODS
`13.
`14.
`REPRESENTATION OF NETBIOS NAMES
`NetBIOS NAME SERVICE
`15.
`NetBIOS SESSION SERVICE
`16.
`NETBIOS DATAGRAM SERVICE
`17.
`NODE CONFIGURATION PARAMETERS
`18.
`MINIMAL CONFORMANCE
`19.
`REFERENCES
`APPENDIX A - INTEGRATION WITH INTERNET GROUP MULTICASTING
`APPENDIX B - IMPLEMENTATION CONSIDERATIONS
`
`6
`6
`7
`7
`10
`15
`15
`16
`16
`16
`18
`20
`23
`25
`27
`48
`55
`58
`59
`60
`61
`62
`
`NetBIOS Working Group
`
`[Page 2]
`
`Petitioner Riot Games, Inc. - Ex. 1018, p. 2
`
`Petitioner Valve - Ex. 1018, Page 2
`
`
`
`
`RFC 1001 March 1987
`
` 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
`
`NetBIOS Working Group [Page 3]
`
`Petitioner Riot Games, Inc. - Ex. 1018, p. 3
`
`Petitioner Valve - Ex. 1018, Page 3
`
`
`
`
`RFC 1001 March 1987
`
` 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
`
`NetBIOS Working Group [Page 4]
`
`Petitioner Riot Games, Inc. - Ex. 1018, p. 4
`
`Petitioner Valve - Ex. 1018, Page 4
`
`
`
`
`RFC 1001 March 1987
`
` 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
`
`NetBIOS Working Group [Page 5]
`
`Petitioner Riot Games, Inc. - Ex. 1018, p. 5
`
`Petitioner Valve - Ex. 1018, Page 5
`
`
`
`
`RFC 1001 March 1987
`
` 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
`
`NetBIOS Working Group [Page 6]
`
`Petitioner Riot Games, Inc. - Ex. 1018, p. 6
`
`Petitioner Valve - Ex. 1018, Page 6
`
`
`
`
`RFC 1001 March 1987
`
`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].
`
`NetBIOS Working Group [Page 7]
`
`Petitioner Riot Games, Inc. - Ex. 1018, p. 7
`
`Petitioner Valve - Ex. 1018, Page 7
`
`
`
`
`RFC 1001 March 1987
`
`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
`
`NetBIOS Working Group [Page 8]
`
`Petitioner Riot Games, Inc. - Ex. 1018, p. 8
`
`Petitioner Valve - Ex. 1018, Page 8
`
`
`
`
`RFC 1001 March 1987
`
` 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.
`
`NetBIOS Working Group [Page 9]
`
`Petitioner Riot Games, Inc. - Ex. 1018, p. 9
`
`Petitioner Valve - Ex. 1018, Page 9
`
`
`
`
`RFC 1001 March 1987
`
`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.
`
`NetBIOS Working Group [Page 10]
`
`Petitioner Riot Games, Inc. - Ex. 1018, p. 10
`
`Petitioner Valve - Ex. 1018, Page 10
`
`
`
`
`RFC 1001 March 1987
`
`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.
`
`NetBIOS Working Group [Page 11]
`
`Petitioner Riot Games, Inc. - Ex. 1018, p. 11
`
`Petitioner Valve - Ex. 1018, Page 11
`
`
`
`
`RFC 1001 March 1987
`
`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.
`
`NetBIOS Working Group [Page 12]
`
`Petitioner Riot Games, Inc. - Ex. 1018, p. 12
`
`Petitioner Valve - Ex. 1018, Page 12
`
`
`
`
`RFC 1001 March 1987
`
` 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.
`
`NetBIOS Working Group [Page 13]
`
`Petitioner Riot Games, Inc. - Ex. 1018, p. 13
`
`Petitioner Valve - Ex. 1018, Page 13
`
`
`
`
`RFC 1001 March 1987
`
` 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
`
`NetBIOS Working Group [Page 14]
`
`Petitioner Riot Games, Inc. - Ex. 1018, p. 14
`
`Petitioner Valve - Ex. 1018, Page 14
`
`
`
`
`RFC 1001 March 1987
`
` 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