Internet DRAFT - draft-white-tsvwg-netblt

draft-white-tsvwg-netblt



 



Internet-Draft                                                  J. White
Intended Status: Standards Track                          M. Yevstifeyev
Obsoletes: 998 (if approved)                            January 30, 2011
Expires: August 3, 2011                                                 

                Network Block Transfer Protocol (NETBLT)
                     <draft-white-tsvwg-netblt-02>

Abstract

   This document is a specification of version 5 of Network Block
   Transfer Protocol (NETBLT), that is used for transferring large
   amount of data.  This protocol was firstly specified in RFC 969, that
   has been made obsolete by RFC 998.  Nevertheless, none of these
   documents match current Internet Standards and are outdated.

   This document aligns the NETBLT specification with the most current
   Internet Standards and obsoletes RFC 998.


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
 


White & Yevstifeyev      Expires August 3, 2011                 [Page 1]

INTERNET DRAFT                   NETBLT                 January 30, 2011


   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
      1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
   2. Protocol Overview  . . . . . . . . . . . . . . . . . . . . . . . 5
      2.1. Buffers and Packets . . . . . . . . . . . . . . . . . . . . 5
      2.2. Buffer Operations . . . . . . . . . . . . . . . . . . . . . 5
      2.3. Flow Control  . . . . . . . . . . . . . . . . . . . . . . . 6
         2.3.1. Client Level Flow Control  . . . . . . . . . . . . . . 6
         2.3.2. Internal Flow Control  . . . . . . . . . . . . . . . . 6
      2.4. Checksumming  . . . . . . . . . . . . . . . . . . . . . . . 6
      2.5. Lower Layer Considerations  . . . . . . . . . . . . . . . . 7
   3.  NETBLT Detailed Operation . . . . . . . . . . . . . . . . . . . 8
      3.1. Connection Setup  . . . . . . . . . . . . . . . . . . . . . 8
      3.2. Data Transfer . . . . . . . . . . . . . . . . . . . . . .  11
         3.2.1. Duplex Transfer Mode . . . . . . . . . . . . . . . .  11
         3.2.2. Simplex Transfer Mode  . . . . . . . . . . . . . . .  12
            3.2.2.1. Sender Simplex Operation  . . . . . . . . . . .  12
            3.2.2.2. Receiver Simplex Operation  . . . . . . . . . .  12
      3.3. Control Messages  . . . . . . . . . . . . . . . . . . . .  13
      3.4. Buffers State Sequences . . . . . . . . . . . . . . . . .  14
         3.4.1. Send Buffer State Sequence . . . . . . . . . . . . .  14
         3.4.2. Receive Buffer State Sequence  . . . . . . . . . . .  15
      3.5. Timers  . . . . . . . . . . . . . . . . . . . . . . . . .  16
         3.5.1. Data Timers  . . . . . . . . . . . . . . . . . . . .  16
         3.5.2. Death Timers . . . . . . . . . . . . . . . . . . . .  17
         3.2.3. Quit Timers  . . . . . . . . . . . . . . . . . . . .  17
         3.2.4. Dally Timers . . . . . . . . . . . . . . . . . . . .  17
      3.6. Keepalive Packets . . . . . . . . . . . . . . . . . . . .  17
      3.7. Connection Termination  . . . . . . . . . . . . . . . . .  17
         3.7.1. Successful Transfer  . . . . . . . . . . . . . . . .  17
         3.7.2. Client QUIT  . . . . . . . . . . . . . . . . . . . .  19
         3.7.3. NETBLT ABORT . . . . . . . . . . . . . . . . . . . .  20
         3.7.4. Death Timer Timeout  . . . . . . . . . . . . . . . .  20
      3.8. NETBLT over UDP . . . . . . . . . . . . . . . . . . . . .  20
   4. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . .  21
      4.1. OPEN and RESPONSE Packets . . . . . . . . . . . . . . . .  22
      4.2. QUITACK and DONE Packets  . . . . . . . . . . . . . . . .  23
 


White & Yevstifeyev      Expires August 3, 2011                 [Page 2]

INTERNET DRAFT                   NETBLT                 January 30, 2011


      4.3. QUIT, ABORT, REFUSED and MESSAGE Packets  . . . . . . . .  24
      4.4. DATA and LDATA Packets  . . . . . . . . . . . . . . . . .  24
      4.5. NULL-ACK Packet . . . . . . . . . . . . . . . . . . . . .  25
      4.6. CONTROL Packet  . . . . . . . . . . . . . . . . . . . . .  26
         4.6.1. GO Message . . . . . . . . . . . . . . . . . . . . .  26
         4.6.2. OK Message . . . . . . . . . . . . . . . . . . . . .  27
         4.6.3. RESEND Message . . . . . . . . . . . . . . . . . . .  28
   5. Security Considerations  . . . . . . . . . . . . . . . . . . .  29
   6. RFC Editor Consideration . . . . . . . . . . . . . . . . . . .  29
   7. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  29
      7.1.  'NETBLT Packet Types' Registry . . . . . . . . . . . . .  29
         7.1.1. 'CONTROL Messages Types' Sub-Registry  . . . . . . .  30
      7.2.  'NETBLT Version Numbers' Registry  . . . . . . . . . . .  31
      7.3. Procedures for Assignment of NETBLT Ports . . . . . . . .  31
         7.3.1. Reserved Values  . . . . . . . . . . . . . . . . . .  32
         7.3.2. Pre-Defined Values . . . . . . . . . . . . . . . . .  32
            7.3.2.1. TACO2 Port Number Assignment  . . . . . . . . .  32
            7.3.2.2. Values for Experimentation  . . . . . . . . . .  32
      7.4. UDP Port Number Assignment  . . . . . . . . . . . . . . .  33
      7.5. IP Protocol Number Assignment . . . . . . . . . . . . . .  34
   8. References . . . . . . . . . . . . . . . . . . . . . . . . . .  34
      8.1. Normative References  . . . . . . . . . . . . . . . . . .  34
      8.2. Informative References  . . . . . . . . . . . . . . . . .  34
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  35
























 


White & Yevstifeyev      Expires August 3, 2011                 [Page 3]

INTERNET DRAFT                   NETBLT                 January 30, 2011


1. Introduction

   Network Block Transfer Protocol (NETBLT), that was firstly defined in
   [RFC969], that has been made obsolete by [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. 

   A number of experiments were conducted nearly at the time of
   publication of RFC 998 with NETBLT.  The results of these experiments
   are discussed in RFC 1030 [RFC1030].  Among other, a number of
   characteristics which make NETBLT very attractive for use across
   noisy, long-delay, slow-turnaround, or asymmetric communications
   links were found out.  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 network delays. NETBLT,
   with minor modifications, was adopted as the transport layer of the
   military standard TACO2 (Tactical Communications Protocol 2) [MIL-
   STD-2045-44500], 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.

   The military standard definition of NETBLT was developed from RFC 998
   [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.  

   Since the NETBLT defined in [MIL-STD-2045-44500] uses the version
   number 4, this document specifies version 5 of NETBLT.

1.1  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   Specific packet types are identified in the following sections by
 


White & Yevstifeyev      Expires August 3, 2011                 [Page 4]

INTERNET DRAFT                   NETBLT                 January 30, 2011


   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. Protocol Overview

   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.

2.1. Buffers and Packets

   The data to be transmitted is broken up into buffers by the sending
   client.  All buffers MUST be 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 MUST be the same size.  DATA and LDATA packets are
   identical in format except for the packet type.

2.2. Buffer Operations

   In its simplest form, a single-buffer 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 to the receiver. 
   The receiving NETBLT loads these packets into a matching buffer. 
   When 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
 


White & Yevstifeyev      Expires August 3, 2011                 [Page 5]

INTERNET DRAFT                   NETBLT                 January 30, 2011


   sender notifies the receiver that the transmission has been
   completed.  The two sides then close the connection.

   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. Flow Control

   NETBLT uses two strategies for flow control, one at the client level
   and one internal.

2.3.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
   by not providing a new buffer.  Clients cannot stop a buffer transfer
   once it is in progress, except by aborting the entire transfer.

2.3.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.

   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.

2.4. Checksumming

   NETBLT SHALL automatically checksum each packet header and,
   optionally, 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
 


White & Yevstifeyev      Expires August 3, 2011                 [Page 6]

INTERNET DRAFT                   NETBLT                 January 30, 2011


   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.

2.5. Lower Layer Considerations

   NETBLT MUST support either Internet Protocol version 4 (IPv4)
   [RFC791] or Internet Protocol version 6 (IPv6) [RFC2460], in which
   case it has been assigned an official protocol number of 30
   (decimal), which is 0x1e (hexadecimal).  It also SHOULD be able to
   operate on top of any datagram protocol similar in function to IP,
   such as TP/IX [RFC1475] or EIP [RFC1385].

   Moreover, NETBLT MAY be implemented over UDP [RFC768] or UDP-Lite
   [RFC3828].  More detailed description of NETBLT over UDP may be found
   in Section 3.8.































 


White & Yevstifeyev      Expires August 3, 2011                 [Page 7]

INTERNET DRAFT                   NETBLT                 January 30, 2011


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.

   All NETBLT flow control parameters (packet size, buffer size, number
   of buffers outstanding, burst size, and burst interval) are
   negotiated during connection setup (if a connection can be
   established).  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.  See
   Section 3.2.1 for details.

   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
 


White & Yevstifeyev      Expires August 3, 2011                 [Page 8]

INTERNET DRAFT                   NETBLT                 January 30, 2011


   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.  Moreover, NETBLT provides the
   possibility for clients to exchange arbitrary messages by MESSAGE
   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.
   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.
















 


White & Yevstifeyev      Expires August 3, 2011                 [Page 9]

INTERNET DRAFT                   NETBLT                 January 30, 2011


     +------------+
     |            |--------<-----------------------------+
     |  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


            +------------+
            |            |--->----------+
       +-<--|  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




 


White & Yevstifeyev      Expires August 3, 2011                [Page 10]

INTERNET DRAFT                   NETBLT                 January 30, 2011


3.2. Data Transfer

   NETBLT supports two modes of operation: duplex and simplex.  This
   section identifies the required components of NETBLT for all modes of
   operation.

3.2.1. Duplex Transfer Mode

   The simplest 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 SHALL 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.

   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.

   A more efficient 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
 


White & Yevstifeyev      Expires August 3, 2011                [Page 11]

INTERNET DRAFT                   NETBLT                 January 30, 2011


   sender has available two buffers A and B in a multiple-buffer
   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.2. Simplex Transfer Mode

   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

3.2.2.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.

3.2.2.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:
 


White & Yevstifeyev      Expires August 3, 2011                [Page 12]

INTERNET DRAFT                   NETBLT                 January 30, 2011


   a. A NETBLT packet with a bad header checksum SHALL be 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
   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 MSUT be replaced with the good one.

3.3. 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 & Yevstifeyev      Expires August 3, 2011                [Page 13]

INTERNET DRAFT                   NETBLT                 January 30, 2011


   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 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.

   NETBLT control messages are used only in full-duplex and half-duplex
   modes.

3.4. Buffers State Sequences

3.4.1. Send Buffer State Sequence

   The state sequence for a sending buffer is as follows: when a GO
   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)
                                    |           |
                                    +-----------+
 


White & Yevstifeyev      Expires August 3, 2011                [Page 14]

INTERNET DRAFT                   NETBLT                 January 30, 2011


   Figure 3. Sending buffer state diagram

3.4.2. 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
   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.




















 


White & Yevstifeyev      Expires August 3, 2011                [Page 15]

INTERNET DRAFT                   NETBLT                 January 30, 2011


    < 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.5. Timers

3.5.1. 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
   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.
 


White & Yevstifeyev      Expires August 3, 2011                [Page 16]

INTERNET DRAFT                   NETBLT                 January 30, 2011


3.5.2. 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 SHALL close the connection without
   sending any more packets.

3.2.3. Quit Timers

   The quit timer is used to ensure that the QUIT packet was
   successfully received by another NETBLT host.  Once the QUIT packet
   is sent, the quit timer is set.  When the quit timer expires, another
   QUIT message is sent.  This continues until the death timer expires.

3.2.4. Dally Timers

   The dally timer is set once the NETBLT host receives the QUIT packet
   and is used to ensure that no other packets will be received.  When
   the dally timer expires, the host may close its part of the
   connection.

3.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.7. 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.7.1. Successful Transfer

 


White & Yevstifeyev      Expires August 3, 2011                [Page 17]

INTERNET DRAFT                   NETBLT                 January 30, 2011


   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.

    +-------------+                                    +------------+
    |             |                                    |            |
    |  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.












 


White & Yevstifeyev      Expires August 3, 2011                [Page 18]

INTERNET DRAFT                   NETBLT                 January 30, 2011


    +-----------+
    |           |
    | 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.7.2. Client QUIT

   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 -+
 


White & Yevstifeyev      Expires August 3, 2011                [Page 19]

INTERNET DRAFT                   NETBLT                 January 30, 2011


                               |            |     or death timeout
                               +------------+

    Figure 7. Quit state diagram

3.7.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.

                +------------+
                |            |
           +-<--| Connected  |-->---+
           |    |            |      |
           |    +------------+      |
           |                        |
      ABORT received            Internal malfunction
           |                     (send ABORT)
           |    +------------+      |
           |    |            |      |
           +->--|  Inactive  |--<---+
                |            |
                +------------+

   Figure 8. Abort state diagram


3.7.4. Death Timer Timeout

   When a NETBLT's death timer expires, it SHALL close the connection
   without sending further packets.

3.8. NETBLT over UDP

   As mentioned in Section 2.5, NETBLT may be implemented over UDP
   [RFC768] and UDP-Lite [RFC3828].  It is used to transfer NETBLT
   packets over the hosts that do not support it.  This section contains
   the detailed description of this encapsulation mechanism.

   If NETBLT is used over UDP, the UDP header fields 'Source Port' and
   'Destination Port' SHALL be set to TBD1.  Then NETBLT packet is put
   directly after UDP header.  The packet, formed in this way is sent to
   the destination host.

   If UDP-Lite is used, it is RECOMMENDED that the checksum covers only
 


White & Yevstifeyev      Expires August 3, 2011                [Page 20]

INTERNET DRAFT                   NETBLT                 January 30, 2011


   NETBLT header.


4. 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
     direction. These packet types either have special ways of insuring
     reliability, or are not transmitted reliably.  They are the OPEN,
     RESPONSE, REFUSED, QUIT, QUITACK, MESSAGE 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.














 


White & Yevstifeyev      Expires August 3, 2011                [Page 21]

INTERNET DRAFT                   NETBLT                 January 30, 2011


4.1. OPEN and RESPONSE Packets

   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 5 of NETBLT.

     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
 


White & Yevstifeyev      Expires August 3, 2011                [Page 22]

INTERNET DRAFT                   NETBLT                 January 30, 2011


     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.

4.2. QUITACK and DONE Packets

   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 & Yevstifeyev      Expires August 3, 2011                [Page 23]

INTERNET DRAFT                   NETBLT                 January 30, 2011


4.3. QUIT, ABORT, REFUSED and MESSAGE Packets

   QUIT (type 2), ABORT (type 4), REFUSED (type 9) and MESSAGE (type 11)
     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 or arbitrary message ... 
    +---------------+---------------+---------------
                                      Longword Alignment Padding    |
                     ---------------+-------------------------------+


4.4. DATA and LDATA Packets

   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     |
    +---------------+---------------+---------------+---------------+
    |   Data Area ...
    +---------------+---------------+---------------
                                      Longword Alignment Padding    |
                     ---------------+-------------------------------+

     a. Checksum: checksum of the packet header only, including the Data
     Area Checksum  Value.
 


White & Yevstifeyev      Expires August 3, 2011                [Page 24]

INTERNET DRAFT                   NETBLT                 January 30, 2011


     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.

     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.

4.5. NULL-ACK Packet

   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
 


White & Yevstifeyev      Expires August 3, 2011                [Page 25]

INTERNET DRAFT                   NETBLT                 January 30, 2011


     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.

     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.

4.6. CONTROL Packet

   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.

4.6.1. GO Message

   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.
 


White & Yevstifeyev      Expires August 3, 2011                [Page 26]

INTERNET DRAFT                   NETBLT                 January 30, 2011


     c. Buffer number: as in DATA/LDATA packet

4.6.2. OK Message

     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.




















 


White & Yevstifeyev      Expires August 3, 2011                [Page 27]

INTERNET DRAFT                   NETBLT                 January 30, 2011


4.6.3. RESEND Message

     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.
























 


White & Yevstifeyev      Expires August 3, 2011                [Page 28]

INTERNET DRAFT                   NETBLT                 January 30, 2011


5. Security Considerations

   NETBLT provides no authentification features itself.  Further
   versions might these issues as well.

   One can notice that NETBLT may create excessive congestion.  While
   testing NETBLT [RFC1030] it was noticed that traffic from one side of
   the connection might hog all the line bandwidth not allowing the
   traffic from other side make its way trough to other one.  This
   problem does not seem to be resolvable under the current rate control
   scheme.  However NETBLT is intended to be used in the environments
   where such issues are already properly considered.

   Additional security may be provided by the upper-layer protocols,
   that may also provide their own congestion control mechanism and/or
   authentification features.


6. RFC Editor Consideration

   RFC Editor is asked to mark the following RFC as Historic and
   obsoleted by this document:

   RFC 998 [RFC998]

   Moreover, RFC 969 [RFC969] is asked to be marked as Historic.


7. IANA Considerations

7.1.  'NETBLT Packet Types' Registry

   IANA is asked to create and maintain the registry called 'NETBLT
   Packet Types' following the guidelines below.

   The 'NETBLT Packet Types' registry consists of 3 values: Packet Type
   Number, Description and Reference.  They are described below:

     Packet Type Number - an integer; refers to the value used in NETBLT
     header.  Values form 0 to 255 are assigned.

     Description - a brief decryption of packet type.

     Reference - the reference document, that defines the packet type.

   Initial values are given below; new assignments to 'NETBLT Packet
   Types' registry are to be made following the 'IETF Consensus'
   policies. [RFC5226]
 


White & Yevstifeyev      Expires August 3, 2011                [Page 29]

INTERNET DRAFT                   NETBLT                 January 30, 2011


   +--------+-------------------------------------+-----------+
   | Number | Description                         | Reference |
   +--------+-------------------------------------+-----------+
   |0       | OPEN                                | RFC xxxx  |
   |1       | RESPONSE                            | RFC xxxx  |
   |2       | QUIT                                | RFC xxxx  |
   |3       | QUITACK                             | RFC xxxx  |
   |4       | ABORT                               | RFC xxxx  |
   |5       | DATA                                | RFC xxxx  |
   |6       | LDATA                               | RFC xxxx  |
   |7       | NULL-ACK                            | RFC xxxx  |
   |8       | CONTROL                             | RFC xxxx  |
   |9       | REFUSED                             | RFC xxxx  |
   |10      | DONE                                | RFC xxxx  |
   |11      | MESSAGE                             | RFC xxxx  |
   |12-253  | Unassigned                          | RFC xxxx  |
   |254     | Used for Experimentation            | RFC xxxx  |
   |255     | Reserved                            | RFC xxxx  |
   +--------+-------------------------------------+-----------+
   [RFC Editor: Replace xxxx with assigned RFC number]

7.1.1. 'CONTROL Messages Types' Sub-Registry

   IANA is asked to create and maintain the 'CONTROL Messages Types'
   sub-registry in the 'NETBLT Packet Types' registry following the
   guidelines below.

   The 'CONTROL Messages Types' sub-registry consists of 3 values:
   CONTROL Message Type Number, Description and Reference. They are
   described below:

     CONTROL Message Type Number - an integer; refers to the value used
     in NETBLT CONTROL message. Values form 0 to 255 are assigned.

     Description - a brief decryption of packet type.

     Reference - the reference document, that defines the packet type.

   Initial values are given below; new assignments to 'CONTROL Messages
   Types' sub-registry are to be made following the 'IETF Consensus'
   policies [RFC5226].

   +--------+-------------------------------------+-----------+
   | Number | Description                         | Reference |
   +--------+-------------------------------------+-----------+
   |0       | GO                                  | RFC xxxx  |
   |1       | OK                                  | RFC xxxx  |
   |2       | RESEND                              | RFC xxxx  |
 


White & Yevstifeyev      Expires August 3, 2011                [Page 30]

INTERNET DRAFT                   NETBLT                 January 30, 2011


   |3-253   | Unassigned                          | RFC xxxx  |
   |254     | Used for Experimentation            | RFC xxxx  |
   |255     | Reserved                            | RFC xxxx  |
   +--------+-------------------------------------+-----------+
   [RFC Editor: Replace xxxx with assigned RFC number]

7.2.  'NETBLT Version Numbers' Registry

   IANA is asked to create and maintain the registry called 'NETBLT
   Version Numbers' following the guidelines below.

   The 'NETBLT Version Numbers' registry consists of 3 values: Version
   Number, State and Reference. They are described below:

     Version Number - an integer; refers to the value used in NETBLT
     header. Values form 0 to 255 are assigned.

     State - may be assigned as 'Specified' for those NETBLT versions
     that are properly specified, 'Reserved' or 'Unassigned', that are
     used as described in RFC 5226 [RFC5226].

     Reference - the reference document, that defines the particular
     version of NETBLT.

   Initial values are given below; new assignments to 'NETBLT Version
   Numbers' registry are to be made following the 'Specification
   Required' policies. [RFC5226]

   +--------+---------------------------+--------------------+
   |Version | State                     | Reference          |
   +--------+---------------------------+--------------------+
   |0       | Reserved                  | RFC xxxx           |
   |1       | Specified                 | RFC 969            |
   |2       | Specified                 | RFC 998            |
   |3       | Reserved                  | RFC xxxx           |
   |4       | Specified                 | MIL-STD-2045-44500 |
   |5       | Specified                 | RFC xxxx           |
   |6-255   | Unassigned                | RFC xxxx           |
   |256     | Reserved                  | RFC xxxx           |
   +--------+---------------------------+--------------------+
   [RFC Editor: Replace xxxx with assigned RFC number]

   No sub-registries are currently defined in 'NETBLT Version Numbers'
   registry.

7.3. Procedures for Assignment of NETBLT Ports

   Since the issues discussed in Section 6 of [I.D. draft-ietf-tsvwg-
 


White & Yevstifeyev      Expires August 3, 2011                [Page 31]

INTERNET DRAFT                   NETBLT                 January 30, 2011


   iana-ports] concern NETBLT port numbers range as well, IANA is asked
   to create the independent registry for NETBLT port numbers and
   maintain in following the guidelines of Section 8 of [I.D. draft-
   ietf-tsvwg-iana-ports].

7.3.1. Reserved Values

   IANA is asked to reserve the following NETBLT ports: 0, 1023, 1024
   and 49151 for future use.

7.3.2. Pre-Defined Values

7.3.2.1. TACO2 Port Number Assignment

   IANA is asked to assign the port number for TACO2 using the following
   template:

     Service Name: TACO2

     Transport Protocol: NETBLT

     Assignee: United States Department of Defense,
     1400 Defense Pentagon Washington, DC 20301-1400

     Contact: United States Department of Defense,
     1400 Defense Pentagon Washington, DC 20301-1400

     Description: Tactical Communications Protocol 2 (TACO2) for the
     National Imagery Transmission Format Standard

     Reference:[MIL-STD-2045-44500]

     Port Number: 1

     Assignment Notes: The document that defines TACO2 appeared before
     this document, that defined registration procedures for NETBLT port
     numbers.  That is why MIL-STD-2045-44500 mentioned the port number
     1 to be used without official registration.  This assignment is to
     officially register the port number for TACO2.

7.3.2.2. Values for Experimentation

   IANA is asked to register 2 NETBLT ports for experimentation using
   the following templates:

     Service Name: exp1

     Transport Protocol: NETBLT
 


White & Yevstifeyev      Expires August 3, 2011                [Page 32]

INTERNET DRAFT                   NETBLT                 January 30, 2011


     Assignee: IETF <iesg@ietf.org>

     Contact: IESG <iesg@ietf.org>

     Description: RFC-3962 style Experiment 1

     Reference: RFC xxxx

     Port Number: 1021


     Service Name: exp2

     Transport Protocol: NETBLT

     Assignee: IETF <iesg@ietf.org>

     Contact: IESG <iesg@ietf.org>

     Description: RFC-3962 style Experiment 2

     Reference: RFC xxxx

     Port Number: 1022

7.4. UDP Port Number Assignment

   Since NETBLT may be implemented over UDP (see Section 3.8), an
   official port number is needed for it.  IANA is asked to register the
   port number for NETBLT using the following template (see [I.D. draft-
   ietf-tsvwg-iana-ports]):

     Service Name: netblt

     Transport Protocol: UDP

     Assignee: IETF <iesg@ietf.org>

     Contact: IESG <iesg@ietf.org>

     Description: NETBLT Encapsulation

     Reference: RFC xxxx

     Port Number: TBD1, please register the user-registered one



 


White & Yevstifeyev      Expires August 3, 2011                [Page 33]

INTERNET DRAFT                   NETBLT                 January 30, 2011


7.5. IP Protocol Number Assignment

   IANA has assigned the IP protocol number 30 for NETBLT.


8. References

8.1. Normative References

   [I.D. draft-ietf-tsvwg-iana-ports] 
               M. Cotton, L. Eggert, J. Touch, M. Westerlund and
               Cheshire, S., "Internet Assigned Numbers Authority (IANA)
               Procedures for the Management of the Service Name and
               Transport Protocol Port Number Registry", work in
               progress

   [RFC791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
               September 1981.

   [RFC2460]   Deering, S. and R. Hinden, "Internet Protocol, Version 6
               (IPv6) Specification", RFC 2460, December 1998.

   [RFC2119]   S. Bradner, "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5226]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
               May 2008.

8.2. Informative References

   [MIL-STD-2045-44500] 
               MIL-STD-2045-44500, "Tactical Communications Protocol 2
               (TACO2) for the National Imagery Transmission Format
               Standard", June 1993

   [RFC768]    Postel, J., "User Datagram Protocol", STD 6, RFC 768,
               August 1980.

   [RFC969]    Clark, D., Lambert, M., and L. Zhang, "NETBLT: A bulk
               data transfer protocol", RFC 969, December 1985.

   [RFC998]    Clark, D., Lambert, M., and Zhang, L. "NETBLT: A Bulk
               Data Transfer Protocol", RFC 998, March 1987

   [RFC1030]   Lambert, M., "On testing the NETBLT Protocol over divers
               networks", RFC 1030, November 1987.

 


White & Yevstifeyev      Expires August 3, 2011                [Page 34]

INTERNET DRAFT                   NETBLT                 January 30, 2011


   [RFC1385]   Wang, Z., "EIP: The Extended Internet Protocol", RFC
               1385, November 1992.

   [RFC1475]   Ullmann, R., "TP/IX: The Next Internet", RFC 1475, June
               1993.

   [RFC3828]   Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
               J. Fairhurst "The Lightweight User Datagram Protocol
               (UDP-Lite)", RFC 3828, July 2004


Author's Address

   John White
   Bedford, USA

   EMail: jccw@jccw.org


   Mykyta Yevstifeyev
   Kotovsk, Ukraine

   EMail: evnikita2@gmail.com




























White & Yevstifeyev      Expires August 3, 2011                [Page 35]