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