idnits 2.17.1 draft-irtf-dtnrg-ltp-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2345. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2329. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2335. 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 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-irtf-dtnrg-ltp-motivation-04 == Outdated reference: A later version (-08) exists of draft-irtf-dtnrg-ltp-extensions-05 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Delay Tolerant Networking Research Group M. Ramadas 3 Internet Draft Ohio University 4 Intended Status: Experimental S. Burleigh 5 NASA/Jet Propulsion Laboratory 6 January 20 2008 S. Farrell 7 Expires July 20 2008 Trinity College Dublin 9 Licklider Transmission Protocol - Specification 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 July 18, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document describes the Licklider Transmission Protocol (LTP), 43 designed to provide retransmission-based reliability over links 44 characterized by extremely long message round-trip times (RTTs) 45 and/or frequent interruptions in connectivity. Since communication 46 across interplanetary space is the most prominent example of this 47 sort of environment, LTP is principally aimed at supporting "long- 48 haul" reliable transmission in interplanetary space, but it has 49 applications in other environments as well. 51 LTP does ARQ of data transmissions by soliciting selective- 52 acknowledgment reception reports. It is stateful, and has no 53 negotiation or handshakes. 55 In an Interplanetary Internet setting deploying the Bundle protocol 56 that is being developed by the Delay Tolerant Networking Research 57 Group, LTP is intended to serve as a reliable "convergence layer" 58 protocol operating in pairwise fashion between adjacent 59 Interplanetary Internet nodes that are in direct RF communication. 60 In that operational scenario, and potentially in some other 61 deployments of the Bundle Protocol, LTP runs directly over a data- 62 link layer protocol; when this is the case, forward error correction 63 coding and/or checksum mechanisms in the underlying data-link layer 64 protocol must assure the integrity of the data passed between the 65 communicating entities. 67 Since no mechanisms for flow control or congestion control are 68 included in the design of LTP, this protocol is not intended or 69 appropriate for ubiquitous deployment in the global Internet. 71 When LTP is run over UDP, it must only be used for software 72 development or in private local area networks. When LTP is not run 73 over UDP, it must be run directly over a protocol, (nominally a link- 74 layer protocol), that meets the requirements specified in section 5. 76 This document is a product of the Delay Tolerant Networking Research 77 Group and has been reviewed by that group. No objections to its 78 publication as an RFC were raised. 80 Table of Contents 82 1. Introduction ................................................. 4 83 2. Terminology .................................................. 4 84 3. Segment Structure ........................................... 9 85 3.1 Segment Header ......................................... 11 86 3.1.1 Segment Type Flags ............................... 11 87 3.1.2 Segment Type Codes ............................... 12 88 3.1.3 Segment Class Masks .............................. 13 89 3.1.4 Extensions field ................................. 14 90 3.2 Segment Content ........................................ 15 91 3.2.1 Data Segment (DS) ................................ 15 92 3.2.2 Report Segment (RS) .............................. 16 93 3.2.3 Report Acknowledgment Segment .................... 19 94 3.2.4 Session Management Segments ...................... 19 95 3.3 Segment Trailer ........................................ 19 96 4. Requests from Client Service ................................ 20 97 4.1 Transmission Request ................................... 20 98 4.2 Cancellation Request ................................... 21 99 5. Requirements from the Operating Environment ................. 22 100 6. Internal Procedures ......................................... 23 101 6.1 Start Transmission ..................................... 23 102 6.2 Start Checkpoint Timer ................................. 24 103 6.3 Start RS Timer ......................................... 24 104 6.4 Stop Transmission ...................................... 24 105 6.5 Suspend Timers ......................................... 24 106 6.6 Resume Timers .......................................... 25 107 6.7 Retransmit Checkpoint .................................. 26 108 6.8 Retransmit RS .......................................... 26 109 6.9 Signify Red-Part Reception ............................. 27 110 6.10 Signify Green-Part Segment Arrival .................... 27 111 6.11 Send Reception Report ................................. 27 112 6.12 Signify Transmission Completion ....................... 29 113 6.13 Retransmit Data ....................................... 29 114 6.14 Stop RS Timer ......................................... 30 115 6.15 Start Cancel Timer .................................... 31 116 6.16 Retransmit Cancellation Segment ....................... 31 117 6.17 Acknowledge Cancellation .............................. 31 118 6.18 Stop Cancel Timer ..................................... 32 119 6.19 Cancel Session ........................................ 32 120 6.20 Close Session ......................................... 32 121 6.21 Handle Miscolored Segment ............................. 32 122 6.22 Handling System Error Conditions ...................... 33 123 7. Notices to Client Service ................................... 34 124 7.1 Session Start .......................................... 34 125 7.2 Green-Part Segment Arrival ............................. 34 126 7.3 Red-Part Reception ..................................... 35 127 7.4 Transmission-Session Completion ........................ 35 128 7.5 Transmission-Session Cancellation ...................... 35 129 7.6 Reception-Session Cancellation ......................... 36 130 7.7 Initial-Transmission Completion ........................ 36 131 8. State Transition Diagrams ................................... 36 132 8.1 Sender ................................................. 38 133 8.2 Receiver ............................................... 44 134 9. Security Considerations ..................................... 49 135 9.1 Denial of Service Considerations ....................... 49 136 9.2 Replay Handling ........................................ 50 137 9.3 Implementation Considerations .......................... 51 138 10. IANA Considerations ........................................ 52 139 11. Acknowledgments ............................................ 52 140 12. References ................................................. 53 141 12.1 Normative References ................................... 53 142 12.2 Informative References ................................. 53 143 13. Author's Addresses ......................................... 53 145 1. Introduction 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [B97]. 151 Discussions on this internet-draft are being made in the Delay 152 Tolerant Networking Research Group (DTNRG) mailing list. More 153 information can be found in the DTNRG web-site at 154 http://www.dtnrg.org 156 This document serves as the main protocol specification of LTP and is 157 part of a series of documents describing LTP. Other documents in 158 this series include the motivation document [LTPMTV] and the protocol 159 extensions document [LTPEXT]. We strongly recommend reading the 160 protocol motivation document before reading the following document, 161 to establish sufficient background and motivation for the 162 specification. 164 2. Terminology 166 (1) Engine ID 168 A number that uniquely identifies a given LTP engine, within some 169 closed set of communicating LTP engines. Note that when LTP is 170 operating underneath the DTN Bundle protocol [BP][DTN], the 171 convergence layer adapter mediating the two will be responsible for 172 translating between DTN endpoint IDs and LTP engine IDs in an 173 implementation-specific manner. 175 (2) Block 177 An array of contiguous octets of application data handed down by the 178 upper layer protocol (typically Bundle protocol) to be transmitted 179 from one LTP client service instance to another. 181 Any subset of a block comprising contiguous octets beginning at the 182 start of the block is termed a "block prefix" and any such subset of 183 the block ending with the end of the block is termed a "block 184 suffix". 186 (3) Red-Part 188 The block prefix that is to be transmitted reliably, i.e., subject to 189 acknowledgment and retransmission. 191 (4) Green-Part 193 The block suffix that is to be transmitted unreliably, i.e., not 194 subject to acknowledgments or retransmissions. If present, the 195 green-part of a block begins at the octet following the end of the 196 red-part. 198 (5) Session 200 A thread of LTP protocol activity conducted between two peer engines 201 for the purpose of transmitting a block. Data flow in a Session is 202 uni-directional: data traffic flows from the sending peer to the 203 receiving peer, while data-acknowledgment traffic flows from the 204 receiving peer to the sending peer. 206 (6) Sender 208 The data sending peer of a Session. 210 (7) Receiver 212 The data receiving peer of a Session. 214 (8) Client Service Instance 216 A software entity, such as an application or a higher-layer protocol 217 implementation, that is using LTP to transfer data. 219 (9) Segment 221 The unit of LTP data transmission activity. It is the data structure 222 transmitted from one LTP engine to another in the course of a 223 session. Each LTP segment is of one of the following types: data 224 segment, report segment, report-acknowledgment segment, cancel 225 segment, cancel-acknowledgment segment. 227 (10) Reception Claim 228 An assertion of reception of some number of contiguous octets of 229 application data (a subset of a block) characterized by: the offset 230 of the first received octet, and the number of contiguous octets 231 received (beginning at the offset). 233 (11) Scope 235 Scope identifies a subset of a block and comprises two numbers - 236 upper bound and lower bound. 238 For a data segment, lower bound is the offset of the segment's 239 application data from the start of the block (in octets), while upper 240 bound is the sum of the offset and length of the segment's 241 application data (in octets). For example, a segment with block 242 offset 1000 and length 500 would have a lower bound 1000 and upper 243 bound 1500. 245 For a report segment, upper bound is the end of the block prefix to 246 which the reception claims in the report apply, while lower bound is 247 the end of the (smaller) interior block prefix to which the reception 248 claims in the report do *not* apply. That is, data at any offset 249 equal to or greater than the report's lower bound but less than its 250 upper bound and not designated as "received" by any of the report's 251 reception claims must be assumed not received and therefore eligible 252 for retransmission. For example, if a report segment carried a lower 253 bound of 1000 and an upper bound of 5000, and the reception claims 254 indicated reception of data within offsets 1000-1999 and 3000-4999, 255 data within the block offsets 2000-2999 can be considered missing and 256 eligible for retransmission. 258 Reception reports (which may comprise multiple report segments) also 259 have scope, as defined in Section 6.11. 261 (12) End of Block (EOB) 263 The last data segment transmitted as part of the original 264 transmission of a block. This data segment also indicates that the 265 segment's upper bound is the total length of the block (in octets). 267 (13) End of Red-Part (EORP) 269 The segment transmitted as part of the original transmission of a 270 block containing the last octet of the block's red-part. This data 271 segment also indicates that the segment's upper bound is the length 272 of the block's red-part (in octets). 274 (14) Checkpoint 276 A data segment soliciting a reception report from the receiving LTP 277 engine. The EORP segment must be flagged as a checkpoint, as must 278 the last segment of any retransmission; these are "mandatory 279 checkpoints". All other checkpoints are "discretionary checkpoints". 281 (15) Reception Report 283 A sequence of one or more report segments reporting on all block data 284 reception within some scope. 286 (16) Synchronous Reception Report 288 A reception report that is issued in response to a checkpoint. 290 (17) Asynchronous Reception Report 292 A reception report that is issued in response to some implementation- 293 defined event other than the arrival of a checkpoint. 295 (18) Primary Reception Report 297 A reception report that is issued in response to some event other 298 than the arrival of a checkpoint segment that was itself issued in 299 response to a reception report. Primary reception reports include 300 all asynchronous reception reports and all synchronous reception 301 reports that are sent in response to discretionary checkpoints or to 302 the EORP segment for a session. 304 (19) Secondary Reception Report 306 A reception report that is issued in response to the arrival of a 307 checkpoint segment that was itself issued in response to a reception 308 report. 310 (20) Self-Delimiting Numeric Value (SDNV) 312 The design of LTP attempts to reconcile minimal consumption of 313 transmission bandwidth with 315 (a) extensibility to satisfy requirements not yet identified, and 316 (b) scalability across a very wide range of network sizes and 317 transmission payload sizes. 319 The SDNV encoding scheme is modeled after the Abstract Syntax 320 Notation One [ASN1] scheme for encoding Object Identifier Values. In 321 a data field encoded as an SDNV, the most significant bit (MSB) of 322 each octet of the SDNV serves to indicate whether the octet is the 323 last octet of the SDNV or not. An octet with an MSB of 1 indicates 324 that it is either the first or a middle octet of a multi-octet SDNV; 325 the octet with an MSB of 0 is the last octet of the SDNV. The value 326 encoded in an SDNV is found by concatenating the 7 least significant 327 bits of each octet of the SDNV, beginning at the first octet and 328 ending at the last octet. 330 The following examples illustrate the encoding scheme for various 331 hexadecimal values. 333 0xABC : 1010 1011 1100 334 is encoded as 336 {100 1010 1} {0 011 1100} 337 - - 339 = 10010101 00111100 341 0x1234 : 0001 0010 0011 0100 342 = 1 0010 0011 0100 343 is encoded as 345 {10 1 0010 0} {0 011 0100} 346 - - 348 = 10100100 00110100 350 0x4234 : 0100 0010 0011 0100 351 =100 0010 0011 0100 352 is encoded as 354 {1000000 1} {1 00 0010 0} {0 011 0100} 355 - - - 357 = 10000001 10000100 00110100 359 0x7F : 0111 1111 360 =111 1111 361 is encoded as 363 {0 111 1111} 364 - 365 = 01111111 367 Note : 369 Care must be taken to make sure that the value to be encoded is 370 padded with zeroes at the most significant bit end (NOT at the 371 least significant bit end) to make its bitwise length a multiple 372 of 7 before encoding. 374 While there is no theoretical limit on the size of an SDNV field, 375 we note that the overhead of the SDNV scheme is 1:7, i.e., one bit 376 of overhead for every 7 bits of actual data to be encoded. Thus a 377 7-octet value (a 56-bit quantity with no leading zeroes) would be 378 encoded in an 8-octet SDNV; an 8-octet value (a 64-bit quantity 379 with no leading zeroes) would be encoded in a 10-octet SDNV. In 380 general, an N-bit quantity with no leading zeroes would be encoded 381 in a ceil(N/7) octet SDNV, where ceil is the integer ceiling 382 function. Clearly, for fields that typically carry larger values 383 such as RSA public keys, the SDNV overhead could become 384 unacceptable. Hence when adopting the SDNV scheme for other 385 purposes related to this document, such as any protocol 386 extensions, we RECOMMEND that if the typical data field value is 387 expected to be larger than 8 octets then the data field should be 388 specified as a {LENGTH, VALUE} tuple, with the LENGTH parameter 389 encoded as an SDNV followed by LENGTH octets housing the VALUE of 390 the data field. 392 We also note that SDNV is clearly not the best way to represent 393 every numeric value. When the maximum possible value of a number 394 is known without question, the cost of additional bits may not be 395 justified. For example, an SDNV is a poor way to represent an 396 integer whose value typically falls in the range 128 to 255. In 397 general, though, we believe that the SDNV representation of 398 various protocol data fields in LTP segments yields the smallest 399 segment sizes without sacrificing scalability. 401 3. Segment Structure 403 Each LTP segment comprises 405 (a) a "header" in the format defined below. 407 (b) zero or more octets of "content". 409 (c) zero or more octets of "trailer" as indicated by information in 410 the "extensions field" of the header. 412 LTP segments are of four general types depending on the nature of the 413 content carried: 415 Data segments flow from the Sender to the Receiver and carry 416 client service (application) data. 418 A report segment flows from the Receiver to the Sender and carries 419 data reception claims together with the upper and lower bounds of 420 the block scope to which the claims pertain. 422 A report-acknowledgment segment flows from the Sender to the 423 Receiver and acknowledges reception of a report segment. It 424 carries the serial number of the report being acknowledged. 426 Session management segments may be generated by both the Sender 427 and the Receiver and are of two general sub-types: Cancellation 428 and Cancellation-acknowledgment. A Cancellation segment initiates 429 session cancellation procedures at the peer and carries a single 430 byte reason-code to indicate the reason for session cancellation. 431 Cancellation-acknowledgment segments merely acknowledge reception 432 of a Cancellation segment and have no content. 434 The overall segment structure is illustrated below: 436 Bit 0 1 2 3 4 5 6 7 437 ^ +-----+-----+-----+-----+-----+-----+-----+-----+ 438 | | Version number | Segment Type Flags | Control 439 | +-----------------------+-----------------------+ -byte 440 | | | 441 | / Session ID \ 442 | \ / 443 Header +-----------------------+-----------------------+ 444 | | Header Extension Cnt. | Trailer Extension Cnt.| Extensions 445 | +-----------------------+-----------------------+ 446 | | | 447 | / Header Extensions \ 448 | \ / 449 V +-----------------------------------------------+ 450 | | 451 | | 452 | | 453 | Segment Content | 454 / \ 455 \ / 456 | | 457 | | 458 | | 459 ^ +-----------------------------------------------+ 460 | | | 461 Trailer / Trailer Extensions \ 462 | \ / 463 V +-----------------------------------------------+ 465 3.1 Segment Header 467 An LTP segment header comprises three data items: a single-octet 468 Control-byte, the Session ID, and the Extensions field. 470 Control-byte comprises the following: 472 Version number (4 bits): MUST be set to the binary value 0000 for 473 this version of the protocol. 475 Segment type flags (4 bits): described in Section 3.1.1. 477 Session ID uniquely identifies, among all transmissions between the 478 Sender and Receiver, the session of which the segment is one token. 479 It comprises the following: 481 Session originator (SDNV): the engine ID of the Sender. 483 Session number (SDNV) : Typically a random number (for anti-DoS 484 reasons), generated by the Sender. 486 The format and resolution of session number are matters that are 487 private to the Sender LTP node; the only requirement imposed by 488 LTP is that every session initiated by an LTP engine MUST be 489 uniquely identified by the session ID. 491 The Extensions field is described in Section 3.1.4. 493 3.1.1 Segment Type Flags 495 The last four bits of the control byte in the segment header are 496 flags that indicate the nature of the segment. In order (most 497 significant bit first), these flags are CTRL, EXC, Flag 1 and Flag 0. 499 A value of 0 in the CTRL (Control) flag identifies the segment as a 500 data segment while a value of 1 identifies it as a control segment. 501 A data segment with the EXC (Exception) flag set to 0 is a red-part 502 segment; a data segment with EXC set to 1 is a green-part segment. 503 For a control segment, having the EXC flag set to 1 indicates that 504 the segment pertains to session cancellation activity. Any data 505 segment (whether red-part or green-part) with both Flag 1 and Flag 0 506 set to 1 indicates EOB. Any data segment (whether red-part or 507 green-part) with both Flag 1 and Flag 0 set to 0 indicates data 508 without any additional protocol significance. Any red-part data 509 segment with either Flag bit non-zero is a checkpoint. Any red-part 510 data segment with Flag 1 set to 1 indicates the end of red-part. 512 Put another way: 514 if (CTRL flag = 0) 515 segment is a Data segment if (EXC flag = 0) 516 segment contains only red-part data if (Flag 1 = 1) 517 segment is a checkpoint segment is the last segment in the 518 red part of the block if (Flag 0 = 1) 519 segment is the last segment in the block 520 else // segment is not end of red part 521 if (Flag 0 = 1) 522 segment is a checkpoint 523 else 524 segment contains only green-part data if (Flag 1 = 1) 525 if (Flag 0 = 1) 526 segment is the last segment in the block 527 else 528 segment is a Control segment if (EXC flag = 0) 529 segment pertains to report activity if (flag 0 = 0) 530 segment is a report segment 531 else 532 segment is an acknowledgment of a report segment 533 else 534 segment pertains to session cancellation activity if (Flag 1 = 535 0) 536 segment pertains to cancellation by block sender if (Flag 0 537 = 1) 538 segment is a cancellation by sender 539 else 540 segment is an acknowledgment of a cancellation by sender 541 else 542 segment pertains to cancellation by block receiver if (Flag 543 0 = 1) 544 segment is a cancellation by receiver 545 else 546 segment is an acknowledgment of a cancellation by 547 receiver 549 3.1.2 Segment Type Codes 550 Combinations of the settings of the segment type flags CTRL, EXC, 551 Flag 1 and Flag 0 constitute segment type codes which serve as 552 concise representations of detailed segment nature. 554 CTRL EXC Flag 1 Flag 0 Code Nature of segment 555 ---- --- ------ ------ ---- --------------------------------------- 556 0 0 0 0 0 Red data, NOT {Checkpoint, EORP or EOB} 557 0 0 0 1 1 Red data, Checkpoint, NOT {EORP or EOB} 558 0 0 1 0 2 Red data, Checkpoint, EORP, NOT EOB 559 0 0 1 1 3 Red data, Checkpoint, EORP, EOB 561 0 1 0 0 4 Green data, NOT EOB 562 0 1 0 1 5 Green data, undefined 563 0 1 1 0 6 Green data, undefined 564 0 1 1 1 7 Green data, EOB 566 1 0 0 0 8 Report segment 567 1 0 0 1 9 Report-acknowledgment segment 568 1 0 1 0 10 Control segment, undefined 569 1 0 1 1 11 Control segment, undefined 571 1 1 0 0 12 Cancel segment from block sender 572 1 1 0 1 13 Cancel-acknowledgment segment 573 to block sender 575 1 1 1 0 14 Cancel segment from block receiver 576 1 1 1 1 15 Cancel-acknowledgment segment 577 to block receiver 579 3.1.3 Segment Class Masks 581 For the purposes of this specification, some bit patterns in the 582 segment type flags field correspond to "segment classes" that are 583 designated by mnemonics. The mnemonics are intended to evoke the 584 characteristics shared by all types of segments characterized by 585 these flag bit patterns. 587 CTRL EXC Flag 1 Flag 0 Mnemonic Description 588 ---- --- ------ ------ -------- --------------------------- 589 0 0 - 1 590 -- or -- 591 0 0 1 - CP Checkpoint 593 0 0 1 - EORP End of red-part; 594 red-part size = offset + length 595 0 - 1 1 EOB End of block; 596 block size = offset + length 598 1 0 0 0 RS Report segment; 599 carries reception claims 601 1 0 0 1 RA Report-acknowledgment segment 603 1 1 0 0 CS Cancel segment from block sender 605 1 1 0 1 CAS Cancel-acknowledgment segment 606 to block sender 608 1 1 1 0 CR Cancel segment from block receiver 610 1 1 1 1 CAR Cancel-acknowledgment segment 611 to block receiver 613 1 1 - 0 Cx Cancel segment (generic) 615 1 1 - 1 CAx Cancel-acknowledgment segment 616 (generic) 618 3.1.4 Extensions field 620 The extensions field enables the inclusion of zero or more functional 621 extensions to the basic LTP segment, each in type-length-value (TLV) 622 representation as explained below. 624 The first octet of the extensions field indicates the number of 625 extensions present in the segment: the high-order 4 bits indicate the 626 number of extension TLVs in the header (immediately following the 627 extensions count octet and preceding the segment's content) while the 628 low-order 4 bits indicate the number of extension TLVs in the trailer 629 (immediately following the segment's content). That is, each segment 630 may have from 0 to 15 extension TLVs in its header and from 0 to 15 631 extension TLVs in its trailer. In the absence of any extension TLVs, 632 all bits of this extensions count octet MUST be set to zero. 634 Note that it is valid for header extensions to be immediately 635 followed by trailer extensions; for example, since a CAx segment has 636 no contents, it may have header extensions immediately followed by 637 trailer extensions. 639 Each extension consists of a one-octet tag identifying the type of 640 the extension, followed by a length parameter in SDNV form, followed 641 by a value of the specified length. 643 The diagram below illustrates the extension TLVs as they may occur in 644 the header or trailer. 646 +--------+----///-----///--+ 647 |ext-tag | length | value | 648 +--------+-------///-------+----------///-------+ 649 |ext-tag | length | value | 650 +--------+-----///-----///-+---------////-------+ 651 |ext-tag | length | value | 652 +--------+----------+----------+ 654 Extension tags are assigned as follows. 656 Extension tag Meaning 657 ------------- ------- 658 0x00 LTP authentication extension [LTPEXT] 659 0x01 LTP cookie extension [LTPEXT] 660 0x02-0xBF Reserved 661 0xC0-0xFF Private / Experimental Use 663 Note that since the last quarter of the extension-tag space is 664 reserved for experimental use, implementations should be aware that 665 collisions for these tags are possible. 667 3.2 Segment Content 669 3.2.1 Data Segment (DS) 671 The content of a data segment includes client service data and the 672 metadata enabling the receiving client service instance to receive 673 and make use of that data. 675 Client service ID (SDNV) 677 The client service ID number identifies the upper-level service to 678 which the segment is to be delivered by the Receiver. It is 679 functionally analogous to a TCP port number. If multiple 680 instances of the client service are present at the destination, 681 multiplexing must be done by the client service itself on the 682 basis of information encoded within the transmitted block. 684 Offset (SDNV) 685 Offset indicates the location of the segment's client service data 686 within the session's transmitted block. It is the number of bytes 687 in the block prior to the byte from which the first octet of the 688 segment's client service data was copied. 690 Length (SDNV) 692 The length of the ensuing client service data, in octets. 694 If the data segment is a checkpoint, the segment MUST additionally 695 include the following two serial numbers (Checkpoint serial number 696 and Report serial number) to support efficient retransmission. Data 697 segments that are not checkpoints MUST NOT have these two fields in 698 the header and MUST continue on directly with the client service 699 data. 701 Checkpoint serial number (SDNV) 703 The checkpoint serial number uniquely identifies the checkpoint 704 among all checkpoints issued by the block sender in a session. 705 The first checkpoint issued by the sender MUST have this serial 706 number chosen randomly for security reasons, and it is RECOMMENDED 707 that the sender use the guidelines in [ESC05] for this. Any 708 subsequent checkpoints issued by the sender MUST have the serial 709 number value found by incrementing the prior checkpoint serial 710 number by 1. When a checkpoint segment is retransmitted, however, 711 its serial number MUST be the same as when it was originally 712 transmitted. The checkpoint serial number MUST NOT be zero. 714 Report serial number (SDNV) 716 If the checkpoint was queued for transmission in response to the 717 reception of an RS [Sec 6.13], then its value MUST be the report 718 serial number value of the RS that caused the data segment to be 719 queued for transmission. 721 Otherwise, the value of report serial number MUST be zero. 723 Client service data (array of octets) 725 The client service data carried in the segment is a copy of a 726 subset of the bytes in the original client service data block, 727 starting at the indicated offset. 729 3.2.2 Report Segment (RS) 730 The content of an RS comprises one or more data reception claims, 731 together with the upper and lower bounds of the scope within the data 732 block to which the claims pertain. It also includes two serial 733 numbers to support efficient retransmission. 735 Report serial number (SDNV) 737 The report serial number uniquely identifies the report among all 738 reports issued by the Receiver in a session. The first report 739 issued by the Receiver MUST have this serial number chosen 740 randomly for security reasons, and it is RECOMMENDED that the 741 receiver use the guidelines in [ESC05] for this. Any subsequent 742 RS issued by the receiver MUST have the serial number value found 743 by incrementing the last report serial number by 1. When an RS is 744 retransmitted however, its serial number MUST be the same as when 745 it was originally transmitted. The report serial number MUST NOT 746 be zero. 748 Checkpoint serial number (SDNV) 750 The value of checkpoint serial number MUST be zero if the report 751 segment is NOT a response to reception of a checkpoint, i.e., the 752 reception report is asynchronous; otherwise it MUST be the 753 checkpoint serial number of the checkpoint that caused the RS to 754 be issued. 756 Upper bound (SDNV) 758 The upper bound of a report segment is the size of the block 759 prefix to which the segment's reception claims pertain. 761 Lower bound (SDNV) 763 The lower bound of a report segment is the size of the (interior) 764 block prefix to which the segment's reception claims do NOT 765 pertain. 767 Reception claim count (SDNV) 769 The number of data reception claims in this report segment. 771 Reception claims 773 Each reception claim comprises two elements: offset and length. 775 Offset (SDNV) 776 The offset indicates the successful reception of data beginning 777 at the indicated offset from the lower bound of the RS. The 778 offset within the entire block can be calculated by summing 779 this offset with the lower bound of the RS. 781 Length (SDNV) 783 The length of a reception claim indicates the number of 784 contiguous octets of block data starting at the indicated 785 offset that have been successfully received. 787 Reception claims MUST conform to the following rules: 789 A reception claim's length shall never be less than 1 and shall 790 never exceed the difference between the upper and lower bounds 791 of the report segment. 793 The offset of a reception claim shall always be greater than 794 the sum of the offset and length of the prior claim, if any. 796 The sum of a reception claim's offset and length and the lower 797 bound of the report segment shall never exceed the upper bound 798 of the report segment. 800 Implied requests for retransmission of client service data can be 801 inferred from an RS's data reception claims. However, *nothing* can 802 be inferred regarding reception of block data at any offset equal to 803 or greater than the segment's upper bound or at any offset less than 804 the segment's lower bound. 806 For example, if the scope of a report segment has lower bound 0 and 807 upper bound 6000, and the report contains a single data reception 808 claim with offset 0 and length 6000, then the report signifies 809 successful reception of the first 6000 bytes of the block. If the 810 total length of the block is 6000, then the report additionally 811 signifies successful reception of the entire block. 813 If on the other hand, the scope of a report segment has lower bound 814 1000 and upper bound 6000, and the report contains two data reception 815 claims, one with offset 0 and length 2000 and the other with offset 816 3000 and length 500, then the report signifies successful reception 817 only of bytes 1000-2999 and 4000-4499 of the block. From this we can 818 infer that bytes 3000-3999 and 4500-5999 of the block need to be 819 retransmitted, but we cannot infer anything about reception of the 820 first 1000 bytes or of any subsequent data beginning at block offset 821 6000. 823 3.2.3 Report Acknowledgment Segment 825 The content of an RA is simply the report serial number of the RS in 826 response to which the segment was generated. 828 Report serial number (SDNV) 830 This field returns the report serial number of the RS being 831 acknowledged. 833 3.2.4 Session Management Segments 835 Cancel segments (Cx) carry a single byte reason-code with the 836 following semantics : 838 Reason-Code Mnemonic Semantics 839 ----------- -------- --------------------------------------- 840 00 USR_CNCLD Client Service canceled session. 842 01 UNREACH Unreachable Client Service. 844 02 RLEXC Retransmission limit exceeded. 846 03 MISCOLORED Received either a red-part data segment 847 at block offset above any green-part 848 data segment offset or a green-part 849 data segment at block offset below any 850 red-part data segment offset. 852 04 SYS_CNCLD A system error condition caused 853 unexpected session termination. 855 05 RXMTCYCEXC Exceeded the Retransmission-Cycles limit 857 06-FF Reserved 859 The Cancel-acknowledgments (CAx) have no content. 861 Note: the reason we use different cancel segment types for the 862 originator and recipient is to allow a loopback mode to work without 863 disturbing any replay protection mechanism in use. 865 3.3 Segment Trailer 867 The segment trailer consists of a sequence of from zero to 15 868 extension TLVs as described in Section 3.1.4 above. 870 4. Requests from Client Service 872 In all cases the representation of request parameters is a local 873 implementation matter, as are validation of parameter values and 874 notification of the client service in the event that a request is 875 found to be invalid. 877 4.1 Transmission Request 879 In order to request transmission of a block of client service data, 880 the client service MUST provide the following parameters to LTP: 882 Destination client service ID 884 Destination LTP engine ID 886 Client service data to send, as an array of bytes. 888 Length of the data to be sent. 890 Length of the red-part of the data. This value MUST be in the 891 range from zero to the total length of data to be sent. 893 On reception of a valid transmission request from a client service, 894 LTP proceeds as follows. 896 First the array of data to be sent is subdivided as necessary, with 897 each subdivision serving as the client service data of a single new 898 LTP data segment. The algorithm used for subdividing the data is a 899 local implementation matter; it is expected that data size 900 constraints imposed by the underlying communication service, if any, 901 will be accommodated in this algorithm. 903 The last (and only the last) of the resulting data segments must be 904 marked as the EOB (End of block). 906 Note that segment type indicates that the client service data in a 907 given LTP segment either is or is not in the red-part of the block. 908 To prevent segment type ambiguity, each data segment MUST contain 909 either only red-part data or only green-part data. Therefore, when 910 the length of the block's red-part is N, the total length of the 911 block is M, and N is not equal to M, the (N+1)th byte of the block 912 SHOULD be the first byte of client service data in a green-part data 913 segment. Note that this means that at the red-part boundary, LTP may 914 send a segment of size lesser than the link MTU size. For bandwidth 915 efficiency reasons, implementations MAY choose to instead mark the 916 entire segment (within which the red-part boundary falls) as red- 917 part, causing green-part data falling within the segment also be 918 treated as red-part. 920 If the length of the block's red-part is greater than zero, then the 921 last data segment containing red-part data must be marked as the EORP 922 (End of red-part) segment by setting the appropriate segment type 923 flag bits [Sec 3.1.2]. Zero or more preceding data segments 924 containing red-part data (selected according to an algorithm that is 925 a local implementation matter) MAY additionally be marked as a CP 926 (Checkpoint), and serve as additional discretionary checkpoints [Sec 927 3.1.2]. 929 All data segments are appended to the (conceptual) application data 930 queue bound for the destination engine, for subsequent transmission. 932 Finally, a session start notice [Sec 7.1] is sent back to the client 933 service that requested the transmission. 935 4.2 Cancellation Request 937 In order to request cancellation of a session, either as the sender 938 or as the receiver of the associated data block, the client service 939 must provide the session ID identifying the session to be canceled. 941 On reception of a valid cancellation request from a client service, 942 LTP proceeds as follows. 944 First the internal "Cancel session" procedure [Sec 6.19] is invoked. 946 Next, if the session is being canceled by the Sender (i.e., the 947 session originator part of the session ID supplied in the 948 cancellation request is the local LTP engine ID): 950 If none of the data segments previously queued for transmission as 951 part of this session have yet been de-queued and transmitted - 952 i.e., if the destination engine cannot possibly be aware of this 953 session - then the session is simply closed; the "Close session" 954 procedure [Sec 6.20] is invoked. 956 Otherwise, a CS (Cancel by block sender) segment with reason-code 957 USR_CNCLD MUST be queued for transmission to the destination LTP 958 engine specified in the transmission request that started this 959 session. 961 Otherwise (i.e., the session is being canceled by the Receiver): 963 If there is no transmission queue-set bound for the Sender 964 (possibly because the local LTP engine is running on a receive- 965 only device), then the session is simply closed; the "Close 966 session" procedure [Sec 6.20] is invoked. 968 Otherwise, a CR (Cancel by block receiver) segment with reason- 969 code USR_CNCLD MUST be queued for transmission to the block 970 sender. 972 5. Requirements from the Operating Environment 974 LTP is designed to run directly over a data-link layer protocol. 976 LTP MUST only be deployed directly over UDP, for software development 977 purposes or for use in private local area networks. For example, in a 978 sparse sensor network where the link, when available, is only used 979 for LTP traffic. 981 In either case, the protocol layer immediately underlying LTP is 982 referred to as the "local data-link layer" for the purposes of this 983 specification. 985 When the local data-link layer protocol is UDP, (a) the content of 986 each UDP datagram MUST be an integral number of LTP segments and (b) 987 the LTP authentication [LTPEXT] extension SHOULD be used unless the 988 end-to-end path is one in which either the likelihood of datagram 989 content corruption is negligible or the consequences of receiving and 990 processing corrupt LTP segments are insignificant (as during software 991 development). In addition, the LTP authentication [LTPEXT] extension 992 SHOULD be used to assure data integrity unless the end-to-end path is 993 one in which either the likelihood of datagram content corruption is 994 negligible (as in some private local area networks) or the 995 consequences of receiving and processing corrupt LTP segments are 996 insignificant (as perhaps during software development). 998 When the local data-link layer protocol is not UDP, the content of 999 each local data-link layer protocol frame MUST be be an integral 1000 number of LTP segments. 1002 The local data-link layer protocol MUST be a protocol which, together 1003 with the operating environment in which that protocol is implemented, 1004 satisfies the following requirements: 1006 It is required to inform LTP whenever the link to a specific LTP 1007 destination is brought up or torn down. Similarly, it is required 1008 to inform the local LTP engine whenever it is known that a remote 1009 LTP engine is set to begin or stop communication with the local 1010 engine based on the engines' operating schedules. 1012 It is required to provide link state cues to LTP upon transmission 1013 of the CP, RS (Report), EORP, EOB, and Cx (Cancel) segments so 1014 that timers can be started. 1016 It is required to provide, upon request, the current distance (in 1017 light seconds) to any peer engine in order to calculate timeout 1018 intervals. 1020 A MIB (Management Information Base) with the above parameters, 1021 updated periodically by the local data-link layer and the operating 1022 environment, should be made available to the LTP engine for its 1023 operations. The details of the MIB are, however, beyond the scope of 1024 this document. 1026 The underlying data-link layer is required to never deliver 1027 incompletely received LTP segments to LTP. In the absence of the use 1028 of LTP authentication [LTPEXT], LTP also requires the underlying 1029 local data-link layer protocol to perform data integrity checking of 1030 the segments received. Specifically, the local data-link layer 1031 protocol is required to detect any corrupted segments received and to 1032 silently discard them. 1034 6. Internal Procedures 1036 This section describes the internal procedures that are triggered by 1037 the occurrence of various events during the life-time of an LTP 1038 session. 1040 Whenever the content of any of the fields of the header of any 1041 received LTP segment does not conform to this specification document, 1042 the segment is assumed to be corrupt and MUST be discarded 1043 immediately and processed no further. This procedure supersedes all 1044 other procedures described below. 1046 All internal procedures described below that are triggered by the 1047 arrival of a data segment are superseded by the following procedure 1048 in the event that the client service identified by the data segment 1049 does not exist at the local LTP engine: 1051 If there is no transmission queue-set bound for the block sender 1052 (possibly because the local LTP engine is running on a receive- 1053 only device), then the received data segment is simply discarded. 1055 Otherwise, if the data segment contains data from the red-part of 1056 the block, a CR with reason-code UNREACH MUST be enqueued for 1057 transmission to the block sender. A CR with reason-code UNREACH 1058 SHOULD be similarly enqueued for transmission to the data sender 1059 even if the data segment contained data from the green-part of the 1060 block; note however that (for example) in the case where the block 1061 receiver knows that the sender of this green-part data is 1062 functioning in a "beacon" (transmit-only) fashion, a CR need not 1063 be sent. In either case the received data segment is discarded. 1065 6.1 Start Transmission 1067 This procedure is triggered by the arrival of a link state cue 1068 indicating the start of transmission to a specified remote LTP 1069 engine. 1071 Response: the de-queuing and delivery of segments to the LTP engine 1072 specified in the link state cue begins. 1074 6.2 Start Checkpoint Timer 1076 This procedure is triggered by the arrival of a link state cue 1077 indicating the de-queuing (for transmission) of a CP segment. 1079 Response: the expected arrival time of the RS segment that will be 1080 produced on reception of this CP segment is computed, and a countdown 1081 timer is started for this arrival time. However, if it is known that 1082 the remote LTP engine has ceased transmission [Sec 6.5] then this 1083 timer is immediately suspended, because the computed expected arrival 1084 time may require an adjustment that cannot yet be computed. 1086 6.3 Start RS Timer 1088 This procedure is triggered by the arrival of a link state cue 1089 indicating the de-queuing (for transmission) of an RS segment. 1091 Response: the expected arrival time of the RA (Report acknowledgment) 1092 segment in response to the reception of this RS segment is computed, 1093 and a countdown timer is started for this arrival time. However, as 1094 in Sec 6.2, if it is known that the remote LTP engine has ceased 1095 transmission [Sec 6.5] then this timer is immediately suspended, 1096 because the computed expected arrival time may require an adjustment 1097 that cannot yet be computed. 1099 6.4 Stop Transmission 1100 This procedure is triggered by the arrival of a link state cue 1101 indicating the cessation of transmission to a specified remote LTP 1102 engine. 1104 Response: the de-queuing and delivery to the underlying communication 1105 system of segments from traffic queues bound for the LTP engine 1106 specified in the link state cue ceases. 1108 6.5 Suspend Timers 1110 This procedure is triggered by the arrival of a link state cue 1111 indicating the cessation of transmission from a specified remote LTP 1112 engine to the local LTP engine. Normally, this event is inferred 1113 from advance knowledge of the remote engine's planned transmission 1114 schedule. 1116 Response: countdown timers for the acknowledging segments that the 1117 remote engine is expected to return are suspended as necessary based 1118 on the following procedure. 1120 The nominal remote engine acknowledge transmission time is computed 1121 as the sum of the transmission time of the original segment (to which 1122 the acknowledging segment will respond) and the one-way light time to 1123 the remote engine, plus N seconds of "additional anticipated latency" 1124 (AAL) encompassing anticipated transmission delays other than signal 1125 propagation time. N is determined in an implementation-specific 1126 manner. For example, when LTP is deployed in deep space vehicles, 1127 the one-way light time to the remote engine may be very large while N 1128 may be relatively small, covering processing and queuing delays. N 1129 may be a network management parameter, for which 2 seconds seems like 1130 a reasonable default value. As another example, when LTP is deployed 1131 in a terrestrial "data mule" environment, one-way light time latency 1132 is effectively zero while N may need to be some dynamically computed 1133 function of the data mule circulation schedule. 1135 If the nominal remote engine acknowledge transmission time is greater 1136 than or equal to the current time (i.e., the acknowledging segment 1137 may be presented for transmission during the time that transmission 1138 at the remote engine is suspended), then the countdown timer for this 1139 acknowledging segment is suspended. 1141 6.6 Resume Timers 1143 This procedure is triggered by the arrival of a link state cue 1144 indicating the start of transmission from a specified remote LTP 1145 engine to the local LTP engine. Normally, this event is inferred 1146 from advance knowledge of the remote engine's planned transmission 1147 schedule. 1149 Response: expected arrival time is adjusted for every acknowledging 1150 segment that the remote engine is expected to return, for which the 1151 countdown timer has been suspended. First, the transmission delay 1152 interval is calculated as follows : 1154 The nominal remote engine acknowledge transmission time is 1155 computed as the sum of the transmission time of the original 1156 segment (to which the acknowledging segment will respond) and the 1157 one-way light time to the remote engine, plus N seconds of AAL 1158 [Sec 6.5]. 1160 If the nominal remote engine acknowledge transmission time is 1161 greater than the current time i.e., the remote engine resumed 1162 transmission prior to presentation of the acknowledging segment 1163 for transmission, then the transmission delay interval is zero. 1165 Otherwise, the transmission delay interval is computed as the 1166 current time less the nominal remote engine acknowledge 1167 transmission time. 1169 The expected arrival time is increased by the computed transmission 1170 delay interval for each of the suspended countdown timers, and the 1171 timers are resumed. 1173 6.7 Retransmit Checkpoint 1175 This procedure is triggered by the expiration of a countdown timer 1176 associated with a CP segment. 1178 Response: if the number of times this CP segment has been queued for 1179 transmission exceeds the checkpoint retransmission limit established 1180 for the local LTP engine by network management, then the session of 1181 which the segment is one token is canceled: the "Cancel session" 1182 procedure [Sec 6.19] is invoked, a CS with reason-code RLEXC is 1183 appended to the (conceptual) application data queue, and a 1184 transmission-session cancellation notice [Sec 7.5] is sent back to 1185 the client service that requested the transmission. 1187 Otherwise, a new copy of the CP segment is appended to the 1188 (conceptual) application data queue for the destination LTP engine. 1190 6.8 Retransmit RS 1191 This procedure is triggered by either (a) the expiration of a 1192 countdown timer associated with an RS segment or (b) the reception of 1193 a CP segment for which one or more RS segments were previously issued 1194 -- a redundantly retransmitted checkpoint. 1196 Response: if the number of times any affected RS segment has been 1197 queued for transmission exceeds the report retransmission limit 1198 established for the local LTP engine by network management, then the 1199 session of which the segment is one token is canceled: the "Cancel 1200 session" procedure [Sec 6.19] is invoked, a CR segment with reason- 1201 code RLEXC is queued for transmission to the LTP engine that 1202 originated the session, and a reception-session cancellation notice 1203 [Sec 7.6] is sent to the client service identified in each of the 1204 data segments received in this session. 1206 Otherwise, a new copy of each affected RS segment is queued for 1207 transmission to the LTP engine that originated the session. 1209 6.9 Signify Red-Part Reception 1211 This procedure is triggered by the arrival of a CP segment when the 1212 EORP for this session has been received (ensuring that the size of 1213 the data block's red-part is known; this includes the case where the 1214 CP segment itself is the EORP segment) and all data in the red-part 1215 of the block being transmitted in this session have been received. 1217 Response: a red-part reception notice [Sec 7.3] is sent to the 1218 specified client service. 1220 6.10 Signify Green-Part Segment Arrival 1222 This procedure is triggered by the arrival of a data segment whose 1223 content is a portion of the green-part of a block. 1225 Response: a green-part segment arrival notice [Sec 7.2] is sent to 1226 the specified client service. 1228 6.11 Send Reception Report 1230 This procedure is triggered by either (a) the original reception of a 1231 CP segment (the checkpoint serial number identifying this CP is new) 1232 (b) an implementation-specific circumstance pertaining to a 1233 particular block reception session for which no EORP has yet been 1234 received ("asynchronous" reception reporting). 1236 Response: if the number of reception problems detected for this 1237 session exceeds a limit established for the local LTP engine by 1238 network management, then the affected session is canceled: the 1239 "Cancel session" procedure [Sec 6.19] is invoked, a CR segment with 1240 reason-code RLEXC is issued and is, in concept, appended to the queue 1241 of internal operations traffic bound for the LTP engine that 1242 originated the session, and a reception-session cancellation notice 1243 [Sec 7.6] is sent to the client service identified in each of the 1244 data segments received in this session. One possible limit on 1245 reception problems would be the maximum number of reception reports 1246 which can be issued for any single session. 1248 If such a limit is not reached, a reception report is issued as 1249 follows. 1251 If production of the reception report was triggered by reception of a 1252 checkpoint: 1254 The upper bound of the report SHOULD be the upper bound (the sum 1255 of the offset and length) of the checkpoint data segment, to 1256 minimize unnecessary retransmission. Note: If a discretionary 1257 checkpoint is lost but subsequent segments are received, then by 1258 the time the retransmission of the lost checkpoint is received the 1259 receiver would have segments at block offsets beyond the upper 1260 bound of the checkpoint. For deployments where bandwidth economy 1261 is not critical, the upper bound of a synchronous reception report 1262 MAY be the maximum upper bound value among all red-part data 1263 segments received so far in the affected session. 1265 If the checkpoint was itself issued in response to a report 1266 segment, then this report is a "secondary" reception report. In 1267 that case the lower bound of the report SHOULD be the lower bound 1268 of the report segment to which the triggering checkpoint was 1269 itself a response, to minimize unnecessary retransmission. Note: 1270 For deployments where bandwidth economy is not critical, the lower 1271 bound of the report MAY instead be zero. 1273 If the checkpoint was not issued in response to a report segment, 1274 this report is a "primary" reception report. The lower bound of 1275 the first primary reception report issued for any session MUST be 1276 zero. The lower bound of each subsequent primary reception report 1277 issued for the same session SHOULD be the upper bound of the prior 1278 primary reception report issued for the session, to minimize 1279 unnecessary retransmission. Note: For deployments where bandwidth 1280 economy is not critical, the lower bound of every primary 1281 reception report MAY be zero. 1283 If production of the reception report is "asynchronous" as noted 1284 above: 1286 The upper bound of the report MUST be the maximum upper bound 1287 among all red-part data segments received so far for this session. 1289 The lower bound of the first asynchronous reception report issued 1290 for any session for which no other primary reception reports have 1291 yet been issued MUST be zero. The lower bound of each subsequent 1292 asynchronous reception report SHOULD be the upper bound of the 1293 prior primary reception report issued for the session, to minimize 1294 unnecessary retransmission. Note: For deployments where bandwidth 1295 economy is not critical, the lower bound of every asynchronous 1296 reception report MAY be zero. 1298 In all cases, if the applicable lower bound of the scope of a report 1299 is determined to be greater than or equal to the applicable upper 1300 bound (for example, due to out-of-order arrival of discretionary 1301 checkpoints) then the reception report MUST NOT be issued. Otherwise: 1303 As many RS segments must be produced as are needed in order to report 1304 on all data reception within the scope of the report, given whatever 1305 data size constraints are imposed by the underlying communication 1306 service. The RS segments are, in concept, appended to the queue of 1307 internal operations traffic bound for the LTP engine that originated 1308 the indicated session. The lower bound of the first RS segment of 1309 the report MUST be the reception report's lower bound. The upper 1310 bound of the last RS segment of the report MUST be the reception 1311 report's upper bound. 1313 6.12 Signify Transmission Completion 1315 This procedure is triggered at the earliest time at which (a) all 1316 data in the block are known to have been transmitted *and* (b) the 1317 entire red-part of the block - if of non-zero length - is known to 1318 have been successfully received. Condition (a) is signaled by 1319 arrival of a link state cue indicating the de-queuing (for 1320 transmission) of the EOB segment for the block. Condition (b) is 1321 signaled by reception of an RS segment whose reception claims, taken 1322 together with the reception claims of all other RS segments 1323 previously received in the course of this session, indicate complete 1324 reception of the red-part of the block. 1326 Response: a transmission-session completion notice [Sec 7.4] is sent 1327 to the local client service associated with the session, and the 1328 session is closed: the "Close session" procedure [Sec 6.20] is 1329 invoked. 1331 6.13 Retransmit Data 1333 This procedure is triggered by the reception of an RS segment. 1335 Response: first, an RA segment with the same report serial number as 1336 the RS segment is issued and is, in concept, appended to the queue of 1337 internal operations traffic bound for the Receiver. If the RS 1338 segment is redundant -- i.e., either the indicated session is unknown 1339 (for example, the RS segment is received after the session has been 1340 completed or canceled) or the RS segment's report serial number 1341 matches that of an RS segment that has already been received and 1342 processed -- then no further action is taken. Otherwise the 1343 procedure below is followed. 1345 If the report's checkpoint serial number is not zero, then the 1346 countdown timer associated with the indicated checkpoint segment is 1347 deleted. 1349 Note: All retransmission buffer space occupied by data whose 1350 reception is claimed in the report segment can (in concept) be 1351 released. 1353 If the segment's reception claims indicate incomplete data reception 1354 within the scope of the report segment: 1356 If the number of transmission problems for this session exceeds a 1357 limit established for the local LTP engine by network management, 1358 then the session of which the segment is one token is canceled: 1359 the "Cancel session" procedure [Sec 6.19] is invoked, a CS with 1360 reason-code RLEXC is appended to the transmission queue specified 1361 in the transmission request that started this session, and a 1362 transmission-session cancellation notice [Sec 7.5] is sent back to 1363 the client service that requested the transmission. One possible 1364 limit on transmission problems would be the maximum number of 1365 retransmission CP segments which may be issued for any single 1366 session. 1368 If the number of transmission problems for this session has not 1369 exceeded any limit, new data segments encapsulating all block data 1370 whose non-reception is implied by the reception claims are 1371 appended to the transmission queue bound for the Receiver. The 1372 last - and only the last - data segment must be marked as a CP 1373 segment carrying a new CP serial number (obtained by incrementing 1374 the last CP serial number used) and the report serial number of 1375 the received RS segment. 1377 6.14 Stop RS Timer 1379 This procedure is triggered by the reception of an RA. 1381 Response: the countdown timer associated with the original RS segment 1382 (identified by the report serial number of the RA segment) is 1383 deleted. If no other countdown timers associated with RS segments 1384 exist for this session, then the session is closed: the "Close 1385 session" procedure [Sec 6.20] is invoked. 1387 6.15 Start Cancel Timer 1389 This procedure is triggered by arrival of a link state cue indicating 1390 the de-queuing (for transmission) of a Cx segment. 1392 Response: the expected arrival time of the CAx segment that will be 1393 produced on reception of this Cx segment is computed and a countdown 1394 timer for this arrival time is started. However, if it is known that 1395 the remote LTP engine has ceased transmission [Sec 6.5] then this 1396 timer is immediately suspended, because the computed expected arrival 1397 time may require an adjustment that cannot yet be computed. 1399 6.16 Retransmit Cancellation Segment 1401 This procedure is triggered by the expiration of a countdown timer 1402 associated with a Cx segment. 1404 Response: if the number of times this Cx segment has been queued for 1405 transmission exceeds the cancellation retransmission limit 1406 established for the local LTP engine by network management, then the 1407 session of which the segment is one token is simply closed: the 1408 "Close session" procedure [Sec 6.20] is invoked. 1410 Otherwise, a copy of the cancellation segment (retaining the same 1411 reason-code) is queued for transmission to the appropriate LTP 1412 engine. 1414 6.17 Acknowledge Cancellation 1416 This procedure is triggered by the reception of a Cx segment. 1418 Response: in the case of a CS segment where there is no transmission 1419 queue-set bound for the Sender (possibly because the Receiver is a 1420 receive-only device), then no action is taken. Otherwise: 1422 If the received segment is a CS segment, a CAS (Cancel 1423 acknowledgment to block sender) segment is issued and is, in 1424 concept, appended to the queue of internal operations traffic 1425 bound for the Sender. 1427 If the received segment is a CR segment, a CAR (Cancel 1428 acknowledgment to block receiver) segment is issued and is, in 1429 concept, appended to the queue of internal operations traffic 1430 bound for the Receiver. 1432 It is possible that the Cx segment has been retransmitted because a 1433 previous responding acknowledgment CAx (Cancel acknowledgment) 1434 segment was lost, in which case there will no longer be any record of 1435 the session of which the segment is one token. If so, no further 1436 action is taken. 1438 Otherwise: the "Cancel session" procedure [Sec 6.19] is invoked and a 1439 reception-session cancellation notice [Sec 7.6] is sent to the client 1440 service identified in each of the data segments received in this 1441 session. Finally, the session is closed: the "Close session" 1442 procedure [Sec 6.20] is invoked. 1444 6.18 Stop Cancel Timer 1446 This procedure is triggered by the reception of a CAx segment. 1448 Response: the timer associated with the Cx segment is deleted, and 1449 the session of which the segment is one token is closed, i.e., the 1450 "Close session" procedure [Sec 6.20] is invoked. 1452 6.19 Cancel Session 1454 This procedure is triggered internally by one of the other procedures 1455 described above. 1457 Response: all segments of the affected session that are currently 1458 queued for transmission can be deleted from the outbound traffic 1459 queues. All countdown timers currently associated with the session 1460 are deleted. Note: If the local LTP engine is the Sender, then all 1461 remaining data retransmission buffer space allocated to the session 1462 can be released. 1464 6.20 Close Session 1466 This procedure is triggered internally by one of the other procedures 1467 described above. 1469 Response: any remaining countdown timers associated with the session 1470 are deleted. The session state record (SSR|RSR) for the session is 1471 deleted; existence of the session is no longer recognized. 1473 6.21 Handle Miscolored Segment 1475 This procedure is triggered by the arrival of either (a) a red-part 1476 data segment whose block offset begins at an offset higher than the 1477 block offset of any green-part data segment previously received for 1478 the same session or (b) a green-part data segment whose block offset 1479 is lower than the block offset of any red-part data segment 1480 previously received for the same session. The arrival of a segment 1481 matching either of the above checks is a violation of the protocol 1482 requirement of having all red-part data as the block prefix and all 1483 green-part data as the block suffix. 1485 Response: the received data segment is simply discarded. 1487 The Cancel Session procedure [Sec 6.19] is invoked and a CR segment 1488 with reason-code MISCOLORED SHOULD be enqueued for transmission to 1489 the data sender. 1491 Note: If there is no transmission queue-set bound for the Sender 1492 (possibly because the local LTP engine is running on a receive-only 1493 device), or if the Receiver knows that the Sender is functioning in a 1494 "beacon" (transmit-only) fashion, a CR segment need not be sent. 1496 A Reception-Session Cancellation Notice [Sec 7.6] is sent to the 1497 client service. 1499 6.22 Handling System Error Conditions 1501 It is possible (especially for long-lived LTP sessions) that an 1502 unexpected operating-system error condition may occur during the 1503 lifetime of an LTP session. An example is the case where the system 1504 faces severe memory crunch forcing LTP sessions into a scenario 1505 similar to that of TCP SACK [SACK] reneging. But unlike TCP SACK 1506 reception reports, which are advisory, LTP reception reports are 1507 binding, and reneging is NOT permitted on previously made reception 1508 claims. 1510 Under any such irrecoverable system error condition, the following 1511 response is to be initiated: the Cancel Session procedure [Sec 6.19] 1512 is invoked. If the error condition is observed on the Sender, a CS 1513 segment with reason-code SYS_CNCLD SHOULD be enqueued for 1514 transmission to the Receiver, and a Transmission-Session Cancellation 1515 Notice [Sec 7.5] is sent to the client service; on the other hand, if 1516 it is observed on the Receiver, a CR segment with the same reason- 1517 code SYS_CNCLD SHOULD be enqueued for transmission to the Sender, and 1518 a Reception-Session Cancellation Notice [Sec 7.6] is sent to the 1519 client service. 1521 Note that as in Sec 6.21, if there is no transmission queue-set bound 1522 for the Sender (possibly because the local LTP engine is running on a 1523 receive-only device), or if the Receiver knows that the sender of 1524 this green-part data is functioning in a "beacon" (transmit-only) 1525 fashion, a CR segment need not be sent. 1527 There may be other implementation-specific limits which may cause an 1528 LTP implementation to initiate session-cancellation procedures. One 1529 such limit is the maximum number of retransmission-cycles seen. A 1530 retransmission cycle at the LTP Sender comprises the two related 1531 events: the transmission of all outstanding CP segments from the 1532 Sender, and the reception of all RS segments issued from the Receiver 1533 in response to those CP segments. A similar definition would apply 1534 at the LTP Receiver but relate to the reception of the CP segments 1535 and transmission of all RS segments in response. Note that the 1536 retransmitted CP and RS segments remain part of their original 1537 retransmission-cycle. Also, a single CP segment may cause multiple 1538 RS segments to be generated if a Reception Report would not fit in a 1539 single datalink-MTU-sized RS segment; all RS segments that are part 1540 of a Reception Report belong to the same retransmission cycle to 1541 which the CP segment belongs. In the presence of severe channel 1542 error conditions, many retransmission cycles may elapse before red- 1543 part transmission is deemed successful; an implementation may 1544 therefore impose a retransmission-cycle limit to shield itself from a 1545 resource-crunch situation. If a sender LTP notices the 1546 retransmission-cycle limit being exceeded, it SHOULD initiate the 1547 Cancel Session Procedure [Sec 6.19], queuing a CS segment with 1548 reason-code RXMTCYCEXC and sending a Transmission-Session 1549 Cancellation Notice [Sec 7.5] to the client service. 1551 7. Notices to Client Service 1553 In all cases the representation of notice parameters is a local 1554 implementation matter. 1556 7.1 Session Start 1558 The Session Start notice returns the Session ID identifying a newly 1559 created session. 1561 At the Sender, the session start notice informs the client service of 1562 the initiation of the transmission session. On receiving this notice 1563 the client service may, for example, release resources of its own 1564 that are allocated to the block being transmitted, or remember the 1565 session ID so that the session can be canceled in the future if 1566 necessary. At the Receiver, this notice indicates the beginning of a 1567 new reception session, and is delivered upon arrival of the first 1568 data segment carrying a new Session ID. 1570 7.2 Green-Part Segment Arrival 1572 The following parameters are provided by the LTP engine when a green- 1573 part segment arrival notice is delivered: 1575 Session ID of the transmission session. 1577 Array of client service data bytes contained in the data segment. 1579 Offset of the data segment's content from the start of the block. 1581 Length of the data segment's content. 1583 Indication as to whether or not the last byte of this data 1584 segment's content is also the end of the block. 1586 Source LTP engine ID. 1588 7.3 Red-Part Reception 1590 The following parameters are provided by the LTP engine when a red- 1591 part reception notice is delivered: 1593 Session ID of the transmission session. 1595 Array of client service data bytes that constitute the red-part of 1596 the block. 1598 Length of the red-part of the block. 1600 Indication as to whether or not the last byte of the red-part is 1601 also the end of the block. 1603 Source LTP engine ID. 1605 7.4 Transmission-Session Completion 1606 The sole parameter provided by the LTP engine when a transmission- 1607 session completion notice is delivered is the session ID of the 1608 transmission session. 1610 A transmission-session completion notice informs the client service 1611 that all bytes of the indicated data block have been transmitted, and 1612 that the Receiver has received the red-part of the block. 1614 7.5 Transmission-Session Cancellation 1616 The parameters provided by the LTP engine when a transmission-session 1617 cancellation notice is delivered are: 1619 Session ID of the transmission session. 1621 The reason-code sent or received in the Cx segment that initiated 1622 the cancellation sequence. 1624 A transmission-session cancellation notice informs the client service 1625 that the indicated session was terminated, either by the Receiver or 1626 else due to an error or a resource quench condition in the local LTP 1627 engine. There is no assurance that the destination client service 1628 instance received any portion of the data block. 1630 7.6 Reception-Session Cancellation 1632 The parameters provided by the LTP engine when a reception 1633 cancellation notice is delivered are: 1635 Session ID of the transmission session. 1637 The reason-code explaining the cancellation. 1639 A reception-session cancellation notice informs the client service 1640 that the indicated session was terminated, either by the Sender or 1641 else due to an error or a resource quench condition in the local LTP 1642 engine. No subsequent delivery notices will be issued for this 1643 session. 1645 7.7 Initial-Transmission Completion 1647 The session ID of the transmission session is included with the 1648 initial-transmission completion notice. 1650 This notice informs the client service that all segments of a block 1651 (both red-part and green-part) have been transmitted. This notice 1652 only indicates that original transmission is complete; retransmission 1653 of any lost red-part data segments may still be necessary. 1655 8. State Transition Diagrams 1657 The following mnemonics have been used in the sender and receiver LTP 1658 state transition diagrams that follow : 1660 TE Timer Expiry 1661 RDS Regular Red Data Segment (NOT {CP|EORP|EOB}) 1662 GDS Regular Green Data Segment (NOT EOB) 1663 RL EXC Retransmission Limit Exceeded 1664 RP Red-Part 1665 GP Green-Part 1666 FG Fully-Green 1668 Note that blocks represented in rectangles, as in 1670 +---------+ 1671 | FG_XMIT | 1672 +---------+ 1674 specify actual states in the state-transition diagrams, while blocks 1675 represented with jagged edges, as in 1677 /\/\/\/\ 1678 | Cncld | 1679 \/\/\/\/ 1681 are either pointers to a state or place-holders for sequences of 1682 state transitions. 1684 8.1 Sender 1685 LTP Sender State Transition Diagram 1687 /\/\/\/\ 1688 | Cncld | 1689 \/\/\/\/ 1690 +--------+ | +------+ 1691 Rcv CR; | V V V | Rcv RS; 1692 Snd CAR | +-------------+ | Snd RA 1693 +-------+ CLOSED +----+ 1694 +---------------------------->+------+------+ 1695 | | Blk. Trans. Req 1696 | Zero RP + 1697 | Xmit ________________________/ \ Non-Zero RP 1698 | GDS; / \ 1699 | +---+ | +------------------+ | +------+ 1700 | | V V | /\/\ Rcv RS V V V | 1701 | | +---------+ +<-| RX |<---+ +---------+ | 1702 | +<-+ FG_XMIT | | \/\/ +---+ +--->+ Xmit RDS; 1703 | +----+----+ | | RP_XMIT | | 1704 | | | /\/\ +---+ +--->+ Xmit {RDS, CP}; 1705 +<--------+ +<-| CP |<---+ +-----+---+ Start CP Tmr 1706 | Xmit \/\/ CP TE | \ 1707 | {GDS, EOB}; | | 1708 | Xmit {RDS, CP, EORP}; | +-------+ 1709 | Start CP Tmr | | 1710 | | | 1711 | +------------------+ | +---+ | Xmit {RDS, 1712 | | /\/\ Rcv RS V V V | | CP, EORP, 1713 | +<-| RX |<---+ +---------+ | | EOB}; 1714 | | \/\/ +---+ | | | Start 1715 | | | GP_XMIT +->+ | CP Tmr 1716 | | /\/\ +---+ | Xmit | 1717 | +<-| CP |<---+ +-----+---+ GDS; | 1718 | \/\/ CP TE | | 1719 | | | 1720 | Xmit {GDS, EOB}; | +---------+ 1721 | | | 1722 | +------------------+ | | 1723 | | /\/\ Rcv RS V V V 1724 | +<-| RX |<---+ +-------------+ 1725 | | \/\/ +---+ | 1726 | | | WAIT_RP_ACK | 1727 | | /\/\ +---+ | 1728 | +<-| CP |<---+ +-----+-------+ 1729 | \/\/ CP TE | RP acknowledged fully; 1730 | V 1731 +----------------------------------------+ 1732 LTP Sender State Transition Diagram (contd.) 1734 /\/\ /\/\ 1735 |CP| |CX | 1736 \/\/ \/\/ 1737 | | | Snd CS, 1738 | | RL EXC; | Start CS Tmr; 1739 | | | 1740 | | /\/\ | +---+ 1741 | +------>| CX | V V | 1742 | \/\/ +---------+ | CS TE, 1743 | | CS_SENT | | RL NOT EXC; 1744 V RL NOT EXC; +-+--+--+-+ | Rxmt CS, 1745 Rxmt CP, | | | | Restart 1746 Start CP Tmr; CS TE, | | +---+ CS Tmr 1747 RL EXC; | | 1748 | | Rcv CAS; 1749 V V 1750 /\/\/\/\ 1751 | Cncld | 1752 \/\/\/\/ 1754 /\/\ 1755 | RX | 1756 \/\/ 1757 | Cncl CP Tmr (if any) 1758 V Snd RA 1759 +---------+ +----+ 1760 | CHK_RPT | | | 1761 +-+--+----+ RP in scope V | 1762 | | \ NOT rcvd. fully +---------+ | Rxmt 1763 Redundant | | RP +--------------------->| RP_RXMT | | missing 1764 RS rcvd; | | in scope +----+--+-+ | RDS; 1765 | | rcvd. fully | | | 1766 V V Rxmt last | +----+ 1767 missing RDS | 1768 (marked CP) | 1769 Start CP Tmr; | 1770 V 1771 Asynchronous cancel request may be received from the local client 1772 service while the sender LTP is in any of the states shown. If it 1773 was not already in the sequence of state transitions beginning at the 1774 CX marker, the internal procedure Cancel Session [Sec 6.19] is 1775 followed, and the sender LTP moves from its current state into the 1776 sequence beginning at the CX marker initiating session cancellation 1777 with reason-code USR_CNCLD. From the CX marker, the CS segment with 1778 appropriate reason-code (USR_CNCLD or RLEXC depending on how the CX 1779 sequence was entered) is queued for transmission to the receiver LTP 1780 and the sender enters the Cancel-from-Sender Sent(CS_SENT) state. 1781 The internal procedure Start Cancel Timer [Sec 6.15] is started upon 1782 receiving a link-state cue indicating the beginning of transmission 1783 of the CS segment. Upon receiving the acknowledging CAS segment from 1784 the receiver, the sender LTP moves to the CLOSED state (via the 1785 'Cncld' pointer). If the CS Timer expires, the internal procedure 1786 Retransmit Cancellation Segment [Sec 6.16] is followed: 1788 If the network management set retransmission limit is exceeded, 1789 the session is simply closed and the sender LTP follows the Cncld 1790 marker to the CLOSED state. If the retransmission limit is not 1791 exceeded however, the CS segment is queued for a retransmission 1792 and the sender LTP stays in the CS_SENT state. The CS Timer is 1793 started upon receiving a link-state cue indicating the beginning 1794 of actual transmission according to the internal procedure Start 1795 Cancel Timer [Sec 6.15]. 1797 Asynchronous cancel request may also be received from the receiver 1798 LTP in the form of a CR segment when the sender LTP is in any of the 1799 states. Upon receiving such a CR segment, the internal procedure 1800 Acknowledge Cancellation [Sec 6.17] is invoked: The sender LTP sends 1801 a CAR segment in response and returns to the CLOSED state. 1803 The sender LTP stays in the CLOSED state until receiving a Block 1804 Transmission Request (Blk. Trans. Req) from the client service 1805 instance. Upon receiving the request it either moves to the Fully 1806 Green Transmission State (FG_XMIT) if no portion of the block was 1807 requested to be transmitted as red, or to the Red-Part Transmission 1808 State (RP_XMIT) state if a non-zero block-prefix was requested to be 1809 transmitted red. 1811 In the FG_XMIT state, the block is segmented as multiple green LTP 1812 data segments respecting the link MTU size and the segments are 1813 queued for transmission to the remote engine. The last such segment 1814 is marked as EOB and the sender LTP returns to the CLOSED state after 1815 queuing it for transmission. 1817 Similarly, from the RP_XMIT state multiple red data segments are 1818 queued for transmission, respecting the link MTU size. The sender 1819 LTP may optionally mark some of the red data segments as asynchronous 1820 checkpoints; the internal procedure Start Checkpoint Timer [Sec 6.2] 1821 is followed upon receiving a link-state cue indicating the 1822 transmission of the asynchronous checkpoints. If the block 1823 transmission request comprises a non-zero Green Part, the sender LTP 1824 marks the last red-data segment as CP and EORP, and after queuing it 1825 for transmission, moves to the Green Part Transmission (GP_XMIT) 1826 state. If the block transmission request was fully red however, the 1827 last red-data segment is marked as CP, EORP, and EOB and the sender 1828 LTP moves directly to the Wait-for-Red-Part-Acknowledgment 1829 (WAIT_RP_ACK) state. In both the above state-transitions, the 1830 internal procedure Start Checkpoint Timer [Sec 6.2] is followed upon 1831 receiving a link-state cue indicating the beginning of transmission 1832 of the queued CP segments. In the GP_XMIT state, the green-part of 1833 the block is segmented as green data segments and queued for 1834 transmission to the receiver LTP; the last green segment of the block 1835 is additionally marked as EOB, and after queueing it for transmission 1836 the sender LTP moves to the WAIT_RP_ACK state. 1838 While the sender LTP is at any of the RP_XMIT, GP_XMIT, or 1839 WAIT_RP_ACK states, it might be interrupted by the occurrence of the 1840 following events: 1842 1. An RS might be received from the receiver LTP (either in 1843 response to a previously transmitted CP segment or sent 1844 asynchronously for accelerated retransmission). The sender LTP 1845 then moves to perform the sequence of state transitions beginning 1846 at the RX marker (second-part of the diagram), and retransmits 1847 data if necessary, illustrating the internal procedure Retransmit 1848 Data [Sec 6.13]: 1850 First, if the RS segment had a non-zero CP serial number, the 1851 corresponding CP timer is canceled. Then an RA segment 1852 acknowledging the received RS segment is queued for transmission 1853 to the receiver LTP and the sender LTP moves to the Check Report 1854 state (CHK_RPT). If the RS segment was redundantly transmitted by 1855 the receiver LTP (possibly because either the last transmitted RA 1856 segment got lost or the RS segment timer expired prematurely at 1857 the receiver), the sender LTP does nothing more and returns back 1858 to the interrupted state. Similarly, if all red-data within the 1859 scope of the RS segment is reported as received, there is no work 1860 to be done and the sender LTP returns to the interrupted state. 1861 However, if the RS segment indicated incomplete reception of data 1862 within its scope, the sender LTP moves to the Red-part Retransmit 1863 state (RP_RXMT) where missing red data-segments within scope are 1864 queued for transmission. The last such segment is marked as a CP, 1865 and the sender LTP returns to the interrupted state. The internal 1866 procedure [Sec 6.2] is followed upon receiving a link-state cue 1867 indicating the beginning of transmission of the CP segment. 1869 2. A previously set CP timer might expire. Now the sender LTP 1870 follows the states beginning at the CP marker (second-part of the 1871 diagram), and follows the internal procedure Retransmit Checkpoint 1872 [Sec 6.7]: 1874 If the CP Retransmission Limit set by network management for the 1875 session has been exceeded, the sender LTP proceeds towards 1876 canceling the session (with reason-code RLEXC) as indicated by the 1877 sequence of state transitions following the CX marker. Otherwise 1878 (if the Retransmission Limit is not exceeded yet), the CP segment 1879 is queued for retransmission and the sender LTP returns to the 1880 interrupted state. The Start Checkpoint Timer internal procedure 1881 [Sec 6.2] is started again upon receiving a link-state cue 1882 indicating the beginning of transmission of the segment. 1884 The sender LTP stays at the WAIT_RP_ACK state after reaching it until 1885 the red-part data is fully acknowledged as received by the receiver 1886 LTP, and then returns to the CLOSED state following the internal 1887 procedure Close Session [Sec 6.20]. 1889 Note that while at the CLOSED state, the sender LTP might receive an 1890 RS segment (if the last transmitted RA segment before session close 1891 got lost or if the receiver LTP retransmitted the RS segment 1892 prematurely), in which case it retransmits an acknowledging RA 1893 segment and stays in the CLOSED state. If the session was canceled 1894 by the Receiver by issuing a CR segment, the receiver may retransmit 1895 the CR segment (either prematurely or because the acknowledging CAR 1896 segment got lost). In this case, the sender LTP retransmits the 1897 acknowledging CAR segment and stays in the CLOSED state. 1899 8.2 Receiver 1900 LTP Receiver State Transition Diagram 1902 /\/\/\/\ 1903 +----+ +----+ Cncld | 1904 Rcv CS; | V V \/\/\/\/ 1905 Snd CAS | +-------------+ 1906 +--+ CLOSED +<--------------------------+ 1907 +------+------+ | 1908 +----+ | Rcv first DS | 1909 Rcv RA; | V V | 1910 Cncl RS Tmr | +--------+ | 1911 +---+ DS_REC | | 1912 +----------------------------->+-+--+-+-+<----------------------+---+ | 1913 | Svc. does not exist | | | RS TE | | | 1914 | /\/\ or Rcv miscolored seg. | | | /\/\ | | | 1915 | | CX |<-----------------------+ | +------------->| RX |---->+ | | 1916 | \/\/ | \/\/ | | 1917 | Rcv RDS; | Rcv GDS; | | 1918 | +-----------+------------+ | | 1919 | V V | | 1920 | /\/\ RS TE +--------------+ +--------+ | | 1921 +<-| RX |<------+ RCV_RP | | RCV_GP | | | 1922 | \/\/ +-+----+--+--+-+ +--+-+-+-+ | | 1923 | | | | | | | | | | 1924 | Rcvd RDS; | | | | Rcvd {RDS, CP, | | | RS TE /\/\ | | 1925 | | | | | EORP, EOB}; | | +------>| RX |->+ | 1926 +<----------------+ | | | Snd RS, | | \/\/ | | 1927 | | | | Start RS Tmr | | Rcvd GDS; | | 1928 | Rcvd {RDS, CP}; | | | | +---------------->+ | 1929 | Snd RS, Start RS Tmr | | +-------+ +-----+ | 1930 +<---------------------+ | | | Rcvd {GDS, EOB}; | 1931 | | | | | 1932 | | +-----+ | | +------+ | 1933 | Rcvd {RDS, CP, EORP}; | | V V V V | | 1934 | Snd RS, Start RS Tmr | | +----------------+ | Rcv RDS; | 1935 | | | | +-->+ | 1936 | | | | WAIT_RP_REC | | Rcv {RDS, CP}; | 1937 | | | | +-->+ Snd RS, Start | 1938 +<------------------------+ | +---+--+-+-+-----+ | RS Tmr | 1939 | RS TE | | | | Rcv RA; | | 1940 | V | | | Cncl | | 1941 | /\/\ | | | RS Tmr | | 1942 +---| RX | | | +-------->+ | 1943 \/\/ | | | 1944 /\/\ | | | 1945 | CX |<------------------------+ | RP rcvd. fully | 1946 \/\/ Rcv miscolored seg. +--------------------------->+ 1947 LTP Receiver State Transition Diagram (contd.) 1949 /\/\ 1950 | RX | 1951 \/\/ 1952 | | 1953 | | RL EXC; /\/\ 1954 RL NOT EXC; | +---------->| CX | 1955 Rxmt RS, | \/\/ 1956 Start RS Tmr | 1957 V 1959 /\/\ 1960 | CX | 1961 \/\/ 1962 | Snd CR, 1963 | Start CR Tmr; 1964 | 1965 | +----+ 1966 V V | 1967 +---------+ | CR TE, 1968 | CR_SENT | | RL NOT EXC; 1969 +-+--+--+-+ | Rxmt CR, 1970 | | | | Restart 1971 CR TE, | | +---+ CR Tmr 1972 RL EXC; | | 1973 | | Rcv CAR; 1974 V V 1975 /\/\/\/\ 1976 | Cncld | 1977 \/\/\/\/ 1978 Asynchronous cancel requests are handled in a manner similar to the 1979 way they are handled in the sender LTP. If the cancel request was 1980 made from the local client service instance and the receiver LTP was 1981 not already in the CR_SENT state, a CR segment with reason-code 1982 USR_CNCLD SHOULD be sent to the sender LTP following the sequence of 1983 state transitions beginning at the CX marker as described above. If 1984 the asynchronous cancel request is received from the sender LTP, a 1985 CAS segment is sent and the receiver LTP moves to the CLOSED state 1986 (independent of the state the receiver LTP may be in). 1988 The receiver LTP begins at the CLOSED state and enters the Data 1989 Segment Reception (DS_REC) state upon receiving the first data 1990 segment. If the client service ID referenced in the data segment was 1991 non-existent, a Cx segment with reason-code UNREACH SHOULD be sent to 1992 the sender LTP via the Cancellation sequence beginning with the CX 1993 marker (second part of the diagram). If the received segment was 1994 found to be miscolored, the internal procedure Handle Miscolored 1995 Segment [Sec 6.21] is followed, and a CX segment with reason-code 1996 MISCOLORED SHOULD be sent to the sender LTP with the Cancellation 1997 sequence beginning with the CX marker. 1999 Otherwise, the receiver LTP enters the Receive Red-Part state 2000 (RCV_RP) or the Receive Green-Part state (RCV_GP) depending on 2001 whether the segment received was red or green, respectively. 2003 In the RCV_RP state, a check is made of the nature of the received 2004 red DS. If the segment was a regular red data segment, the receiver 2005 LTP just returns to the DS_REC state. For red data segments marked 2006 also as CP and as CP & EORP, a responding RS segment is queued for 2007 transmission to the sender following either the internal procedure 2008 Retransmit RS [Sec 6.8] or Send Reception Report [Sec 6.11] depending 2009 on whether the CP segment was a retransmission (An RS segment 2010 corresponding to the Checkpoint Serial Number in the CP segment was 2011 previously issued) or not, respectively. The receiver LTP then 2012 returns to the DS_REC state. If the block transmission was fully red 2013 and the segment was marked as CP, EORP, and EOB, the receiver LTP 2014 enters the Wait-for-Red-Part-Reception state (WAIT_RP_REC). In all 2015 cases the internal procedure Start RS Timer [Sec 6.3] is followed 2016 upon receiving link-state cues indicating beginning of transmission 2017 of the RS segments. 2019 In the RCV_GP state, if the received green data segment was not 2020 marked EOB, the receiver LTP returns to the DS_REC state. Otherwise 2021 it enters the WAIT_RP_REC state to receive the red-part of the block 2022 fully. 2024 A previously set RS timer may expire and interrupt the receiver LTP 2025 while in the DS_REC, RCV_RP, RCV_GP, or WAIT_RP_REC states. If so, 2026 the internal procedure Retransmit RS [Sec 6.8] is followed as 2027 illustrated in the states beginning at the RX marker (shown in the 2028 second part of the diagram) before returning to the interrupted 2029 state: 2031 A check is made here to see if the retransmission limit set by the 2032 network management has been exceeded in the number of RSs sent in 2033 the session. If so, a CR segment with reason-code RLEXC SHOULD be 2034 sent to the sender LTP and the sequence indicated by the CX marker 2035 is followed. Otherwise, the RS segment is queued for 2036 retransmission and the associated RS timer is started following 2037 the internal procedure Start RS Timer [Sec 6.3] upon receiving a 2038 link-state cue indicating the beginning of its transmission. 2040 The receiver LTP may also receive RA segments from the sender in 2041 response to the RS segments sent while in the DS_REC state. If so, 2042 then the RS timer corresponding to the report serial number mentioned 2043 in the RA segment is canceled following the internal procedure Stop 2044 RS Timer [Sec 6.14]. 2046 The receiver LTP stays in the WAIT_RP_REC state until the entire red- 2047 part of the block is received, and moves to the CLOSED state upon 2048 full red-part reception. In this state, a check is made upon 2049 reception of every red-part data segment to see if it is at a block 2050 offset higher than any green-part data segment received. If so, the 2051 Handle Miscolored Segment internal procedure [Sec 6.21] is invoked 2052 and the sequence of state transitions beginning with the CX marker is 2053 followed; a CX segment with reason-code MISCOLORED SHOULD be sent to 2054 the sender LTP with the Cancellation sequence beginning with the CX 2055 marker. 2057 Note that if there were no red data segments received in the session 2058 yet, including the case where the session was indeed fully green or 2059 the pathological case where the entire red-part of the block gets 2060 lost but at least the green data segment marked EOB is received (the 2061 receiver LTP has no indication of whether the session had a red-part 2062 transmission), the receiver LTP assumes the "RP rcvd. fully" 2063 condition to be true and moves to the CLOSED state from the 2064 WAIT_RP_REC state. 2066 In the WAIT_RP_REC state, the receiver LTP may receive the 2067 retransmitted red data segments. Upon receiving red data segments 2068 marked CP, it queues the responding RS segment for transmission based 2069 on either internal procedure Retransmit RS [Sec 6.8] or Send 2070 Reception Report [Sec 6.11] depending on whether the CP was found to 2071 be a retransmission or not, respectively. The Start RS Timer 2072 internal procedure is invoked upon receiving a link-state cue 2073 indicating the beginning of transmission of the RS segment. If an RA 2074 segment is received, the RS timer corresponding to the report segment 2075 mentioned is canceled and the receiver LTP stays in the state until 2076 the entire red-part is received. 2078 In the sequence of state transitions beginning at the CX marker, the 2079 CR segment with the given reason-code (depending on how the sequence 2080 is entered) is queued for transmission, and the CR timer is started 2081 upon reception of the link-state cue indicating actual transmission 2082 following internal procedure Start Cancel Timer [Sec 6.15]. If the 2083 CAR segment is received from the sender LTP, the receiver LTP returns 2084 to the CLOSED state (via the Cncld marker) following the Stop Cancel 2085 Timer internal procedure [Sec 6.18]. If the CR timer expires 2086 asynchronously, the internal procedure Retransmit Cancellation 2087 Segment [Sec 6.16] is followed : 2089 A check is made to see if the retransmission limit set by the 2090 network management for the number of CR segments per session has 2091 been exceeded. If so, the receiver LTP returns to the CLOSED 2092 state following the Cncld marker. Otherwise, a CR segment is 2093 scheduled for retransmission with the CR timer being started 2094 following the internal procedure Start Cancel Timer [Sec 6.15] 2095 upon reception of a link-state cue indicating actual transmission. 2097 The receiver LTP might also receive a retransmitted CS segment at the 2098 CLOSED state (either if the CAS segment previously transmitted was 2099 lost or if the CS timer expired prematurely at the sender LTP). In 2100 such a case the CAS is scheduled for retransmission. 2102 9. Security Considerations 2104 9.1 Denial of Service Considerations 2106 Implementers SHOULD consider the likelihood of the following DoS 2107 attacks : 2109 A fake Cx could be inserted, thus bringing down a session. 2111 Various acknowledgment segments (RA, RS, etc.) could be deleted, 2112 causing timers to expire, and having the potential to disable 2113 communication altogether if done with a knowledge of the 2114 communications schedule. This could be achieved either by 2115 mounting a DoS attack on a lower layer service in order to prevent 2116 it from sending an acknowledgment segment, or by simply jamming 2117 the transmission (all of which are more likely for terrestrial 2118 applications of LTP). 2120 An attacker might also corrupt some bits, which is tantamount to 2121 deleting that segment. 2123 An attacker may flood a node with segments for the internal 2124 operations queue and prevent transmission of legitimate data 2125 segments. 2127 An attacker could attempt to fill up the storage in a node by 2128 sending many large messages to it. In terrestrial LTP 2129 applications this may be much more serious since spotting the 2130 additional traffic may not be possible from any network management 2131 point. 2133 LTP includes the following anti-DoS mechanisms: 2135 Session numbers SHOULD be partly random making it harder to insert 2136 valid segments. 2138 A node which suspects that either it or its peer is under DoS 2139 attack could frequently checkpoint its data segments (if it were 2140 the sender) or send asynchronous RSs (if it were the receiver), 2141 thus eliciting an earlier response from its peer or timing out 2142 earlier due to the failure of an attacker to respond. 2144 Serial numbers (checkpoint serial numbers, report serial numbers) 2145 MUST begin each session anew using random numbers rather than from 2146 0. 2148 The authentication header [LTPEXT]. 2150 9.2 Replay Handling 2152 The following algorithm is given as an example of how an LTP 2153 implementation MAY handle replays. 2155 1. On receipt of an LTP segment, check against a cache for replay. 2156 If this is a replay segment and if a pre-cooked response is available 2157 (stored from the last time this segment was processed), then send the 2158 pre-cooked response. If there is no pre-cooked response then 2159 silently drop the inbound segment. This can all be done without 2160 attempting to decode the buffer. 2162 2. If the inbound segment does not decode correctly, then silently 2163 drop the segment. If the segment decodes properly, then add its hash 2164 to the replay cache and return a handle to the entry. 2166 3. For those cases where a pre-cooked response should be stored, 2167 store the response using the handle received from the previous step. 2168 These cases include: 2170 (a) when the inbound packet is a CP segment the RS segment sent in 2171 response gets stored as pre-cooked; 2173 (b) when the incoming packet is an RS segment the RA segment is 2174 stored as precooked, and, 2176 (c) when the incoming packet is a Cx segment the CAx segment sent 2177 in response gets stored precooked. 2179 4. Occasionally clean out the replay cache - how frequently this 2180 happens in an implementation issue. 2182 The downside of this algorithm is that receiving a totally bogus 2183 segment still results in a replay cache search and attempted LTP 2184 decode operation. It is not clear that it is possible to do much 2185 better though, since all an attacker would have to do to get past the 2186 replay cache would be to tweak a single bit in the inbound segment 2187 each time, which is certainly cheaper than the hash+lookup+decode 2188 combination, though also certainly more expensive than simply sending 2189 the same octets many times. 2191 The benefit of doing this is that implementers no longer need to 2192 analyze many bugs/attacks based on replaying packets, which in 2193 combination with the use of LTP authentication should defeat many 2194 attempted DoS attacks. 2196 9.3 Implementation Considerations 2198 SDNV 2200 Implementations SHOULD make sanity checks on SDNV length fields 2201 and SHOULD check that no SDNV field is too long when compared with 2202 the overall segment length. 2204 Implementations SHOULD check that SDNV values are within suitable 2205 ranges where possible. 2207 Byte ranges 2208 Various report and other segments contain offset and length 2209 fields. Implementations MUST ensure that these are consistent and 2210 sane. 2212 Randomness 2214 Various fields in LTP (e.g. serial numbers) MUST be initialized 2215 using random values. Good sources of randomness which are not 2216 easily guessable SHOULD be used [ESC05]. The collision of random 2217 values is subject to the birthday paradox, which means that a 2218 collision is likely after roughly the square-root of the space has 2219 been seen (e.g. 2^16 in the case of a 32-bit random value). 2220 Implementers MUST ensure that they use sufficiently long random 2221 values so that the birthday paradox doesn't cause a problem in 2222 their environment. 2224 10. IANA Considerations 2226 The UDP port number 1113 with the name "ltp-deepspace" has been 2227 reserved for LTP deployments. An LTP implementation may be 2228 implemented to operate over UDP datagrams using this port number for 2229 study and testing over the Internet. 2231 11. Acknowledgments 2233 Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian 2234 Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss for 2235 their thoughts on this protocol and its role in Delay-Tolerant 2236 Networking architecture. 2238 Part of the research described in this document was carried out at 2239 the Jet Propulsion laboratory, California Institute of Technology, 2240 under a contract with the National Aeronautics and Space 2241 Administration. This work was performed under DOD Contract DAA-B07- 2242 00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; 2243 and NASA Contract NAS7-1407. 2245 Thanks are also due to Shawn Ostermann, Hans Kruse, Dovel Myers, and 2246 Jayram Deshpande at Ohio University for their suggestions and advice 2247 in making various design decisions. 2249 Part of this work was carried out at Trinity College Dublin as part 2250 of the SeNDT contract funded by Enterprise Ireland's research 2251 innovation fund. 2253 12. References 2255 12.1 Normative References 2257 [B97] S. Bradner, "Key words for use in RFCs to Indicate Requirement 2258 Levels", BCP 14, RFC 2119, March 1997. 2260 [LTPMTV] Burleigh, S., Ramadas, M., and Farrell, S., "Licklider 2261 Transmission Protocol - Motivation", draft-irtf-dtnrg-ltp- 2262 motivation-04.txt (Work in Progress), March 2007. 2264 [LTPEXT] Farrell, S., Ramadas, M., and Burleigh, S., "Licklider 2265 Transmission Protocol - Extensions", draft-irtf-dtnrg-ltp- 2266 extensions-05.txt (Work in Progress), October 2007. 2268 12.2 Informative References 2270 [ASN1] Abstract Syntax Notation One (ASN.1). ASN.1 Encoding Rules: 2271 Specification of Basic Encoding Rules (BER), Canonical Encoding Rules 2272 (CER), and Distinguished Encoding Rules (DER). ITU-T Rec. X.690 2273 (2002) | ISO/IEC 8825-1:2002. 2275 [BP] K. Scott and S. Burleigh, "Bundle Protocol Specification", RFC 2276 5050, November 2007. 2278 [DTN] K. Fall, "A Delay-Tolerant Network Architecture for Challenged 2279 Internets", In Proceedings of ACM SIGCOMM 2003, Karlsruhe, Germany, 2280 Aug 2003. 2282 [ESC05] D. Eastlake, J. Schiller and S. Crockerr, "Randomness 2283 Recommendations for Security", RFC 4086, June 2005. 2285 [SACK] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, "TCP 2286 Selective Acknowledgement Options", RFC 2018, October 1996. 2288 13. Author's Addresses 2290 Manikantan Ramadas 2291 Internetworking Research Group 2292 301 Stocker Center 2293 Ohio University 2294 Athens, OH 45701 2295 Telephone +1 (740) 593-1562 2296 Email mramadas@irg.cs.ohiou.edu 2297 Scott C. Burleigh 2298 Jet Propulsion Laboratory 2299 4800 Oak Grove Drive 2300 M/S: 301-490 2301 Pasadena, CA 91109-8099 2302 Telephone +1 (818) 393-3353 2303 FAX +1 (818) 354-1075 2304 Email Scott.Burleigh@jpl.nasa.gov 2306 Stephen Farrell 2307 Computer Science Department 2308 Trinity College Dublin 2309 Ireland 2310 Telephone +353-1-896-1761 2311 Email stephen.farrell@cs.tcd.ie 2313 Intellectual Property Statement 2315 The IETF takes no position regarding the validity or scope of any 2316 Intellectual Property Rights or other rights that might be claimed to 2317 pertain to the implementation or use of the technology described in 2318 this document or the extent to which any license under such rights 2319 might or might not be available; nor does it represent that it has 2320 made any independent effort to identify any such rights. Information 2321 on the procedures with respect to rights in RFC documents can be 2322 found in BCP 78 and BCP 79. 2324 Copies of IPR disclosures made to the IETF Secretariat and any 2325 assurances of licenses to be made available, or the result of an 2326 attempt made to obtain a general license or permission for the use of 2327 such proprietary rights by implementers or users of this 2328 specification can be obtained from the IETF on-line IPR repository at 2329 http://www.ietf.org/ipr. 2331 The IETF invites any interested party to bring to its attention any 2332 copyrights, patents or patent applications, or other proprietary 2333 rights that may cover technology that may be required to implement 2334 this standard. Please address the information to the IETF 2335 at ietf-ipr@ietf.org. 2337 Disclaimer of Validity 2339 This document and the information contained herein are provided on an 2340 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2341 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2342 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2343 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2344 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2345 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2347 Copyright Statement 2349 Copyright (C) The IETF Trust (2008). This document is subject to the 2350 rights, licenses and restrictions contained in BCP 78, and except as 2351 set forth therein, the authors retain all their rights. 2353 Acknowledgment 2355 Funding for the RFC Editor function is currently provided by the 2356 Internet Society.