University of California, Berkeley Intel Research Berkeley XXX address, etc This internet draft describes a protocol for implementing a Convergence Layer as described in the Architecture for Delay Tolerant Networking (DTN), using the TCP transport protocol.

This document describes version 2 of the Delay Tolerant Networking TCP convergence layer protocol (DTN-TCPCL). Delay Tolerant Networking is an end-to-end architecture providing communications in and/or through highly stressed environments, including those with intermittent connectivity, long and/or variable delays, and high bit error rates. More detailed descriptions of the rationale and capabilities of these networks can be found in the Delay-Tolerant Network Architecture Internet Draft. An important goal of the DTN architecture is to accomodate a wide range of networking technologies and environments. The protocol used for DTN communications is the Bundling Protocol (BP), an application-layer protocol that is used to construct a store-and-forward overlay network. As described in the bundle protocol specification, BP requires the services of a "convergence layer adapter" (CLA) to send and receive bundles using an underlying internet protocol. This document describes one such convergence layer adapter that uses the well-known Transmission Control Protocol (TCP). The locations of the TCPCL and BP in the Internet model protocol stack are shown in Figure . In particular, both the BP and the TCPCL sit at the application layer, while TCP and IP sit at their normal layers.

+-------------------------+ | DTN Application | -\ +-------------------------| | | Bundle Protocol (BP) | -> Application Layer +-------------------------+ | | TCP Conv. Layer (TCPCL) | -/ +-------------------------+ | TCP | ---> Transport Layer +-------------------------+ | IP | ---> Network Layer +-------------------------+ | Link-Layer Protocol | ---> Link Layer +-------------------------+ | Physical Medium | ---> Physical Layer +-------------------------+

This document describes the format of the protocol data units (called bundles) passed between entities participating in TCPCL communications. The entities are referred to as "bundle nodes". This document does not address: The format of protocol data units of the bundling protocol itself, as those are defined elsewhere . Mechanisms for locating or identifying other bundle nodes within an internet. Operational logic or procedures used to implement this protocol. Note that this document describes version 2 of the protocol. Versions 0 and 1 were never specified in any Internet Draft, RFC, or any other public document. These prior versions of the protocol were, however, implemented in the DTN reference implementation versions 2.0.1 and 2.0.2.

The following set of definitions are abbreviated versions of those which appear in the Bundle Protocol Specification. To the extent in which terms appear in both documents, they are intended to have the same meaning. A bundle is a protocol data unit of the DTN bundle protocol. A bundle payload (or simply "payload") is the application data whose conveyance to the bundle's destination is the purpose for the transmission of a given bundle. A fragment is a bundle whose payload contains a range of bytes from another bundle's payload. A bundle node (or simply a "node") is any entity that can send and/or receive bundles. The particular instantiation of this entity is deliberately unconstrained, allowing for implementations in software libraries, long-running processes, or even hardware. One component of the bundle node is the implementation of a convergence layer adapter. A convergence layer adapter (CLA) sends and receives bundles utilizing the services of some 'native' internet protocol. This document describes the manner in which a CLA sends and receives bundles when using the TCP protocol for inter-node communication. A self describing numeric value (SDNV) is a variable length encoding for integer values, defined in the bundle protocol specification.

This section contains definitions that are interpreted to be specific to the operation of the TCPCL protocol, as described below. XXX need something?? A connection is a TCPCL communication session between two bundle nodes. The lifetime of a connection is one-to-one with the lifetime of an underlying TCP session. Therefore a TCPCL connection is initated when a bundle node initiates a TCP session to be initiated for the purposes of bundle communication. A connection is terminated when the TCP session ends, due either to one or both nodes actively terminating the connection or due to network errors causing a failure of the session. The connection parameters are a set of values used to affect the operation of the TCPCL for a given connection. The manner in which these parameters are conveyed to the bundle node and thereby to the TCPCL is implementation dependant. However, the mechanism by which two bundle nodes exchange and negotiate the values to be used for a given connection is described in Secion . The connection initiator is the bundle node that causes the establishment of a new connection by creating a new TCP session (for example, by using the connect() call in the BSD sockets API) and then following the procedures described in . The connection acceptor is the bundle node that establishes a connection in response to an active connection attempt by another bundle node (for example, by using the listen() and accept() calls of the BSD sockets API) and then following the procedures described in . Transmission refers to the procedures and mechanisms (described below) for conveyance of a bundle from the sender node to the receiver node. As bundle communication over a TCPCL connection is unidirectional, the sender node or simply "sender" is the bundle node that performs the transmission of bundles. Note that for a single connection, the connection initiator is not always the sender, nor is the connection acceptor always the receiver, as described in . Correspondingly, the receiver node is the recipient of bundle transmissions over a TCPCL connection.

For bundle transmissions to occur using the TCPCL, a connection must first be established between the sender and receiver nodes. The manner in which a bundle node makes the decision to establish such a connection is implementation dependant. For example, some connections may be opened proactively and maintained for as long as is possible given the network conditions, yet other connections may be opened only when there is a bundle that is ready for transmission over it. To establish a TCPCL connection, a node must first establish a TCP session with the intended peer node, typically by using the services provided by the operating system. If the node is unable to establish a connection for any reason, then it is an implementation manner to determine how to handle the failed connection. For example, a node may decide to re-attempt to establish the connection, perhaps after some delay or it may attempt to find an alternate route for bundle data. Once a TCP session is established, both the connection initiator and the connection acceptor should immediately transmit a contact header over the session. The format of the contact header is described in . Upon receipt of the contact header, both nodes perform the validation and negotiation procedures defined in

When a connection is established between a sender and receiver, both parties must transmit a Contact Header upon establishing a connection. This section describes the format of the contact header and the meaning of its fields.

The format for the Contact Header is as follows: 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 +---------------+---------------+---------------+---------------+ | magic='dtn!' | +---------------+---------------+---------------+---------------+ | version | flags | keepalive_interval | +---------------+---------------+---------------+---------------+ | partial_ack_length | +---------------+---------------+---------------+---------------+

The fields of the contact header are: A four byte field that always contains the byte sequence 0x64 0x76 0x6e 0x21, i.e. the ASCII string "dtn!". A one byte field value containing the current version of the protocol, i.e. 2. A one byte field containing optional connection flags. The first five bits are unused and must be set to zero. The last three bits are interpreted as follows: Value Meaning 001 Request acknowledgement of bundle reception. 010 Request enabling of reactive fragmentation. 100 The connection initiator shall be the receiver. A two byte integer field containing the number of seconds between exchanges of keepalive messages on the connection (see ). This value is in network byte order, as are all other multi-byte fields described in this protocol. A four byte integer field containing the length in bytes for which partial reception acknowledgements are requested (see ). The manner in which values are configured and chosen for the various flags and parameters in the contact header is implementation dependent.

Upon reception of the contact header from the other side, both the connection initiator and the connection acceptor follow the following procedures for ensuring the validity of the connection and to negotiate values for the connection parameters. If the magic string is not present and valid, the connection must be terminated. The intent of the magic string is to provide a some protection against an inadvertent connection to a node from a misconfigured application. To prevent a flood of repeated connections from a misconfigured application, a node may hold an invalid connection open for some time before closing it. If a node receives a contact header with a version that is greater than the version of the protocol that the node implements, then the node should interpret all received fields as it would normally with a peer using the same version of the protocol. If a node receives a contact header with a version that is smaller than the version of the protocol that the node implements, the node may either terminate the connection due to the version mismatch, or may adapt its usage to conform to the older version of the protocol. This decision is an implementation manner. A node calculates connection parameters by negotiating the values from its own preferences, as conveyed by the contact header it sent with the preferences of the peer node, as conveyed in the contact header that was received. This negotiation should proceed in the following manner: The bundle acknowledgements enabled parameter is set to true iff the corresponding flag is set in both contact headers. The reactive fragmentation enabled parameter is set to true iff the corresponding flag is set in both contact headers. The connection initiator is receiver flag may only ever be set by the connection initiator, if it intends to follow the procedures described in to be the receiver node instead of the sender node. For the connection acceptor, this flag must always be set to zero. The keealive_interval parameter should be set to the minimum value from both contact headers. If one or both contact headers contains the value zero, then the keepalive feature (described in ) is disabled. The partial_ack_length parameter should be set to the minimum value from both contact headers. If one or both contact headers contains the value zero, then the partial acknowledgement feature (described in ) is disabled. Once this process of parameter negotiation is completed, the protocol defines no additional mechanism to change the parameters of an established connection; to effect such a change, the connection must be terminated and a new connection established.

In typical operation of the TCPCL, the connection initiator is the sender node. However, there are certain circumstances in which a node can initiate a connection and then be the receiver node, i.e. the connection provides a mechanism of sending bundles back to the connection initiator. For example, if the network path between two bundle nodes traverses firewall or a a router that uses network address translation (NAT), then it may be difficult or impossible for a node on the public side of the NAT to initiate a TCP connection to a node on the private side of the NAT. Instead, using a receiver initated connection, the private-side node could initiate a connection to the public-side node and use that connection to receive bundles. To effect a receiver initiated connection, the connection initator first sets the "connection initiator is receiver" flag in the contact header. Additionally, immediately after transmitting the contact header, the connection initiator also transmits a four byte IPv4 address and a two byte port number (both in network byte order). The address and port number can be used by the connection acceptor to identify the connection initiator for the purposes of routing bundles to the new connection. This address and port will typically correspond to some IPv4 address on the private network on which the connection initiator is bound, and some port. The combination of the public IPv4 address (which can be obtained from the TCP socket), and the private IPv4 address/port conveyed in the address header can then identify the initator node. XXX rework this After this exchange, the operation of a receiver initiated connection is identical to that of a sender initated one, as described in the following sections.

This section describes the protocol operation for the duration of an established connection, including the mechanisms for transmitting bundles over the connection.

After the initial exchange of a contact header, all messages transmitted over the connection are denoted by a one byte message type code. The types and values for the message type code are as follows. Type Code Comment BUNDLE_DATA 0x01 Precedes the transmission of a Bundle Data Header, which itself precedes the transmission of a Bundle.   BUNDLE_ACK 0x02 Precedes the transmission of a Bundle Acknowledgement Header.   KEEPALIVE 0x03 Keepalive message for the connection, described in .   SHUTDOWN 0x04 Indicates that one of the nodes participating in the connection wishes to cleanly terminate the connection, described in .

The sender side transmits a bundle to the receiver side by first transmitting a BUNDLE_DATA message code, and then transmitting a Bundle Data Header.

The format for the Bundle Data Header with its preceding message type code is as follows. 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 +---------------+ | BUNDLE_DATA | +---------------+---------------+---------------+---------------+ | bundle_id | +---------------+---------------+---------------+---------------+ | bundle_length (vari.) ... +---------------+---------------+---------------+---------------+

The fields of the bundle data header are: A four byte field that contains an identifier for the bundle at the sender. The format and specification for this field is implementation specific. The total length of the bundle that immediately follows, expressed as an SDNV, and therefore is variable-length. Immediately following the Bundle Data Header is the transmission of a bundle, as described in .

Although the TCP transport provides reliable transfer of data between hosts, the typical BSD sockets interface provides no mechanism to a sending application to determine when the receiving host has delivered transmitted data to the receiving application. Furthermore, as described in the DTN architecture, some convergence layer adaptors may offer reliable bundle transmission service to the bundling layer. The reliable nature of the TCP transport therefore implies that a convergence layer should be able to offer reliable bundle transport. To this end, the TCPCL protocol offers an optional feature whereby the receiving node will transmit acknowledgements of bundle reception. This feature is enabled if during the exchange of contact headers, both the sender and receiver set the bundle_ack_enabled flag (see ). If so, then the receiver must transmit a bundle acknowledgement header when it successfully receives the entire bundle.

To transmit a bundle acknowledgement header, a node first transmits a BUNDLE_ACK message type code, then transmits a Bundle Acknowledgement Header, with the following format: 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 +---------------+ | BUNDLE_ACK | +---------------+---------------+---------------+---------------+ | bundle_id | +---------------+---------------+---------------+---------------+ | acked_length (vari.) | +---------------+---------------+---------------+---------------+

The fields of the bundle acknowledgement header are: A four byte field that contains the sender-specified identifier for the bundle that was received in the bundle data header. An SDNV that contains the total length (in bytes) of the data that has been successfully received and is being acknowledged.

The protocol also includes a provision for bundle acknowledgements to be transmitted during the course of receiving a bundle. The motivation behind this feature is to enable the bundle daemon to communicate state knowledge to enable "reactive fragmentation", as described in . As described in , one of the parameters negotiated in the contact header is the partial_ack_len. The sender populates this field with a requested length (in bytes), and the receiver populates the field with an offered length (in bytes). As described above, the two parties agree to a negotiated value that is is the minimum of the two lengths, and if either side sets the length to be zero, then the feature is disabled and no partial acknowledgements are transmitted. If the two parties agree to a non-zero value of the partial_ack_len parameter, then the receiver should transmit a bundle acknowledgement (see ) whenever it receives at least partial_ack_len additional bytes of the bundle payload since the last acknowledgement transmission (or the start of the bundle if no acknowledgements have been sent).

The protocol includes a provision for transmission of keepalive messages over the TCP connection to determine if the connection has been disrupted. As described in , one of the parameters in the contact header is the keepalive_interval. Both sides populate this field with their requested intervals (in seconds) between keepalive messages. The format of a keepalive message is a one byte message type code of KEEPALIVE (as described in , with no additional data. Both sides should send a keepalive message whenever the negotiated interval has elapsed without transmission of any message (keepalive or other). If no message (keepalive or other) has been received for at least twice the keepalive interval, then either party may terminate the session by transmitting a one byte message type code of SHUTDOWN (as described in ) and closing the TCP connection.

This section describes the procedures for ending a TCPCL connection.

To cleanly shut down a connection, a one byte message type code of SHUTDOWN may be transmitted at any time by either the sender or the receiver. When a node receives a SHUTDOWN message, it should send a SHUTDOWN message in return, then close the connection and clean up the TCP session.

The protocol includes a provision for clean shutdown of idle TCP connections. As described in , one of the parameters in the contact header is the idle_close_time. Both nodes populate this field with the requested duration (in seconds) to maintain an open connection after the last (non-keepalive) message is transmitted over the connection. The two parties should set the negotiated interval to the MAXIMUM value of the two requests. If either side sets the interval to zero, then that side should not close idle connections. The other party may adopt this same behavior or may choose to close idle connections at its own behest. If no bundle data other than keepalives has been received for at least twice the keepalive interval, then either party may terminate the session by transmitting a one byte message type code of SHUTDOWN (as described in ) and closing the TCP connection.

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 .

XXX something about DOS and peer identification

XXX something about a well-known port

XXX MCI/Jet Propulsion Laboratory The MITRE Corporation Jet Propulsion Laboratory University of California, Berkeley Intel Research Berkeley