diff options
Diffstat (limited to 'doc/rfc/rfc7242.txt')
| -rw-r--r-- | doc/rfc/rfc7242.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc7242.txt b/doc/rfc/rfc7242.txt new file mode 100644 index 0000000..b83ea7d --- /dev/null +++ b/doc/rfc/rfc7242.txt @@ -0,0 +1,1235 @@ + + + + + + +Internet Research Task Force (IRTF) M. Demmer +Request for Comments: 7242 UC Berkeley +Category: Experimental J. Ott +ISSN: 2070-1721 Aalto University + S. Perreault + + June 2014 + + + Delay-Tolerant Networking TCP Convergence-Layer Protocol + +Abstract + + This document describes the protocol for the TCP-based convergence + layer for Delay-Tolerant Networking (DTN). It is the product of the + IRTF's DTN Research Group (DTNRG). + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Research Task + Force (IRTF). The IRTF publishes the results of Internet-related + research and development activities. These results might not be + suitable for deployment. This RFC represents the consensus of the + Delay-Tolerant Networking Research Group of the Internet Research + Task Force (IRTF). Documents approved for publication by the IRSG + are not a candidate for any level of Internet Standard; see Section 2 + of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7242. + +Copyright Notice + + Copyright (c) 2014 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 + 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. + + + +Demmer, et al. Experimental [Page 1] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Definitions .....................................................4 + 2.1. Definitions Specific to the TCPCL Protocol .................4 + 3. General Protocol Description ....................................5 + 3.1. Bidirectional Use of TCP Connection ........................6 + 3.2. Example Message Exchange ...................................6 + 4. Connection Establishment ........................................7 + 4.1. Contact Header .............................................8 + 4.2. Validation and Parameter Negotiation ......................10 + 5. Established Connection Operation ...............................11 + 5.1. Message Type Codes ........................................11 + 5.2. Bundle Data Transmission (DATA_SEGMENT) ...................12 + 5.3. Bundle Acknowledgments (ACK_SEGMENT) ......................13 + 5.4. Bundle Refusal (REFUSE_BUNDLE) ............................14 + 5.5. Bundle Length (LENGTH) ....................................15 + 5.6. KEEPALIVE Feature (KEEPALIVE) .............................16 + 6. Connection Termination .........................................17 + 6.1. Shutdown Message (SHUTDOWN) ...............................17 + 6.2. Idle Connection Shutdown ..................................18 + 7. Security Considerations ........................................19 + 8. IANA Considerations ............................................20 + 8.1. Port Number ...............................................20 + 8.2. Protocol Versions .........................................20 + 8.3. Message Types .............................................20 + 8.4. REFUSE_BUNDLE Reason Codes ................................21 + 8.5. SHUTDOWN Reason Codes .....................................21 + 9. Acknowledgments ................................................21 + 10. References ....................................................21 + 10.1. Normative References .....................................21 + 10.2. Informative References ...................................21 + +1. Introduction + + This document describes the TCP-based convergence-layer protocol for + Delay-Tolerant Networking. 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 "Delay-Tolerant Network Architecture" + [RFC4838]. + + An important goal of the DTN architecture is to accommodate a wide + range of networking technologies and environments. The protocol used + for DTN communications is the Bundle Protocol (BP) [RFC5050], an + application-layer protocol that is used to construct a store-and- + + + +Demmer, et al. Experimental [Page 2] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + + forward overlay network. As described in the Bundle Protocol + specification [RFC5050], it requires the services of a "convergence- + layer adapter" (CLA) to send and receive bundles using the service of + some "native" link, network, or Internet protocol. This document + describes one such convergence-layer adapter that uses the well-known + Transmission Control Protocol (TCP). This convergence layer is + referred to as TCPCL. + + The locations of the TCPCL and the BP in the Internet model protocol + stack are shown in Figure 1. In particular, when BP is using TCP as + its bearer with TCPCL as its convergence layer, both BP and TCPCL + reside at the application layer of the Internet model. + + +-------------------------+ + | 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 + +-------------------------+ + + Figure 1: The Locations of the Bundle Protocol and the TCP + Convergence-Layer Protocol in the Internet Protocol Stack + + This document describes the format of the protocol data units passed + between entities participating in TCPCL communications. This + document does not address: + + o The format of protocol data units of the Bundle Protocol, as those + are defined elsewhere [RFC5050]. + + o Mechanisms for locating or identifying other bundle nodes within + an internet. + + Note that this document describes version 3 of the protocol. + Versions 0, 1, and 2 were never specified in an Internet-Draft, RFC, + or any other public document. These prior versions of the protocol + were, however, implemented in the DTN reference implementation + [DTNIMPL] in prior releases; hence, the current version number + reflects the existence of those prior versions. + + + +Demmer, et al. Experimental [Page 3] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + + This is an experimental protocol produced within the IRTF's Delay- + Tolerant Networking Research Group (DTNRG). It represents the + consensus of all active contributors to this group. If this protocol + is used on the Internet, IETF standard protocols for security and + congestion control should be used. + +2. Definitions + + 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 [RFC2119]. + + The terms defined in Section 3.1 of [RFC5050] are used extensively in + this document. + +2.1. Definitions Specific to the TCPCL Protocol + + This section contains definitions that are interpreted to be specific + to the operation of the TCPCL protocol, as described below. + + TCP Connection -- A TCP connection refers to a transport connection + using TCP as the transport protocol. + + TCPCL Connection -- A TCPCL connection (as opposed to a TCP + connection) is a TCPCL communication relationship between two + bundle nodes. The lifetime of a TCPCL connection is bound to + the lifetime of an underlying TCP connection. Therefore, a + TCPCL connection is initiated when a bundle node initiates a TCP + connection to be established for the purposes of bundle + communication. A TCPCL connection is terminated when the TCP + connection ends, due either to one or both nodes actively + terminating the TCP connection or due to network errors causing + a failure of the TCP connection. For the remainder of this + document, the term "connection" without the prefix "TCPCL" shall + refer to a TCPCL connection. + + Connection parameters -- 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 + dependent. However, the mechanism by which two bundle nodes + exchange and negotiate the values to be used for a given session + is described in Section 4.2. + + Transmission -- Transmission refers to the procedures and mechanisms + (described below) for conveyance of a bundle from one node to + another. + + + + +Demmer, et al. Experimental [Page 4] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + +3. General Protocol Description + + The service of this protocol is the transmission of DTN bundles over + TCP. This document specifies the encapsulation of bundles, + procedures for TCP setup and teardown, and a set of messages and node + requirements. The general operation of the protocol is as follows. + + First, one node establishes a TCPCL connection to the other by + initiating a TCP connection. After setup of the TCP connection is + complete, an initial contact header is exchanged in both directions + to set parameters of the TCPCL connection and exchange a singleton + endpoint identifier for each node (not the singleton Endpoint + Identifier (EID) of any application running on the node) to denote + the bundle-layer identity of each DTN node. This is used to assist + in routing and forwarding messages, e.g., to prevent loops. + + Once the TCPCL connection is established and configured in this way, + bundles can be transmitted in either direction. Each bundle is + transmitted in one or more logical segments of formatted bundle data. + Each logical data segment consists of a DATA_SEGMENT message header, + a Self-Delimiting Numeric Value (SDNV) as defined in [RFC5050] (see + also [RFC6256]) containing the length of the segment, and finally the + byte range of the bundle data. The choice of the length to use for + segments is an implementation matter. The first segment for a bundle + must set the 'start' flag, and the last one must set the 'end' flag + in the DATA_SEGMENT message header. + + If multiple bundles are transmitted on a single TCPCL connection, + they MUST be transmitted consecutively. Interleaving data segments + from different bundles is not allowed. Bundle interleaving can be + accomplished by fragmentation at the BP layer. + + An optional feature of the protocol is for the receiving node to send + acknowledgments as bundle data segments arrive (ACK_SEGMENT). The + rationale behind these acknowledgments is to enable the sender node + to determine how much of the bundle has been received, so that in + case the connection is interrupted, it can perform reactive + fragmentation to avoid re-sending the already transmitted part of the + bundle. + + When acknowledgments are enabled, then for each data segment that is + received, the receiving node sends an ACK_SEGMENT code followed by an + SDNV containing the cumulative length of the bundle that has been + received. The sending node may transmit multiple DATA_SEGMENT + messages without necessarily waiting for the corresponding + ACK_SEGMENT responses. This enables pipelining of messages on a + channel. In addition, there is no explicit flow control on the TCPCL + layer. + + + +Demmer, et al. Experimental [Page 5] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + + Another optional feature is that a receiver may interrupt the + transmission of a bundle at any point in time by replying with a + REFUSE_BUNDLE message, which causes the sender to stop transmission + of the current bundle, after completing transmission of a partially + sent data segment. Note: This enables a cross-layer optimization in + that it allows a receiver that detects that it already has received a + certain bundle to interrupt transmission as early as possible and + thus save transmission capacity for other bundles. + + For connections that are idle, a KEEPALIVE message may optionally be + sent at a negotiated interval. This is used to convey liveness + information. + + Finally, before connections close, a SHUTDOWN message is sent on the + channel. After sending a SHUTDOWN message, the sender of this + message may send further acknowledgments (ACK_SEGMENT or + REFUSE_BUNDLE) but no further data messages (DATA_SEGMENT). A + SHUTDOWN message may also be used to refuse a connection setup by a + peer. + +3.1. Bidirectional Use of TCP Connection + + There are specific messages for sending and receiving operations (in + addition to connection setup/teardown). TCPCL is symmetric, i.e., + both sides can start sending data segments in a connection, and one + side's bundle transfer does not have to complete before the other + side can start sending data segments on its own. Hence, the protocol + allows for a bi-directional mode of communication. + + Note that in the case of concurrent bidirectional transmission, + acknowledgment segments may be interleaved with data segments. + +3.2. Example Message Exchange + + The following figure visually depicts the protocol exchange for a + simple session, showing the connection establishment and the + transmission of a single bundle split into three data segments (of + lengths L1, L2, and L3) from Node A to Node B. + + Note that the sending node may transmit multiple DATA_SEGMENT + messages without necessarily waiting for the corresponding + ACK_SEGMENT responses. This enables pipelining of messages on a + channel. Although this example only demonstrates a single bundle + transmission, it is also possible to pipeline multiple DATA_SEGMENT + + + + + + + +Demmer, et al. Experimental [Page 6] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + + messages for different bundles without necessarily waiting for + ACK_SEGMENT messages to be returned for each one. However, + interleaving data segments from different bundles is not allowed. + + No errors or rejections are shown in this example. + + Node A Node B + ====== ====== + + +-------------------------+ +-------------------------+ + | Contact Header | -> <- | Contact Header | + +-------------------------+ +-------------------------+ + + +-------------------------+ + | DATA_SEGMENT (start) | -> + | SDNV length [L1] | -> + | Bundle Data 0..(L1-1) | -> + +-------------------------+ + +-------------------------+ +-------------------------+ + | DATA_SEGMENT | -> <- | ACK_SEGMENT | + | SDNV length [L2] | -> <- | SDNV length [L1] | + |Bundle Data L1..(L1+L2-1)| -> +-------------------------+ + +-------------------------+ + +-------------------------+ +-------------------------+ + | DATA_SEGMENT (end) | -> <- | ACK_SEGMENT | + | SDNV length [L3] | -> <- | SDNV length [L1+L2] | + |Bundle Data | -> +-------------------------+ + | (L1+L2)..(L1+L2+L3-1)| + +-------------------------+ + +-------------------------+ + <- | ACK_SEGMENT | + <- | SDNV length [L1+L2+L3] | + +-------------------------+ + + +-------------------------+ +-------------------------+ + | SHUTDOWN | -> <- | SHUTDOWN | + +-------------------------+ +-------------------------+ + + Figure 2: A Simple Visual Example of the Flow of Protocol Messages on + a Single TCP Session between Two Nodes (A and B) + +4. Connection Establishment + + For bundle transmissions to occur using the TCPCL, a TCPCL connection + must first be established between communicating nodes. It is up to + the implementation to decide how and when connection setup is + triggered. For example, some connections may be opened proactively + and maintained for as long as is possible given the network + + + +Demmer, et al. Experimental [Page 7] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + + conditions, while other connections may be opened only when there is + a bundle that is queued for transmission and the routing algorithm + selects a certain next-hop node. + + To establish a TCPCL connection, a node must first establish a TCP + connection with the intended peer node, typically by using the + services provided by the operating system. Port number 4556 has been + assigned by IANA as the well-known port number for the TCP + convergence layer. Other port numbers MAY be used per local + configuration. Determining a peer's port number (if different from + the well-known TCPCL port) is up to the implementation. + + If the node is unable to establish a TCP connection for any reason, + then it is an implementation matter to determine how to handle the + connection failure. A node MAY decide to re-attempt to establish the + connection. If it does so, it MUST NOT overwhelm its target with + repeated connection attempts. Therefore, the node MUST retry the + connection setup only after some delay (a 1-second minimum is + RECOMMENDED), and it SHOULD use a (binary) exponential backoff + mechanism to increase this delay in case of repeated failures. In + case a SHUTDOWN message specifying a reconnection delay is received, + that delay is used as the initial delay. The default initial delay + SHOULD be at least 1 second but SHOULD be configurable since it will + be application and network type dependent. + + The node MAY declare failure after one or more connection attempts + and MAY attempt to find an alternate route for bundle data. Such + decisions are up to the higher layer (i.e., the BP). + + Once a TCP connection is established, each node MUST immediately + transmit a contact header over the TCP connection. The format of the + contact header is described in Section 4.1. + + Upon receipt of the contact header, both nodes perform the validation + and negotiation procedures defined in Section 4.2 + + After receiving the contact header from the other node, either node + MAY also refuse the connection by sending a SHUTDOWN message. If + connection setup is refused, a reason MUST be included in the + SHUTDOWN message. + +4.1. Contact Header + + Once a TCP connection is established, both parties exchange a contact + header. This section describes the format of the contact header and + the meaning of its fields. + + + + + +Demmer, et al. Experimental [Page 8] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + + The format for the Contact Header is as follows: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 | + +---------------+---------------+---------------+---------------+ + | local EID length (SDNV) | + +---------------+---------------+---------------+---------------+ + | | + + local EID (variable) + + | | + +---------------+---------------+---------------+---------------+ + + Figure 3: Contact Header Format + + The fields of the contact header are: + + magic: A four-byte field that always contains the byte sequence 0x64 + 0x74 0x6e 0x21, i.e., the text string "dtn!" in US-ASCII. + + version: A one-byte field value containing the value 3 (current + version of the protocol). + + flags: A one-byte field containing optional connection flags. The + first four bits are unused and MUST be set to zero upon + transmission and MUST be ignored upon reception. The last four + bits are interpreted as shown in Table 1 below. + + keepalive_interval: A two-byte integer field containing the number + of seconds between exchanges of KEEPALIVE messages on the + connection (see Section 5.6). This value is in network byte + order, as are all other multi-byte fields described in this + protocol. + + local EID length: A variable-length SDNV field containing the length + of the endpoint identifier (EID) for some singleton endpoint in + which the sending node is a member. A four-byte SDNV is + depicted for clarity of the figure. + + local EID: A byte string containing the EID of some singleton + endpoint in which the sending node is a member, in the canonical + format of <scheme name>:<scheme-specific part>. An eight-byte + EID is shown for clarity of the figure. + + + + + +Demmer, et al. Experimental [Page 9] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + + +----------+--------------------------------------------------------+ + | Value | Meaning | + +----------+--------------------------------------------------------+ + | 00000001 | Request acknowledgment of bundle segments. | + | 00000010 | Request enabling of reactive fragmentation. | + | 00000100 | Indicate support for bundle refusal. This flag MUST | + | | NOT be set to '1' unless support for acknowledgments | + | | is also indicated. | + | 00001000 | Request sending of LENGTH messages. | + +----------+--------------------------------------------------------+ + + Table 1: Contact Header Flags + + The manner in which values are configured and chosen for the various + flags and parameters in the contact header is implementation + dependent. + +4.2. Validation and Parameter Negotiation + + Upon reception of the contact header, each node follows the following + procedures to ensure the validity of the TCPCL connection and to + negotiate values for the connection parameters. + + If the magic string is not present or is not valid, the connection + MUST be terminated. The intent of the magic string is to provide + some protection against an inadvertent TCP connection by a different + protocol than the one described in this document. To prevent a flood + of repeated connections from a misconfigured application, a node MAY + elect to hold an invalid connection open and idle for some time + before closing it. + + If a node receives a contact header containing a version that is + greater than the current version of the protocol that the node + implements, then the node SHOULD interpret all fields and messages as + it would normally. If a node receives a contact header with a + version that is lower 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 operation to conform to the older + version of the protocol. This decision is an implementation matter. + + A node calculates the parameters for a TCPCL connection by + negotiating the values from its own preferences (conveyed by the + contact header it sent) with the preferences of the peer node + (expressed in the contact header that it received). This negotiation + MUST proceed in the following manner: + + + + + + +Demmer, et al. Experimental [Page 10] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + + o The parameter for requesting acknowledgment of bundle segments is + set to true iff the corresponding flag is set in both contact + headers. + + o The parameter for enabling reactive fragmentation is set to true + iff the corresponding flag is set in both contact headers. + + o The bundle refusal capability is set to true if the corresponding + flag is set in both contact headers and if segment acknowledgment + has been enabled. + + o The keepalive_interval parameter is 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 Section 5.6) + is disabled. + + o The flag requesting sending of LENGTH messages is handled as + described in Section 5.5. + + 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. + +5. Established Connection Operation + + This section describes the protocol operation for the duration of an + established connection, including the mechanisms for transmitting + bundles over the connection. + +5.1. Message Type Codes + + After the initial exchange of a contact header, all messages + transmitted over the connection are identified by a one-byte header + with the following structure: + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | type | flags | + +-+-+-+-+-+-+-+-+ + + Figure 4: Format of the One-Byte Message Header + + type: Indicates the type of the message as per Table 2 below + + flags: Optional flags defined based on message type. + + The types and values for the message type code are as follows. + + + +Demmer, et al. Experimental [Page 11] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + + +----------------+---------+----------------------------------------+ + | Type | Code | Description | + +----------------+---------+----------------------------------------+ + | | 0x0 | Reserved. | + | | | | + | DATA_SEGMENT | 0x1 | Indicates the transmission of a | + | | | segment of bundle data, as described | + | | | in Section 5.2. | + | | | | + | ACK_SEGMENT | 0x2 | Acknowledges reception of a data | + | | | segment, as described in Section 5.3 | + | | | | + | REFUSE_BUNDLE | 0x3 | Indicates that the transmission of the | + | | | current bundle shall be stopped, as | + | | | described in Section 5.4. | + | | | | + | KEEPALIVE | 0x4 | KEEPALIVE message for the connection, | + | | | as described in Section 5.6. | + | | | | + | SHUTDOWN | 0x5 | Indicates that one of the nodes | + | | | participating in the connection wishes | + | | | to cleanly terminate the connection, | + | | | as described in Section 6. | + | | | | + | LENGTH | 0x6 | Contains the length (in bytes) of the | + | | | next bundle, as described in Section | + | | | 5.5. | + | | | | + | | 0x7-0xf | Unassigned. | + | | | | + +----------------+---------+----------------------------------------+ + + Table 2: TCPCL Message Types + +5.2. Bundle Data Transmission (DATA_SEGMENT) + + Each bundle is transmitted in one or more data segments. The format + of a DATA_SEGMENT message follows: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0x1 |0|0|S|E| length ... | contents.... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: Format of DATA_SEGMENT Messages + + The type portion of the message header contains the value 0x1. + + + +Demmer, et al. Experimental [Page 12] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + + The flags portion of the message header byte contains two optional + values in the two low-order bits, denoted 'S' and 'E' above. The 'S' + bit MUST be set to one if it precedes the transmission of the first + segment of a new bundle. The 'E' bit MUST be set to one when + transmitting the last segment of a bundle. + + Following the message header, the length field is an SDNV containing + the number of bytes of bundle data that are transmitted in this + segment. Following this length is the actual data contents. + + Determining the size of the segment is an implementation matter. In + particular, a node may, based on local policy or configuration, only + ever transmit bundle data in a single segment, in which case both the + 'S' and 'E' bits MUST be set to one. + + In the Bundle Protocol specification [RFC5050], a single bundle + comprises a primary bundle block, a payload block, and zero or more + additional bundle blocks. The relationship between the protocol + blocks and the convergence-layer segments is an implementation- + specific decision. In particular, a segment MAY contain more than + one protocol block; alternatively, a single protocol block (such as + the payload) MAY be split into multiple segments. + + However, a single segment MUST NOT contain data of more than a single + bundle. + + Once a transmission of a bundle has commenced, the node MUST only + send segments containing sequential portions of that bundle until it + sends a segment with the 'E' bit set. + +5.3. Bundle Acknowledgments (ACK_SEGMENT) + + Although the TCP transport provides reliable transfer of data between + transport peers, the typical BSD sockets interface provides no means + to inform a sending application of when the receiving application has + processed some amount of transmitted data. Thus, after transmitting + some data, a Bundle Protocol agent needs an additional mechanism to + determine whether the receiving agent has successfully received the + segment. + + To this end, the TCPCL protocol offers an optional feature whereby a + receiving node transmits acknowledgments of reception of data + segments. This feature is enabled if, and only if, during the + exchange of contact headers, both parties set the flag to indicate + that segment acknowledgments are enabled (see Section 4.1). If so, + then the receiver MUST transmit a bundle acknowledgment message when + it successfully receives each data segment. + + + + +Demmer, et al. Experimental [Page 13] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + + The format of a bundle acknowledgment is as follows: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0x2 |0|0|0|0| acknowledged length ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: Format of ACK_SEGMENT Messages + + To transmit an acknowledgment, a node first transmits a message + header with the ACK_SEGMENT type code and all flags set to zero, then + transmits an SDNV containing the cumulative length in bytes of the + received segment(s) of the current bundle. The length MUST fall on a + segment boundary. That is, only full segments can be acknowledged. + + For example, suppose the sending node transmits four segments of + bundle data with lengths 100, 200, 500, and 1000, respectively. + After receiving the first segment, the node sends an acknowledgment + of length 100. After the second segment is received, the node sends + an acknowledgment of length 300. The third and fourth + acknowledgments are of length 800 and 1800, respectively. + +5.4. Bundle Refusal (REFUSE_BUNDLE) + + As bundles may be large, the TCPCL supports an optional mechanisms by + which a receiving node may indicate to the sender that it does not + want to receive the corresponding bundle. + + To do so, upon receiving a DATA_SEGMENT message, the node MAY + transmit a REFUSE_BUNDLE message. As data segments and + acknowledgments may cross on the wire, the bundle that is being + refused is implicitly identified by the sequence in which + acknowledgements and refusals are received. + + The format of the REFUSE_BUNDLE message is as follows: + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + | 0x3 | RCode | + +-+-+-+-+-+-+-+-+ + + Figure 7: Format of REFUSE_BUNDLE Messages + + The RCode field, which stands for "reason code", contains a value + indicating why the bundle was refused. The following table contains + semantics for some values. Other values may be registered with IANA, + as defined in Section 8. + + + +Demmer, et al. Experimental [Page 14] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + + +---------+---------------------------------------------------------+ + | RCode | Semantics | + +---------+---------------------------------------------------------+ + | 0x0 | Reason for refusal is unknown or not specified. | + | 0x1 | The receiver now has the complete bundle. The sender | + | | may now consider the bundle as completely received. | + | 0x2 | The receiver's resources are exhausted. The sender | + | | SHOULD apply reactive bundle fragmentation before | + | | retrying. | + | 0x3 | The receiver has encountered a problem that requires | + | | the bundle to be retransmitted in its entirety. | + | 0x4-0x7 | Unassigned. | + | 0x8-0xf | Reserved for future usage. | + +---------+---------------------------------------------------------+ + + Table 3: REFUSE_BUNDLE Reason Codes + + The receiver MUST, for each bundle preceding the one to be refused, + have either acknowledged all DATA_SEGMENTs or refused the bundle. + This allows the sender to identify the bundles accepted and refused + by means of a simple FIFO list of segments and acknowledgments. + + The bundle refusal MAY be sent before the entire data segment is + received. If a sender receives a REFUSE_BUNDLE message, the sender + MUST complete the transmission of any partially sent DATA_SEGMENT + message (so that the receiver stays in sync). The sender MUST NOT + commence transmission of any further segments of the rejected bundle + subsequently. Note, however, that this requirement does not ensure + that a node will not receive another DATA_SEGMENT for the same bundle + after transmitting a REFUSE_BUNDLE message since messages may cross + on the wire; if this happens, subsequent segments of the bundle + SHOULD also be refused with a REFUSE_BUNDLE message. + + Note: If a bundle transmission is aborted in this way, the receiver + may not receive a segment with the 'E' flag set to '1' for the + aborted bundle. The beginning of the next bundle is identified by + the 'S' bit set to '1', indicating the start of a new bundle. + +5.5. Bundle Length (LENGTH) + + The LENGTH message contains the total length, in bytes, of the next + bundle, formatted as an SDNV. Its purpose is to allow nodes to + preemptively refuse bundles that would exceed their resources. It is + an optimization. + + + + + + + +Demmer, et al. Experimental [Page 15] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + + The format of the LENGTH message is as follows: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0x6 |0|0|0|0| total bundle length ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 8: Format of LENGTH Messages + + LENGTH messages MUST NOT be sent unless the corresponding flag bit is + set in the contact header. If the flag bit is set, LENGTH messages + MAY be sent at the sender's discretion. LENGTH messages MUST NOT be + sent unless the next DATA_SEGMENT message has the 'S' bit set to "1" + (i.e., just before the start of a new bundle). + + A receiver MAY send a BUNDLE_REFUSE message as soon as it receives a + LENGTH message without waiting for the next DATA_SEGMENT message. + The sender MUST be prepared for this and MUST associate the refusal + with the right bundle. + +5.6. KEEPALIVE Feature (KEEPALIVE) + + The protocol includes a provision for transmission of KEEPALIVE + messages over the TCP connection to help determine if the connection + has been disrupted. + + As described in Section 4.1, 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 Table 2) with no additional data. Both + sides SHOULD send a KEEPALIVE message whenever the negotiated + interval has elapsed with no 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 SHUTDOWN message (as described in + Table 2) and by closing the TCP connection. + + Note: The keepalive_interval should not be chosen too short as TCP + retransmissions may occur in case of packet loss. Those will have to + be triggered by a timeout (TCP retransmission timeout (RTO)), which + is dependent on the measured RTT for the TCP connection so that + KEEPALIVE messages may experience noticeable latency. + + + +Demmer, et al. Experimental [Page 16] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + +6. Connection Termination + + This section describes the procedures for ending a TCPCL connection. + +6.1. Shutdown Message (SHUTDOWN) + + To cleanly shut down a connection, a SHUTDOWN message MUST be + transmitted by either node at any point following complete + transmission of any other message. In case acknowledgments have been + negotiated, a node SHOULD acknowledge all received data segments + first and then shut down the connection. + + The format of the SHUTDOWN message is as follows: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 0x5 |0|0|R|D| reason (opt) | reconnection delay (opt) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 9: Format of Bundle SHUTDOWN Messages + + It is possible for a node to convey additional information regarding + the reason for connection termination. To do so, the node MUST set + the 'R' bit in the message header flags and transmit a one-byte + reason code immediately following the message header. The specified + values of the reason code are: + + +-----------+------------------+------------------------------------+ + | Code | Meaning | Description | + +-----------+------------------+------------------------------------+ + | 0x00 | Idle timeout | The connection is being closed due | + | | | to idleness. | + | | | | + | 0x01 | Version mismatch | The node cannot conform to the | + | | | specified TCPCL protocol version. | + | | | | + | 0x02 | Busy | The node is too busy to handle the | + | | | current connection. | + | | | | + | 0x03-0xff | | Unassigned. | + +-----------+------------------+------------------------------------+ + + Table 4: SHUTDOWN Reason Codes + + It is also possible to convey a requested reconnection delay to + indicate how long the other node must wait before attempting + connection re-establishment. To do so, the node sets the 'D' bit in + + + +Demmer, et al. Experimental [Page 17] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + + the message header flags and then transmits an SDNV specifying the + requested delay, in seconds, following the message header (and + optionally, the SHUTDOWN reason code). The value 0 SHALL be + interpreted as an infinite delay, i.e., that the connecting node MUST + NOT re-establish the connection. In contrast, if the node does not + wish to request a delay, it SHOULD omit the reconnection delay field + (and set the 'D' bit to zero). Note that in the figure above, the + reconnection delay SDNV is represented as a two-byte field for + convenience. + + A connection shutdown MAY occur immediately after TCP connection + establishment or reception of a contact header (and prior to any + further data exchange). This may, for example, be used to notify + that the node is currently not able or willing to communicate. + However, a node MUST always send the contact header to its peer + before sending a SHUTDOWN message. + + If either node terminates a connection prematurely in this manner, it + SHOULD send a SHUTDOWN message and MUST indicate a reason code unless + the incoming connection did not include the magic string. If a node + does not want its peer to reopen the connection immediately, it + SHOULD set the 'D' bit in the flags and include a reconnection delay + to indicate when the peer is allowed to attempt another connection + setup. + + If a connection is to be terminated before another protocol message + has completed, then the node MUST NOT transmit the SHUTDOWN message + but still SHOULD close the TCP connection. In particular, if the + connection is to be closed (for whatever reason) while a node is in + the process of transmitting a bundle data segment, the receiving node + is still expecting segment data and might erroneously interpret the + SHUTDOWN message to be part of the data segment. + +6.2. Idle Connection Shutdown + + The protocol includes a provision for clean shutdown of idle TCP + connections. Determining the length of time to wait before closing + idle connections, if they are to be closed at all, is an + implementation and configuration matter. + + If there is a configured time to close idle links and if no bundle + data (other than KEEPALIVE messages) has been received for at least + that amount of time, then either node MAY terminate the connection by + transmitting a SHUTDOWN message indicating the reason code of 'Idle + timeout' (as described in Table 4). After receiving a SHUTDOWN + message in response, both sides may close the TCP connection. + + + + + +Demmer, et al. Experimental [Page 18] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + +7. Security Considerations + + One security consideration for this protocol relates to the fact that + nodes present their endpoint identifier as part of the connection + header exchange. It would be possible for a node to fake this value + and present the identity of a singleton endpoint in which the node is + not a member, essentially masquerading as another DTN node. If this + identifier is used without further verification as a means to + determine which bundles are transmitted over the connection, then the + node that has falsified its identity may be able to obtain bundles + that it should not have. Therefore, a node SHALL NOT use the + endpoint identifier conveyed in the TCPCL connection message to + derive a peer node's identity unless it can ascertain it via other + means. + + These concerns may be mitigated through the use of the Bundle + Security Protocol [RFC6257]. In particular, the Bundle + Authentication Block defines mechanism for secure exchange of bundles + between DTN nodes. Thus, an implementation could delay trusting the + presented endpoint identifier until the node can securely validate + that its peer is in fact the only member of the given singleton + endpoint. + + In general, TCPCL does not provide any security services. The + mechanisms defined in [RFC6257] are to be used instead. + + Nothing in TCPCL prevents the use of the Transport Layer Security + (TLS) protocol [RFC5246] to secure a connection. + + Another consideration for this protocol relates to denial-of-service + attacks. A node may send a large amount of data over a TCP + connection, requiring the receiving node to handle the data, attempt + to stop the flood of data by sending a REFUSE_BUNDLE message, or + forcibly terminate the connection. This burden could cause denial of + service on other, well-behaving connections. There is also nothing + to prevent a malicious node from continually establishing connections + and repeatedly trying to send copious amounts of bundle data. A + listening node MAY take countermeasures such as ignoring TCP SYN + messages, closing TCP connections as soon as they are established, + waiting before sending the contact header, sending a SHUTDOWN message + quickly or with a delay, etc. + + + + + + + + + + +Demmer, et al. Experimental [Page 19] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + +8. IANA Considerations + + In this section, registration procedures are as defined in [RFC5226]. + +8.1. Port Number + + Port number 4556 has been assigned as the default port for the TCP + convergence layer. + + Service Name: dtn-bundle + + Transport Protocol(s): TCP + + Assignee: Simon Perreault <simon@per.reau.lt> + + Contact: Simon Perreault <simon@per.reau.lt> + + Description: DTN Bundle TCP CL Protocol + + Reference: [RFC7242] + + Port Number: 4556 + +8.2. Protocol Versions + + IANA has created, under the "Bundle Protocol" registry, a sub- + registry titled "Bundle Protocol TCP Convergence-Layer Version + Numbers" and initialized it with the following: + + +-------+-------------+-----------+ + | Value | Description | Reference | + +-------+-------------+-----------+ + | 0 | Reserved | [RFC7242] | + | 1 | Reserved | [RFC7242] | + | 2 | Reserved | [RFC7242] | + | 3 | TCPCL | [RFC7242] | + | 4-255 | Unassigned | [RFC7242] | + +-------+-------------+-----------+ + + The registration procedure is RFC Required. + +8.3. Message Types + + IANA has created, under the "Bundle Protocol" registry, a sub- + registry titled "Bundle Protocol TCP Convergence-Layer Message Types" + and initialized it with the contents of Table 2. The registration + procedure is RFC Required. + + + + +Demmer, et al. Experimental [Page 20] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + +8.4. REFUSE_BUNDLE Reason Codes + + IANA has created, under the "Bundle Protocol" registry, a sub- + registry titled "Bundle Protocol TCP Convergence-Layer REFUSE_BUNDLE + Reason Codes" and initialized it with the contents of Table 3. The + registration procedure is RFC Required. + +8.5. SHUTDOWN Reason Codes + + IANA has created, under the "Bundle Protocol" registry, a sub- + registry titled "Bundle Protocol TCP Convergence-Layer SHUTDOWN + Reason Codes" and initialized it with the contents of Table 4. The + registration procedure is RFC Required. + +9. Acknowledgments + + The authors would like to thank the following individuals who have + participated in the drafting, review, and discussion of this memo: + Alex McMahon, Brenton Walker, Darren Long, Dirk Kutscher, Elwyn + Davies, Jean-Philippe Dionne, Joseph Ishac, Keith Scott, Kevin Fall, + Lloyd Wood, Marc Blanchet, Peter Lovell, Scott Burleigh, Stephen + Farrell, Vint Cerf, and William Ivancic. + +10. References + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol + Specification", RFC 5050, November 2007. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + +10.2. Informative References + + [DTNIMPL] DTNRG, "Delay-Tolerant Networking Reference + Implementation", <https://sites.google.com/site/ + dtnresgroup/home/code>. + + [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, + R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant + Networking Architecture", RFC 4838, April 2007. + + + + + +Demmer, et al. Experimental [Page 21] + +RFC 7242 DTN TCP Convergence Layer June 2014 + + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric + Values in Protocols", RFC 6256, May 2011. + + [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, + "Bundle Security Protocol Specification", RFC 6257, May + 2011. + +Authors' Addresses + + Michael J. Demmer + University of California, Berkeley + Computer Science Division + 445 Soda Hall + Berkeley, CA 94720-1776 + US + + EMail: demmer@cs.berkeley.edu + + + Joerg Ott + Aalto University + Department of Communications and Networking + PO Box 13000 + AALTO 02015 + Finland + + EMail: jo@netlab.tkk.fi + + + Simon Perreault + Quebec, QC + Canada + + EMail: simon@per.reau.lt + + + + + + + + + + + + + + +Demmer, et al. Experimental [Page 22] + |