idnits 2.17.1 draft-irtf-dtnrg-tcp-clayer-04.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 28, 2012) is 4252 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'L1' is mentioned on line 304, but not defined == Missing Reference: 'L2' is mentioned on line 304, but not defined == Missing Reference: 'L3' is mentioned on line 309, 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: March 1, 2013 Technology 7 S. Perreault 8 Viagenie 9 August 28, 2012 11 Delay Tolerant Networking TCP Convergence Layer Protocol 12 draft-irtf-dtnrg-tcp-clayer-04.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 March 1, 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 the service of some "native" link, network, or internet protocol. 97 This document describes one such convergence layer adapter that uses 98 the well-known Transmission Control Protocol (TCP). This convergence 99 layer is referred to as TCPCL. 101 The locations of the TCPCL and the BP in the Internet model protocol 102 stack are shown in Figure 1. In particular, when BP is using TCP as 103 its bearer with TCPCL as its convergence layer, both BP and TCPCL 104 reside at the application layer of the Internet model. 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 159 contiguous subset of 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 Transmission -- Transmission refers to the procedures and mechanisms 208 (described below) for conveyance of a bundle from one node to 209 another. 211 3. General Protocol Description 213 This protocol provides bundle conveyance over a TCP connection and 214 specifies the encapsulation of bundles as well as procedures for TCP 215 connection setup and teardown. The general operation of the protocol 216 is as follows: 218 First one node establishes a TCPCL connection to the other by 219 initiating a TCP connection. After setup of the TCP connection is 220 complete, an initial contact header is exchanged in both directions 221 to set parameters of the TCPCL connection and exchange a singleton 222 endpoint identifier for each node (not the singleton EID of any 223 application running on the node), to denote the bundle-layer identity 224 of each DTN node. This is used to assist in routing and forwarding 225 messages, e.g., to prevent loops. 227 Once the TCPCL connection is established and configured in this way, 228 bundles can be transmitted in either direction. Each bundle is 229 transmitted in one or more logical segments of formatted bundle data. 230 Each logical data segment consists of a DATA_SEGMENT message header, 231 an SDNV containing the length of the segment, and finally the byte 232 range of the bundle data. The choice of the length to use for 233 segments is an implementation matter. The first segment for a bundle 234 must set the 'start' flag and the last one must set the 'end' flag in 235 the DATA_SEGMENT message header. 237 An optional feature of the protocol is for the receiving node to send 238 acknowledgments as bundle data segments arrive (ACK_SEGMENT). The 239 rationale behind these acknowledgments is to enable the sender node 240 to determine how much of the bundle has been received, so that in 241 case the connection is interrupted, it can perform reactive 242 fragmentation to avoid re-sending the already transmitted part of the 243 bundle. 245 When acknowledgments are enabled, then for each data segment that is 246 received, the receiving node sends an ACK_SEGMENT code followed by an 247 SDNV containing the cumulative length of the bundle that has been 248 received. Note that in the case of concurrent bidirectional 249 transmission, then ack segments may be interleaved with data 250 segments. 252 Another optional feature is that a receiver may interrupt the 253 transmission of a bundle at any point in time by replying with a 254 REFUSE_BUNDLE message which causes the sender to stop transmission of 255 the current bundle, after completing transmission of a partially sent 256 data segment. Note: This enables a cross-layer optimization in that 257 it allows a receiver that detects that it already has received a 258 certain bundle to interrupt transmission as early as possible and 259 thus save transmission capacity for other bundles. 261 For connections that are idle, a KEEPALIVE message may optionally be 262 sent at a negotiated interval. This is used to convey liveness 263 information. 265 Finally, before connections close, a SHUTDOWN message is sent on the 266 channel. After sending a SHUTDOWN message, the sender of this 267 message may send further acknowledgments (ACK_SEGMENT or 268 REFUSE_BUNDLE) but no further data messages (DATA_SEGMENT). A 269 SHUTDOWN message may also be used to refuse a connection setup by a 270 peer. 272 3.1. Example message exchange 274 The following figure visually depicts the protocol exchange for a 275 simple session, showing the connection establishment, and the 276 transmission of a single bundle split into three data segments (of 277 lengths L1, L2, and L3) from Node A to Node B. 279 Note that the sending node may transmit multiple DATA_SEGMENT 280 messages without necessarily waiting for the corresponding 281 ACK_SEGMENT responses. This enables pipelining of messages on a 282 channel. Although this example only demonstrates a single bundle 283 transmission, it is also possible to pipeline multiple DATA_SEGMENT 284 messages for different bundles without necessarily waiting for 285 ACK_SEGMENT messages to be returned for each one. However, 286 interleaving data segments from different bundles is not allowed. 288 No errors or rejections are shown in this example. 290 Node A Node B 291 ====== ====== 293 +-------------------------+ +-------------------------+ 294 | Contact Header | -> <- | Contact Header | 295 +-------------------------+ +-------------------------+ 297 +-------------------------+ 298 | DATA_SEGMENT (start) | -> 299 | SDNV length [L1] | -> 300 | Bundle Data 0..L1 | -> 301 +-------------------------+ 302 +-------------------------+ +-------------------------+ 303 | DATA_SEGMENT | -> <- | ACK_SEGMENT | 304 | SDNV length [L2] | -> <- | SDNV length [L1] | 305 | Bundle Data L1..L2 | -> +-------------------------+ 306 +-------------------------+ 307 +-------------------------+ +-------------------------+ 308 | DATA_SEGMENT (end) | -> <- | ACK_SEGMENT | 309 | SDNV length [L3] | -> <- | SDNV length [L1+L2] | 310 | Bundle Data L2..L3 | -> +-------------------------+ 311 +-------------------------+ 312 +-------------------------+ 313 <- | ACK_SEGMENT | 314 <- | SDNV length [L1+L2+L3] | 315 +-------------------------+ 317 +-------------------------+ +-------------------------+ 318 | SHUTDOWN | -> <- | SHUTDOWN | 319 +-------------------------+ +-------------------------+ 321 Figure 2: A simple visual example of the flow of protocol messages on 322 a single TCP session between two nodes (A and B) 324 4. Connection Establishment 326 For bundle transmissions to occur using the TCPCL, a TCPCL connection 327 must first be established between communicating nodes. The manner in 328 which a bundle node makes the decision to establish such a connection 329 is implementation-dependent. For example, some connections may be 330 opened proactively and maintained for as long as is possible given 331 the network conditions, while other connections may be opened only 332 when there is a bundle that is queued for transmission and the 333 routing algorithm selects a certain next hop node. 335 To establish a TCPCL connection, a node must first establish a TCP 336 connection with the intended peer node, typically by using the 337 services provided by the operating system. Port number 4556 has been 338 assigned by IANA as the well-known port number for the TCP 339 convergence layer. Other port numbers MAY be used per local 340 configuration. Determining a peer's port number (if different from 341 the well-known TCPCL port) is up to the implementation. 343 If the node is unable to establish a TCP connection for any reason, 344 then it is an implementation matter to determine how to handle the 345 connection failure. A node MAY decide to re-attempt to establish the 346 connection, perhaps. If it does so, it MUST NOT overwhelm its target 347 with repeated connection attempts. Therefore, the node MUST retry 348 the connection setup only after some delay and it SHOULD use a 349 (binary) exponential backoff mechanism to increase this delay in case 350 of repeated failures. 352 The node MAY declare failure after one or more connection attempts 353 and MAY attempt to find an alternate route for bundle data. Such 354 decisions are up to the higher layer (i.e., the BP). 356 Once a TCP connection is established, each node MUST immediately 357 transmit a contact header over the TCP connection. The format of the 358 contact header is described in Section 4.1). 360 Upon receipt of the contact header, both nodes perform the validation 361 and negotiation procedures defined in Section 4.2 363 After receiving the contact header from the other node, either node 364 MAY also refuse the connection by sending a SHUTDOWN message. If 365 connection setup is refused a reason MUST be included in the SHUTDOWN 366 message. 368 4.1. Contact Header 370 Once a TCP connection is established, both parties exchange a contact 371 header. This section describes the format of the contact header and 372 the meaning of its fields. 374 The format for the Contact Header is as follows: 376 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 377 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 378 +---------------+---------------+---------------+---------------+ 379 | magic='dtn!' | 380 +---------------+---------------+---------------+---------------+ 381 | version | flags | keepalive_interval | 382 +---------------+---------------+---------------+---------------+ 383 | local EID length (SDNV) | 384 +---------------+---------------+---------------+---------------+ 385 | | 386 + local EID (variable) + 387 | | 388 +---------------+---------------+---------------+---------------+ 390 Figure 3: Contact Header Format 392 The fields of the contact header are: 394 magic: A four byte field that always contains the byte sequence 0x64 395 0x74 0x6e 0x21, i.e. the text string "dtn!". 397 version: A one byte field value containing the current version of 398 the protocol. 400 flags: A one byte field containing optional connection flags. The 401 first four bits are unused and MUST be set to zero upon 402 transmission and MUST be ignored upon reception. The last four 403 bits are interpreted as shown in table Table 1 below. 405 keepalive_interval: A two byte integer field containing the number 406 of seconds between exchanges of keepalive messages on the 407 connection (see Section 5.6). This value is in network byte 408 order, as are all other multi-byte fields described in this 409 protocol. 411 local eid length: A variable length SDNV field containing the length 412 of the endpoint identifier (EID) for some singleton endpoint in 413 which the sending node is a member. A four byte SDNV is 414 depicted for clarity of the figure. 416 local EID: An octet string containing the EID of some singleton 417 endpoint in which the sending node is a member, in the canonical 418 format of :. A eight byte 419 EID is shown the clarity of the figure. 421 +----------+--------------------------------------------------------+ 422 | Value | Meaning | 423 +----------+--------------------------------------------------------+ 424 | 00000001 | Request acknowledgment of bundle segments. | 425 | 00000010 | Request enabling of reactive fragmentation. | 426 | 00000100 | Indicate support for bundle refusal. This flag MUST | 427 | | NOT be set to '1' unless support for acknowledgments | 428 | | is also indicated. | 429 | 00001000 | Request sending of LENGTH messages. | 430 +----------+--------------------------------------------------------+ 432 Table 1: Contact Header Flags 434 The manner in which values are configured and chosen for the various 435 flags and parameters in the contact header is implementation 436 dependent. 438 4.2. Validation and parameter negotiation 440 Upon reception of the contact header, each node follows the following 441 procedures for ensuring the validity of the TCPCL connection and to 442 negotiate values for the connection parameters. 444 If the magic string is not present or is not valid, the connection 445 MUST be terminated. The intent of the magic string is to provide 446 some protection against an inadvertent TCP connection by a different 447 protocol than the one described in this document. To prevent a flood 448 of repeated connections from a misconfigured application, a node MAY 449 elect to hold an invalid connection open and idle for some time 450 before closing it. 452 If a node receives a contact header containing a version that is 453 greater than the current version of the protocol that the node 454 implements, then the node SHOULD interpret all fields and messages as 455 it would normally. If a node receives a contact header with a 456 version that is lower than the version of the protocol that the node 457 implements, the node may either terminate the connection due to the 458 version mismatch, or may adapt its operation to conform to the older 459 version of the protocol. This decision is an implementation matter. 461 A node calculates the parameters for a TCPCL connection by 462 negotiating the values from its own preferences (conveyed by the 463 contact header it sent) with the preferences of the peer node 464 (expressed in the contact header that it received). This negotiation 465 MUST proceed in the following manner: 467 The segment acknowledgments enabled parameter is set to true iff 468 the corresponding flag is set in both contact headers. 470 The reactive fragmentation enabled parameter is set to true iff 471 the corresponding flag is set in both contact headers. 473 The bundle refusal capability may only be used iff both peers 474 indicate support for it in their contact header. 476 The keepalive_interval parameter is set to the minimum value 477 from both contact headers. If one or both contact headers 478 contains the value zero, then the keepalive feature (described 479 in Section 5.6) is disabled. 481 Once this process of parameter negotiation is completed, the protocol 482 defines no additional mechanism to change the parameters of an 483 established connection; to effect such a change, the connection MUST 484 be terminated and a new connection established. 486 5. Established Connection Operation 488 This section describes the protocol operation for the duration of an 489 established connection, including the mechanisms for transmitting 490 bundles over the connection. 492 5.1. Message Type Codes 494 After the initial exchange of a contact header, all messages 495 transmitted over the connection are identified by a one octet header 496 with the following structure: 498 0 1 2 3 4 5 6 7 499 +-+-+-+-+-+-+-+-+ 500 | type | flags | 501 +-+-+-+-+-+-+-+-+ 503 type: Indicates the type of the message as per Table 2 below 505 flags: Optional flags defined on a per message type basis. 507 The types and values for the message type code are as follows. 509 +----------------+------+-------------------------------------------+ 510 | Type | Code | Comment | 511 +----------------+------+-------------------------------------------+ 512 | DATA_SEGMENT | 0x1 | Indicates the transmission of a segment | 513 | | | of bundle data, described in Section 5.2. | 514 | | | | 515 | ACK_SEGMENT | 0x2 | Acknowledges reception of a data segment, | 516 | | | described in Section 5.3 | 517 | | | | 518 | REFUSE_BUNDLE | 0x3 | Indicates that the transmission of the | 519 | | | current bundle shall be stopped, | 520 | | | described in Section 5.4. | 521 | | | | 522 | KEEPALIVE | 0x4 | Keepalive message for the connection, | 523 | | | described in Section 5.6. | 524 | | | | 525 | SHUTDOWN | 0x5 | Indicates that one of the nodes | 526 | | | participating in the connection wishes to | 527 | | | cleanly terminate the connection, | 528 | | | described in Section 6. | 529 | | | | 530 | LENGTH | 0x6 | Contains the length (in bytes) of the | 531 | | | next bundle, described in Section 5.5. | 532 | | | | 533 +----------------+------+-------------------------------------------+ 535 Table 2: TCPCL Header Types 537 5.2. Bundle Data Transmission 539 Each bundle is transmitted in one or more data segments. The format 540 of a data segment message follows: 542 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 543 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 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | 0x1 |0|0|S|E| length ... | contents.... | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Figure 4: Format of bundle data segment messages 550 The type portion of the message header contains the value 0x1. 552 The flags portion of the message header octet contains two optional 553 values in the two low-order bits, denoted 'S' and 'E' above. The 'S' 554 bit MUST be set to one iff it precedes the transmission of the first 555 segment of a new bundle. The 'E' bit MUST be set to one when 556 transmitting the last segment of a bundle. 558 Determining the size of the segment is an implementation matter. In 559 particular, a node may, based on local policy or configuration, only 560 ever transmit bundle data in a single segment, in which case both the 561 'S' and 'E' bits MUST be set to one. However, a node MUST be able to 562 receive a bundle that has been transmitted in any segment size. 564 In the bundle protocol specification, a single bundle comprises a 565 primary bundle block, a payload block, and zero or more additional 566 bundle blocks. The relationship between the protocol blocks and the 567 convergence layer segments is an implementation-specific decision. 568 In particular, a segment MAY contain more than one protocol block; 569 alternatively, a single protocol block (such as the payload) MAY be 570 split into multiple segments. 572 However, a single segment MUST NOT contain data of more than a single 573 bundle. 575 Once a transmission of a bundle has commenced, the node MUST only 576 send segments containing sequential portions of that bundle until it 577 sends a segment with the 'E' bit set. 579 Following the message header, the length field is an SDNV containing 580 the number of bytes of bundle data that are transmitted in this 581 segment. Following this length is the actual data contents. 583 5.3. Bundle Acknowledgments 585 Although the TCP transport provides reliable transfer of data between 586 transport peers, the typical BSD sockets interface provides no means 587 to inform a sending application of when the receiving application has 588 processed some amount of transmitted data. Thus after transmitting 589 some data, a bundle protocol agent needs an additional mechanism to 590 determine whether the receiving agent has successfully received the 591 segment. 593 To this end, the TCPCL protocol offers an optional feature whereby a 594 receiving node transmits acknowledgments of reception of data 595 segments. This feature is enabled if and only if during the exchange 596 of contact headers, both parties set the flag to indicate that 597 segment acknowledgments are enabled (see Section 4.1). If so, then 598 the receiver MUST transmit a bundle acknowledgment header when it 599 successfully receives each data segment. 601 The format of a bundle acknowledgment is as follows: 603 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 604 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 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | 0x2 |0|0|0|0| acknowledged length ... | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 Figure 5: Format of bundle acknowledgement messages 611 To transmit an acknowledgment, a node first transmits a message 612 header with the ACK_SEGMENT type code and all flags set to zero, then 613 transmits an SDNV containing the cumulative length of the received 614 segment(s) of the current bundle. The length MUST fall on a segment 615 boundary. That is, only full segments can be acknowledged. 617 For example, suppose the sending node transmits four segments of 618 bundle data with lengths 100, 200, 500, and 1000 respectively. After 619 receiving the first segment, the node sends an acknowledgment of 620 length 100. After the second segment is received, the node sends an 621 acknowledgment of length 300. The third and fourth acknowledgments 622 are of length 800 and 1800 respectively. 624 5.4. Bundle Refusal 626 As bundles may be large, the TCPCL supports an optional mechanisms by 627 which a receiving node may indicate to the sender that it does not 628 want to receive the corresponding bundle. 630 To do so, upon receiving a DATA_SEGMENT message, the node MAY 631 transmit a REFUSE_BUNDLE message. As data segments and 632 acknowledgments may cross on the wire, the bundle that is being 633 refused is implicitly identified by the sequence in which 634 acknowledgements and refusals are received. 636 The receiver MUST, for each bundle preceding the one to be refused, 637 have either acknowledged all DATA_SEGMENTs or refused the bundle. 638 This allows the sender to identify the bundles accepted and refused 639 by means of a simple FIFO list of segments and acknowledgments. 641 The bundle refusal MAY be sent before the entire data segment is 642 received. If a sender receives a REFUSE_BUNDLE message, the sender 643 MUST complete the transmission of any partially-sent DATA_SEGMENT 644 message (so that the receiver stays in sync). The sender MUST NOT 645 commence transmission of any further segments of the rejected bundle 646 subsequently. Note, however, that this requirement does not ensure 647 that a node will not receive another DATA_SEGMENT for the same bundle 648 after transmitting a REFUSE_BUNDLE message since messages may cross 649 on the wire; if this happens, subsequent segments of the bundle 650 SHOULD be refused with a REFUSE_BUNDLE message, too. 652 Note: If a bundle transmission if aborted in this way, the receiver 653 may not receive a segment with the 'E' flag set to '1' for the 654 aborted bundle. The beginning of the next bundle is identified by 655 the 'S' bit set to '1', indicating the start of a new bundle. 657 5.5. Bundle Length 659 The format of the LENGTH message is as follows: 661 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 662 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 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | 0x6 |0|0|0|0| total bundle length ... | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 Figure 6: Format of LENGTH messages 669 The LENGTH message contains the total length, in bytes, of the next 670 bundle, formatted as an SDNV. Its purpose is to allow nodes to 671 preemptively refuse bundles that would exceed their resources. It is 672 an optimization. 674 LENGTH messages MUST NOT be sent unless the corresponding flag bit is 675 set in the contact header. If the flag bit is set, LENGTH messages 676 MAY be sent, at the sender's discretion. LENGTH messages MUST NOT be 677 sent unless the next DATA_SEGMENT message has the S bit set to 1 678 (i.e., just before the start of a new bundle). 680 A receiver MAY send a BUNDLE_REFUSE message as soon as it receives a 681 LENGTH message, without waiting for the next DATA_SEGMENT message. 682 The receiver MUST be prepared for this and MUST associate the refusal 683 with the right bundle. 685 5.6. Keepalive Messages 687 The protocol includes a provision for transmission of keepalive 688 messages over the TCP connection to help determine if the connection 689 has been disrupted. 691 As described in Section 4.1, one of the parameters in the contact 692 header is the keepalive_interval. Both sides populate this field 693 with their requested intervals (in seconds) between keepalive 694 messages. 696 The format of a keepalive message is a one byte message type code of 697 KEEPALIVE (as described in Table 2, with no additional data. Both 698 sides SHOULD send a keepalive message whenever the negotiated 699 interval has elapsed with no transmission of any message (keepalive 700 or other). 702 If no message (keepalive or other) has been received for at least 703 twice the keepalive interval, then either party may terminate the 704 session by transmitting a one byte message type code of SHUTDOWN (as 705 described in Table 2) and closing the TCP connection. 707 Note: The keepalive interval should not be chosen too short as TCP 708 retransmissions may occur in case of packet loss. Those will have to 709 be triggered by a timeout (TCP RTO) which is dependent on the 710 measured RTT for the TCP connection so that keepalive message may 711 experience noticeable latency. 713 6. Connection Termination 715 This section describes the procedures for ending a TCPCL connection. 717 6.1. Shutdown Message 719 To cleanly shut down a connection, a SHUTDOWN message MUST be 720 transmitted by either node at any point following complete 721 transmission of any other message. In case acknowledgments have been 722 negotiated, it is advisable to acknowledge all received data segments 723 first and then shut down the connection. 725 The format of the shutdown message is as follows: 727 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 728 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 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | 0x5 |0|0|R|D| reason (opt) | reconnection delay (opt) | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 Figure 7: Format of bundle shutdown messages 735 It is possible for a node to convey additional information regarding 736 the reason for connection termination. To do so, the node MUST set 737 the 'R' bit in the message header flags, and transmit a one-byte 738 reason code immediately following the message header. The specified 739 values of the reason code are: 741 +------+-------------------+----------------------------------------+ 742 | Code | Meaning | Comment | 743 +------+-------------------+----------------------------------------+ 744 | 0x00 | Idle timeout | The connection is being closed due to | 745 | | | idleness. | 746 | | | | 747 | 0x01 | Version mismatch | The node cannot conform to the | 748 | | | specified TCPCL protocol version. | 749 | | | | 750 | 0x02 | Busy | The node is too busy to handle the | 751 | | | current connection. | 752 +------+-------------------+----------------------------------------+ 754 Table 3: Shutdown Reason Codes 756 It is also possible to convey a requested reconnection delay to 757 indicate how long the other node must wait before attempting 758 connection re-establishment. To do so, the node sets the 'D' bit in 759 the message header flags, then transmits an SDNV specifying the 760 requested delay, in seconds, following the message header (and 761 optionally the shutdown reason code). The value 0 SHALL be 762 interpreted as an infinite delay, i.e. that the connecting node MUST 763 NOT re-establish the connection. In contrast, if the node does not 764 wish to request a delay, it SHOULD omit the delay field (and set the 765 'D' bit to zero). Note that in the figure above, a two octet SDNV is 766 shown for convenience of the presentation. 768 A connection shutdown MAY occur immediately after TCP connection 769 establishment or reception of a contact header (and prior to any 770 further data exchange). This may, for example, be used to notify 771 that the node is currently not capable of or willing to communicate. 772 However, a node MUST always send the contact header to its peer 773 first. 775 If either node terminates a connection prematurely in this manner, it 776 SHOULD send a SHUTDOWN message and MUST indicate a reason code unless 777 the incoming connection did not include the magic string. If a node 778 does not want its peer to re-open the connection immediately, it 779 SHOULD set the 'D' bit in the flags and include a reconnection delay 780 to indicate when the peer is allowed to attempt another connection 781 setup. 783 If a connection is to be terminated before another protocol message 784 has completed, then the node MUST NOT transmit the SHUTDOWN message 785 but still SHOULD close the TCP connection. In particular, if the 786 connection is to be closed (for whatever reason) while a node is in 787 the process of transmitting a bundle data segment, receiving node is 788 still expecting segment data and might erroneously interpret the 789 SHUTDOWN message to be part of the data segment. 791 6.2. Idle Connection Shutdown 793 The protocol includes a provision for clean shutdown of idle TCP 794 connections. Determining the length of time to wait before closing 795 idle connections, if they are to be closed at all, is an 796 implementation and configuration matter. 798 If there is a configured time to close idle links, then if no bundle 799 data (other than keepalive messages) has been received for at least 800 that amount of time, then either node MAY terminate the connection by 801 transmitting a SHUTDOWN message indicating the reason code of 'idle 802 timeout' (as described above). After receiving a SHUTDOWN message in 803 response, both sides may close the TCP connection. 805 7. Requirements notation 807 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 808 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 809 document are to be interpreted as described in [RFC2119]. 811 8. Security Considerations 813 One security consideration for this protocol relates to the fact that 814 nodes present their endpoint identifier as part of the connection 815 header exchange. It would be possible for a node to fake this value 816 and present the identity of a singleton endpoint in which the node is 817 not a member, essentially masquerading as another DTN node. If this 818 identifier is used without further verification as a means to 819 determine which bundles are transmitted over the connection, then the 820 node that has falsified its identity may be able to obtain bundles 821 that it should not have. 823 These concerns may be mitigated through the use of the Bundle 824 Security Protocols [refs.dtnsecurity]. In particular, the Bundle 825 Authentication Header defines mechanism for secure exchange of 826 bundles between DTN nodes. Thus an implementation could delay 827 trusting the presented endpoint identifier until the node can 828 securely validate that its peer is in fact the only member of the 829 given singleton endpoint. 831 Another consideration for this protocol relates to denial of service 832 attacks. A node may send a large amount of data over a TCP 833 connection, requiring the receiving node to either handle the data, 834 attempt to stop the flood of data by sending a REFUSE_BUNDLE message, 835 or forcibly terminate the connection. This burden could cause denial 836 of service on other, well-behaving connections. There is also 837 nothing to prevent a malicious node from continually establishing 838 connections and repeatedly trying to send copious amounts of bundle 839 data. 841 9. IANA Considerations 843 Port number 4556 has been assigned as the default port for the TCP 844 convergence layer. 846 10. References 848 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 849 Requirement Levels", RFC 2119, March 1997. 851 [refs.bundleproto] 852 Scott, K. and S. Burleigh, "Bundle Protocol 853 Specification", RFC 5050, November 2007. 855 [refs.dtnarch] 856 Cerf et al, V., "Delay-Tolerant Network Architecture", 857 RFC 4838, April 2007. 859 [refs.dtnimpl] 860 DTNRG, "Delay Tolerant Networking Reference 861 Implementation", . 863 [refs.dtnsecurity] 864 Symington, S., Farrell, S., and H. Weiss, "Bundle Security 865 Protocol Specification", Internet Draft, work in 866 progress draft-irtf-dtnrg-bundle-security-03.txt, 867 April 2007. 869 Authors' Addresses 871 Michael J. Demmer 872 University of California, Berkeley 873 Computer Science Division 874 445 Soda Hall 875 Berkeley, CA 94720-1776 876 US 878 Email: demmer@cs.berkeley.edu 879 Joerg Ott 880 Helsinki University of Technology 881 Department of Communications and Networking 882 PO Box 3000 883 TKK 02015 884 Finland 886 Email: jo@netlab.tkk.fi 888 Simon Perreault 889 Viagenie 890 246 Aberdeen 891 Quebec, QC G1R 2E1 892 Canada 894 Phone: +1 418 656 9254 895 Email: simon.perreault@viagenie.ca