idnits 2.17.1 draft-irtf-dtnrg-tcp-clayer-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 878. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 889. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 896. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 902. 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 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 (November 3, 2008) is 5646 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'L1' is mentioned on line 307, but not defined == Missing Reference: 'L2' is mentioned on line 307, but not defined == Missing Reference: 'L3' is mentioned on line 312, but not defined Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 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 Technology 6 Expires: May 7, 2009 November 3, 2008 8 Delay Tolerant Networking TCP Convergence Layer Protocol 9 draft-irtf-dtnrg-tcp-clayer-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 7, 2009. 36 Abstract 38 This document describes the protocol for the TCP-based Convergence 39 Layer for Delay Tolerant Networking (DTN). 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 45 2.1. Definitions Relating to the Bundle Protocol . . . . . . . 4 46 2.2. Definitions specific to the TCPCL Protocol . . . . . . . . 5 47 3. General Protocol Description . . . . . . . . . . . . . . . . . 6 48 3.1. Example message exchange . . . . . . . . . . . . . . . . . 7 49 4. Connection Establishment . . . . . . . . . . . . . . . . . . . 8 50 4.1. Contact Header . . . . . . . . . . . . . . . . . . . . . . 9 51 4.2. Validation and parameter negotiation . . . . . . . . . . . 11 52 5. Established Connection Operation . . . . . . . . . . . . . . . 12 53 5.1. Message Type Codes . . . . . . . . . . . . . . . . . . . . 12 54 5.2. Bundle Data Transmission . . . . . . . . . . . . . . . . . 13 55 5.3. Bundle Acknowledgments . . . . . . . . . . . . . . . . . . 14 56 5.4. Bundle Refusal . . . . . . . . . . . . . . . . . . . . . . 15 57 5.5. Keepalive Messages . . . . . . . . . . . . . . . . . . . . 16 58 6. Connection Termination . . . . . . . . . . . . . . . . . . . . 16 59 6.1. Shutdown Message . . . . . . . . . . . . . . . . . . . . . 16 60 6.2. Idle Connection Shutdown . . . . . . . . . . . . . . . . . 18 61 7. Requirements notation . . . . . . . . . . . . . . . . . . . . 18 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 66 Intellectual Property and Copyright Statements . . . . . . . . . . 21 68 1. Introduction 70 This document describes the TCP-based convergence layer protocol for 71 Delay Tolerant Networking (TCPCL). Delay Tolerant Networking is an 72 end-to-end architecture providing communications in and/or through 73 highly stressed environments, including those with intermittent 74 connectivity, long and/or variable delays, and high bit error rates. 75 More detailed descriptions of the rationale and capabilities of these 76 networks can be found in the Delay-Tolerant Network Architecture 77 [refs.dtnarch] RFC. 79 An important goal of the DTN architecture is to accommodate a wide 80 range of networking technologies and environments. The protocol used 81 for DTN communications is the Bundling Protocol (BP) 82 [refs.bundleproto], an application-layer protocol that is used to 83 construct a store-and-forward overlay network. As described in the 84 bundle protocol specification, it requires the services of a 85 "convergence layer adapter" (CLA) to send and receive bundles using 86 an underlying internet protocol. This document describes one such 87 convergence layer adapter that uses the well-known Transmission 88 Control Protocol (TCP). This convergence layer is referred to as 89 TCPCL. 91 The locations of the TCPCL and the BP in the Internet model protocol 92 stack are shown in Figure 1. In particular, both the BP and the 93 TCPCL reside above the transport layer, i.e., at the application 94 layer. 96 +-------------------------+ 97 | DTN Application | -\ 98 +-------------------------| | 99 | Bundle Protocol (BP) | -> Application Layer 100 +-------------------------+ | 101 | TCP Conv. Layer (TCPCL) | -/ 102 +-------------------------+ 103 | TCP | ---> Transport Layer 104 +-------------------------+ 105 | IP | ---> Network Layer 106 +-------------------------+ 107 | Link-Layer Protocol | ---> Link Layer 108 +-------------------------+ 109 | Physical Medium | ---> Physical Layer 110 +-------------------------+ 112 Figure 1: The locations of the bundle protocol and the TCP 113 convergence layer protocol in the Internet protocol stack 115 This document describes the format of the protocol data units passed 116 between entities participating in TCPCL communications. This 117 document does not address: 119 The format of protocol data units of the bundling protocol, as 120 those are defined elsewhere [refs.bundleproto]. 122 Mechanisms for locating or identifying other bundle nodes within 123 an internet. 125 Note that this document describes version 3 of the protocol. 126 Versions 0, 1, and 2 were never specified in any Internet Draft, RFC, 127 or any other public document. These prior versions of the protocol 128 were, however, implemented in the DTN reference implementation 129 [refs.dtnimpl], in prior releases, hence the current version number 130 reflects the existence of those prior versions. 132 2. Definitions 134 2.1. Definitions Relating to the Bundle Protocol 136 The following set of definitions are abbreviated versions of those 137 which appear in the Bundle Protocol Specification [refs.bundleproto]. 138 To the extent in which terms appear in both documents, they are 139 intended to have the same meaning. 141 Bundle -- A bundle is a protocol data unit of the DTN bundle 142 protocol. 144 Bundle payload -- A bundle payload (or simply "payload") is the 145 application data whose conveyance to the bundle's destination is 146 the purpose for the transmission of a given bundle. 148 Fragment -- A fragment is a bundle whose payload contains a range of 149 bytes from another bundle's payload. 151 Bundle node -- A bundle node (or simply a "node") is any entity that 152 can send and/or receive bundles. The particular instantiation 153 of this entity is deliberately unconstrained, allowing for 154 implementations in software libraries, long-running processes, 155 or even hardware. One component of the bundle node is the 156 implementation of a convergence layer adapter. 158 Convergence layer adapter -- A convergence layer adapter (CLA) sends 159 and receives bundles utilizing the services of some 'native' 160 link, network, or internet protocol. This document describes 161 the manner in which a CLA sends and receives bundles when using 162 the TCP protocol for inter-node communication. 164 Self Describing Numeric Value -- A self describing numeric value 165 (SDNV) is a variable length encoding for integer values, defined 166 in the bundle protocol specification. 168 2.2. Definitions specific to the TCPCL Protocol 170 This section contains definitions that are interpreted to be specific 171 to the operation of the TCPCL protocol, as described below. 173 TCP Connection -- A TCP connection refers to a transport connection 174 using TCP as the transport protocol. 176 TCPCL Connection -- A TCPCL connection (as opposed to a TCP 177 connection) is a TCPCL communication relationship between two 178 bundle nodes. The lifetime of a TCPCL connection is one-to-one 179 with the lifetime of an underlying TCP connection. Therefore a 180 TCPCL connection is initiated when a bundle node initiates a TCP 181 connection to be established for the purposes of bundle 182 communication. A TCPCL connection is terminated when the TCP 183 connection ends, due either to one or both nodes actively 184 terminating the TCP connection or due to network errors causing 185 a failure of the TCP connection. For the remainder of this 186 document, the term "connection" without the prefix "TCPCL" shall 187 refer to a TCPCL connection. 189 Connection parameters -- The connection parameters are a set of 190 values used to affect the operation of the TCPCL for a given 191 connection. The manner in which these parameters are conveyed 192 to the bundle node and thereby to the TCPCL is implementation- 193 dependent. However, the mechanism by which two bundle nodes 194 exchange and negotiate the values to be used for a given session 195 is described in Section Section 4.2. 197 Connection initiator -- The connection initiator is the bundle node 198 that causes the establishment of a new connection by creating a 199 new TCP connection (for example, by using the connect() call in 200 the BSD sockets API) and then following the procedures described 201 in Section 4. 203 Connection acceptor -- The connection acceptor is the bundle node 204 that establishes a connection in response to an active 205 connection attempt by another bundle node (for example, by using 206 the listen() and accept() calls of the BSD sockets API) and then 207 following the procedures described in Section 4. 209 Transmission -- Transmission refers to the procedures and mechanisms 210 (described below) for conveyance of a bundle from one node to 211 another. 213 3. General Protocol Description 215 This protocol provides bundle conveyance over a TCP connection and 216 specifies the encapsulation of bundles as well as procedures for TCP 217 connection setup and teardown. The general operation of the protocol 218 is as follows: 220 First one node establishes a TCPCL connection to the other by 221 initiating a TCP connection. After setup of the TCP connection is 222 complete, an initial contact header is exchanged in both directions 223 to set parameters of the TCPCL connection and exchange a singleton 224 endpoint identifier for each node (not the singleton EID of any 225 application running on the node), to denote the bundle-layer identity 226 of each DTN node. This is used to assist in routing and forwarding 227 messages, e.g., to prevent loops. 229 Once the TCPCL connection is established and configured in this way, 230 bundles can be transmitted in either direction. Each bundle is 231 transmitted in one or more logical segments of formatted bundle data. 232 Each logical data segment consists of a DATA_SEGMENT message header, 233 an SDNV containing the length of the segment, and finally the byte 234 range of the bundle data. The choice of the length to use for 235 segments is an implementation matter. The first segment for a bundle 236 must set the 'start' flag and the last one must set the 'end' flag in 237 the DATA_SEGMENT message header. 239 An optional feature of the protocol is for the receiving node to send 240 acknowledgments as bundle data segments arrive (ACK_SEGMENT). The 241 rationale behind these acknowledgments is to enable the sender node 242 to determine how much of the bundle has been received, so that in 243 case the connection is interrupted, it can perform reactive 244 fragmentation to avoid re-sending the already transmitted part of the 245 bundle. 247 When acknowledgments are enabled, then for each data segment that is 248 received, the receiving node sends an ACK_SEGMENT code followed by an 249 SDNV containing the cumulative length of the bundle that has been 250 received. Note that in the case of concurrent bidirectional 251 transmission, then ack segments may be interleaved with data 252 segments. 254 Another optional feature is that a receiver may interrupt the 255 transmission of a bundle at any point in time by replying with a 256 negative acknowledgment (REFUSE_BUNDLE) which causes the sender to 257 stop transmission of the current bundle, after completing 258 transmission of a partially sent data segment. Note: This enables a 259 cross-layer optimization in that it allows a receiver that detects 260 that it already has received a certain bundle to interrupt 261 transmission as early as possible and thus save transmission capacity 262 for other bundles. 264 For connections that are idle, a KEEPALIVE message may optionally be 265 sent at a negotiated interval. This is used to convey liveness 266 information. 268 Finally, before connections close, a SHUTDOWN message is sent on the 269 channel. After sending a SHUTDOWN message, the sender of this 270 message may send further acknowledgments (ACK_SEGMENT or 271 REFUSE_BUNDLE) but no further data messages (DATA_SEGMENT). A 272 SHUTDOWN message may also be used to refuse a connection setup by a 273 peer. 275 3.1. Example message exchange 277 The following figure visually depicts the protocol exchange for a 278 simple session, showing the connection establishment, and the 279 transmission of a single bundle split into three data segments (of 280 lengths L1, L2, and L3) from Node A to Node B. 282 Note that the sending node may transmit multiple DATA_SEGMENT 283 messages without necessarily waiting for the corresponding 284 ACK_SEGMENT responses. This enables pipelining of messages on a 285 channel. Although this example only demonstrates a single bundle 286 transmission, it is also possible to pipeline multiple DATA_SEGMENT 287 messages for different bundles without necessarily waiting for 288 ACK_SEGMENT messages to be returned for each one. However, 289 interleaving data segments from different bundles is not allowed. 291 No errors or rejections are shown in this example. 293 Node A Node B 294 ====== ====== 296 +-------------------------+ +-------------------------+ 297 | Contact Header | -> <- | Contact Header | 298 +-------------------------+ +-------------------------+ 300 +-------------------------+ 301 | DATA_SEGMENT (start) | -> 302 | SDNV length [L1] | -> 303 | Bundle Data 0..L1 | -> 304 +-------------------------+ 305 +-------------------------+ +-------------------------+ 306 | DATA_SEGMENT | -> <- | ACK_SEGMENT | 307 | SDNV length [L2] | -> <- | SDNV length [L1] | 308 | Bundle Data L1..L2 | -> +-------------------------+ 309 +-------------------------+ 310 +-------------------------+ +-------------------------+ 311 | DATA_SEGMENT (end) | -> <- | ACK_SEGMENT | 312 | SDNV length [L3] | -> <- | SDNV length [L1+L2] | 313 | Bundle Data L2..L3 | -> +-------------------------+ 314 +-------------------------+ 315 +-------------------------+ 316 <- | ACK_SEGMENT | 317 <- | SDNV length [L1+L2+L3] | 318 +-------------------------+ 320 +-------------------------+ +-------------------------+ 321 | SHUTDOWN | -> <- | SHUTDOWN | 322 +-------------------------+ +-------------------------+ 324 Figure 2: A simple visual example of the flow of protocol messages on 325 a single TCP session between two nodes (A and B) 327 4. Connection Establishment 329 For bundle transmissions to occur using the TCPCL, a TCPCL connection 330 must first be established between communicating nodes. The manner in 331 which a bundle node makes the decision to establish such a connection 332 is implementation-dependent. For example, some connections may be 333 opened proactively and maintained for as long as is possible given 334 the network conditions, while other connections may be opened only 335 when there is a bundle that is queued for transmission and the 336 routing algorithm selects a certain next hop node. 338 To establish a TCPCL connection, a node must first establish a TCP 339 connection with the intended peer node, typically by using the 340 services provided by the operating system. Port number 4556 has been 341 assigned by IANA as the well-known port number for the TCP 342 convergence layer. Other port numbers MAY be used per local 343 configuration. Determining a peer's port number (if different from 344 the well-known TCPCL port) is up to the implementation. 346 If the node is unable to establish a TCP connection for any reason, 347 then it is an implementation matter to determine how to handle the 348 connection failure. A node MAY decide to re-attempt to establish the 349 connection, perhaps. If it does so, it MUST NOT overwhelm its target 350 with repeated connection attempts. Therefore, the node MUST retry 351 the connection setup only after some delay and it SHOULD use a 352 (binary) exponential backoff mechanism to increase this delay in case 353 of repeated failures. 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, the connection initiator MUST 360 immediately transmit a contact header over the TCP connection. The 361 connection acceptor MUST also immediately transmit a contact header 362 over the TCP connection. The format of the contact header is 363 described in Section 4.1). 365 Upon receipt of the contact header, both nodes perform the validation 366 and negotiation procedures defined in Section 4.2 368 After receiving the contact header from the other node, either node 369 MAY also refuse the connection by sending a SHUTDOWN message. If 370 connection setup is refused a reason MUST be included in the SHUTDOWN 371 message. 373 4.1. Contact Header 375 Once a TCP connection is established, both parties exchange a contact 376 header. This section describes the format of the contact header and 377 the meaning of its fields. 379 The format for the Contact Header is as follows: 381 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 382 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 383 +---------------+---------------+---------------+---------------+ 384 | magic='dtn!' | 385 +---------------+---------------+---------------+---------------+ 386 | version | flags | keepalive_interval | 387 +---------------+---------------+---------------+---------------+ 388 | local EID length (SDNV) | 389 +---------------+---------------+---------------+---------------+ 390 | | 391 + local EID (variable) + 392 | | 393 +---------------+---------------+---------------+---------------+ 395 Figure 3: Contact Header Format 397 The fields of the contact header are: 399 magic: A four byte field that always contains the byte sequence 0x64 400 0x74 0x6e 0x21, i.e. the text string "dtn!". 402 version: A one byte field value containing the current version of 403 the protocol. 405 flags: A one byte field containing optional connection flags. The 406 first five bits are unused and MUST be set to zero upon 407 transmission and MUST be ignored upon reception. The last three 408 bits are interpreted as shown in table Table 1 below. 410 keepalive_interval: A two byte integer field containing the number 411 of seconds between exchanges of keepalive messages on the 412 connection (see Section 5.5). This value is in network byte 413 order, as are all other multi-byte fields described in this 414 protocol. 416 local eid length: A variable length SDNV field containing the length 417 of the endpoint identifier (EID) for some singleton endpoint in 418 which the sending node is a member. A four byte SDNV is 419 depicted for clarity of the figure. 421 local EID: An octet string containing the EID of some singleton 422 endpoint in which the sending node is a member, in the canonical 423 format of :. A eight byte 424 EID is shown the clarity of the figure. 426 +----------+--------------------------------------------------------+ 427 | Value | Meaning | 428 +----------+--------------------------------------------------------+ 429 | 00000001 | Request acknowledgment of bundle segments. | 430 | 00000010 | Request enabling of reactive fragmentation. | 431 | 00000100 | Indicate support for negative acknowledgments. This | 432 | | flag MUST NOT be set to '1' unless support for | 433 | | acknowledgments is also indicated. | 434 +----------+--------------------------------------------------------+ 436 Table 1: Contact Header Flags 438 The manner in which values are configured and chosen for the various 439 flags and parameters in the contact header is implementation 440 dependent. 442 4.2. Validation and parameter negotiation 444 Upon reception of the contact header, both the TCPCL connection 445 initiator and the TCPCL connection acceptor follow the following 446 procedures for ensuring the validity of the TCPCL connection and to 447 negotiate values for the connection parameters. 449 If the magic string is not present or is not valid, the connection 450 MUST be terminated. The intent of the magic string is to provide a 451 some protection against an inadvertent TCP connection by a different 452 protocol than the one described in this document. To prevent a flood 453 of repeated connections from a misconfigured application, a node MAY 454 elect to hold an invalid connection open and idle for some time 455 before closing it. 457 If a node receives a contact header containing a version that is 458 greater than the current version of the protocol that the node 459 implements, then the node SHOULD interpret all fields and messages as 460 it would normally. If a node receives a contact header with a 461 version that is lower than the version of the protocol that the node 462 implements, the node may either terminate the connection due to the 463 version mismatch, or may adapt its operation to conform to the older 464 version of the protocol. This decision is an implementation matter. 466 A node calculates the parameters for a TCPCL connection by 467 negotiating the values from its own preferences (conveyed by the 468 contact header it sent) with the preferences of the peer node 469 (expressed in the contact header that it received). This negotiation 470 should proceed in the following manner: 472 The segment acknowledgments enabled parameter is set to true iff 473 the corresponding flag is set in both contact headers. 475 The reactive fragmentation enabled parameter is set to true iff 476 the corresponding flag is set in both contact headers. 478 Negative acknowledgments to interrupt transmission (actually: 479 refuse reception) of a bundle may only be used iff both peers 480 indicate support for negative acknowledgments in their contact 481 header. 483 The keepalive_interval parameter is set to the minimum value 484 from both contact headers. If one or both contact headers 485 contains the value zero, then the keepalive feature (described 486 in Section 5.5) is disabled. 488 Once this process of parameter negotiation is completed, the protocol 489 defines no additional mechanism to change the parameters of an 490 established connection; to effect such a change, the connection MUST 491 be terminated and a new connection established. 493 5. Established Connection Operation 495 This section describes the protocol operation for the duration of an 496 established connection, including the mechanisms for transmitting 497 bundles over the connection. 499 5.1. Message Type Codes 501 After the initial exchange of a contact header, all messages 502 transmitted over the connection are identified by a one octet header 503 with the following structure: 505 0 1 2 3 4 5 6 7 506 +-+-+-+-+-+-+-+-+ 507 | type | flags | 508 +-+-+-+-+-+-+-+-+ 510 type: Indicates the type of the message as per Table 2 below 512 flags: Optional flags defined on a per message type basis. 514 The types and values for the message type code are as follows. 516 +----------------+------+-------------------------------------------+ 517 | Type | Code | Comment | 518 +----------------+------+-------------------------------------------+ 519 | DATA_SEGMENT | 0x1 | Indicates the transmission of a segment | 520 | | | of bundle data, described in Section 5.2. | 521 | | | | 522 | ACK_SEGMENT | 0x2 | Acknowledges reception of a data segment, | 523 | | | described in Section 5.3 | 524 | | | | 525 | REFUSE_BUNDLE | 0x3 | Indicates that the transmission of the | 526 | | | current bundle shall be stopped, | 527 | | | described in Section 5.4. | 528 | | | | 529 | KEEPALIVE | 0x4 | Keepalive message for the connection, | 530 | | | described in Section 5.5. | 531 | | | | 532 | SHUTDOWN | 0x5 | Indicates that one of the nodes | 533 | | | participating in the connection wishes to | 534 | | | cleanly terminate the connection, | 535 | | | described in Section 6. | 536 | | | | 537 +----------------+------+-------------------------------------------+ 539 Table 2: TCPCL Header Types 541 5.2. Bundle Data Transmission 543 Each bundle is transmitted in one or more data segments. The format 544 of a data segment message follows: 546 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | 0x1 |0|0|S|E| length ... | contents.... | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 Figure 4: Format of bundle data segment messages 554 The type portion of the message header contains the value 0x1. 556 The flags portion of the message header octet contains two optional 557 values in the two low-order bits, denoted 'S' and 'E' above. The 'S' 558 bit MUST be set to one iff it precedes the transmission of the first 559 segment of a new bundle. The 'E' bit MUST be set to one when 560 transmitting the last segment of a bundle. 562 Determining the size of the segment is an implementation matter. In 563 particular, a node may, based on local policy or configuration, only 564 ever transmit bundle data in a single segment, in which case both the 565 'S' and 'E' bits MUST be set to one. However, a node MUST be able to 566 receive a bundle that has been transmitted in any segment size. 568 In the bundle protocol specification, a single bundle comprises a 569 primary bundle block, a payload block, and zero or more additional 570 bundle blocks. The relationship between the protocol blocks and the 571 convergence layer segments is an implementation-specific decision. 572 In particular, a segment MAY contain more than one protocol block; 573 alternatively, a single protocol block (such as the payload) MAY be 574 split into multiple segments. 576 However, a single segment MUST NOT contain data of more than a single 577 bundle. 579 Once a transmission of a bundle has commenced, the node MUST only 580 send segments containing sequential portions of that bundle until it 581 sends a segment with the 'E' bit set. 583 Following the message header, the length field is an SDNV containing 584 the number of bytes of bundle data that are transmitted in this 585 segment. Following this length is the actual data contents. 587 5.3. Bundle Acknowledgments 589 Although the TCP transport provides reliable transfer of data between 590 transport peers, the typical BSD sockets interface provides no means 591 to inform a sending application of when the receiving application has 592 processed some amount of transmitted data. Thus after transmitting 593 some data, a bundle protocol agent needs an additional mechanism to 594 determine whether the receiving agent has successfully received the 595 segment. 597 To this end, the TCPCL protocol offers an optional feature whereby a 598 receiving node transmits acknowledgments of reception of data 599 segments. This feature is enabled if and only if during the exchange 600 of contact headers, both parties set the flag to indicate that 601 segment acknowledgments are enabled (see Section 4.1). If so, then 602 the receiver MUST transmit a bundle acknowledgment header when it 603 successfully receives each data segment. 605 The format of a bundle acknowledgment is as follows: 607 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | 0x2 |0|0|0|0| acknowledged length ... | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 Figure 5: Format of bundle acknowledgement messages 615 To transmit an acknowledgment, a node first transmits a message 616 header with the ACK_SEGMENT type code and all flags set to zero, then 617 transmits an SDNV containing the cumulative length of the received 618 segment(s) of the current bundle. 620 For example, suppose the sending node transmits four segments of 621 bundle data with lengths 100, 200, 500, and 1000 respectively. After 622 receiving the first segment, the node sends an acknowledgment of 623 length 100. After the second segment is received, the node sends an 624 acknowledgment of length 300. The third and fourth acknowledgments 625 are of length 800 and 1800 respectively. 627 5.4. Bundle Refusal 629 As bundles may be large, the TCPCL supports an optional mechanisms by 630 which a receiving node may indicate to the sender that it does not 631 want to receive the corresponding bundle. 633 To do so, upon receiving a DATA_SEGMENT message, the node MAY 634 transmit a REFUSE_BUNDLE message. As data segments and 635 acknowledgments may cross on the wire, the data segment (and thus the 636 bundle) that is being refused is implicitly identified by the 637 sequence in which positive and negative acknowledgments are received. 639 The receiver MUST have acknowledged (positively or negatively) all 640 other received DATA_SEGMENTs before the one to be refused so that the 641 sender can identify the bundles accepted and refused by means of a 642 simple FIFO list of segments and acknowledgments. 644 The bundle refusal MAY be sent before the entire data segment is 645 received. If a sender receives a REFUSE_BUNDLE message, the sender 646 MUST complete the transmission of any partially-sent DATA_SEGMENT 647 message (so that the receiver stays in sync). The sender MUST NOT 648 commence transmission of any further segments of the rejected bundle 649 subsequently. Note, however, that this requirement does not ensure 650 that a node will not receive another DATA_SEGMENT for the same bundle 651 after transmitting a REFUSE_BUNDLE message since messages may cross 652 on the wire; if this happens, subsequent segments of the bundle 653 SHOULD be refused with a REFUSE_BUNDLE message, too. 655 Note: If a bundle transmission if aborted in this way, the receiver 656 may not receive a segment with the 'E' flag set to '1' for the 657 aborted bundle. The beginning of the next bundle is identified by 658 the 'S' bit set to '1', indicating the start of a new bundle. 660 5.5. Keepalive Messages 662 The protocol includes a provision for transmission of keepalive 663 messages over the TCP connection to help determine if the connection 664 has been disrupted. 666 As described in Section 4.1, one of the parameters in the contact 667 header is the keepalive_interval. Both sides populate this field 668 with their requested intervals (in seconds) between keepalive 669 messages. 671 The format of a keepalive message is a one byte message type code of 672 KEEPALIVE (as described in Table 2, with no additional data. Both 673 sides SHOULD send a keepalive message whenever the negotiated 674 interval has elapsed with no transmission of any message (keepalive 675 or other). 677 If no message (keepalive or other) has been received for at least 678 twice the keepalive interval, then either party may terminate the 679 session by transmitting a one byte message type code of SHUTDOWN (as 680 described in Table 2) and closing the TCP connection. 682 Note: The keepalive interval should not be chosen too short as TCP 683 retransmissions may occur in case of packet loss. Those will have to 684 be triggered by a timeout (TCP RTO) which is dependent on the 685 measured RTT for the TCP connection so that keepalive message may 686 experience noticeable latency. 688 6. Connection Termination 690 This section describes the procedures for ending a TCPCL connection. 692 6.1. Shutdown Message 694 To cleanly shut down a connection, a SHUTDOWN message MUST be 695 transmitted by either the initiator or the acceptor at any point 696 following complete transmission of any other message. In case 697 acknowledgments have been negotiated, it is advisable to acknowledge 698 all received data segments first and then shut down the connection. 700 The format of the shutdown message is as follows: 702 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 703 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 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | 0x3 |0|0|R|D| reason (opt) | reconnection delay (opt) | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 Figure 6: Format of bundle shutdown messages 710 It is possible for a node to convey additional information regarding 711 the reason for connection termination. To do so, the node MUST set 712 the 'R' bit in the message header flags, and transmit a one-byte 713 reason code immediately following the message header. The specified 714 values of the reason code are: 716 +------+-------------------+----------------------------------------+ 717 | Code | Meaning | Comment | 718 +------+-------------------+----------------------------------------+ 719 | 0x00 | Idle timeout | The connection is being closed due to | 720 | | | idleness. | 721 | | | | 722 | 0x01 | Version mismatch | The node cannot conform to the | 723 | | | specified TCPCL protocol version. | 724 | | | | 725 | 0x02 | Busy | The node is too busy to handle the | 726 | | | current connection. | 727 +------+-------------------+----------------------------------------+ 729 Table 3: Shutdown Reason Codes 731 It is also possible to convey a requested reconnection delay to 732 indicate how long the other node must wait before attempting 733 connection re-establishment. To do so, the node sets the 'D' bit in 734 the message header flags, then transmits an SDNV specifying the 735 requested delay, in seconds, following the message header (and 736 optionally the shutdown reason code). The value 0 SHALL be 737 interpreted as an infinite delay, i.e. that the connecting node MUST 738 NOT re-establish the connection. In contrast, if the node does not 739 wish to request a delay, it SHOULD omit the delay field (and set the 740 'D' bit to zero). Note that in the figure above, a two octet SDNV is 741 shown for convenience of the presentation. 743 A connection shutdown MAY occur immediately after TCP connection 744 establishment or reception of a contact header (and prior to any 745 further data exchange). This may, for example, be used to notify a 746 the initiator that the node is currently not capable of or willing to 747 communicate. However, a node MUST always send the contact header to 748 its peer first. 750 If either node terminates a connection prematurely in this manner, it 751 SHOULD send a SHUTDOWN message and MUST indicate a reason code unless 752 the incoming connection did not include the magic string. If a node 753 does not want its peer to re-open the connection immediately, it 754 SHOULD set the 'D' bit in the flags and include a reconnection delay 755 to indicate when the peer is allowed to attempt another connection 756 setup. 758 If a connection is to be terminated before another protocol message 759 has completed, then the node MUST NOT transmit the SHUTDOWN message 760 but still SHOULD close the TCP connection. In particular, if the 761 connection is to be closed (for whatever reason) while a node is in 762 the process of transmitting a bundle data segment, receiving node is 763 still expecting segment data and might erroneously interpret the 764 SHUTDOWN message to be part of the data segment. 766 6.2. Idle Connection Shutdown 768 The protocol includes a provision for clean shutdown of idle TCP 769 connections. Determining the length of time to wait before closing 770 idle connections, if they are to be closed at all, is an 771 implementation and configuration matter. 773 If there is a configured time to close idle links, then if no bundle 774 data (other than keepalive messages) has been received for at least 775 that amount of time, then either node MAY terminate the connection by 776 transmitting a SHUTDOWN message indicating the reason code of 'idle 777 timeout' (as described above). After receiving a SHUTDOWN message in 778 response, both sides may close the TCP connection. 780 7. Requirements notation 782 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 783 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 784 document are to be interpreted as described in [RFC2119]. 786 8. Security Considerations 788 One security consideration for this protocol relates to the fact that 789 nodes present their endpoint identifier as part of the connection 790 header exchange. It would be possible for a node to fake this value 791 and present the identity of a singleton endpoint in which the node is 792 not a member, essentially masquerading as another DTN node. If this 793 identifier is used without further verification as a means to 794 determine which bundles are transmitted over the connection, then the 795 node that has falsified its identity may be able to obtain bundles 796 that it should not have. 798 These concerns may be mitigated through the use of the Bundle 799 Security Protocols [refs.dtnsecurity]. In particular, the Bundle 800 Authentication Header defines mechanism for secure exchange of 801 bundles between DTN nodes. Thus an implementation could delay 802 trusting the presented endpoint identifier until the node can 803 securely validate that its peer is in fact the only member of the 804 given singleton endpoint. 806 Another consideration for this protocol relates to denial of service 807 attacks. A node may send a large amount of data over a TCP 808 connection, requiring the receiving node to either handle the data, 809 attempt to stop the flood of data by sending a REFUSE_BUNDLE message, 810 or forcibly terminate the connection. This burden could cause denial 811 of service on other, well-behaving connections. There is also 812 nothing to prevent a malicious node from continually establishing 813 connections and repeatedly trying to send copious amounts of bundle 814 data. 816 9. IANA Considerations 818 Port number 4556 has been assigned as the default port for the TCP 819 convergence layer. 821 10. References 823 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 824 Requirement Levels", RFC 2119, March 1997. 826 [refs.bundleproto] 827 Scott, K. and S. Burleigh, "Bundle Protocol 828 Specification", RFC 5050, November 2007. 830 [refs.dtnarch] 831 Cerf et al, V., "Delay-Tolerant Network Architecture", 832 RFC 4838, April 2007. 834 [refs.dtnimpl] 835 DTNRG, "Delay Tolerant Networking Reference 836 Implementation", . 838 [refs.dtnsecurity] 839 Symington, S., Farrell, S., and H. Weiss, "Bundle Security 840 Protocol Specification", Internet Draft, work in 841 progress draft-irtf-dtnrg-bundle-security-03.txt, 842 April 2007. 844 Authors' Addresses 846 Michael J. Demmer 847 University of California, Berkeley 848 Computer Science Division 849 445 Soda Hall 850 Berkeley, CA 94720-1776 851 US 853 Email: demmer@cs.berkeley.edu 855 Joerg Ott 856 Helsinki University of Technology 857 Department of Communications and Networking 858 PO Box 3000 859 TKK 02015 860 Finland 862 Email: jo@netlab.tkk.fi 864 Full Copyright Statement 866 Copyright (C) The IETF Trust (2008). 868 This document is subject to the rights, licenses and restrictions 869 contained in BCP 78, and except as set forth therein, the authors 870 retain all their rights. 872 This document and the information contained herein are provided on an 873 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 874 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 875 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 876 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 877 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 878 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 880 Intellectual Property 882 The IETF takes no position regarding the validity or scope of any 883 Intellectual Property Rights or other rights that might be claimed to 884 pertain to the implementation or use of the technology described in 885 this document or the extent to which any license under such rights 886 might or might not be available; nor does it represent that it has 887 made any independent effort to identify any such rights. Information 888 on the procedures with respect to rights in RFC documents can be 889 found in BCP 78 and BCP 79. 891 Copies of IPR disclosures made to the IETF Secretariat and any 892 assurances of licenses to be made available, or the result of an 893 attempt made to obtain a general license or permission for the use of 894 such proprietary rights by implementers or users of this 895 specification can be obtained from the IETF on-line IPR repository at 896 http://www.ietf.org/ipr. 898 The IETF invites any interested party to bring to its attention any 899 copyrights, patents or patent applications, or other proprietary 900 rights that may cover technology that may be required to implement 901 this standard. Please address the information to the IETF at 902 ietf-ipr@ietf.org.