idnits 2.17.1 draft-irtf-dtnrg-tcp-clayer-01.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 890. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 901. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 908. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 914. 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 (February 25, 2008) is 5899 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'L1' on line 311 -- Looks like a reference, but probably isn't: 'L2' on line 311 -- Looks like a reference, but probably isn't: 'L3' on line 316 == Outdated reference: A later version (-10) exists of draft-irtf-dtnrg-bundle-spec-09 == Outdated reference: A later version (-19) exists of draft-irtf-dtnrg-bundle-security-03 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 10 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: August 28, 2008 February 25, 2008 8 Delay Tolerant Networking TCP Convergence Layer Protocol 9 draft-irtf-dtnrg-tcp-clayer-01.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 August 28, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document describes the protocol for the TCP-based Convergence 43 Layer for Delay Tolerant Networking (DTN). 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 2.1. Definitions Relating to the Bundle Protocol . . . . . . . 4 50 2.2. Definitions specific to the TCPCL Protocol . . . . . . . . 5 51 3. General Protocol Description . . . . . . . . . . . . . . . . . 6 52 3.1. Example message exchange . . . . . . . . . . . . . . . . . 7 53 4. Connection Establishment . . . . . . . . . . . . . . . . . . . 8 54 4.1. Contact Header . . . . . . . . . . . . . . . . . . . . . . 9 55 4.2. Validation and parameter negotiation . . . . . . . . . . . 11 56 5. Established Connection Operation . . . . . . . . . . . . . . . 12 57 5.1. Message Type Codes . . . . . . . . . . . . . . . . . . . . 12 58 5.2. Bundle Data Transmission . . . . . . . . . . . . . . . . . 14 59 5.3. Bundle Acknowledgments . . . . . . . . . . . . . . . . . . 15 60 5.4. Bundle Refusal . . . . . . . . . . . . . . . . . . . . . . 15 61 5.5. Keepalive Messages . . . . . . . . . . . . . . . . . . . . 16 62 6. Connection Termination . . . . . . . . . . . . . . . . . . . . 17 63 6.1. Shutdown Message . . . . . . . . . . . . . . . . . . . . . 17 64 6.2. Idle Connection Shutdown . . . . . . . . . . . . . . . . . 18 65 7. Requirements notation . . . . . . . . . . . . . . . . . . . . 19 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 70 Intellectual Property and Copyright Statements . . . . . . . . . . 21 72 1. Introduction 74 This document describes the TCP-based convergence layer protocol for 75 Delay Tolerant Networking (TCPCL). Delay Tolerant Networking is an 76 end-to-end architecture providing communications in and/or through 77 highly stressed environments, including those with intermittent 78 connectivity, long and/or variable delays, and high bit error rates. 79 More detailed descriptions of the rationale and capabilities of these 80 networks can be found in the Delay-Tolerant Network Architecture [2] 81 Internet Draft. 83 An important goal of the DTN architecture is to accommodate a wide 84 range of networking technologies and environments. The protocol used 85 for DTN communications is the Bundling Protocol (BP) [3], an 86 application-layer protocol that is used to construct a store-and- 87 forward overlay network. As described in the bundle protocol 88 specification, BP requires the services of a "convergence layer 89 adapter" (CLA) to send and receive bundles using an underlying 90 internet protocol. This document describes one such convergence 91 layer adapter that uses the well-known Transmission Control Protocol 92 (TCP). 94 The locations of the TCPCL and BP in the Internet model protocol 95 stack are shown in Figure 1. In particular, both the BP and the 96 TCPCL reside above the transport layer, i.e., at the application 97 layer. 99 +-------------------------+ 100 | DTN Application | -\ 101 +-------------------------| | 102 | Bundle Protocol (BP) | -> Application Layer 103 +-------------------------+ | 104 | TCP Conv. Layer (TCPCL) | -/ 105 +-------------------------+ 106 | TCP | ---> Transport Layer 107 +-------------------------+ 108 | IP | ---> Network Layer 109 +-------------------------+ 110 | Link-Layer Protocol | ---> Link Layer 111 +-------------------------+ 112 | Physical Medium | ---> Physical Layer 113 +-------------------------+ 115 Figure 1: The locations of the bundle protocol and the TCP 116 convergence layer protocol in the Internet protocol stack 118 This document describes the format of the protocol data units passed 119 between entities participating in TCPCL communications. This 120 document does not address: 122 The format of protocol data units of the bundling protocol, as 123 those are defined elsewhere [3]. 125 Mechanisms for locating or identifying other bundle nodes within 126 an internet. 128 Operational logic or procedures used to implement this protocol. 130 Note that this document describes version 3 of the protocol. 131 Versions 0, 1, and 2 were never specified in any Internet Draft, RFC, 132 or any other public document. These prior versions of the protocol 133 were, however, implemented in the DTN reference implementation [5], 134 in prior releases, hence the current version number reflects the 135 existence of those prior versions. 137 2. Definitions 139 2.1. Definitions Relating to the Bundle Protocol 141 The following set of definitions are abbreviated versions of those 142 which appear in the Bundle Protocol Specification [3]. To the extent 143 in which terms appear in both documents, they are intended to have 144 the same meaning. 146 Bundle -- A bundle is a protocol data unit of the DTN bundle 147 protocol. 149 Bundle payload -- A bundle payload (or simply "payload") is the 150 application data whose conveyance to the bundle's destination is 151 the purpose for the transmission of a given bundle. 153 Fragment -- A fragment is a bundle whose payload contains a range of 154 bytes from another bundle's payload. 156 Bundle node -- A bundle node (or simply a "node") is any entity that 157 can send and/or receive bundles. The particular instantiation 158 of this entity is deliberately unconstrained, allowing for 159 implementations in software libraries, long-running processes, 160 or even hardware. One component of the bundle node is the 161 implementation of a convergence layer adapter. 163 Convergence layer adapter -- A convergence layer adapter (CLA) sends 164 and receives bundles utilizing the services of some 'native' 165 internet protocol. This document describes the manner in which 166 a CLA sends and receives bundles when using the TCP protocol for 167 inter-node communication. 169 Self Describing Numeric Value -- A self describing numeric value 170 (SDNV) is a variable length encoding for integer values, defined 171 in the bundle protocol specification. 173 2.2. Definitions specific to the TCPCL Protocol 175 This section contains definitions that are interpreted to be specific 176 to the operation of the TCPCL protocol, as described below. 178 TCP Connection -- A TCP connection refers to a transport connection 179 using TCP as the transport protocol. 181 TCPCL Connection -- A TCPCL connection (as opposed to a TCP 182 connection) is a TCPCL communication relationship between two 183 bundle nodes. The lifetime of a TCPCL connection is one-to-one 184 with the lifetime of an underlying TCP connection. Therefore a 185 TCPCL connection is initiated when a bundle node initiates a TCP 186 connection to be established for the purposes of bundle 187 communication. A TCPCL connection is terminated when the TCP 188 connection ends, due either to one or both nodes actively 189 terminating the TCP connection or due to network errors causing 190 a failure of the TCP connection. For the remainder of this 191 document, the term "connection" without the prefix "TCPCL" shall 192 refer to a TCPCL connection. 194 Connection parameters -- The connection parameters are a set of 195 values used to affect the operation of the TCPCL for a given 196 connection. The manner in which these parameters are conveyed 197 to the bundle node and thereby to the TCPCL is implementation- 198 dependent. However, the mechanism by which two bundle nodes 199 exchange and negotiate the values to be used for a given session 200 is described in Section Section 4.2. 202 Connection initiator -- The connection initiator is the bundle node 203 that causes the establishment of a new connection by creating a 204 new TCP connection (for example, by using the connect() call in 205 the BSD sockets API) and then following the procedures described 206 in Section 4. 208 Connection acceptor -- The connection acceptor is the bundle node 209 that establishes a connection in response to an active 210 connection attempt by another bundle node (for example, by using 211 the listen() and accept() calls of the BSD sockets API) and then 212 following the procedures described in Section 4. 214 Transmission -- Transmission refers to the procedures and mechanisms 215 (described below) for conveyance of a bundle from one node to 216 another. 218 3. General Protocol Description 220 This protocol provides bundle conveyance over a TCP connection and 221 specifies the encapsulation of bundles as well as procedures for TCP 222 connection setup and teardown. The general operation of the protocol 223 is as follows: 225 First one node establishes a TCPCL connection to the other by 226 initiating a TCP connection. After setup of the TCP connection is 227 complete, an initial contact header is exchanged in both directions 228 to set parameters of the TCPCL connection and exchange a singleton 229 endpoint identifier for each node (not the singleton EID of any 230 application running on the node), to denote the bundle-layer identity 231 of each DTN node. This is used to assist in routing and forwarding 232 messages, e.g., to prevent loops. 234 Once the TCPCL connection is established and configured in this way, 235 bundles can be transmitted in either direction. Each bundle is 236 transmitted in one or more logical segments of formatted bundle data. 237 Each logical data segment consists of a DATA_SEGMENT message header, 238 an SDNV containing the length of the segment, and finally the byte 239 range of the bundle data. The choice of the length to use for 240 segments is an implementation matter. The first segment for a bundle 241 must set the 'start' flag and the last one must set the 'end' flag in 242 the DATA_SEGMENT message header. 244 An optional feature of the protocol is for the receiving node to send 245 acknowledgments as bundle data segments arrive (ACK_SEGMENT). The 246 rationale behind these acknowledgments is to enable the sender node 247 to determine how much of the bundle has been received, so that in 248 case the connection is interrupted, it can perform reactive 249 fragmentation to avoid re-sending the already transmitted part of the 250 bundle. 252 When acknowledgments are enabled, then for each data segment that is 253 received, the receiving node sends an ACK_SEGMENT code followed by an 254 SDNV containing the cumulative length of the bundle that has been 255 received. Note that in the case of concurrent bidirectional 256 transmission, then ack segments may be interleaved with data 257 segments. 259 Another optional feature is that a receiver may interrupt the 260 transmission of a bundle at any point in time by replying with a 261 negative acknowledgment (REFUSE_BUNDLE) which causes the sender to 262 stop transmission of the current bundle, after completing 263 transmission of a partially sent data segment. Note: This allows a 264 receiver that detects it already has received a certain bundle to 265 interrupt transmission as early as possible and thus save 266 transmission capacity for other bundles. 268 For connections that are idle, a KEEPALIVE message may optionally be 269 sent at a negotiated interval. This is used to convey liveness 270 information. 272 Finally, before connections close, a SHUTDOWN message is sent on the 273 channel. After sending a SHUTDOWN message, the sender of this 274 message may send further acknowledgments (ACK_SEGMENT or 275 REFUSE_BUNDLE) but no further data messages (DATA_SEGMENT). A 276 SHUTDOWN message may also be used to refuse a connection setup by a 277 peer. 279 3.1. Example message exchange 281 The following figure visually depicts the protocol exchange for a 282 simple session, showing the connection establishment, and the 283 transmission of a single bundle split into three data segments (of 284 lengths L1, L2, and L3) from Node A to Node B. 286 Note that the sending node may transmit multiple DATA_SEGMENT 287 messages without necessarily waiting for the corresponding 288 ACK_SEGMENT responses. This enables pipelining of messages on a 289 channel. Although this example only demonstrates a single bundle 290 transmission, it is also possible to pipeline multiple DATA_SEGMENT 291 messages for different bundles without necessarily waiting for 292 ACK_SEGMENT messages to be returned for each one. However, 293 interleaving data segments from different bundles is not allowed. 295 No errors or rejections are shown in this example. 297 Node A Node B 298 ====== ====== 300 +-------------------------+ +-------------------------+ 301 | Contact Header | -> <- | Contact Header | 302 +-------------------------+ +-------------------------+ 304 +-------------------------+ 305 | DATA_SEGMENT (start) | -> 306 | SDNV length [L1] | -> 307 | Bundle Data 0..L1 | -> 308 +-------------------------+ 309 +-------------------------+ +-------------------------+ 310 | DATA_SEGMENT | -> <- | ACK_SEGMENT | 311 | SDNV length [L2] | -> <- | SDNV length [L1] | 312 | Bundle Data L1..L2 | -> +-------------------------+ 313 +-------------------------+ 314 +-------------------------+ +-------------------------+ 315 | DATA_SEGMENT (end) | -> <- | ACK_SEGMENT | 316 | SDNV length [L3] | -> <- | SDNV length [L1+L2] | 317 | Bundle Data L2..L3 | -> +-------------------------+ 318 +-------------------------+ 319 +-------------------------+ 320 <- | ACK_SEGMENT | 321 <- | SDNV length [L1+L2+L3] | 322 +-------------------------+ 324 +-------------------------+ +-------------------------+ 325 | SHUTDOWN | -> <- | SHUTDOWN | 326 +-------------------------+ +-------------------------+ 328 Figure 2: A simple visual example of the flow of protocol messages on 329 a single TCP session between two nodes (A and B) 331 4. Connection Establishment 333 For bundle transmissions to occur using the TCPCL, a TCPCL connection 334 must first be established between communicating nodes. The manner in 335 which a bundle node makes the decision to establish such a connection 336 is implementation-dependent. For example, some connections may be 337 opened proactively and maintained for as long as is possible given 338 the network conditions, while other connections may be opened only 339 when there is a bundle that is queued for transmission and the 340 routing algorithm selects a certain next hop node. 342 To establish a TCPCL connection, a node must first establish a TCP 343 connection with the intended peer node, typically by using the 344 services provided by the operating system. Port number 4556 has been 345 assigned by IANA as the well-known port number for the TCP 346 convergence layer. Other port numbers MAY be used per local 347 configuration. Determining a peer's port number (if different from 348 the well-known TCPCL port) is up to the implementation. 350 If the node is unable to establish a TCP connection for any reason, 351 then it is an implementation matter to determine how to handle the 352 connection failure. A node MAY decide to re-attempt to establish the 353 connection, perhaps. If it does so, it MUST NOT overwhelm its target 354 with repeated connection attempts. Therefore, the node MUST retry 355 the connection setup only after some delay and it SHOULD use a 356 (binary) exponential backoff mechanism to increase this delay in case 357 of repeated failures. 359 The node MAY declare failure after one or more connection attempts 360 and MAY attempt to find an alternate route for bundle data. 362 Once a TCP connection is established, the connection initiator MUST 363 immediately transmit a contact header over the TCP connection. The 364 connection acceptor MUST also immediately transmit a contact header 365 over the TCP connection. The format of the contact header is 366 described in Section 4.1). 368 Upon receipt of the contact header, both nodes perform the validation 369 and negotiation procedures defined in Section 4.2 371 After receiving the contact header from the other node, either node 372 MAY also refuse the connection by sending a SHUTDOWN message. If 373 connection setup is refused a reason MUST be included in the SHUTDOWN 374 message. 376 4.1. Contact Header 378 Once a TCP connection is established, both parties exchange a contact 379 header. This section describes the format of the contact header and 380 the meaning of its fields. 382 The format for the Contact Header is as follows: 384 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 385 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 386 +---------------+---------------+---------------+---------------+ 387 | magic='dtn!' | 388 +---------------+---------------+---------------+---------------+ 389 | version | flags | keepalive_interval | 390 +---------------+---------------+---------------+---------------+ 391 | local EID length (SDNV) | 392 +---------------+---------------+---------------+---------------+ 393 | | 394 + local EID (variable) + 395 | | 396 +---------------+---------------+---------------+---------------+ 398 Figure 3: Contact Header Format 400 The fields of the contact header are: 402 magic: A four byte field that always contains the byte sequence 0x64 403 0x76 0x6e 0x21, i.e. the text string "dtn!". 405 version: A one byte field value containing the current version of 406 the protocol. 408 flags: A one byte field containing optional connection flags. The 409 first five bits are unused and MUST be set to zero upon 410 transmission and MUST be ignored upon reception. The last three 411 bits are interpreted as shown in table Table 1 below. 413 keepalive_interval: A two byte integer field containing the number 414 of seconds between exchanges of keepalive messages on the 415 connection (see Section 5.5). This value is in network byte 416 order, as are all other multi-byte fields described in this 417 protocol. 419 local eid length: A variable length SDNV field containing the length 420 of the endpoint identifier (EID) for some singleton endpoint in 421 which the sending node is a member. A four byte SDNV is 422 depicted for clarity of the figure. 424 local EID: An octet string containing the EID of some singleton 425 endpoint in which the sending node is a member, in the canonical 426 format of :. A four byte EID 427 is shown the clarity of the figure. 429 +----------+--------------------------------------------------------+ 430 | Value | Meaning | 431 +----------+--------------------------------------------------------+ 432 | 00000001 | Request acknowledgment of bundle segments. | 433 | 00000010 | Request enabling of reactive fragmentation. | 434 | 00000100 | Indicate support for negative acknowledgments. This | 435 | | flag MUST NOT be set to '1' unless support for | 436 | | acknowledgments is also indicated. | 437 +----------+--------------------------------------------------------+ 439 Table 1: Contact Header Flags 441 The manner in which values are configured and chosen for the various 442 flags and parameters in the contact header is implementation 443 dependent. 445 4.2. Validation and parameter negotiation 447 Upon reception of the contact header, both the TCPCL connection 448 initiator and the TCPCL connection acceptor follow the following 449 procedures for ensuring the validity of the TCPCL connection and to 450 negotiate values for the connection parameters. 452 If the magic string is not present or is not valid, the connection 453 MUST be terminated. The intent of the magic string is to provide a 454 some protection against an inadvertent TCP connection by a different 455 protocol than the one described in this document. To prevent a flood 456 of repeated connections from a misconfigured application, a node MAY 457 elect to hold an invalid connection open and idle for some time 458 before closing it. 460 If a node receives a contact header containing a version that is 461 greater than the current version of the protocol that the node 462 implements, then the node SHOULD interpret all fields and messages as 463 it would normally. If a node receives a contact header with a 464 version that is lower than the version of the protocol that the node 465 implements, the node may either terminate the connection due to the 466 version mismatch, or may adapt its operation to conform to the older 467 version of the protocol. This decision is an implementation matter. 469 A node calculates the parameters for a TCPCL connection by 470 negotiating the values from its own preferences (conveyed by the 471 contact header it sent) with the preferences of the peer node 472 (expressed in the contact header that it received). This negotiation 473 should proceed in the following manner: 475 The segment acknowledgments enabled parameter is set to true iff 476 the corresponding flag is set in both contact headers. 478 The reactive fragmentation enabled parameter is set to true iff 479 the corresponding flag is set in both contact headers. 481 Negative acknowledgments to interrupt transmission (actually: 482 refuse reception) of a bundle may only be used iff both peers 483 indicate support for negative acknowledgments in their contact 484 header. 486 The keealive_interval parameter should be set to the minimum 487 value from both contact headers. If one or both contact headers 488 contains the value zero, then the keepalive feature (described 489 in Section 5.5) is disabled. 491 Once this process of parameter negotiation is completed, the protocol 492 defines no additional mechanism to change the parameters of an 493 established connection; to effect such a change, the connection MUST 494 be terminated and a new connection established. 496 5. Established Connection Operation 498 This section describes the protocol operation for the duration of an 499 established connection, including the mechanisms for transmitting 500 bundles over the connection. 502 5.1. Message Type Codes 504 After the initial exchange of a contact header, all messages 505 transmitted over the connection are denoted by a one octet header 506 with the following structure: 508 0 1 2 3 4 5 6 7 509 +-+-+-+-+-+-+-+-+ 510 | type | flags | 511 +-+-+-+-+-+-+-+-+ 513 type: Indicates the type of the message as per Table 2 below 515 flags: Optional flags defined on a per message type basis. 517 The types and values for the message type code are as follows. 519 +----------------+------+-------------------------------------------+ 520 | Type | Code | Comment | 521 +----------------+------+-------------------------------------------+ 522 | DATA_SEGMENT | 0x1 | Indicates the transmission of a segment | 523 | | | of bundle data, described in Section 5.2. | 524 | | | | 525 | ACK_SEGMENT | 0x2 | Acknowledges reception of a data segment, | 526 | | | described in Section 5.3 | 527 | | | | 528 | REFUSE_BUNDLE | 0x3 | Indicates that the transmission of the | 529 | | | current bundle shall be stopped, | 530 | | | described in Section 5.4. | 531 | | | | 532 | KEEPALIVE | 0x4 | Keepalive message for the connection, | 533 | | | described in Section 5.5. | 534 | | | | 535 | SHUTDOWN | 0x5 | Indicates that one of the nodes | 536 | | | participating in the connection wishes to | 537 | | | cleanly terminate the connection, | 538 | | | described in Section 6. | 539 | | | | 540 +----------------+------+-------------------------------------------+ 542 Table 2: TCPCL Header Types 544 Open Issue: Currently, the message code implicitly identifies the 545 expected message length, possibly in combination with some flags. 546 This may limit backwards compatible extensibility: an "old" endpoint 547 may not know about a "new" message code or extension flag and hence 548 may not be able to skip the unknown (part of the) message, even 549 though it would otherwise be perfectly capable of interoperating (at 550 reduced functionality). Therefore, we may want to consider providing 551 an explicit length indication if the message length is more than a 552 single octet. Options include: (a) always including a length field, 553 (b) using one bit of the flags to indicate whether or not length 554 field is present (which then would be the case for all messages of 555 more than one byte length), and (c) relying on a new version number 556 for all extensions. 558 5.2. Bundle Data Transmission 560 Each bundle is transmitted in one or more data segments. The format 561 of a data segment message follows: 563 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | 0x1 |0|0|S|E| length ... | contents.... | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Figure 4: Format of bundle data segment messages 571 The type portion of the message header contains the value 0x1. 573 The flags portion of the message header octet contains two optional 574 values in the two low-order bits, denoted 'S' and 'E' above. The 'S' 575 bit MUST be set to one iff it precedes the transmission of the first 576 segment of a new bundle. The 'E' bit MUST be set to one when 577 transmitting the last segment of a bundle. 579 Determining the size of the segment is an implementation matter. In 580 particular, a node may, based on local policy or configuration, only 581 ever transmit bundle data in a single segment, in which case both the 582 'S' and 'E' bits MUST be set to one. However, a node MUST be able to 583 receive a bundle that has been transmitted in any segment size. 585 In the bundle protocol specification, a single bundle comprises a 586 primary bundle block, a payload block, and zero or more additional 587 bundle blocks. The relationship between the protocol blocks and the 588 convergence layer segments is an implementation-specific decision. 589 In particular, a segment MAY contain more than one protocol block; 590 alternatively, a single protocol block (such as the payload) MAY be 591 split into multiple segments. 593 However, a single segment MUST NOT contain data of more than a single 594 bundle. 596 Once a transmission of a bundle has commenced, the node MUST only 597 send segments containing sequential portions of that bundle until it 598 sends a segment with the 'E' bit set. 600 Following the message header, the length field is an SDNV containing 601 the number of bytes of bundle data that are transmitted in this 602 segment. Following this length is the actual data contents. 604 5.3. Bundle Acknowledgments 606 Although the TCP transport provides reliable transfer of data between 607 transport peers, the typical BSD sockets interface provides no means 608 to inform a sending application of when the receiving application has 609 processed some amount of transmitted data. Thus after transmitting 610 some data, a bundle protocol agent needs an additional mechanism to 611 determine whether the receiving agent has successfully received the 612 segment. 614 To this end, the TCPCL protocol offers an optional feature whereby a 615 receiving node transmits acknowledgments of reception of data 616 segments. This feature is enabled if and only if during the exchange 617 of contact headers, both parties set the flag to indicate that 618 segment acknowledgments are enabled (see Section 4.1). If so, then 619 the receiver MUST transmit a bundle acknowledgment header when it 620 successfully receives each data segment. 622 The format of a bundle acknowledgment is as follows: 624 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 625 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 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | 0x2 |0|0|0|0| acknowledged length ... | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 Figure 5: Format of bundle acknowledgement messages 632 To transmit an acknowledgment, a node first transmits a message 633 header with the ACK_SEGMENT type code and all flags set to zero, then 634 transmits an SDNV containing the cumulative length of the received 635 segment(s) of the current bundle. 637 For example, suppose the sending node transmits four segments of 638 bundle data with lengths 100, 200, 500, and 1000 respectively. After 639 receiving the first segment, the node sends an acknowledgment of 640 length 100. After the second segment is received, the node sends an 641 acknowledgment of length 300. The third and fourth acknowledgments 642 are of length 800 and 1800 respectively. 644 5.4. Bundle Refusal 646 As bundles may be large, the TCPCL supports an optional mechanisms by 647 which a receiving node may indicate to the sender that it does not 648 want to receive the corresponding bundle. 650 To do so, upon receiving a DATA_SEGMENT message, the node MAY 651 transmit a REFUSE_BUNDLE message. As data segments and 652 acknowledgments may cross on the wire, the data segment (and thus the 653 bundle) that is being refused is implicitly identified by the 654 sequence in which positive and negative acknowledgments are received. 656 The receiver MUST have acknowledged (positively or negatively) all 657 other received DATA_SEGMENTs before the one to be refused so that the 658 sender can identify the bundles accepted and refused by means of a 659 simple FIFO list of segments and acknowledgments. 661 The bundle refusal MAY be sent before the entire data segment is 662 received. If a sender receives a REFUSE_BUNDLE message, the sender 663 MUST complete the transmission of any partially-sent DATA_SEGMENT 664 message (so that the receiver stays in sync). The sender MUST NOT 665 commence transmission of any further segments of the rejected bundle 666 subsequently. Note, however, that this requirement does not ensure 667 that a node will not receive another DATA_SEGMENT for the same bundle 668 after transmitting a REFUSE_BUNDLE message since messages may cross 669 on the wire; if this happens, subsequent segments of the bundle 670 SHOULD be refused with a REFUSE_BUNDLE message, too. 672 Note: If a bundle transmission if aborted in this way, the receiver 673 may not receive a segment with the 'E' flag set to '1' for the 674 aborted bundle. The beginning of the next bundle is identified by 675 the 'S' bit set to '1', indicating the start of a new bundle. 677 5.5. Keepalive Messages 679 The protocol includes a provision for transmission of keepalive 680 messages over the TCP connection to help determine if the connection 681 has been disrupted. 683 As described in Section 4.1, one of the parameters in the contact 684 header is the keepalive_interval. Both sides populate this field 685 with their requested intervals (in seconds) between keepalive 686 messages. 688 The format of a keepalive message is a one byte message type code of 689 KEEPALIVE (as described in Table 2, with no additional data. Both 690 sides SHOULD send a keepalive message whenever the negotiated 691 interval has elapsed with no transmission of any message (keepalive 692 or other). 694 If no message (keepalive or other) has been received for at least 695 twice the keepalive interval, then either party may terminate the 696 session by transmitting a one byte message type code of SHUTDOWN (as 697 described in Table 2) and closing the TCP connection. 699 Note: The keepalive interval should not be chosen too short as TCP 700 retransmissions may occur in case of packet loss. Those will have to 701 be triggered by a timeout (TCP RTO) which is dependent on the 702 measured RTT for the TCP connection so that keepalive message may 703 experience noticeable latency. 705 6. Connection Termination 707 This section describes the procedures for ending a TCPCL connection. 709 6.1. Shutdown Message 711 To cleanly shut down a connection, a SHUTDOWN message MUST be 712 transmitted by either the initiator or the acceptor at any point 713 following complete transmission of any other message. In case 714 acknowledgments have been negotiated, it is advisable to acknowledge 715 all received data segments first and then shut down the connection. 717 The format of the shutdown message is as follows: 719 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 720 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 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | 0x3 |0|0|R|D| reason (opt) | reconnection delay (opt) | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 Figure 6: Format of bundle shutdown messages 727 It is possible for a node to convey additional information regarding 728 the reason for connection termination. To do so, the node MUST set 729 the 'R' bit in the message header flags, and transmit a one-byte 730 reason code immediately following the message header. The specified 731 values of the reason code are: 733 +------+-------------------+----------------------------------------+ 734 | Code | Meaning | Comment | 735 +------+-------------------+----------------------------------------+ 736 | 0x00 | Idle timeout | The connection is being closed due to | 737 | | | idleness. | 738 | | | | 739 | 0x01 | Version mismatch | The node cannot conform to the | 740 | | | specified TCPCL protocol version. | 741 | | | | 742 | 0x02 | Busy | The node is too busy to handle the | 743 | | | current connection. | 744 +------+-------------------+----------------------------------------+ 746 Table 3: Shutdown Reason Codes 748 It is also possible to convey a requested reconnection delay to 749 indicate how long the other node must wait before attempting 750 connection re-establishment. To do so, the node sets the 'D' bit in 751 the message header flags, then transmits an SDNV specifying the 752 requested delay, in seconds, following the message header (and 753 optionally the shutdown reason code). The value 0 SHALL be 754 interpreted as an infinite delay, i.e. that the connecting node MUST 755 NOT re-establish the connection. In contrast, if the node does not 756 wish to request a delay, it SHOULD omit the delay field (and set the 757 'D' bit to zero). Note that in the figure above, a two octet SDNV is 758 shown for convenience of the presentation. 760 A connection shutdown MAY occur immediately after TCP connection 761 establishment or reception of a contact header (and prior to any 762 further data exchange). This may, for example, be used to notify a 763 the initiator that the node is currently not capable of or willing to 764 communicate. However, a node MUST always send the contact header to 765 its peer first. 767 If either node terminates a connection prematurely in this manner, it 768 SHOULD send a SHUTDOWN message and MUST indicate a reason code unless 769 the incoming connection did not include the magic string. If a node 770 does not want its peer to re-open the connection immediately, it 771 SHOULD set the 'D' bit in the flags and include a reconnection delay 772 to indicate when the peer is allowed to attempt another connection 773 setup. 775 If a connection is to be terminated before another protocol message 776 has completed, then the node MUST NOT transmit the SHUTDOWN message 777 but still SHOULD close the TCP connection. In particular, if the 778 connection is to be closed (for whatever reason) while a node is in 779 the process of transmitting a bundle data segment, receiving node is 780 still expecting segment data and might erroneously interpret the 781 SHUTDOWN message to be part of the data segment. 783 6.2. Idle Connection Shutdown 785 The protocol includes a provision for clean shutdown of idle TCP 786 connections. Determining the length of time to wait before closing 787 idle connections, if they are to be closed at all, is an 788 implementation and configuration matter. 790 If there is a configured time to close idle links, then if no bundle 791 data (other than keepalive messages) has been received for at least 792 that amount of time, then either node MAY terminate the connection by 793 transmitting a SHUTDOWN message indicating the reason code of 'idle 794 timeout' (as described above). After receiving a SHUTDOWN message in 795 response, both sides may close the TCP connection. 797 7. Requirements notation 799 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 800 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 801 document are to be interpreted as described in [1]. 803 8. Security Considerations 805 One security consideration for this protocol relates to the fact that 806 nodes present their endpoint identifier as part of the connection 807 header exchange. It would be possible for a node to fake this value 808 and present the identity of a singleton endpoint in which the node is 809 not a member, essentially masquerading as another DTN node. If this 810 identifier is used without further verification as a means to 811 determine which bundles are transmitted over the connection, then the 812 node that has falsified its identity may be able to obtain bundles 813 that it should not have. 815 These concerns may be mitigated through the use of the Bundle 816 Security Protocols [4]. In particular, the Bundle Authentication 817 Header defines mechanism for secure exchange of bundles between DTN 818 nodes. Thus an implementation could delay trusting the presented 819 endpoint identifier until the node can securely validate that its 820 peer is in fact the only member of the given singleton endpoint. 822 Another consideration for this protocol relates to denial of service 823 attacks. A node may send a large amount of data over a TCP 824 connection, requiring the receiving node to either handle the data, 825 attempt to stop the flood of data by sending a REFUSE_BUNDLE message, 826 or forcibly terminate the connection. This burden could cause denial 827 of service on other, well-behaving connections. There is also 828 nothing to prevent a malicious node from continually establishing 829 connections and repeatedly trying to send copious amounts of bundle 830 data. 832 9. IANA Considerations 834 Port number 4556 has been assigned as the default port for the TCP 835 convergence layer. 837 10. References 839 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 840 Levels", RFC 2119, March 1997. 842 [2] Cerf et al, V., "Delay-Tolerant Network Architecture", RFC 4838, 843 April 2007. 845 [3] Scott, K. and S. Burleigh, "Bundle Protocol Specification", 846 Internet Draft, work in progress, Internet Draft 847 draft-irtf-dtnrg-bundle-spec-09.txt, April 2007. 849 [4] Symington, S., Farrell, S., and H. Weiss, "Bundle Security 850 Protocol Specification", Internet Draft, work in 851 progress draft-irtf-dtnrg-bundle-security-03.txt, April 2007. 853 [5] DTNRG, "Delay Tolerant Networking Reference Implementation", 854 . 856 Authors' Addresses 858 Michael J. Demmer 859 University of California, Berkeley 860 Computer Science Division 861 445 Soda Hall 862 Berkeley, CA 94720-1776 863 US 865 Email: demmer@cs.berkeley.edu 867 Joerg Ott 868 Helsinki University of Technology 869 Networking Laboratory 870 PO Box 3000 871 TKK 02015 872 Finland 874 Email: jo@netlab.tkk.fi 876 Full Copyright Statement 878 Copyright (C) The IETF Trust (2008). 880 This document is subject to the rights, licenses and restrictions 881 contained in BCP 78, and except as set forth therein, the authors 882 retain all their rights. 884 This document and the information contained herein are provided on an 885 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 886 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 887 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 888 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 889 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 890 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 892 Intellectual Property 894 The IETF takes no position regarding the validity or scope of any 895 Intellectual Property Rights or other rights that might be claimed to 896 pertain to the implementation or use of the technology described in 897 this document or the extent to which any license under such rights 898 might or might not be available; nor does it represent that it has 899 made any independent effort to identify any such rights. Information 900 on the procedures with respect to rights in RFC documents can be 901 found in BCP 78 and BCP 79. 903 Copies of IPR disclosures made to the IETF Secretariat and any 904 assurances of licenses to be made available, or the result of an 905 attempt made to obtain a general license or permission for the use of 906 such proprietary rights by implementers or users of this 907 specification can be obtained from the IETF on-line IPR repository at 908 http://www.ietf.org/ipr. 910 The IETF invites any interested party to bring to its attention any 911 copyrights, patents or patent applications, or other proprietary 912 rights that may cover technology that may be required to implement 913 this standard. Please address the information to the IETF at 914 ietf-ipr@ietf.org. 916 Acknowledgment 918 Funding for the RFC Editor function is provided by the IETF 919 Administrative Support Activity (IASA).