home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft__misc
/
part1.txt
< prev
next >
Wrap
Text File
|
1997-04-17
|
62KB
|
1,405 lines
Network Working Group John C. C. White
Internet-Draft The MITRE Corporation
Obsoletes: RFC998 April 1997
Category: Proposed Standard
NETBLT (Network Block Transfer Protocol)
draft-white-protocol-stack-00.txt
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
The NETBLT protocol [RFC998] was designed as an experimental
transport layer protocol, intended for moving large quantities of
data across a wide variety of networks. It provides reliable bulk
transfer with an end-to-end flow-control mechanism meant to deal with
network congestion by throttling the rate at which data is inserted
into the network. However, experiments with NETBLT across shared
links revealed problems with fairness; traffic from one connection
could hog most of a link's bandwidth, and there seems to be no way to
prevent this under the current rate-control scheme, so further
application of NETBLT was not pursued by its original developers.
However, NETBLT has a number of characteristics which make it very
attractive for use across noisy, long-delay, slow-turnaround, or
asymmetric communications links. Such links are common in military
usage, and may become more widespread with the development of mobile
computing. NETBLT's attractive characteristics include selective
retransmission of lost packets, potentially large transmission
windows, and control of transmission from the receiving, rather than
the sending side; the latter makes NETBLT relatively insensitive to
White [Page 1]
INTERNET DRAFT NETBLT April 1997
network delays. NETBLT, with minor modifications, was adopted as the
transport layer of the military standard TACO2 (Tactical
Communications Protocol 2) [MIL- STD], which is intended for the
transmission of images and other bulk data across links that cannot
support the usual TCP/IP operation. This document describes NETBLT as
it is currently used, and is intended partly to encourage
consideration of NETBLT in other difficult communications
environments.
1. Document History
The military standard definition of NETBLT was developed from RFC998
by expunging most of the tutorial information and translating the
remainder into the language required by military standards. This
document was then prepared from the military standard; as a result,
there may be some unnecessary rearrangements and rewordings. In any
case, most of the protocol remains as designed by the original
developers. Modifications have been made to simplify protocol
operation and to extend its capability.
2. NETBLT Overview
The bulk data transfer protocol NETBLT works by opening a connection
between a sender and a receiver, transferring a message in one or
more buffers, and closing the connection. Each buffer is transferred
as a sequence of packets; the interaction between sender and receiver
is primarily on a per-buffer basis. This section provides an
overview of NETBLT; further explanation and detailed requirements are
found in the following sections. The material here assumes the
existence of a full- duplex connection between sender and receiver,
such that information can be transferred in both directions more or
less concurrently. Changes for half-duplex and simplex operation are
provided later.
Specific packet types are identified in the following sections by
upper-case names (e.g., DATA packets), in contrast with packet
functions (e.g., keepalive packets) which are accomplished by more
than one packet type.
2.1 Single-buffer operation.
In its simplest form, a NETBLT transfer works as follows: first, a
connection is opened between a sending and a receiving NETBLT. That
step includes negotiation of various transmission parameters. The
sending client loads a buffer of data and passes it to the NETBLT
layer to be transferred. NETBLT breaks the buffer up into packets
and sends these packets across the network via datagrams. The
receiving NETBLT loads these packets into a matching buffer. When
White [Page 2]
INTERNET DRAFT NETBLT April 1997
the last packet in the buffer should have arrived at the receiver,
the receiving NETBLT checks whether all packets in that buffer have
been received correctly. If some packets have not been received
correctly, the receiving NETBLT requests that they be resent. When
the buffer has been completely received, the receiving NETBLT passes
it to the receiving client, and confirms its receipt to the sender.
When a new buffer is ready to receive more data, the receiving NETBLT
notifies the sender that the new buffer is ready, and the sender
prepares and sends the next buffer in the same manner. This
continues until all the data has been sent; at that time the sender
notifies the receiver that the transmission has been completed. The
two sides then close the connection.
2.2 Multiple-buffer operation.
As described above the NETBLT protocol is "lock-step". Action halts
after a buffer is transmitted, and begins again after confirmation is
received from the receiver of data. NETBLT provides for multiple
buffering, so that the sending NETBLT can transmit new buffers while
waiting for confirmation of earlier buffers from the receiving
NETBLT.
2.3 Buffers and packets.
The data to be transmitted is broken up into buffers by the sending
client. All buffers are the same size, except for the last buffer.
During connection setup, the sending and receiving NETBLTs negotiate
the buffer size. Buffer sizes are in bytes; data is placed in
buffers on byte boundaries.
Each buffer is broken down by NETBLT into a sequence of DATA packets
terminated by an LDATA packet. DATA packet size is negotiated
between the sending and receiving NETBLTs during connection setup.
All DATA packets are the same size. DATA and LDATA packets are
identical in format except for the packet type.
2.4 Flow control.
NETBLT uses two strategies for flow control, one at the client level
and one internal.
2.4.1 Client level flow control.
The sending and receiving NETBLTs transmit data in buffers; client
flow control is therefore by buffer. Before a buffer can be
transmitted, NETBLT confirms that both clients have set up matching
buffers, that one is ready to send data, and that the other is ready
to receive data. Either client can therefore control the flow of data
White [Page 3]
INTERNET DRAFT NETBLT April 1997
by not providing a new buffer. Clients cannot stop a buffer transfer
once it is in progress, except by aborting the entire transfer.
2.4.2 Internal flow control.
The internal flow control mechanism for NETBLT is rate control. The
transmission rate is negotiated by the sending and receiving NETBLTs
during connection setup and after each buffer transmission. The
sender uses timers to maintain the negotiated rate, by controlling
the time to transmit groups of packets. The sender transmits a burst
of packets over the negotiated time interval, and sends another burst
in the next interval. NETBLT's rate control therefore has two parts,
a burst size and a burst interval, with (burst interval)/(burst size)
equal to the average transmission time per packet.
A burst interval value of zero means that internal flow control is
turned off, so that only client level flow control is in effect. In
this case, the sending NETBLT will transmit packets without regard
for the rate control mechanism.
All NETBLT flow control parameters (packet size, buffer size, number
of buffers outstanding, burst size, and burst interval) are
negotiated during connection setup. The negotiation process is the
same for all parameters. The client initiating the connection (the
active side) sends a value for each parameter in its OPEN packet.
The other client (the passive side) will compare these values with
the highest- performance values it can support. The passive side can
modify any of the parameters, but only by making them more
restrictive; i. e., smaller packet size, smaller buffer size, fewer
buffers, smaller burst size, and larger burst interval. The
(possibly modified) parameters are sent back to the active side in
the RESPONSE packet.
The burst size and burst interval may also be re-negotiated after
each buffer transmission to adjust the transfer rate according to the
performance observed from transferring the previous buffer. The
receiving end sends burst size and burst interval values in its OK
messages (which acknowledge successful receipt of a buffer) and in
its RESEND messages (which request retransmission of specific
packets). The sender will compare these values with the values it
can support. Again, it may modify either of these parameters, but
only by making them more restrictive. The modified parameters will
then be communicated to the receiver in DATA, LDATA, or NULL-ACK
packets.
2.5 Checksumming.
NETBLT automatically checksums each packet header and, optionally,
White [Page 4]
INTERNET DRAFT NETBLT April 1997
the data portion of each DATA and LDATA packet. The checksum value is
the bitwise negation of the ones-complement sum of the 16-bit words
being checksummed. If a packet to be transferred has an odd number of
bytes, it is padded with a final null byte (binary 0's) to make the
number of bytes even for the purpose of checksum calculation. The
extra byte is not transmitted as part of the packet, but its
existence is assumed at the receiving end for checksum verification.
3. NETBLT detailed operation
Each NETBLT transfer has three stages: connection setup, data
transfer, and connection close. The stages are described in detail
below, along with methods for insuring that each stage completes
reliably. State diagrams are provided at the end of the description
for each stage of the transfer. Each transition in the diagrams is
labelled with the event that causes the transition, and optionally,
in parentheses, actions that occur at the time of the transition.
3.1 Connection setup.
A NETBLT connection is set up by an exchange of two packets between
the active NETBLT and the passive NETBLT. The active end sends an
OPEN packet; the passive end acknowledges the OPEN packet in one of
two ways: it either sends a REFUSED packet, indicating that the
connection cannot be completed for some reason, or it completes the
connection setup by sending a RESPONSE packet. After a successful
connection setup, the transfer can begin. Figure 1 illustrates the
opening of a connection by the active end, and figure 2 shows the
same process for the passive end.
Each side of the connection transmits its death-timeout value in
seconds in the OPEN or the RESPONSE packet. The death-timeout value
is used to determine the frequency with which to send keepalive
packets during idle periods of an opened connection (death timers and
keepalive packets are discussed later).
The sending NETBLT specifies a passive client through a client-
specific "well-known" 16 bit logical port number on which the
receiving end listens. The sending client identifies itself through a
32 bit Internet address and a unique 16 bit port number.
An unstructured, variable-length client message field is provided in
OPEN and RESPONSE packets for any client-specific information that
may be required. In addition, a "reason for refusal" field is
provided in REFUSED packets.
Recovery for lost OPEN and RESPONSE packets is provided by the use of
timers. The sending end sets a timer when it sends an OPEN packet.
White [Page 5]
INTERNET DRAFT NETBLT April 1997
When the timer expires, another OPEN packet is sent, until some
predetermined maximum number (at least five) of OPEN packets have
been sent. The timer is cleared upon receipt of a RESPONSE or
REFUSED packet.
To prevent duplication of OPEN and RESPONSE packets, the OPEN packet
contains a 32 bit connection unique ID (UID) that must be returned in
the RESPONSE packet. This unique ID prevents the initiator from
confusing the response to the current request with the response to an
earlier connection request (there can only be one connection open
between any pair of logical ports). Any OPEN or RESPONSE packet with
a port pair matching that of an open connection will have its unique
ID checked. If the unique ID of the packet matches the unique ID of
the connection, then the packet type is checked. If it is a RESPONSE
packet, it is treated as a duplicate and ignored. If it is an OPEN
packet, the passive NETBLT will send another RESPONSE (on the
assumption that a previous RESPONSE packet was sent and lost, causing
the initiating NETBLT to retransmit its OPEN packet). A non-matching
unique ID is treated as an attempt to open a second connection
between the port pair and is rejected by sending a REFUSED message.
+------------+
| |--------<-----------------------------+
| Inactive |-->-+ |
| | | |
+------------+ | |
^ Connect request from client |
| (Send OPEN, start Open Timer) |
REFUSED received | <=max # OPENs sent
| | |
+------------+ | |
| Opening |-<--+---<---------+ ^
| | | |
| |->-+ <max # OPENs sent |
+------------+ | (send OPEN, start Open Timer) |
| | | |
| Open Timer timeout | |
| +------>-------+-------------------+
RESPONSE received
(clear Open Timer)
| +------------+
| | |
+-->----| Connected |
| |
+------------+
Figure 1. Active side open state diagram
White [Page 6]
INTERNET DRAFT NETBLT April 1997
+------------+
| |--->----------+
+-<--| Inactive | Unacceptable OPEN received
| | | (send REFUSED)
| | |---<----------+
| +------------+
Acceptable OPEN received
(send RESPONSE) +-------+--------->-----------+
| +------------+ | | |
| | |--->--+ Acceptable OPEN Unacceptable OPEN
+->--| Connected | received received
| | (send RESPONSE) (send REFUSED)
| |--<---+ | |
+------------+ +-------+---------<-----------+
Figure 2. Passive side open state diagram
3.2 Data transfer
The simplest full-duplex mode of data transfer proceeds as follows.
The sending client sets up a buffer full of data. The receiving
NETBLT sends a GO message inside a CONTROL packet to the sender,
signifying that it too has set up a buffer and is ready to receive
data. Once the GO message is received, the sender transmits the
buffer as a series of DATA packets followed by an LDATA packet. When
the last packet in the buffer should have been received (as
determined by a timer), if any packets in the buffer have not been
received the receiver sends a RESEND message inside a CONTROL packet
containing a list of packets that were not received. The sender will
resend these packets. This process continues until there are no
missing packets. At that time the receiver sends an OK message
inside a CONTROL packet, sets up another buffer to receive data, and
sends another GO message. The sender, having received the OK
message, will set up another buffer, wait for the GO message, and
repeat the process.
A more efficient full-duplex transfer mode uses multiple buffering,
in which the sender and receiver allocate and transfer buffers in a
manner that allows error recovery or successful transmission
confirmation of previous buffers to be concurrent with transmission
of the current buffer. During the connection setup phase, one of the
negotiated parameters is the number of concurrent buffers permitted
during the transfer. If there is more than one buffer available,
transfer of the next buffer will start right after the current buffer
finishes, and the receiver is ready to receive the buffer. The
receiver signals that it is ready for the next buffer by sending a GO
message. This is illustrated in the following example: Assume the
sender has available two buffers A and B in a multiple-buffer
White [Page 7]
INTERNET DRAFT NETBLT April 1997
transfer, with A preceding B. When A has been transferred and the
sending NETBLT is waiting for either an OK or a RESEND message for
it, the sending NETBLT can start sending B immediately. If the
receiver of data sends an OK for A, all is well; if it sends a
RESEND, the missing packets specified in the RESEND message are
retransmitted. In the multiple-buffer transfer mode, all packets to
be sent are ordered by buffer number (lowest number first). Since
buffer numbers increase monotonically, packets from an earlier buffer
will precede packets from a later buffer.
3.2.1 Control Messages.
NETBLT uses a single long-lived control packet; the packet is treated
like a FIFO queue, with new control messages added on at the end and
acknowledged control messages removed from the front. The
implementation places control messages in the control packet and
transmits the entire control packet, consisting of any unacknowledged
control messages plus new messages just added. Since control packet
transmissions are fairly frequent, unacknowledged messages may be
transmitted several times before they are finally acknowledged. The
receiver may send zero or more control messages (OK, GO, or RESEND)
within a single CONTROL packet. In order to limit the size of the
control packet, it is permissible to send fewer than the full set of
unacknowledged control messages in a control packet; it is however
required that the control messages in a control packet be
consecutive, starting with the lowest-numbered unacknowledged control
message.
Each control message includes a sequence number, which starts at one
and increases by one for each control message generated. The sending
NETBLT checks the sequence number of every incoming control and
stores the highest sequence number below which all other sequence
numbers have been received (in following paragraphs this is called
the high-acknowledged- sequence-number). It returns this number in
every packet flowing back to the receiver. The receiver removes
control messages with sequence numbers less than or equal to the
high-acknowledged-sequence-number from the control packet.
Whenever the receiver sends a control packet, it starts a control
timer. When the control timer expires, the receiving NETBLT will
resend the control packet and reset the timer. The receiving NETBLT
will continue to resend control packets in response to control timer
expiration until either the control timer is cleared or the receiving
NETBLT's death timer (described later) expires (at which time it will
shut down the connection). The control timer may have as its initial
value an arbitrary number. Subsequent control timer values are based
on the network round-trip transit time (the time between sending the
control packet and receiving the acknowledgment of all messages in
White [Page 8]
INTERNET DRAFT NETBLT April 1997
the control packet) plus a variance factor. The timer value is
regularly updated, based on a smoothed average of collected round-
trip transit times. The control timer is set to the keepalive value
when a packet is received from the sender with high-acknowledged-
sequence-number equal to the highest sequence number in the control
packet most recently sent.
The exact algorithm for control timer calculation is not mandated.
The suggested algorithm, similar to that [Jacobsen] now used in TCP,
is as follows:
Initially, the round trip time is set to one-half the keepalive value
and the deviation is set to zero. When a control packet is sent, if
the round-trip-delay (RTD) timer is not running, its highest sequence
number is stored and the RTD timer is started. When acknowledgement
of that sequence number is received, the RTD timer value is used to
calculate a new RTD estimate. However, if a control packet is
retransmitted, the RTD timer is zeroed, its value is not used (to
avoid ambiguous RTD measurements), and the estimated RTD is increased
by 1/2 of its value (to allow recovery from too low an RTD estimate).
To calculate the new RTD estimate,
New smoothed round trip time = (1-a) * old smoothed round trip time +
a * latest round trip measurement
New deviation = (1-b) * old deviation + b * |latest round trip
measurement - old smoothed round trip time|
where a = 1/8 and b = 1/4, allowing computations to be done with add
and shift operations. The control timer is set equal to the new
smoothed round trip time plus twice the new deviation, or to the
keepalive value, whichever is less, if the control packet is not
empty. If the control packet is empty, the control timer is set to
the keepalive value.
The sending NETBLT, upon receiving a previously unseen control
message, will either set up a new buffer (upon receipt of an OK
message for a previous buffer), mark data for resending (upon receipt
of a RESEND message), or prepare a buffer for sending (upon receipt
of a GO message). If the sending NETBLT is not in a position to send
data, it sends a NULL-ACK packet, which contains its high-
acknowledged-sequence- number (this permits the receiving NETBLT to
resend any outstanding control messages or to clear its control
timer), and waits until it can send more data.
3.2.2 Send buffer state sequence.
The state sequence for a sending buffer is as follows: when a GO
White [Page 9]
INTERNET DRAFT NETBLT April 1997
message for the buffer is received, the buffer is created, filled
with data, and placed in a SENDING state. When an OK for that buffer
has been received, it goes into a SENT state and may be released.
Figure 3 illustrates this sequence.
+-----------+
| |
GO for buffer n received --->---| Ready |-->-------+
(create and fill buffer n) | | |
+-----------+ |
Start sending buffer n
(set last-buffer-touched to n)
+-----------+ |
| | |
+------<------| Sending |--<-------+
| | |
OK for buffer n received +-----------+
| +-----------+
+------>------| |
| Sent |-->- (remove buffer n)
| |
+-----------+
Figure 3. Sending buffer state diagram
3.2.3 Receive buffer state sequence.
The state sequence for a receiving buffer is more complicated.
Assume existence of a Buffer A. When a control message for Buffer A
is sent, the buffer will move into state ACK-WAIT (it is waiting for
acknowledgement of the control message). As soon as the control
message has been acknowledged, Buffer A will move from the ACK-WAIT
state into the ACKED state (it is now waiting for DATA packets to
arrive). At this point, the control message is removed from the
control packet. Buffer A will stay in the ACKED state until a DATA,
LDATA, or NULL-ACK packet arrives with its "Last Buffer Touched"
number greater than or equal to Buffer A's number. At this time,
Buffer A's data timer is set to the time expected for the remaining
packets in the buffer to be received plus a variance, and Buffer A
will move to the RECEIVING state. (Note: This mechanism is different
from, and simpler than, the "loose/tight" timer mechanism described
in RFC 998). When all DATA packets for A have been received, it will
move from the RECEIVING state to the RECEIVED state and may be passed
to the receiving client. Had any packets been missing, Buffer A's
data timer would have expired; in that case, Buffer A will move into
the ACK-WAIT state after sending a RESEND message. The sending of a
RESEND message will cause the data timers of all buffers currently in
White [Page 10]
INTERNET DRAFT NETBLT April 1997
the RECEIVING state to be recalculated, since the presence of re-sent
packets will change the expected completion time for later buffers.
The state progression would then move as in the above example. Figure
4 illustrates this sequence.
< maximum # buffers exist &
last buffer not detected --->---------------------+
(create buffer n; send GO n) |
+--------------+
| |
+--<--ACK for buffer n GO or --<--| ACK-wait |
| RESEND message received | |
| +--------------+
+------------+ |
| | ^
| ACKed | |
| |-->---+ RESEND sent
+------------+ | (set all receiving
| buffer data timers)
DATA/LDATA/NULL-ACK with |
last-buffer-touched >= n received |
(set buffer n data timer) +-------------+
| | |
| | Resend-wait |
| | |
| +-------------+
+-------------+ | |
| |---<--+ |
| Receiving | |
| |-->-- Buffer n data timeout & ->--+
+-------------+ buffer n not complete
| (add RESEND to control packet)
|
Buffer n complete +------------+
| | |
+---->--------| Received |--->--- Buffer n flushed
| | (remove buffer n)
+------------+
Figure 4. Receiving buffer state diagram
3.2.4 Data Timers.
NETBLT solves the problem of DATA and LDATA packet loss by using a
data timer for each buffer at the receiving end. The simplest data
timer model has a data timer set when a buffer is ready to be
received; if the data timer expires, the receiving NETBLT will send a
White [Page 11]
INTERNET DRAFT NETBLT April 1997
RESEND message requesting all missing DATA/LDATA packets in the
buffer. When all packets have been received, the timer is cleared.
Data timer values are based on the amount of time taken to transfer a
buffer plus a variance factor.
The exact algorithm for data timer estimation is not mandated. The
suggested algorithm is to compute the number of packets expected
before the buffer is complete, multiply that by the time required to
transmit a packet, and add a variance. The receiver uses both the
minimum time per packet established by the burst size/burst interval,
and the measured time per packet with mean deviation, to establish
two estimates of the expected time per packet. These two estimates
are then used to calculate data timer settings for each buffer, and
the maximum value is used for that buffer's data timer. This
combination allows the demand placed on the net capacity by a given
transfer to be limited, while still avoiding unnecessary
retransmissions if the available net capacity is less than that
requested. The algorithm is as follows:
The average time-per-packet A and the mean deviation D are
initialized. The first-packet time and packet number are stored when
the first packet from a given buffer arrives, and the latest-packet
time and packet number are stored or updated as each packet from that
same buffer arrives.
When a packet from a different buffer or a NULL-ACK arrives, or a
RESEND is sent for the given buffer, the difference between the
first-packet time and the latest-packet time is divided by the
difference between the first-packet number and the latest-packet
number, to provide a sample time-per-packet. Then,
New smoothed time-per-packet = (1-a) * old smoothed time-per-packet +
a * latest time-per-packet measurement
New time-per-packet deviation = (1-b) * old time-per-packet deviation
+ b * |latest time-per-packet measurement - old smoothed time-per-
packet |
where a = 1/8 and b = 1/4, allowing computations to be done with add
and shift operations, as with the control timer. When the data timer
for a buffer must be set, two times are calculated using N, the
number of packets which must be received before the buffer is
completely filled:
T1 = 1.25 * N * smoothed time-per-packet + 2 * time-per-packet
deviation
T2 = 1.5 * N * burst interval / burst size.
White [Page 12]
INTERNET DRAFT NETBLT April 1997
The data timer is then set to the maximum of (T1, T2).
3.2.5 Death timers.
At connection startup, each NETBLT sends its death value to the other
end in either the OPEN or the RESPONSE packet. As soon as the
connection is opened, each end sets its death timer to its chosen
value; this timer is reset every time a packet is received. When a
NETBLT's death timer expires, it will close the connection without
sending any more packets.
3.2.6 Keepalive packets.
NETBLT includes a keepalive function, which sends packets repeatedly
at fixed intervals when a NETBLT has no other reason to send packets.
The sender uses NULL-ACKs as keepalive packets; the receiver uses
empty CONTROL packets. If the sending NETBLT is not ready to send
upon receipt of a control packet, it sends a single NULL-ACK packet
to clear any outstanding control timers at the receiving end. Each
end uses the other end's death-timeout value to compute a frequency
with which to send keepalive packets. The keepalive frequency should
be high enough that several keepalive packets can be lost before the
other end's death timer expires; suitable values are the sender's
death timer value divided by seven for the receiver, and the
receiver's death timer value divided by eight for the sender
(keepalive intervals should be different to avoid repeated collisions
in half-duplex operations).
3.3 Connection termination.
There are four conditions under which a connection is terminated: a
successful transfer, a client quit, a NETBLT abort, and a death timer
timeout.
3.3.1 Successful transfer.
After a successful data transfer, NETBLT closes the connection.
When the sender is transmitting the last buffer of data, it sets a
"last-buffer" flag on every DATA packet in the buffer. The receiver
will recognize that the transfer has completed successfully when all
of the following are true: (1) it has received DATA packets with a
"last- buffer" flag set, (2) all its control messages have been
acknowledged, and (3) it has no outstanding buffers with missing
packets. The DONE packet is transmitted when the receiver recognizes
that the transfer has been successfully completed. At that point,
the receiver closes its half of the connection. Figure 5 illustrates
this sequence.
White [Page 13]
INTERNET DRAFT NETBLT April 1997
+-------------+ +------------+
| | | |
| Connected |-->-- Last buffer received & --->---| Inactive |
| | all buffers disposed of & | |
+-------------+ all messages acked +------------+
(send DONE)
Figure 5. Receiver successful close state diagram
The sender will recognize that the transfer has completed when the
following are true: (1) it has transmitted DATA packets with a "last-
buffer" flag set and (2) it has received OK messages for all its
buffers. At that point, it will "dally" for a predetermined period
of time before closing its half of the connection. If the NULL-ACK
packet acknowledging the receiver's last OK message was lost, the
receiver has time to retransmit the OK message, receive a new NULL-
ACK, and recognize a successful transfer. The dally timer value is
based on the receiver's control timer value; it should be long enough
to allow the receiver's control timer to expire so that the OK
message can be re-sent. A value of twice the receiver's control timer
value is suitable for the dally timer. When the sender receives a
DONE packet, it clears its dally timer and close its half of the
connection. Figure 6 illustrates this sequence.
+-----------+
| |
| Connected |--->---+
| | |
+-----------+ All buffers flushed
(send NULL-ACK;
set dally timer)
+-----------+ |
| |---<---+-------<-----------------+
| Dallying | |
| |----->--- OK message received ->-+
+-----------+ (send NULL-ACK;
| set dally timer) +----------+
| | |
+-->-- DONE received or dally timeout ->--| Inactive |
| |
+----------+
Figure 6. Sender successful close state diagram
3.3.2 Client QUIT.
White [Page 14]
INTERNET DRAFT NETBLT April 1997
During a NETBLT transfer, one client may send a QUIT packet to the
other, to terminate the transfer prematurely. The NETBLT receiving
the QUIT packet will take no action other than immediately notifying
its client and transmitting a QUITACK packet. The QUIT sender will
time out and retransmit until a QUITACK has been received or its
death timer expires. The sender of the QUITACK will dally before
quitting, so that it can respond to a retransmitted QUIT. Figure 7
illustrates this sequence.
+-----------+
| |
+---| Connected |--->--- Quit request from client ----->---+
| | | (send QUIT; set quit timer) |
| +-----------+ +-----------+
| +- Quit timer timeout ->-| |
+->- QUIT received -->--+ | (send QUIT) | Quit-sent |
(send QUIT-ACK; | +--------<---------------| |
set dally timer) | +-----------+
+------------+ | |
| |--<---+--------<-----------+ +->--+
+---| Ouit-rcvd | | |
| | |---->----- QUIT received --+ |
| +------------+ (send QUIT-ACK; |
| set dally timer) |
| +------------+ |
| | | |
+-->-- Dally timeout -->---| Inactive |-<--QUIT-ACK received -+
| | or death timeout
+------------+
Figure 7. Quit state diagram
3.3.3 NETBLT ABORT.
An ABORT will take place when an unrecoverable malfunction occurs.
Since the ABORT originates in the NETBLT layer, it may be sent at any
time. The ABORT implies a malfunction, so no transmit reliability is
expected, and the sender will immediately close its connection.
Figure 8 illustrates this sequence.
White [Page 15]
INTERNET DRAFT NETBLT April 1997
+------------+
| |
+-<--| Connected |-->---+
| | | |
| +------------+ |
| |
ABORT received Internal malfunction
| (send ABORT)
| +------------+ |
| | | |
+->--| Inactive |--<---+
| |
+------------+
Figure 8. Abort state diagram
3.3.4 Death timer timeout.
When a NETBLT's death timer expires, it closes the connection without
sending further packets.
4. Protocol layering structure.
NETBLT may be implemented directly on top of the Internet Protocol
(IP), in which case it has been assigned an official protocol number
of 30 (decimal), which is 0x1e (hexadecimal). In other instances, it
has been implemented over UDP, for which an official protocol number
will be requested.
5. Packet formats.
NETBLT packets are divided into three categories, all of which share
a common 12-byte packet header.
a. There are three packet types that travel only from data sender
to receiver; these include the high-acknowledged-sequence-numbers
which the receiver uses for control of message transmission
reliability. They are the NULL-ACK, DATA, and LDATA packets.
b. There are two packet types that travels only from receiver to
sender. One is the CONTROL packet. Each CONTROL packet can contain
an arbitrary number of control messages (GO, OK, or RESEND), each
with its own sequence number. The other is the unreliably-transmitted
DONE packet.
c. There are six packet types which can travel in either
White [Page 16]
INTERNET DRAFT NETBLT April 1997
direction. These packet types either have special ways of insuring
reliability, or are not transmitted reliably. They are the OPEN,
RESPONSE, REFUSED, QUIT, QUITACK, and ABORT packets. The OPEN packet
travels from active side to passive side; the RESPONSE and REFUSED
packets travel from passive side to active side; and the QUIT,
QUITACK, and ABORT packets can be sent by either side.
All packet headers are "longword-aligned," such that all packet
headers are a multiple of four bytes in length and all four-byte
fields start on a longword boundary. The content of the longword
alignment fields is zeros. The Client String field is terminated
with at least one null byte, with extra null bytes added at the end
to create a field that is a multiple of four bytes long. All numeric
values are coded as binary integers.
OPEN (type 0) and RESPONSE (type 1)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Checksum | Version | Type |
+---------------+---------------+---------------+---------------+
| Length | Local Port |
+---------------+---------------+---------------+---------------+
| Foreign Port | Longword Alignment Padding |
+---------------+---------------+---------------+---------------+
| Connection Unique ID |
+---------------+---------------+---------------+---------------+
| Buffer Size |
+---------------+---------------+---------------+---------------+
| DATA packet size | Burst Size |
+---------------+---------------+---------------+---------------+
| Burst Interval | Death Timer Value |
+---------------+---------------+---------------+---------------+
| Reserved (must be zero) |C|M| Maximum # Outstanding Buffers |
+---------------+---------------+---------------+---------------+
| Client String ...
+---------------+---------------+---------------
Longword Alignment Padding |
---------------+-------------------------------+
a. Checksum: to generate the checksum, the checksum field itself is
cleared, the 16-bit ones-complement sum is computed over the packet,
and the ones complement of this sum is placed in the checksum field.
b. Version: the NETBLT protocol version number. This document describes
version 4 of NETBLT.
White [Page 17]
INTERNET DRAFT NETBLT April 1997
c. Type: the NETBLT packet type number (OPEN = 0, RESPONSE = 1, etc.)
d. Length: the total length (NETBLT header plus data, if present) of the
NETBLT packet in bytes
e. Local Port: the local NETBLT's 16-bit port number
f. Foreign Port: the foreign NETBLT's 16-bit port number
g. Connection UID: the 32 bit connection unique identifier. Connection
UID may be any randomly-selected value, which is unique in that if more
than one NETBLT connection is supported by a single host interface, it
will not be duplicated.
h. Buffer size: the size in bytes of each NETBLT buffer (except the
last)
i. Data packet size: length of each DATA packet in bytes
j. Burst Size: Number of DATA packets in a burst
k. Burst Interval: Transmit time in milliseconds of a single burst
l. Death timer: Packet sender's death timer value in seconds
m. "C": the DATA/LDATA packet data checksum flag (0 = do not checksum
DATA and LDATA packet data, 1 = do).
n. "M": the transfer mode (0 = READ, 1 = WRITE).
o. Maximum Outstanding Buffers: maximum number of buffers that can be
transferred before waiting for an OK message from the receiving NETBLT.
p. Client string: an arbitrary, null-terminated, longword-aligned string
for use by NETBLT clients.
QUITACK (type 3), and DONE (type 10)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Checksum | Version | Type |
+---------------+---------------+---------------+---------------+
| Length | Local Port |
+---------------+---------------+---------------+---------------+
| Foreign Port | Longword Alignment Padding |
+---------------+---------------+---------------+---------------+
White [Page 18]
INTERNET DRAFT NETBLT April 1997
QUIT (type 2), ABORT (type 4), and REFUSED (type 9)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Checksum | Version | Type |
+---------------+---------------+---------------+---------------+
| Length | Local Port |
+---------------+---------------+---------------+---------------+
| Foreign Port | Longword Alignment Padding |
+---------------+---------------+---------------+---------------+
| Reason for QUIT/ABORT/REFUSE...
+---------------+---------------+---------------
Longword Alignment Padding |
---------------+-------------------------------+
DATA (type 5) and LDATA (type 6)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Checksum | Version | Type |
+---------------+---------------+---------------+---------------+
| Length | Local Port |
+---------------+---------------+---------------+---------------+
| Foreign Port | Longword Alignment Padding |
+---------------+---------------+---------------+---------------+
| Buffer Number |
+---------------+---------------+---------------+---------------+
| Last Buffer Touched |
+---------------+---------------+---------------+---------------+
| High Consecutive Seq Num Rcvd | Packet Number |
+---------------+---------------+---------------+---------------+
| Data Area Checksum Value | Reserved (MBZ) |L|
+---------------+---------------+---------------+---------------+
| New Burst Size | New Burst Interval |
+---------------+---------------+---------------+---------------+
a. Checksum: checksum of the packet header only, including the Data Area
Checksum Value.
b. Buffer number: a 32 bit unique number assigned to every buffer.
Buffers are sequentially numbered, starting with 1.
c. Last Buffer Touched: the number of the highest buffer transmitted so
far.
White [Page 19]
INTERNET DRAFT NETBLT April 1997
d. High Consecutive Sequence Number Received: Highest control message
sequence number below which all control messages have been received.
e. Packet number: sequential, monotonically increasing DATA packet
identifier, starting with 0 in each buffer.
f. Data Area Checksum Value: Checksum of the DATA packet's data.
Algorithm used is the same as that used to compute checksums of other
NETBLT packets.
g. "L" is a bit that is set to 1 when the buffer that this DATA packet
belongs to is the last buffer in the transfer.
h. New Burst Size: Burst size as negotiated from value given by
receiving NETBLT in OK message.
i. New Burst Interval: Burst interval as negotiated from value given by
receiving NETBLT in OK message. Value is in milliseconds.
NULL-ACK (type 7)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Checksum | Version | Type |
+---------------+---------------+---------------+---------------+
| Length | Local Port |
+---------------+---------------+---------------+---------------+
| Foreign Port | Longword Alignment Padding |
+---------------+---------------+---------------+---------------+
| Last Buffer Touched |
+---------------+---------------+---------------+---------------+
| High Consecutive Seq Num Rcvd | New Burst Size |
+---------------+---------------+---------------+---------------+
| New Burst Interval | Longword Alignment Padding |L|
+---------------+---------------+---------------+---------------+
a. Last Buffer Touched: the number of the highest buffer transmitted so
far.
b. High Consecutive Sequence Number Received: same as in DATA/LDATA
packet.
c. New Burst Size: Burst size as negotiated (half- and full-duplex
only) from value given by receiving NETBLT in OK message.
White [Page 20]
INTERNET DRAFT NETBLT April 1997
d. New Burst Interval: Burst interval as negotiated (half- and full-
duplex only) from value given by receiving NETBLT in OK message. Value
is in milliseconds.
e. "L" is a bit that is set to 1 when the buffer identified in the Last
Buffer Touched field is the last buffer in the transfer.
CONTROL (type 8)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Checksum | Version | Type |
+---------------+---------------+---------------+---------------+
| Length | Local Port |
+---------------+---------------+---------------+---------------+
| Foreign Port | Longword Alignment Padding |
+---------------+---------------+---------------+---------------+
Followed by any number of messages, each of which is longword
aligned, with the following formats:
GO message (subtype 0)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Subtype | Word Padding | Sequence Number |
+---------------+---------------+---------------+---------------+
| Buffer Number |
+---------------+---------------+---------------+---------------+
a. Subtype: message type (GO = 0, OK = 1, RESEND = 2)
b. Sequence number: A 16 bit unique message number. Sequence numbers
must be monotonically increasing, starting with 1.
c. Buffer number: as in DATA/LDATA packet
White [Page 21]
INTERNET DRAFT NETBLT April 1997
OK message (subtype 1).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Subtype | Word Padding | Sequence Number |
+---------------+---------------+---------------+---------------+
| Buffer Number |
+---------------+---------------+---------------+---------------+
| New Offered Burst Size | New Offered Burst Interval |
+---------------+---------------+---------------+---------------+
| Current control timer value | Longword Alignment Padding |
+---------------+---------------+---------------+---------------+
a. New offered burst size: burst size for subsequent buffer transfers,
possibly based on performance information for previous buffer
transfers.
b. New offered burst interval: burst rate for subsequent buffer
transfers, possibly based on performance information for previous
buffer transfers. Rate is in milliseconds.
c. Current control timer value: Receiving NETBLT's control timer value
in milliseconds.
RESEND message (subtype 2)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Subtype | Word Padding | Sequence Number |
+---------------+---------------+---------------+---------------+
| Buffer Number |
+---------------+---------------+---------------+---------------+
| Number of Missing Packets | New Offered Burst Size |
+---------------+---------------+---------------+---------------+
| New Offered Burst Interval | Longword Alignment Padding |
+---------------+---------------+---------------+---------------+
| Packet Number (2 bytes/packet)| ...
+---------------+---------------+----------
| Padding (if necessary) |
-----------+---------------+---------------+
a. Packet number: the 16 bit data packet identifier of a DATA packet,
from the buffer identified by Buffer Number, whose retransmission is
requested. Multiple packet numbers may occur in one RESEND message.
6. NETBLT modes of operation.
White [Page 22]
INTERNET DRAFT NETBLT April 1997
NETBLT supports three modes of operation; simplex, half-duplex, and
full-duplex. This section identifies the required components of
NETBLT for simplex and half-duplex modes of operation. Across full-
duplex connections the normal NETBLT as described above is used.
6.1 Simplex.
The only NETBLT packet types used in the simplex case are the
following:
a. OPEN
b. QUIT
c. ABORT
d. DATA
e. LDATA
f. NULL-ACK
6.1.1 Sender simplex operation.
Operation of NETBLT in simplex send mode is as follows: the OPEN
message is sent; DATA and LDATA packets are sent; and the connection
is closed. Any packet may be sent more than once, for redundancy, but
for all n, packets from buffer(n - 1) will not be sent after packets
from buffer(n). QUIT and ABORT packets may be sent at any time, and
will have the same effect. The Maximum Number of Outstanding Buffers
(in the OPEN packet) is set to 2.
6.1.2 Receiver simplex operation.
Operation of NETBLT in simplex receive mode is as follows: when an
OPEN packet is received, a connection is considered to be
established. Packets received are stored into NETBLT buffers. The
receiving NETBLT will pass a buffer to the client when the buffer is
filled with correct packets or when good packets for a higher-
numbered buffer are received. A list of packets which are possibly
bad, or missing, is passed to the client. When the last buffer (L
flag set in packet headers) has been passed to the client, or when
the death timeout has expired, the receiving connection is
terminated.
The receiving NETBLT will discard redundant packets. In the case of
errors, the following rules apply at the receiving NETBLT:
a. A NETBLT packet with a bad header checksum is discarded.
b. A NETBLT DATA or LDATA packet with a good header checksum and a
bad data area checksum may optionally be saved but flagged as
possibly bad. Reasonableness checks may be used to insure that good
White [Page 23]
INTERNET DRAFT NETBLT April 1997
data is not affected by the possibly bad packet data. If a good
NETBLT packet (redundantly transmitted) is received with the same
buffer and packet number as a possibly bad one, the possibly bad
packet is replaced with the good one.
6.2 Half-duplex.
The normal, full-duplex version of NETBLT operates across half-duplex
connections with the following modification: keepalive packets will
not be sent by the receiver while it is in the process of receiving a
packet. The burst timer and burst size counter are reset at the
start of each transmission period. If the Maximum Number of
Outstanding Buffers (in the OPEN packet) is set to 1, the sending and
receiving NETBLTs will operate in lockstep. If the Maximum Number of
Outstanding Buffers is set to a value N greater than 1, the receiving
NETBLT will wait until N buffers have been completely received or
have had their data timers expire before sending a CONTROL packet.
An exception occurs when the last buffer is sent; when all buffers up
to and including the last buffer have been completely received or
have had their data timers expire, the receiving NETBLT is permitted
to send its CONTROL packet. The last buffer is identified by the
receiver as the buffer for which the "L" bit is set in a DATA/LDATA
packet, or as the Last Buffer Touched in a NULL-ACK packet with its
"L" bit set to 1.
7. Security Considerations
Security considerations for NETBLT operation have not been addressed
in this document.
8. Possible Extensions
Two forms of extension to NETBLT are being examined. The first would
make it possible for NETBLT to operate as a unidirectional stream
protocol, by allowing all buffers, not just the last one, to be of
any size less than or equal to the negotiated size. The second would
provide a "Transaction NETBLT", using an approach similar to
Transaction TCP [RFC1379].
9. References
[Jacobsen] Jacobsen, V. "Congestion Avoidance and Control", ACM
SIGCOMM 88 Symposium Proceedings, August 1988
[MIL-STD] MIL-STD-2045-44500 "Tactical Communications Protocol 2
(TACO2) for the National Imagery Transmission Format Standard", June
1993
White [Page 24]
INTERNET DRAFT NETBLT April 1997
[RFC998] Clark, D., Lambert, M., and Zhang, L. "NETBLT: A Bulk Data
Transfer Protocol", RFC 998, March 1987
[RFC1379] Braden, R., "Extending TCP for Transactions -- Concepts",
RFC 1379, November 1992
10. Author's Address
John C. C. White
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730-1420
Phone: 617-271-3284
Fax: 617-271-2721
Email: jccw@mitre.org
White [Page 25]
