On this page
|
| SUMMARY | |
| Protocol |
: |
NetBIOS Datagram Service |
| Protocol suite |
: |
IBM protocol suite |
| Layer |
: |
Transport Layer |
| Ports |
: |
138 Datagram Service |
| Related protocols |
: |
Domain Name Service,
Internet Group Multicast |
|
| DESCRIPTION |
Every NetBIOS datagram has a named destination and source. To transmit a NetBIOS datagram, the datagram service must perform a name query operation to learn the IP address and the attributes of the destination NetBIOS name. (This information may be cached to avoid the overhead of name query on subsequent NetBIOS datagrams.)
NetBIOS datagrams are carried within UDP packets. If a NetBIOS datagram is larger than a single UDP packet, it may be fragmented into several UDP packets.
End-nodes may receive NetBIOS datagrams addressed to names not held by the receiving node. Such datagrams should be discarded. If the name is unique then a DATAGRAM ERROR packet is sent to the source of that NetBIOS datagram.
- Unicast, Multicast, and Broadcast
NetBIOS datagrams may be unicast, multicast, or broadcast. A NetBIOS datagram addressed to a unique NetBIOS name is unicast. A NetBIOS datagram addressed to a group NetBIOS name, whether there are zero, one, or more actual members, is multicast. A NetBIOS datagram sent using the NetBIOS "Send Broadcast Datagram" primitive is broadcast.
- Fragmentation of NetBIOS Datagrams
When the header and data of a NetBIOS datagram exceeds the maximum amount of data allowed in a UDP packet, the NetBIOS datagram must be fragmented before transmission and reassembled upon receipt.
A NetBIOS Datagram is composed of the following protocol elements:
- IP header of 20 bytes (minimum).
- UDP header of 8 bytes.
- NetBIOS Datagram Header of 14 bytes.
- The NetBIOS Datagram data.
The NetBIOS Datagram data section is composed of 3 parts:
- Source NetBIOS name (255 bytes maximum)
- Destination NetBIOS name (255 bytes maximum)
- The NetBIOS user's data (maximum of 512 bytes)
NetBIOS Datagram Header
8 | 16 | 32 | MSG_TYPE | FLAGS | DGM_ID | SOURCE_IP | SOURCE_PORT | DGM_LENGTH | PACKET_OFFSET |
- MSG_TYPE values (in hexadecimal)
| 10 | DIRECT_UNIQUE DATAGRAM | | 11 | DIRECT_GROUP DATAGRAM | | 12 | BROADCAST DATAGRAM | | 13 | DATAGRAM ERROR | | 14 | DATAGRAM QUERY REQUEST | | 15 | DATAGRAM POSITIVE QUERY RESPONSE | | 16 | DATAGRAM NEGATIVE QUERY RESPONSE |
- Direct_Unique, Direct_Group, & Broadcast Datagram
8 | 16 | 32 | MSG_TYPE | FLAGS | DGM_ID | SOURCE_IP | SOURCE_PORT | DGM_LENGTH | PACKET_OFFSET | | SOURCE_NAME | DESTINATION_NAME | USER_DATA |
- Datagram Error Packet
8 | 16 | 32 | MSG_TYPE | FLAGS | DGM_ID | SOURCE_IP | SOURCE_PORT | ERROR_CODE | |
ERROR_CODE
| No. | values (in hexadecimal) | | 82 | DESTINATION NAME NOT PRESENT | | 83 | INVALID SOURCE NAME FORMAT | | 84 | INVALID DESTINATION NAME FORMAT |
- Datagram Query Request
8 | 16 | 32 | MSG_TYPE | FLAGS | DGM_ID | SOURCE_IP | SOURCE_PORT | DESTINATION_NAME |
- Datagram Positive and Negative Query Response
8 | 16 | 32 | MSG_TYPE | FLAGS | DGM_ID | SOURCE_IP | SOURCE_PORT | DESTINATION_NAME |
- FLAGS
Bit definitions of the FLAGS field.
| Symbol | Bit(s) | Description | M | 7 | MORE flag, If set then more NetBIOS datagram fragments follow. | F | 6 | FIRST packet flag, If set then this is first(and possibly only) fragment of NetBIOS datagram | SNT | 4,5 | Source End-Node type:
00 = B node
01 = P node
10 = M node
11 = NBDD | RESERVED | 0-3 | Reserved, must be zero (0) |
NetBIOS Datagrams by B Nodes
For NetBIOS datagrams with a named destination (i.e. non- broadcast), a B node performs a name discovery for the destination name before sending the datagram. (Name discovery may be bypassed if information from a previous discovery is held in a cache.) If the name type returned by name discovery is UNIQUE, the datagram is unicast to the sole owner of the name. If the name type is GROUP, the datagram is broadcast to the entire broadcast area using the destination IP address BROADCAST_ADDRESS.
A receiving node always filters datagrams based on the destination name. If the destination name is not owned by the node or if no RECEIVE DATAGRAM user operations are pending for the name, then the datagram is discarded. For datagrams with a UNIQUE name destination, if the name is not owned by the node then the receiving node sends a DATAGRAM ERROR packet. The error packet originates from the DGM_SRVC_UDP_PORT and is addressed to the SOURCE_IP and SOURCE_PORT from the bad datagram. The receiving node quietly discards datagrams with a GROUP name destination if the name is not owned by the node.
Since broadcast NetBIOS datagrams do not have a named destination, the B node sends the DATAGRAM SERVICE packet(s) to the entire broadcast area using the destination IP address BROADCAST_ADDRESS. In order for the receiving nodes to distinguish this datagram as a broadcast NetBIOS datagram, the NetBIOS name used as the destination name is '*' (hexadecimal 2A) followed by 15 bytes of hexadecimal 00. The NetBIOS scope identifier is appended to the name before it is converted into second-level encoding. For example, if the scope identifier is "NETBIOS.SCOPE" then the first-level encoded name would be:
CKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.NETBIOS.SCOPE
NetBIOS Datagrams by P and M Nodes
P and M nodes do not use IP broadcast to distribute NetBIOS datagrams.
Like B nodes, P and M nodes must perform a name discovery or use cached information to learn whether a destination name is a group or a unique name.
Datagrams to unique names are unicast directly to the destination by P and M nodes, exactly as they are by B nodes.
Datagrams to group names and NetBIOS broadcast datagrams are unicast to the NBDD. The NBDD then relays the datagrams to each of the nodes specified by the destination name.
An NBDD may not be capable of sending a NetBIOS datagram to a particular NetBIOS name, including the broadcast NetBIOS name ("*") defined above. A query mechanism is available to the end- node to determine if a NBDD will be able to relay a datagram to a given name. Before a datagram, or its fragments, are sent to the NBDD the P or M node may send a DATAGRAM QUERY REQUEST packet to the NBDD with the DESTINATION_NAME from the DATAGRAM SERVICE packet(s).
An NBDD may not be capable of sending a NetBIOS datagram to a particular NetBIOS name, including the broadcast NetBIOS name ("*") defined above. A query mechanism is available to the end- node to determine if a NBDD will be able to relay a datagram to a given name. Before a datagram, or its fragments, are sent to the NBDD the P or M node may send a DATAGRAM QUERY REQUEST packet to the NBDD with the DESTINATION_NAME from the DATAGRAM SERVICE packet(s). The NBDD will respond with a DATAGRAM POSITIVE QUERY RESPONSE if it will relay datagrams to the specified destination name. After a positive response the end-node unicast the datagram to the NBDD. If the NBDD will not be able to relay a datagram to the destination name specified in the query, a DATAGRAM NEGATIVE QUERY RESPONSE packet is returned. If the NBDD can not distribute a datagram, the end-node then has the option of getting the name's owner list from the NBNS and sending the datagram directly to each of the owners.
An NBDD must be able to respond to DATAGRAM QUERY REQUEST packets. The response may always be positive. However, the usage or implementation of the query mechanism by a P or M node is optional. An implementation may always unicast the NetBIOS datagram to the NBDD without asking if it will be relayed. Except for the datagram query facility described above, an NBDD provides no feedback to indicate whether it forwarded a datagram.
|
 Top of Page
|
| EXAMPLES |
Example 1: B Node Transmission of NetBIOS Datagrams
PROCEDURE send_datagram(data, source, destination, broadcast)
/*
* user initiated processing on B node
*/
BEGIN
group = FALSE;
do name discovery on destination name, returns name type and IP address;
IF name type is group name THEN
BEGIN
group = TRUE;
END
/*
* build datagram service UDP packet;
*/
convert source and destination NetBIOS names into half-ASCII, biased encoded
name;
SOURCE_NAME = cat(source, SCOPE_ID);
SOURCE_IP = this nodes IP address;
SOURCE_PORT = DGM_SRVC_UDP_PORT;
IF NetBIOS broadcast THEN
BEGIN
DESTINATION_NAME = cat("*", SCOPE_ID)
END
ELSE
BEGIN
DESTINATION_NAME = cat(destination, SCOPE_ID)
END
MSG_TYPE = select_one_from_set
{BROADCAST, DIRECT_UNIQUE, DIRECT_GROUP}
DGM_ID = next transaction id for Datagrams;
DGM_LENGTH = length of data + length of second level encoded source and
destination names;
IF (length of the NetBIOS Datagram, including UDP and IP headers, >
MAX_DATAGRAM_LENGTH) THEN
BEGIN
/*
* fragment NetBIOS datagram into 2 UDP packets
*/
Put names into 1st UDP packet and any data that fits after names;
Set MORE and FIRST bits in 1st UDP packet's FLAGS;
OFFSET in 1st UDP = 0;
Replicate NetBIOS Datagram header from 1st UDP packet into 2nd UDP packet;
Put rest of data in 2nd UDP packet;
Clear MORE and FIRST bits in 2nd UDP packet's FLAGS;
OFFSET in 2nd UDP = DGM_LENGTH - number of name and data bytes in 1st
UDP;
END
BEGIN
/*
* Only need one UDP packet
*/
USER_DATA = data;
Clear MORE bit and set FIRST bit in FLAGS;
OFFSET = 0;
END
IF (group == TRUE) OR (NetBIOS broadcast) THEN
BEGIN
send UDP packet(s) to BROADCAST_ADDRESS;
END
ELSE
BEGIN
send UDP packet(s) to IP address returned by name discovery;
END
END /* procedure */ Example 2: Reception of NetBIOS Datagrams by All Nodes
The following algorithm discards out of order NetBIOS Datagram fragments. An
implementation which reassembles out of order NetBIOS Datagram fragments conforms
to this specification. The fragment discard timer is initialized to the value
FRAGMENT_TO. This value should be user configurable. The default value is given in
Section 6, "Defined Constants and Variables".
PROCEDURE datagram_packet(packet)
/*
* processing initiated by datagram packet reception
* on B, P and M nodes
*/
BEGIN
/*
* if this node is a P node, ignore
* broadcast packets.
*/
IF this is a P node AND incoming packet is a broadcast packet THEN
BEGIN
discard packet;
END
CASE packet type OF
DATAGRAM SERVICE:
BEGIN
IF FIRST bit in FLAGS is set THEN
BEGIN
IF MORE bit in FLAGS is set THEN
BEGIN
Save 1st UDP packet of the Datagram;
Set this Datagram's fragment discard timer to FRAGMENT_TO;
return;
END
ELSE
Datagram is composed of a single UDP packet;
END
ELSE
BEGIN
/* Have the second fragment of a Datagram */
Search for 1st fragment by source IP address and DGM_ID;
IF found 1st fragment THEN Process both UDP packets;
ELSE
BEGIN
discard 2nd fragment UDP packet;
return;
END
END
IF DESTINATION_NAME is '*' THEN
BEGIN
/* NetBIOS broadcast */
deliver USER_DATA from UDP packet(s) to all outstanding
receive broadcast datagram requests;
return;
END
ELSE
BEGIN /* non-broadcast */
/* Datagram for Unique or Group Name */
IF DESTINATION_NAME is not present in the
local name table THEN
BEGIN
/* destination not present */
build DATAGRAM ERROR packet, clear FIRST and MORE bit,
put in this nodes IP and PORT, set ERROR_CODE;
send DATAGRAM ERROR packet to source IP address and
port of UDP;
discard UDP packet(s);
return;
END
ELSE
BEGIN /* good */
/*
* Replicate received NetBIOS datagram for
* each recipient
*/
FOR EACH pending NetBIOS user's receive datagram operation
BEGIN
IF source name of operation matches destination
name of packet THEN
BEGIN
deliver USER_DATA from UDP packet(s);
END
END /* for each */
return;
END /* good */
END /* non-broadcast */
END /* datagram service */
DATAGRAM ERROR:
BEGIN
/*
* name service returned incorrect information
*/
inform local name service that incorrect information was provided;
IF this is a P or M node THEN
BEGIN
/*
* tell NetBIOS Name Server that it may
* have given incorrect information
*/
send NAME RELEASE REQUEST with name and incorrect IP address
to NetBIOS Name Server;
END
END /* datagram error */
END /* case */
END Example 3: Protocols for the NBDD
The key to NetBIOS Datagram forwarding service is the packet delivered to the
destination end node must have the same NetBIOS header as if the source end node
sent the packet directly to the destination end node. Consequently, the NBDD does
not reassemble NetBIOS Datagrams. It forwards the UDP packet as is.
PROCEDURE datagram_packet(packet)
/*
* processing initiated by a incoming datagram service
* packet on a NBDD node.
*/
BEGIN
CASE packet type OF
DATAGRAM SERVICE:
BEGIN
IF packet was sent as a directed NetBIOS datagram THEN
BEGIN
/*
* provide group forwarding service
*
* Forward datagram to each member of the
* group. Can forward via:
* 1) get list of group members and send
* the DATAGRAM SERVICE packet unicast
* to each
* 2) use Group Multicast, if available
* 3) combination of 1) and 2)
*/
...
END
ELSE
BEGIN
/*
* provide broadcast forwarding service
*
* Forward datagram to every node in the
* NetBIOS scope. Can forward via:
* 1) get list of group members and send
* the DATAGRAM SERVICE packet unicast
* to each
* 2) use Group Multicast, if available
* 3) combination of 1) and 2)
*/
...
END
END /* datagram service */
DATAGRAM ERROR:
BEGIN
/*
* Should never receive these because Datagrams
* forwarded have source end node IP address and
* port in NetBIOS header.
*/
send DELETE NAME REQUEST with incorrect name and IP address to
NetBIOS Name Server;
END /* datagram error */
DATAGRAM QUERY REQUEST:
BEGIN
IF can send packet to DESTINATION_NAME THEN BEGIN
/*
* NBDD is able to relay Datagrams for
* this name
*/
send POSITIVE DATAGRAM QUERY RESPONSE to REQUEST source
IP address and UDP port with request's DGM_ID;
END
ELSE
BEGIN
/*
* NBDD is NOT able to relay Datagrams for
* this name
*/
send NEGATIVE DATAGRAM QUERY RESPONSE to REQUEST source
IP address and UDP port with request's DGM_ID;
END
END /* datagram query request */
END /* case */
END /* procedure */ |
Top of Page
|
| PROTOCOL RELATIONS |
■ Parent layer
■ Child layer
|
Top of Page
|
| GLOSSARY |
|
Broadcast
Broadcast is the term used to describe communication where a piece of information is sent from one point to all other points. Broadcasting is a useful feature in e-mail systems. It is also supported by some fax systems.
In networking, a distinction is made between broadcasting and multicasting. Broadcasting sends a message to everyone on the network whereas multicasting sends a message to a select list of recipients.
Datagram
A datagram is a self-contained, independent entity of data carrying sufficient information to be routed from the source to the destination computer without reliance on earlier exchanges between this source and destination computer and the transporting network.
The term has been generally replaced by the term packet. Datagrams or packets are the message units that the Internet Protocol deals with and that the Internet transports. A datagram or packet needs to be self-contained without reliance on earlier exchanges because there is no connection of fixed duration between the two communicating points as there is, for example, in most voice telephone conversations.
IP address
IP address is an identifier for a computer or device on a TCP/IP network. Networks using the TCP/IP protocol route messages based on the IP address of the destination. The format of an IP address is a 32-bit numeric address written as four numbers separated by periods. Each number can be zero to 255. For example, 1.160.10.240 could be an IP address. Within an isolated network, you can assign IP addresses at random as long as each one is unique. However, connecting a private network to the Internet requires using registered IP addresses (called Internet addresses) to avoid duplicates.
The four numbers in an IP address are used in different ways to identify a particular network and a host on that network. Four regional Internet registries -- ARIN, RIPE NCC, LACNIC and APNIC -- assign Internet addresses from the following three classes.
Class A - supports 16 million hosts on each of 126 networks
Class B - supports 65,000 hosts on each of 16,000 networks
Class C - supports 254 hosts on each of 2 million networks
The number of unassigned Internet addresses is running out, so a new classless scheme called CIDR is gradually replacing the system based on classes A, B, and C and is tied to adoption of IPv6.
Multicast
Multicast is designed to transmit a single message to a select group of recipients. A simple example of multicasting is sending an e-mail message to a mailing list. Teleconferencing and videoconferencing also use multicasting, but require more robust protocols and networks.
NBDD
NBDD is Netbios datagram distribution. This server relays broadcast and multicast (group) datagrams to all intended recipients. When a P, M, or H node wishes to send a broadcast or multicast datagram, it will send the datagram to the NBDD. The NBDD will obtain the list of destination IPs from the NBNS and then unicast the datagram to each of those nodes.
NetBIOS
NetBIOS(Network Basic Input Output System) is an API that augments the DOS BIOS by adding special functions for local-area networks (LANs). Almost all Windows-based LANs for PCs are based on the NetBIOS. Some LAN manufacturers have even extended it, adding additional network capabilities.
Packet
A packet is the unit of data that is routed between an origin and a destination on the Internet or any other packet-switched network. When any file (e-mail message, HTML file, Graphics Interchange Format file, Uniform Resource Locator request, and so forth) is sent from one place to another on the Internet, the Transmission Control Protocol (TCP) layer of TCP/IP divides the file into "chunks" of an efficient size for routing. Each of these packets is separately numbered and includes the Internet address of the destination. The individual packets for a given file may travel different routes through the Internet. When they have all arrived, they are reassembled into the original file (by the TCP layer at the receiving end).
UDP
UDP (User Datagram Protocol) is a connectionless protocol that, like TCP, runs on top of IP networks. Unlike TCP/IP, UDP/IP provides very few error recovery services, offering instead a direct way to send and receive datagrams over an IP network. It's used primarily for broadcasting messages over a network.
Unicast
Unicast is a communication that takes place over a network between a single sender and a single receiver.
|
Top of Page
|
| REFERENCES |
RFCs:
[ RFC 1001] PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS.
[ RFC 1002] PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: DETAILED SPECIFICATIONS.
|
Top of Page
|
| OTHER PROTOCOLS OF TCP/IP SUITE |
|
|
|
|
|
