idnits 2.17.1 draft-irtf-dtnrg-tcp-clayer-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 13, 2013) is 3879 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'L1' is mentioned on line 303, but not defined == Missing Reference: 'L2' is mentioned on line 303, but not defined == Missing Reference: 'L3' is mentioned on line 308, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 911, but not defined == Unused Reference: 'RFC6256' is defined on line 970, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Delay Tolerant Networking Research Group M. Demmer 3 Internet-Draft UC Berkeley 4 Intended status: Experimental J. Ott 5 Expires: March 17, 2014 Helsinki University of Technology 6 S. Perreault 7 Viagenie 8 September 13, 2013 10 Delay Tolerant Networking TCP Convergence Layer Protocol 11 draft-irtf-dtnrg-tcp-clayer-07.txt 13 Abstract 15 This document describes the protocol for the TCP-based Convergence 16 Layer for Delay Tolerant Networking (DTN). 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 17, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Definitions specific to the TCPCL Protocol . . . . . . . 4 55 3. General Protocol Description . . . . . . . . . . . . . . . . 5 56 3.1. Bidirectional Use of TCP Connection . . . . . . . . . . . 6 57 3.2. Example message exchange . . . . . . . . . . . . . . . . 6 58 4. Connection Establishment . . . . . . . . . . . . . . . . . . 7 59 4.1. Contact Header . . . . . . . . . . . . . . . . . . . . . 8 60 4.2. Validation and parameter negotiation . . . . . . . . . . 10 61 5. Established Connection Operation . . . . . . . . . . . . . . 11 62 5.1. Message Type Codes . . . . . . . . . . . . . . . . . . . 11 63 5.2. Bundle Data Transmission (DATA_SEGMENT) . . . . . . . . . 12 64 5.3. Bundle Acknowledgments (ACK_SEGMENT) . . . . . . . . . . 13 65 5.4. Bundle Refusal (REFUSE_BUNDLE) . . . . . . . . . . . . . 14 66 5.5. Bundle Length (LENGTH) . . . . . . . . . . . . . . . . . 15 67 5.6. Keepalive Messages (KEEPALIVE) . . . . . . . . . . . . . 16 68 6. Connection Termination . . . . . . . . . . . . . . . . . . . 17 69 6.1. Shutdown Message (SHUTDOWN) . . . . . . . . . . . . . . . 17 70 6.2. Idle Connection Shutdown . . . . . . . . . . . . . . . . 18 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 73 8.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 19 74 8.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 20 75 8.3. Message Types . . . . . . . . . . . . . . . . . . . . . . 20 76 8.4. REFUSE Reason Codes . . . . . . . . . . . . . . . . . . . 20 77 8.5. SHUTDOWN Reason Codes . . . . . . . . . . . . . . . . . . 20 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 81 10.2. Informative References . . . . . . . . . . . . . . . . . 21 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 84 1. Introduction 86 This document describes the TCP-based convergence layer protocol for 87 Delay Tolerant Networking (TCPCL). Delay Tolerant Networking is an 88 end-to-end architecture providing communications in and/or through 89 highly stressed environments, including those with intermittent 90 connectivity, long and/or variable delays, and high bit error rates. 91 More detailed descriptions of the rationale and capabilities of these 92 networks can be found in the Delay-Tolerant Network Architecture 93 [RFC4838] RFC. 95 An important goal of the DTN architecture is to accommodate a wide 96 range of networking technologies and environments. The protocol used 97 for DTN communications is the Bundling Protocol (BP) [RFC5050], an 98 application-layer protocol that is used to construct a store-and- 99 forward overlay network. As described in the Bundle Protocol 100 specification, it requires the services of a "convergence layer 101 adapter" (CLA) to send and receive bundles using the service of some 102 "native" link, network, or internet protocol. This document 103 describes one such convergence layer adapter that uses the well-known 104 Transmission Control Protocol (TCP). This convergence layer is 105 referred to as TCPCL. 107 The locations of the TCPCL and the BP in the Internet model protocol 108 stack are shown in Figure 1. In particular, when BP is using TCP as 109 its bearer with TCPCL as its convergence layer, both BP and TCPCL 110 reside at the application layer of the Internet model. 112 +-------------------------+ 113 | DTN Application | -\ 114 +-------------------------| | 115 | Bundle Protocol (BP) | -> Application Layer 116 +-------------------------+ | 117 | TCP Conv. Layer (TCPCL) | -/ 118 +-------------------------+ 119 | TCP | ---> Transport Layer 120 +-------------------------+ 121 | IP | ---> Network Layer 122 +-------------------------+ 123 | Link-Layer Protocol | ---> Link Layer 124 +-------------------------+ 125 | Physical Medium | ---> Physical Layer 126 +-------------------------+ 128 Figure 1: The locations of the Bundle Protocol and the TCP 129 convergence layer protocol in the Internet protocol stack 131 This document describes the format of the protocol data units passed 132 between entities participating in TCPCL communications. This 133 document does not address: 135 The format of protocol data units of the Bundle Protocol, as 136 those are defined elsewhere [RFC5050]. 138 Mechanisms for locating or identifying other bundle nodes within 139 an internet. 141 Note that this document describes version 3 of the protocol. 142 Versions 0, 1, and 2 were never specified in any Internet Draft, RFC, 143 or any other public document. These prior versions of the protocol 144 were, however, implemented in the DTN reference implementation 145 [refs.dtnimpl], in prior releases, hence the current version number 146 reflects the existence of those prior versions. 148 2. Definitions 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 The terms defined in Section 3.1 of [RFC5050] are used extensively in 155 this document. 157 2.1. Definitions specific to the TCPCL Protocol 159 This section contains definitions that are interpreted to be specific 160 to the operation of the TCPCL protocol, as described below. 162 TCP Connection -- A TCP connection refers to a transport connection 163 using TCP as the transport protocol. 165 TCPCL Connection -- A TCPCL connection (as opposed to a TCP 166 connection) is a TCPCL communication relationship between two 167 bundle nodes. The lifetime of a TCPCL connection is bound to 168 the lifetime of an underlying TCP connection. Therefore a TCPCL 169 connection is initiated when a bundle node initiates a TCP 170 connection to be established for the purposes of bundle 171 communication. A TCPCL connection is terminated when the TCP 172 connection ends, due either to one or both nodes actively 173 terminating the TCP connection or due to network errors causing 174 a failure of the TCP connection. For the remainder of this 175 document, the term "connection" without the prefix "TCPCL" shall 176 refer to a TCPCL connection. 178 Connection parameters -- The connection parameters are a set of 179 values used to affect the operation of the TCPCL for a given 180 connection. The manner in which these parameters are conveyed 181 to the bundle node and thereby to the TCPCL is implementation- 182 dependent. However, the mechanism by which two bundle nodes 183 exchange and negotiate the values to be used for a given session 184 is described in Section Section 4.2. 186 Transmission -- Transmission refers to the procedures and mechanisms 187 (described below) for conveyance of a bundle from one node to 188 another. 190 3. General Protocol Description 192 The service of this protocol is the transmission of DTN bundles over 193 TCP. This document specifies the encapsulation of bundles, 194 procedures for TCP setup and teardown, and a set of messages and node 195 requirements. The general operation of the protocol is as follows: 197 First one node establishes a TCPCL connection to the other by 198 initiating a TCP connection. After setup of the TCP connection is 199 complete, an initial contact header is exchanged in both directions 200 to set parameters of the TCPCL connection and exchange a singleton 201 endpoint identifier for each node (not the singleton EID of any 202 application running on the node), to denote the bundle-layer identity 203 of each DTN node. This is used to assist in routing and forwarding 204 messages, e.g., to prevent loops. 206 Once the TCPCL connection is established and configured in this way, 207 bundles can be transmitted in either direction. Each bundle is 208 transmitted in one or more logical segments of formatted bundle data. 209 Each logical data segment consists of a DATA_SEGMENT message header, 210 an SDNV containing the length of the segment, and finally the byte 211 range of the bundle data. The choice of the length to use for 212 segments is an implementation matter. The first segment for a bundle 213 must set the 'start' flag and the last one must set the 'end' flag in 214 the DATA_SEGMENT message header. 216 If multiple bundles are transmitted on a single TCPCL connection, 217 they MUST be transmitted consecutively. Interleaving data segments 218 from different bundles is not allowed. Bundle interleaving can be 219 accomplished by fragmentation at the BP layer. 221 An optional feature of the protocol is for the receiving node to send 222 acknowledgments as bundle data segments arrive (ACK_SEGMENT). The 223 rationale behind these acknowledgments is to enable the sender node 224 to determine how much of the bundle has been received, so that in 225 case the connection is interrupted, it can perform reactive 226 fragmentation to avoid re-sending the already transmitted part of the 227 bundle. 229 When acknowledgments are enabled, then for each data segment that is 230 received, the receiving node sends an ACK_SEGMENT code followed by an 231 SDNV containing the cumulative length of the bundle that has been 232 received. The sending node may transmit multiple DATA_SEGMENT 233 messages without necessarily waiting for the corresponding 234 ACK_SEGMENT responses. This enables pipelining of messages on a 235 channel. In addition, there is no explicit flow control on the TCPCL 236 layer. 238 Another optional feature is that a receiver may interrupt the 239 transmission of a bundle at any point in time by replying with a 240 REFUSE_BUNDLE message which causes the sender to stop transmission of 241 the current bundle, after completing transmission of a partially sent 242 data segment. Note: This enables a cross-layer optimization in that 243 it allows a receiver that detects that it already has received a 244 certain bundle to interrupt transmission as early as possible and 245 thus save transmission capacity for other bundles. 247 For connections that are idle, a KEEPALIVE message may optionally be 248 sent at a negotiated interval. This is used to convey liveness 249 information. 251 Finally, before connections close, a SHUTDOWN message is sent on the 252 channel. After sending a SHUTDOWN message, the sender of this 253 message may send further acknowledgments (ACK_SEGMENT or 254 REFUSE_BUNDLE) but no further data messages (DATA_SEGMENT). A 255 SHUTDOWN message may also be used to refuse a connection setup by a 256 peer. 258 3.1. Bidirectional Use of TCP Connection 260 There are different specific messages for sending and receiving 261 operations (in addition to connection setup/teardown). TCPCL is 262 symmetric, i.e., both sides can start sending data segments in a 263 connection, and one side's bundle transfer does not have to complete 264 before the other side can start sending data segments on its own. 265 Hence, the protocol allows for a bi-directional mode of 266 communication. 268 Note that in the case of concurrent bidirectional transmission, ack 269 segments may be interleaved with data segments. 271 3.2. Example message exchange 273 The following figure visually depicts the protocol exchange for a 274 simple session, showing the connection establishment, and the 275 transmission of a single bundle split into three data segments (of 276 lengths L1, L2, and L3) from Node A to Node B. 278 Note that the sending node may transmit multiple DATA_SEGMENT 279 messages without necessarily waiting for the corresponding 280 ACK_SEGMENT responses. This enables pipelining of messages on a 281 channel. Although this example only demonstrates a single bundle 282 transmission, it is also possible to pipeline multiple DATA_SEGMENT 283 messages for different bundles without necessarily waiting for 284 ACK_SEGMENT messages to be returned for each one. However, 285 interleaving data segments from different bundles is not allowed. 287 No errors or rejections are shown in this example. 289 Node A Node B 290 ====== ====== 292 +-------------------------+ +-------------------------+ 293 | Contact Header | -> <- | Contact Header | 294 +-------------------------+ +-------------------------+ 296 +-------------------------+ 297 | DATA_SEGMENT (start) | -> 298 | SDNV length [L1] | -> 299 | Bundle Data 0..L1 | -> 300 +-------------------------+ 301 +-------------------------+ +-------------------------+ 302 | DATA_SEGMENT | -> <- | ACK_SEGMENT | 303 | SDNV length [L2] | -> <- | SDNV length [L1] | 304 | Bundle Data L1..L2 | -> +-------------------------+ 305 +-------------------------+ 306 +-------------------------+ +-------------------------+ 307 | DATA_SEGMENT (end) | -> <- | ACK_SEGMENT | 308 | SDNV length [L3] | -> <- | SDNV length [L1+L2] | 309 | Bundle Data L2..L3 | -> +-------------------------+ 310 +-------------------------+ 311 +-------------------------+ 312 <- | ACK_SEGMENT | 313 <- | SDNV length [L1+L2+L3] | 314 +-------------------------+ 316 +-------------------------+ +-------------------------+ 317 | SHUTDOWN | -> <- | SHUTDOWN | 318 +-------------------------+ +-------------------------+ 320 Figure 2: A simple visual example of the flow of protocol messages on 321 a single TCP session between two nodes (A and B) 323 4. Connection Establishment 325 For bundle transmissions to occur using the TCPCL, a TCPCL connection 326 must first be established between communicating nodes. It is up to 327 the implementation to decide how and when connection setup is 328 triggered. For example, some connections may be opened proactively 329 and maintained for as long as is possible given the network 330 conditions, while other connections may be opened only when there is 331 a bundle that is queued for transmission and the routing algorithm 332 selects a certain next hop node. 334 To establish a TCPCL connection, a node must first establish a TCP 335 connection with the intended peer node, typically by using the 336 services provided by the operating system. Port number 4556 has been 337 assigned by IANA as the well-known port number for the TCP 338 convergence layer. Other port numbers MAY be used per local 339 configuration. Determining a peer's port number (if different from 340 the well-known TCPCL port) is up to the implementation. 342 If the node is unable to establish a TCP connection for any reason, 343 then it is an implementation matter to determine how to handle the 344 connection failure. A node MAY decide to re-attempt to establish the 345 connection, perhaps. If it does so, it MUST NOT overwhelm its target 346 with repeated connection attempts. Therefore, the node MUST retry 347 the connection setup only after some delay (a 1 second minimum is 348 RECOMMENDED) and it SHOULD use a (binary) exponential backoff 349 mechanism to increase this delay in case of repeated failures. In 350 case a SHUTDOWN message specifying a reconnection delay is received, 351 that delay is used as the initial delay. The default initial delay 352 SHOULD be at least 1 second but SHOULD be configurable since it will 353 be application and network type dependent. 355 The node MAY declare failure after one or more connection attempts 356 and MAY attempt to find an alternate route for bundle data. Such 357 decisions are up to the higher layer (i.e., the BP). 359 Once a TCP connection is established, each node MUST immediately 360 transmit a contact header over the TCP connection. The format of the 361 contact header is described in Section 4.1. 363 Upon receipt of the contact header, both nodes perform the validation 364 and negotiation procedures defined in Section 4.2 366 After receiving the contact header from the other node, either node 367 MAY also refuse the connection by sending a SHUTDOWN message. If 368 connection setup is refused a reason MUST be included in the SHUTDOWN 369 message. 371 4.1. Contact Header 373 Once a TCP connection is established, both parties exchange a contact 374 header. This section describes the format of the contact header and 375 the meaning of its fields. 377 The format for the Contact Header is as follows: 379 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 380 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 381 +---------------+---------------+---------------+---------------+ 382 | magic='dtn!' | 383 +---------------+---------------+---------------+---------------+ 384 | version | flags | keepalive_interval | 385 +---------------+---------------+---------------+---------------+ 386 | local EID length (SDNV) | 387 +---------------+---------------+---------------+---------------+ 388 | | 389 + local EID (variable) + 390 | | 391 +---------------+---------------+---------------+---------------+ 393 Figure 3: Contact Header Format 395 The fields of the contact header are: 397 magic: A four byte field that always contains the byte sequence 0x64 398 0x74 0x6e 0x21, i.e., the text string "dtn!" in US-ASCII. 400 version: A one byte field value containing the value 3 (current 401 version of the protocol). 403 flags: A one byte field containing optional connection flags. The 404 first four bits are unused and MUST be set to zero upon 405 transmission and MUST be ignored upon reception. The last four 406 bits are interpreted as shown in table Table 1 below. 408 keepalive_interval: A two byte integer field containing the number 409 of seconds between exchanges of keepalive messages on the 410 connection (see Section 5.6). This value is in network byte 411 order, as are all other multi-byte fields described in this 412 protocol. 414 local eid length: A variable length SDNV field containing the length 415 of the endpoint identifier (EID) for some singleton endpoint in 416 which the sending node is a member. A four byte SDNV is 417 depicted for clarity of the figure. 419 local EID: An octet string containing the EID of some singleton 420 endpoint in which the sending node is a member, in the canonical 421 format of :. A eight byte 422 EID is shown for clarity of the figure. 424 +-------------+-----------------------------------------------------+ 425 | Value | Meaning | 426 +-------------+-----------------------------------------------------+ 427 | 00000001 | Request acknowledgment of bundle segments. | 428 | 00000010 | Request enabling of reactive fragmentation. | 429 | 00000100 | Indicate support for bundle refusal. This flag MUST | 430 | | NOT be set to '1' unless support for | 431 | | acknowledgments is also indicated. | 432 | 00001000 | Request sending of LENGTH messages. | 433 +-------------+-----------------------------------------------------+ 435 Table 1: Contact Header Flags 437 The manner in which values are configured and chosen for the various 438 flags and parameters in the contact header is implementation 439 dependent. 441 4.2. Validation and parameter negotiation 443 Upon reception of the contact header, each node follows the following 444 procedures for ensuring the validity of the TCPCL connection and to 445 negotiate values for the connection parameters. 447 If the magic string is not present or is not valid, the connection 448 MUST be terminated. The intent of the magic string is to provide 449 some protection against an inadvertent TCP connection by a different 450 protocol than the one described in this document. To prevent a flood 451 of repeated connections from a misconfigured application, a node MAY 452 elect to hold an invalid connection open and idle for some time 453 before closing it. 455 If a node receives a contact header containing a version that is 456 greater than the current version of the protocol that the node 457 implements, then the node SHOULD interpret all fields and messages as 458 it would normally. If a node receives a contact header with a 459 version that is lower than the version of the protocol that the node 460 implements, the node may either terminate the connection due to the 461 version mismatch, or may adapt its operation to conform to the older 462 version of the protocol. This decision is an implementation matter. 464 A node calculates the parameters for a TCPCL connection by 465 negotiating the values from its own preferences (conveyed by the 466 contact header it sent) with the preferences of the peer node 467 (expressed in the contact header that it received). This negotiation 468 MUST proceed in the following manner: 470 The segment acknowledgments enabled parameter is set to true iff 471 the corresponding flag is set in both contact headers. 473 The reactive fragmentation enabled parameter is set to true iff 474 the corresponding flag is set in both contact headers. 476 The bundle refusal capability is set to true if the 477 corresponding flag is set in both contact headers and if segment 478 acknowledgment has been enabled. 480 The keepalive_interval parameter is set to the minimum value 481 from both contact headers. If one or both contact headers 482 contains the value zero, then the keepalive feature (described 483 in Section 5.6) is disabled. 485 Once this process of parameter negotiation is completed, the protocol 486 defines no additional mechanism to change the parameters of an 487 established connection; to effect such a change, the connection MUST 488 be terminated and a new connection established. 490 5. Established Connection Operation 492 This section describes the protocol operation for the duration of an 493 established connection, including the mechanisms for transmitting 494 bundles over the connection. 496 5.1. Message Type Codes 498 After the initial exchange of a contact header, all messages 499 transmitted over the connection are identified by a one octet header 500 with the following structure: 502 0 1 2 3 4 5 6 7 503 +-+-+-+-+-+-+-+-+ 504 | type | flags | 505 +-+-+-+-+-+-+-+-+ 507 type: Indicates the type of the message as per Table 2 below 509 flags: Optional flags defined on a per message type basis. 511 The types and values for the message type code are as follows. 513 +-----------------+-----------+-------------------------------------+ 514 | Type | Code | Comment | 515 +-----------------+-----------+-------------------------------------+ 516 | | 0x0 | Reserved. | 517 | | | | 518 | DATA_SEGMENT | 0x1 | Indicates the transmission of a | 519 | | | segment of bundle data, described | 520 | | | in Section 5.2. | 521 | | | | 522 | ACK_SEGMENT | 0x2 | Acknowledges reception of a data | 523 | | | segment, described in Section 5.3 | 524 | | | | 525 | REFUSE_BUNDLE | 0x3 | Indicates that the transmission of | 526 | | | the current bundle shall be | 527 | | | stopped, described in Section 5.4. | 528 | | | | 529 | KEEPALIVE | 0x4 | Keepalive message for the | 530 | | | connection, described in Section | 531 | | | 5.6. | 532 | | | | 533 | SHUTDOWN | 0x5 | Indicates that one of the nodes | 534 | | | participating in the connection | 535 | | | wishes to cleanly terminate the | 536 | | | connection, described in Section 6. | 537 | | | | 538 | LENGTH | 0x6 | Contains the length (in bytes) of | 539 | | | the next bundle, described in | 540 | | | Section 5.5. | 541 | | | | 542 | | 0x7-0xf | Unassigned. | 543 | | | | 544 +-----------------+-----------+-------------------------------------+ 546 Table 2: TCPCL Message Types 548 5.2. Bundle Data Transmission (DATA_SEGMENT) 550 Each bundle is transmitted in one or more data segments. The format 551 of a data segment message follows: 553 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 554 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 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | 0x1 |0|0|S|E| length ... | contents.... | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 Figure 4: Format of bundle data segment messages 561 The type portion of the message header contains the value 0x1. 563 The flags portion of the message header octet contains two optional 564 values in the two low-order bits, denoted 'S' and 'E' above. The 'S' 565 bit MUST be set to one iff it precedes the transmission of the first 566 segment of a new bundle. The 'E' bit MUST be set to one when 567 transmitting the last segment of a bundle. 569 Following the message header, the length field is an SDNV containing 570 the number of bytes of bundle data that are transmitted in this 571 segment. Following this length is the actual data contents. 573 Determining the size of the segment is an implementation matter. In 574 particular, a node may, based on local policy or configuration, only 575 ever transmit bundle data in a single segment, in which case both the 576 'S' and 'E' bits MUST be set to one. However, if a node is able to 577 receive, over TCP, a bundle of size X with segment size Y, then it 578 MUST also be able to do it with any segment size <= X. 580 In the Bundle Protocol specification, a single bundle comprises a 581 primary bundle block, a payload block, and zero or more additional 582 bundle blocks. The relationship between the protocol blocks and the 583 convergence layer segments is an implementation-specific decision. 584 In particular, a segment MAY contain more than one protocol block; 585 alternatively, a single protocol block (such as the payload) MAY be 586 split into multiple segments. 588 However, a single segment MUST NOT contain data of more than a single 589 bundle. 591 Once a transmission of a bundle has commenced, the node MUST only 592 send segments containing sequential portions of that bundle until it 593 sends a segment with the 'E' bit set. 595 5.3. Bundle Acknowledgments (ACK_SEGMENT) 597 Although the TCP transport provides reliable transfer of data between 598 transport peers, the typical BSD sockets interface provides no means 599 to inform a sending application of when the receiving application has 600 processed some amount of transmitted data. Thus after transmitting 601 some data, a Bundle Protocol agent needs an additional mechanism to 602 determine whether the receiving agent has successfully received the 603 segment. 605 To this end, the TCPCL protocol offers an optional feature whereby a 606 receiving node transmits acknowledgments of reception of data 607 segments. This feature is enabled if and only if during the exchange 608 of contact headers, both parties set the flag to indicate that 609 segment acknowledgments are enabled (see Section 4.1). If so, then 610 the receiver MUST transmit a bundle acknowledgment message when it 611 successfully receives each data segment. 613 The format of a bundle acknowledgment is as follows: 615 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | 0x2 |0|0|0|0| acknowledged length ... | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 Figure 5: Format of bundle acknowledgement messages 623 To transmit an acknowledgment, a node first transmits a message 624 header with the ACK_SEGMENT type code and all flags set to zero, then 625 transmits an SDNV containing the cumulative length in bytes of the 626 received segment(s) of the current bundle. The length MUST fall on a 627 segment boundary. That is, only full segments can be acknowledged. 629 For example, suppose the sending node transmits four segments of 630 bundle data with lengths 100, 200, 500, and 1000 respectively. After 631 receiving the first segment, the node sends an acknowledgment of 632 length 100. After the second segment is received, the node sends an 633 acknowledgment of length 300. The third and fourth acknowledgments 634 are of length 800 and 1800 respectively. 636 5.4. Bundle Refusal (REFUSE_BUNDLE) 638 As bundles may be large, the TCPCL supports an optional mechanisms by 639 which a receiving node may indicate to the sender that it does not 640 want to receive the corresponding bundle. 642 To do so, upon receiving a DATA_SEGMENT message, the node MAY 643 transmit a REFUSE_BUNDLE message. As data segments and 644 acknowledgments may cross on the wire, the bundle that is being 645 refused is implicitly identified by the sequence in which 646 acknowledgements and refusals are received. 648 The format of the REFUSE_BUNDLE message is as follows: 650 0 1 2 3 4 5 6 7 651 +-+-+-+-+-+-+-+-+ 652 | 0x3 | RCode | 653 +-+-+-+-+-+-+-+-+ 655 Figure 6: Format of REFUSE_BUNDLE message 657 The RCode field, which stands for "reason code", contains a value 658 indicating why the bundle was refused. The following table contains 659 semantics for some values. Other values may be registered with IANA, 660 as defined in Section 8. 662 +-----------+-------------------------------------------------------+ 663 | RCode | Semantics | 664 +-----------+-------------------------------------------------------+ 665 | 0x0 | Reason for refusal is unknown or not specified. | 666 | 0x1 | The receiver now has the complete bundle. The sender | 667 | | may now consider the bundle as completely received. | 668 | 0x2 | The receiver's resources are exhausted. The sender | 669 | | SHOULD apply reactive bundle fragmentation before | 670 | | retrying. | 671 | 0x3 | The receiver has encountered a problem that requires | 672 | | the bundle to be retransmitted in its entirety. | 673 | 0x4-0x7 | Unassigned. | 674 | 0x8-0xf | Reserved for future usage. | 675 +-----------+-------------------------------------------------------+ 677 Table 3: REFUSE_BUNDLE Reason Codes 679 The receiver MUST, for each bundle preceding the one to be refused, 680 have either acknowledged all DATA_SEGMENTs or refused the bundle. 681 This allows the sender to identify the bundles accepted and refused 682 by means of a simple FIFO list of segments and acknowledgments. 684 The bundle refusal MAY be sent before the entire data segment is 685 received. If a sender receives a REFUSE_BUNDLE message, the sender 686 MUST complete the transmission of any partially-sent DATA_SEGMENT 687 message (so that the receiver stays in sync). The sender MUST NOT 688 commence transmission of any further segments of the rejected bundle 689 subsequently. Note, however, that this requirement does not ensure 690 that a node will not receive another DATA_SEGMENT for the same bundle 691 after transmitting a REFUSE_BUNDLE message since messages may cross 692 on the wire; if this happens, subsequent segments of the bundle 693 SHOULD be refused with a REFUSE_BUNDLE message, too. 695 Note: If a bundle transmission if aborted in this way, the receiver 696 may not receive a segment with the 'E' flag set to '1' for the 697 aborted bundle. The beginning of the next bundle is identified by 698 the 'S' bit set to '1', indicating the start of a new bundle. 700 5.5. Bundle Length (LENGTH) 702 The LENGTH message contains the total length, in bytes, of the next 703 bundle, formatted as an SDNV. Its purpose is to allow nodes to 704 preemptively refuse bundles that would exceed their resources. It is 705 an optimization. 707 The format of the LENGTH message is as follows: 709 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 710 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 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | 0x6 |0|0|0|0| total bundle length ... | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 Figure 7: Format of LENGTH messages 717 LENGTH messages MUST NOT be sent unless the corresponding flag bit is 718 set in the contact header. If the flag bit is set, LENGTH messages 719 MAY be sent, at the sender's discretion. LENGTH messages MUST NOT be 720 sent unless the next DATA_SEGMENT message has the S bit set to 1 721 (i.e., just before the start of a new bundle). 723 A receiver MAY send a BUNDLE_REFUSE message as soon as it receives a 724 LENGTH message, without waiting for the next DATA_SEGMENT message. 725 The receiver MUST be prepared for this and MUST associate the refusal 726 with the right bundle. 728 5.6. Keepalive Messages (KEEPALIVE) 730 The protocol includes a provision for transmission of keepalive 731 messages over the TCP connection to help determine if the connection 732 has been disrupted. 734 As described in Section 4.1, one of the parameters in the contact 735 header is the keepalive_interval. Both sides populate this field 736 with their requested intervals (in seconds) between keepalive 737 messages. 739 The format of a keepalive message is a one byte message type code of 740 KEEPALIVE (as described in Table 2, with no additional data. Both 741 sides SHOULD send a keepalive message whenever the negotiated 742 interval has elapsed with no transmission of any message (keepalive 743 or other). 745 If no message (keepalive or other) has been received for at least 746 twice the keepalive interval, then either party MAY terminate the 747 session by transmitting a one byte SHUTDOWN message (as described in 748 Table 2) and by closing the TCP connection. 750 Note: The keepalive interval should not be chosen too short as TCP 751 retransmissions may occur in case of packet loss. Those will have to 752 be triggered by a timeout (TCP RTO) which is dependent on the 753 measured RTT for the TCP connection so that keepalive message may 754 experience noticeable latency. 756 6. Connection Termination 758 This section describes the procedures for ending a TCPCL connection. 760 6.1. Shutdown Message (SHUTDOWN) 762 To cleanly shut down a connection, a SHUTDOWN message MUST be 763 transmitted by either node at any point following complete 764 transmission of any other message. In case acknowledgments have been 765 negotiated, a node SHOULD acknowledge all received data segments 766 first and then shut down the connection. 768 The format of the shutdown message is as follows: 770 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 771 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 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | 0x5 |0|0|R|D| reason (opt) | reconnection delay (opt) | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 776 Figure 8: Format of bundle shutdown messages 778 It is possible for a node to convey additional information regarding 779 the reason for connection termination. To do so, the node MUST set 780 the 'R' bit in the message header flags, and transmit a one-byte 781 reason code immediately following the message header. The specified 782 values of the reason code are: 784 +---------------+---------------+-----------------------------------+ 785 | Code | Meaning | Comment | 786 +---------------+---------------+-----------------------------------+ 787 | 0x00 | Idle timeout | The connection is being closed | 788 | | | due to idleness. | 789 | | | | 790 | 0x01 | Version | The node cannot conform to the | 791 | | mismatch | specified TCPCL protocol version. | 792 | | | | 793 | 0x02 | Busy | The node is too busy to handle | 794 | | | the current connection. | 795 | 0x03-0xff | | Unassigned. | 796 +---------------+---------------+-----------------------------------+ 798 Table 4: Shutdown Reason Codes 800 It is also possible to convey a requested reconnection delay to 801 indicate how long the other node must wait before attempting 802 connection re-establishment. To do so, the node sets the 'D' bit in 803 the message header flags, then transmits an SDNV specifying the 804 requested delay, in seconds, following the message header (and 805 optionally the shutdown reason code). The value 0 SHALL be 806 interpreted as an infinite delay, i.e., that the connecting node MUST 807 NOT re-establish the connection. In contrast, if the node does not 808 wish to request a delay, it SHOULD omit the delay field (and set the 809 'D' bit to zero). Note that in the figure above, a two octet SDNV is 810 shown for convenience of the presentation. 812 A connection shutdown MAY occur immediately after TCP connection 813 establishment or reception of a contact header (and prior to any 814 further data exchange). This may, for example, be used to notify 815 that the node is currently not able or willing to communicate. 816 However, a node MUST always send the contact header to its peer 817 before sending a SHUTDOWN message. 819 If either node terminates a connection prematurely in this manner, it 820 SHOULD send a SHUTDOWN message and MUST indicate a reason code unless 821 the incoming connection did not include the magic string. If a node 822 does not want its peer to re-open the connection immediately, it 823 SHOULD set the 'D' bit in the flags and include a reconnection delay 824 to indicate when the peer is allowed to attempt another connection 825 setup. 827 If a connection is to be terminated before another protocol message 828 has completed, then the node MUST NOT transmit the SHUTDOWN message 829 but still SHOULD close the TCP connection. In particular, if the 830 connection is to be closed (for whatever reason) while a node is in 831 the process of transmitting a bundle data segment, receiving node is 832 still expecting segment data and might erroneously interpret the 833 SHUTDOWN message to be part of the data segment. 835 6.2. Idle Connection Shutdown 837 The protocol includes a provision for clean shutdown of idle TCP 838 connections. Determining the length of time to wait before closing 839 idle connections, if they are to be closed at all, is an 840 implementation and configuration matter. 842 If there is a configured time to close idle links, then if no bundle 843 data (other than keepalive messages) has been received for at least 844 that amount of time, then either node MAY terminate the connection by 845 transmitting a SHUTDOWN message indicating the reason code of 'idle 846 timeout' (as described above). After receiving a SHUTDOWN message in 847 response, both sides may close the TCP connection. 849 7. Security Considerations 850 One security consideration for this protocol relates to the fact that 851 nodes present their endpoint identifier as part of the connection 852 header exchange. It would be possible for a node to fake this value 853 and present the identity of a singleton endpoint in which the node is 854 not a member, essentially masquerading as another DTN node. If this 855 identifier is used without further verification as a means to 856 determine which bundles are transmitted over the connection, then the 857 node that has falsified its identity may be able to obtain bundles 858 that it should not have. Therefore, a node SHALL NOT use the 859 endpoint identifier conveyed in the TCPCL connection message to 860 derive a peer node's entity unless it can ascertain it via other 861 means. 863 These concerns may be mitigated through the use of the Bundle 864 Security Protocol [RFC6257]. In particular, the Bundle 865 Authentication Block defines mechanism for secure exchange of bundles 866 between DTN nodes. Thus an implementation could delay trusting the 867 presented endpoint identifier until the node can securely validate 868 that its peer is in fact the only member of the given singleton 869 endpoint. 871 In general, TCPCL does not provide any security services. The 872 mechanisms defined in [RFC6257] are to be used instead. 874 Nothing in TCPCL prevents the use of the Transport Layer Security 875 (TLS) protocol [RFC5246] to secure a connection. 877 Another consideration for this protocol relates to denial of service 878 attacks. A node may send a large amount of data over a TCP 879 connection, requiring the receiving node to either handle the data, 880 attempt to stop the flood of data by sending a REFUSE_BUNDLE message, 881 or forcibly terminate the connection. This burden could cause denial 882 of service on other, well-behaving connections. There is also 883 nothing to prevent a malicious node from continually establishing 884 connections and repeatedly trying to send copious amounts of bundle 885 data. A listening node MAY take counter-measures such as ignoring 886 TCP SYN messages, closing TCP connections as soon as they are 887 established, waiting before sending the contact header, sending a 888 SHUTDOWN message quickly or with a delay, etc. 890 8. IANA Considerations 892 In this section, registration procedures are as defined in [RFC5226]. 894 8.1. Port Number 896 Port number 4556 has been assigned as the default port for the TCP 897 convergence layer. 899 8.2. Protocol Versions 901 IANA is asked to create a registry titled "Bundle Protocol TCP 902 Convergence Layer Version Numbers" and initialize it with the 903 following: 905 +-------+-----------+ 906 | Value | Reference | 907 +-------+-----------+ 908 | 0 | [RFCXXXX] | 909 | 1 | [RFCXXXX] | 910 | 2 | [RFCXXXX] | 911 | 3 | [RFCXXXX] | 912 +-------+-----------+ 914 (NOTE TO THE EDITOR: in the above, replace XXXX with this RFC number) 916 The registration procedure shall be RFC Required. 918 8.3. Message Types 920 IANA is asked to create a registry titled "Bundle Protocol TCP 921 Convergence Layer Message Types" and initialize it with the contents 922 of Table 2. The registration procedure shall be RFC Required. 924 8.4. REFUSE Reason Codes 926 IANA is asked to create a registry titled "Bundle Protocol TCP 927 Convergence Layer REFUSE Reason Codes" and initialize it with the 928 contents of Table 3. The registration procedure shall be RFC 929 Required. 931 8.5. SHUTDOWN Reason Codes 933 IANA is asked to create a registry titled "Bundle Protocol TCP 934 Convergence Layer SHUTDOWN Reason Codes" and initialize it with the 935 contents of Table 4. The registration procedure shall be RFC 936 Required. 938 9. Acknowledgements 940 The authors would like to thank the following individuals who have 941 participated in the drafting, review, and discussion of this memo: 942 Alex McMahon, Brenton Walker, Darren Long, Dirk Kutscher, Elwyn 943 Davies, Jean-Philippe Dionne, Joseph Ishac, Keith Scott, Kevin Fall, 944 Lloyd Wood, Marc Blanchet, Peter Lovell, Scott Burleigh, Stephen 945 Farrell, Vint Cerf, and William Ivancic. 947 10. References 949 10.1. Normative References 951 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 952 Requirement Levels", RFC 2119, March 1997. 954 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 955 Specification", RFC 5050, November 2007. 957 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 958 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 959 May 2008. 961 10.2. Informative References 963 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 964 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 965 Networking Architecture", RFC 4838, April 2007. 967 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 968 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 970 [RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric 971 Values in Protocols", RFC 6256, May 2011. 973 [RFC6257] Symington, S., Farrell, S., Weiss, H., and P. Lovell, 974 "Bundle Security Protocol Specification", RFC 6257, May 975 2011. 977 [refs.dtnimpl] 978 DTNRG, ., "Delay Tolerant Networking Reference 979 Implementation", , . 981 Authors' Addresses 983 Michael J. Demmer 984 University of California, Berkeley 985 Computer Science Division 986 445 Soda Hall 987 Berkeley, CA 94720-1776 988 US 990 Email: demmer@cs.berkeley.edu 991 Joerg Ott 992 Helsinki University of Technology 993 Department of Communications and Networking 994 PO Box 3000 995 TKK 02015 996 Finland 998 Email: jo@netlab.tkk.fi 1000 Simon Perreault 1001 Viagenie 1002 246 Aberdeen 1003 Quebec, QC G1R 2E1 1004 Canada 1006 Phone: +1 418 656 9254 1007 Email: simon.perreault@viagenie.ca