idnits 2.17.1 draft-burleigh-dtnrg-ltpcl-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 (April 25, 2013) is 4018 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC3986' is defined on line 335, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Burleigh 3 Internet-DraftJet Propulsion Laboratory, California Institute of Technol 4 Intended status: Experimental April 25, 2013 5 Expires: October 27, 2013 7 Delay-Tolerant Networking LTP Convergence Layer (LTPCL) Adapter 8 draft-burleigh-dtnrg-ltpcl-05 10 Abstract 12 This document describes the procedures by which the Licklider 13 Transmission Protocol (LTP) is used as a "convergence-layer" protocol 14 to convey Delay-Tolerant Networking (DTN) "bundles" between DTN 15 nodes. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 27, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. LTP Engine Configuration . . . . . . . . . . . . . . . . 4 60 2.2. Bundle Transmission . . . . . . . . . . . . . . . . . . . 4 61 2.3. Bundle Reception . . . . . . . . . . . . . . . . . . . . 5 62 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 5. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 This document describes the procedures by which the Licklider 71 Transmission Protocol (LTP)) [RFC5326] is used as a "convergence- 72 layer" protocol to convey Delay-Tolerant Networking (DTN) Bundle 73 Protocol (BP) [RFC5050] "bundles" between DTN nodes. 75 BP is designed to enable end-to-end forwarding of a unit of user 76 data, encapsulated in a bundle, from one DTN node to another, 77 possibly indirectly through the agency of other DTN nodes that relay 78 the bundle among themselves toward the destination node. Conveyance 79 of a bundle directly from one node to a second node -- either a relay 80 node or the final destination -- is accomplished by the sending 81 node's invocation of the transmission services of some underlying 82 "convergence-layer" protocol stack. 84 A virtually limitless variety of convergence-layer stacks may be 85 utilized in support of BP for this purpose, each one achieving inter- 86 node bundle flow in a way that is suited to the particular 87 communications infrastructure to which both the sending and receiving 88 nodes have access. 90 Convergence-layer stacks are typically characterized by the highest- 91 layer standard protocol in the stack, i.e., the protocol that is 92 immediately below BP, which is commonly called the "convergence-layer 93 protocol." To assure interoperability among nodes that utilize a 94 common convergence-layer protocol, it is necessary to agree on the 95 procedures by which bundles are encapsulated in the protocol data 96 units of the convergence-layer protocol and reconstructed from those 97 protocol data units upon reception; these procedures are performed by 98 a "convergence-layer adapter" that conforms to a standardized 99 convergence-layer adapter specification. (Note that convergence- 100 layer adapter standardization is necessary for BP node interoperation 101 but is in itself not sufficient: agreement on the configuration of 102 protocols at all layers below the convergence-layer protocol is also 103 necessary. Mechanisms for achieving this agreement are beyond the 104 scope of this document.) 106 This document, the LTP convergence-layer adapter specification, 107 defines standard procedures for encapsulating bundles in LTP segments 108 and reconstructing bundles from received LTP segments. 110 2. Specification 112 In general, LTP operates as follows: an LTP "sender" engine generates 113 one or more data "segments" from a "block" of client service data and 114 conducts a segment transmission "session" that ultimately enables 115 reconstruction of the client service data block, from received 116 segments, at the "receiver" engine. 118 Each block comprises a "red-part" of zero or more octets, to which 119 reliable transmission procedures must be applied, immediately 120 followed by a "green-part" of zero or more octets, to which only 121 "best efforts" transmission procedures need be applied. The length 122 of the red-part of a block is termed the block's "red length." The 123 length of the green-part of a block is termed the block's "green 124 length." The length of a block is the sum of its red length and 125 green length. Each LTP data segment encapsulates part (or all) of 126 the red-part of a block or part (or all) of the green-part of a 127 block, but never both. LTP data segments that encapsulate red-part 128 data are termed "red segments." LTP data segments that encapsulate 129 green-part data are termed "green segments." 131 The LTP specification implicitly mandates the reassembly of the red- 132 part of a block into a contiguous byte array from received red 133 segments, but it does not mandate the reassembly of the green-part 134 from received green segments. That is, any required reassembly of 135 "green" service data is the responsibility of the client service - in 136 this case, the LTP convergence-layer adapter. 138 Specific procedures for invoking LTP to send bundles are as follows. 140 2.1. LTP Engine Configuration 142 If the BP node that utilizes a given LTP engine is a member of one or 143 more endpoints identified by CBHE-conformant endpoint IDs, then the 144 engine number of that LTP engine MAY be identical to the node number 145 that is common to those endpoint IDs. This convention can simplify 146 network management in some environments. 148 Otherwise, the LTP engine number MAY be interpreted as the node 149 number that identifies this node, in any context where some such 150 identifying node number may be useful. 152 2.2. Bundle Transmission 154 The client service data block that the LTP convergence-layer adapter 155 (LTPCLA) passes to the LTP sender engine for transmission MUST 156 comprise only one or more complete "conformant" bundles. 157 ("Conformant" bundles are bundles that conform to the Bundle Protocol 158 specification [RFC5050].) The total length of the block MUST be 159 equal to the sum of the lengths of all bundles in the block. 161 The client service data block passed to the LTP sender engine by 162 LTPCLA MUST contain exactly one of the following: 164 o A single conformant bundle of length L for which only best-efforts 165 transmission is intended. In this case, the red length of the 166 block is zero and the green length of the block is L. 168 o A single conformant bundle of length L comprising N bytes (0 < N < 169 L) for which reliable transmission is intended followed by (L - N) 170 bytes for which only best-efforts transmission is intended. In 171 this case, the red length of the block is N and the green length 172 of the block is (L - N). 174 o A single conformant bundle of length L for which reliable 175 transmission is intended. In this case, the red length of the 176 block is L and the green length of the block is zero. 178 o The concatenation of two or more conformant bundles for which 179 reliable transmission is intended, the sum of whose lengths is L. 180 In this case, the red length of the block is L and the green 181 length of the block is zero. 183 Note that the length of a bundle in a client service data block is 184 not constrained in any way by the lengths of the LTP data segments in 185 which portions of the block will be transmitted. 187 An LTP sender engine MAY impose an upper limit on the red length of a 188 block. Mechanisms by which LTPCLA may determine the block red length 189 limit are an implementation matter. 191 The client service ID number passed by LTPCLA to LTP with each block 192 MUST be 1, signifying that the client service is the Bundle Protocol. 194 Upon reception of a transmission-session completion notice from the 195 LTP receiver engine, LTPCLA MUST inform the bundle protocol agent 196 that data sending procedures with regard to all bundles in the 197 corresponding block have concluded. 199 Procedures to be performed upon reception of a transmission-session 200 cancellation notice from the LTP receiver engine are an 201 implementation matter, but in particular LTPCLA MUST NOT inform the 202 bundle protocol agent that data sending procedures with regard to all 203 bundles in the corresponding block have concluded. LTPCLA MAY advise 204 the bundle protocol agent to repeat steps 2 though 6 of the Bundle 205 Forwarding procedure defined in section 5.4 of RFC 5050, for each 206 bundle in the block, in this event. 208 Procedures to be performed by LTPCLA upon reception of transmission- 209 session start notices and initial-transmission completion notices are 210 an implementation matter. 212 2.3. Bundle Reception 214 Upon reception of a red-part reception notice from the LTP receiver 215 engine: 217 a. The red-part reception notice's client service data is the 218 reassembled red-part of a client service data block. 220 b. If the last byte of the red-part is the last byte of the block, 221 LTPCLA MUST initiate bundle reception procedures (complying with 222 RFC 5050) once for each conformant bundle in the continuous 223 sequence of complete conformant bundles beginning at the first 224 octet of the red-part reception notice's client service data (the 225 reassembled red-part of the block). The total length of a 226 conformant bundle is the sum of the lengths of all BP blocks (not 227 to be confused with LTP blocks) in that bundle, and the length of 228 each conformant BP block can always be determined by inspection 229 of the initial octets of the block. Inability to determine the 230 length of a BP block in the red-part of an LTP block signifies 231 that the immediately prior complete bundle, if any, was the last 232 conformant bundle in the block's red-part; in this case, LTPCLA 233 MUST discard all data in the block following that last conformant 234 bundle. 236 c. Otherwise, LTPCLA MUST interpret the red-part as the initial N 237 bytes of a single bundle that is being conveyed via this block, 238 where N is the length of the red-part. LTPCLA SHOULD retain 239 these N bytes of data for the purpose of reconstructing the 240 bundle; alternatively, LTPCLA MAY discard the entire red-part. 241 The latter option is preferable when there is a non-negligible 242 probability that subsequent arrival of green-part segments will 243 not occur in time to prevent block reassembly storage resource 244 consumption from exhausting available storage, as might result 245 from some kinds of denial-of-service attack as discussed in 246 section 4. 248 Upon reception of a green-part segment arrival notice from the LTP 249 receiver engine: 251 a. LTPCLA SHOULD discard all data retained for the purpose of 252 reconstructing the bundle(s) encapsulated in all other blocks for 253 which green data are still unreceived. Green segments nominally 254 arrive in transmission order, and they are never retransmitted, 255 so the arrival of a green segment for one block nominally 256 indicates that no further green segments will be received for any 257 other block that is still pending reassembly. 259 b. The "expected offset" for the first green segment received for 260 any block is the red length of the block; the expected offset for 261 every other green segment received for a block is the sum of the 262 offset and length of whichever previously received green segment 263 for that block had the largest offset. 265 * When a green-part segment arrival notice indicates an offset 266 that is less than the expected offset for that segment, the 267 notice's client service data MAY be discarded or it MAY be 268 retained for the purposes of reconstructing the bundle 269 encapsulated in the affected block, an implementation 270 decision. 272 * When a green-part segment arrival notice indicates an offset 273 that is equal to the expected offset for that segment, the 274 notice's client service data MUST be retained for the purposes 275 of reconstructing the bundle encapsulated in the affected 276 block. 278 * When a green-part segment arrival notice indicates an offset 279 that is greater than the expected offset for that segment, the 280 notice's client service data MUST be retained for the purposes 281 of reconstructing the bundle encapsulated in the affected 282 block and the fact that a gap in client service data reception 283 was detected SHOULD be reported if and when the bundle 284 encapsulated in that block is received. The manner in which 285 this information is reported is an implementation matter. 287 c. When a green-part segment arrival notice indicates that the last 288 byte of the notice's client service data is the last byte of the 289 block, LTPCLA MUST initiate bundle reception procedures 290 (complying with RFC 5050) for the bundle that is encapsulated in 291 this block (regardless of whether or not gaps in the block were 292 detected) and then MUST discard this notice's client service data 293 and all retained data for this block. 295 Upon reception of a reception-session cancellation notice, LTPCLA 296 MUST discard all data retained for the purpose of reconstructing the 297 bundle conveyed in the affected block. 299 Procedures to be performed by LTPCLA upon reception of reception- 300 session start notices are an implementation matter. 302 3. IANA Considerations 304 This document has no IANA considerations. 306 4. Security Considerations 308 As noted in section 2.3 above, LTPCLA reception of a partially-red 309 bundle introduces the possibility of a denial-of-service attack. An 310 attacker could transmit an unlimited number of LTP red segments, each 311 of which is flagged as end-of-red-part but not end-of-block, without 312 ever sending any green segments at all. If the attacked node chooses 313 to retain all of these completely received red-parts in hopes of 314 reassembling the original bundles that they are apparently pieces of, 315 without ever receiving any green segments that would cause the 316 retained data to be discarded, it may eventually exhaust its storage 317 resources and cease operation. LTP authentication as documented in 318 [RFC5327] could reduce the chance that such an attack might succeed, 319 making partially-red bundle reception safer. 321 Otherwise, LTPCLA introduces no new security considerations beyond 322 those discussed in the DTN Bundle Protocol and Licklider Transmission 323 Protocol specifications. 325 5. Acknowledgment 327 Stephen Farrell's and Keith Scott's many helpful observations on this 328 specification are gratefully acknowledged. 330 6. Normative References 332 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 333 Requirement Levels", BCP 14, RFC 2119, March 1997. 335 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 336 Resource Identifier (URI): Generic Syntax", STD 66, RFC 337 3986, January 2005. 339 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 340 Specification", RFC 5050, November 2007. 342 [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider 343 Transmission Protocol - Specification", RFC 5326, 344 September 2008. 346 [RFC5327] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider 347 Transmission Protocol - Security Extensions", RFC 5327, 348 September 2008. 350 Author's Address 352 Scott Burleigh 353 Jet Propulsion Laboratory, California Institute of Technology 354 4800 Oak Grove Drive, m/s 301-490 355 Pasadena, CA 91109 356 USA 358 Phone: +1 818 393 3353 359 Email: Scott.C.Burleigh@jpl.nasa.gov