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]