idnits 2.17.1 draft-irtf-dtnrg-tcp-clayer-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 (August 9, 2012) is 4278 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'L1' is mentioned on line 316, but not defined == Missing Reference: 'L2' is mentioned on line 316, but not defined == Missing Reference: 'L3' is mentioned on line 321, but not defined Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Delay Tolerant Networking Research M. Demmer 3 Group UC Berkeley 4 Internet-Draft J. Ott 5 Intended status: Experimental Helsinki University of 6 Expires: February 10, 2013 Technology 7 S. Perreault 8 Viagenie 9 August 9, 2012 11 Delay Tolerant Networking TCP Convergence Layer Protocol 12 draft-irtf-dtnrg-tcp-clayer-03.txt 14 Abstract 16 This document describes the protocol for the TCP-based Convergence 17 Layer for Delay Tolerant Networking (DTN). 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 10, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1. Definitions Relating to the Bundle Protocol . . . . . . . 4 56 2.2. Definitions specific to the TCPCL Protocol . . . . . . . . 5 57 3. General Protocol Description . . . . . . . . . . . . . . . . . 6 58 3.1. Example message exchange . . . . . . . . . . . . . . . . . 7 59 4. Connection Establishment . . . . . . . . . . . . . . . . . . . 8 60 4.1. Contact Header . . . . . . . . . . . . . . . . . . . . . . 9 61 4.2. Validation and parameter negotiation . . . . . . . . . . . 11 62 5. Established Connection Operation . . . . . . . . . . . . . . . 12 63 5.1. Message Type Codes . . . . . . . . . . . . . . . . . . . . 12 64 5.2. Bundle Data Transmission . . . . . . . . . . . . . . . . . 13 65 5.3. Bundle Acknowledgments . . . . . . . . . . . . . . . . . . 14 66 5.4. Bundle Refusal . . . . . . . . . . . . . . . . . . . . . . 15 67 5.5. Bundle Length . . . . . . . . . . . . . . . . . . . . . . 16 68 5.6. Keepalive Messages . . . . . . . . . . . . . . . . . . . . 16 69 6. Connection Termination . . . . . . . . . . . . . . . . . . . . 17 70 6.1. Shutdown Message . . . . . . . . . . . . . . . . . . . . . 17 71 6.2. Idle Connection Shutdown . . . . . . . . . . . . . . . . . 19 72 7. Requirements notation . . . . . . . . . . . . . . . . . . . . 19 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 78 1. Introduction 80 This document describes the TCP-based convergence layer protocol for 81 Delay Tolerant Networking (TCPCL). Delay Tolerant Networking is an 82 end-to-end architecture providing communications in and/or through 83 highly stressed environments, including those with intermittent 84 connectivity, long and/or variable delays, and high bit error rates. 85 More detailed descriptions of the rationale and capabilities of these 86 networks can be found in the Delay-Tolerant Network Architecture 87 [refs.dtnarch] RFC. 89 An important goal of the DTN architecture is to accommodate a wide 90 range of networking technologies and environments. The protocol used 91 for DTN communications is the Bundling Protocol (BP) 92 [refs.bundleproto], an application-layer protocol that is used to 93 construct a store-and-forward overlay network. As described in the 94 bundle protocol specification, it requires the services of a 95 "convergence layer adapter" (CLA) to send and receive bundles using 96 an underlying internet protocol. This document describes one such 97 convergence layer adapter that uses the well-known Transmission 98 Control Protocol (TCP). This convergence layer is referred to as 99 TCPCL. 101 The locations of the TCPCL and the BP in the Internet model protocol 102 stack are shown in Figure 1. In particular, both the BP and the 103 TCPCL reside above the transport layer, i.e., at the application 104 layer. 106 +-------------------------+ 107 | DTN Application | -\ 108 +-------------------------| | 109 | Bundle Protocol (BP) | -> Application Layer 110 +-------------------------+ | 111 | TCP Conv. Layer (TCPCL) | -/ 112 +-------------------------+ 113 | TCP | ---> Transport Layer 114 +-------------------------+ 115 | IP | ---> Network Layer 116 +-------------------------+ 117 | Link-Layer Protocol | ---> Link Layer 118 +-------------------------+ 119 | Physical Medium | ---> Physical Layer 120 +-------------------------+ 122 Figure 1: The locations of the bundle protocol and the TCP 123 convergence layer protocol in the Internet protocol stack 125 This document describes the format of the protocol data units passed 126 between entities participating in TCPCL communications. This 127 document does not address: 129 The format of protocol data units of the bundling protocol, as 130 those are defined elsewhere [refs.bundleproto]. 132 Mechanisms for locating or identifying other bundle nodes within 133 an internet. 135 Note that this document describes version 3 of the protocol. 136 Versions 0, 1, and 2 were never specified in any Internet Draft, RFC, 137 or any other public document. These prior versions of the protocol 138 were, however, implemented in the DTN reference implementation 139 [refs.dtnimpl], in prior releases, hence the current version number 140 reflects the existence of those prior versions. 142 2. Definitions 144 2.1. Definitions Relating to the Bundle Protocol 146 The following set of definitions are abbreviated versions of those 147 which appear in the Bundle Protocol Specification [refs.bundleproto]. 148 To the extent in which terms appear in both documents, they are 149 intended to have the same meaning. 151 Bundle -- A bundle is a protocol data unit of the DTN bundle 152 protocol. 154 Bundle payload -- A bundle payload (or simply "payload") is the 155 application data whose conveyance to the bundle's destination is 156 the purpose for the transmission of a given bundle. 158 Fragment -- A fragment is a bundle whose payload contains a range of 159 bytes from another bundle's payload. 161 Bundle node -- A bundle node (or simply a "node") is any entity that 162 can send and/or receive bundles. The particular instantiation 163 of this entity is deliberately unconstrained, allowing for 164 implementations in software libraries, long-running processes, 165 or even hardware. One component of the bundle node is the 166 implementation of a convergence layer adapter. 168 Convergence layer adapter -- A convergence layer adapter (CLA) sends 169 and receives bundles utilizing the services of some 'native' 170 link, network, or internet protocol. This document describes 171 the manner in which a CLA sends and receives bundles when using 172 the TCP protocol for inter-node communication. 174 Self Describing Numeric Value -- A self describing numeric value 175 (SDNV) is a variable length encoding for integer values, defined 176 in the bundle protocol specification. 178 2.2. Definitions specific to the TCPCL Protocol 180 This section contains definitions that are interpreted to be specific 181 to the operation of the TCPCL protocol, as described below. 183 TCP Connection -- A TCP connection refers to a transport connection 184 using TCP as the transport protocol. 186 TCPCL Connection -- A TCPCL connection (as opposed to a TCP 187 connection) is a TCPCL communication relationship between two 188 bundle nodes. The lifetime of a TCPCL connection is one-to-one 189 with the lifetime of an underlying TCP connection. Therefore a 190 TCPCL connection is initiated when a bundle node initiates a TCP 191 connection to be established for the purposes of bundle 192 communication. A TCPCL connection is terminated when the TCP 193 connection ends, due either to one or both nodes actively 194 terminating the TCP connection or due to network errors causing 195 a failure of the TCP connection. For the remainder of this 196 document, the term "connection" without the prefix "TCPCL" shall 197 refer to a TCPCL connection. 199 Connection parameters -- The connection parameters are a set of 200 values used to affect the operation of the TCPCL for a given 201 connection. The manner in which these parameters are conveyed 202 to the bundle node and thereby to the TCPCL is implementation- 203 dependent. However, the mechanism by which two bundle nodes 204 exchange and negotiate the values to be used for a given session 205 is described in Section Section 4.2. 207 Connection initiator -- The connection initiator is the bundle node 208 that causes the establishment of a new connection by creating a 209 new TCP connection (for example, by using the connect() call in 210 the BSD sockets API) and then following the procedures described 211 in Section 4. 213 Connection acceptor -- The connection acceptor is the bundle node 214 that establishes a connection in response to an active 215 connection attempt by another bundle node (for example, by using 216 the listen() and accept() calls of the BSD sockets API) and then 217 following the procedures described in Section 4. 219 Transmission -- Transmission refers to the procedures and mechanisms 220 (described below) for conveyance of a bundle from one node to 221 another. 223 3. General Protocol Description 225 This protocol provides bundle conveyance over a TCP connection and 226 specifies the encapsulation of bundles as well as procedures for TCP 227 connection setup and teardown. The general operation of the protocol 228 is as follows: 230 First one node establishes a TCPCL connection to the other by 231 initiating a TCP connection. After setup of the TCP connection is 232 complete, an initial contact header is exchanged in both directions 233 to set parameters of the TCPCL connection and exchange a singleton 234 endpoint identifier for each node (not the singleton EID of any 235 application running on the node), to denote the bundle-layer identity 236 of each DTN node. This is used to assist in routing and forwarding 237 messages, e.g., to prevent loops. 239 Once the TCPCL connection is established and configured in this way, 240 bundles can be transmitted in either direction. Each bundle is 241 transmitted in one or more logical segments of formatted bundle data. 242 Each logical data segment consists of a DATA_SEGMENT message header, 243 an SDNV containing the length of the segment, and finally the byte 244 range of the bundle data. The choice of the length to use for 245 segments is an implementation matter. The first segment for a bundle 246 must set the 'start' flag and the last one must set the 'end' flag in 247 the DATA_SEGMENT message header. 249 An optional feature of the protocol is for the receiving node to send 250 acknowledgments as bundle data segments arrive (ACK_SEGMENT). The 251 rationale behind these acknowledgments is to enable the sender node 252 to determine how much of the bundle has been received, so that in 253 case the connection is interrupted, it can perform reactive 254 fragmentation to avoid re-sending the already transmitted part of the 255 bundle. 257 When acknowledgments are enabled, then for each data segment that is 258 received, the receiving node sends an ACK_SEGMENT code followed by an 259 SDNV containing the cumulative length of the bundle that has been 260 received. Note that in the case of concurrent bidirectional 261 transmission, then ack segments may be interleaved with data 262 segments. 264 Another optional feature is that a receiver may interrupt the 265 transmission of a bundle at any point in time by replying with a 266 REFUSE_BUNDLE message which causes the sender to stop transmission of 267 the current bundle, after completing transmission of a partially sent 268 data segment. Note: This enables a cross-layer optimization in that 269 it allows a receiver that detects that it already has received a 270 certain bundle to interrupt transmission as early as possible and 271 thus save transmission capacity for other bundles. 273 For connections that are idle, a KEEPALIVE message may optionally be 274 sent at a negotiated interval. This is used to convey liveness 275 information. 277 Finally, before connections close, a SHUTDOWN message is sent on the 278 channel. After sending a SHUTDOWN message, the sender of this 279 message may send further acknowledgments (ACK_SEGMENT or 280 REFUSE_BUNDLE) but no further data messages (DATA_SEGMENT). A 281 SHUTDOWN message may also be used to refuse a connection setup by a 282 peer. 284 3.1. Example message exchange 286 The following figure visually depicts the protocol exchange for a 287 simple session, showing the connection establishment, and the 288 transmission of a single bundle split into three data segments (of 289 lengths L1, L2, and L3) from Node A to Node B. 291 Note that the sending node may transmit multiple DATA_SEGMENT 292 messages without necessarily waiting for the corresponding 293 ACK_SEGMENT responses. This enables pipelining of messages on a 294 channel. Although this example only demonstrates a single bundle 295 transmission, it is also possible to pipeline multiple DATA_SEGMENT 296 messages for different bundles without necessarily waiting for 297 ACK_SEGMENT messages to be returned for each one. However, 298 interleaving data segments from different bundles is not allowed. 300 No errors or rejections are shown in this example. 302 Node A Node B 303 ====== ====== 305 +-------------------------+ +-------------------------+ 306 | Contact Header | -> <- | Contact Header | 307 +-------------------------+ +-------------------------+ 309 +-------------------------+ 310 | DATA_SEGMENT (start) | -> 311 | SDNV length [L1] | -> 312 | Bundle Data 0..L1 | -> 313 +-------------------------+ 314 +-------------------------+ +-------------------------+ 315 | DATA_SEGMENT | -> <- | ACK_SEGMENT | 316 | SDNV length [L2] | -> <- | SDNV length [L1] | 317 | Bundle Data L1..L2 | -> +-------------------------+ 318 +-------------------------+ 319 +-------------------------+ +-------------------------+ 320 | DATA_SEGMENT (end) | -> <- | ACK_SEGMENT | 321 | SDNV length [L3] | -> <- | SDNV length [L1+L2] | 322 | Bundle Data L2..L3 | -> +-------------------------+ 323 +-------------------------+ 324 +-------------------------+ 325 <- | ACK_SEGMENT | 326 <- | SDNV length [L1+L2+L3] | 327 +-------------------------+ 329 +-------------------------+ +-------------------------+ 330 | SHUTDOWN | -> <- | SHUTDOWN | 331 +-------------------------+ +-------------------------+ 333 Figure 2: A simple visual example of the flow of protocol messages on 334 a single TCP session between two nodes (A and B) 336 4. Connection Establishment 338 For bundle transmissions to occur using the TCPCL, a TCPCL connection 339 must first be established between communicating nodes. The manner in 340 which a bundle node makes the decision to establish such a connection 341 is implementation-dependent. For example, some connections may be 342 opened proactively and maintained for as long as is possible given 343 the network conditions, while other connections may be opened only 344 when there is a bundle that is queued for transmission and the 345 routing algorithm selects a certain next hop node. 347 To establish a TCPCL connection, a node must first establish a TCP 348 connection with the intended peer node, typically by using the 349 services provided by the operating system. Port number 4556 has been 350 assigned by IANA as the well-known port number for the TCP 351 convergence layer. Other port numbers MAY be used per local 352 configuration. Determining a peer's port number (if different from 353 the well-known TCPCL port) is up to the implementation. 355 If the node is unable to establish a TCP connection for any reason, 356 then it is an implementation matter to determine how to handle the 357 connection failure. A node MAY decide to re-attempt to establish the 358 connection, perhaps. If it does so, it MUST NOT overwhelm its target 359 with repeated connection attempts. Therefore, the node MUST retry 360 the connection setup only after some delay and it SHOULD use a 361 (binary) exponential backoff mechanism to increase this delay in case 362 of repeated failures. 364 The node MAY declare failure after one or more connection attempts 365 and MAY attempt to find an alternate route for bundle data. Such 366 decisions are up to the higher layer (i.e., the BP). 368 Once a TCP connection is established, the connection initiator MUST 369 immediately transmit a contact header over the TCP connection. The 370 connection acceptor MUST also immediately transmit a contact header 371 over the TCP connection. The format of the contact header is 372 described in Section 4.1). 374 Upon receipt of the contact header, both nodes perform the validation 375 and negotiation procedures defined in Section 4.2 377 After receiving the contact header from the other node, either node 378 MAY also refuse the connection by sending a SHUTDOWN message. If 379 connection setup is refused a reason MUST be included in the SHUTDOWN 380 message. 382 4.1. Contact Header 384 Once a TCP connection is established, both parties exchange a contact 385 header. This section describes the format of the contact header and 386 the meaning of its fields. 388 The format for the Contact Header is as follows: 390 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 391 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 392 +---------------+---------------+---------------+---------------+ 393 | magic='dtn!' | 394 +---------------+---------------+---------------+---------------+ 395 | version | flags | keepalive_interval | 396 +---------------+---------------+---------------+---------------+ 397 | local EID length (SDNV) | 398 +---------------+---------------+---------------+---------------+ 399 | | 400 + local EID (variable) + 401 | | 402 +---------------+---------------+---------------+---------------+ 404 Figure 3: Contact Header Format 406 The fields of the contact header are: 408 magic: A four byte field that always contains the byte sequence 0x64 409 0x74 0x6e 0x21, i.e. the text string "dtn!". 411 version: A one byte field value containing the current version of 412 the protocol. 414 flags: A one byte field containing optional connection flags. The 415 first four bits are unused and MUST be set to zero upon 416 transmission and MUST be ignored upon reception. The last four 417 bits are interpreted as shown in table Table 1 below. 419 keepalive_interval: A two byte integer field containing the number 420 of seconds between exchanges of keepalive messages on the 421 connection (see Section 5.6). This value is in network byte 422 order, as are all other multi-byte fields described in this 423 protocol. 425 local eid length: A variable length SDNV field containing the length 426 of the endpoint identifier (EID) for some singleton endpoint in 427 which the sending node is a member. A four byte SDNV is 428 depicted for clarity of the figure. 430 local EID: An octet string containing the EID of some singleton 431 endpoint in which the sending node is a member, in the canonical 432 format of :. A eight byte 433 EID is shown the clarity of the figure. 435 +----------+--------------------------------------------------------+ 436 | Value | Meaning | 437 +----------+--------------------------------------------------------+ 438 | 00000001 | Request acknowledgment of bundle segments. | 439 | 00000010 | Request enabling of reactive fragmentation. | 440 | 00000100 | Indicate support for bundle refusal. This flag MUST | 441 | | NOT be set to '1' unless support for acknowledgments | 442 | | is also indicated. | 443 | 00001000 | Request sending of LENGTH messages. | 444 +----------+--------------------------------------------------------+ 446 Table 1: Contact Header Flags 448 The manner in which values are configured and chosen for the various 449 flags and parameters in the contact header is implementation 450 dependent. 452 4.2. Validation and parameter negotiation 454 Upon reception of the contact header, both the TCPCL connection 455 initiator and the TCPCL connection acceptor follow the following 456 procedures for ensuring the validity of the TCPCL connection and to 457 negotiate values for the connection parameters. 459 If the magic string is not present or is not valid, the connection 460 MUST be terminated. The intent of the magic string is to provide a 461 some protection against an inadvertent TCP connection by a different 462 protocol than the one described in this document. To prevent a flood 463 of repeated connections from a misconfigured application, a node MAY 464 elect to hold an invalid connection open and idle for some time 465 before closing it. 467 If a node receives a contact header containing a version that is 468 greater than the current version of the protocol that the node 469 implements, then the node SHOULD interpret all fields and messages as 470 it would normally. If a node receives a contact header with a 471 version that is lower than the version of the protocol that the node 472 implements, the node may either terminate the connection due to the 473 version mismatch, or may adapt its operation to conform to the older 474 version of the protocol. This decision is an implementation matter. 476 A node calculates the parameters for a TCPCL connection by 477 negotiating the values from its own preferences (conveyed by the 478 contact header it sent) with the preferences of the peer node 479 (expressed in the contact header that it received). This negotiation 480 should proceed in the following manner: 482 The segment acknowledgments enabled parameter is set to true iff 483 the corresponding flag is set in both contact headers. 485 The reactive fragmentation enabled parameter is set to true iff 486 the corresponding flag is set in both contact headers. 488 Bundle refusal to interrupt transmission of a bundle may only be 489 used iff both peers indicate support for it in their contact 490 header. 492 The keepalive_interval parameter is set to the minimum value 493 from both contact headers. If one or both contact headers 494 contains the value zero, then the keepalive feature (described 495 in Section 5.6) is disabled. 497 Once this process of parameter negotiation is completed, the protocol 498 defines no additional mechanism to change the parameters of an 499 established connection; to effect such a change, the connection MUST 500 be terminated and a new connection established. 502 5. Established Connection Operation 504 This section describes the protocol operation for the duration of an 505 established connection, including the mechanisms for transmitting 506 bundles over the connection. 508 5.1. Message Type Codes 510 After the initial exchange of a contact header, all messages 511 transmitted over the connection are identified by a one octet header 512 with the following structure: 514 0 1 2 3 4 5 6 7 515 +-+-+-+-+-+-+-+-+ 516 | type | flags | 517 +-+-+-+-+-+-+-+-+ 519 type: Indicates the type of the message as per Table 2 below 521 flags: Optional flags defined on a per message type basis. 523 The types and values for the message type code are as follows. 525 +----------------+------+-------------------------------------------+ 526 | Type | Code | Comment | 527 +----------------+------+-------------------------------------------+ 528 | DATA_SEGMENT | 0x1 | Indicates the transmission of a segment | 529 | | | of bundle data, described in Section 5.2. | 530 | | | | 531 | ACK_SEGMENT | 0x2 | Acknowledges reception of a data segment, | 532 | | | described in Section 5.3 | 533 | | | | 534 | REFUSE_BUNDLE | 0x3 | Indicates that the transmission of the | 535 | | | current bundle shall be stopped, | 536 | | | described in Section 5.4. | 537 | | | | 538 | KEEPALIVE | 0x4 | Keepalive message for the connection, | 539 | | | described in Section 5.6. | 540 | | | | 541 | SHUTDOWN | 0x5 | Indicates that one of the nodes | 542 | | | participating in the connection wishes to | 543 | | | cleanly terminate the connection, | 544 | | | described in Section 6. | 545 | | | | 546 | LENGTH | 0x6 | Contains the length (in bytes) of the | 547 | | | next bundle, described in Section 5.5. | 548 | | | | 549 +----------------+------+-------------------------------------------+ 551 Table 2: TCPCL Header Types 553 5.2. Bundle Data Transmission 555 Each bundle is transmitted in one or more data segments. The format 556 of a data segment message follows: 558 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | 0x1 |0|0|S|E| length ... | contents.... | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 Figure 4: Format of bundle data segment messages 566 The type portion of the message header contains the value 0x1. 568 The flags portion of the message header octet contains two optional 569 values in the two low-order bits, denoted 'S' and 'E' above. The 'S' 570 bit MUST be set to one iff it precedes the transmission of the first 571 segment of a new bundle. The 'E' bit MUST be set to one when 572 transmitting the last segment of a bundle. 574 Determining the size of the segment is an implementation matter. In 575 particular, a node may, based on local policy or configuration, only 576 ever transmit bundle data in a single segment, in which case both the 577 'S' and 'E' bits MUST be set to one. However, a node MUST be able to 578 receive a bundle that has been transmitted in any segment size. 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 Following the message header, the length field is an SDNV containing 596 the number of bytes of bundle data that are transmitted in this 597 segment. Following this length is the actual data contents. 599 5.3. Bundle Acknowledgments 601 Although the TCP transport provides reliable transfer of data between 602 transport peers, the typical BSD sockets interface provides no means 603 to inform a sending application of when the receiving application has 604 processed some amount of transmitted data. Thus after transmitting 605 some data, a bundle protocol agent needs an additional mechanism to 606 determine whether the receiving agent has successfully received the 607 segment. 609 To this end, the TCPCL protocol offers an optional feature whereby a 610 receiving node transmits acknowledgments of reception of data 611 segments. This feature is enabled if and only if during the exchange 612 of contact headers, both parties set the flag to indicate that 613 segment acknowledgments are enabled (see Section 4.1). If so, then 614 the receiver MUST transmit a bundle acknowledgment header when it 615 successfully receives each data segment. 617 The format of a bundle acknowledgment is as follows: 619 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 620 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 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | 0x2 |0|0|0|0| acknowledged length ... | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 Figure 5: Format of bundle acknowledgement messages 627 To transmit an acknowledgment, a node first transmits a message 628 header with the ACK_SEGMENT type code and all flags set to zero, then 629 transmits an SDNV containing the cumulative length of the received 630 segment(s) of the current bundle. The length MUST fall on a segment 631 boundary. That is, only full segments can be acknowledged. 633 For example, suppose the sending node transmits four segments of 634 bundle data with lengths 100, 200, 500, and 1000 respectively. After 635 receiving the first segment, the node sends an acknowledgment of 636 length 100. After the second segment is received, the node sends an 637 acknowledgment of length 300. The third and fourth acknowledgments 638 are of length 800 and 1800 respectively. 640 5.4. Bundle Refusal 642 As bundles may be large, the TCPCL supports an optional mechanisms by 643 which a receiving node may indicate to the sender that it does not 644 want to receive the corresponding bundle. 646 To do so, upon receiving a DATA_SEGMENT message, the node MAY 647 transmit a REFUSE_BUNDLE message. As data segments and 648 acknowledgments may cross on the wire, the bundle that is being 649 refused is implicitly identified by the sequence in which 650 acknowledgements and refusals are received. 652 The receiver MUST, for each bundle preceding the one to be refused, 653 have either acknowledged all DATA_SEGMENTs or refused the bundle. 654 This allows the sender to identify the bundles accepted and refused 655 by means of a simple FIFO list of segments and acknowledgments. 657 The bundle refusal MAY be sent before the entire data segment is 658 received. If a sender receives a REFUSE_BUNDLE message, the sender 659 MUST complete the transmission of any partially-sent DATA_SEGMENT 660 message (so that the receiver stays in sync). The sender MUST NOT 661 commence transmission of any further segments of the rejected bundle 662 subsequently. Note, however, that this requirement does not ensure 663 that a node will not receive another DATA_SEGMENT for the same bundle 664 after transmitting a REFUSE_BUNDLE message since messages may cross 665 on the wire; if this happens, subsequent segments of the bundle 666 SHOULD be refused with a REFUSE_BUNDLE message, too. 668 Note: If a bundle transmission if aborted in this way, the receiver 669 may not receive a segment with the 'E' flag set to '1' for the 670 aborted bundle. The beginning of the next bundle is identified by 671 the 'S' bit set to '1', indicating the start of a new bundle. 673 5.5. Bundle Length 675 The format of the LENGTH message is as follows: 677 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 678 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 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | 0x6 |0|0|0|0| total bundle length ... | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 Figure 6: Format of LENGTH messages 685 The LENGTH message contains the total length, in bytes, of the next 686 bundle, formatted as an SDNV. Its purpose is to allow nodes to 687 preemptively refuse bundles that would exceed their resources. It is 688 an optimization. 690 LENGTH messages MUST NOT be sent unless the corresponding flag bit is 691 set in the contact header. If the flag bit is set, LENGTH messages 692 MAY be sent, at the sender's discretion. LENGTH messages MUST NOT be 693 sent unless the next DATA_SEGMENT message has the S bit set to 1 694 (i.e., just before the start of a new bundle). 696 A receiver MAY send a BUNDLE_REFUSE message as soon as it receives a 697 LENGTH message, without waiting for the next DATA_SEGMENT message. 698 The receiver MUST be prepared for this and MUST associate the refusal 699 with the right bundle. 701 5.6. Keepalive Messages 703 The protocol includes a provision for transmission of keepalive 704 messages over the TCP connection to help determine if the connection 705 has been disrupted. 707 As described in Section 4.1, one of the parameters in the contact 708 header is the keepalive_interval. Both sides populate this field 709 with their requested intervals (in seconds) between keepalive 710 messages. 712 The format of a keepalive message is a one byte message type code of 713 KEEPALIVE (as described in Table 2, with no additional data. Both 714 sides SHOULD send a keepalive message whenever the negotiated 715 interval has elapsed with no transmission of any message (keepalive 716 or other). 718 If no message (keepalive or other) has been received for at least 719 twice the keepalive interval, then either party may terminate the 720 session by transmitting a one byte message type code of SHUTDOWN (as 721 described in Table 2) and closing the TCP connection. 723 Note: The keepalive interval should not be chosen too short as TCP 724 retransmissions may occur in case of packet loss. Those will have to 725 be triggered by a timeout (TCP RTO) which is dependent on the 726 measured RTT for the TCP connection so that keepalive message may 727 experience noticeable latency. 729 6. Connection Termination 731 This section describes the procedures for ending a TCPCL connection. 733 6.1. Shutdown Message 735 To cleanly shut down a connection, a SHUTDOWN message MUST be 736 transmitted by either the initiator or the acceptor at any point 737 following complete transmission of any other message. In case 738 acknowledgments have been negotiated, it is advisable to acknowledge 739 all received data segments first and then shut down the connection. 741 The format of the shutdown message is as follows: 743 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 744 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 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | 0x5 |0|0|R|D| reason (opt) | reconnection delay (opt) | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 Figure 7: Format of bundle shutdown messages 751 It is possible for a node to convey additional information regarding 752 the reason for connection termination. To do so, the node MUST set 753 the 'R' bit in the message header flags, and transmit a one-byte 754 reason code immediately following the message header. The specified 755 values of the reason code are: 757 +------+-------------------+----------------------------------------+ 758 | Code | Meaning | Comment | 759 +------+-------------------+----------------------------------------+ 760 | 0x00 | Idle timeout | The connection is being closed due to | 761 | | | idleness. | 762 | | | | 763 | 0x01 | Version mismatch | The node cannot conform to the | 764 | | | specified TCPCL protocol version. | 765 | | | | 766 | 0x02 | Busy | The node is too busy to handle the | 767 | | | current connection. | 768 +------+-------------------+----------------------------------------+ 770 Table 3: Shutdown Reason Codes 772 It is also possible to convey a requested reconnection delay to 773 indicate how long the other node must wait before attempting 774 connection re-establishment. To do so, the node sets the 'D' bit in 775 the message header flags, then transmits an SDNV specifying the 776 requested delay, in seconds, following the message header (and 777 optionally the shutdown reason code). The value 0 SHALL be 778 interpreted as an infinite delay, i.e. that the connecting node MUST 779 NOT re-establish the connection. In contrast, if the node does not 780 wish to request a delay, it SHOULD omit the delay field (and set the 781 'D' bit to zero). Note that in the figure above, a two octet SDNV is 782 shown for convenience of the presentation. 784 A connection shutdown MAY occur immediately after TCP connection 785 establishment or reception of a contact header (and prior to any 786 further data exchange). This may, for example, be used to notify a 787 the initiator that the node is currently not capable of or willing to 788 communicate. However, a node MUST always send the contact header to 789 its peer first. 791 If either node terminates a connection prematurely in this manner, it 792 SHOULD send a SHUTDOWN message and MUST indicate a reason code unless 793 the incoming connection did not include the magic string. If a node 794 does not want its peer to re-open the connection immediately, it 795 SHOULD set the 'D' bit in the flags and include a reconnection delay 796 to indicate when the peer is allowed to attempt another connection 797 setup. 799 If a connection is to be terminated before another protocol message 800 has completed, then the node MUST NOT transmit the SHUTDOWN message 801 but still SHOULD close the TCP connection. In particular, if the 802 connection is to be closed (for whatever reason) while a node is in 803 the process of transmitting a bundle data segment, receiving node is 804 still expecting segment data and might erroneously interpret the 805 SHUTDOWN message to be part of the data segment. 807 6.2. Idle Connection Shutdown 809 The protocol includes a provision for clean shutdown of idle TCP 810 connections. Determining the length of time to wait before closing 811 idle connections, if they are to be closed at all, is an 812 implementation and configuration matter. 814 If there is a configured time to close idle links, then if no bundle 815 data (other than keepalive messages) has been received for at least 816 that amount of time, then either node MAY terminate the connection by 817 transmitting a SHUTDOWN message indicating the reason code of 'idle 818 timeout' (as described above). After receiving a SHUTDOWN message in 819 response, both sides may close the TCP connection. 821 7. Requirements notation 823 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 824 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 825 document are to be interpreted as described in [RFC2119]. 827 8. Security Considerations 829 One security consideration for this protocol relates to the fact that 830 nodes present their endpoint identifier as part of the connection 831 header exchange. It would be possible for a node to fake this value 832 and present the identity of a singleton endpoint in which the node is 833 not a member, essentially masquerading as another DTN node. If this 834 identifier is used without further verification as a means to 835 determine which bundles are transmitted over the connection, then the 836 node that has falsified its identity may be able to obtain bundles 837 that it should not have. 839 These concerns may be mitigated through the use of the Bundle 840 Security Protocols [refs.dtnsecurity]. In particular, the Bundle 841 Authentication Header defines mechanism for secure exchange of 842 bundles between DTN nodes. Thus an implementation could delay 843 trusting the presented endpoint identifier until the node can 844 securely validate that its peer is in fact the only member of the 845 given singleton endpoint. 847 Another consideration for this protocol relates to denial of service 848 attacks. A node may send a large amount of data over a TCP 849 connection, requiring the receiving node to either handle the data, 850 attempt to stop the flood of data by sending a REFUSE_BUNDLE message, 851 or forcibly terminate the connection. This burden could cause denial 852 of service on other, well-behaving connections. There is also 853 nothing to prevent a malicious node from continually establishing 854 connections and repeatedly trying to send copious amounts of bundle 855 data. 857 9. IANA Considerations 859 Port number 4556 has been assigned as the default port for the TCP 860 convergence layer. 862 10. References 864 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 865 Requirement Levels", RFC 2119, March 1997. 867 [refs.bundleproto] 868 Scott, K. and S. Burleigh, "Bundle Protocol 869 Specification", RFC 5050, November 2007. 871 [refs.dtnarch] 872 Cerf et al, V., "Delay-Tolerant Network Architecture", 873 RFC 4838, April 2007. 875 [refs.dtnimpl] 876 DTNRG, "Delay Tolerant Networking Reference 877 Implementation", . 879 [refs.dtnsecurity] 880 Symington, S., Farrell, S., and H. Weiss, "Bundle Security 881 Protocol Specification", Internet Draft, work in 882 progress draft-irtf-dtnrg-bundle-security-03.txt, 883 April 2007. 885 Authors' Addresses 887 Michael J. Demmer 888 University of California, Berkeley 889 Computer Science Division 890 445 Soda Hall 891 Berkeley, CA 94720-1776 892 US 894 Email: demmer@cs.berkeley.edu 895 Joerg Ott 896 Helsinki University of Technology 897 Department of Communications and Networking 898 PO Box 3000 899 TKK 02015 900 Finland 902 Email: jo@netlab.tkk.fi 904 Simon Perreault 905 Viagenie 906 246 Aberdeen 907 Quebec, QC G1R 2E1 908 Canada 910 Phone: +1 418 656 9254 911 Email: simon.perreault@viagenie.ca