idnits 2.17.1 draft-irtf-dtnrg-ltp-02.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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2225. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 49 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 47 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1593 has weird spacing: '...ollowed upon ...' -- 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SDNV-8' is mentioned on line 734, but not defined == Missing Reference: 'SDNV-16' is mentioned on line 687, but not defined == Unused Reference: 'IPN' is defined on line 2180, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-irtf-dtnrg-ltp-motivation-00 ** Downref: Normative reference to an Informational draft: draft-irtf-dtnrg-ltp-motivation (ref. 'LTPMOTIVE') == Outdated reference: A later version (-08) exists of draft-irtf-dtnrg-ltp-extensions-00 ** Downref: Normative reference to an Experimental draft: draft-irtf-dtnrg-ltp-extensions (ref. 'LTPEXT') -- Obsolete informational reference (is this intentional?): RFC 2402 (ref. 'AH') (Obsoleted by RFC 4302, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 1750 (ref. 'ECS94') (Obsoleted by RFC 4086) Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Delay Tolerant Networking Research Group M. Ramadas 2 Internet Draft Ohio University 3 S. Burleigh 4 December 2004 NASA/Jet Propulsion Laboratory 5 Expires June 2005 S. Farrell 6 Trinity College Dublin 8 Licklider Transmission Protocol - Specification 10 Status of this Memo 12 By submitting this Internet-Draft, we certify that any applicable 13 patent or other IPR claims of which we are aware have been disclosed, 14 or will be disclosed, and any of which we become aware will be 15 disclosed, in accordance with RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than a "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in [B97]. 37 Discussions on this internet-draft are being made in the Delay 38 Tolerant Networking Research Group (DTNRG) mailing list. More 39 information can be found in the DTNRG web-site at 40 http://www.dtnrg.org 42 Abstract 44 This document describes the Licklider Transmission Protocol (LTP) 45 designed to provide retransmission-based reliability over links 46 characterized by extremely long message round-trip times (RTTs) 47 and/or frequent interruptions in connectivity. Since communication 48 across interplanetary space is the most prominent example of this 49 sort of environment, LTP is principally aimed at supporting "long- 50 haul" reliable transmission in interplanetary space, but has 51 applications in other environments as well. 53 In an Interplanetary Internet setting deploying the Bundling protocol 54 being developed by the Delay Tolerant Networking Research Group, LTP 55 is intended to serve as a reliable convergence layer over single hop 56 deep-space RF links. LTP does ARQ of data transmissions by soliciting 57 selective-acknowledgment reception reports. It is stateful, and has 58 no negotiation or handshakes. 60 Table of Contents 62 1. Introduction ................................................. 3 63 2. Terminology .................................................. 3 64 3. Segment Structure ............................................ 8 65 3.1 Segment Header ........................................... 9 66 3.1.1 Segment Type Flags .................................. 10 67 3.1.2 Segment Type Codes .................................. 10 68 3.1.3 Segment Class Masks ................................. 11 69 3.1.4 Extensions Field .................................... 12 70 3.2 Segment Content .......................................... 13 71 3.2.1 Data Segment ........................................ 13 72 3.2.2 Report Segment ...................................... 14 73 3.2.3 Report Acknowledgment Segment ....................... 16 74 3.2.4 Session Management Segments ......................... 16 75 3.3 Segment Trailer .......................................... 17 76 4. Requests from Client Service ................................. 17 77 4.1 Transmission Request ..................................... 17 78 4.2 Cancellation Request ..................................... 18 79 5. Internal Procedures .......................................... 19 80 5.1 Start Transmission ....................................... 19 81 5.2 Start Checkpoint Timer ................................... 19 82 5.3 Start RS Timer ........................................... 20 83 5.4 Stop Transmission ........................................ 20 84 5.5 Suspend Timers ........................................... 20 85 5.6 Resume Timers ............................................ 21 86 5.7 Retransmit Checkpoint .................................... 21 87 5.8 Retransmit RS ............................................ 22 88 5.9 Signify Red-Part Reception ............................... 22 89 5.10 Signify Green-Part Segment Arrival ...................... 22 90 5.11 Send Reception Report ................................... 23 91 5.12 Signify Transmission Completion ......................... 24 92 5.13 Retransmit Data ......................................... 25 93 5.14 Stop RS Timer ........................................... 26 94 5.15 Start Cancel Timer ...................................... 26 95 5.16 Retransmit Cancellation Segment ......................... 26 96 5.17 Acknowledge Cancellation ................................ 26 97 5.18 Stop Cancel Timer ....................................... 27 98 5.19 Cancel Session .......................................... 27 99 5.20 Close Session ........................................... 27 100 5.21 Handle Miscolored Segment ............................... 27 101 6. Notices to Client Service .................................... 28 102 6.1 Session Start ............................................. 28 103 6.2 Green-Part Segment Arrival ................................ 28 104 6.3 Red-Part Reception ........................................ 29 105 6.4 Transmission Completion ................................... 29 106 6.5 Transmission Cancellation ................................. 29 107 6.6 Reception Cancellation .................................... 30 108 7. State Transition Diagrams ..................................... 30 109 7.1 Sender .................................................... 32 110 7.2 Receiver .................................................. 37 111 8. Requirements from the Operating Environment ................... 41 112 9. Security Considerations ....................................... 42 113 9.1 Security Mechanisms and Layering Considerations ........... 43 114 9.2 Denial of Service Considerations .......................... 44 115 9.3 Replay Handling ........................................... 45 116 9.4 Implementation Considerations ............................. 46 117 10. IANA Considerations .......................................... 46 118 11. Acknowledgments .............................................. 47 119 12. References ................................................... 47 120 12.1 Normative References ..................................... 47 121 12.2 Informative References ................................... 47 122 13. Author's Addresses ........................................... 48 123 14. Copyright Statement .......................................... 48 125 1. Introduction 127 This document serves as the main protocol specification of LTP, and 128 is part of a series of documents describing LTP. Other documents in 129 this series include the motivation document [LTPMOTIVE] and the 130 protocol extensions document [LTPEXT] respectively. We strongly 131 recommend reading the protocol motivation document before reading the 132 following document to establish sufficient background and motivation 133 for the contents that follow in this document. 135 2. Terminology 137 (1) Engine ID 139 A number that uniquely identifies a given LTP engine, within some 140 closed set of communicating LTP engines. Note that when LTP is 141 operating underneath the DTN Bundling protocol [BP][DTN], the 142 convergence layer adapter mediating between the two will be 143 responsible for translating between DTN endpoint IDs and LTP engine 144 IDs in an implementation-specific manner. 146 (2) Block 148 An array of contiguous octets of application data handed down by the 149 upper layer protocol (typically Bundling) to be transmitted via LTP 150 from one client service instance to another. 152 Any subset of a block comprising contiguous octets that begins at the 153 start of the block is termed a "block prefix" and any such subset of 154 the block that ends with the end of the block is termed a "block 155 suffix". 157 (3) Red-Part 159 The block prefix that is to be transmitted reliably, i.e., subject to 160 acknowledgement and retransmission. 162 (4) Green-Part 164 The block suffix that is to be transmitted unreliably, i.e., not 165 subject to acknowledgments or retransmissions. If present, the green- 166 part of a block begins at the octet following the end of the red- 167 part. 169 (5) Session 171 A thread of LTP protocol activity conducted for the purpose of 172 transmitting a block. 174 (6) Segment 176 The unit of LTP data transmission activity. It is the data structure 177 transmitted from one LTP engine to another in the course of a 178 session. An LTP segment is either a data segment, a report segment, 179 a report-acknowledgment segment, a cancel segment, or a cancel- 180 acknowledgment segment. 182 (7) Reception Claim 184 An assertion of reception of some number of contiguous octets of 185 application data (a subset of a block) characterized by the offset of 186 the first received octet and the number of contiguous octets 187 received. 189 (8) Scope 190 Scope identifies a subset of a block and comprises two numbers - 191 upper bound and lower bound. 193 For a data segment, lower bound is the offset of the segment's 194 application data from the start of the block (in octets), while upper 195 bound is the sum of the offset and length of the segment's 196 application data (in octets). For example, a segment with block 197 offset 1000 and length 500 would have a lower bound 1000 and upper 198 bound 1500. 200 For a report segment, upper bound is the end of the block prefix to 201 which the reception claims in the report apply, while lower bound is 202 the end of the (smaller) interior block prefix to which the reception 203 claims in the report do *not* apply. That is, data at any offset 204 equal to or greater than the report's lower bound but less than its 205 upper bound and not designated as "received" by any of the report's 206 reception claims must be assumed not received and therefore eligible 207 for retransmission. For example, if a report segment carried a lower 208 bound of 1000 and an upper bound of 5000, and the reception claims 209 indicated reception of data within offsets 1000-1999 and 3000-4999, 210 data within the block offsets 2000-2999 can be considered eligible 211 for retransmission. 213 Reception reports (which may comprise multiple report segments) also 214 have scope, as defined in Section 5.11. 216 (9) End of Block (EOB) 218 The last data segment transmitted as part of the original 219 transmission of a block. This data segment also indicates that the 220 segment's upper bound is the total length of the block (in octets). 222 (10) End of Red-Part (EORP) 224 That segment transmitted as part of the original transmission of a 225 block which contains the last octet of the block's red-part. This 226 data segment also indicates that the segment's upper bound is the 227 length of the block's red-part (in octets). 229 (11) Checkpoint 231 A data segment soliciting a reception report from the receiving LTP 232 engine. The EORP segment must be flagged as a checkpoint, as must 233 the last segment of any retransmission; these are "mandatory 234 checkpoints". All other checkpoints are "discretionary checkpoints". 236 (12) Reception Report 237 A sequence of one or more report segments reporting on all block data 238 reception within some scope. 240 (13) Synchronous Reception Report 242 A reception report that is issued in response to a checkpoint. 244 (14) Asynchronous Reception Report 246 A reception report that is issued in response to some implementation- 247 defined event other than the arrival of a checkpoint. 249 (15) Primary Reception Report 251 A reception report that is issued in response to some event other 252 than the arrival of a checkpoint segment that was itself issued in 253 response to a reception report. Primary reception reports include 254 all asynchronous reception reports and all synchronous reception 255 reports that are sent in response to discretionary checkpoints or to 256 the EORP segment for a session. 258 (16) Secondary Reception Report 260 A reception report that is issued in response to the arrival of a 261 checkpoint segment that was itself issued in response to a reception 262 report. 264 (17) Self-Delimiting Numeric Value (SDNV) 266 The design of LTP attempts to reconcile minimal consumption of 267 transmission bandwidth with 269 (a) extensibility to satisfy requirements not yet identified and 270 (b) scalability across a very wide range of network sizes and 271 transmission payload sizes. 273 A key strategic element in the design is the use of self-delimiting 274 numeric values (SDNVs) that are similar in design to the Abstract 275 Syntax Notation One [ASN1] encoding of data structures. SDNVs are of 276 two basic types, SDNV-8 and SDNV-16. An SDNV-8 can be used to encode 277 a variable length number from 1 to 128 octets in length; an SDNV-16 278 can be used to encode a variable length number from 2 to 128 octets 279 in length. The first octet of an SDNV - the "discriminant" - fully 280 characterizes the SDNV's value. 282 SDNV-8 284 If the most significant bit of the discriminant is zero, the 285 length of the SDNV-8 is 1 octet and the contents of the remaining 286 7 bits of the discriminant viewed as an unsigned integer is the 287 value of the SDNV. An integer in the range of 0 to 127 can be 288 encoded this way. 290 Otherwise (if the most significant bit of the discriminant is 1), 291 the remaining 7 bits encode the length of the SDNV's value. If the 292 content of the remaining 7 bits viewed as an unsigned integer has 293 the value N, the encoded number is N+1 octets long and has the 294 value found by concatenating octets 2 through N+2 of the SDNV-8, 295 viewed as an unsigned integer. For example, if N were 0, the 296 following single octet would contain the value of the SDNV-8; if N 297 were 127, the following 128 octets would contain the encoded 298 unsigned number. 300 SDNV-16 302 If the most significant bit of the discriminant is zero, then the 303 length of the SDNV-16 is 2 octets and the contents of the 304 remaining 7 bits of the discriminant concatenated with the 305 following octet, viewed as a 15-bit unsigned integer, is the value 306 encoded. An integer in the range of 0 to 32767 can be encoded this 307 way. 309 Otherwise (if the most significant bit of the discriminant is 1), 310 the encoding is similar to SDNV-8. If the content of the remaining 311 7 bits viewed as an unsigned integer has the value N, the encoded 312 number is N+1 octets long and has the value found by concatenating 313 octets 2 through N+2 of the SDNV-16, viewed as an unsigned 314 integer. 316 An SDNV can therefore be used to represent both very large and very 317 small integer values. For example, the maximum size of an SDNV - a 318 1024-bit number - is large enough to contain a fairly safe encryption 319 key, while any whole-degree Celsius temperature in the range in which 320 water is a liquid can be represented in a single-octet SDNV-8. 322 In the LTP header specification that follows, various fields in the 323 header are defined to be of types SDNV-8 or SDNV-16 depending on the 324 typical range of values expected for the field. If a field in the 325 header carries a number that typically requires 16 bits to encode, 326 but under certain infrequent conditions may grow longer and require, 327 say, 32 bits to encode, it might be optimal to specify it as an 328 SDNV-16 instead of specifying the field as a fixed 32 bit integer. 330 However, SDNV is clearly not the best way to represent every numeric 331 value. When the maximum possible value of a number is known without 332 question, the cost of an additional 8 bits of discriminant may not be 333 justified. For example, an SDNV-8 is a poor way to represent an 334 integer whose value typically falls in the range 128 to 255. 336 In general, though, we believe that SDNV representation of selected 337 numeric values in LTP segments yields the smallest segment sizes 338 without sacrificing scalability. 340 (18) Client Service Instance 342 A software entity, such as an application or a higher-layer protocol 343 implementation, that is using LTP to transfer data. 345 3. Segment Structure 347 Each LTP segment comprises 349 (a) a "header" in the format defined below. 351 (b) zero or more octets of "content". 353 (c) zero or more octets of "trailer" as indicated by information in 354 the "extensions field" of the header. 356 LTP segments are of four general types depending on the nature of the 357 content carried: 359 Data segments carry client service (application) data, together 360 with metadata enabling the receiving client service instance to 361 receive and make use of that data. 363 A report segment carries data reception claims together with the 364 upper and lower bounds of the data block scope to which the claims 365 pertain. 367 A report-acknowledgment segment carries only the serial number of 368 the report being acknowledged. 370 Session management segments are of two general subtypes: 371 Cancellation and Cancellation-acknowledgment. A Cancellation 372 segment carries a single byte reason-code to indicate the reason 373 for the cancellation. Cancellation-acknowledgment segments have no 374 content. 376 The overall segment structure is illustrated below : 378 Bit 0 1 2 3 4 5 6 7 379 ^ +-----+-----+-----+-----+-----+-----+-----+-----+ 380 | | Version number | Segment Type Flags | 381 | +-----------------------+-----------------------+ 382 | | | 383 | / Session ID \ 384 | \ / 385 Header +-----------------------+-----------------------+ 386 | | Header Extension Cnt. | Trailer Extension Cnt.| 387 | +-----------------------+-----------------------+ 388 | | | 389 | / Header Extensions \ 390 | \ / 391 V +-----------------------------------------------+ 392 | | 393 | | 394 | | 395 | Segment Content | 396 / \ 397 \ / 398 | | 399 | | 400 | | 401 ^ +-----------------------------------------------+ 402 | | | 403 Trailer / Trailer Extensions \ 404 | \ / 405 V +-----------------------------------------------+ 407 3.1 Segment Header 409 An LTP segment header comprises three data items: a single-octet 410 control byte, a session ID, and an extensions field. 412 Control byte comprises the following: 414 Version number (4 bits): MUST be set to the binary value 0000 for 415 this version of the protocol. 417 Segment type flags (4 bits): described below. 419 Session ID uniquely identifies, among all transmissions between the 420 segment's sender and receiver, the session of which the segment is 421 one token. It comprises the following: 423 Session originator: the engine ID of the LTP engine that initiated 424 the session, in SDNV-8 representation. 426 Session number: a number in SDNV-16 representation, typically a 427 random number (for anti-DoS reasons), generated by the LTP engine 428 identified as the session originator. 430 The format and resolution of session number are matters that are 431 private to the session-originating engine; the only requirement 432 imposed by LTP is that every session initiated by an LTP engine 433 MUST be uniquely identified by the session ID. 435 The extensions field is described in Section 3.1.4. 437 3.1.1 Segment Type Flags 439 The last four bits of the control byte in the segment header are 440 flags that indicate the nature of the segment. In order (most 441 significant bit first), these flags are CTRL, EXC, Flag 1 and Flag 0. 443 A value of 0 in the CTRL (Control) flag identifies the segment as a 444 data segment while a value of 1 identifies it as a control segment. A 445 data segment with the EXC (Exception) flag set to 0 is a red-part 446 segment; a data segment with EXC set to 1 is a green-part segment. 447 For a control segment, having the EXC flag set to 1 indicates that 448 the segment pertains to session cancellation activity. Any data 449 segment (whether red-part or green-part) with both Flag 1 and Flag 0 450 set to 1 indicates end of block. Any data segment (whether red-part 451 or green-part) with both Flag 1 and Flag 0 set to 0 indicates data 452 without any additional protocol significance. Any red-part data 453 segment with either Flag bit non-zero is a checkpoint. Any red-part 454 data segment with Flag 1 set to 1 indicates the end of the red-part 455 of the block. 457 3.1.2 Segment Type Codes 459 Combinations of the settings of the segment type flags CTRL, EXC, 460 Flag 1 and Flag 0 constitute segment type codes which serve as 461 concise representations of detailed segment nature. 463 CTRL EXC Flag 1 Flag 0 Code Nature of segment 464 ---- --- ------ ------ ---- ----------------------------------------- 465 0 0 0 0 0 Red data, NOT {Checkpoint or EORP or EOB} 466 0 0 0 1 1 Red data, Checkpoint, NOT {EORP or EOB} 467 0 0 1 0 2 Red data, Checkpoint, EORP, NOT EOB 468 0 0 1 1 3 Red data, Checkpoint, EORP, EOB 470 0 1 0 0 4 Green data, NOT EOB 471 0 1 0 1 5 Undefined 472 0 1 1 0 6 Undefined 473 0 1 1 1 7 Green data, EOB 474 1 0 0 0 8 Report segment 475 1 0 0 1 9 Report-acknowledgment segment 476 1 0 1 0 10 Undefined 477 1 0 1 1 11 Undefined 479 1 1 0 0 12 Cancel segment from block sender 480 1 1 0 1 13 Cancel-acknowledgment segment 481 to block sender 483 1 1 1 0 14 Cancel segment from block receiver 484 1 1 1 1 15 Cancel-acknowledgment segment 485 to block receiver 487 3.1.3 Segment Class Masks 489 For the purposes of this specification, some bit patterns in the 490 segment type flags field correspond to "segment classes" that are 491 designated by mnemonics. The mnemonics are intended to evoke the 492 characteristics shared by all types of segments characterized by 493 these flag bit patterns. 495 CTRL EXC Flag 1 Flag 0 Mnemonic Description 496 ---- --- ------ ------ -------- --------------------------- 497 0 0 - 1 498 -- or -- 499 0 0 1 - CP Checkpoint 501 0 0 1 - EORP End of red-part; 502 red-part size = offset + length 504 0 - 1 1 EOB End of block; 505 block size = offset + length 507 1 0 0 0 RS Report segment; 508 carries reception claims 510 1 0 0 1 RA Report-acknowledgment segment 512 1 1 0 0 CS Cancel segment from block sender 514 1 1 0 1 CAS Cancel-acknowledgment segment 515 to block sender 517 1 1 1 0 CR Cancel segment from block receiver 519 1 1 1 1 CAR Cancel-acknowledgment segment 520 to block receiver 522 1 1 - 0 Cx Cancel segment (generic) 524 1 1 - 1 CAx Cancel-acknowledgment segment 525 (generic) 527 3.1.4 Extensions field 529 The extension field enables the inclusion of zero or more functional 530 extensions to the basic LTP segment, each in type-length-value (TLV) 531 representation as explained below. 533 The first octet of the extensions field indicates the number of 534 extensions present in the segment: the high-order 4 bits indicate the 535 number of extension TLVs in the header (immediately following the 536 extensions count octet and preceding the segment's content) while the 537 low-order 4 bits indicate the number of extension TLVs in the trailer 538 (immediately following the segment's content). That is, each segment 539 may have from 0 to 15 extension TLVs in its header and from 0 to 15 540 extension TLVs in its trailer. In the absence of any extension TLVs, 541 all bits of this extensions count octet MUST be set to zero. 543 Each extension consists of a one-octet tag identifying the type of 544 extension (the "T" of the extension TLV), followed by an extension 545 specification in SDNV-8 format. [Since an SDNV-8 comprises both a 546 numeric data value and the length of that value, the extension 547 specification serves to supply both the "L" and the "V" of the 548 extension TLV.] 550 The diagram below illustrates the extension TLVs as they may occur in 551 the header or trailer. 553 +--------+---------------///-+ 554 |ext-tag | SDNV-8 spec | 555 +--------+-------------------////-+ 556 |ext-tag | SDNV-8 spec | 557 +--------+-------------------////-+ 558 |ext-tag | SDNV-8 spec | 559 +--------+------------////-+-+ 560 |ext-tag | SDNV-8 spec | 561 +--------+--------------////-+ 563 One extension type is defined at this time. 565 Extension tag Meaning 566 ------------- ------- 567 0x00 LTP authentication extension [LTPEXT] 568 0x01 LTP cookie estension [LTPEXT] 569 0x02-0xff Reserved 571 3.2 Segment Content 573 3.2.1 Data Segment (DS) 575 The content of a data segment includes client service data and 576 metadata enabling the receiving client service instance to receive 577 and make use of that data. 579 Client service ID [SDNV-8] 581 The client service ID number identifies the upper-level service to 582 which the segment is to be delivered by the destination LTP 583 engine. It is functionally analogous to a well-known TCP port 584 number. If multiple instances of the client service are present 585 at the destination, multiplexing must be done by the client 586 service itself on the basis of information encoded within the 587 transmitted block. 589 Offset [SDNV-16] 591 Offset indicates the location of the segment's client service data 592 within the session's transmitted block. It is the number of bytes 593 in the block prior to the byte from which the first octet of the 594 segment's client service data was copied. 596 Length [SDNV-16] 598 The length of the ensuing client service data, in octets. 600 If the data segment is a checkpoint, the segment MUST additionally 601 include the following two serial numbers (Checkpoint serial number 602 and Report serial number) to support efficient retransmission. Data 603 segments that are not checkpoints MUST NOT have these two fields in 604 the header and MUST continue on directly with the client service 605 data. 607 Checkpoint serial number [SDNV-8] 609 The checkpoint serial number uniquely identifies the checkpoint 610 among all checkpoints issued by the block sender in a session. 611 The first checkpoint issued by the sender MUST have this serial 612 number chosen randomly for security reasons, and it is RECOMMENDED 613 that the sender use the guidelines in [ECS94] for this. Any 614 subsequent checkpoints issued by the sender MUST have the serial 615 number value found by incrementing the prior checkpoint serial 616 number by 1. When a checkpoint segment is retransmitted, however, 617 its serial number MUST be the same as when it was originally 618 transmitted. 620 Report serial number [SDNV-8] 622 If the checkpoint was queued for transmission in response to the 623 reception of an RS [Sec 5.13], then its value MUST be the report 624 serial number value of the RS that caused the data segment to be 625 queued for transmission. 627 Otherwise, the value of report serial number MUST be zero. 629 Client service data [array of octets] 631 The client service data carried in the segment is a copy of a 632 subset of the bytes in the original client service data block, 633 starting at the indicated offset. 635 3.2.2 Report Segment (RS) 637 The content of an RS comprises one or more data reception claims, 638 together with the upper and lower bounds of the scope within the data 639 block to which the claims pertain. It also includes two serial 640 numbers to support efficient retransmission. 642 Report serial number [SDNV-8] 644 The report serial number uniquely identifies the report among all 645 reports issued by the block receiver in a session. The first 646 report issued by the receiver MUST have this serial number chosen 647 randomly for security reasons, and it is RECOMMENDED that the 648 receiver use the guidelines in [ECS94] for this. Any subsequent RS 649 issued by the receiver MUST have the serial number value found by 650 incrementing the last report serial number by 1. When an RS is 651 retransmitted however, its serial number MUST be the same as when 652 it was originally transmitted. 654 Checkpoint serial number [SDNV-8] 656 The value of checkpoint serial number MUST be zero if the report 657 segment is NOT a response to reception of a checkpoint, i.e., the 658 reception report is asynchronous; otherwise it is the checkpoint 659 serial number of the checkpoint that caused the RS to be issued. 661 Upper bound [SDNV-16] 663 The upper bound of a report segment is the size of the block 664 prefix to which the segment's reception claims pertain. 666 Lower bound [SDNV-16] 668 The lower bound of a report segment is the size of the (interior) 669 block prefix to which the segment's reception claims do NOT 670 pertain. 672 Reception claim count [SDNV-8] 674 The number of data reception claims in this report segment. 676 Reception claims 678 Each reception claim comprises two elements: offset and length. 680 Offset [SDNV-16] 682 The offset indicates the successful reception of data beginning 683 at the indicated offset from the lower bound of the RS. The 684 offset within the entire block can be calculated by summing 685 this offset with the lower bound of the RS. 687 Length [SDNV-16] 689 The length of a reception claim indicates the number of 690 contiguous octets of block data starting at the indicated 691 offset (within the scope of the report) that have been 692 successfully received so far. 694 Reception claims MUST conform to the following rules: 696 A reception claim's length shall never be less than 1 and shall 697 never exceed the difference between the upper and lower bounds 698 of the report segment. 700 The offset of a reception claim shall always be greater than 701 the sum of the offset and length of the prior claim, if any. 703 The sum of a reception claim's offset and length and the lower 704 bound of the report segment shall never exceed the upper bound 705 of the report segment. 707 Implied requests for retransmission of client service data can be 708 inferred from an RS's data reception claims. However, *nothing* can 709 be inferred regarding reception of block data at any offset equal to 710 or greater than the segment's upper bound or at any offset less than 711 the segment's lower bound. 713 For example, if the scope of a report segment has lower bound 0 and 714 upper bound 6000, and the report contains a single data reception 715 claim with offset 0 and length 6000, then the report signifies 716 successful reception of the first 6000 bytes of the block. If the 717 total length of the block is 6000, then the report additionally 718 signifies successful reception of the entire block. 720 If on the other hand, the scope of a report segment has lower bound 721 1000 and upper bound 6000, and the report contains two data reception 722 claims, one with offset 0 and length 2000 and the other with offset 723 3000 and length 500, then the report signifies successful reception 724 only of bytes 1000-2999 and 4000-4499 of the block. From this we 725 can infer that bytes 3000-3999 and 4500-5999 of the block need to be 726 retransmitted, but we cannot infer anything about reception of the 727 first 1000 bytes. 729 3.2.3 Report Acknowledgment Segment 731 The content of an RA is simply the report serial number of the RS in 732 response to which the segment was generated. 734 Report serial number [SDNV-8] 736 This field returns the report serial number of the RS being 737 acknowledged. 739 3.2.4 Session Management Segments 741 Note: the reason we use different cancel segment types for the 742 originator and recipient is to allow a loopback mode to work without 743 disturbing any replay protection mechanism in use. 745 Cancel segments (Cx) carry a single byte reason-code with the 746 following semantics : 748 Reason-Code Mnemonic Semantics 749 ----------- -------- --------------------------------------- 750 00 CNCLD Client Service canceled session. 752 01 UNREACH Unreachable Client Service. 754 02 RLEXC Retransmission limit exceeded. 756 03 MISCOLORED Received either a red-part data segment 757 at block offset above any green-part 758 data segment offset or a green-part 759 data segment at block offset below any 760 red-part data segment offset. 762 04-FF Undefined 764 The Cancel-acknowledgments (CAx) have no content. 766 3.3 Segment Trailer 768 The segment trailer consists of a sequence of from zero to 15 769 extension TLVs as described in Section 3.1.4 above. 771 4. Requests from Client Service 773 In all cases the representation of request parameters is a local 774 implementation matter, as are validation of parameter values and 775 notification of the client service in the event that a request is 776 found to be invalid. 778 4.1 Transmission Request 780 In order to request transmission of a block of client service data, 781 the client service MUST provide the following parameters to LTP: 783 Client service ID 785 Destination LTP engine ID 787 Client service data to send, as an array of bytes. 789 Length of the data to be sent. This value MUST NOT exceed the 790 largest numeric value that can be represented in an SDNV-8. 792 Length of the red-part of the data. This value MUST be in the 793 range from zero to the total length of data to be sent. 795 On reception of a valid transmission request from a client service, 796 LTP proceeds as follows. 798 First the array of data to be sent is subdivided as necessary, with 799 each subdivision serving as the client service data of a single new 800 LTP data segment. The algorithm used for subdividing the data is a 801 local implementation matter; it is expected that data size 802 constraints imposed by the underlying communication service, if any, 803 will be accommodated in this algorithm. 805 The last (and only the last) of the resulting data segments must be 806 marked as the EOB. 808 Note that segment type indicates that the client service data in a 809 given LTP segment either is or is not in the red-part of the block. 811 To prevent segment type ambiguity, each data segment MUST contain 812 either only red-part data or only green-part data. Note that this 813 implies that, when the length of the block's red-part is N and the 814 total length of the block M, and N is not equal to M, the (N+1)st 815 byte of the block MUST be the first byte of client service data in 816 some green-part data segment. 818 If the length of the block's red-part is greater than zero, then the 819 last data segment containing red-part data must be marked as the EORP 820 segment by setting the appropriate segment type flag bits [Sec 821 3.1.2]. Zero or more preceding data segments containing red-part data 822 (selected according to an algorithm that is a local implementation 823 matter) MAY additionally be marked to serve as additional 824 discretionary checkpoints [Sec 3.1.2]. 826 All data segments are appended to the (conceptual) application data 827 queue for transmission. 829 Finally, a session start notice [Sec 6.1] is sent back to the client 830 service that requested the transmission. 832 4.2 Cancellation Request 834 In order to request cancellation of a session, either as sender or as 835 receiver of the associated data block, the client service must 836 provide to LTP the session ID of the session to be canceled. 838 On reception of a valid cancellation request from a client service, 839 LTP proceeds as follows. 841 First the internal "Cancel session" procedure [Sec 5.19] is invoked. 843 Next, if the session is being canceled by the block sender (i.e., the 844 session originator part of the session ID supplied in the 845 cancellation request is the local LTP engine ID): 847 If none of the data segments previously queued for transmission as 848 part of this session have yet been de-queued and radiated - i.e., 849 if the destination engine cannot possibly be aware of this session 850 - then the session is simply closed; the "Close session" procedure 851 [Sec 5.20] is invoked. 853 Otherwise, a CS with reason-code CNCLD MUST be queued for 854 transmission to the destination LTP engine specified in the 855 transmission request that started this session. 857 Otherwise (i.e., the session is being canceled by the block 858 receiver): 860 If there is no transmission queue-set bound for the block sender 861 (possibly because the local LTP engine is running on a receive- 862 only device), then the session is simply closed; the "Close 863 session" procedure [Sec 5.20] is invoked. 865 Otherwise, a CR with reason-code CNCLD MUST be queued for 866 transmission to the block sender. 868 5. Internal Procedures 870 This section describes the internal procedures that are triggered by 871 the occurrence of various events during the life-time of the LTP 872 session. 874 Whenever the content of any of the fields of the header of any 875 received LTP segment does not conform to this specification document, 876 the segment is assumed to be corrupt and MUST be discarded 877 immediately and processed no further. This procedure supersedes all 878 other procedures described below. 880 All internal procedures described below that are triggered by the 881 arrival of a data segment are superseded by the following procedure 882 in the event that the client service identified by the data segment 883 does not exist at the local LTP engine: 885 If there is no transmission queue-set bound for the block sender 886 (possibly because the local LTP engine is running on a receive- 887 only device), then the received data segment is simply discarded. 889 Otherwise, if the data segment contains data from the red-part of 890 the block, a CR with reason-code UNREACH MUST be enqueued for 891 transmission to the block sender. A CR with reason-code UNREACH 892 SHOULD be similarly enqueued for transmission to the data sender 893 even if the data segment contained data from the green-part of the 894 block; note however that (for example) in the case where the block 895 receiver knows that the sender of this green-part data is 896 functioning in a "beacon" (transmit-only) fashion, a CR need not 897 be sent. In either case the received data segment is discarded. 899 5.1 Start Transmission 901 This procedure is triggered by arrival of a link state cue indicating 902 the start of transmission to a specified remote LTP engine. 904 Response: the de-queuing and delivery of segments to the LTP engine 905 specified in the link state cue begins. 907 5.2 Start Checkpoint Timer 908 This procedure is triggered by arrival of a link state cue indicating 909 the de-queuing (for transmission) of a CP segment. 911 Response: the expected arrival time of the RS that will be produced 912 on reception of this CP segment is computed, and a countdown timer 913 for this arrival time is started. However, if it is known that the 914 remote LTP engine has ceased transmission [Sec 5.5], then this timer 915 is immediately suspended, because the computed expected arrival time 916 may require an adjustment that cannot yet be computed. 918 5.3 Start RS Timer 920 This procedure is triggered by arrival of a link state cue indicating 921 the de-queuing (for transmission) of an RS. 923 Response: the expected arrival time of the RA that will be produced 924 on reception of this RS is computed, and a countdown timer for this 925 arrival time is started. However, if it is known that the remote LTP 926 engine has ceased transmission [Sec 5.5], then this timer is 927 immediately suspended, because the computed expected arrival time may 928 require an adjustment that cannot yet be computed. 930 5.4 Stop Transmission 932 This procedure is triggered by arrival of a link state cue indicating 933 the cessation of transmission to a specified remote LTP engine. 935 Response: the de-queuing and delivery to the underlying communication 936 system of segments from traffic queues bound for the LTP engine 937 specified in the link state cue ceases. 939 5.5 Suspend Timers 941 This procedure is triggered by arrival of a link state cue indicating 942 the cessation of transmission from a specified remote LTP engine to 943 the local LTP engine. Normally, this event is inferred from advance 944 knowledge of the remote engine's planned transmission schedule. 946 Response: countdown timers for the acknowledging segments that the 947 remote engine is expected to return are suspended as necessary based 948 on the following procedure. 950 The nominal acknowledge transmission time is computed as the sum of 951 the transmission time of the original segment (to which the 952 acknowledging segment will respond) and the one-way light time to the 953 remote engine, plus N seconds of "additional anticipated latency" 954 (AAL) encompassing anticipated transmission delays other than signal 955 propagation time. N is determined in an implementation-specific 956 manner. For example, when LTP is deployed in deep space vehicles, 957 the one-way light time to the remote engine may be very large while N 958 normally need only reflect processing and queuing delay margin; it 959 can be a network management parameter, for which 2 seconds seems to 960 be a reasonable default value. As another example, when LTP is 961 deployed in a terrestrial "data mule" environment, one-way light time 962 latency is effectively zero while N may need to be some dynamically 963 computed function of the data mule circulation schedule. 965 If the nominal acknowledge transmission time is greater than or equal 966 to the current time (i.e., the acknowledging segment may be presented 967 for transmission during the time that transmission at the remote 968 engine is suspended), then the countdown timer for this acknowledging 969 segment is suspended. 971 5.6 Resume Timers 973 This procedure is triggered by arrival of a link state cue indicating 974 the start of transmission from a specified remote LTP engine to the 975 local LTP engine. Normally, this event is inferred from advance 976 knowledge of the remote engine's planned transmission schedule. 978 Response: expected arrival time is adjusted for every acknowledging 979 segment that the remote engine is expected to return, for which the 980 countdown timer has been suspended. In each case, expected arrival 981 time is increased by a transmission delay interval that is calculated 982 as follows: 984 The nominal acknowledge transmission time is computed as the sum 985 of the transmission time of the original segment (to which the 986 acknowledging segment will respond) and the one-way light time to 987 the remote engine, plus N seconds of AAL [Sec 5.5]. 989 If the nominal acknowledge transmission time is greater than the 990 current time i.e., the remote engine resumed transmission prior to 991 presentation of the acknowledging segment for transmission, then 992 the transmission delay interval is zero. 994 Otherwise, the transmission delay interval is computed as the 995 current time less the nominal acknowledge transmission time. 997 After adjustment of expected arrival time, each of the suspended 998 countdown timers is resumed. 1000 5.7 Retransmit Checkpoint 1002 This procedure is triggered by the expiration of a countdown timer 1003 associated with a CP segment. 1005 Response: if the number of times this CP segment has been queued for 1006 transmission exceeds the checkpoint retransmission limit established 1007 for the local LTP engine by network management, then the session of 1008 which the segment is one token is canceled: the "Cancel session" 1009 procedure [Sec 5.19] is invoked, a CS with reason-code RLEXC is 1010 appended to the (conceptual) application data queue, and a 1011 transmission cancellation notice [Sec 6.5] is sent back to the client 1012 service that requested the transmission. 1014 Otherwise, a new copy of the CP segment is appended to the 1015 (conceptual) application data queue. 1017 5.8 Retransmit RS 1019 This procedure is triggered by either (a) expiration of a countdown 1020 timer associated with an RS or (b) reception of a CP segment whose 1021 checkpoint serial number is equal to that of one or more previously 1022 issued RSs for the same session -- an unnecessarily retransmitted 1023 checkpoint. 1025 Response: if the number of times any affected RS has been queued for 1026 transmission exceeds the report retransmission limit established for 1027 the local LTP engine by network management, then the session of which 1028 the segment is one token is canceled: the "Cancel session" procedure 1029 [Sec 5.19] is invoked, a CR with reason-code RLEXC is queued for 1030 transmission to the LTP engine that originated the session, and a 1031 reception cancellation notice [Sec 6.6] is sent to the client service 1032 identified in each of the data segments received in this session. 1034 Otherwise, a new copy of each affected RS is queued for transmission 1035 to the LTP engine that originated the session. 1037 5.9 Signify Red-Part Reception 1039 This procedure is triggered by the arrival of a CP segment when the 1040 EORP for this session has been received (ensuring that the size of 1041 the data block's red-part is known; this includes the case where the 1042 CP segment itself is the EORP segment) and all data in the red-part 1043 of the block being transmitted in this session have been received. 1045 Response: a red-part reception notice [Sec 6.3] is sent to the 1046 specified client service. 1048 5.10 Signify Green-Part Segment Arrival 1050 This procedure is triggered by the arrival of a data segment whose 1051 content is a portion of the green-part of a block. 1053 Response: a green-part segment arrival notice [Sec 6.2] is sent to 1054 the specified client service. 1056 5.11 Send Reception Report 1058 This procedure is triggered by either (a) reception of a CP segment 1059 whose checkpoint serial number is not equal to that of any previously 1060 issued RS or (b) an implementation-specific circumstance pertaining 1061 to a particular block reception session for which no EORP has yet 1062 been received ("asynchronous" reception reporting). 1064 Response: if the number of reception problems detected for this 1065 session exceeds a limit established for the local LTP engine by 1066 network management, then the affected session is canceled: the 1067 "Cancel session" procedure [Sec 5.19] is invoked, a CR with reason- 1068 code RLEXC is issued and is, in concept, appended to the queue of 1069 internal operations traffic bound for the LTP engine that originated 1070 the session, and a reception cancellation notice [Sec 6.6] is sent to 1071 the client service identified in each of the data segments received 1072 in this session. One possible limit on reception problems would be 1073 the maximum number of reception reports which can be issued for any 1074 single session. 1076 If such limit is not reached, a reception report is issued as 1077 follows. 1079 If production of the reception report was triggered by reception of a 1080 checkpoint: 1082 The upper bound of the report SHOULD be the upper bound (the sum 1083 of the offset and length) of the checkpoint data segment, to 1084 minimize unnecessary retransmission. Note: For deployments where 1085 bandwidth economy is not critical, the upper bound of a 1086 synchronous reception report MAY be the maximum upper bound value 1087 among all red-part data segments received so far in the affected 1088 session. 1090 If the checkpoint was itself issued in response to a report 1091 segment, then this report is a "secondary" reception report. In 1092 that case the lower bound of the report SHOULD be the lower bound 1093 of the report segment to which the triggering checkpoint was 1094 itself a response, to minimize unnecessary retransmission. Note: 1095 For deployments where bandwidth economy is not critical, the lower 1096 bound of the report MAY instead be zero. 1098 If the checkpoint was not issued in response to a report segment, 1099 this report is a "primary" reception report. The lower bound of 1100 the first primary reception report issued for any session MUST be 1101 zero. The lower bound of each subsequent primary reception report 1102 issued for the same session SHOULD be the upper bound of the prior 1103 primary reception report issued for the session, to minimize 1104 unnecessary retransmission. Note: For deployments where bandwidth 1105 economy is not critical, the lower bound of every primary 1106 reception report MAY be zero. 1108 If production of the reception report is "asynchronous" as noted 1109 above: 1111 The upper bound of the report MUST be the maximum upper bound 1112 among all red-part data segments received so far for this session. 1114 The lower bound of the first asynchronous reception report issued 1115 for any session for which no other primary reception reports have 1116 yet been issued MUST be zero. The lower bound of each subsequent 1117 asynchronous reception report SHOULD be the upper bound of the 1118 prior primary reception report issued for the session, to minimize 1119 unnecessary retransmission. Note: For deployments where bandwidth 1120 economy is not critical, the lower bound of every asynchronous 1121 reception report MAY be zero. 1123 In all cases, if the applicable lower bound of the scope of a report 1124 is determined to be greater than or equal to the applicable upper 1125 bound (e.g., due to out-of-order arrival of discretionary 1126 checkpoints) then the reception report MUST NOT be issued. Otherwise: 1128 As many RSs must be produced as are needed in order to report on all 1129 data reception within the scope of the report, given whatever data 1130 size constraints are imposed by the underlying communication service. 1131 The RSs are, in concept, appended to the queue of internal operations 1132 traffic bound for the LTP engine that originated the indicated 1133 session. The lower bound of the first RS of the report MUST be the 1134 reception report's lower bound. The upper bound of the last RS of 1135 the report MUST be the reception report's upper bound. 1137 5.12 Signify Transmission Completion 1139 This procedure is triggered at the earliest time at which (a) all 1140 data in the block are known to have been transmitted *and* (b) the 1141 entire red-part of the block - if of non-zero length - is known to 1142 have been successfully received. Condition (a) is signaled by 1143 arrival of a link state cue indicating the de-queuing (for 1144 transmission) of the EOB segment for the block. Condition (b) is 1145 signaled by reception of an RS whose reception claims, taken together 1146 with the reception claims of all other RSs previously received in the 1147 course of this session, indicate complete reception of the red-part 1148 of the block. 1150 Response: a transmission completion notice [Sec 6.4] is sent to the 1151 client service that requested the transmission identified in the 1152 segment header and the session is closed: the "Close session" 1153 procedure [Sec 5.20] is invoked. 1155 5.13 Retransmit Data 1157 This procedure is triggered by reception of an RS. 1159 Response: first, an RA with the same report serial number as the RS 1160 is issued and is, in concept, appended to the queue of internal 1161 operations traffic bound for the LTP engine that originated the 1162 indicated session. If the RS is redundant -- i.e., either the 1163 indicated session is unknown (for example, the RS is received after 1164 the session has been completed or canceled), or the RS's report 1165 serial number is equal to that of a previously received report 1166 segment for this session -- then no further action is taken. 1167 Otherwise the procedure below is followed. 1169 If the report's checkpoint serial number is not zero, then the 1170 countdown timer associated with the indicated checkpoint segment is 1171 deleted. 1173 Note: All retransmission buffer space occupied by data whose 1174 reception is claimed in the report segment can be released. 1176 If the segment's reception claims indicate incomplete data reception 1177 within the scope of the report segment: 1179 If the number of transmission problems for this session exceeds a 1180 limit established for the local LTP engine by network management, 1181 then the session of which the segment is one token is canceled: 1182 the "Cancel session" procedure [Sec 5.19] is invoked, a CS with 1183 reason-code RLEXC is appended to the transmission queue specified 1184 in the transmission request that started this session, and a 1185 transmission cancellation notice [Sec 6.5] is sent back to the 1186 client service that requested the transmission. One possible 1187 limit on transmission problems would be the maximum number of 1188 retransmission CP segments which may be issued for any single 1189 session. 1191 If the number of transmission problems for this session has not 1192 exceeded any limit, new data segments encapsulating all block data 1193 whose non-reception is implied by the reception claims are 1194 appended to the transmission queue specified in the transmission 1195 request that started this session. The last - and only the last - 1196 such segment must be marked as a CP segment and must contain the 1197 report serial number of the received RS. 1199 5.14 Stop RS Timer 1201 This procedure is triggered by reception of an RA. 1203 Response: the countdown timer associated with the original RS 1204 (identified by the report serial number of the RA segment) is 1205 deleted. If no other countdown timers associated with RSs exist 1206 for this session, then the session is closed: the "Close session" 1207 procedure [Sec 5.20] is invoked. 1209 5.15 Start Cancel Timer 1211 This procedure is triggered by arrival of a link state cue 1212 indicating the de-queuing (for transmission) of a Cx. 1214 Response: the expected arrival time of the CAx that will be 1215 produced on reception of this Cx is computed and a countdown timer 1216 for this arrival time is started. However, if it is known that 1217 the remote LTP engine has ceased transmission [Sec 5.5] then this 1218 timer is immediately suspended, because the computed expected 1219 arrival time may require an adjustment that cannot yet be 1220 computed. 1222 5.16 Retransmit Cancellation Segment 1224 This procedure is triggered by the expiration of a countdown timer 1225 associated with a Cx. 1227 Response: if the number of times this Cx has been queued for 1228 transmission exceeds the cancellation retransmission limit 1229 established for the local LTP engine by network management, then 1230 the session of which the segment is one token is simply closed: 1231 the "Close session" procedure [Sec 5.20] is invoked. 1233 Otherwise, a copy of the cancellation segment (retaining the same 1234 reason-code) is queued for transmission to the appropriate LTP 1235 engine. 1237 5.17 Acknowledge Cancellation 1239 This procedure is triggered by the reception of a Cx. 1241 Response: in the case of a CS where there is no transmission 1242 queue-set bound for the engine that originated the segment's 1243 session (possibly because the local LTP engine is running on a 1244 receive-only device), then no action is taken. Otherwise: 1246 If the received segment is a CS, a CAS is issued and is, in 1247 concept, appended to the queue of internal operations traffic 1248 bound for the LTP engine that sent the CS. 1250 If the received segment is a CR, a CAR is issued and is, in 1251 concept appended to the queue of internal operations traffic 1252 bound for the LTP engine that sent the CR. 1254 It is possible that the Cx has been retransmitted because a 1255 previous responding acknowledgment CAx was lost, in which case 1256 there will no longer be any record of the session of which the 1257 segment is one token. If so, no further action is taken. 1259 Otherwise: the "Cancel session" procedure [Sec 5.19] is invoked 1260 and a reception cancellation notice [Sec 6.6] is sent to the 1261 client service identified in each of the data segments received in 1262 this session. Finally, the session is closed: the "Close session" 1263 procedure [Sec 5.20] is invoked. 1265 5.18 Stop Cancel Timer 1267 This procedure is triggered by reception of a CAx. 1269 Response: the session of which the segment is one token is closed, 1270 i.e., the "Close session" procedure [Sec 5.20] is invoked. 1272 5.19 Cancel Session 1274 This procedure is triggered internally by one of the other 1275 procedures described above. 1277 Response: all segments of the affected session that are currently 1278 queued for transmission can be deleted from the outbound traffic 1279 queues. All countdown timers currently associated with the 1280 session are deleted. Note: If the local LTP engine is the 1281 originator of the session, then all remaining data retransmission 1282 buffer space allocated to the session can be released. 1284 5.20 Close Session 1286 This procedure is triggered internally by one of the other 1287 procedures described above. 1289 Response: any remaining countdown timers associated with the 1290 session (such as the timer associated with a Cx) are deleted. The 1291 session state record (SSR|RSR) for the session is deleted; 1292 existence of the session is no longer recognized. 1294 5.21 Handle Miscolored Segment 1295 This procedure is triggered by the arrival of either (a) a red- 1296 part data segment whose block offset begins at an offset higher 1297 than the offset of any green-part data segment previously received 1298 for the same session or (b) a green-part data segment whose block 1299 offset begins at an offset lower than the offset of any red-part 1300 data segment previously received for the same session. 1302 Response: the received data segment is simply discarded. 1304 The Cancel Session procedure [Sec 5.19] is invoked and a CR with 1305 reason-code MISCOLORED SHOULD be enqueued for transmission to the 1306 data sender. Note : If there is no transmission queue-set bound 1307 for the block sender (possibly because the local LTP engine is 1308 running on a receive-only device), or if the block receiver knows 1309 that the sender of this green-part data is functioning in a 1310 "beacon" (transmit-only) fashion, a CR need not be sent. A 1311 Reception Cancellation Notice [Sec 6.6] is sent to the client 1312 service. 1314 6. Notices to Client Service 1316 In all cases the representation of notice parameters is a local 1317 implementation matter. 1319 6.1 Session Start 1321 The LTP engine returns the session ID of the new transmission 1322 session when a session start notice is delivered. 1324 A session start notice informs the client service of the 1325 initiation of a transmission session in response to a transmission 1326 request from that client service. On receiving this notice the 1327 client service may, for example, release resources of its own that 1328 are allocated to the block being transmitted, or remember the 1329 session ID so that the session can be canceled in the future if 1330 necessary. 1332 6.2 Green-Part Segment Arrival 1334 The following parameters are provided by the LTP engine when a 1335 green-part segment arrival notice is delivered: 1337 Session ID of the transmission session. 1339 Array of client service data bytes contained in the data 1340 segment. 1342 Offset of the data segment's content from the start of the 1343 block. 1345 Length of the data segment's content. 1347 Indication as to whether or not the last byte of this data 1348 segment's content is also the end of the block. 1350 Source LTP engine ID. 1352 6.3 Red-Part Reception 1354 The following parameters are provided by the LTP engine when a 1355 red-part reception notice is delivered: 1357 Session ID of the transmission session. 1359 Array of client service data bytes that constitute the red-part 1360 of the block. 1362 Length of the red-part of the block. 1364 Indication as to whether or not the last byte of the red-part 1365 is also the end of the block. 1367 Source LTP engine ID. 1369 6.4 Transmission Completion 1371 The sole parameter provided by the LTP engine when a transmission 1372 completion notice is delivered is the session ID of the 1373 transmission session. 1375 A transmission completion notice informs the client service that 1376 all bytes of the indicated data block have been transmitted and 1377 the destination LTP engine has received the red-part of the block. 1379 6.5 Transmission Cancellation 1381 The parameters provided by the LTP engine when a transmission 1382 cancellation notice is delivered are: 1384 Session ID of the transmission session. 1386 The reason-code sent or received in the Cx segment that 1387 initiated the cancellation sequence. 1389 A transmission cancellation notice informs the client service that 1390 the indicated session was terminated, either by decision of the 1391 destination client service instance or due to violation of a 1392 retransmission limit in the local LTP engine. There is no 1393 assurance that the destination client service instance received 1394 the critical part of the data block. 1396 6.6 Reception Cancellation 1398 The parameters provided by the LTP engine when a reception 1399 cancellation notice is delivered are: 1401 Session ID of the transmission session. 1403 The reason-code explaining the cancellation. 1405 A reception cancellation notice informs the client service that 1406 the indicated session was terminated, either by decision of the 1407 source client service instance or due to error conditions at the 1408 local LTP engine. No subsequent delivery notices will be issued 1409 for this session. 1411 7. State Transition Diagrams 1413 The following mnemonics have been used in the sender and 1414 receiver LTP state transition diagrams that follow : 1416 TE Timer Expiry 1417 RDS Regular Red Data Segment (NOT {CP|EORP|EOB}) 1418 GDS Regular Green Data Segment (NOT EOB) 1419 RL EXC Retransmission Limit Exceeded 1421 Both the diagrams have been specified in two parts such that 1422 sequence of state transitions that occur multiple times in the 1423 main diagram have been presented in the second part. Note that 1424 blocks represented in rectangles as in 1426 +---------+ 1427 | FG_XMIT | 1428 +---------+ 1430 specify actual states in the state-transition diagrams, while 1431 blocks represented as in 1433 /\/\/\/\ 1434 | Cncld | 1435 \/\/\/\/ 1437 are not actual states but merely pointers to a state or a sequence 1438 of state transitions represented elsewhere in the state transition 1439 diagram (to avoid having multiple copies of a sequence of state 1440 transitions, thus accomodating space constraints). 1442 7.1 Sender 1443 LTP Sender State Transition Diagram 1445 /\/\/\/\ 1446 | Cncld | 1447 \/\/\/\/ 1448 +--------+ | +------+ 1449 Rcv CR; | V V V | Rcv RS; 1450 Snd CAR | +-------------+ | Snd RA 1451 +-------+ CLOSED +----+ 1452 +---------------------------->+------+------+ 1453 | | Blk. Trans. Req 1454 | Zero RP + 1455 | Xmit ________________________/ \ Non-Zero RP 1456 | GDS; / \ 1457 | +---+ | +------------------+ | +------+ 1458 | | V V | /\/\ Rcv RS V V V | 1459 | | +---------+ +<-| RX |<---+ +---------+ | 1460 | +<-+ FG_XMIT | | \/\/ +---+ +--->+ Xmit RDS; 1461 | +----+----+ | | RP_XMIT | | 1462 | | | /\/\ +---+ +--->+ Xmit {RDS, CP}; 1463 +<--------+ +<-| CP |<---+ +-----+---+ Start CP Tmr 1464 | Xmit \/\/ CP TE | \ 1465 | {GDS, EOB}; | | 1466 | Xmit {RDS, CP, EORP}; | +-------+ 1467 | Start CP Tmr | | 1468 | | | 1469 | +------------------+ | +---+ | Xmit {RDS, 1470 | | /\/\ Rcv RS V V V | | CP, EORP, 1471 | +<-| RX |<---+ +---------+ | | EOB}; 1472 | | \/\/ +---+ | | | Start 1473 | | | GP_XMIT +->+ | CP Tmr 1474 | | /\/\ +---+ | Xmit | 1475 | +<-| CP |<---+ +-----+---+ GDS; | 1476 | \/\/ CP TE | | 1477 | | | 1478 | Xmit {GDS, EOB}; | +---------+ 1479 | | | 1480 | +------------------+ | | 1481 | | /\/\ Rcv RS V V V 1482 | +<-| RX |<---+ +-------------+ 1483 | | \/\/ +---+ | 1484 | | | WAIT_RP_ACK | 1485 | | /\/\ +---+ | 1486 | +<-| CP |<---+ +-----+-------+ 1487 | \/\/ CP TE | RP acknowledged fully; 1488 | V 1489 +----------------------------------------+ 1490 LTP Sender State Transition Diagram (contd.) 1492 /\/\ /\/\ 1493 | CP | | CX | 1494 \/\/ \/\/ 1495 | | | Snd CS, 1496 | | RL EXC; | Start CS Tmr; 1497 | | | 1498 | | /\/\ | +---+ 1499 | +------>| CX | V V | 1500 | \/\/ +---------+ | CS TE, 1501 | | CS_SENT | | RL NOT EXC; 1502 V RL NOT EXC; +-+--+--+-+ | Rxmt CS, 1503 Rxmt CP, | | | | Restart 1504 Start CP Tmr; CS TE, | | +---+ CS Tmr 1505 RL EXC; | | 1506 | | Rcv CAS; 1507 V V 1508 /\/\/\/\ 1509 | Cncld | 1510 \/\/\/\/ 1512 /\/\ 1513 | RX | 1514 \/\/ 1515 | Cncl CP Tmr (if any) 1516 V Snd RA 1517 +---------+ +----+ 1518 | CHK_RPT | | | 1519 +-+--+----+ RP in scope V | 1520 | | \ NOT rcvd. fully +---------+ | Rxmt 1521 Redundant | | RP +--------------------->| RP_RXMT | | missing 1522 RS rcvd; | | in scope +----+--+-+ | RDS; 1523 | | rcvd. fully | | | 1524 V V Rxmt last | +----+ 1525 missing RDS | 1526 (marked CP) | 1527 Start CP Tmr; | 1528 V 1530 The sender LTP stays in the CLOSED state until receiving a 1531 Block Transmission Request (Blk. Trans. Req) from the client 1532 service instance. Upon receiving the request it either moves to 1533 the Fully Green Transmission State (FG_XMIT) if no portion of the 1534 block was requested to be transmitted as red, or moves to the Red- 1535 Part Transmission State (RP_XMIT) state if a non-zero block-prefix 1536 was requested to be transmitted red. 1538 In the FG_XMIT state, the block is segmented as multiple green 1539 LTP data segments respecting the link MTU size and the segments 1540 are queued for transmission to the remote engine. The last such 1541 segment is marked as EOB and the sender LTP returns to the CLOSED 1542 state after queuing it for transmission. 1544 Similarly, from the RP_XMIT state multiple red data segments 1545 are queued for transmission. The sender LTP may optionally mark 1546 some of the red data segments as asynchronous checkpoints; the 1547 internal procedure Start Checkpoint Timer [Sec 5.2] is followed 1548 upon receiving a link-state cue indicating the actual beginning of 1549 transmission of such segments. The sender LTP marks the last red- 1550 data segment of the block as both CP and EORP, and after queuing 1551 it for transmission moves to the Green Part Transmission (GP_XMIT) 1552 state. If the block transmission was fully red however, the last 1553 red-data segment is marked as CP, EORP, and EOB and the sender LTP 1554 moves to the Wait-for-Red-Part-Acknowledgment (WAIT_RP_ACK) state 1555 instead. For both the above state-transitions, the internal 1556 procedure Start Checkpoint Timer [Sec 5.2] is followed upon 1557 receiving a link-state cue indicating the beginning of 1558 transmission of the queued CP segments. If the sender LTP entered 1559 the GP_XMIT state, the remaining green-part of the block is 1560 segmented as green data segments and queued for transmission to 1561 the receiver LTP; the last green segment of the block is 1562 additionally marked as EOB and the sender LTP moves to the 1563 WAIT_RP_ACK state. 1565 While the sender LTP is at any of the RP_XMIT, GP_XMIT, or 1566 WAIT_RP_ACK states, it might be interrupted by the following two 1567 events asynchronously: 1569 1. An RS might be received from the receiver LTP (either in 1570 response to a previously transmitted CP segment or sent 1571 asynchronously for accelerated retransmission). The sender LTP 1572 then moves to perform the sequence of state transitions 1573 beginning at the RX marker (second-part of the diagram), and 1574 retransmits data if necessary, illustrating the internal 1575 procedure Retransmit Data [Sec 5.13]: 1577 First, if the RS had a non-zero CP serial number, the 1578 corresponding CP timer is canceled. Then, an RA segment 1579 acknowledging the received RS is queued for transmission to the 1580 receiver LTP and the sender LTP moves to the Check Report state 1581 (CHK_RPT). If the RS was redundantly transmitted by the 1582 receiver LTP (possibly because either the last transmitted RA 1583 got lost or the RS timer expired prematurely at the receiver), 1584 the sender LTP does nothing more and returns back to the 1585 interrupted state. Similarly, if all red-data within the scope 1586 of the RS is reported as received, there is no work to be done 1587 and the sender LTP returns to the interrupted state. However, 1588 if the RS indicated incomplete reception of data within its 1589 scope, the sender LTP moves to the Red-part Retransmit state 1590 (RP_RXMT) where missing red data-segments within scope are 1591 queued for transmission. The last such segment is marked as a 1592 CP, and the sender LTP returns to the interrupted state. The 1593 internal procedure [Sec 5.2] is followed upon receiving a 1594 link-state cue indicating beginning of transmission of the CP 1595 segment. 1597 2. A previously set CP timer might expire. Now the sender LTP 1598 follows the states beginning at the CP marker (second-part of 1599 the diagram), and follows the internal procedure Retransmit 1600 Checkpoint [Sec 5.7]: 1602 If the CP Retransmission Limit set by network management for 1603 the session has been exceeded, the sender LTP proceeds towards 1604 canceling the session (with reason-code RLEXC) as indicated by 1605 the sequence of state transitions following the CX marker. 1606 Otherwise (if the Retransmission Limit is not exceeded yet), 1607 the CP segment is queued for retransmission and the sender LTP 1608 returns to the interrupted state. The Start Checkpoint Timer 1609 internal procedure [Sec 5.2] is started again upon receiving a 1610 link-state cue indicating the beginning of transmission of the 1611 segment. 1613 The sender LTP stays at the WAIT_RP_ACK state after reaching it 1614 until the red-part data is fully acknowledged as received by the 1615 receiver LTP, and then returns to the CLOSED state following the 1616 internal procedure Close Session [Sec 5.20]. 1618 <> Note that while at the CLOSED state, 1619 the sender LTP might receive an RS (if the last transmitted RA 1620 before session close got lost or if the receiver LTP retransmitted 1621 the RS prematurely), in which case it retransmits an acknowledging 1622 RA and stays in the CLOSED state. If the session was canceled by 1623 the Receiver by issuing a CR segment, the receiver may retransmit 1624 the CR (either prematurely or because the acknowledging CAR got 1625 lost). In this case, the sender LTP retransmits the acknowledging 1626 CAR and stays in the CLOSED state. 1628 Asynchronous cancel request may be received from the local client 1629 service while the sender LTP was in any of the states mentioned. 1630 If it was not already in the sequence of state transitions 1631 beginning at the CX marker, the internal procedure Cancel Session 1632 [Sec 5.19] is followed, and the sender LTP moves from its current 1633 state into the sequence beginning at the CX marker initiating 1634 session cancellation with reason-code CNCLD. From the CX marker, 1635 the CS segment with appropriate reason-code (CNCLD or RLEXC 1636 depending on how the CX sequence was entered) is queued for 1637 transmission to the receiver LTP and the sender enters the Cancel- 1638 from-Sender Sent(CS_SENT) state. The internal procedure Start 1639 Cancel Timer [Sec 5.15] is started upon receiving a link-state cue 1640 indicating the beginning of transmission of the CS segment. Upon 1641 receiving the acknowledging CAS from the receiver, the sender LTP 1642 moves to the CLOSED state (via the Cncld marker). If the CS Timer 1643 expires, the internal procedure Retransmit Cancellation Segment 1644 [Sec 5.16] is followed: 1646 If the network management set retransmission limit is exceeded, 1647 the session is simply closed and the sender LTP follows the 1648 Cncld marker to the CLOSED state. If the retransmission limit 1649 is not exceeded however, the CS segment is queued for a 1650 retransmission and the sender LTP stays in the CS_SENT state. 1651 The CS Timer is started upon receiving a link-state cue 1652 indicating the beginning of actual transmission according to 1653 the internal procedure Start Cancel Timer [Sec 5.15]. 1655 Asynchronous cancel request may also be received from the receiver 1656 LTP in the form of a CR segment when the sender LTP is in any of 1657 the states. Upon receiving such a CR segment, the internal 1658 procedure Acknowledge Cancellation [Sec 5.17] is invoked: The 1659 sender LTP sends a CAR segment in response and returns to the 1660 CLOSED state. 1662 7.2 Receiver 1663 LTP Receiver State Transition Diagram 1665 /\/\/\/\ 1666 +----+ +----+ Cncld | 1667 Rcv CS; | V V \/\/\/\/ 1668 Snd CAS | +-------------+ 1669 +--+ CLOSED +<--------------------------+ 1670 +------+------+ | 1671 +----+ | Rcv first DS | 1672 Rcv RA; | V V | 1673 Cncl RS Tmr | +--------+ | 1674 +---+ DS_REC | | 1675 +----------------------------->+-+--+-+-+<----------------------+---+ | 1676 | Svc. does not exist | | | RS TE | | | 1677 | /\/\ or Rcv miscolored seg. | | | /\/\ | | | 1678 | | CX |<-----------------------+ | +------------->| RX |---->+ | | 1679 | \/\/ | \/\/ | | 1680 | Rcv RDS; | Rcv GDS; | | 1681 | +-----------+------------+ | | 1682 | V V | | 1683 | /\/\ RS TE +--------------+ +--------+ | | 1684 +<-| RX |<------+ RCV_RP | | RCV_GP | | | 1685 | \/\/ +-+----+--+--+-+ +--+-+-+-+ | | 1686 | | | | | | | | | | 1687 | Rcvd RDS; | | | | Rcvd {RDS, CP, | | | RS TE /\/\ | | 1688 | | | | | EORP, EOB}; | | +------>| RX |->+ | 1689 +<----------------+ | | | Snd RS, | | \/\/ | | 1690 | | | | Start RS Tmr | | Rcvd GDS; | | 1691 | Rcvd {RDS, CP}; | | | | +---------------->+ | 1692 | Snd RS, Start RS Tmr | | +-------+ +-----+ | 1693 +<---------------------+ | | | Rcvd {GDS, EOB}; | 1694 | | | | | 1695 | | +-----+ | | +------+ | 1696 | Rcvd {RDS, CP, EORP}; | | V V V V | | 1697 | Snd RS, Start RS Tmr | | +----------------+ | Rcv RDS; | 1698 | | | | +-->+ | 1699 | | | | WAIT_RP_REC | | Rcv {RDS, CP}; | 1700 | | | | +-->+ Snd RS, Start | 1701 +<------------------------+ | +---+--+-+-+-----+ | RS Tmr | 1702 | RS TE | | | | Rcv RA; | | 1703 | V | | | Cncl | | 1704 | /\/\ | | | RS Tmr | | 1705 +---| RX | | | +-------->+ | 1706 \/\/ | | | 1707 /\/\ | | | 1708 | CX |<------------------------+ | RP rcvd. fully | 1709 \/\/ Rcv miscolored seg. +--------------------------->+ 1710 LTP Receiver State Transition Diagram (contd.) 1712 /\/\ 1713 | RX | 1714 \/\/ 1715 | | 1716 | | RL EXC; /\/\ 1717 RL NOT EXC; | +---------->| CX | 1718 Rxmt RS, | \/\/ 1719 Start RS Tmr | 1720 V 1722 /\/\ 1723 | CX | 1724 \/\/ 1725 | Snd CR, 1726 | Start CR Tmr; 1727 | 1728 | +----+ 1729 V V | 1730 +---------+ | CR TE, 1731 | CR_SENT | | RL NOT EXC; 1732 +-+--+--+-+ | Rxmt CR, 1733 | | | | Restart 1734 CR TE, | | +---+ CR Tmr 1735 RL EXC; | | 1736 | | Rcv CAR; 1737 V V 1738 /\/\/\/\ 1739 | Cncld | 1740 \/\/\/\/ 1742 The receiver LTP begins at the CLOSED state and enters the Data 1743 Segment Reception (DS_REC) state upon receiving the first data 1744 segment. If the client service ID referenced in the data segment 1745 was non-existent, a CX segment with reason-code UNREACH SHOULD be 1746 sent to the sender LTP with the Cancellation sequence beginning 1747 with the CX marker (second part of the diagram). If the received 1748 segment was found to be miscolored (a red-part data segment whose 1749 block offset begins at an offset higher than the offset of any 1750 green-part data segment previously received, or a green-part data 1751 segment whose block offset begins at an offset lower than the 1752 offset of any red-part data segment previously received), the 1753 internal procedure Handle Miscolored Segment [Sec 5.21] is 1754 followed; a CX segment with reason-code MISCOLORED SHOULD be sent 1755 to the sender LTP with the Cancellation sequence beginning with 1756 the CX marker. 1758 Otherwise, the receiver LTP enters the Receive Red-Part state 1759 (RCV_RP) or the Receive Green-Part state (RCV_GP) depending on 1760 whether the segment received was red or green respectively. 1762 In the RCV_RP state, a check is made of the nature of the received 1763 red DS. If the segment was a regular red data segment, the 1764 receiver LTP just returns to the DS_REC state. For red data 1765 segments marked also as CP and as CP & EORP, a responding RS is 1766 queued for transmission to the sender following either the 1767 internal procedure Retransmit RS [Sec 5.8] or Send Reception 1768 Report [Sec 5.11] depending on whether the CP segment was a 1769 retransmission (An RS corresponding to the Checkpoint Serial 1770 Number in the CP was previously issued) or not, respectively. 1771 The receiver LTP then returns to the DS_REC state. If the block 1772 transmission was fully red and the segment was marked as CP, EORP, 1773 and EOB, the receiver LTP enters the Wait-for-Red-Part-Reception 1774 state (WAIT_RP_REC). In all cases the internal procedure Start RS 1775 Timer [Sec 5.3] is followed upon receiving link-state cues 1776 indicating beginning of transmission of the RS segments. 1778 In the RCV_GP state, if the received green data segment was not 1779 marked EOB, the receiver LTP returns to the DS_REC state. 1780 Otherwise it enters the WAIT_RP_REC state to receive the red-part 1781 of the block fully. 1783 A previously set RS timer may expire asynchronously while the 1784 receiver LTP was in the DS_REC, RCV_RP, RCV_GP, or WAIT_RP_REC 1785 states. If so, the internal procedure Retransmit RS [Sec 5.8] is 1786 followed as illustrated in the states beginning at the RX marker 1787 (shown in the second part of the diagram) before returning to the 1788 interrupted state: 1790 A check is made here to see if the retransmission limit set by 1791 the network management has been exceeded in the number of RSs 1792 sent in the session. If so, a CR segment with reason-code RLEXC 1793 SHOULD be sent to the sender LTP and the sequence following the 1794 CX marker is followed. Otherwise, the RS is queued for 1795 retransmission and the associated RS timer is started following 1796 the internal procedure Start RS Timer [Sec 5.3] upon receiving 1797 a link-state cue indicating the beginning of its transmission. 1799 The receiver LTP may also receive RA segments from the sender in 1800 response to the RSs sent while in the DS_REC state. If so, then 1801 the RS timer corresponding to the report serial number mentioned 1802 in the RA segment is canceled following the internal procedure 1803 Stop RS Timer [Sec 5.14]. 1805 The receiver LTP stays in the WAIT_RP_REC state until the entire 1806 red-part of the block is received, and moves to the CLOSED state 1807 upon full red-part reception. In this state, a check is made upon 1808 reception of every red-part DS to see if it is at a block offset 1809 higher than any green-part DS received. If so, the Handle 1810 Miscolored Segment internal procedure [Sec 5.21] is invoked and 1811 the sequence of state transitions beginning with the CX marker is 1812 followed; a CX segment with reason-code MISCOLORED SHOULD be sent 1813 to the sender LTP with the Cancellation sequence beginning with 1814 the CX marker. 1816 Note that if there were no red data segments received in the 1817 session yet, including the case where the session was indeed fully 1818 green or the pathological case where the entire red-part of the 1819 block gets lost but at least the green data segment marked EOB is 1820 received (the receiver LTP has no indication of whether the 1821 session had a red-part transmission), the receiver LTP assumes the 1822 "RP rcvd. fully" condition to be true and moves to the CLOSED 1823 state from the WAIT_RP_REC state. 1825 In the WAIT_RP_REC state, the receiver LTP may receive the 1826 retransmitted red data segments. Upon receiving red data segments 1827 marked CP, it queues the responding RS for transmission based on 1828 either internal procedure Retransmit RS [Sec 5.8] or Send 1829 Reception Report [Sec 5.11] depending on whether the CP was found 1830 to be a retransmission or not, respectively. The Start RS Timer 1831 internal procedure is invoked upon receiving a link-state cue 1832 indicating the beginning of transmission of the RS. If an RA 1833 segment is received, the RS timer corresponding to the report 1834 segment mentioned is canceled and the receiver LTP stays in the 1835 state until the entire red-part is received. 1837 In the sequence of state transitions beginning at the CX marker, 1838 the CR segment with the given reason-code (depending on how the 1839 sequence is entered) is queued for transmission, and the CR timer 1840 is started upon reception of the link-state cue indicating actual 1841 transmission following internal procedure Start Cancel Timer [Sec 1842 5.15]. If the CAR is received from the sender LTP, the receiver 1843 LTP returns to the CLOSED state (via the Cncld marker) following 1844 the Stop Cancel Timer internal procedure [Sec 5.18]. If the CR 1845 timer expires asynchronously, the internal procedure Retransmit 1846 Cancellation Segment [Sec 5.16] is followed : 1847 A check is made to see if the retransmission limit set by the 1848 network management for the number of CRs per session has been 1849 exceeded. If so, the receiver LTP returns to the CLOSED state 1850 following the Cncld marker. Otherwise, a CR segment is 1851 scheduled for retransmission with the CR timer being started 1852 following the internal procedure Start Cancel Timer [Sec 5.15] 1853 upon reception of a link-state cue indicating actual 1854 transmission. 1856 <> The receiver LTP might also receive a 1857 retransmitted CS at the CLOSED state (either if the CAS segment 1858 previously transmitted was lost or if the CS timer expired 1859 prematurely at the sender LTP). In such a case the CAS is 1860 scheduled for retransmission. 1862 Asynchronous cancel requests are handled similar to the way they 1863 are handled in the sender LTP. If the cancel request was made from 1864 the local client service instance and the receiver LTP was not 1865 already in the CR_SENT state, a CR with reason-code CNCLD SHOULD 1866 be sent to the sender LTP following the sequence of state 1867 transitions beginning at the CX marker as described above. If the 1868 asynchronous cancel request is received from the sender LTP, a CAS 1869 segment is sent and the receiver LTP moves to the CLOSED state 1870 (independent of the state the receiver LTP may be in). 1872 8. Requirements from the Operating Environment 1874 LTP requires support from its operating environment (which 1875 includes network management activities) and link-state cues from 1876 the data-link layer for its operations. 1878 The local data-link layer needs to inform LTP whenever the link to 1879 a specific LTP destination is brought up or torn down. Similarly, 1880 the operating environment needs to inform the local LTP engine 1881 whenever it is known that a remote LTP engine is set to begin or 1882 stop communication with the local engine based on the operating 1883 schedules. LTP requires link state cues from the datalink layer 1884 upon transmission of the CP, RS, EORP, EOB, and Cx segments. LTP 1885 also needs to be able to query the current distance (in light 1886 seconds) to any peer engine in order to calculate timeout 1887 intervals in a typical deep-space environment. 1889 A MIB (Management Information Base), with the above parameters 1890 filled in by the local data-link layer and the operating 1891 environment periodically, should be made available to the LTP 1892 engine for its operations. The exact details of the MIB are, 1893 however, beyond the scope of this document. 1895 The underlying data-link layer is required to never deliver 1896 incompletely received LTP segments to LTP. In the absence of the 1897 use of LTP authentication [LTPEXT] LTP also requires the 1898 underlying data-link layer to perform data integrity check of the 1899 segments received. Specifically, the data-link layer is expected 1900 to detect any corrupted segments received and to silently discard 1901 them. 1903 9. Security Considerations 1905 <> 1910 There is a clear risk that unintended receivers can listen in on 1911 LTP transmissions over satellite and other radio broadcast 1912 datalinks. Such unintended recipients of LTP transmissions may 1913 also be able to manipulate LTP segments at will. 1915 Hence there is a potential requirement for confidentiality, 1916 integrity and anti-DoS (Denial of Service) security services and 1917 mechanisms. 1919 In particular, DoS problems are more severe for LTP compared to 1920 other typical internet protocols because LTP inherently retains 1921 state for long periods, and has very high time-out values. 1922 Further, it could be difficult to reset LTP nodes to recover from 1923 an attack. Thus any adversary who can actively attack an LTP 1924 transmission has the potential to create severe DoS conditions for 1925 the LTP receiver. 1927 To give a terrestrial example - were LTP to be used in a sparse 1928 sensor network, DoS attacks could be mounted resulting in nodes 1929 missing critical information, for example, communications schedule 1930 updates. In such cases, a single successful DoS attack could take 1931 a node entirely off the network until the node is physically 1932 visited and reset. 1934 Even for deep space applications of LTP, we do need to consider 1935 certain terrestrial attacks, in particular those involving 1936 insertion of messages into an on-going session (usually without 1937 having seen the exact bytes of the previous messages in the 1938 session). Such attacks are likely in the presence of firewall 1939 failures at various nodes in the network, or due to Trojan 1940 software running on an authorized host. 1942 Many message insertion attacks will depend on the attacker 1943 correctly "guessing" something about the state of the LTP peers, 1944 but experience shows that successful guesses are easier than might 1945 be thought [DDJ]. 1947 9.1 Security Mechanisms and Layering Considerations 1949 In this section we consider the appropriate layer(s) at which 1950 security mechanisms can best be deployed to increase the security 1951 properties of LTP. 1953 The Application layer (above-LTP) 1955 Higher layer security mechanisms clearly protect LTP payload, 1956 but leave LTP headers open. Such mechanisms provide little or 1957 no protection against DoS type attacks against LTP, but may 1958 well provide sufficient data integrity and ought to be able to 1959 provide data confidentiality. 1961 The LTP layer 1963 An authentication header (similar to IPSEC [AH]) can help 1964 protect against replay attacks and other bogus packets. 1965 However, an adversary may still see the LTP header of segments 1966 passing by in the ether. This approach also requires some key 1967 management infrastructure to be in place in order to provide 1968 strong authentication, which may not always be an acceptable 1969 overhead. Such an authentication header could mitigate many DoS 1970 attacks. 1972 Similarly, a confidentiality service could be defined for LTP 1973 payload and (some) header fields. However, this seems less 1974 attractive since (a) confidentiality is arguably better 1975 provided either above or below the LTP layer, (b) key 1976 management for such a service is harder (in a high-delay 1977 context) than for an integrity service, and (c) forcing LTP 1978 engines to attempt decryption of incoming segments can in 1979 itself provide a DoS opportunity. 1981 Further, within the LTP layer we can make various design 1982 decisions to reduce the probability of successful DoS attacks. 1983 In particular, we can mandate that values for certain fields in 1984 the header (session numbers, for example) be chosen randomly. 1986 The Datalink layer (below-LTP) 1988 The lower layers can clearly provide confidentiality and 1989 integrity services, although such security may result in 1990 unnecessary overhead (if a service provided is not required for 1991 all LTP sessions, for example) and loss of flexibility. 1992 However, the lower layers may well be the optimal place to do 1993 compression and encryption. 1995 9.2 Denial of Service Considerations 1997 Implementers SHOULD consider the likelihood of the following DoS 1998 attacks : 2000 A fake Cx could be inserted, thus bringing down a session. 2002 Various acknowledgment segments (RA, RS, etc.) could be 2003 deleted, causing timers to expire, and has the potential to 2004 disable communication altogether if done with a knowledge of 2005 the communications schedule. This could be achieved either by 2006 mounting a DoS attack on a lower layer service in order to 2007 prevent it from sending an acknowledgment segment, or by simply 2008 jamming the transmission (all of which are more likely for 2009 terrestrial applications of LTP). 2011 An attacker might also flip some bits, which is tantamount to 2012 deleting that segment. 2014 An attacker may flood a node with segments for the internal 2015 operations queue and prevent transmission of legitimate data 2016 segments. 2018 An attacker could attempt to fill up the storage in a node by 2019 sending many large messages to it. In terrestrial LTP 2020 applications this may be much more serious since spotting the 2021 additional traffic may not be possible from any network 2022 management point. 2024 <> 2026 LTP includes the following anti-DoS mechanisms: 2028 Session numbers MUST be partly random making it harder to 2029 insert valid segments. 2031 A node which suspects that either it or its peer is under DoS 2032 attack could frequently checkpoint its data segments (if it 2033 were the sender) or send asynchronous RSs (if it were the 2034 receiver), thus eliciting an earlier response from its peer or 2035 timing out earlier due to the failure of an attacker to 2036 respond. 2038 Serial numbers (checkpoint serial numbers, report serial 2039 numbers) MUST begin each session anew using random numbers 2040 rather than from 0. 2042 The authentication header [LTPEXT]. 2044 9.3 Replay Handling 2046 The following algorithm is given as an example of how an LTP 2047 implementation MAY handle replays. 2049 1. On receipt of an LTP segment, check against a cache for replay. 2050 If this is a replay segment and if a pre-cooked response is 2051 available (stored from the last time this segment was processed), 2052 then send the pre-cooked response. If there is no pre-cooked 2053 response then silently drop the inbound segment. This can all be 2054 done without attempting to decode the buffer. 2056 2. If the inbound segment does not decode correctly, then silently 2057 drop the segment. If the segment decodes properly, then add its 2058 hash to the replay cache and return a handle to the entry. 2060 3. For those cases where a pre-cooked response should be stored, 2061 store the response using the handle received from the previous 2062 step. These cases include: 2064 (a) when the inbound packet is a CP DS the response RS gets 2065 stored as pre-cooked; 2067 (b) when the incoming packet is an RS the RA is stored as 2068 precooked, and, 2070 (c) when the incoming packet is a Cx the CAx gets stored 2071 precooked. 2073 4. Occasionally clean out the replay cache - how frequently this 2074 happens in an implementation issue. 2076 The downside of this algorithm is that receiving a totally bogus 2077 segment still results in a replay cache search and attempted LTP 2078 decode operation. It is not clear that it is possible to do much 2079 better though, since all an attacker would have to do to get past 2080 the replay cache would be to tweak a single bit in the inbound 2081 segment each time, which is certainly cheaper than the 2082 hash+lookup+decode combination, though also certainly more 2083 expensive than simply sending the same octets many times. 2085 The benefit of doing this is that implementers no longer need to 2086 analyze many bugs/attacks based on replaying packets, which in 2087 combination with the use of LTP authentication should defeat many 2088 attempted DoS attacks. 2090 9.4 Implementation Considerations 2092 SDNV 2094 Implementations SHOULD make sanity checks on SDNV length fields 2095 and SHOULD check that no SDNV field is too long when compared 2096 with the overall segment length. 2098 Implementations SHOULD check that SDNV values are within 2099 suitable ranges where possible, e.g. <> 2101 Byte ranges 2103 Various report and other segments contain offset and length 2104 fields. Implementations MUST ensure that these are consistent 2105 and sane. 2107 Randomness 2109 Various fields in LTP (e.g. serial numbers) should be 2110 initialized using random values. Good sources of randomness 2111 which are not easily guessable SHOULD be used [ECS94]. The 2112 collision of random values is subject to the birthday paradox, 2113 which means that a collision is likely after roughly the 2114 square-root of the space has been seen (e.g. 2^16 in the case 2115 of a 32-bit random value). Implementers MUST ensure that they 2116 use sufficiently long random values so that the birthday 2117 paradox doesn't cause a problem in their environment. 2119 10. IANA Considerations 2121 At present there are none known. However if someone wanted to run 2122 LTP over IP (or even TCP or UDP), then we would want to allocate a 2123 port number. <> 2125 11. Acknowledgments 2127 Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian 2128 Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss 2129 for their thoughts on this protocol and its role in Delay-Tolerant 2130 Networking architecture. 2132 Part of the research described in this document was carried out at 2133 the Jet Propulsion laboratory, California Institute of Technology, 2134 under a contract with the National Aeronautics and Space 2135 Administration. This work was performed under DOD Contract DAA- 2136 B07- 00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO 2137 H870; and NASA Contract NAS7-1407. 2139 Thanks are also due to Shawn Ostermann, Hans Kruse, and Dovel 2140 Myers at Ohio University for their suggestions and advice in 2141 making various design decisions. 2143 Part of this work was carried out at Trinity College Dublin as 2144 part of the SeNDT contract funded by Enterprise Ireland's research 2145 innovation fund. 2147 12. References 2149 12.1 Normative References 2151 [B97] S. Bradner, "Key words for use in RFCs to Indicate 2152 Requirement Levels", BCP 14, RFC 2119, March 1997. 2154 [LTPMOTIVE] Burleigh, S., Ramadas, M., and Farrell, S., "Licklider 2155 Transmission Protocol - Motivation", draft-irtf-dtnrg-ltp- 2156 motivation-00.txt (Work in Progress), December 2004. 2158 [LTPEXT] Farrell, S., Ramadas, M., and Burleigh, S., "Licklider 2159 Transmission Protocol - Extensions", draft-irtf-dtnrg-ltp- 2160 extensions-00.txt (Work in Progress), December 2004. 2162 12.2 Informative References 2164 [AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2165 2402, November 1998. 2167 [ASN1] Abstract Syntax Notation One (ASN.1). Specification of 2168 Basic Notation. ITU-T Rec. X.680 (2002) | ISO/IEC 8824-1:2002. 2170 [DDJ] I. Goldberg and E. Wagner, "Randomness and the Netscape 2171 Browser", Dr. Dobb's Journal, 1996, (pages 66-70). 2173 [BP] K. Scott, and S. Burleigh, "Bundle Protocol Specification", 2174 Work in Progress, October 2003. 2176 [DTN] K. Fall, "A Delay-Tolerant Network Architecture for 2177 Challenged Internets", In Proceedings of ACM SIGCOMM 2003, 2178 Karlsruhe, Germany, Aug 2003. 2180 [IPN] InterPlanetary Internet Special Interest Group web page, 2181 "http://www.ipnsig.org". 2183 [ECS94] D. Eastlake, S. Crocker, and J. Schiller, "Randomness 2184 Recommendations for Security", RFC 1750, December 1994. 2186 13. Author's Addresses 2188 Manikantan Ramadas 2189 Internetworking Research Group 2190 301 Stocker Center 2191 Ohio University 2192 Athens, OH 45701 2193 Telephone +1 (740) 593-1562 2194 Email mramadas@irg.cs.ohiou.edu 2196 Scott C. Burleigh 2197 Jet Propulsion Laboratory 2198 4800 Oak Grove Drive 2199 M/S: 179-206 2200 Pasadena, CA 91109-8099 2201 Telephone +1 (818) 393-3353 2202 FAX +1 (818) 354-1075 2203 Email Scott.Burleigh@jpl.nasa.gov 2205 Stephen Farrell 2206 Distributed Systems Group 2207 Computer Science Department 2208 Trinity College Dublin 2209 Ireland 2210 Telephone +353-1-608-3070 2211 Email stephen.farrell@cs.tcd.ie 2213 14. Copyright Statement 2215 Copyright (C) The Internet Society (2004). This document is subject 2216 to the rights, licenses and restrictions contained in BCP 78, and 2217 except as set forth therein, the authors retain all their rights." 2219 This document and the information contained herein are provided on an 2220 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2221 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2222 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2223 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2224 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2225 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.