idnits 2.17.1 draft-irtf-dtnrg-ltp-10.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 2383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2373. 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 ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (ref. 'GUIDE') (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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 June 24 2008 S. Farrell 7 Expires December 24 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 December 24, 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 Automatic Repeat reQuest (ARQ) of data transmissions by 52 soliciting selective-acknowledgment reception reports. It is 53 stateful, and has no 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 This document serves as the main protocol specification of LTP and is 152 part of a series of documents describing LTP. Other documents in 153 this series include the motivation document [LTPMTV] and the protocol 154 extensions document [LTPEXT]. We strongly recommend reading the 155 protocol motivation document before reading this document, to 156 establish sufficient background and motivation for the specification. 158 2. Terminology 160 (1) Engine ID 162 A number that uniquely identifies a given LTP engine, within some 163 closed set of communicating LTP engines. Note that when LTP is 164 operating underneath the DTN Bundle protocol [BP][DTN], the 165 convergence layer adapter mediating the two will be responsible for 166 translating between DTN endpoint IDs and LTP engine IDs in an 167 implementation-specific manner. 169 (2) Block 171 An array of contiguous octets of application data handed down by the 172 upper layer protocol (typically Bundle protocol) to be transmitted 173 from one LTP client service instance to another. 175 Any subset of a block comprising contiguous octets beginning at the 176 start of the block is termed a "block prefix" and any such subset of 177 the block ending with the end of the block is termed a "block 178 suffix". 180 (3) Red-Part 182 The block prefix that is to be transmitted reliably, i.e., subject to 183 acknowledgment and retransmission. 185 (4) Green-Part 187 The block suffix that is to be transmitted unreliably, i.e., not 188 subject to acknowledgments or retransmissions. If present, the 189 green-part of a block begins at the octet following the end of the 190 red-part. 192 (5) Session 194 A thread of LTP protocol activity conducted between two peer engines 195 for the purpose of transmitting a block. Data flow in a Session is 196 uni-directional: data traffic flows from the sending peer to the 197 receiving peer, while data-acknowledgment traffic flows from the 198 receiving peer to the sending peer. 200 (6) Sender 202 The data sending peer of a Session. 204 (7) Receiver 206 The data receiving peer of a Session. 208 (8) Client Service Instance 210 A software entity, such as an application or a higher-layer protocol 211 implementation, that is using LTP to transfer data. 213 (9) Segment 215 The unit of LTP data transmission activity. It is the data structure 216 transmitted from one LTP engine to another in the course of a 217 session. Each LTP segment is of one of the following types: data 218 segment, report segment, report-acknowledgment segment, cancel 219 segment, cancel-acknowledgment segment. 221 (10) Reception Claim 223 An assertion of reception of some number of contiguous octets of 224 application data (a subset of a block) characterized by: the offset 225 of the first received octet, and the number of contiguous octets 226 received (beginning at the offset). 228 (11) Scope 229 Scope identifies a subset of a block and comprises two numbers - 230 upper bound and lower bound. 232 For a data segment, lower bound is the offset of the segment's 233 application data from the start of the block (in octets), while upper 234 bound is the sum of the offset and length of the segment's 235 application data (in octets). For example, a segment with block 236 offset 1000 and length 500 would have a lower bound 1000 and upper 237 bound 1500. 239 For a report segment, upper bound is the end of the block prefix to 240 which the reception claims in the report apply, while lower bound is 241 the end of the (smaller) interior block prefix to which the reception 242 claims in the report do *not* apply. That is, data at any offset 243 equal to or greater than the report's lower bound but less than its 244 upper bound and not designated as "received" by any of the report's 245 reception claims must be assumed not received and therefore eligible 246 for retransmission. For example, if a report segment carried a lower 247 bound of 1000 and an upper bound of 5000, and the reception claims 248 indicated reception of data within offsets 1000-1999 and 3000-4999, 249 data within the block offsets 2000-2999 can be considered missing and 250 eligible for retransmission. 252 Reception reports (which may comprise multiple report segments) also 253 have scope, as defined in Section 6.11. 255 (12) End of Block (EOB) 257 The last data segment transmitted as part of the original 258 transmission of a block. This data segment also indicates that the 259 segment's upper bound is the total length of the block (in octets). 261 (13) End of Red-Part (EORP) 263 The segment transmitted as part of the original transmission of a 264 block containing the last octet of the block's red-part. This data 265 segment also indicates that the segment's upper bound is the length 266 of the block's red-part (in octets). 268 (14) Checkpoint 270 A data segment soliciting a reception report from the receiving LTP 271 engine. The EORP segment must be flagged as a checkpoint, as must 272 the last segment of any retransmission; these are "mandatory 273 checkpoints". All other checkpoints are "discretionary checkpoints". 275 (15) Reception Report 277 A sequence of one or more report segments reporting on all block data 278 reception within some scope. 280 (16) Synchronous Reception Report 282 A reception report that is issued in response to a checkpoint. 284 (17) Asynchronous Reception Report 286 A reception report that is issued in response to some implementation- 287 defined event other than the arrival of a checkpoint. 289 (18) Primary Reception Report 291 A reception report that is issued in response to some event other 292 than the arrival of a checkpoint segment that was itself issued in 293 response to a reception report. Primary reception reports include 294 all asynchronous reception reports and all synchronous reception 295 reports that are sent in response to discretionary checkpoints or to 296 the EORP segment for a session. 298 (19) Secondary Reception Report 300 A reception report that is issued in response to the arrival of a 301 checkpoint segment that was itself issued in response to a reception 302 report. 304 (20) Self-Delimiting Numeric Value (SDNV) 306 The design of LTP attempts to reconcile minimal consumption of 307 transmission bandwidth with 309 (a) extensibility to satisfy requirements not yet identified, and 310 (b) scalability across a very wide range of network sizes and 311 transmission payload sizes. 313 The SDNV encoding scheme is modeled after the Abstract Syntax 314 Notation One [ASN1] scheme for encoding Object Identifier Values. In 315 a data field encoded as an SDNV, the most significant bit (MSB) of 316 each octet of the SDNV serves to indicate whether the octet is the 317 last octet of the SDNV or not. An octet with an MSB of 1 indicates 318 that it is either the first or a middle octet of a multi-octet SDNV; 319 the octet with an MSB of 0 is the last octet of the SDNV. The value 320 encoded in an SDNV is found by concatenating the 7 least significant 321 bits of each octet of the SDNV, beginning at the first octet and 322 ending at the last octet. 324 The following examples illustrate the encoding scheme for various 325 hexadecimal values. 327 0xABC : 1010 1011 1100 328 is encoded as 330 {100 1010 1} {0 011 1100} 331 - - 333 = 10010101 00111100 335 0x1234 : 0001 0010 0011 0100 336 = 1 0010 0011 0100 337 is encoded as 339 {10 1 0010 0} {0 011 0100} 340 - - 342 = 10100100 00110100 344 0x4234 : 0100 0010 0011 0100 345 =100 0010 0011 0100 346 is encoded as 348 {1000000 1} {1 00 0010 0} {0 011 0100} 349 - - - 351 = 10000001 10000100 00110100 353 0x7F : 0111 1111 354 =111 1111 355 is encoded as 357 {0 111 1111} 358 - 360 = 01111111 362 Note : 364 Care must be taken to make sure that the value to be encoded is 365 padded with zeroes at the most significant bit end (NOT at the 366 least significant bit end) to make its bitwise length a multiple 367 of 7 before encoding. 369 While there is no theoretical limit on the size of an SDNV field, 370 we note that the overhead of the SDNV scheme is 1:7, i.e., one bit 371 of overhead for every 7 bits of actual data to be encoded. Thus a 372 7-octet value (a 56-bit quantity with no leading zeroes) would be 373 encoded in an 8-octet SDNV; an 8-octet value (a 64-bit quantity 374 with no leading zeroes) would be encoded in a 10-octet SDNV. In 375 general, an N-bit quantity with no leading zeroes would be encoded 376 in a ceil(N/7) octet SDNV, where ceil is the integer ceiling 377 function. Clearly, for fields that typically carry larger values 378 such as RSA public keys, the SDNV overhead could become 379 unacceptable. Hence when adopting the SDNV scheme for other 380 purposes related to this document, such as any protocol 381 extensions, we RECOMMEND that if the typical data field value is 382 expected to be larger than 8 octets then the data field should be 383 specified as a {LENGTH, VALUE} tuple, with the LENGTH parameter 384 encoded as an SDNV followed by LENGTH octets housing the VALUE of 385 the data field. 387 We also note that SDNV is clearly not the best way to represent 388 every numeric value. When the maximum possible value of a number 389 is known without question, the cost of additional bits may not be 390 justified. For example, an SDNV is a poor way to represent an 391 integer whose value typically falls in the range 128 to 255. In 392 general, though, we believe that the SDNV representation of 393 various protocol data fields in LTP segments yields the smallest 394 segment sizes without sacrificing scalability. 396 3. Segment Structure 398 Each LTP segment comprises 400 (a) a "header" in the format defined below. 402 (b) zero or more octets of "content". 404 (c) zero or more octets of "trailer" as indicated by information in 405 the "extensions field" of the header. 407 LTP segments are of four general types depending on the nature of the 408 content carried: 410 Data segments flow from the Sender to the Receiver and carry 411 client service (application) data. 413 A report segment flows from the Receiver to the Sender and carries 414 data reception claims together with the upper and lower bounds of 415 the block scope to which the claims pertain. 417 A report-acknowledgment segment flows from the Sender to the 418 Receiver and acknowledges reception of a report segment. It 419 carries the serial number of the report being acknowledged. 421 Session management segments may be generated by both the Sender 422 and the Receiver and are of two general sub-types: Cancellation 423 and Cancellation-acknowledgment. A Cancellation segment initiates 424 session cancellation procedures at the peer and carries a single 425 byte reason-code to indicate the reason for session cancellation. 426 Cancellation-acknowledgment segments merely acknowledge reception 427 of a Cancellation segment and have no content. 429 The overall segment structure is illustrated below: 431 Bit 0 1 2 3 4 5 6 7 432 ^ +-----+-----+-----+-----+-----+-----+-----+-----+ 433 | | Version number | Segment Type Flags | Control 434 | +-----------------------+-----------------------+ -byte 435 | | | 436 | / Session ID \ 437 | \ / 438 Header +-----------------------+-----------------------+ 439 | | Header Extension Cnt. | Trailer Extension Cnt.| Extensions 440 | +-----------------------+-----------------------+ 441 | | | 442 | / Header Extensions \ 443 | \ / 444 V +-----------------------------------------------+ 445 | | 446 | | 447 | | 448 | Segment Content | 449 / \ 450 \ / 451 | | 452 | | 453 | | 454 ^ +-----------------------------------------------+ 455 | | | 456 Trailer / Trailer Extensions \ 457 | \ / 458 V +-----------------------------------------------+ 459 3.1 Segment Header 461 An LTP segment header comprises three data items: a single-octet 462 Control-byte, the Session ID, and the Extensions field. 464 Control-byte comprises the following: 466 Version number (4 bits): MUST be set to the binary value 0000 for 467 this version of the protocol. 469 Segment type flags (4 bits): described in Section 3.1.1. 471 Session ID uniquely identifies, among all transmissions between the 472 Sender and Receiver, the session of which the segment is one token. 473 It comprises the following: 475 Session originator (SDNV): the engine ID of the Sender. 477 Session number (SDNV) : Typically a random number (for anti-DoS 478 reasons), generated by the Sender. 480 The format and resolution of session number are matters that are 481 private to the Sender LTP node; the only requirement imposed by 482 LTP is that every session initiated by an LTP engine MUST be 483 uniquely identified by the session ID. 485 The Extensions field is described in Section 3.1.4. 487 3.1.1 Segment Type Flags 489 The last four bits of the control byte in the segment header are 490 flags that indicate the nature of the segment. In order (most 491 significant bit first), these flags are CTRL, EXC, Flag 1 and Flag 0. 493 A value of 0 in the CTRL (Control) flag identifies the segment as a 494 data segment while a value of 1 identifies it as a control segment. 495 A data segment with the EXC (Exception) flag set to 0 is a red-part 496 segment; a data segment with EXC set to 1 is a green-part segment. 497 For a control segment, having the EXC flag set to 1 indicates that 498 the segment pertains to session cancellation activity. Any data 499 segment (whether red-part or green-part) with both Flag 1 and Flag 0 500 set to 1 indicates EOB. Any data segment (whether red-part or 501 green-part) with both Flag 1 and Flag 0 set to 0 indicates data 502 without any additional protocol significance. Any red-part data 503 segment with either Flag bit non-zero is a checkpoint. Any red-part 504 data segment with Flag 1 set to 1 indicates the end of red-part. 506 Put another way: 508 if (CTRL flag = 0) 509 segment is a Data segment if (EXC flag = 0) 510 segment contains only red-part data if (Flag 1 = 1) 511 segment is a checkpoint segment is the last segment in the 512 red part of the block if (Flag 0 = 1) 513 segment is the last segment in the block 514 else // segment is not end of red part 515 if (Flag 0 = 1) 516 segment is a checkpoint 517 else 518 segment contains only green-part data if (Flag 1 = 1) 519 if (Flag 0 = 1) 520 segment is the last segment in the block 521 else 522 segment is a Control segment if (EXC flag = 0) 523 segment pertains to report activity if (flag 0 = 0) 524 segment is a report segment 525 else 526 segment is an acknowledgment of a report segment 527 else 528 segment pertains to session cancellation activity if (Flag 1 = 529 0) 530 segment pertains to cancellation by block sender if (Flag 0 531 = 1) 532 segment is a cancellation by sender 533 else 534 segment is an acknowledgment of a cancellation by sender 535 else 536 segment pertains to cancellation by block receiver if (Flag 537 0 = 1) 538 segment is a cancellation by receiver 539 else 540 segment is an acknowledgment of a cancellation by 541 receiver 543 3.1.2 Segment Type Codes 545 Combinations of the settings of the segment type flags CTRL, EXC, 546 Flag 1 and Flag 0 constitute segment type codes which serve as 547 concise representations of detailed segment nature. 549 CTRL EXC Flag 1 Flag 0 Code Nature of segment 550 ---- --- ------ ------ ---- --------------------------------------- 551 0 0 0 0 0 Red data, NOT {Checkpoint, EORP or EOB} 552 0 0 0 1 1 Red data, Checkpoint, NOT {EORP or EOB} 553 0 0 1 0 2 Red data, Checkpoint, EORP, NOT EOB 554 0 0 1 1 3 Red data, Checkpoint, EORP, EOB 556 0 1 0 0 4 Green data, NOT EOB 557 0 1 0 1 5 Green data, undefined 558 0 1 1 0 6 Green data, undefined 559 0 1 1 1 7 Green data, EOB 561 1 0 0 0 8 Report segment 562 1 0 0 1 9 Report-acknowledgment segment 563 1 0 1 0 10 Control segment, undefined 564 1 0 1 1 11 Control segment, undefined 566 1 1 0 0 12 Cancel segment from block sender 567 1 1 0 1 13 Cancel-acknowledgment segment 568 to block sender 570 1 1 1 0 14 Cancel segment from block receiver 571 1 1 1 1 15 Cancel-acknowledgment segment 572 to block receiver 574 3.1.3 Segment Class Masks 576 For the purposes of this specification, some bit patterns in the 577 segment type flags field correspond to "segment classes" that are 578 designated by mnemonics. The mnemonics are intended to evoke the 579 characteristics shared by all types of segments characterized by 580 these flag bit patterns. 582 CTRL EXC Flag 1 Flag 0 Mnemonic Description 583 ---- --- ------ ------ -------- --------------------------- 584 0 0 - 1 585 -- or -- 586 0 0 1 - CP Checkpoint 588 0 0 1 - EORP End of red-part; 589 red-part size = offset + length 591 0 - 1 1 EOB End of block; 592 block size = offset + length 594 1 0 0 0 RS Report segment; 595 carries reception claims 597 1 0 0 1 RA Report-acknowledgment segment 598 1 1 0 0 CS Cancel segment from block sender 600 1 1 0 1 CAS Cancel-acknowledgment segment 601 to block sender 603 1 1 1 0 CR Cancel segment from block receiver 605 1 1 1 1 CAR Cancel-acknowledgment segment 606 to block receiver 608 1 1 - 0 Cx Cancel segment (generic) 610 1 1 - 1 CAx Cancel-acknowledgment segment 611 (generic) 613 3.1.4 Extensions field 615 The extensions field enables the inclusion of zero or more functional 616 extensions to the basic LTP segment, each in type-length-value (TLV) 617 representation as explained below. 619 The first octet of the extensions field indicates the number of 620 extensions present in the segment: the high-order 4 bits indicate the 621 number of extension TLVs in the header (immediately following the 622 extensions count octet and preceding the segment's content) while the 623 low-order 4 bits indicate the number of extension TLVs in the trailer 624 (immediately following the segment's content). That is, each segment 625 may have from 0 to 15 extension TLVs in its header and from 0 to 15 626 extension TLVs in its trailer. In the absence of any extension TLVs, 627 all bits of this extensions count octet MUST be set to zero. 629 Note that it is valid for header extensions to be immediately 630 followed by trailer extensions; for example, since a CAx segment has 631 no contents, it may have header extensions immediately followed by 632 trailer extensions. 634 Each extension consists of a one-octet tag identifying the type of 635 the extension, followed by a length parameter in SDNV form, followed 636 by a value of the specified length. 638 The diagram below illustrates the extension TLVs as they may occur in 639 the header or trailer. 641 +--------+----///-----///--+ 642 |ext-tag | length | value | 643 +--------+-------///-------+----------///-------+ 644 |ext-tag | length | value | 645 +--------+-----///-----///-+---------////-------+ 646 |ext-tag | length | value | 647 +--------+----------+----------+ 649 The IANA will maintain an LTP Extension Tag registry as shown below. 650 See the IANA considerations section below for details of code point 651 assignment in the Unassigned range. 653 Extension tag Meaning 654 ------------- ------- 655 0x00 LTP authentication extension [LTPEXT] 656 0x01 LTP cookie extension [LTPEXT] 657 0x02-0xAF Unassigned 658 0xB0-0xBF Reserved 659 0xC0-0xFF Private / Experimental Use 661 Note that since the last quarter of the extension-tag space is for 662 experimental use, implementations should be aware that collisions for 663 these tags are possible. 665 3.2 Segment Content 667 3.2.1 Data Segment (DS) 669 The content of a data segment includes client service data and the 670 metadata enabling the receiving client service instance to receive 671 and make use of that data. 673 Client service ID (SDNV) 675 The client service ID number identifies the upper-level service to 676 which the segment is to be delivered by the Receiver. It is 677 functionally analogous to a TCP port number. If multiple 678 instances of the client service are present at the destination, 679 multiplexing must be done by the client service itself on the 680 basis of information encoded within the transmitted block. 682 Offset (SDNV) 684 Offset indicates the location of the segment's client service data 685 within the session's transmitted block. It is the number of bytes 686 in the block prior to the byte from which the first octet of the 687 segment's client service data was copied. 689 Length (SDNV) 691 The length of the ensuing client service data, in octets. 693 If the data segment is a checkpoint, the segment MUST additionally 694 include the following two serial numbers (Checkpoint serial number 695 and Report serial number) to support efficient retransmission. Data 696 segments that are not checkpoints MUST NOT have these two fields in 697 the header and MUST continue on directly with the client service 698 data. 700 Checkpoint serial number (SDNV) 702 The checkpoint serial number uniquely identifies the checkpoint 703 among all checkpoints issued by the block sender in a session. 704 The first checkpoint issued by the sender MUST have this serial 705 number chosen randomly for security reasons, and it is RECOMMENDED 706 that the sender use the guidelines in [ESC05] for this. Any 707 subsequent checkpoints issued by the sender MUST have the serial 708 number value found by incrementing the prior checkpoint serial 709 number by 1. When a checkpoint segment is retransmitted, however, 710 its serial number MUST be the same as when it was originally 711 transmitted. The checkpoint serial number MUST NOT be zero. 713 Report serial number (SDNV) 715 If the checkpoint was queued for transmission in response to the 716 reception of an RS [Sec 6.13], then its value MUST be the report 717 serial number value of the RS that caused the data segment to be 718 queued for transmission. 720 Otherwise, the value of report serial number MUST be zero. 722 Client service data (array of octets) 724 The client service data carried in the segment is a copy of a 725 subset of the bytes in the original client service data block, 726 starting at the indicated offset. 728 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) 777 The offset indicates the successful reception of data beginning 778 at the indicated offset from the lower bound of the RS. The 779 offset within the entire block can be calculated by summing 780 this offset with the lower bound of the RS. 782 Length (SDNV) 784 The length of a reception claim indicates the number of 785 contiguous octets of block data starting at the indicated 786 offset that have been successfully received. 788 Reception claims MUST conform to the following rules: 790 A reception claim's length shall never be less than 1 and shall 791 never exceed the difference between the upper and lower bounds 792 of the report segment. 794 The offset of a reception claim shall always be greater than 795 the sum of the offset and length of the prior claim, if any. 797 The sum of a reception claim's offset and length and the lower 798 bound of the report segment shall never exceed the upper bound 799 of the report segment. 801 Implied requests for retransmission of client service data can be 802 inferred from an RS's data reception claims. However, *nothing* can 803 be inferred regarding reception of block data at any offset equal to 804 or greater than the segment's upper bound or at any offset less than 805 the segment's lower bound. 807 For example, if the scope of a report segment has lower bound 0 and 808 upper bound 6000, and the report contains a single data reception 809 claim with offset 0 and length 6000, then the report signifies 810 successful reception of the first 6000 bytes of the block. If the 811 total length of the block is 6000, then the report additionally 812 signifies successful reception of the entire block. 814 If on the other hand, the scope of a report segment has lower bound 815 1000 and upper bound 6000, and the report contains two data reception 816 claims, one with offset 0 and length 2000 and the other with offset 817 3000 and length 500, then the report signifies successful reception 818 only of bytes 1000-2999 and 4000-4499 of the block. From this we can 819 infer that bytes 3000-3999 and 4500-5999 of the block need to be 820 retransmitted, but we cannot infer anything about reception of the 821 first 1000 bytes or of any subsequent data beginning at block offset 822 6000. 824 3.2.3 Report Acknowledgment Segment 826 The content of an RA is simply the report serial number of the RS in 827 response to which the segment was generated. 829 Report serial number (SDNV) 831 This field returns the report serial number of the RS being 832 acknowledged. 834 3.2.4 Session Management Segments 836 Cancel segments (Cx) carry a single byte reason-code with the 837 following semantics : 839 Reason-Code Mnemonic Semantics 840 ----------- -------- --------------------------------------- 841 00 USR_CNCLD Client Service canceled session. 843 01 UNREACH Unreachable Client Service. 845 02 RLEXC Retransmission limit exceeded. 847 03 MISCOLORED Received either a red-part data segment 848 at block offset above any green-part 849 data segment offset or a green-part 850 data segment at block offset below any 851 red-part data segment offset. 853 04 SYS_CNCLD A system error condition caused 854 unexpected session termination. 856 05 RXMTCYCEXC Exceeded the Retransmission-Cycles limit 858 06-FF Reserved 860 The Cancel-acknowledgments (CAx) have no content. 862 Note: the reason we use different cancel segment types for the 863 originator and recipient is to allow a loopback mode to work without 864 disturbing any replay protection mechanism in use. 866 3.3 Segment Trailer 868 The segment trailer consists of a sequence of from zero to 15 869 extension TLVs as described in Section 3.1.4 above. 871 4. Requests from Client Service 873 In all cases the representation of request parameters is a local 874 implementation matter, as are validation of parameter values and 875 notification of the client service in the event that a request is 876 found to be invalid. 878 4.1 Transmission Request 880 In order to request transmission of a block of client service data, 881 the client service MUST provide the following parameters to LTP: 883 Destination client service ID 885 Destination LTP engine ID 887 Client service data to send, as an array of bytes. 889 Length of the data to be sent. 891 Length of the red-part of the data. This value MUST be in the 892 range from zero to the total length of data to be sent. 894 On reception of a valid transmission request from a client service, 895 LTP proceeds as follows. 897 First the array of data to be sent is subdivided as necessary, with 898 each subdivision serving as the client service data of a single new 899 LTP data segment. The algorithm used for subdividing the data is a 900 local implementation matter; it is expected that data size 901 constraints imposed by the underlying communication service, if any, 902 will be accommodated in this algorithm. 904 The last (and only the last) of the resulting data segments must be 905 marked as the EOB (End of block). 907 Note that segment type indicates that the client service data in a 908 given LTP segment either is or is not in the red-part of the block. 909 To prevent segment type ambiguity, each data segment MUST contain 910 either only red-part data or only green-part data. Therefore, when 911 the length of the block's red-part is N, the total length of the 912 block is M, and N is not equal to M, the (N+1)th byte of the block 913 SHOULD be the first byte of client service data in a green-part data 914 segment. Note that this means that at the red-part boundary, LTP may 915 send a segment of size lesser than the link MTU size. For bandwidth 916 efficiency reasons, implementations MAY choose to instead mark the 917 entire segment (within which the red-part boundary falls) as red- 918 part, causing green-part data falling within the segment also be 919 treated as red-part. 921 If the length of the block's red-part is greater than zero, then the 922 last data segment containing red-part data must be marked as the EORP 923 (End of red-part) segment by setting the appropriate segment type 924 flag bits [Sec 3.1.2]. Zero or more preceding data segments 925 containing red-part data (selected according to an algorithm that is 926 a local implementation matter) MAY additionally be marked as a CP 927 (Checkpoint), and serve as additional discretionary checkpoints [Sec 928 3.1.2]. 930 All data segments are appended to the (conceptual) application data 931 queue bound for the destination engine, for subsequent transmission. 933 Finally, a session start notice [Sec 7.1] is sent back to the client 934 service that requested the transmission. 936 4.2 Cancellation Request 938 In order to request cancellation of a session, either as the sender 939 or as the receiver of the associated data block, the client service 940 must provide the session ID identifying the session to be canceled. 942 On reception of a valid cancellation request from a client service, 943 LTP proceeds as follows. 945 First the internal "Cancel session" procedure [Sec 6.19] is invoked. 947 Next, if the session is being canceled by the Sender (i.e., the 948 session originator part of the session ID supplied in the 949 cancellation request is the local LTP engine ID): 951 If none of the data segments previously queued for transmission as 952 part of this session have yet been de-queued and transmitted - 953 i.e., if the destination engine cannot possibly be aware of this 954 session - then the session is simply closed; the "Close session" 955 procedure [Sec 6.20] is invoked. 957 Otherwise, a CS (Cancel by block sender) segment with reason-code 958 USR_CNCLD MUST be queued for transmission to the destination LTP 959 engine specified in the transmission request that started this 960 session. 962 Otherwise (i.e., the session is being canceled by the Receiver): 964 If there is no transmission queue-set bound for the Sender 965 (possibly because the local LTP engine is running on a receive- 966 only device), then the session is simply closed; the "Close 967 session" procedure [Sec 6.20] is invoked. 969 Otherwise, a CR (Cancel by block receiver) segment with reason- 970 code USR_CNCLD MUST be queued for transmission to the block 971 sender. 973 5. Requirements from the Operating Environment 975 LTP is designed to run directly over a data-link layer protocol. 977 LTP MUST only be deployed directly over UDP, for software development 978 purposes or for use in private local area networks. For example, in a 979 sparse sensor network where the link, when available, is only used 980 for LTP traffic. 982 In either case, the protocol layer immediately underlying LTP is 983 referred to as the "local data-link layer" for the purposes of this 984 specification. 986 When the local data-link layer protocol is UDP, (a) the content of 987 each UDP datagram MUST be an integral number of LTP segments and (b) 988 the LTP authentication [LTPEXT] extension SHOULD be used unless the 989 end-to-end path is one in which either the likelihood of datagram 990 content corruption is negligible or the consequences of receiving and 991 processing corrupt LTP segments are insignificant (as during software 992 development). In addition, the LTP authentication [LTPEXT] extension 993 SHOULD be used to assure data integrity unless the end-to-end path is 994 one in which either the likelihood of datagram content corruption is 995 negligible (as in some private local area networks) or the 996 consequences of receiving and processing corrupt LTP segments are 997 insignificant (as perhaps during software development). 999 When the local data-link layer protocol is not UDP, the content of 1000 each local data-link layer protocol frame MUST be be an integral 1001 number of LTP segments. 1003 The local data-link layer protocol MUST be a protocol which, together 1004 with the operating environment in which that protocol is implemented, 1005 satisfies the following requirements: 1007 It is required to inform LTP whenever the link to a specific LTP 1008 destination is brought up or torn down. Similarly, it is required 1009 to inform the local LTP engine whenever it is known that a remote 1010 LTP engine is set to begin or stop communication with the local 1011 engine based on the engines' operating schedules. 1013 It is required to provide link state cues to LTP upon transmission 1014 of the CP, RS (Report), EORP, EOB, and Cx (Cancel) segments so 1015 that timers can be started. 1017 It is required to provide, upon request, the current distance (in 1018 light seconds) to any peer engine in order to calculate timeout 1019 intervals. 1021 A MIB (Management Information Base) with the above parameters, 1022 updated periodically by the local data-link layer and the operating 1023 environment, should be made available to the LTP engine for its 1024 operations. The details of the MIB are, however, beyond the scope of 1025 this document. 1027 The underlying data-link layer is required to never deliver 1028 incompletely received LTP segments to LTP. In the absence of the use 1029 of LTP authentication [LTPEXT], LTP also requires the underlying 1030 local data-link layer protocol to perform data integrity checking of 1031 the segments received. Specifically, the local data-link layer 1032 protocol is required to detect any corrupted segments received and to 1033 silently discard them. 1035 6. Internal Procedures 1037 This section describes the internal procedures that are triggered by 1038 the occurrence of various events during the life-time of an LTP 1039 session. 1041 Whenever the content of any of the fields of the header of any 1042 received LTP segment does not conform to this specification document, 1043 the segment is assumed to be corrupt and MUST be discarded 1044 immediately and processed no further. This procedure supersedes all 1045 other procedures described below. 1047 All internal procedures described below that are triggered by the 1048 arrival of a data segment are superseded by the following procedure 1049 in the event that the client service identified by the data segment 1050 does not exist at the local LTP engine: 1052 If there is no transmission queue-set bound for the block sender 1053 (possibly because the local LTP engine is running on a receive- 1054 only device), then the received data segment is simply discarded. 1056 Otherwise, if the data segment contains data from the red-part of 1057 the block, a CR with reason-code UNREACH MUST be enqueued for 1058 transmission to the block sender. A CR with reason-code UNREACH 1059 SHOULD be similarly enqueued for transmission to the data sender 1060 even if the data segment contained data from the green-part of the 1061 block; note however that (for example) in the case where the block 1062 receiver knows that the sender of this green-part data is 1063 functioning in a "beacon" (transmit-only) fashion, a CR need not 1064 be sent. In either case the received data segment is discarded. 1066 6.1 Start Transmission 1068 This procedure is triggered by the arrival of a link state cue 1069 indicating the start of transmission to a specified remote LTP 1070 engine. 1072 Response: the de-queuing and delivery of segments to the LTP engine 1073 specified in the link state cue begins. 1075 6.2 Start Checkpoint Timer 1077 This procedure is triggered by the arrival of a link state cue 1078 indicating the de-queuing (for transmission) of a CP segment. 1080 Response: the expected arrival time of the RS segment that will be 1081 produced on reception of this CP segment is computed, and a countdown 1082 timer is started for this arrival time. However, if it is known that 1083 the remote LTP engine has ceased transmission [Sec 6.5] then this 1084 timer is immediately suspended, because the computed expected arrival 1085 time may require an adjustment that cannot yet be computed. 1087 6.3 Start RS Timer 1089 This procedure is triggered by the arrival of a link state cue 1090 indicating the de-queuing (for transmission) of an RS segment. 1092 Response: the expected arrival time of the RA (Report acknowledgment) 1093 segment in response to the reception of this RS segment is computed, 1094 and a countdown timer is started for this arrival time. However, as 1095 in Sec 6.2, if it is known that the remote LTP engine has ceased 1096 transmission [Sec 6.5] then this timer is immediately suspended, 1097 because the computed expected arrival time may require an adjustment 1098 that cannot yet be computed. 1100 6.4 Stop Transmission 1102 This procedure is triggered by the arrival of a link state cue 1103 indicating the cessation of transmission to a specified remote LTP 1104 engine. 1106 Response: the de-queuing and delivery to the underlying communication 1107 system of segments from traffic queues bound for the LTP engine 1108 specified in the link state cue ceases. 1110 6.5 Suspend Timers 1112 This procedure is triggered by the arrival of a link state cue 1113 indicating the cessation of transmission from a specified remote LTP 1114 engine to the local LTP engine. Normally, this event is inferred 1115 from advance knowledge of the remote engine's planned transmission 1116 schedule. 1118 Response: countdown timers for the acknowledging segments that the 1119 remote engine is expected to return are suspended as necessary based 1120 on the following procedure. 1122 The nominal remote engine acknowledge transmission time is computed 1123 as the sum of the transmission time of the original segment (to which 1124 the acknowledging segment will respond) and the one-way light time to 1125 the remote engine, plus N seconds of "additional anticipated latency" 1126 (AAL) encompassing anticipated transmission delays other than signal 1127 propagation time. N is determined in an implementation-specific 1128 manner. For example, when LTP is deployed in deep space vehicles, 1129 the one-way light time to the remote engine may be very large while N 1130 may be relatively small, covering processing and queuing delays. N 1131 may be a network management parameter, for which 2 seconds seems like 1132 a reasonable default value. As another example, when LTP is deployed 1133 in a terrestrial "data mule" environment, one-way light time latency 1134 is effectively zero while N may need to be some dynamically computed 1135 function of the data mule circulation schedule. 1137 If the nominal remote engine acknowledge transmission time is greater 1138 than or equal to the current time (i.e., the acknowledging segment 1139 may be presented for transmission during the time that transmission 1140 at the remote engine is suspended), then the countdown timer for this 1141 acknowledging segment is suspended. 1143 6.6 Resume Timers 1145 This procedure is triggered by the arrival of a link state cue 1146 indicating the start of transmission from a specified remote LTP 1147 engine to the local LTP engine. Normally, this event is inferred 1148 from advance knowledge of the remote engine's planned transmission 1149 schedule. 1151 Response: expected arrival time is adjusted for every acknowledging 1152 segment that the remote engine is expected to return, for which the 1153 countdown timer has been suspended. First, the transmission delay 1154 interval is calculated as follows : 1156 The nominal remote engine acknowledge transmission time is 1157 computed as the sum of the transmission time of the original 1158 segment (to which the acknowledging segment will respond) and the 1159 one-way light time to the remote engine, plus N seconds of AAL 1160 [Sec 6.5]. 1162 If the nominal remote engine acknowledge transmission time is 1163 greater than the current time i.e., the remote engine resumed 1164 transmission prior to presentation of the acknowledging segment 1165 for transmission, then the transmission delay interval is zero. 1167 Otherwise, the transmission delay interval is computed as the 1168 current time less the nominal remote engine acknowledge 1169 transmission time. 1171 The expected arrival time is increased by the computed transmission 1172 delay interval for each of the suspended countdown timers, and the 1173 timers are resumed. 1175 6.7 Retransmit Checkpoint 1177 This procedure is triggered by the expiration of a countdown timer 1178 associated with a CP segment. 1180 Response: if the number of times this CP segment has been queued for 1181 transmission exceeds the checkpoint retransmission limit established 1182 for the local LTP engine by network management, then the session of 1183 which the segment is one token is canceled: the "Cancel session" 1184 procedure [Sec 6.19] is invoked, a CS with reason-code RLEXC is 1185 appended to the (conceptual) application data queue, and a 1186 transmission-session cancellation notice [Sec 7.5] is sent back to 1187 the client service that requested the transmission. 1189 Otherwise, a new copy of the CP segment is appended to the 1190 (conceptual) application data queue for the destination LTP engine. 1192 6.8 Retransmit RS 1194 This procedure is triggered by either (a) the expiration of a 1195 countdown timer associated with an RS segment or (b) the reception of 1196 a CP segment for which one or more RS segments were previously issued 1197 -- a redundantly retransmitted checkpoint. 1199 Response: if the number of times any affected RS segment has been 1200 queued for transmission exceeds the report retransmission limit 1201 established for the local LTP engine by network management, then the 1202 session of which the segment is one token is canceled: the "Cancel 1203 session" procedure [Sec 6.19] is invoked, a CR segment with reason- 1204 code RLEXC is queued for transmission to the LTP engine that 1205 originated the session, and a reception-session cancellation notice 1206 [Sec 7.6] is sent to the client service identified in each of the 1207 data segments received in this session. 1209 Otherwise, a new copy of each affected RS segment is queued for 1210 transmission to the LTP engine that originated the session. 1212 6.9 Signify Red-Part Reception 1214 This procedure is triggered by the arrival of a CP segment when the 1215 EORP for this session has been received (ensuring that the size of 1216 the data block's red-part is known; this includes the case where the 1217 CP segment itself is the EORP segment) and all data in the red-part 1218 of the block being transmitted in this session have been received. 1220 Response: a red-part reception notice [Sec 7.3] is sent to the 1221 specified client service. 1223 6.10 Signify Green-Part Segment Arrival 1225 This procedure is triggered by the arrival of a data segment whose 1226 content is a portion of the green-part of a block. 1228 Response: a green-part segment arrival notice [Sec 7.2] is sent to 1229 the specified client service. 1231 6.11 Send Reception Report 1233 This procedure is triggered by either (a) the original reception of a 1234 CP segment (the checkpoint serial number identifying this CP is new) 1235 (b) an implementation-specific circumstance pertaining to a 1236 particular block reception session for which no EORP has yet been 1237 received ("asynchronous" reception reporting). 1239 Response: if the number of reception problems detected for this 1240 session exceeds a limit established for the local LTP engine by 1241 network management, then the affected session is canceled: the 1242 "Cancel session" procedure [Sec 6.19] is invoked, a CR segment with 1243 reason-code RLEXC is issued and is, in concept, appended to the queue 1244 of internal operations traffic bound for the LTP engine that 1245 originated the session, and a reception-session cancellation notice 1246 [Sec 7.6] is sent to the client service identified in each of the 1247 data segments received in this session. One possible limit on 1248 reception problems would be the maximum number of reception reports 1249 which can be issued for any single session. 1251 If such a limit is not reached, a reception report is issued as 1252 follows. 1254 If production of the reception report was triggered by reception of a 1255 checkpoint: 1257 - The upper bound of the report SHOULD be the upper bound (the sum 1258 of the offset and length) of the checkpoint data segment, to 1259 minimize unnecessary retransmission. Note: If a discretionary 1260 checkpoint is lost but subsequent segments are received, then by 1261 the time the retransmission of the lost checkpoint is received the 1262 receiver would have segments at block offsets beyond the upper 1263 bound of the checkpoint. For deployments where bandwidth economy 1264 is not critical, the upper bound of a synchronous reception report 1265 MAY be the maximum upper bound value among all red-part data 1266 segments received so far in the affected session. 1268 - If the checkpoint was itself issued in response to a report 1269 segment, then this report is a "secondary" reception report. In 1270 that case the lower bound of the report SHOULD be the lower bound 1271 of the report segment to which the triggering checkpoint was 1272 itself a response, to minimize unnecessary retransmission. Note: 1273 For deployments where bandwidth economy is not critical, the lower 1274 bound of the report MAY instead be zero. 1276 - If the checkpoint was not issued in response to a report 1277 segment, this report is a "primary" reception report. The lower 1278 bound of the first primary reception report issued for any session 1279 MUST be zero. The lower bound of each subsequent primary 1280 reception report issued for the same session SHOULD be the upper 1281 bound of the prior primary reception report issued for the 1282 session, to minimize unnecessary retransmission. Note: For 1283 deployments where bandwidth economy is not critical, the lower 1284 bound of every primary reception report MAY be zero. 1286 If production of the reception report is "asynchronous" as noted 1287 above: 1289 - The upper bound of the report MUST be the maximum upper bound 1290 among all red-part data segments received so far for this session. 1292 - The lower bound of the first asynchronous reception report 1293 issued for any session for which no other primary reception 1294 reports have yet been issued MUST be zero. The lower bound of 1295 each subsequent asynchronous reception report SHOULD be the upper 1296 bound of the prior primary reception report issued for the 1297 session, to minimize unnecessary retransmission. Note: For 1298 deployments where bandwidth economy is not critical, the lower 1299 bound of every asynchronous reception report MAY be zero. 1301 In all cases, if the applicable lower bound of the scope of a report 1302 is determined to be greater than or equal to the applicable upper 1303 bound (for example, due to out-of-order arrival of discretionary 1304 checkpoints) then the reception report MUST NOT be issued. Otherwise: 1306 As many RS segments must be produced as are needed in order to report 1307 on all data reception within the scope of the report, given whatever 1308 data size constraints are imposed by the underlying communication 1309 service. The RS segments are, in concept, appended to the queue of 1310 internal operations traffic bound for the LTP engine that originated 1311 the indicated session. The lower bound of the first RS segment of 1312 the report MUST be the reception report's lower bound. The upper 1313 bound of the last RS segment of the report MUST be the reception 1314 report's upper bound. 1316 6.12 Signify Transmission Completion 1318 This procedure is triggered at the earliest time at which (a) all 1319 data in the block are known to have been transmitted *and* (b) the 1320 entire red-part of the block - if of non-zero length - is known to 1321 have been successfully received. Condition (a) is signaled by 1322 arrival of a link state cue indicating the de-queuing (for 1323 transmission) of the EOB segment for the block. Condition (b) is 1324 signaled by reception of an RS segment whose reception claims, taken 1325 together with the reception claims of all other RS segments 1326 previously received in the course of this session, indicate complete 1327 reception of the red-part of the block. 1329 Response: a transmission-session completion notice [Sec 7.4] is sent 1330 to the local client service associated with the session, and the 1331 session is closed: the "Close session" procedure [Sec 6.20] is 1332 invoked. 1334 6.13 Retransmit Data 1336 This procedure is triggered by the reception of an RS segment. 1338 Response: first, an RA segment with the same report serial number as 1339 the RS segment is issued and is, in concept, appended to the queue of 1340 internal operations traffic bound for the Receiver. If the RS 1341 segment is redundant -- i.e., either the indicated session is unknown 1342 (for example, the RS segment is received after the session has been 1343 completed or canceled) or the RS segment's report serial number 1344 matches that of an RS segment that has already been received and 1345 processed -- then no further action is taken. Otherwise the 1346 procedure below is followed. 1348 If the report's checkpoint serial number is not zero, then the 1349 countdown timer associated with the indicated checkpoint segment is 1350 deleted. 1352 Note: All retransmission buffer space occupied by data whose 1353 reception is claimed in the report segment can (in concept) be 1354 released. 1356 If the segment's reception claims indicate incomplete data reception 1357 within the scope of the report segment: 1359 - If the number of transmission problems for this session exceeds 1360 a limit established for the local LTP engine by network 1361 management, then the session of which the segment is one token is 1362 canceled: the "Cancel session" procedure [Sec 6.19] is invoked, a 1363 CS with reason-code RLEXC is appended to the transmission queue 1364 specified in the transmission request that started this session, 1365 and a transmission-session cancellation notice [Sec 7.5] is sent 1366 back to the client service that requested the transmission. One 1367 possible limit on transmission problems would be the maximum 1368 number of retransmission CP segments which may be issued for any 1369 single session. 1371 - If the number of transmission problems for this session has not 1372 exceeded any limit, new data segments encapsulating all block data 1373 whose non-reception is implied by the reception claims are 1374 appended to the transmission queue bound for the Receiver. The 1375 last - and only the last - data segment must be marked as a CP 1376 segment carrying a new CP serial number (obtained by incrementing 1377 the last CP serial number used) and the report serial number of 1378 the received RS segment. 1380 6.14 Stop RS Timer 1382 This procedure is triggered by the reception of an RA. 1384 Response: the countdown timer associated with the original RS segment 1385 (identified by the report serial number of the RA segment) is 1386 deleted. If no other countdown timers associated with RS segments 1387 exist for this session, then the session is closed: the "Close 1388 session" procedure [Sec 6.20] is invoked. 1390 6.15 Start Cancel Timer 1392 This procedure is triggered by arrival of a link state cue indicating 1393 the de-queuing (for transmission) of a Cx segment. 1395 Response: the expected arrival time of the CAx segment that will be 1396 produced on reception of this Cx segment is computed and a countdown 1397 timer for this arrival time is started. However, if it is known that 1398 the remote LTP engine has ceased transmission [Sec 6.5] then this 1399 timer is immediately suspended, because the computed expected arrival 1400 time may require an adjustment that cannot yet be computed. 1402 6.16 Retransmit Cancellation Segment 1404 This procedure is triggered by the expiration of a countdown timer 1405 associated with a Cx segment. 1407 Response: if the number of times this Cx segment has been queued for 1408 transmission exceeds the cancellation retransmission limit 1409 established for the local LTP engine by network management, then the 1410 session of which the segment is one token is simply closed: the 1411 "Close session" procedure [Sec 6.20] is invoked. 1413 Otherwise, a copy of the cancellation segment (retaining the same 1414 reason-code) is queued for transmission to the appropriate LTP 1415 engine. 1417 6.17 Acknowledge Cancellation 1419 This procedure is triggered by the reception of a Cx segment. 1421 Response: in the case of a CS segment where there is no transmission 1422 queue-set bound for the Sender (possibly because the Receiver is a 1423 receive-only device), then no action is taken. Otherwise: 1425 - If the received segment is a CS segment, a CAS (Cancel 1426 acknowledgment to block sender) segment is issued and is, in 1427 concept, appended to the queue of internal operations traffic 1428 bound for the Sender. 1430 - If the received segment is a CR segment, a CAR (Cancel 1431 acknowledgment to block receiver) segment is issued and is, in 1432 concept, appended to the queue of internal operations traffic 1433 bound for the Receiver. 1435 It is possible that the Cx segment has been retransmitted because a 1436 previous responding acknowledgment CAx (Cancel acknowledgment) 1437 segment was lost, in which case there will no longer be any record of 1438 the session of which the segment is one token. If so, no further 1439 action is taken. 1441 Otherwise: the "Cancel session" procedure [Sec 6.19] is invoked and a 1442 reception-session cancellation notice [Sec 7.6] is sent to the client 1443 service identified in each of the data segments received in this 1444 session. Finally, the session is closed: the "Close session" 1445 procedure [Sec 6.20] is invoked. 1447 6.18 Stop Cancel Timer 1449 This procedure is triggered by the reception of a CAx segment. 1451 Response: the timer associated with the Cx segment is deleted, and 1452 the session of which the segment is one token is closed, i.e., the 1453 "Close session" procedure [Sec 6.20] is invoked. 1455 6.19 Cancel Session 1457 This procedure is triggered internally by one of the other procedures 1458 described above. 1460 Response: all segments of the affected session that are currently 1461 queued for transmission can be deleted from the outbound traffic 1462 queues. All countdown timers currently associated with the session 1463 are deleted. Note: If the local LTP engine is the Sender, then all 1464 remaining data retransmission buffer space allocated to the session 1465 can be released. 1467 6.20 Close Session 1469 This procedure is triggered internally by one of the other procedures 1470 described above. 1472 Response: any remaining countdown timers associated with the session 1473 are deleted. The session state record (SSR|RSR) for the session is 1474 deleted; existence of the session is no longer recognized. 1476 6.21 Handle Miscolored Segment 1478 This procedure is triggered by the arrival of either (a) a red-part 1479 data segment whose block offset begins at an offset higher than the 1480 block offset of any green-part data segment previously received for 1481 the same session or (b) a green-part data segment whose block offset 1482 is lower than the block offset of any red-part data segment 1483 previously received for the same session. The arrival of a segment 1484 matching either of the above checks is a violation of the protocol 1485 requirement of having all red-part data as the block prefix and all 1486 green-part data as the block suffix. 1488 Response: the received data segment is simply discarded. 1490 The Cancel Session procedure [Sec 6.19] is invoked and a CR segment 1491 with reason-code MISCOLORED SHOULD be enqueued for transmission to 1492 the data sender. 1494 Note: If there is no transmission queue-set bound for the Sender 1495 (possibly because the local LTP engine is running on a receive-only 1496 device), or if the Receiver knows that the Sender is functioning in a 1497 "beacon" (transmit-only) fashion, a CR segment need not be sent. 1499 A Reception-Session Cancellation Notice [Sec 7.6] is sent to the 1500 client service. 1502 6.22 Handling System Error Conditions 1504 It is possible (especially for long-lived LTP sessions) that an 1505 unexpected operating-system error condition may occur during the 1506 lifetime of an LTP session. An example is the case where the system 1507 faces severe memory crunch forcing LTP sessions into a scenario 1508 similar to that of TCP SACK [SACK] reneging. But unlike TCP SACK 1509 reception reports, which are advisory, LTP reception reports are 1510 binding, and reneging is NOT permitted on previously made reception 1511 claims. 1513 Under any such irrecoverable system error condition, the following 1514 response is to be initiated: the Cancel Session procedure [Sec 6.19] 1515 is invoked. If the error condition is observed on the Sender, a CS 1516 segment with reason-code SYS_CNCLD SHOULD be enqueued for 1517 transmission to the Receiver, and a Transmission-Session Cancellation 1518 Notice [Sec 7.5] is sent to the client service; on the other hand, if 1519 it is observed on the Receiver, a CR segment with the same reason- 1520 code SYS_CNCLD SHOULD be enqueued for transmission to the Sender, and 1521 a Reception-Session Cancellation Notice [Sec 7.6] is sent to the 1522 client service. 1524 Note that as in Sec 6.21, if there is no transmission queue-set bound 1525 for the Sender (possibly because the local LTP engine is running on a 1526 receive-only device), or if the Receiver knows that the sender of 1527 this green-part data is functioning in a "beacon" (transmit-only) 1528 fashion, a CR segment need not be sent. 1530 There may be other implementation-specific limits which may cause an 1531 LTP implementation to initiate session-cancellation procedures. One 1532 such limit is the maximum number of retransmission-cycles seen. A 1533 retransmission cycle at the LTP Sender comprises the two related 1534 events: the transmission of all outstanding CP segments from the 1535 Sender, and the reception of all RS segments issued from the Receiver 1536 in response to those CP segments. A similar definition would apply 1537 at the LTP Receiver but relate to the reception of the CP segments 1538 and transmission of all RS segments in response. Note that the 1539 retransmitted CP and RS segments remain part of their original 1540 retransmission-cycle. Also, a single CP segment may cause multiple 1541 RS segments to be generated if a Reception Report would not fit in a 1542 single datalink-MTU-sized RS segment; all RS segments that are part 1543 of a Reception Report belong to the same retransmission cycle to 1544 which the CP segment belongs. In the presence of severe channel 1545 error conditions, many retransmission cycles may elapse before red- 1546 part transmission is deemed successful; an implementation may 1547 therefore impose a retransmission-cycle limit to shield itself from a 1548 resource-crunch situation. If a sender LTP notices the 1549 retransmission-cycle limit being exceeded, it SHOULD initiate the 1550 Cancel Session Procedure [Sec 6.19], queuing a CS segment with 1551 reason-code RXMTCYCEXC and sending a Transmission-Session 1552 Cancellation Notice [Sec 7.5] to the client service. 1554 7. Notices to Client Service 1556 In all cases the representation of notice parameters is a local 1557 implementation matter. 1559 7.1 Session Start 1561 The Session Start notice returns the Session ID identifying a newly 1562 created session. 1564 At the Sender, the session start notice informs the client service of 1565 the initiation of the transmission session. On receiving this notice 1566 the client service may, for example, release resources of its own 1567 that are allocated to the block being transmitted, or remember the 1568 session ID so that the session can be canceled in the future if 1569 necessary. At the Receiver, this notice indicates the beginning of a 1570 new reception session, and is delivered upon arrival of the first 1571 data segment carrying a new Session ID. 1573 7.2 Green-Part Segment Arrival 1575 The following parameters are provided by the LTP engine when a green- 1576 part segment arrival notice is delivered: 1578 Session ID of the transmission session. 1580 Array of client service data bytes contained in the data segment. 1582 Offset of the data segment's content from the start of the block. 1584 Length of the data segment's content. 1586 Indication as to whether or not the last byte of this data 1587 segment's content is also the end of the block. 1589 Source LTP engine ID. 1591 7.3 Red-Part Reception 1593 The following parameters are provided by the LTP engine when a red- 1594 part reception notice is delivered: 1596 Session ID of the transmission session. 1598 Array of client service data bytes that constitute the red-part of 1599 the block. 1601 Length of the red-part of the block. 1603 Indication as to whether or not the last byte of the red-part is 1604 also the end of the block. 1606 Source LTP engine ID. 1608 7.4 Transmission-Session Completion 1610 The sole parameter provided by the LTP engine when a transmission- 1611 session completion notice is delivered is the session ID of the 1612 transmission session. 1614 A transmission-session completion notice informs the client service 1615 that all bytes of the indicated data block have been transmitted, and 1616 that the Receiver has received the red-part of the block. 1618 7.5 Transmission-Session Cancellation 1620 The parameters provided by the LTP engine when a transmission-session 1621 cancellation notice is delivered are: 1623 Session ID of the transmission session. 1625 The reason-code sent or received in the Cx segment that initiated 1626 the cancellation sequence. 1628 A transmission-session cancellation notice informs the client service 1629 that the indicated session was terminated, either by the Receiver or 1630 else due to an error or a resource quench condition in the local LTP 1631 engine. There is no assurance that the destination client service 1632 instance received any portion of the data block. 1634 7.6 Reception-Session Cancellation 1636 The parameters provided by the LTP engine when a reception 1637 cancellation notice is delivered are: 1639 Session ID of the transmission session. 1641 The reason-code explaining the cancellation. 1643 A reception-session cancellation notice informs the client service 1644 that the indicated session was terminated, either by the Sender or 1645 else due to an error or a resource quench condition in the local LTP 1646 engine. No subsequent delivery notices will be issued for this 1647 session. 1649 7.7 Initial-Transmission Completion 1651 The session ID of the transmission session is included with the 1652 initial-transmission completion notice. 1654 This notice informs the client service that all segments of a block 1655 (both red-part and green-part) have been transmitted. This notice 1656 only indicates that original transmission is complete; retransmission 1657 of any lost red-part data segments may still be necessary. 1659 8. State Transition Diagrams 1660 The following mnemonics have been used in the sender and receiver LTP 1661 state transition diagrams that follow : 1663 TE Timer Expiry 1664 RDS Regular Red Data Segment (NOT {CP|EORP|EOB}) 1665 GDS Regular Green Data Segment (NOT EOB) 1666 RL EXC Retransmission Limit Exceeded 1667 RP Red-Part 1668 GP Green-Part 1669 FG Fully-Green 1671 Note that blocks represented in rectangles, as in 1673 +---------+ 1674 | FG_XMIT | 1675 +---------+ 1677 specify actual states in the state-transition diagrams, while blocks 1678 represented with jagged edges, as in 1680 /\/\/\/\ 1681 | Cncld | 1682 \/\/\/\/ 1684 are either pointers to a state or place-holders for sequences of 1685 state transitions. 1687 8.1 Sender 1688 LTP Sender State Transition Diagram 1690 /\/\/\/\ 1691 | Cncld | 1692 \/\/\/\/ 1693 +--------+ | +------+ 1694 Rcv CR; | V V V | Rcv RS; 1695 Snd CAR | +-------------+ | Snd RA 1696 +-------+ CLOSED +----+ 1697 +---------------------------->+------+------+ 1698 | | Blk. Trans. Req 1699 | Zero RP + 1700 | Xmit ________________________/ \ Non-Zero RP 1701 | GDS; / \ 1702 | +---+ | +------------------+ | +------+ 1703 | | V V | /\/\ Rcv RS V V V | 1704 | | +---------+ +<-| RX |<---+ +---------+ | 1705 | +<-+ FG_XMIT | | \/\/ +---+ +--->+ Xmit RDS; 1706 | +----+----+ | | RP_XMIT | | 1707 | | | /\/\ +---+ +--->+ Xmit {RDS, CP}; 1708 +<--------+ +<-| CP |<---+ +-----+---+ Start CP Tmr 1709 | Xmit \/\/ CP TE | \ 1710 | {GDS, EOB}; | | 1711 | Xmit {RDS, CP, EORP}; | +-------+ 1712 | Start CP Tmr | | 1713 | | | 1714 | +------------------+ | +---+ | Xmit {RDS, 1715 | | /\/\ Rcv RS V V V | | CP, EORP, 1716 | +<-| RX |<---+ +---------+ | | EOB}; 1717 | | \/\/ +---+ | | | Start 1718 | | | GP_XMIT +->+ | CP Tmr 1719 | | /\/\ +---+ | Xmit | 1720 | +<-| CP |<---+ +-----+---+ GDS; | 1721 | \/\/ CP TE | | 1722 | | | 1723 | Xmit {GDS, EOB}; | +---------+ 1724 | | | 1725 | +------------------+ | | 1726 | | /\/\ Rcv RS V V V 1727 | +<-| RX |<---+ +-------------+ 1728 | | \/\/ +---+ | 1729 | | | WAIT_RP_ACK | 1730 | | /\/\ +---+ | 1731 | +<-| CP |<---+ +-----+-------+ 1732 | \/\/ CP TE | RP acknowledged fully; 1733 | V 1734 +----------------------------------------+ 1735 LTP Sender State Transition Diagram (contd.) 1737 /\/\ /\/\ 1738 |CP| |CX | 1739 \/\/ \/\/ 1740 | | | Snd CS, 1741 | | RL EXC; | Start CS Tmr; 1742 | | | 1743 | | /\/\ | +---+ 1744 | +------>| CX | V V | 1745 | \/\/ +---------+ | CS TE, 1746 | | CS_SENT | | RL NOT EXC; 1747 V RL NOT EXC; +-+--+--+-+ | Rxmt CS, 1748 Rxmt CP, | | | | Restart 1749 Start CP Tmr; CS TE, | | +---+ CS Tmr 1750 RL EXC; | | 1751 | | Rcv CAS; 1752 V V 1753 /\/\/\/\ 1754 | Cncld | 1755 \/\/\/\/ 1757 /\/\ 1758 | RX | 1759 \/\/ 1760 | Cncl CP Tmr (if any) 1761 V Snd RA 1762 +---------+ +----+ 1763 | CHK_RPT | | | 1764 +-+--+----+ RP in scope V | 1765 | | \ NOT rcvd. fully +---------+ | Rxmt 1766 Redundant | | RP +--------------------->| RP_RXMT | | missing 1767 RS rcvd; | | in scope +----+--+-+ | RDS; 1768 | | rcvd. fully | | | 1769 V V Rxmt last | +----+ 1770 missing RDS | 1771 (marked CP) | 1772 Start CP Tmr; | 1773 V 1774 Asynchronous cancel request may be received from the local client 1775 service while the sender LTP is in any of the states shown. If it 1776 was not already in the sequence of state transitions beginning at the 1777 CX marker, the internal procedure Cancel Session [Sec 6.19] is 1778 followed, and the sender LTP moves from its current state into the 1779 sequence beginning at the CX marker initiating session cancellation 1780 with reason-code USR_CNCLD. From the CX marker, the CS segment with 1781 appropriate reason-code (USR_CNCLD or RLEXC depending on how the CX 1782 sequence was entered) is queued for transmission to the receiver LTP 1783 and the sender enters the Cancel-from-Sender Sent(CS_SENT) state. 1784 The internal procedure Start Cancel Timer [Sec 6.15] is started upon 1785 receiving a link-state cue indicating the beginning of transmission 1786 of the CS segment. Upon receiving the acknowledging CAS segment from 1787 the receiver, the sender LTP moves to the CLOSED state (via the 1788 'Cncld' pointer). If the CS Timer expires, the internal procedure 1789 Retransmit Cancellation Segment [Sec 6.16] is followed: 1791 - If the network management set retransmission limit is exceeded, 1792 the session is simply closed and the sender LTP follows the Cncld 1793 marker to the CLOSED state. If the retransmission limit is not 1794 exceeded however, the CS segment is queued for a retransmission 1795 and the sender LTP stays in the CS_SENT state. The CS Timer is 1796 started upon receiving a link-state cue indicating the beginning 1797 of actual transmission according to the internal procedure Start 1798 Cancel Timer [Sec 6.15]. 1800 Asynchronous cancel request may also be received from the receiver 1801 LTP in the form of a CR segment when the sender LTP is in any of the 1802 states. Upon receiving such a CR segment, the internal procedure 1803 Acknowledge Cancellation [Sec 6.17] is invoked: The sender LTP sends 1804 a CAR segment in response and returns to the CLOSED state. 1806 The sender LTP stays in the CLOSED state until receiving a Block 1807 Transmission Request (Blk. Trans. Req) from the client service 1808 instance. Upon receiving the request it either moves to the Fully 1809 Green Transmission State (FG_XMIT) if no portion of the block was 1810 requested to be transmitted as red, or to the Red-Part Transmission 1811 State (RP_XMIT) state if a non-zero block-prefix was requested to be 1812 transmitted red. 1814 In the FG_XMIT state, the block is segmented as multiple green LTP 1815 data segments respecting the link MTU size and the segments are 1816 queued for transmission to the remote engine. The last such segment 1817 is marked as EOB and the sender LTP returns to the CLOSED state after 1818 queuing it for transmission. 1820 Similarly, from the RP_XMIT state multiple red data segments are 1821 queued for transmission, respecting the link MTU size. The sender 1822 LTP may optionally mark some of the red data segments as asynchronous 1823 checkpoints; the internal procedure Start Checkpoint Timer [Sec 6.2] 1824 is followed upon receiving a link-state cue indicating the 1825 transmission of the asynchronous checkpoints. If the block 1826 transmission request comprises a non-zero Green Part, the sender LTP 1827 marks the last red-data segment as CP and EORP, and after queuing it 1828 for transmission, moves to the Green Part Transmission (GP_XMIT) 1829 state. If the block transmission request was fully red however, the 1830 last red-data segment is marked as CP, EORP, and EOB and the sender 1831 LTP moves directly to the Wait-for-Red-Part-Acknowledgment 1832 (WAIT_RP_ACK) state. In both the above state-transitions, the 1833 internal procedure Start Checkpoint Timer [Sec 6.2] is followed upon 1834 receiving a link-state cue indicating the beginning of transmission 1835 of the queued CP segments. In the GP_XMIT state, the green-part of 1836 the block is segmented as green data segments and queued for 1837 transmission to the receiver LTP; the last green segment of the block 1838 is additionally marked as EOB, and after queueing it for transmission 1839 the sender LTP moves to the WAIT_RP_ACK state. 1841 While the sender LTP is at any of the RP_XMIT, GP_XMIT, or 1842 WAIT_RP_ACK states, it might be interrupted by the occurrence of the 1843 following events: 1845 1. An RS might be received from the receiver LTP (either in 1846 response to a previously transmitted CP segment or sent 1847 asynchronously for accelerated retransmission). The sender LTP 1848 then moves to perform the sequence of state transitions beginning 1849 at the RX marker (second-part of the diagram), and retransmits 1850 data if necessary, illustrating the internal procedure Retransmit 1851 Data [Sec 6.13]: 1853 First, if the RS segment had a non-zero CP serial number, the 1854 corresponding CP timer is canceled. Then an RA segment 1855 acknowledging the received RS segment is queued for transmission 1856 to the receiver LTP and the sender LTP moves to the Check Report 1857 state (CHK_RPT). If the RS segment was redundantly transmitted by 1858 the receiver LTP (possibly because either the last transmitted RA 1859 segment got lost or the RS segment timer expired prematurely at 1860 the receiver), the sender LTP does nothing more and returns back 1861 to the interrupted state. Similarly, if all red-data within the 1862 scope of the RS segment is reported as received, there is no work 1863 to be done and the sender LTP returns to the interrupted state. 1864 However, if the RS segment indicated incomplete reception of data 1865 within its scope, the sender LTP moves to the Red-part Retransmit 1866 state (RP_RXMT) where missing red data-segments within scope are 1867 queued for transmission. The last such segment is marked as a CP, 1868 and the sender LTP returns to the interrupted state. The internal 1869 procedure [Sec 6.2] is followed upon receiving a link-state cue 1870 indicating the beginning of transmission of the CP segment. 1872 2. A previously set CP timer might expire. Now the sender LTP 1873 follows the states beginning at the CP marker (second-part of the 1874 diagram), and follows the internal procedure Retransmit Checkpoint 1875 [Sec 6.7]: 1877 If the CP Retransmission Limit set by network management for the 1878 session has been exceeded, the sender LTP proceeds towards 1879 canceling the session (with reason-code RLEXC) as indicated by the 1880 sequence of state transitions following the CX marker. Otherwise 1881 (if the Retransmission Limit is not exceeded yet), the CP segment 1882 is queued for retransmission and the sender LTP returns to the 1883 interrupted state. The Start Checkpoint Timer internal procedure 1884 [Sec 6.2] is started again upon receiving a link-state cue 1885 indicating the beginning of transmission of the segment. 1887 The sender LTP stays at the WAIT_RP_ACK state after reaching it until 1888 the red-part data is fully acknowledged as received by the receiver 1889 LTP, and then returns to the CLOSED state following the internal 1890 procedure Close Session [Sec 6.20]. 1892 Note that while at the CLOSED state, the sender LTP might receive an 1893 RS segment (if the last transmitted RA segment before session close 1894 got lost or if the receiver LTP retransmitted the RS segment 1895 prematurely), in which case it retransmits an acknowledging RA 1896 segment and stays in the CLOSED state. If the session was canceled 1897 by the Receiver by issuing a CR segment, the receiver may retransmit 1898 the CR segment (either prematurely or because the acknowledging CAR 1899 segment got lost). In this case, the sender LTP retransmits the 1900 acknowledging CAR segment and stays in the CLOSED state. 1902 8.2 Receiver 1903 LTP Receiver State Transition Diagram 1905 /\/\/\/\ 1906 +----+ +----+ Cncld | 1907 Rcv CS; | V V \/\/\/\/ 1908 Snd CAS | +-------------+ 1909 +--+ CLOSED +<--------------------------+ 1910 +------+------+ | 1911 +----+ | Rcv first DS | 1912 Rcv RA; | V V | 1913 Cncl RS Tmr | +--------+ | 1914 +---+ DS_REC | | 1915 +----------------------------->+-+--+-+-+<----------------------+---+ | 1916 | Svc. does not exist | | | RS TE | | | 1917 | /\/\ or Rcv miscolored seg. | | | /\/\ | | | 1918 | | CX |<-----------------------+ | +------------->| RX |---->+ | | 1919 | \/\/ | \/\/ | | 1920 | Rcv RDS; | Rcv GDS; | | 1921 | +-----------+------------+ | | 1922 | V V | | 1923 | /\/\ RS TE +--------------+ +--------+ | | 1924 +<-| RX |<------+ RCV_RP | | RCV_GP | | | 1925 | \/\/ +-+----+--+--+-+ +--+-+-+-+ | | 1926 | | | | | | | | | | 1927 | Rcvd RDS; | | | | Rcvd {RDS, CP, | | | RS TE /\/\ | | 1928 | | | | | EORP, EOB}; | | +------>| RX |->+ | 1929 +<----------------+ | | | Snd RS, | | \/\/ | | 1930 | | | | Start RS Tmr | | Rcvd GDS; | | 1931 | Rcvd {RDS, CP}; | | | | +---------------->+ | 1932 | Snd RS, Start RS Tmr | | +-------+ +-----+ | 1933 +<---------------------+ | | | Rcvd {GDS, EOB}; | 1934 | | | | | 1935 | | +-----+ | | +------+ | 1936 | Rcvd {RDS, CP, EORP}; | | V V V V | | 1937 | Snd RS, Start RS Tmr | | +----------------+ | Rcv RDS; | 1938 | | | | +-->+ | 1939 | | | | WAIT_RP_REC | | Rcv {RDS, CP}; | 1940 | | | | +-->+ Snd RS, Start | 1941 +<------------------------+ | +---+--+-+-+-----+ | RS Tmr | 1942 | RS TE | | | | Rcv RA; | | 1943 | V | | | Cncl | | 1944 | /\/\ | | | RS Tmr | | 1945 +---| RX | | | +-------->+ | 1946 \/\/ | | | 1947 /\/\ | | | 1948 | CX |<------------------------+ | RP rcvd. fully | 1949 \/\/ Rcv miscolored seg. +--------------------------->+ 1950 LTP Receiver State Transition Diagram (contd.) 1952 /\/\ 1953 | RX | 1954 \/\/ 1955 | | 1956 | | RL EXC; /\/\ 1957 RL NOT EXC; | +---------->| CX | 1958 Rxmt RS, | \/\/ 1959 Start RS Tmr | 1960 V 1962 /\/\ 1963 | CX | 1964 \/\/ 1965 | Snd CR, 1966 | Start CR Tmr; 1967 | 1968 | +----+ 1969 V V | 1970 +---------+ | CR TE, 1971 | CR_SENT | | RL NOT EXC; 1972 +-+--+--+-+ | Rxmt CR, 1973 | | | | Restart 1974 CR TE, | | +---+ CR Tmr 1975 RL EXC; | | 1976 | | Rcv CAR; 1977 V V 1978 /\/\/\/\ 1979 | Cncld | 1980 \/\/\/\/ 1981 Asynchronous cancel requests are handled in a manner similar to the 1982 way they are handled in the sender LTP. If the cancel request was 1983 made from the local client service instance and the receiver LTP was 1984 not already in the CR_SENT state, a CR segment with reason-code 1985 USR_CNCLD SHOULD be sent to the sender LTP following the sequence of 1986 state transitions beginning at the CX marker as described above. If 1987 the asynchronous cancel request is received from the sender LTP, a 1988 CAS segment is sent and the receiver LTP moves to the CLOSED state 1989 (independent of the state the receiver LTP may be in). 1991 The receiver LTP begins at the CLOSED state and enters the Data 1992 Segment Reception (DS_REC) state upon receiving the first data 1993 segment. If the client service ID referenced in the data segment was 1994 non-existent, a Cx segment with reason-code UNREACH SHOULD be sent to 1995 the sender LTP via the Cancellation sequence beginning with the CX 1996 marker (second part of the diagram). If the received segment was 1997 found to be miscolored, the internal procedure Handle Miscolored 1998 Segment [Sec 6.21] is followed, and a CX segment with reason-code 1999 MISCOLORED SHOULD be sent to the sender LTP with the Cancellation 2000 sequence beginning with the CX marker. 2002 Otherwise, the receiver LTP enters the Receive Red-Part state 2003 (RCV_RP) or the Receive Green-Part state (RCV_GP) depending on 2004 whether the segment received was red or green, respectively. 2006 In the RCV_RP state, a check is made of the nature of the received 2007 red DS. If the segment was a regular red data segment, the receiver 2008 LTP just returns to the DS_REC state. For red data segments marked 2009 also as CP and as CP & EORP, a responding RS segment is queued for 2010 transmission to the sender following either the internal procedure 2011 Retransmit RS [Sec 6.8] or Send Reception Report [Sec 6.11] depending 2012 on whether the CP segment was a retransmission (An RS segment 2013 corresponding to the Checkpoint Serial Number in the CP segment was 2014 previously issued) or not, respectively. The receiver LTP then 2015 returns to the DS_REC state. If the block transmission was fully red 2016 and the segment was marked as CP, EORP, and EOB, the receiver LTP 2017 enters the Wait-for-Red-Part-Reception state (WAIT_RP_REC). In all 2018 cases the internal procedure Start RS Timer [Sec 6.3] is followed 2019 upon receiving link-state cues indicating beginning of transmission 2020 of the RS segments. 2022 In the RCV_GP state, if the received green data segment was not 2023 marked EOB, the receiver LTP returns to the DS_REC state. Otherwise 2024 it enters the WAIT_RP_REC state to receive the red-part of the block 2025 fully. 2027 A previously set RS timer may expire and interrupt the receiver LTP 2028 while in the DS_REC, RCV_RP, RCV_GP, or WAIT_RP_REC states. If so, 2029 the internal procedure Retransmit RS [Sec 6.8] is followed as 2030 illustrated in the states beginning at the RX marker (shown in the 2031 second part of the diagram) before returning to the interrupted 2032 state: 2034 - A check is made here to see if the retransmission limit set by 2035 the network management has been exceeded in the number of RSs sent 2036 in the session. If so, a CR segment with reason-code RLEXC SHOULD 2037 be sent to the sender LTP and the sequence indicated by the CX 2038 marker is followed. Otherwise, the RS segment is queued for 2039 retransmission and the associated RS timer is started following 2040 the internal procedure Start RS Timer [Sec 6.3] upon receiving a 2041 link-state cue indicating the beginning of its transmission. 2043 The receiver LTP may also receive RA segments from the sender in 2044 response to the RS segments sent while in the DS_REC state. If so, 2045 then the RS timer corresponding to the report serial number mentioned 2046 in the RA segment is canceled following the internal procedure Stop 2047 RS Timer [Sec 6.14]. 2049 The receiver LTP stays in the WAIT_RP_REC state until the entire red- 2050 part of the block is received, and moves to the CLOSED state upon 2051 full red-part reception. In this state, a check is made upon 2052 reception of every red-part data segment to see if it is at a block 2053 offset higher than any green-part data segment received. If so, the 2054 Handle Miscolored Segment internal procedure [Sec 6.21] is invoked 2055 and the sequence of state transitions beginning with the CX marker is 2056 followed; a CX segment with reason-code MISCOLORED SHOULD be sent to 2057 the sender LTP with the Cancellation sequence beginning with the CX 2058 marker. 2060 Note that if there were no red data segments received in the session 2061 yet, including the case where the session was indeed fully green or 2062 the pathological case where the entire red-part of the block gets 2063 lost but at least the green data segment marked EOB is received (the 2064 receiver LTP has no indication of whether the session had a red-part 2065 transmission), the receiver LTP assumes the "RP rcvd. fully" 2066 condition to be true and moves to the CLOSED state from the 2067 WAIT_RP_REC state. 2069 In the WAIT_RP_REC state, the receiver LTP may receive the 2070 retransmitted red data segments. Upon receiving red data segments 2071 marked CP, it queues the responding RS segment for transmission based 2072 on either internal procedure Retransmit RS [Sec 6.8] or Send 2073 Reception Report [Sec 6.11] depending on whether the CP was found to 2074 be a retransmission or not, respectively. The Start RS Timer 2075 internal procedure is invoked upon receiving a link-state cue 2076 indicating the beginning of transmission of the RS segment. If an RA 2077 segment is received, the RS timer corresponding to the report segment 2078 mentioned is canceled and the receiver LTP stays in the state until 2079 the entire red-part is received. 2081 In the sequence of state transitions beginning at the CX marker, the 2082 CR segment with the given reason-code (depending on how the sequence 2083 is entered) is queued for transmission, and the CR timer is started 2084 upon reception of the link-state cue indicating actual transmission 2085 following internal procedure Start Cancel Timer [Sec 6.15]. If the 2086 CAR segment is received from the sender LTP, the receiver LTP returns 2087 to the CLOSED state (via the Cncld marker) following the Stop Cancel 2088 Timer internal procedure [Sec 6.18]. If the CR timer expires 2089 asynchronously, the internal procedure Retransmit Cancellation 2090 Segment [Sec 6.16] is followed : 2092 A check is made to see if the retransmission limit set by the 2093 network management for the number of CR segments per session has 2094 been exceeded. If so, the receiver LTP returns to the CLOSED 2095 state following the Cncld marker. Otherwise, a CR segment is 2096 scheduled for retransmission with the CR timer being started 2097 following the internal procedure Start Cancel Timer [Sec 6.15] 2098 upon reception of a link-state cue indicating actual transmission. 2100 The receiver LTP might also receive a retransmitted CS segment at the 2101 CLOSED state (either if the CAS segment previously transmitted was 2102 lost or if the CS timer expired prematurely at the sender LTP). In 2103 such a case the CAS is scheduled for retransmission. 2105 9. Security Considerations 2107 9.1 Denial of Service Considerations 2109 Implementers SHOULD consider the likelihood of the following DoS 2110 attacks : 2112 - A fake Cx could be inserted, thus bringing down a session. 2114 - Various acknowledgment segments (RA, RS, etc.) could be deleted, 2115 causing timers to expire, and having the potential to disable 2116 communication altogether if done with a knowledge of the 2117 communications schedule. This could be achieved either by 2118 mounting a DoS attack on a lower layer service in order to prevent 2119 it from sending an acknowledgment segment, or by simply jamming 2120 the transmission (all of which are more likely for terrestrial 2121 applications of LTP). 2123 - An attacker might also corrupt some bits, which is tantamount to 2124 deleting that segment. 2126 - An attacker may flood a node with segments for the internal 2127 operations queue and prevent transmission of legitimate data 2128 segments. 2130 - An attacker could attempt to fill up the storage in a node by 2131 sending many large messages to it. In terrestrial LTP 2132 applications this may be much more serious since spotting the 2133 additional traffic may not be possible from any network management 2134 point. 2136 If any of the above DoS attacks is likely, then one or more of the 2137 anti-DoS mechanisms ought to be employed. LTP includes the following 2138 anti-DoS mechanisms: 2140 - Session numbers SHOULD be partly random making it harder to 2141 insert valid segments. 2143 - A node which suspects that either it or its peer is under DoS 2144 attack could frequently checkpoint its data segments (if it were 2145 the sender) or send asynchronous RSs (if it were the receiver), 2146 thus eliciting an earlier response from its peer or timing out 2147 earlier due to the failure of an attacker to respond. 2149 - Serial numbers (checkpoint serial numbers, report serial 2150 numbers) MUST begin each session anew using random numbers rather 2151 than from 0. 2153 - The authentication header [LTPEXT]. 2155 9.2 Replay Handling 2157 The following algorithm is given as an example of how an LTP 2158 implementation MAY handle replays. 2160 1. On receipt of an LTP segment, check against a cache for replay. 2161 If this is a replay segment and if a pre-cooked response is available 2162 (stored from the last time this segment was processed), then send the 2163 pre-cooked response. If there is no pre-cooked response then 2164 silently drop the inbound segment. This can all be done without 2165 attempting to decode the buffer. 2167 2. If the inbound segment does not decode correctly, then silently 2168 drop the segment. If the segment decodes properly, then add its hash 2169 to the replay cache and return a handle to the entry. 2171 3. For those cases where a pre-cooked response should be stored, 2172 store the response using the handle received from the previous step. 2173 These cases include: 2175 (a) when the inbound packet is a CP segment the RS segment sent in 2176 response gets stored as pre-cooked; 2178 (b) when the incoming packet is an RS segment the RA segment is 2179 stored as precooked, and, 2181 (c) when the incoming packet is a Cx segment the CAx segment sent 2182 in response gets stored precooked. 2184 4. Occasionally clean out the replay cache - how frequently this 2185 happens in an implementation issue. 2187 The downside of this algorithm is that receiving a totally bogus 2188 segment still results in a replay cache search and attempted LTP 2189 decode operation. It is not clear that it is possible to do much 2190 better though, since all an attacker would have to do to get past the 2191 replay cache would be to tweak a single bit in the inbound segment 2192 each time, which is certainly cheaper than the hash+lookup+decode 2193 combination, though also certainly more expensive than simply sending 2194 the same octets many times. 2196 The benefit of doing this is that implementers no longer need to 2197 analyze many bugs/attacks based on replaying packets, which in 2198 combination with the use of LTP authentication should defeat many 2199 attempted DoS attacks. 2201 9.3 Implementation Considerations 2203 SDNV 2205 Implementations SHOULD make sanity checks on SDNV length fields 2206 and SHOULD check that no SDNV field is too long when compared with 2207 the overall segment length. 2209 Implementations SHOULD check that SDNV values are within suitable 2210 ranges where possible. 2212 Byte ranges 2214 Various report and other segments contain offset and length 2215 fields. Implementations MUST ensure that these are consistent and 2216 sane. 2218 Randomness 2220 Various fields in LTP (e.g. serial numbers) MUST be initialized 2221 using random values. Good sources of randomness which are not 2222 easily guessable SHOULD be used [ESC05]. The collision of random 2223 values is subject to the birthday paradox, which means that a 2224 collision is likely after roughly the square-root of the space has 2225 been seen (e.g. 2^16 in the case of a 32-bit random value). 2226 Implementers MUST ensure that they use sufficiently long random 2227 values so that the birthday paradox doesn't cause a problem in 2228 their environment. 2230 10. IANA Considerations 2232 10.1 UDP Port Number for LTP 2234 <> 2238 The UDP port number 1113 with the name "ltp-deepspace" has been 2239 reserved for LTP deployments. An LTP implementation may be 2240 implemented to operate over UDP datagrams using this port number for 2241 study and testing over the Internet. 2243 10.1 LTP Extension Tag Registry 2245 <> 2253 Section 3.1 above calls for a new registry to be created by the IANA, 2254 maintaining the set of known LTP Extension Tags. The registry will 2255 be initially populated using the values given in Section 3.1 above. 2256 IANA may assign LTP Extension Tag values from the range 0x02-0xAF 2257 (inclusive) using the Specifiction Required rule. [GUIDE] The 2258 Specification concerned can be an RFC (whether Standards Track, 2259 Experimental or Informational), or a specification from any other 2260 standards development organisation recognised by IANA or with a 2261 liaison with the IESG, specifically including CCSDS. 2262 (http://www.ccsds.org/) Any use of Reserved values (0xB0-0xBF 2263 inclusive) requires an update this specification. 2265 11. Acknowledgments 2267 Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian 2268 Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss for 2269 their thoughts on this protocol and its role in Delay-Tolerant 2270 Networking architecture. 2272 Part of the research described in this document was carried out at 2273 the Jet Propulsion laboratory, California Institute of Technology, 2274 under a contract with the National Aeronautics and Space 2275 Administration. This work was performed under DOD Contract DAA-B07- 2276 00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; 2277 and NASA Contract NAS7-1407. 2279 Thanks are also due to Shawn Ostermann, Hans Kruse, Dovel Myers, and 2280 Jayram Deshpande at Ohio University for their suggestions and advice 2281 in making various design decisions. 2283 Part of this work was carried out at Trinity College Dublin as part 2284 of the SeNDT contract funded by Enterprise Ireland's research 2285 innovation fund. 2287 12. References 2289 12.1 Normative References 2291 [B97] S. Bradner, "Key words for use in RFCs to Indicate Requirement 2292 Levels", BCP 14, RFC 2119, March 1997. 2294 [GUIDE] Narten, T. & Alvestrand, H. "Guidelines for Writing IANA 2295 Considerations Sections in RFCs," BCP 26, RFC 5226, May 2008. 2297 [LTPMTV] Burleigh, S., Ramadas, M., and Farrell, S., "Licklider 2298 Transmission Protocol - Motivation", draft-irtf-dtnrg-ltp- 2299 motivation-07.txt (Work in Progress), June 2008. 2301 [LTPEXT] Farrell, S., Ramadas, M., and Burleigh, S., "Licklider 2302 Transmission Protocol - Extensions", draft-irtf-dtnrg-ltp- 2303 extensions-08.txt (Work in Progress), June 2008. 2305 12.2 Informative References 2307 [ASN1] Abstract Syntax Notation One (ASN.1). ASN.1 Encoding Rules: 2308 Specification of Basic Encoding Rules (BER), Canonical Encoding Rules 2309 (CER), and Distinguished Encoding Rules (DER). ITU-T Rec. X.690 2310 (2002) | ISO/IEC 8825-1:2002. 2312 [BP] K. Scott and S. Burleigh, "Bundle Protocol Specification", RFC 2313 5050, November 2007. 2315 [DTN] K. Fall, "A Delay-Tolerant Network Architecture for Challenged 2316 Internets", In Proceedings of ACM SIGCOMM 2003, Karlsruhe, Germany, 2317 Aug 2003. 2319 [ESC05] D. Eastlake, J. Schiller and S. Crockerr, "Randomness 2320 Recommendations for Security", RFC 4086, June 2005. 2322 [SACK] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, "TCP 2323 Selective Acknowledgement Options", RFC 2018, October 1996. 2325 13. Author's Addresses 2327 Manikantan Ramadas 2328 Internetworking Research Group 2329 301 Stocker Center 2330 Ohio University 2331 Athens, OH 45701 2332 Telephone +1 (740) 593-1562 2333 Email mramadas@irg.cs.ohiou.edu 2335 Scott C. Burleigh 2336 Jet Propulsion Laboratory 2337 4800 Oak Grove Drive 2338 M/S: 301-490 2339 Pasadena, CA 91109-8099 2340 Telephone +1 (818) 393-3353 2341 FAX +1 (818) 354-1075 2342 Email Scott.Burleigh@jpl.nasa.gov 2344 Stephen Farrell 2345 Computer Science Department 2346 Trinity College Dublin 2347 Ireland 2348 Telephone +353-1-896-1761 2349 Email stephen.farrell@cs.tcd.ie 2351 Intellectual Property Statement 2353 The IETF takes no position regarding the validity or scope of any 2354 Intellectual Property Rights or other rights that might be claimed to 2355 pertain to the implementation or use of the technology described in 2356 this document or the extent to which any license under such rights 2357 might or might not be available; nor does it represent that it has 2358 made any independent effort to identify any such rights. Information 2359 on the procedures with respect to rights in RFC documents can be 2360 found in BCP 78 and BCP 79. 2362 Copies of IPR disclosures made to the IETF Secretariat and any 2363 assurances of licenses to be made available, or the result of an 2364 attempt made to obtain a general license or permission for the use of 2365 such proprietary rights by implementers or users of this 2366 specification can be obtained from the IETF on-line IPR repository at 2367 http://www.ietf.org/ipr. 2369 The IETF invites any interested party to bring to its attention any 2370 copyrights, patents or patent applications, or other proprietary 2371 rights that may cover technology that may be required to implement 2372 this standard. Please address the information to the IETF at ietf- 2373 ipr@ietf.org. 2375 Disclaimer of Validity 2377 This document and the information contained herein are provided on an 2378 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2379 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2380 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2381 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2382 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2383 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2385 Copyright Statement 2387 Copyright (C) The IETF Trust (2008). This document is subject to the 2388 rights, licenses and restrictions contained in BCP 78, and except as 2389 set forth therein, the authors retain all their rights. 2391 Acknowledgment 2393 Funding for the RFC Editor function is currently provided by the 2394 Internet Society.