idnits 2.17.1 draft-demmer-dtnrg-tcp-clayer-00.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 on line 856. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 867. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 874. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 880. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (October 16, 2006) is 6402 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'L1' on line 306 -- Looks like a reference, but probably isn't: 'L2' on line 306 -- Looks like a reference, but probably isn't: 'L3' on line 311 == Outdated reference: A later version (-08) exists of draft-irtf-dtnrg-arch-06 == Outdated reference: A later version (-19) exists of draft-irtf-dtnrg-bundle-security-02 == Outdated reference: A later version (-19) exists of draft-irtf-dtnrg-bundle-security-02 -- Duplicate reference: draft-irtf-dtnrg-bundle-security, mentioned in '4', was also mentioned in '3'. Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Delay Tolerant Networking Research Group M. Demmer 3 UC Berkeley 4 Internet-Draft J. Ott 5 Intended status: Experimental Helsinki University of Technology 6 Expires: April 19, 2007 October 16, 2006 8 Delay Tolerant Networking TCP Convergence Layer Protocol 9 draft-demmer-dtnrg-tcp-clayer-00.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 April 19, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . 13 59 5.3. Bundle Acknowledgements . . . . . . . . . . . . . . . . . 14 60 5.4. Bundle Refusal . . . . . . . . . . . . . . . . . . . . . . 15 61 5.5. Keepalive Messages . . . . . . . . . . . . . . . . . . . . 15 62 6. Connection Termination . . . . . . . . . . . . . . . . . . . . 16 63 6.1. Shutdown Message . . . . . . . . . . . . . . . . . . . . . 16 64 6.2. Idle Connection Shutdown . . . . . . . . . . . . . . . . . 17 65 7. Requirements notation . . . . . . . . . . . . . . . . . . . . 18 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 70 Intellectual Property and Copyright Statements . . . . . . . . . . 20 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 accomodate 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 Figure 1. In particular, both the BP and 96 the 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 and teardown. The general operation of the protocol is as 223 follows: 225 First one node establishes a connection to the other by initiating a 226 TCP connection. At the beginning of the connection, an initial 227 contact header is exchanged in both directions to set parameters of 228 the connection and exchange a singleton endpoint identifier for each 229 node, to denote the bundle-layer identity of each DTN node. 231 Once the connection is established, bundles can be transmitted in 232 either direction. Each bundle is transmitted in one or more logical 233 segments of formatted bundle data. Each logical data segment 234 consists of a DATA_SEGMENT message header, an SDNV containing the 235 length of the segment, and finally the byte range of the bundle data. 236 The choice of the length to use for segments is an implementation 237 manner. The first segment for a bundle must set the 'start' flag and 238 the last must set the 'end' flag in the DATA_SEGMENT message header. 240 An optional feature of the protocol is for the receiving node to send 241 acknowledgements as bundle data segments arrive (ACK_SEGMENT). The 242 rationale behind these acknowledgements is to enable the sender node 243 to determine how much of the bundle has been received, so that in 244 case the connection is interrupted, it can perform reactive 245 fragmentation to avoid re-sending the already transmitted part of the 246 bundle. 248 When acknowledgements are enabled, then for each data segment that is 249 received, the receiving node sends an ACK_SEGMENT code followed by an 250 SDNV containing the cumulative length of the bundle that has been 251 received. Note that in the case of concurrent bidirectional 252 transmission, then ack segments may be interleaved with data 253 segments. 255 Another optional feature is that a receiver may interrupt the 256 transmission of a bundle at any point in time by replying with a 257 negative acknowledgement (REFUSE_BUNDLE) which causes the sender to 258 stop transmission of the current bundle, after completing 259 transmission of all partially sent data segments. Note: This allows 260 a receiver that detects it already has received a certain bundle to 261 interrupt transmission as early as possible and thus save 262 transmission capacity 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 acknowledgements (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. 290 No errors or rejections are shown in this example. 292 Node A Node B 293 ====== ====== 295 +-------------------------+ +-------------------------+ 296 | Contact Header | -> <- | Contact Header | 297 +-------------------------+ +-------------------------+ 299 +-------------------------+ 300 | DATA_SEGMENT (start) | -> 301 | SDNV length [L1] | -> 302 | Bundle Data 0..L1 | -> 303 +-------------------------+ 304 +-------------------------+ +-------------------------+ 305 | DATA_SEGMENT | -> <- | ACK_SEGMENT | 306 | SDNV length [L2] | -> <- | SDNV length [L1] | 307 | Bundle Data L1..L2 | -> +-------------------------+ 308 +-------------------------+ 309 +-------------------------+ +-------------------------+ 310 | DATA_SEGMENT (end) | -> <- | ACK_SEGMENT | 311 | SDNV length [L3] | -> <- | SDNV length [L1+L2] | 312 | Bundle Data L2..L3 | -> +-------------------------+ 313 +-------------------------+ 314 +-------------------------+ 315 <- | ACK_SEGMENT | 316 <- | SDNV length [L1+L2+L3] | 317 +-------------------------+ 319 +-------------------------+ +-------------------------+ 320 | SHUTDOWN | -> <- | SHUTDOWN | 321 +-------------------------+ +-------------------------+ 323 Figure 2: A simple visual example of the flow of protocol messages on 324 a single TCP session between two nodes (A and B) 326 4. Connection Establishment 328 For bundle transmissions to occur using the TCPCL, a connection must 329 first be established between communicating nodes. The manner in 330 which a bundle node makes the decision to establish such a connection 331 is implementation dependant. For example, some connections may be 332 opened proactively and maintained for as long as is possible given 333 the network conditions, while other connections may be opened only 334 when there is a bundle that is queued for transmission and the 335 routing algorithm selects a certain next hop node. 337 To establish a TCPCL connection, a node must first establish a TCP 338 connection with the intended peer node, typically by using the 339 services provided by the operating system. If the node is unable to 340 establish a TCP connection for any reason, then it is an 341 implementation manner to determine how to handle the failed 342 connection. For example, a node may decide to re-attempt to 343 establish the connection, perhaps after some delay or it may attempt 344 to find an alternate route for bundle data. 346 Note: If a node re-attempts a connection establishment, it SHOULD 347 ensure that it does not overwhelm its target with repeated connection 348 setup attempts and SHOULD use a (binary) exponential backoff to 349 determine the timeout after which to retry. 351 Once a TCP connection is established, the connection initiator MUST 352 immediately transmit a contact header over the TCP connection. The 353 connection acceptor MUST also immediately transmit a contact header 354 over the TCP connection. The format of the contact header is 355 described in Section 4.1). 357 Upon receipt of the contact header, both nodes perform the validation 358 and negotiation procedures defined in Section 4.2 360 After receiving the contact header from the other node, either node 361 MAY also refuse the connection by sending a SHUTDOWN message. If 362 connection setup is refused a reason MUST be included in the SHUTDOWN 363 message. 365 4.1. Contact Header 367 Once a TCP connection is established, both parties exchange a contact 368 header. This section describes the format of the contact header and 369 the meaning of its fields. 371 The format for the Contact Header is as follows: 373 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 374 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 375 +---------------+---------------+---------------+---------------+ 376 | magic='dtn!' | 377 +---------------+---------------+---------------+---------------+ 378 | version | flags | keepalive_interval | 379 +---------------+---------------+---------------+---------------+ 380 | local eid length (SDNV) | 381 +---------------+---------------+---------------+---------------+ 382 | local eid (variable) | 383 +---------------+---------------+---------------+---------------+ 385 Figure 3: Contact Header Format 387 The fields of the contact header are: 389 magic: A four byte field that always contains the byte sequence 0x64 390 0x76 0x6e 0x21, i.e. the ASCII string "dtn!". 392 version: A one byte field value containing the current version of 393 the protocol. 395 flags: A one byte field containing optional connection flags. The 396 first five bits are unused and must be set to zero. The last 397 three bits are interpreted as follows: 399 keepalive_interval: A two byte integer field containing the number 400 of seconds between exchanges of keepalive messages on the 401 connection (see Section 5.5). This value is in network byte 402 order, as are all other multi-byte fields described in this 403 protocol. 405 local eid length: A variable length SDNV field containing the length 406 of the endpoint identifier (EID) for some singleton endpoint in 407 which the sending node is a member. A four byte SDNV is 408 depicted for clarity of the figure. 410 local eid: An octet string containing the EID of some singleton 411 endpoint in which the sending node is a member, in the canonical 412 format of :. A four byte EID 413 is shown the clarity of the figure. 415 +----------+--------------------------------------------------------+ 416 | Value | Meaning | 417 +----------+--------------------------------------------------------+ 418 | 00000001 | Request acknowledgement of bundle segments. | 419 | 00000010 | Request enabling of reactive fragmentation. | 420 | 00000100 | Indicate support for negative acknowledgements. This | 421 | | flags MUST NOT be used unless support for | 422 | | acknowledgements is also indicated. | 423 +----------+--------------------------------------------------------+ 425 Table 1: Contact Header Flags 427 The manner in which values are configured and chosen for the various 428 flags and parameters in the contact header is implementation 429 dependent. 431 4.2. Validation and parameter negotiation 433 Upon reception of the contact header, both the connection initiator 434 and the connection acceptor follow the following procedures for 435 ensuring the validity of the connection and to negotiate values for 436 the connection parameters. 438 If the magic string is not present or is not valid, the connection 439 MUST be terminated. The intent of the magic string is to provide a 440 some protection against an inadvertent TCP connection by a different 441 protocol than the one described in this document. To prevent a flood 442 of repeated connections from a misconfigured application, a node MAY 443 elect to hold an invalid connection open and idle for some time 444 before closing it. 446 If a node receives a contact header containing a version that is 447 greater than the current version of the protocol that the node 448 implements, then the node SHOULD interpret all fields and messages as 449 it would normally. If a node receives a contact header with a 450 version that is lower than the version of the protocol that the node 451 implements, the node may either terminate the connection due to the 452 version mismatch, or may adapt its operation to conform to the older 453 version of the protocol. This decision is an implementation manner. 455 A node calculates the parameters for a connection by negotiating the 456 values from its own preferences (conveyed by the contact header it 457 sent) with the preferences of the peer node (expressed in the contact 458 header that it received). This negotiation should proceed in the 459 following manner: 461 The segment acknowledgements enabled parameter is set to true 462 iff the corresponding flag is set in both contact headers. 464 The reactive fragmentation enabled parameter is set to true iff 465 the corresponding flag is set in both contact headers. 467 Negative acknowledgements to interrupt transmission (actually: 468 refuse reception) of a bundle may only be used iff both peers 469 indicate support for negative acknowledements in their contact 470 header. 472 The keealive_interval parameter should be set to the minimum 473 value from both contact headers. If one or both contact headers 474 contains the value zero, then the keepalive feature (described 475 in Section 5.5) is disabled. 477 Once this process of parameter negotiation is completed, the protocol 478 defines no additional mechanism to change the parameters of an 479 established connection; to effect such a change, the connection MUST 480 be terminated and a new connection established. 482 5. Established Connection Operation 484 This section describes the protocol operation for the duration of an 485 established connection, including the mechanisms for transmitting 486 bundles over the connection. 488 5.1. Message Type Codes 490 After the initial exchange of a contact header, all messages 491 transmitted over the connection are denoted by a one octet header 492 with the following structure: 494 0 1 2 3 4 5 6 7 495 +-+-+-+-+-+-+-+-+ 496 | type | flags | 497 +-+-+-+-+-+-+-+-+ 499 type: Indicates the type of the message as per Table 2 below 501 flags: Optional flags defined on a per message type basis. 503 The types and values for the message type code are as follows. 505 +----------------+------+-------------------------------------------+ 506 | Type | Code | Comment | 507 +----------------+------+-------------------------------------------+ 508 | DATA_SEGMENT | 0x1 | Indicates the transmission of a segment | 509 | | | of bundle data, described in Section 5.2. | 510 | | | | 511 | ACK_SEGMENT | 0x2 | Acknowledges reception of a data segment, | 512 | | | described in Section 5.3 | 513 | | | | 514 | REFUSE_BUNDLE | 0x3 | Indicates that the transmission of the | 515 | | | current bundle shall be stopped, | 516 | | | decscribed in Section 5.4. | 517 | | | | 518 | KEEPALIVE | 0x4 | Keepalive message for the connection, | 519 | | | described in Section 5.5. | 520 | | | | 521 | SHUTDOWN | 0x5 | Indicates that one of the nodes | 522 | | | participating in the connection wishes to | 523 | | | cleanly terminate the connection, | 524 | | | described in Section 6. | 525 | | | | 526 +----------------+------+-------------------------------------------+ 528 Table 2: TCPCL Header Types 530 Open Issue: Currently, the message code implicitly identifies the 531 expected message length, possibly in combination with some flags. 532 This may limit backwards compatible extensibility: an "old" endpoint 533 may not know about a "new" message code or extension flag and hence 534 may not be able to skip the unknown (part of the) message, even 535 though it would otherwise be perfectly capable of interoperating (at 536 reduced functionality). Therefore, we may want to consider providing 537 an explicit length indication if the message length is more than a 538 single octet. Options include: (a) always including a length field, 539 (b) using one bit of the flags to indicate whether or not length 540 field is present (which then would be the case for all messages of 541 more than one byte length), and (c) relying on a new version number 542 for all extensions. 544 5.2. Bundle Data Transmission 546 Each bundle is transmitted in one or more data segments. The format 547 of a data segment message is as follows: 549 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 550 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 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | 0x1 |0|0|S|E| length ... | contents.... | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 The type portion of the message header contains the value 0x1. 557 The flags portion of the message header octet contains two optional 558 values in the two low-order bits, denoted 'S' and 'E' above. The 'S' 559 bit MUST be set to one iff it precedes the transmission of the first 560 segment of a new bundle. The 'E' bit MUST be set to one when 561 transmitting the last segment of a bundle. 563 Determining the segment size is an implementation manner. In 564 particular, a node may, based on local policy or configuration, only 565 ever transmit bundle data in a single segment, in which case both the 566 'S' and 'E' bits MUST be set to one. However a node must be able to 567 receive a bundle that has been tranmsmitted in any segment size. 569 In the bundle protocol specification, a single bundle comprises of a 570 primary bundle block, a payload block, and zero or more additional 571 bundle blocks. The relationship between the protocol blocks and the 572 convergence layer segments is an implementation-specific decision. 573 In particular, a segment may contain more than one protocol block; 574 alternatively, a single protocol block (such as the payload) may be 575 split into multiple segments. 577 Once a transmission of a bundle has commenced, the node MUST only 578 send segments containing sequential portions of that bundle until it 579 sends a segment with the 'E' bit set. 581 Following the message header, the length field is an SDNV containing 582 the number of bytes of bundle data that are transmitted in this 583 segment. Following this length is the actual data contents. 585 5.3. Bundle Acknowledgements 587 Although the TCP transport provides reliable transfer of data between 588 hosts, the typical BSD sockets interface provides no means to inform 589 a sending application of when the receiving application has processed 590 some amount of transmitted data. Thus after transmitting some data, 591 a bundle protocol agent needs an additional mechanism to determine 592 whether the receiving agent has successfully received the segment. 594 To this end, the TCPCL protocol offers an optional feature whereby a 595 receiving node transmits acknowledgements of reception of data 596 segments. This feature is enabled if and only if during the exchange 597 of contact headers, both parties set the flag to indicate that 598 segment acknowledgements are enabled (see Section 4.1). If so, then 599 the receiver must transmit a bundle acknowledgement header when it 600 successfully receives each data segment. 602 The format of a bundle acknowledgement is: 604 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 605 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 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | 0x2 |0|0|0|0| acknowledged length ... | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 To transmit an acknowledgement, a node first transmits a message 611 header with the ACK_SEGMENT type code and all flags set to zero, then 612 transmits an SDNV containing the cumulative length of the received 613 segment(s) of the current bundle. For example, suppose the sending 614 node transmits four segments of bundle data with lengths 100, 200, 615 500, and 1000 respectively. After receiving the first segment, the 616 node sends an acknowledgement of length 100. After the second 617 segment is received, the node sends an acknowledgement of length 300. 618 The third and fourth acknowledgements are of length 800 and 1800 619 respectively. 621 5.4. Bundle Refusal 623 As bundles may be large, the TCPCL supports an optional mechanisms by 624 which a receiving node may indicate to the sender that it does not 625 want to receive the corresponding bundle. 627 To do so, upon receiving a DATA_SEGMENT message, the node may 628 transmit a REFUSE_BUNDLE message. As data segments and 629 acknowledgements may cross on the wire, the data segment (and thus 630 the bundle) that is being refused is implicitly identified by the 631 sequence in which positive and negative acknowledgements are 632 received. 634 The receiver MUST have acknowledged (positively or negatively) all 635 other received DATA_SEGMENTs before the one to be refused so that the 636 sender can identify the bundles accepted and refused by means of a 637 simple FIFO list of segments and acknowledgments. 639 The bundle refusal MAY be sent before the entire data segment is 640 received. If a sender receives a REFUSE_BUNDLE message, the sender 641 MUST complete the transmission of any partially-sent DATA_SEGMENT 642 message (so that the receiver stays in sync). The sender MUST NOT 643 commence transmission of any further segments of the rejected bundle 644 subsequently. Note, however, that this requirement does not ensure 645 that a node will not receive another DATA_SEGMENT for the same bundle 646 after transmitting a REFUSE_BUNDLE message since messages may cross 647 on the wire; if this happens, subsequent segments of the bundle 648 SHOULD be refused with a REFUSE_BUNDLE message, too. 650 5.5. Keepalive Messages 652 The protocol includes a provision for transmission of keepalive 653 messages over the TCP connection to help determine if the connection 654 has been disrupted. 656 As described in Section 4.1, one of the parameters in the contact 657 header is the keepalive_interval. Both sides populate this field 658 with their requested intervals (in seconds) between keepalive 659 messages. 661 The format of a keepalive message is a one byte message type code of 662 KEEPALIVE (as described in Table 2, with no additional data. Both 663 sides should send a keepalive message whenever the negotiated 664 interval has elapsed with no transmission of any message (keepalive 665 or other). 667 If no message (keepalive or other) has been received for at least 668 twice the keepalive interval, then either party may terminate the 669 session by transmitting a one byte message type code of SHUTDOWN (as 670 described in Table 2) and closing the TCP connection. 672 6. Connection Termination 674 This section describes the procedures for ending a TCPCL connection. 676 6.1. Shutdown Message 678 To cleanly shut down a connection, a SHUTDOWN message can be 679 transmitted by either the initiator or the acceptor at any point 680 following complete transmission of any other message. In case 681 acknowledgements have been negotiated, it is advisable to acknowledge 682 all received data segments first and then shut down the connection. 684 The format of the shutdown message is as follows: 686 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | 0x3 |0|0|R|D| reason (opt) | reconnection delay (opt) | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 It is possible for a node to convey additional information regarding 693 the reason for connection termination. To do so, the node sets the 694 'R' bit in the message header flags, and transmits a one-byte reason 695 code immediately following the message header. The specified values 696 of the reason code are: 698 +------+-------------------+----------------------------------------+ 699 | Code | Meaning | Comment | 700 +------+-------------------+----------------------------------------+ 701 | 0x00 | Idle timeout | The connection is being closed due to | 702 | | | idleness. | 703 | | | | 704 | 0x01 | Version mismatch | The node cannot conform to the | 705 | | | specified TCPCL protocol version. | 706 | | | | 707 | 0x02 | Busy | The node is too busy to handle the | 708 | | | current connection. | 709 +------+-------------------+----------------------------------------+ 710 Table 3: Shutdown Reason Codes 712 It is also possible to convey a requested reconnection delay to 713 indicate how long the other node must wait before attempting 714 connection re-establishment. To do so, the node sets the 'D' bit in 715 the message header flags, then transmits an SDNV specifying the 716 requested delay, in seconds, following the message header (and 717 optionally the shutdown reason code). The value 0 shall be 718 interpreted as an infinite delay, i.e. that the node should not ever 719 re-establish the connection. In contrast, if the node does not wish 720 to request a delay, it should omit the delay field (and set the 'D' 721 bit to zero). Note that in the figure above, a two octet SDNV is 722 shown for convenience in representation. 724 A connection shutdown MAY occur immediately after TCP connection 725 establishment or reception of a contact header (and prior to any 726 further data exchange). This may, for example, be used to notify a 727 the initiator that the node is currenly not capable of or willing to 728 communicate. Note, however, that a node MUST always send the contact 729 header to its peer first. 731 If either node terminates a connection prematurely in this manner, it 732 SHOULD send a SHUTDOWN message and MUST indicate a reason code unless 733 the incoming connection did not include the magic string. If a node 734 does not want its peer to re-open the connection immediately, it 735 SHOULD set the 'D' bit in the flags and include a reconnection delay 736 to indicate when the peer is allowed to attempt another connection 737 setup. 739 If a connection is terminated before another protocol message has 740 completed, then the node must not transmit the SHUTDOWN message but 741 still should close the TCP connection. In particular, if the 742 connection is interrupted while a node is in the process of 743 transmitting a bundle data segment, then the node may identify that 744 the connection should be terminated before it has completed the 745 transmission of the data segment. Thus were the node to transmit the 746 SHUTDOWN message, the receiving node might erroneously interpret the 747 SHUTDOWN message to be part of the data segment. 749 6.2. Idle Connection Shutdown 751 The protocol includes a provision for clean shutdown of idle TCP 752 connections. Determining the length of time to wait before closing 753 idle connections, if they are to be closed at all, is an 754 implementation and configuration matter. 756 If there is a configured time to close idle links, then if no bundle 757 data (other than keepalive messages) has been received for at least 758 that amount of time, then either node may terminate the connection by 759 transmitting a SHUTDOWN message indicating the reason code of 'idle 760 timeout' (as described above). After receiving a SHUTDOWN message in 761 response, both sides may close the TCP connection. 763 7. Requirements notation 765 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 766 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 767 document are to be interpreted as described in [1]. 769 8. Security Considerations 771 One security consideration for this protocol relates to the fact that 772 nodes present their endpoint identifier as part of the connection 773 header exchange. It would be possible for a node to fake this value 774 and present the identity of a singleton endpoint in which the node is 775 not a member, essentially masquerading as another DTN node. If this 776 identifier is used without further verification as a means to 777 determine which bundles are transmitted over the connection, then the 778 node that has falsified its identity may be able to obtain bundles 779 that it should not have. 781 These concerns may be mitigated through the use of the Bundle 782 Security Protocols [4]. In particular, the Bundle Authentication 783 Header defines mechanism for secure exchange of bundles between DTN 784 nodes. Thus an implementation could delay trusting the presented 785 endpoint identifier until the node can securely validate that its 786 peer is in fact the only member of the given singleton endpoint. 788 Another consideration for this protocol relates to denial of service 789 attacks. A node may send a large amount of data over a TCP 790 connection, requiring the receiving node to either handle the data, 791 attempt to stop the flood of data by sending a REFUSE_BUNDLE message, 792 or forcibly terminate the connection. This burden could cause denial 793 of service on other, well-behaving connections. There is also 794 nothing to prevent a malicious node from continually establishing 795 connections and repeatedly trying to send copious amounts of bundle 796 data. 798 9. IANA Considerations 800 There should be a well-known TCP port assignment for this protocol. 802 10. References 804 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 805 Levels", RFC 2119, March 1997. 807 [2] Cerf et al, V., "Delay-Tolerant Network Architecture", work in 808 progress, Internet Draft draft-irtf-dtnrg-arch-06.txt, 809 September 2006. 811 [3] Scott, K. and S. Burleigh, "Bundle Protocol Specification", work 812 in progress, Internet Draft 813 draft-irtf-dtnrg-bundle-security-02.txt, August 2006. 815 [4] Symington, S., Farrell, S., and H. Weiss, "Bundle Security 816 Protocol Specification", work in progress, Internet 817 Draft draft-irtf-dtnrg-bundle-security-02.txt, October 2006. 819 [5] DTNRG, "Delay Tolerant Networking Reference Implementation", 820 . 822 Authors' Addresses 824 Michael J. Demmer 825 University of California, Berkeley 826 Computer Science Division 827 445 Soda Hall 828 Berkeley, CA 94720-1776 829 US 831 Email: demmer@cs.berkeley.edu 833 Joerg Ott 834 Helsinki University of Technology 835 Networking Laboratory 836 PO Box 3000 837 TKK 02015 838 Finland 840 Email: jo@netlab.tkk.fi 842 Full Copyright Statement 844 Copyright (C) The Internet Society (2006). 846 This document is subject to the rights, licenses and restrictions 847 contained in BCP 78, and except as set forth therein, the authors 848 retain all their rights. 850 This document and the information contained herein are provided on an 851 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 852 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 853 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 854 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 855 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 856 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 858 Intellectual Property 860 The IETF takes no position regarding the validity or scope of any 861 Intellectual Property Rights or other rights that might be claimed to 862 pertain to the implementation or use of the technology described in 863 this document or the extent to which any license under such rights 864 might or might not be available; nor does it represent that it has 865 made any independent effort to identify any such rights. Information 866 on the procedures with respect to rights in RFC documents can be 867 found in BCP 78 and BCP 79. 869 Copies of IPR disclosures made to the IETF Secretariat and any 870 assurances of licenses to be made available, or the result of an 871 attempt made to obtain a general license or permission for the use of 872 such proprietary rights by implementers or users of this 873 specification can be obtained from the IETF on-line IPR repository at 874 http://www.ietf.org/ipr. 876 The IETF invites any interested party to bring to its attention any 877 copyrights, patents or patent applications, or other proprietary 878 rights that may cover technology that may be required to implement 879 this standard. Please address the information to the IETF at 880 ietf-ipr@ietf.org. 882 Acknowledgment 884 Funding for the RFC Editor function is provided by the IETF 885 Administrative Support Activity (IASA).