idnits 2.17.1 draft-irtf-dtnrg-dgram-clayer-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 17, 2013) is 3843 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC0791' is defined on line 399, but no explicit reference was found in the text == Unused Reference: 'RFC1883' is defined on line 402, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 2147 (Obsoleted by RFC 2675) == Outdated reference: A later version (-09) exists of draft-irtf-dtnrg-tcp-clayer-05 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 2309 (Obsoleted by RFC 7567) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DTNRG H. Kruse 3 Internet-Draft S. Jero 4 Intended status: Experimental S. Ostermann 5 Expires: April 20, 2014 Ohio University 6 October 17, 2013 8 Datagram Convergence Layers for the DTN Bundle and LTP Protocols 9 draft-irtf-dtnrg-dgram-clayer-05 11 Abstract 13 This document is a product of the Delay- and Distruption-Tolerant 14 Networking Research Group (DTNRG), and represents the consensus of 15 the DTNRG. It specifies the preferred method for transporting Delay- 16 and Disruption-Tolerant Networking (DTN) protocol data over the 17 Internet using datagrams. The specification covers convergence 18 layers for the Bundle Protocol (RFC 5050) as well as the 19 transportation of Licklider Transmission Protocol (LTP) (RFC 5326) 20 segments. UDP and the Datagram Congestion Control Protocol (DCCP) 21 are the candidate datagram protocols discussed. UDP can only be used 22 on a local network, or in cases where the DTN node implements 23 explicit congestion control. DCCP addresses the congestion control 24 problem, and its use is recommended whenever possible. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 20, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 62 2. General Recommendation . . . . . . . . . . . . . . . . . . . 4 63 3. Recommendations for Implementers . . . . . . . . . . . . . . 5 64 3.1. How and Where to Deal with Fragmentation . . . . . . . . 6 65 3.1.1. DCCP . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.2. Bundle Protocol over a Datagram Convergence Layer . . . . 6 68 3.2.1. DCCP . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.2.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 3.3. LTP over Datagrams . . . . . . . . . . . . . . . . . . . 7 71 3.3.1. DCCP . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3.3.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.4. Keep Alive Option . . . . . . . . . . . . . . . . . . . . 7 74 3.5. Checksums . . . . . . . . . . . . . . . . . . . . . . . . 8 75 3.5.1. DCCP . . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.5.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 3.6. DCCP Congestion Control Modules . . . . . . . . . . . . . 8 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 82 6.2. Informative References . . . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 DTN communication protocols include the Bundle Protocol described in 88 RFC 5050 [RFC5050], which provides transmission of application data 89 blocks (Bundles) through optional intermediate custody transfer, and 90 the Licklider Transmission Protocol (LTP), RFCs 5325 (LTP Motivation) 91 [RFC5325], 5326 (LTP Specification) [RFC5326], and 5327 (LTP 92 Security) [RFC5327] which can be used to transmit Bundles reliably 93 and efficiently over a point to point link. It is often desirable to 94 test these protocols over Internet Protocol links. draft-irtf-dtnrg- 95 tcp-clayer [I-D.irtf-dtnrg-tcp-clayer] defines a method for 96 transporting Bundles over TCP. This draft specifies the preferred 97 method for transmitting either Bundles or LTP blocks across the 98 Internet using datagrams in place of TCP. Figure 1 shows the general 99 protocol layering described in the DTN documents. DTN Applications 100 interact with the Bundle Protocol Layer, which in turn uses a 101 Convergence Layer to prepare a bundle for transmission. The 102 Convergence Layer will typically rely on a lower level protocol to 103 carry out the transmission. 105 +-----------------------------------------+ 106 | | 107 | DTN Application | 108 | | 109 +-----------------------------------------+ 110 +-----------------------------------------+ 111 | | 112 | Bundle Protocol (BP) | 113 | | 114 +-----------------------------------------+ 115 +-----------------------------------------+ 116 | | 117 | Convergence Layer Adapter (CL) | 118 | | 119 +-----------------------------------------+ 120 +-----------------------------------------+ 121 | | 122 | Local Data Link Layer (Transport) | 123 | | 124 +-----------------------------------------+ 126 Figure 1: Generic Protocol Stack for DTN 128 This document provides guidance for implementation of the two 129 protocol stacks illustrated in figure 2. In figure 2(a) the 130 Convergence Layer Adapater is UDP or DCCP for direct transport of 131 Bundles over the Internet. In figure 2(b) the Convergence Layer 132 Adapter is LTP, which then uses UDP or DCCP as the local data link 133 layer. 135 +-------------+ +-------------+ 136 | | | | 137 | DTN App | | DTN App | 138 | | | | 139 +-------------+ +-------------+ 140 +-------------+ +-------------+ 141 | | | | 142 | BP | | BP | 143 | | | | 144 +-------------+ +-------------+ 145 +-------------+ +-------------+ 146 | | | | 147 | UDP/DCCP | | LTP | 148 | | | | 149 +-------------+ +-------------+ 150 +-------------+ 151 | | 152 | UDP/DCCP | 153 | | 154 +-------------+ 156 (a) (b) 158 Figure 2: Protocol Stacks Addressed in this Document 160 1.1. Requirements Language 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in RFC 2119 [RFC2119]. 166 2. General Recommendation 168 In order to utilize DTN protocols across the Internet, whether for 169 testing purposes or as part of a larger network path, it is necessary 170 to encapsulate them into a standard Internet protocol so that they 171 travel easily across the Internet. This is particularly true for 172 LTP, which provides no endpoint addressing. This encapsulation 173 choice needs to be made carefully in order to avoid redundancy, since 174 DTN protocols may provide their own reliability mechanisms. 176 Congestion control is vital to the continued functioning of the 177 Internet, particularly for situations where data will be sent at 178 arbitrarily fast data rates. The Bundle Protocol delegates provision 179 of reliable delivery and, implicitly, congestion control to the 180 convergence layer used (Section 7.2 of RFC 5050 [RFC5050]). In 181 situations where TCP will work effectively in communications between 182 pairs of DTN nodes, use of the TCP convergence layer draft-irtf- 183 dtnrg-tcp-clayer [I-D.irtf-dtnrg-tcp-clayer] will provide the 184 required reliability and congestion control for transport of Bundles 185 and would be the default choice in the Internet. Alternatives such 186 as encapsulating Bundles directly in datagrams and using UDP or DCCP 187 are not generally appropriate because they offer limited reliability 188 and, in the case of UDP, no congestion control. 190 LTP, on the other hand, offers its own form of reliability. 191 Particularly for testing purposes, it makes no sense to run LTP over 192 a protocol, like TCP, that offers reliability already. In addition, 193 running LTP over TCP would reduce the flexibility available to users, 194 since LTP offers more control over what data is delivered reliably 195 and what data is delivered best effort, a feature that TCP lacks. As 196 such, it would be better to run LTP over an unreliable protocol. 198 One solution would be to use UDP. UDP provides no reliability, 199 allowing LTP to manage that itself. However, UDP does not provide 200 congestion control. Because LTP is designed to run over fixed rate 201 radio links it does provide rate control, but not congestion control. 202 Lack of congestion control in network connections is a major problem 203 that can cause artificially high loss rates and/or serious fairness 204 issues. Previous standards documents are unanimous in recommending 205 congestion control for protocols to be used on the Internet, see 206 "Congestion Control Principles" [RFC2914], "Unicast UDP Usage 207 Guidelines" [RFC5405], and "Queue Management and Congestion 208 Avoidance" [RFC2309], among others. RFC 5405, in particular, calls 209 congestion control "vital" for "applications that can operate at 210 higher, potentially unbounded data rates". Therefore, any Bundle 211 Protocol implementation permitting the use of UDP to transport LTP 212 segments or Bundles outside an isolated network for the transmission 213 of any non-trivial amounts of data MUST implement congestion control 214 consistent with RFC 5405. 216 Alternatively, the Datagram Congestion Control Protocol (DCCP) 217 [RFC4340] was designed specifically to provide congestion control 218 without reliability for those applications that traverse the Internet 219 but do not desire to retransmit lost data. As such, it is 220 RECOMMENDED that, if possible, DCCP be used to transport LTP segments 221 across the Internet. 223 3. Recommendations for Implementers 224 3.1. How and Where to Deal with Fragmentation 226 The Bundle Protocol allows Bundles with sizes limited only by node 227 resource constraints. In IPv4, the maximum size of a UDP datagram is 228 nearly 64KB. In IPv6, when using jumbograms [RFC2675], UDP datagrams 229 can technically be up to 4GB in size [RFC2147], although this option 230 is rarely used. It is well understood that sending large IP 231 datagrams that must be fragmented by the network has enormous 232 efficiency penalties [Kent88]. The Bundle Protocol specification 233 provides a Bundle fragmentation concept [RFC5050] that allows a large 234 Bundle to be divided into Bundle fragments. If the Bundle Protocol 235 is being encapsulated in DCCP or UDP, it therefore SHOULD create each 236 fragment of sufficiently small size that it can then be encapsulated 237 into a datagram that will not need to be fragmented at the IP layer. 239 IP fragmentation can be avoided by using IP Path MTU Discovery 240 [RFC1191][RFC1981], which depends on the deterministic delivery of 241 ICMP Packet Too Big (PTB) messages from routers in the network. To 242 bypass a condition referred to as a black hole [RFC2923], a newer 243 specification is available in [RFC4821] to determine the IP Path MTU 244 without the use of PTB messages. This document does not attempt to 245 recommend one fragmentation avoidance mechanism over another; the 246 information in this section is included for the benefit of 247 implementers. 249 3.1.1. DCCP 251 Because DCCP implementations are not required to support IP 252 fragmentation and are not allowed to enable it by default, a DCCP 253 Convergence Layer (we will use "CL" from here on) MUST NOT accept 254 data segments that cannot be sent as one MTU sized datagram. 256 3.1.2. UDP 258 When an LTP CL is using UDP for datagram delivery, it SHOULD NOT 259 create segments that will result in UDP datagrams that will need to 260 be fragmented, as discussed above. 262 3.2. Bundle Protocol over a Datagram Convergence Layer 264 In general, the use of the Bundle Protocol over a datagram CL is 265 discouraged in IP networks. Bundles can be of (almost) arbitrary 266 length, and the Bundle Protocol does not include an effective 267 retransmission mechanism. Whenever possible the Bundle Protocol 268 SHOULD be operated over the TCP Convergence Layer or over LTP. 270 If a datagram CL is used for transmission of Bundles, every datagram 271 MUST contain exactly one Bundle or four zero octets as a keep-alive. 273 Bundles that are too large for the path MTU SHOULD be fragmented and 274 reassembled at the Bundle Protocol layer to prevent IP fragmentation. 276 3.2.1. DCCP 278 The DCCP CL for Bundle Protocol use SHOULD use the IANA assigned port 279 4556/DCCP and service code 1685351985; the use of other port numbers 280 and service codes is implementation specific. 282 3.2.2. UDP 284 The UDP CL for Bundle Protocol use SHOULD use the IANA assigned port 285 4556/UDP; the use of other port numbers is implementation specific. 287 3.3. LTP over Datagrams 289 LTP is designed as a point to point protocol within DTN, and it 290 provides intrinsic acknowledgement and retransmission facilities. 291 LTP segments are transported over a "local data link layer" (RFC 5325 292 [RFC5325]); we will use the term "transport" from here on. Transport 293 of LTP using datagrams is an appropriate choice. When a datagram 294 transport is used to send LTP segments, every datagram MUST contain 295 exactly one LTP segment or four zero octets as a keep-alive. LTP 296 MUST perform segmentation in such a way as to ensure that every LTP 297 segment fits into a single packet which will not require IP 298 fragmentation as discussed above. 300 3.3.1. DCCP 302 The DCCP transport for LTP SHOULD use the IANA assigned port 1113/ 303 DCCP and service code 7107696; the use of other port numbers and 304 service codes is implementation specific. 306 3.3.2. UDP 308 The UDP transport for LTP SHOULD use the IANA assigned port 1113/UDP; 309 the use of other port numbers is implementation specific. 311 3.4. Keep Alive Option 313 It may be desirable for a UDP or DCCP CL or transport to send "keep- 314 alive" packets during extended idle periods. This may be needed to 315 refresh a contact table entry at the destination, or to maintain an 316 address mapping in a NAT or a dynamic access rule in a firewall. 317 Therefore, the CL or transport MAY send a datagram containing exactly 318 4 octets of zero bits. The CL or transport receiving such a packet 319 MUST discard this packet; the receiving CL or transport may then 320 perform local maintenance of its state tables, these maintenance 321 functions are not covered in this draft. Note that packets carrying 322 Bundles or segments will always contain more than 4 octets of 323 information (either the Bundle or the LTP header); keep-alive packets 324 will therefore never be mistaken for actual data packets. If UDP or 325 DCCP are being used for communication in both directions between a 326 pair of Bundle agents, transmission and processing of keep-alives in 327 the two directions occurs independently. Keep-alive intervals SHOULD 328 be configurable, SHOULD default to 15 sec, and MUST NOT be configured 329 shorter than 15 sec. 331 3.5. Checksums 333 Both the core Bundle Protocol specification and core LTP 334 specification assume that they are transmitting over an erasure 335 channel, i.e. a channel that either delivers packets correctly or not 336 at all. 338 3.5.1. DCCP 340 A DCCP transmitter MUST, therefore, ensure that the entire packet is 341 checksummed by setting the Checksum Coverage to 0. Likewise, the 342 DCCP receiver MUST ignore all packets with partial checksum coverage. 344 3.5.2. UDP 346 A UDP transmitter therefore MUST NOT disable UDP checksums, and the 347 UDP receiver MUST NOT disable checking of received UDP checksums. 349 Even when UDP checksums are enabled a small probability of UDP packet 350 corruption remains. In some environments it may be acceptable for 351 LTP or the Bundle Protocol to occasionally receive corrupted input. 352 In general, however, a UDP implementation SHOULD use optional 353 security extensions available in the Bundle Protocol or LTP to 354 protect against message corruption. 356 3.6. DCCP Congestion Control Modules 358 DCCP supports pluggable congestion control modules in order to 359 optimize its behavior to particular environments. The two most 360 common congestion control modules (CCIDs) are TCP-like Congestion 361 Control (CCID2) [RFC4341] and TCP-Friendly Rate Control (CCID3) 362 [RFC4342]. TCP-like Congestion Control is designed to emulate TCP's 363 congestion control as much as possible. It is recommended for 364 applications that want to send data as quickly as possible, while 365 TCP-Friendly Rate Control is aimed at applications that want to avoid 366 sudden changes in sending rate. DTN use cases seem to fit more into 367 the first case so DCCP CL's and transports SHOULD use TCP-like 368 Congestion Control (CCID2) by default. 370 4. IANA Considerations 372 Port number assignments 1113/UDP and 4556/UDP have been registered 373 with IANA. Port number 1113/DCCP with Service Code 7107696 has been 374 requested for the transport of LTP under IANA ticket number 717731. 375 Port number 4556/DCCP with Service Code 1685351985 has been requested 376 for the transport of Bundles under IANA ticket number 717732. 378 5. Security Considerations 380 This memo describes the use of datagrams to transport DTN application 381 data. Hosts may be in the position of having to accept and process 382 packets from unknown sources; the DTN Endpoint ID can be discovered 383 only after the Bundle has been retrieved from the DCCP or UDP packet. 384 Hosts SHOULD use authentication methods available in the DTN 385 specifications to prevent malicious hosts from inserting unknown data 386 into the application. 388 Hosts need to listen for and process DCCP or UDP data on the known 389 LTP or Bundle Protocol ports. A denial of service scenario exists 390 where a malicious host sends datagrams at a high rate, forcing the 391 receiving hosts to use their resources to process and attempt to 392 authenticate this data. Whenever possible, hosts SHOULD use IP 393 address filtering to limit the origin of packets to known hosts. 395 6. References 397 6.1. Normative References 399 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 400 1981. 402 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 403 (IPv6) Specification", RFC 1883, December 1995. 405 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 406 Requirement Levels", BCP 14, RFC 2119, March 1997. 408 [RFC2147] Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147, 409 May 1997. 411 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 412 RFC 2675, August 1999. 414 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 415 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 417 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 418 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 419 Congestion Control", RFC 4341, March 2006. 421 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 422 Specification", RFC 5050, November 2007. 424 [RFC5325] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider 425 Transmission Protocol - Motivation", RFC 5325, September 426 2008. 428 [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 429 Transmission Protocol - Specification", RFC 5326, 430 September 2008. 432 [RFC5327] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider 433 Transmission Protocol - Security Extensions", RFC 5327, 434 September 2008. 436 6.2. Informative References 438 [I-D.irtf-dtnrg-tcp-clayer] 439 Demmer, M., Ott, J., and S. Perreault, "Delay Tolerant 440 Networking TCP Convergence Layer Protocol", draft-irtf- 441 dtnrg-tcp-clayer-05 (work in progress), January 2013. 443 [Kent88] Kent, C. and J. Mogul, "Fragmentation considered 444 harmful.", 1988, . 446 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 447 November 1990. 449 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 450 for IP version 6", RFC 1981, August 1996. 452 [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, 453 S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., 454 Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, 455 S., Wroclawski, J., and L. Zhang, "Recommendations on 456 Queue Management and Congestion Avoidance in the 457 Internet", RFC 2309, April 1998. 459 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 460 2914, September 2000. 462 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 463 2923, September 2000. 465 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 466 Datagram Congestion Control Protocol (DCCP) Congestion 467 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342, 468 March 2006. 470 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 471 Discovery", RFC 4821, March 2007. 473 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 474 for Application Designers", BCP 145, RFC 5405, November 475 2008. 477 Authors' Addresses 479 Hans Kruse 480 Ohio University 481 31 S. Court Street, Rm 150 482 Athens, OH 45701 483 United States 485 Phone: +1 740 593 4891 486 Email: kruse@ohio.edu 488 Samuel Jero 489 Ohio University 490 Athens, Ohio 45701 491 United States 493 Email: sj323707@ohio.edu 495 Shawn Ostermann 496 Ohio University 497 Stocker Engineering Center 498 Athens, OH 45701 499 United States 501 Phone: +1 740 593 1566 502 Email: ostermann@eecs.ohiou.edu