diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc5326.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc5326.txt')
| -rw-r--r-- | doc/rfc/rfc5326.txt | 3027 |
1 files changed, 3027 insertions, 0 deletions
diff --git a/doc/rfc/rfc5326.txt b/doc/rfc/rfc5326.txt new file mode 100644 index 0000000..79b6099 --- /dev/null +++ b/doc/rfc/rfc5326.txt @@ -0,0 +1,3027 @@ + + + + + + +Networking Working Group M. Ramadas +Request for Comments: 5326 ISTRAC, ISRO +Category: Experimental S. Burleigh + NASA/Jet Propulsion Laboratory + S. Farrell + Trinity College Dublin + September 2008 + + + Licklider Transmission Protocol - Specification + +Status of This Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +IESG Note + + This RFC is not a candidate for any level of Internet Standard. It + represents the consensus of the Delay Tolerant Networking (DTN) + Research Group of the Internet Research Task Force (IRTF). It may be + considered for standardization by the IETF in the future, but the + IETF disclaims any knowledge of the fitness of this RFC for any + purpose and in particular notes that the decision to publish is not + based on IETF review for such things as security, congestion control, + or inappropriate interaction with deployed protocols. See RFC 3932 + for more information. + +Abstract + + This document describes the Licklider Transmission Protocol (LTP), + designed to provide retransmission-based reliability over links + characterized by extremely long message round-trip times (RTTs) + and/or frequent interruptions in connectivity. Since communication + across interplanetary space is the most prominent example of this + sort of environment, LTP is principally aimed at supporting "long- + haul" reliable transmission in interplanetary space, but it has + applications in other environments as well. + + This document is a product of the Delay Tolerant Networking Research + Group and has been reviewed by that group. No objections to its + publication as an RFC were raised. + + + + + + + +Ramadas, et al. Experimental [Page 1] + +RFC 5326 LTP - Specification September 2008 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Terminology .....................................................4 + 3. Segment Structure ...............................................9 + 3.1. Segment Header ............................................10 + 3.1.1. Segment Type Flags .................................11 + 3.1.2. Segment Type Codes .................................13 + 3.1.3. Segment Class Masks ................................14 + 3.1.4. Extensions Field ...................................14 + 3.2. Segment Content ...........................................16 + 3.2.1. Data Segment (DS) ..................................16 + 3.2.2. Report Segment (RS) ................................17 + 3.2.3. Report Acknowledgment Segment ......................19 + 3.2.4. Session Management Segments ........................20 + 3.3. Segment Trailer ...........................................20 + 4. Requests from Client Service ...................................20 + 4.1. Transmission Request ......................................21 + 4.2. Cancellation Request ......................................22 + 5. Requirements from the Operating Environment ....................23 + 6. Internal Procedures ............................................24 + 6.1. Start Transmission ........................................25 + 6.2. Start Checkpoint Timer ....................................25 + 6.3. Start RS Timer ............................................25 + 6.4. Stop Transmission .........................................25 + 6.5. Suspend Timers ............................................26 + 6.6. Resume Timers .............................................26 + 6.7. Retransmit Checkpoint .....................................27 + 6.8. Retransmit RS .............................................27 + 6.9. Signify Red-Part Reception ................................28 + 6.10. Signify Green-Part Segment Arrival .......................28 + 6.11. Send Reception Report ....................................28 + 6.12. Signify Transmission Completion ..........................30 + 6.13. Retransmit Data ..........................................30 + 6.14. Stop RS Timer ............................................31 + 6.15. Start Cancel Timer .......................................32 + 6.16. Retransmit Cancellation Segment ..........................32 + 6.17. Acknowledge Cancellation .................................32 + 6.18. Stop Cancel Timer ........................................33 + 6.19. Cancel Session ...........................................33 + 6.20. Close Session ............................................33 + 6.21. Handle Miscolored Segment ................................33 + 6.22. Handling System Error Conditions .........................34 + 7. Notices to Client Service ......................................35 + 7.1. Session Start .............................................35 + 7.2. Green-Part Segment Arrival ................................36 + 7.3. Red-Part Reception ........................................36 + 7.4. Transmission-Session Completion ...........................36 + + + +Ramadas, et al. Experimental [Page 2] + +RFC 5326 LTP - Specification September 2008 + + + 7.5. Transmission-Session Cancellation .........................37 + 7.6. Reception-Session Cancellation ............................37 + 7.7. Initial-Transmission Completion ...........................37 + 8. State Transition Diagrams ......................................38 + 8.1. Sender ....................................................39 + 8.2. Receiver ..................................................44 + 9. Security Considerations ........................................48 + 9.1. Denial of Service Considerations ..........................48 + 9.2. Replay Handling ...........................................49 + 9.3. Implementation Considerations .............................50 + 10. IANA Considerations ...........................................51 + 10.1. UDP Port Number for LTP ..................................51 + 10.2. LTP Extension Tag Registry ...............................51 + 11. Acknowledgments ...............................................51 + 12. References ....................................................52 + 12.1. Normative References .....................................52 + 12.2. Informative References ...................................52 + +1. Introduction + + This document serves as the main protocol specification of LTP and is + part of a series of documents describing LTP. Other documents in + this series include the motivation document [LTPMTV] and the protocol + extensions document [LTPEXT]. We strongly recommend reading the + protocol motivation document before reading this document, to + establish sufficient background and motivation for the specification. + + LTP does Automatic Repeat reQuest (ARQ) of data transmissions by + soliciting selective-acknowledgment reception reports. It is + stateful, and has no negotiation or handshakes. + + In an Interplanetary Internet setting deploying the Bundle Protocol + that is being developed by the Delay Tolerant Networking Research + Group, LTP is intended to serve as a reliable "convergence layer" + protocol operating in pairwise fashion between adjacent + Interplanetary Internet nodes that are in direct radio frequency (RF) + communication. In that operational scenario, and potentially in some + other deployments of the Bundle Protocol, LTP runs directly over a + data-link layer protocol; when this is the case, forward error + correction coding and/or checksum mechanisms in the underlying data- + link layer protocol must ensure the integrity of the data passed + between the communicating entities. + + Since no mechanisms for flow control or congestion control are + included in the design of LTP, this protocol is not intended or + appropriate for ubiquitous deployment in the global Internet. + + + + + +Ramadas, et al. Experimental [Page 3] + +RFC 5326 LTP - Specification September 2008 + + + When LTP is run over UDP, it must only be used for software + development or in private local area networks. When LTP is not run + over UDP, it must be run directly over a protocol (nominally a link- + layer protocol) that meets the requirements specified in Section 5. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [B97]. + +2. Terminology + + (1) Engine ID + + A number that uniquely identifies a given LTP engine, within some + closed set of communicating LTP engines. Note that when LTP is + operating underneath the Delay-Tolerant Networking (DTN) [DTN] Bundle + Protocol [BP], the convergence layer adapter mediating the two will + be responsible for translating between DTN endpoint IDs and LTP + engine IDs in an implementation-specific manner. + + (2) Block + + An array of contiguous octets of application data handed down by the + upper layer protocol (typically Bundle Protocol) to be transmitted + from one LTP client service instance to another. + + Any subset of a block comprising contiguous octets beginning at the + start of the block is termed a "block prefix", and any such subset of + the block ending with the end of the block is termed a "block + suffix". + + (3) Red-Part + + The block prefix that is to be transmitted reliably, i.e., subject to + acknowledgment and retransmission. + + (4) Green-Part + + The block suffix that is to be transmitted unreliably, i.e., not + subject to acknowledgments or retransmissions. If present, the + green-part of a block begins at the octet following the end of the + red-part. + + (5) Session + + A thread of LTP protocol activity conducted between two peer engines + for the purpose of transmitting a block. Data flow in a session is + unidirectional: data traffic flows from the sending peer to the + + + +Ramadas, et al. Experimental [Page 4] + +RFC 5326 LTP - Specification September 2008 + + + receiving peer, while data-acknowledgment traffic flows from the + receiving peer to the sending peer. + + (6) Sender + + The data sending peer of a session. + + (7) Receiver + + The data receiving peer of a session. + + (8) Client Service Instance + + A software entity, such as an application or a higher-layer protocol + implementation, that is using LTP to transfer data. + + (9) Segment + + The unit of LTP data transmission activity. It is the data structure + transmitted from one LTP engine to another in the course of a + session. Each LTP segment is of one of the following types: data + segment, report segment, report-acknowledgment segment, cancel + segment, cancel-acknowledgment segment. + + (10) Reception Claim + + An assertion of reception of some number of contiguous octets of + application data (a subset of a block) characterized by: the offset + of the first received octet, and the number of contiguous octets + received (beginning at the offset). + + (11) Scope + + Scope identifies a subset of a block and comprises two numbers -- + upper bound and lower bound. + + For a data segment, lower bound is the offset of the segment's + application data from the start of the block (in octets), while upper + bound is the sum of the offset and length of the segment's + application data (in octets). For example, a segment with a block + offset of 1000 and length of 500 would have a lower bound of 1000 and + upper bound of 1500. + + For a report segment, upper bound is the end of the block prefix to + which the reception claims in the report apply, while lower bound is + the end of the (smaller) interior block prefix to which the reception + claims in the report do *not* apply. That is, data at any offset + equal to or greater than the report's lower bound but less than its + + + +Ramadas, et al. Experimental [Page 5] + +RFC 5326 LTP - Specification September 2008 + + + upper bound and not designated as "received" by any of the report's + reception claims must be assumed not received, and therefore eligible + for retransmission. For example, if a report segment carried a lower + bound of 1000 and an upper bound of 5000, and the reception claims + indicated reception of data within offsets 1000-1999 and 3000-4999, + data within the block offsets 2000-2999 can be considered missing and + eligible for retransmission. + + Reception reports (which may comprise multiple report segments) also + have scope, as defined in Section 6.11. + + (12) End of Block (EOB) + + The last data segment transmitted as part of the original + transmission of a block. This data segment also indicates that the + segment's upper bound is the total length of the block (in octets). + + (13) End of Red-Part (EORP) + + The segment transmitted as part of the original transmission of a + block containing the last octet of the block's red-part. This data + segment also indicates that the segment's upper bound is the length + of the block's red-part (in octets). + + (14) Checkpoint + + A data segment soliciting a reception report from the receiving LTP + engine. The EORP segment must be flagged as a checkpoint, as must + the last segment of any retransmission; these are "mandatory + checkpoints". All other checkpoints are "discretionary checkpoints". + + (15) Reception Report + + A sequence of one or more report segments reporting on all block data + reception within some scope. + + (16) Synchronous Reception Report + + A reception report that is issued in response to a checkpoint. + + (17) Asynchronous Reception Report + + A reception report that is issued in response to some implementation- + defined event other than the arrival of a checkpoint. + + + + + + + +Ramadas, et al. Experimental [Page 6] + +RFC 5326 LTP - Specification September 2008 + + + (18) Primary Reception Report + + A reception report that is issued in response to some event other + than the arrival of a checkpoint segment that was itself issued in + response to a reception report. Primary reception reports include + all asynchronous reception reports and all synchronous reception + reports that are sent in response to discretionary checkpoints or to + the EORP segment for a session. + + (19) Secondary Reception Report + + A reception report that is issued in response to the arrival of a + checkpoint segment that was itself issued in response to a reception + report. + + (20) Self-Delimiting Numeric Value (SDNV) + + The design of LTP attempts to reconcile minimal consumption of + transmission bandwidth with + + (a) extensibility to satisfy requirements not yet identified, and + + (b) scalability across a very wide range of network sizes and + transmission payload sizes. + + The SDNV encoding scheme is modeled after the Abstract Syntax + Notation One [ASN1] scheme for encoding Object Identifier values. In + a data field encoded as an SDNV, the most significant bit (MSB) of + each octet of the SDNV serves to indicate whether or not the octet is + the last octet of the SDNV. An octet with an MSB of 1 indicates that + it is either the first or a middle octet of a multi-octet SDNV; the + octet with an MSB of 0 is the last octet of the SDNV. The value + encoded in an SDNV is found by concatenating the 7 least significant + bits of each octet of the SDNV, beginning at the first octet and + ending at the last octet. + + + + + + + + + + + + + + + + +Ramadas, et al. Experimental [Page 7] + +RFC 5326 LTP - Specification September 2008 + + + The following examples illustrate the encoding scheme for various + hexadecimal values. + + 0xABC : 1010 1011 1100 + is encoded as + + {100 1010 1} {0 011 1100} + - - + + = 10010101 00111100 + + 0x1234 : 0001 0010 0011 0100 + = 1 0010 0011 0100 + is encoded as + + {10 1 0010 0} {0 011 0100} + - - + + = 10100100 00110100 + + 0x4234 : 0100 0010 0011 0100 + =100 0010 0011 0100 + is encoded as + + {1000000 1} {1 00 0010 0} {0 011 0100} + - - - + + = 10000001 10000100 00110100 + + 0x7F : 0111 1111 + =111 1111 + is encoded as + + {0 111 1111} + - + + = 01111111 + + Note: + + Care must be taken to make sure that the value to be encoded is + padded with zeroes at the most significant bit end (NOT at the least + significant bit end) to make its bitwise length a multiple of 7 + before encoding. + + While there is no theoretical limit on the size of an SDNV field, we + note that the overhead of the SDNV scheme is 1:7, i.e., 1 bit of + overhead for every 7 bits of actual data to be encoded. Thus, a + + + +Ramadas, et al. Experimental [Page 8] + +RFC 5326 LTP - Specification September 2008 + + + 7-octet value (a 56-bit quantity with no leading zeroes) would be + encoded in an 8-octet SDNV; an 8-octet value (a 64-bit quantity with + no leading zeroes) would be encoded in a 10-octet SDNV. In general, + an N-bit quantity with no leading zeroes would be encoded in a + ceil(N/7) octet SDNV, where ceil is the integer ceiling function. + Clearly, for fields that typically carry larger values such as RSA + public keys, the SDNV overhead could become unacceptable. Hence, + when adopting the SDNV scheme for other purposes related to this + document, such as any protocol extensions, we RECOMMEND that if the + typical data field value is expected to be larger than 8 octets, then + the data field should be specified as a {LENGTH, VALUE} tuple, with + the LENGTH parameter encoded as an SDNV followed by LENGTH octets + housing the VALUE of the data field. + + We also note that SDNV is clearly not the best way to represent every + numeric value. When the maximum possible value of a number is known + without question, the cost of additional bits may not be justified. + For example, an SDNV is a poor way to represent an integer whose + value typically falls in the range 128 to 255. In general, though, + we believe that the SDNV representation of various protocol data + fields in LTP segments yields the smallest segment sizes without + sacrificing scalability. + +3. Segment Structure + + Each LTP segment comprises + + (a) a "header" in the format defined below. + + (b) zero or more octets of "content". + + (c) zero or more octets of "trailer" as indicated by information + in the "Extensions field" of the header. + + LTP segments are of four general types depending on the nature of the + content carried: + + Data segments flow from the sender to the receiver and carry + client service (application) data. + + A report segment flows from the receiver to the sender and carries + data reception claims together with the upper and lower bounds of + the block scope to which the claims pertain. + + A report-acknowledgment segment flows from the sender to the + receiver and acknowledges reception of a report segment. It + carries the serial number of the report being acknowledged. + + + + +Ramadas, et al. Experimental [Page 9] + +RFC 5326 LTP - Specification September 2008 + + + Session management segments may be generated by both the sender + and the receiver and are of two general sub-types: cancellation + and cancellation-acknowledgment. A cancellation segment initiates + session cancellation procedures at the peer and carries a single + byte reason-code to indicate the reason for session cancellation. + Cancellation-acknowledgment segments merely acknowledge reception + of a cancellation segment and have no content. + + The overall segment structure is illustrated below: + + Bit 0 1 2 3 4 5 6 7 + ^ +-----+-----+-----+-----+-----+-----+-----+-----+ + | | Version number | Segment Type Flags | Control + | +-----------------------+-----------------------+ -byte + | | | + | / Session ID \ + | \ / + Header +-----------------------+-----------------------+ + | | Header Extension Cnt. | Trailer Extension Cnt.| Extensions + | +-----------------------+-----------------------+ + | | | + | / Header Extensions \ + | \ / + V +-----------------------------------------------+ + | | + | | + | | + | Segment Content | + / \ + \ / + | | + | | + | | + ^ +-----------------------------------------------+ + | | | + Trailer / Trailer Extensions \ + | \ / + V +-----------------------------------------------+ + +3.1. Segment Header + + An LTP segment header comprises three data items: a single-octet + control byte, the session ID, and the Extensions field. + + Control byte comprises the following: + + Version number (4 bits): MUST be set to the binary value 0000 for + this version of the protocol. + + + +Ramadas, et al. Experimental [Page 10] + +RFC 5326 LTP - Specification September 2008 + + + Segment type flags (4 bits): described in Section 3.1.1. + + Session ID uniquely identifies, among all transmissions between the + sender and receiver, the session of which the segment is one token. + It comprises the following: + + Session originator (SDNV): the engine ID of the sender. + + Session number (SDNV): typically a random number (for anti-DoS + reasons), generated by the sender. + + The format and resolution of session number are matters that are + private to the LTP sender; the only requirement imposed by LTP is + that every session initiated by an LTP engine MUST be uniquely + identified by the session ID. + + The Extensions field is described in Section 3.1.4. + +3.1.1. Segment Type Flags + + The last 4 bits of the control byte in the segment header are flags + that indicate the nature of the segment. In order (most significant + bit first), these flags are CTRL, EXC, Flag 1, and Flag 0. + + A value of 0 in the CTRL (Control) flag identifies the segment as a + data segment, while a value of 1 identifies it as a control segment. + A data segment with the EXC (Exception) flag set to 0 is a red-part + segment; a data segment with EXC set to 1 is a green-part segment. + For a control segment, having the EXC flag set to 1 indicates that + the segment pertains to session cancellation activity. Any data + segment (whether red-part or green-part) with both Flag 1 and Flag 0 + set to 1 indicates EOB. Any data segment (whether red-part or + green-part) with both Flag 1 and Flag 0 set to 0 indicates data + without any additional protocol significance. Any red-part data + segment with either flag bit non-zero is a checkpoint. Any red-part + data segment with Flag 1 set to 1 indicates the end of red-part. + + + + + + + + + + + + + + + +Ramadas, et al. Experimental [Page 11] + +RFC 5326 LTP - Specification September 2008 + + + Put another way: + + if (CTRL flag = 0) + segment is a data segment if (EXC flag = 0) + segment contains only red-part data if (Flag 1 = 1) + segment is a checkpoint segment is the last segment in the + red part of the block if (Flag 0 = 1) + segment is the last segment in the block + else // segment is not end of red-part + if (Flag 0 = 1) + segment is a checkpoint + else + segment contains only green-part data if (Flag 1 = 1) + if (Flag 0 = 1) + segment is the last segment in the block + else + segment is a control segment if (EXC flag = 0) + segment pertains to report activity if (flag 0 = 0) + segment is a report segment + else + segment is an acknowledgment of a report segment + else + segment pertains to session cancellation activity if (Flag 1 = + 0) + segment pertains to cancellation by block sender if (Flag 0 + = 1) + segment is a cancellation by sender + else + segment is an acknowledgment of a cancellation by sender + else + segment pertains to cancellation by block receiver if (Flag + 0 = 1) + segment is a cancellation by receiver + else + segment is an acknowledgment of a cancellation by + receiver + + + + + + + + + + + + + + + +Ramadas, et al. Experimental [Page 12] + +RFC 5326 LTP - Specification September 2008 + + +3.1.2. Segment Type Codes + + Combinations of the settings of the segment type flags CTRL, EXC, + Flag 1, and Flag 0 constitute segment type codes, which serve as + concise representations of detailed segment nature. + + CTRL EXC Flag 1 Flag 0 Code Nature of segment + ---- --- ------ ------ ---- --------------------------------------- + 0 0 0 0 0 Red data, NOT {Checkpoint, EORP or EOB} + 0 0 0 1 1 Red data, Checkpoint, NOT {EORP or EOB} + 0 0 1 0 2 Red data, Checkpoint, EORP, NOT EOB + 0 0 1 1 3 Red data, Checkpoint, EORP, EOB + + 0 1 0 0 4 Green data, NOT EOB + 0 1 0 1 5 Green data, undefined + 0 1 1 0 6 Green data, undefined + 0 1 1 1 7 Green data, EOB + + 1 0 0 0 8 Report segment + 1 0 0 1 9 Report-acknowledgment segment + 1 0 1 0 10 Control segment, undefined + 1 0 1 1 11 Control segment, undefined + + 1 1 0 0 12 Cancel segment from block sender + 1 1 0 1 13 Cancel-acknowledgment segment + to block sender + + 1 1 1 0 14 Cancel segment from block receiver + 1 1 1 1 15 Cancel-acknowledgment segment + to block receiver + + + + + + + + + + + + + + + + + + + + + +Ramadas, et al. Experimental [Page 13] + +RFC 5326 LTP - Specification September 2008 + + +3.1.3. Segment Class Masks + + For the purposes of this specification, some bit patterns in the + segment type flags field correspond to "segment classes" that are + designated by mnemonics. The mnemonics are intended to evoke the + characteristics shared by all types of segments characterized by + these flag bit patterns. + + CTRL EXC Flag 1 Flag 0 Mnemonic Description + ---- --- ------ ------ -------- --------------------------- + 0 0 - 1 + -- or -- + 0 0 1 - CP Checkpoint + + 0 0 1 - EORP End of red-part; + red-part size = offset + length + + 0 - 1 1 EOB End of block; + block size = offset + length + + 1 0 0 0 RS Report segment; + carries reception claims + + 1 0 0 1 RA Report-acknowledgment segment + + 1 1 0 0 CS Cancel segment from block sender + + 1 1 0 1 CAS Cancel-acknowledgment segment + to block sender + + 1 1 1 0 CR Cancel segment from block receiver + + 1 1 1 1 CAR Cancel-acknowledgment segment + to block receiver + + 1 1 - 0 Cx Cancel segment (generic) + + 1 1 - 1 CAx Cancel-acknowledgment segment + (generic) + +3.1.4. Extensions Field + + The Extensions field enables the inclusion of zero or more functional + extensions to the basic LTP segment, each in type-length-value (TLV) + representation as explained below. + + + + + + +Ramadas, et al. Experimental [Page 14] + +RFC 5326 LTP - Specification September 2008 + + + The first octet of the Extensions field indicates the number of + extensions present in the segment: the high-order 4 bits indicate the + number of extension TLVs in the header (immediately following the + extensions count octet and preceding the segment's content), while + the low-order 4 bits indicate the number of extension TLVs in the + trailer (immediately following the segment's content). That is, each + segment may have from 0 to 15 extension TLVs in its header and from 0 + to 15 extension TLVs in its trailer. In the absence of any extension + TLVs, all bits of this extensions count octet MUST be set to zero. + + Note that it is valid for header extensions to be immediately + followed by trailer extensions; for example, since a CAx segment has + no contents, it may have header extensions immediately followed by + trailer extensions. + + Each extension consists of a one-octet tag identifying the type of + the extension, followed by a length parameter in SDNV form, followed + by a value of the specified length. + + The diagram below illustrates the extension TLVs as they may occur in + the header or trailer. + + +--------+----///-----///--+ + |ext-tag | length | value | + +--------+-------///-------+----------///-------+ + |ext-tag | length | value | + +--------+-----///-----///-+---------////-------+ + |ext-tag | length | value | + +--------+----------+----------+ + + The IANA maintains an LTP Extension Tag registry as shown below. See + the IANA considerations section below for details of code point + assignment in the Unassigned range. + + Extension tag Meaning + ------------- ------- + 0x00 LTP authentication extension [LTPEXT] + 0x01 LTP cookie extension [LTPEXT] + 0x02-0xAF Unassigned + 0xB0-0xBF Reserved + 0xC0-0xFF Private / Experimental Use + + Note that since the last quarter of the extension-tag space is for + experimental use, implementations should be aware that collisions for + these tags are possible. + + + + + + +Ramadas, et al. Experimental [Page 15] + +RFC 5326 LTP - Specification September 2008 + + +3.2. Segment Content + +3.2.1. Data Segment (DS) + + The content of a data segment includes client service data and the + metadata enabling the receiving client service instance to receive + and make use of that data. + + Client service ID (SDNV) + + The client service ID number identifies the upper-level service to + which the segment is to be delivered by the receiver. It is + functionally analogous to a TCP port number. If multiple + instances of the client service are present at the destination, + multiplexing must be done by the client service itself on the + basis of information encoded within the transmitted block. + + Offset (SDNV) + + Offset indicates the location of the segment's client service data + within the session's transmitted block. It is the number of bytes + in the block prior to the byte from which the first octet of the + segment's client service data was copied. + + Length (SDNV) + + The length of the ensuing client service data, in octets. + + If the data segment is a checkpoint, the segment MUST additionally + include the following two serial numbers (checkpoint serial number + and report serial number) to support efficient retransmission. Data + segments that are not checkpoints MUST NOT have these two fields in + the header and MUST continue on directly with the client service + data. + + Checkpoint serial number (SDNV) + + The checkpoint serial number uniquely identifies the checkpoint + among all checkpoints issued by the block sender in a session. + The first checkpoint issued by the sender MUST have this serial + number chosen randomly for security reasons, and it is RECOMMENDED + that the sender use the guidelines in [ESC05] for this. Any + subsequent checkpoints issued by the sender MUST have the serial + number value found by incrementing the prior checkpoint serial + number by 1. When a checkpoint segment is retransmitted, however, + its serial number MUST be the same as when it was originally + transmitted. The checkpoint serial number MUST NOT be zero. + + + + +Ramadas, et al. Experimental [Page 16] + +RFC 5326 LTP - Specification September 2008 + + + Report serial number (SDNV) + + If the checkpoint was queued for transmission in response to the + reception of an RS (Section 6.13), then its value MUST be the + report serial number value of the RS that caused the data segment + to be queued for transmission. + + Otherwise, the value of report serial number MUST be zero. + + Client service data (array of octets) + + The client service data carried in the segment is a copy of a + subset of the bytes in the original client service data block, + starting at the indicated offset. + +3.2.2. Report Segment (RS) + + The content of an RS comprises one or more data reception claims, + together with the upper and lower bounds of the scope within the data + block to which the claims pertain. It also includes two serial + numbers to support efficient retransmission. + + Report serial number (SDNV) + + The report serial number uniquely identifies the report among all + reports issued by the receiver in a session. The first report + issued by the receiver MUST have this serial number chosen + randomly for security reasons, and it is RECOMMENDED that the + receiver use the guidelines in [ESC05] for this. Any subsequent + RS issued by the receiver MUST have the serial number value found + by incrementing the last report serial number by 1. When an RS is + retransmitted however, its serial number MUST be the same as when + it was originally transmitted. The report serial number MUST NOT + be zero. + + Checkpoint serial number (SDNV) + + The value of the checkpoint serial number MUST be zero if the + report segment is NOT a response to reception of a checkpoint, + i.e., the reception report is asynchronous; otherwise, it MUST be + the checkpoint serial number of the checkpoint that caused the RS + to be issued. + + Upper bound (SDNV) + + The upper bound of a report segment is the size of the block + prefix to which the segment's reception claims pertain. + + + + +Ramadas, et al. Experimental [Page 17] + +RFC 5326 LTP - Specification September 2008 + + + Lower bound (SDNV) + + The lower bound of a report segment is the size of the (interior) + block prefix to which the segment's reception claims do NOT + pertain. + + Reception claim count (SDNV) + + The number of data reception claims in this report segment. + + Reception claims + + Each reception claim comprises two elements: offset and length. + + Offset (SDNV) + + The offset indicates the successful reception of data beginning + at the indicated offset from the lower bound of the RS. The + offset within the entire block can be calculated by summing + this offset with the lower bound of the RS. + + Length (SDNV) + + The length of a reception claim indicates the number of + contiguous octets of block data starting at the indicated + offset that have been successfully received. + + Reception claims MUST conform to the following rules: + + A reception claim's length shall never be less than 1 and shall + never exceed the difference between the upper and lower bounds + of the report segment. + + The offset of a reception claim shall always be greater than + the sum of the offset and length of the prior claim, if any. + + The sum of a reception claim's offset and length and the lower + bound of the report segment shall never exceed the upper bound + of the report segment. + + Implied requests for retransmission of client service data can be + inferred from an RS's data reception claims. However, *nothing* can + be inferred regarding reception of block data at any offset equal to + or greater than the segment's upper bound or at any offset less than + the segment's lower bound. + + + + + + +Ramadas, et al. Experimental [Page 18] + +RFC 5326 LTP - Specification September 2008 + + + For example, if the scope of a report segment has lower bound 0 and + upper bound 6000, and the report contains a single data reception + claim with offset 0 and length 6000, then the report signifies + successful reception of the first 6000 bytes of the block. If the + total length of the block is 6000, then the report additionally + signifies successful reception of the entire block. + + If on the other hand, the scope of a report segment has lower bound + 1000 and upper bound 6000, and the report contains two data reception + claims, one with offset 0 and length 2000 and the other with offset + 3000 and length 500, then the report signifies successful reception + only of bytes 1000-2999 and 4000-4499 of the block. From this we can + infer that bytes 3000-3999 and 4500-5999 of the block need to be + retransmitted, but we cannot infer anything about reception of the + first 1000 bytes or of any subsequent data beginning at block offset + 6000. + +3.2.3. Report Acknowledgment Segment + + The content of an RA is simply the report serial number of the RS in + response to which the segment was generated. + + Report serial number (SDNV) + + This field returns the report serial number of the RS being + acknowledged. + + + + + + + + + + + + + + + + + + + + + + + + + +Ramadas, et al. Experimental [Page 19] + +RFC 5326 LTP - Specification September 2008 + + +3.2.4. Session Management Segments + + Cancel segments (Cx) carry a single byte reason-code with the + following semantics: + + Reason-Code Mnemonic Semantics + ----------- -------- --------------------------------------- + 00 USR_CNCLD Client service canceled session. + + 01 UNREACH Unreachable client service. + + 02 RLEXC Retransmission limit exceeded. + + 03 MISCOLORED Received either a red-part data segment + at block offset above any green-part + data segment offset or a green-part + data segment at block offset below any + red-part data segment offset. + + 04 SYS_CNCLD A system error condition caused + unexpected session termination. + + 05 RXMTCYCEXC Exceeded the Retransmission-Cycles limit. + + 06-FF Reserved + + The Cancel-acknowledgments (CAx) have no content. + + Note: The reason we use different cancel segment types for the + originator and recipient is to allow a loopback mode to work without + disturbing any replay protection mechanism in use. + +3.3. Segment Trailer + + The segment trailer consists of a sequence of zero to 15 extension + TLVs as described in Section 3.1.4 above. + +4. Requests from Client Service + + In all cases, the representation of request parameters is a local + implementation matter, as are validation of parameter values and + notification of the client service in the event that a request is + found to be invalid. + + + + + + + + +Ramadas, et al. Experimental [Page 20] + +RFC 5326 LTP - Specification September 2008 + + +4.1. Transmission Request + + In order to request transmission of a block of client service data, + the client service MUST provide the following parameters to LTP: + + Destination client service ID. + + Destination LTP engine ID. + + Client service data to send, as an array of bytes. + + Length of the data to be sent. + + Length of the red-part of the data. This value MUST be in the + range from zero to the total length of data to be sent. + + On reception of a valid transmission request from a client service, + LTP proceeds as follows. + + First, the array of data to be sent is subdivided as necessary, with + each subdivision serving as the client service data of a single new + LTP data segment. The algorithm used for subdividing the data is a + local implementation matter; it is expected that data size + constraints imposed by the underlying communication service, if any, + will be accommodated in this algorithm. + + The last (and only the last) of the resulting data segments must be + marked as the EOB (end of block). + + Note that segment type indicates that the client service data in a + given LTP segment either is or is not in the red-part of the block. + To prevent segment type ambiguity, each data segment MUST contain + either only red-part data or only green-part data. Therefore, when + the length of the block's red-part is N, the total length of the + block is M, and N is not equal to M, the (N+1)th byte of the block + SHOULD be the first byte of client service data in a green-part data + segment. Note that this means that at the red-part boundary, LTP may + send a segment of size lesser than the link MTU size. For bandwidth + efficiency reasons, implementations MAY choose to instead mark the + entire segment (within which the red-part boundary falls) as red- + part, causing green-part data falling within the segment to also be + treated as red-part. + + If the length of the block's red-part is greater than zero, then the + last data segment containing red-part data must be marked as the EORP + (end of red-part) segment by setting the appropriate segment type + flag bits (Section 3.1.2). Zero or more preceding data segments + containing red-part data (selected according to an algorithm that is + + + +Ramadas, et al. Experimental [Page 21] + +RFC 5326 LTP - Specification September 2008 + + + a local implementation matter) MAY additionally be marked as a CP + (Checkpoint), and serve as additional discretionary checkpoints + (Section 3.1.2). + + All data segments are appended to the (conceptual) application data + queue bound for the destination engine, for subsequent transmission. + + Finally, a session start notice (Section 7.1) is sent back to the + client service that requested the transmission. + +4.2. Cancellation Request + + In order to request cancellation of a session, either as the sender + or as the receiver of the associated data block, the client service + must provide the session ID identifying the session to be canceled. + + On reception of a valid cancellation request from a client service, + LTP proceeds as follows. + + First, the internal "Cancel Session" procedure (Section 6.19) is + invoked. + + Next, if the session is being canceled by the sender (i.e., the + session originator part of the session ID supplied in the + cancellation request is the local LTP engine ID): + + - If none of the data segments previously queued for transmission + as part of this session have yet been de-queued and transmitted + -- i.e., if the destination engine cannot possibly be aware of + this session -- then the session is simply closed; the "Close + Session" procedure (Section 6.20) is invoked. + + - Otherwise, a CS (cancel by block sender) segment with the + reason-code USR_CNCLD MUST be queued for transmission to the + destination LTP engine specified in the transmission request + that started this session. + + Otherwise (i.e., the session is being canceled by the receiver): + + - If there is no transmission queue-set bound for the sender + (possibly because the local LTP engine is running on a receive- + only device), then the session is simply closed; the "Close + Session" procedure (Section 6.20) is invoked. + + - Otherwise, a CR (cancel by block receiver) segment with reason- + code USR_CNCLD MUST be queued for transmission to the block + sender. + + + + +Ramadas, et al. Experimental [Page 22] + +RFC 5326 LTP - Specification September 2008 + + +5. Requirements from the Operating Environment + + LTP is designed to run directly over a data-link layer protocol. + + LTP MUST only be deployed directly over UDP, for software development + purposes or for use in private local area networks, for example, in a + sparse sensor network where the link, when available, is only used + for LTP traffic. + + In either case, the protocol layer immediately underlying LTP is + referred to as the "local data-link layer" for the purposes of this + specification. + + When the local data-link layer protocol is UDP, (a) the content of + each UDP datagram MUST be an integral number of LTP segments and (b) + the LTP authentication [LTPEXT] extension SHOULD be used unless the + end-to-end path is one in which either the likelihood of datagram + content corruption is negligible or the consequences of receiving and + processing corrupt LTP segments are insignificant (as during software + development). In addition, the LTP authentication [LTPEXT] extension + SHOULD be used to ensure data integrity unless the end-to-end path is + one in which either the likelihood of datagram content corruption is + negligible (as in some private local area networks) or the + consequences of receiving and processing corrupt LTP segments are + insignificant (as perhaps during software development). + + When the local data-link layer protocol is not UDP, the content of + each local data-link layer protocol frame MUST be an integral number + of LTP segments. + + The local data-link layer protocol MUST be a protocol that, together + with the operating environment in which that protocol is implemented, + satisfies the following requirements: + + - It is required to inform LTP whenever the link to a specific LTP + destination is brought up or torn down. Similarly, it is + required to inform the local LTP engine whenever it is known + that a remote LTP engine is set to begin or stop communication + with the local engine based on the engines' operating schedules. + + - It is required to provide link state cues to LTP upon + transmission of the CP, RS (report), EORP, EOB, and Cx (cancel) + segments so that timers can be started. + + - It is required to provide, upon request, the current distance + (in light seconds) to any peer engine in order to calculate + timeout intervals. + + + + +Ramadas, et al. Experimental [Page 23] + +RFC 5326 LTP - Specification September 2008 + + + A MIB (Management Information Base) with the above parameters, + updated periodically by the local data-link layer and the operating + environment, should be made available to the LTP engine for its + operations. The details of the MIB are, however, beyond the scope of + this document. + + The underlying data-link layer is required to never deliver + incompletely received LTP segments to LTP. In the absence of the use + of LTP authentication [LTPEXT], LTP also requires the underlying + local data-link layer protocol to perform data integrity checking of + the segments received. Specifically, the local data-link layer + protocol is required to detect any corrupted segments received and to + silently discard them. + +6. Internal Procedures + + This section describes the internal procedures that are triggered by + the occurrence of various events during the lifetime of an LTP + session. + + Whenever the content of any of the fields of the header of any + received LTP segment does not conform to this specification document, + the segment is assumed to be corrupt and MUST be discarded + immediately and processed no further. This procedure supersedes all + other procedures described below. + + All internal procedures described below that are triggered by the + arrival of a data segment are superseded by the following procedure + in the event that the client service identified by the data segment + does not exist at the local LTP engine: + + - If there is no transmission queue-set bound for the block sender + (possibly because the local LTP engine is running on a receive- + only device), then the received data segment is simply + discarded. + + - Otherwise, if the data segment contains data from the red-part + of the block, a CR with reason-code UNREACH MUST be enqueued for + transmission to the block sender. A CR with reason-code UNREACH + SHOULD be similarly enqueued for transmission to the data sender + even if the data segment contained data from the green-part of + the block; note however that (for example) in the case where the + block receiver knows that the sender of this green-part data is + functioning in a "beacon" (transmit-only) fashion, a CR need not + be sent. In either case, the received data segment is + discarded. + + + + + +Ramadas, et al. Experimental [Page 24] + +RFC 5326 LTP - Specification September 2008 + + +6.1. Start Transmission + + This procedure is triggered by the arrival of a link state cue + indicating the start of transmission to a specified remote LTP + engine. + + Response: the de-queuing and delivery of segments to the LTP engine + specified in the link state cue begins. + +6.2. Start Checkpoint Timer + + This procedure is triggered by the arrival of a link state cue + indicating the de-queuing (for transmission) of a CP segment. + + Response: the expected arrival time of the RS segment that will be + produced on reception of this CP segment is computed, and a countdown + timer is started for this arrival time. However, if it is known that + the remote LTP engine has ceased transmission (Section 6.5), then + this timer is immediately suspended, because the computed expected + arrival time may require an adjustment that cannot yet be computed. + +6.3. Start RS Timer + + This procedure is triggered by the arrival of a link state cue + indicating the de-queuing (for transmission) of an RS segment. + + Response: the expected arrival time of the RA (report acknowledgment) + segment in response to the reception of this RS segment is computed, + and a countdown timer is started for this arrival time. However, as + in Section 6.2, if it is known that the remote LTP engine has ceased + transmission (Section 6.5), then this timer is immediately suspended, + because the computed expected arrival time may require an adjustment + that cannot yet be computed. + +6.4. Stop Transmission + + This procedure is triggered by the arrival of a link state cue + indicating the cessation of transmission to a specified remote LTP + engine. + + Response: the de-queuing and delivery to the underlying communication + system of segments from traffic queues bound for the LTP engine + specified in the link state cue ceases. + + + + + + + + +Ramadas, et al. Experimental [Page 25] + +RFC 5326 LTP - Specification September 2008 + + +6.5. Suspend Timers + + This procedure is triggered by the arrival of a link state cue + indicating the cessation of transmission from a specified remote LTP + engine to the local LTP engine. Normally, this event is inferred + from advance knowledge of the remote engine's planned transmission + schedule. + + Response: countdown timers for the acknowledging segments that the + remote engine is expected to return are suspended as necessary based + on the following procedure. + + The nominal remote engine acknowledge transmission time is computed + as the sum of the transmission time of the original segment (to which + the acknowledging segment will respond) and the one-way light time to + the remote engine, plus N seconds of "additional anticipated latency" + (AAL) encompassing anticipated transmission delays other than signal + propagation time. N is determined in an implementation-specific + manner. For example, when LTP is deployed in deep-space vehicles, + the one-way light time to the remote engine may be very large while N + may be relatively small, covering processing and queuing delays. N + may be a network management parameter, for which 2 seconds seems like + a reasonable default value. As another example, when LTP is deployed + in a terrestrial "data mule" environment, one-way light time latency + is effectively zero while N may need to be some dynamically computed + function of the data mule circulation schedule. + + If the nominal remote engine acknowledge transmission time is greater + than or equal to the current time (i.e., the acknowledging segment + may be presented for transmission during the time that transmission + at the remote engine is suspended), then the countdown timer for this + acknowledging segment is suspended. + +6.6. Resume Timers + + This procedure is triggered by the arrival of a link state cue + indicating the start of transmission from a specified remote LTP + engine to the local LTP engine. Normally, this event is inferred + from advance knowledge of the remote engine's planned transmission + schedule. + + Response: expected arrival time is adjusted for every acknowledging + segment that the remote engine is expected to return, for which the + countdown timer has been suspended. First, the transmission delay + interval is calculated as follows: + + + + + + +Ramadas, et al. Experimental [Page 26] + +RFC 5326 LTP - Specification September 2008 + + + - The nominal remote engine acknowledge transmission time is + computed as the sum of the transmission time of the original + segment (to which the acknowledging segment will respond) and + the one-way light time to the remote engine, plus N seconds of + AAL Section 6.5. + + - If the nominal remote engine acknowledge transmission time is + greater than the current time, i.e., the remote engine resumed + transmission prior to presentation of the acknowledging segment + for transmission, then the transmission delay interval is zero. + + - Otherwise, the transmission delay interval is computed as the + current time less the nominal remote engine acknowledge + transmission time. + + The expected arrival time is increased by the computed transmission + delay interval for each of the suspended countdown timers, and the + timers are resumed. + +6.7. Retransmit Checkpoint + + This procedure is triggered by the expiration of a countdown timer + associated with a CP segment. + + Response: if the number of times this CP segment has been queued for + transmission exceeds the checkpoint retransmission limit established + for the local LTP engine by network management, then the session of + which the segment is one token is canceled: the "Cancel Session" + procedure (Section 6.19) is invoked, a CS with reason-code RLEXC is + appended to the (conceptual) application data queue, and a + transmission-session cancellation notice (Section 7.5) is sent back + to the client service that requested the transmission. + + Otherwise, a new copy of the CP segment is appended to the + (conceptual) application data queue for the destination LTP engine. + +6.8. Retransmit RS + + This procedure is triggered by either (a) the expiration of a + countdown timer associated with an RS segment or (b) the reception of + a CP segment for which one or more RS segments were previously issued + -- a redundantly retransmitted checkpoint. + + Response: if the number of times any affected RS segment has been + queued for transmission exceeds the report retransmission limit + established for the local LTP engine by network management, then the + session of which the segment is one token is canceled: the "Cancel + Session" procedure (Section 6.19) is invoked, a CR segment with + + + +Ramadas, et al. Experimental [Page 27] + +RFC 5326 LTP - Specification September 2008 + + + reason-code RLEXC is queued for transmission to the LTP engine that + originated the session, and a reception-session cancellation notice + (Section 7.6) is sent to the client service identified in each of the + data segments received in this session. + + Otherwise, a new copy of each affected RS segment is queued for + transmission to the LTP engine that originated the session. + +6.9. Signify Red-Part Reception + + This procedure is triggered by the arrival of a CP segment when the + EORP for this session has been received (ensuring that the size of + the data block's red-part is known; this includes the case where the + CP segment itself is the EORP segment) and all data in the red-part + of the block being transmitted in this session have been received. + + Response: a red-part reception notice (Section 7.3) is sent to the + specified client service. + +6.10. Signify Green-Part Segment Arrival + + This procedure is triggered by the arrival of a data segment whose + content is a portion of the green-part of a block. + + Response: a green-part segment arrival notice (Section 7.2) is sent + to the specified client service. + +6.11. Send Reception Report + + This procedure is triggered by either (a) the original reception of a + CP segment (the checkpoint serial number identifying this CP is new) + (b) an implementation-specific circumstance pertaining to a + particular block reception session for which no EORP has yet been + received ("asynchronous" reception reporting). + + Response: if the number of reception problems detected for this + session exceeds a limit established for the local LTP engine by + network management, then the affected session is canceled: the + "Cancel Session" procedure (Section 6.19) is invoked, a CR segment + with reason-code RLEXC is issued and is, in concept, appended to the + queue of internal operations traffic bound for the LTP engine that + originated the session, and a reception-session cancellation notice + (Section 7.6) is sent to the client service identified in each of the + data segments received in this session. One possible limit on + reception problems would be the maximum number of reception reports + that can be issued for any single session. + + + + + +Ramadas, et al. Experimental [Page 28] + +RFC 5326 LTP - Specification September 2008 + + + If such a limit is not reached, a reception report is issued as + follows. + + If production of the reception report was triggered by reception of a + checkpoint: + + - The upper bound of the report SHOULD be the upper bound (the sum + of the offset and length) of the checkpoint data segment, to + minimize unnecessary retransmission. Note: If a discretionary + checkpoint is lost but subsequent segments are received, then by + the time the retransmission of the lost checkpoint is received + the receiver would have segments at block offsets beyond the + upper bound of the checkpoint. For deployments where bandwidth + economy is not critical, the upper bound of a synchronous + reception report MAY be the maximum upper bound value among all + red-part data segments received so far in the affected session. + + - If the checkpoint was itself issued in response to a report + segment, then this report is a "secondary" reception report. In + that case, the lower bound of the report SHOULD be the lower + bound of the report segment to which the triggering checkpoint + was itself a response, to minimize unnecessary retransmission. + Note: For deployments where bandwidth economy is not critical, + the lower bound of the report MAY instead be zero. + + - If the checkpoint was not issued in response to a report + segment, this report is a "primary" reception report. The lower + bound of the first primary reception report issued for any + session MUST be zero. The lower bound of each subsequent + primary reception report issued for the same session SHOULD be + the upper bound of the prior primary reception report issued for + the session, to minimize unnecessary retransmission. Note: For + deployments where bandwidth economy is not critical, the lower + bound of every primary reception report MAY be zero. + + If production of the reception report is "asynchronous" as noted + above: + + - The upper bound of the report MUST be the maximum upper bound + among all red-part data segments received so far for this + session. + + - The lower bound of the first asynchronous reception report + issued for any session for which no other primary reception + reports have yet been issued MUST be zero. The lower bound of + each subsequent asynchronous reception report SHOULD be the + upper bound of the prior primary reception report issued for the + + + + +Ramadas, et al. Experimental [Page 29] + +RFC 5326 LTP - Specification September 2008 + + + session, to minimize unnecessary retransmission. Note: For + deployments where bandwidth economy is not critical, the lower + bound of every asynchronous reception report MAY be zero. + + In all cases, if the applicable lower bound of the scope of a report + is determined to be greater than or equal to the applicable upper + bound (for example, due to out-of-order arrival of discretionary + checkpoints) then the reception report MUST NOT be issued. + Otherwise: + + As many RS segments must be produced as are needed in order to report + on all data reception within the scope of the report, given whatever + data size constraints are imposed by the underlying communication + service. The RS segments are, in concept, appended to the queue of + internal operations traffic bound for the LTP engine that originated + the indicated session. The lower bound of the first RS segment of + the report MUST be the reception report's lower bound. The upper + bound of the last RS segment of the report MUST be the reception + report's upper bound. + +6.12. Signify Transmission Completion + + This procedure is triggered at the earliest time at which (a) all + data in the block are known to have been transmitted *and* (b) the + entire red-part of the block -- if of non-zero length -- is known to + have been successfully received. Condition (a) is signaled by + arrival of a link state cue indicating the de-queuing (for + transmission) of the EOB segment for the block. Condition (b) is + signaled by reception of an RS segment whose reception claims, taken + together with the reception claims of all other RS segments + previously received in the course of this session, indicate complete + reception of the red-part of the block. + + Response: a transmission-session completion notice (Section 7.4) is + sent to the local client service associated with the session, and the + session is closed: the "Close Session" procedure (Section 6.20) is + invoked. + +6.13. Retransmit Data + + This procedure is triggered by the reception of an RS segment. + + Response: first, an RA segment with the same report serial number as + the RS segment is issued and is, in concept, appended to the queue of + internal operations traffic bound for the receiver. If the RS + segment is redundant -- i.e., either the indicated session is unknown + (for example, the RS segment is received after the session has been + completed or canceled) or the RS segment's report serial number + + + +Ramadas, et al. Experimental [Page 30] + +RFC 5326 LTP - Specification September 2008 + + + matches that of an RS segment that has already been received and + processed -- then no further action is taken. Otherwise, the + procedure below is followed. + + If the report's checkpoint serial number is not zero, then the + countdown timer associated with the indicated checkpoint segment is + deleted. + + Note: All retransmission buffer space occupied by data whose + reception is claimed in the report segment can (in concept) be + released. + + If the segment's reception claims indicate incomplete data reception + within the scope of the report segment: + + - If the number of transmission problems for this session exceeds + a limit established for the local LTP engine by network + management, then the session of which the segment is one token + is canceled: the "Cancel Session" procedure (Section 6.19) is + invoked, a CS with reason-code RLEXC is appended to the + transmission queue specified in the transmission request that + started this session, and a transmission-session cancellation + notice (Section 7.5) is sent back to the client service that + requested the transmission. One possible limit on transmission + problems would be the maximum number of retransmission CP + segments that may be issued for any single session. + + - If the number of transmission problems for this session has not + exceeded any limit, new data segments encapsulating all block + data whose non-reception is implied by the reception claims are + appended to the transmission queue bound for the receiver. The + last -- and only the last -- data segment must be marked as a CP + segment carrying a new CP serial number (obtained by + incrementing the last CP serial number used) and the report + serial number of the received RS segment. + +6.14. Stop RS Timer + + This procedure is triggered by the reception of an RA. + + Response: the countdown timer associated with the original RS segment + (identified by the report serial number of the RA segment) is + deleted. If no other countdown timers associated with RS segments + exist for this session, then the session is closed: the "Close + Session" procedure (Section 6.20) is invoked. + + + + + + +Ramadas, et al. Experimental [Page 31] + +RFC 5326 LTP - Specification September 2008 + + +6.15. Start Cancel Timer + + This procedure is triggered by arrival of a link state cue indicating + the de-queuing (for transmission) of a Cx segment. + + Response: the expected arrival time of the CAx segment that will be + produced on reception of this Cx segment is computed and a countdown + timer for this arrival time is started. However, if it is known that + the remote LTP engine has ceased transmission (Section 6.5), then + this timer is immediately suspended, because the computed expected + arrival time may require an adjustment that cannot yet be computed. + +6.16. Retransmit Cancellation Segment + + This procedure is triggered by the expiration of a countdown timer + associated with a Cx segment. + + Response: if the number of times this Cx segment has been queued for + transmission exceeds the cancellation retransmission limit + established for the local LTP engine by network management, then the + session of which the segment is one token is simply closed: the + "Close Session" procedure (Section 6.20) is invoked. + + Otherwise, a copy of the cancellation segment (retaining the same + reason-code) is queued for transmission to the appropriate LTP + engine. + +6.17. Acknowledge Cancellation + + This procedure is triggered by the reception of a Cx segment. + + Response: in the case of a CS segment where there is no transmission + queue-set bound for the sender (possibly because the receiver is a + receive-only device), then no action is taken. Otherwise: + + - If the received segment is a CS segment, a CAS (cancel + acknowledgment to block sender) segment is issued and is, in + concept, appended to the queue of internal operations traffic + bound for the sender. + + - If the received segment is a CR segment, a CAR (cancel + acknowledgment to block receiver) segment is issued and is, in + concept, appended to the queue of internal operations traffic + bound for the receiver. + + + + + + + +Ramadas, et al. Experimental [Page 32] + +RFC 5326 LTP - Specification September 2008 + + + It is possible that the Cx segment has been retransmitted because a + previous responding acknowledgment CAx (cancel acknowledgment) + segment was lost, in which case there will no longer be any record of + the session of which the segment is one token. If so, no further + action is taken. + + Otherwise: the "Cancel Session" procedure (Section 6.19) is invoked + and a reception-session cancellation notice (Section 7.6) is sent to + the client service identified in each of the data segments received + in this session. Finally, the session is closed: the "Close Session" + procedure (Section 6.20) is invoked. + +6.18. Stop Cancel Timer + + This procedure is triggered by the reception of a CAx segment. + + Response: the timer associated with the Cx segment is deleted, and + the session of which the segment is one token is closed, i.e., the + "Close Session" procedure (Section 6.20) is invoked. + +6.19. Cancel Session + + This procedure is triggered internally by one of the other procedures + described above. + + Response: all segments of the affected session that are currently + queued for transmission can be deleted from the outbound traffic + queues. All countdown timers currently associated with the session + are deleted. Note: If the local LTP engine is the sender, then all + remaining data retransmission buffer space allocated to the session + can be released. + +6.20. Close Session + + This procedure is triggered internally by one of the other procedures + described above. + + Response: any remaining countdown timers associated with the session + are deleted. The session state record (SSR|RSR) for the session is + deleted; existence of the session is no longer recognized. + +6.21. Handle Miscolored Segment + + This procedure is triggered by the arrival of either (a) a red-part + data segment whose block offset begins at an offset higher than the + block offset of any green-part data segment previously received for + the same session or (b) a green-part data segment whose block offset + is lower than the block offset of any red-part data segment + + + +Ramadas, et al. Experimental [Page 33] + +RFC 5326 LTP - Specification September 2008 + + + previously received for the same session. The arrival of a segment + matching either of the above checks is a violation of the protocol + requirement of having all red-part data as the block prefix and all + green-part data as the block suffix. + + Response: the received data segment is simply discarded. + + The Cancel Session procedure (Section 6.19) is invoked and a CR + segment with reason-code MISCOLORED SHOULD be enqueued for + transmission to the data sender. + + Note: If there is no transmission queue-set bound for the sender + (possibly because the local LTP engine is running on a receive-only + device), or if the receiver knows that the sender is functioning in a + "beacon" (transmit-only) fashion, a CR segment need not be sent. + + A reception-session cancellation notice (Section 7.6) is sent to the + client service. + +6.22. Handling System Error Conditions + + It is possible (especially for long-lived LTP sessions) that an + unexpected operating system error condition may occur during the + lifetime of an LTP session. An example is the case where the system + faces severe memory crunch forcing LTP sessions into a scenario + similar to that of TCP SACK [SACK] reneging. But unlike TCP SACK + reception reports, which are advisory, LTP reception reports are + binding, and reneging is NOT permitted on previously made reception + claims. + + Under any such irrecoverable system error condition, the following + response is to be initiated: the Cancel Session procedure (Section + 6.19) is invoked. If the error condition is observed on the sender, + a CS segment with reason-code SYS_CNCLD SHOULD be enqueued for + transmission to the receiver, and a transmission-session cancellation + notice (Section 7.5) is sent to the client service; on the other + hand, if it is observed on the receiver, a CR segment with the same + reason-code SYS_CNCLD SHOULD be enqueued for transmission to the + sender, and a reception-session cancellation notice (Section 7.6) is + sent to the client service. + + Note that as in (Section 6.21), if there is no transmission queue-set + bound for the sender (possibly because the local LTP engine is + running on a receive-only device), or if the receiver knows that the + sender of this green-part data is functioning in a "beacon" + (transmit-only) fashion, a CR segment need not be sent. + + + + + +Ramadas, et al. Experimental [Page 34] + +RFC 5326 LTP - Specification September 2008 + + + There may be other implementation-specific limits that may cause an + LTP implementation to initiate session-cancellation procedures. One + such limit is the maximum number of retransmission-cycles seen. A + retransmission cycle at the LTP Sender comprises the two related + events: the transmission of all outstanding CP segments from the + sender, and the reception of all RS segments issued from the receiver + in response to those CP segments. A similar definition would apply + at the LTP Receiver but relate to the reception of the CP segments + and transmission of all RS segments in response. Note that the + retransmitted CP and RS segments remain part of their original + retransmission-cycle. Also, a single CP segment may cause multiple + RS segments to be generated if a reception report would not fit in a + single data link-MTU-sized RS segment; all RS segments that are part + of a reception report belong to the same retransmission cycle to + which the CP segment belongs. In the presence of severe channel + error conditions, many retransmission cycles may elapse before red- + part transmission is deemed successful; an implementation may + therefore impose a retransmission-cycle limit to shield itself from a + resource-crunch situation. If an LTP sender notices the + retransmission-cycle limit being exceeded, it SHOULD initiate the + Cancel Session procedure (Section 6.19), queuing a CS segment with + reason-code RXMTCYCEXC and sending a transmission-session + cancellation notice (Section 7.5) to the client service. + +7. Notices to Client Service + + In all cases, the representation of notice parameters is a local + implementation matter. + +7.1. Session Start + + The Session Start notice returns the session ID identifying a newly + created session. + + At the sender, the session start notice informs the client service of + the initiation of the transmission session. On receiving this notice + the client service may, for example, release resources of its own + that are allocated to the block being transmitted, or remember the + session ID so that the session can be canceled in the future if + necessary. At the receiver, this notice indicates the beginning of a + new reception session, and is delivered upon arrival of the first + data segment carrying a new session ID. + + + + + + + + + +Ramadas, et al. Experimental [Page 35] + +RFC 5326 LTP - Specification September 2008 + + +7.2. Green-Part Segment Arrival + + The following parameters are provided by the LTP engine when a green- + part segment arrival notice is delivered: + + Session ID of the transmission session. + + Array of client service data bytes contained in the data segment. + + Offset of the data segment's content from the start of the block. + + Length of the data segment's content. + + Indication as to whether or not the last byte of this data + segment's content is also the end of the block. + + Source LTP engine ID. + +7.3. Red-Part Reception + + The following parameters are provided by the LTP engine when a red- + part reception notice is delivered: + + Session ID of the transmission session. + + Array of client service data bytes that constitute the red-part of + the block. + + Length of the red-part of the block. + + Indication as to whether or not the last byte of the red-part is + also the end of the block. + + Source LTP engine ID. + +7.4. Transmission-Session Completion + + The sole parameter provided by the LTP engine when a transmission- + session completion notice is delivered is the session ID of the + transmission session. + + A transmission-session completion notice informs the client service + that all bytes of the indicated data block have been transmitted and + that the receiver has received the red-part of the block. + + + + + + + +Ramadas, et al. Experimental [Page 36] + +RFC 5326 LTP - Specification September 2008 + + +7.5. Transmission-Session Cancellation + + The parameters provided by the LTP engine when a transmission-session + cancellation notice is delivered are: + + Session ID of the transmission session. + + The reason-code sent or received in the Cx segment that initiated + the cancellation sequence. + + A transmission-session cancellation notice informs the client service + that the indicated session was terminated, either by the receiver or + else due to an error or a resource quench condition in the local LTP + engine. There is no assurance that the destination client service + instance received any portion of the data block. + +7.6. Reception-Session Cancellation + + The parameters provided by the LTP engine when a reception + cancellation notice is delivered are: + + Session ID of the transmission session. + + The reason-code explaining the cancellation. + + A reception-session cancellation notice informs the client service + that the indicated session was terminated, either by the sender or + else due to an error or a resource quench condition in the local LTP + engine. No subsequent delivery notices will be issued for this + session. + +7.7. Initial-Transmission Completion + + The session ID of the transmission session is included with the + initial-transmission completion notice. + + This notice informs the client service that all segments of a block + (both red-part and green-part) have been transmitted. This notice + only indicates that original transmission is complete; retransmission + of any lost red-part data segments may still be necessary. + + + + + + + + + + + +Ramadas, et al. Experimental [Page 37] + +RFC 5326 LTP - Specification September 2008 + + +8. State Transition Diagrams + + The following mnemonics have been used in the sender and LTP receiver + state transition diagrams that follow: + + TE Timer Expiry + RDS Regular Red Data Segment (NOT {CP|EORP|EOB}) + GDS Regular Green Data Segment (NOT EOB) + RL EXC Retransmission Limit Exceeded + RP Red-Part + GP Green-Part + FG Fully-Green + + Note that blocks represented in rectangles, as in + + +---------+ + | FG_XMIT | + +---------+ + + specify actual states in the state-transition diagrams, while blocks + represented with jagged edges, as in + + /\/\/\/\ + | Cncld | + \/\/\/\/ + + are either pointers to a state or place-holders for sequences of + state transitions. + + + + + + + + + + + + + + + + + + + + + + + +Ramadas, et al. Experimental [Page 38] + +RFC 5326 LTP - Specification September 2008 + + +8.1. Sender + LTP Sender State Transition Diagram + + /\/\/\/\ + | Cncld | + \/\/\/\/ + +--------+ | +------+ + Rcv CR; | V V V | Rcv RS; + Snd CAR | +-------------+ | Snd RA + +-------+ CLOSED +----+ + +---------------------------->+------+------+ + | | Blk. Trans. Req + | Zero RP + + | Xmit ________________________/ \ Non-Zero RP + | GDS; / \ + | +---+ | +------------------+ | +------+ + | | V V | /\/\ Rcv RS V V V | + | | +---------+ +<-| RX |<---+ +---------+ | + | +<-+ FG_XMIT | | \/\/ +---+ +--->+ Xmit RDS; + | +----+----+ | | RP_XMIT | | + | | | /\/\ +---+ +--->+ Xmit {RDS, CP}; + +<--------+ +<-| CP |<---+ +-----+---+ Start CP Tmr + | Xmit \/\/ CP TE | \ + | {GDS, EOB}; | | + | Xmit {RDS, CP, EORP}; | +-------+ + | Start CP Tmr | | + | | | + | +------------------+ | +---+ | Xmit {RDS, + | | /\/\ Rcv RS V V V | | CP, EORP, + | +<-| RX |<---+ +---------+ | | EOB}; + | | \/\/ +---+ | | | Start + | | | GP_XMIT +->+ | CP Tmr + | | /\/\ +---+ | Xmit | + | +<-| CP |<---+ +-----+---+ GDS; | + | \/\/ CP TE | | + | | | + | Xmit {GDS, EOB}; | +---------+ + | | | + | +------------------+ | | + | | /\/\ Rcv RS V V V + | +<-| RX |<---+ +-------------+ + | | \/\/ +---+ | + | | | WAIT_RP_ACK | + | | /\/\ +---+ | + | +<-| CP |<---+ +-----+-------+ + | \/\/ CP TE | RP acknowledged fully; + | V + +----------------------------------------+ + + + +Ramadas, et al. Experimental [Page 39] + +RFC 5326 LTP - Specification September 2008 + + + LTP Sender State Transition Diagram (contd.) + + /\/\ /\/\ + |CP| |CX | + \/\/ \/\/ + | | | Snd CS, + | | RL EXC; | Start CS Tmr; + | | | + | | /\/\ | +---+ + | +------>| CX | V V | + | \/\/ +---------+ | CS TE, + | | CS_SENT | | RL NOT EXC; + V RL NOT EXC; +-+--+--+-+ | Rxmt CS, + Rxmt CP, | | | | Restart + Start CP Tmr; CS TE, | | +---+ CS Tmr + RL EXC; | | + | | Rcv CAS; + V V + /\/\/\/\ + | Cncld | + \/\/\/\/ + + /\/\ + | RX | + \/\/ + | Cncl CP Tmr (if any) + V Snd RA + +---------+ +----+ + | CHK_RPT | | | + +-+--+----+ RP in scope V | + | | \ NOT rcvd. fully +---------+ | Rxmt + Redundant | | RP +--------------------->| RP_RXMT | | missing + RS rcvd; | | in scope +----+--+-+ | RDS; + | | rcvd. fully | | | + V V Rxmt last | +----+ + missing RDS | + (marked CP) | + Start CP Tmr; | + V + + Asynchronous cancel request may be received from the local client + service while the LTP sender is in any of the states shown. If it + was not already in the sequence of state transitions beginning at the + CX marker, the internal procedure Cancel Session (Section 6.19) is + followed, and the LTP sender moves from its current state into the + sequence beginning at the CX marker initiating session cancellation + with reason-code USR_CNCLD. From the CX marker, the CS segment with + appropriate reason-code (USR_CNCLD or RLEXC depending on how the CX + + + +Ramadas, et al. Experimental [Page 40] + +RFC 5326 LTP - Specification September 2008 + + + sequence was entered) is queued for transmission to the LTP receiver + and the sender enters the Cancel-from-Sender Sent (CS_SENT) state. + The internal procedure Start Cancel Timer (Section 6.15) is started + upon receiving a link state cue indicating the beginning of + transmission of the CS segment. Upon receiving the acknowledging CAS + segment from the receiver, the LTP sender moves to the CLOSED state + (via the 'Cncld' pointer). If the CS timer expires, the internal + procedure Retransmit Cancellation Segment (Section 6.16) is followed: + + - If the network management set retransmission limit is exceeded, + the session is simply closed and the LTP sender follows the + Cncld marker to the CLOSED state. If the retransmission limit + is not exceeded however, the CS segment is queued for a + retransmission and the LTP sender stays in the CS_SENT state. + The CS timer is started upon receiving a link state cue + indicating the beginning of actual transmission according to the + internal procedure Start Cancel Timer (Section 6.15). + + Asynchronous cancel request may also be received from the receiver + LTP in the form of a CR segment when the LTP sender is in any of the + states. Upon receiving such a CR segment, the internal procedure + Acknowledge Cancellation (Section 6.17) is invoked: The LTP sender + sends a CAR segment in response and returns to the CLOSED state. + + The LTP sender stays in the CLOSED state until receiving a Block + Transmission Request (Blk. Trans. Req) from the client service + instance. Upon receiving the request, it moves to either the Fully + Green Transmission State (FG_XMIT) if no portion of the block was + requested to be transmitted as red or to the Red-Part Transmission + State (RP_XMIT) state if a non-zero block-prefix was requested to be + transmitted red. + + In the FG_XMIT state, the block is segmented as multiple green LTP + data segments respecting the link MTU size and the segments are + queued for transmission to the remote engine. The last such segment + is marked as EOB, and the LTP sender returns to the CLOSED state + after queuing it for transmission. + + Similarly, from the RP_XMIT state, multiple red data segments are + queued for transmission, respecting the link MTU size. The sender + LTP may optionally mark some of the red data segments as asynchronous + checkpoints; the internal procedure Start Checkpoint Timer (Section + 6.2) is followed upon receiving a link state cue indicating the + transmission of the asynchronous checkpoints. If the block + transmission request comprises a non-zero green part, the LTP sender + marks the last red data segment as CP and EORP, and after queuing it + for transmission, moves to the Green Part Transmission (GP_XMIT) + state. If the block transmission request was fully red however, the + + + +Ramadas, et al. Experimental [Page 41] + +RFC 5326 LTP - Specification September 2008 + + + last red data segment is marked as CP, EORP, and EOB and the sender + LTP moves directly to the Wait-for-Red-Part-Acknowledgment + (WAIT_RP_ACK) state. In both of the above state-transitions, the + internal procedure Start Checkpoint Timer (Section 6.2) is followed + upon receiving a link state cue indicating the beginning of + transmission of the queued CP segments. In the GP_XMIT state, the + green-part of the block is segmented as green data segments and + queued for transmission to the LTP receiver; the last green segment + of the block is additionally marked as EOB, and after queueing it for + transmission the LTP sender moves to the WAIT_RP_ACK state. + + While the LTP sender is at any of the RP_XMIT, GP_XMIT, or + WAIT_RP_ACK states, it might be interrupted by the occurrence of the + following events: + + 1. An RS might be received from the LTP receiver (either in + response to a previously transmitted CP segment or sent + asynchronously for accelerated retransmission). The LTP sender + then moves to perform the sequence of state transitions + beginning at the RX marker (second part of the diagram), and + retransmits data if necessary, illustrating the internal + procedure Retransmit Data (Section 6.13): + + First, if the RS segment had a non-zero CP serial number, the + corresponding CP timer is canceled. Then an RA segment + acknowledging the received RS segment is queued for + transmission to the LTP receiver and the LTP sender moves to + the Check Report state (CHK_RPT). If the RS segment was + redundantly transmitted by the LTP receiver (possibly because + either the last transmitted RA segment got lost or the RS + segment timer expired prematurely at the receiver), the LTP + sender does nothing more and returns back to the interrupted + state. Similarly, if all red data within the scope of the RS + segment is reported as received, there is no work to be done + and the LTP sender returns to the interrupted state. However, + if the RS segment indicated incomplete reception of data within + its scope, the LTP sender moves to the Red-Part Retransmit + state (RP_RXMT) where missing red data segments within scope + are queued for transmission. The last such segment is marked + as a CP, and the LTP sender returns to the interrupted state. + The internal procedure (Section 6.2) is followed upon receiving + a link state cue indicating the beginning of transmission of + the CP segment. + + 2. A previously set CP timer might expire. Now the LTP sender + follows the states beginning at the CP marker (second part of + the diagram), and follows the internal procedure Retransmit + Checkpoint (Section 6.7): + + + +Ramadas, et al. Experimental [Page 42] + +RFC 5326 LTP - Specification September 2008 + + + If the CP Retransmission Limit set by network management for + the session has been exceeded, the LTP sender proceeds towards + canceling the session (with reason-code RLEXC) as indicated by + the sequence of state transitions following the CX marker. + Otherwise (if the Retransmission Limit is not exceeded yet), + the CP segment is queued for retransmission and the LTP sender + returns to the interrupted state. The internal procedure Start + Checkpoint Timer (Section 6.2) is started again upon receiving + a link state cue indicating the beginning of transmission of + the segment. + + The LTP sender stays at the WAIT_RP_ACK state after reaching it until + the red-part data is fully acknowledged as received by the receiver + LTP, and then returns to the CLOSED state following the internal + procedure Close Session (Section 6.20). + + Note that while at the CLOSED state, the LTP sender might receive an + RS segment (if the last transmitted RA segment before session close + got lost or if the LTP receiver retransmitted the RS segment + prematurely), in which case it retransmits an acknowledging RA + segment and stays in the CLOSED state. If the session was canceled + by the receiver by issuing a CR segment, the receiver may retransmit + the CR segment (either prematurely or because the acknowledging CAR + segment got lost). In this case, the LTP sender retransmits the + acknowledging CAR segment and stays in the CLOSED state. + + + + + + + + + + + + + + + + + + + + + + + + + + +Ramadas, et al. Experimental [Page 43] + +RFC 5326 LTP - Specification September 2008 + + +8.2. Receiver + LTP Receiver State Transition Diagram + + /\/\/\/\ + +----+ +----+ Cncld | + Rcv CS; | V V \/\/\/\/ + Snd CAS | +-------------+ + +--+ CLOSED +<--------------------------+ + +------+------+ | + +----+ | Rcv first DS | + Rcv RA; | V V | + Cncl RS Tmr | +--------+ | + +---+ DS_REC | | + +----------------------------->+-+--+-+-+<----------------------+---+ | + | Svc. does not exist | | | RS TE | | | + | /\/\ or Rcv miscolored seg. | | | /\/\ | | | + | | CX |<-----------------------+ | +------------->| RX |---->+ | | + | \/\/ | \/\/ | | + | Rcv RDS; | Rcv GDS; | | + | +-----------+------------+ | | + | V V | | + | /\/\ RS TE +--------------+ +--------+ | | + +<-| RX |<------+ RCV_RP | | RCV_GP | | | + | \/\/ +-+----+--+--+-+ +--+-+-+-+ | | + | | | | | | | | | | + | Rcvd RDS; | | | | Rcvd {RDS, CP, | | | RS TE /\/\ | | + | | | | | EORP, EOB}; | | +------>| RX |->+ | + +<----------------+ | | | Snd RS, | | \/\/ | | + | | | | Start RS Tmr | | Rcvd GDS; | | + | Rcvd {RDS, CP}; | | | | +---------------->+ | + | Snd RS, Start RS Tmr | | +-------+ +-----+ | + +<---------------------+ | | | Rcvd {GDS, EOB}; | + | | | | | + | | +-----+ | | +------+ | + | Rcvd {RDS, CP, EORP}; | | V V V V | | + | Snd RS, Start RS Tmr | | +----------------+ | Rcv RDS; | + | | | | +-->+ | + | | | | WAIT_RP_REC | | Rcv {RDS, CP}; | + | | | | +-->+ Snd RS, Start | + +<------------------------+ | +---+--+-+-+-----+ | RS Tmr | + | RS TE | | | | Rcv RA; | | + | V | | | Cncl | | + | /\/\ | | | RS Tmr | | + +---| RX | | | +-------->+ | + \/\/ | | | + /\/\ | | | + | CX |<------------------------+ | RP rcvd. fully | + \/\/ Rcv miscolored seg. +--------------------------->+ + + + +Ramadas, et al. Experimental [Page 44] + +RFC 5326 LTP - Specification September 2008 + + + Receiver State Transition Diagram (contd.) + + /\/\ + | RX | + \/\/ + | | + | | RL EXC; /\/\ + RL NOT EXC; | +---------->| CX | + Rxmt RS, | \/\/ + Start RS Tmr | + V + + /\/\ + | CX | + \/\/ + | Snd CR, + | Start CR Tmr; + | + | +----+ + V V | + +---------+ | CR TE, + | CR_SENT | | RL NOT EXC; + +-+--+--+-+ | Rxmt CR, + | | | | Restart + CR TE, | | +---+ CR Tmr + RL EXC; | | + | | Rcv CAR; + V V + /\/\/\/\ + | Cncld | + \/\/\/\/ + + Asynchronous cancel requests are handled in a manner similar to the + way they are handled in the LTP sender. If the cancel request was + made from the local client service instance and the LTP receiver was + not already in the CR_SENT state, a CR segment with reason-code + USR_CNCLD SHOULD be sent to the LTP sender following the sequence of + state transitions beginning at the CX marker as described above. If + the asynchronous cancel request is received from the LTP sender, a + CAS segment is sent and the LTP receiver moves to the CLOSED state + (independent of the state the LTP receiver may be in). + + The LTP receiver begins at the CLOSED state and enters the Data + Segment Reception (DS_REC) state upon receiving the first data + segment. If the client service ID referenced in the data segment was + non-existent, a Cx segment with reason-code UNREACH SHOULD be sent to + the LTP sender via the Cancellation sequence beginning with the CX + marker (second part of the diagram). If the received segment was + + + +Ramadas, et al. Experimental [Page 45] + +RFC 5326 LTP - Specification September 2008 + + + found to be miscolored, the internal procedure Handle Miscolored + Segment (Section 6.21) is followed, and a CX segment with reason-code + MISCOLORED SHOULD be sent to the LTP sender with the Cancellation + sequence beginning with the CX marker. + + Otherwise, the LTP receiver enters the Receive Red-Part state + (RCV_RP) or the Receive Green-Part state (RCV_GP) depending on + whether the segment received was red or green, respectively. + + In the RCV_RP state, a check is made of the nature of the received + red DS. If the segment was a regular red data segment, the receiver + LTP just returns to the DS_REC state. For red data segments marked + also as CP and as CP & EORP, a responding RS segment is queued for + transmission to the sender following either the internal procedure + Retransmit RS (Section 6.8) or Send Reception Report (Section 6.11) + depending on whether the CP segment was a retransmission (an RS + segment corresponding to the checkpoint serial number in the CP + segment was previously issued) or not, respectively. The LTP + receiver then returns to the DS_REC state. If the block transmission + was fully red and the segment was marked as CP, EORP, and EOB, the + LTP receiver enters the Wait-for-Red-Part-Reception state + (WAIT_RP_REC). In all cases, the internal procedure Start RS Timer + (Section 6.3) is followed upon receiving link state cues indicating + the beginning of transmission of the RS segments. + + In the RCV_GP state, if the received green data segment was not + marked EOB, the LTP receiver returns to the DS_REC state. Otherwise, + it enters the WAIT_RP_REC state to receive the red-part of the block + fully. + + A previously set RS timer may expire and interrupt the LTP receiver + while in the DS_REC, RCV_RP, RCV_GP, or WAIT_RP_REC state. If so, + the internal procedure Retransmit RS (Section 6.8) is followed as + illustrated in the states beginning at the RX marker (shown in the + second part of the diagram) before returning to the interrupted + state: + + - A check is made here to see if the retransmission limit set by + the network management has been exceeded in the number of RSs + sent in the session. If so, a CR segment with reason-code RLEXC + SHOULD be sent to the LTP sender and the sequence indicated by + the CX marker is followed. Otherwise, the RS segment is queued + for retransmission and the associated RS timer is started + following the internal procedure Start RS Timer (Section 6.3) + upon receiving a link state cue indicating the beginning of its + transmission. + + + + + +Ramadas, et al. Experimental [Page 46] + +RFC 5326 LTP - Specification September 2008 + + + The LTP receiver may also receive RA segments from the sender in + response to the RS segments sent while in the DS_REC state. If so, + then the RS timer corresponding to the report serial number mentioned + in the RA segment is canceled following the internal procedure Stop + RS Timer (Section 6.14). + + The LTP receiver stays in the WAIT_RP_REC state until the entire red- + part of the block is received, and moves to the CLOSED state upon + full red-part reception. In this state, a check is made upon + reception of every red-part data segment to see if it is at a block + offset higher than any green-part data segment received. If so, the + internal procedure Handle Miscolored Segment (Section 6.21) is + invoked and the sequence of state transitions beginning with the CX + marker is followed; a CX segment with reason-code MISCOLORED SHOULD + be sent to the LTP sender with the Cancellation sequence beginning + with the CX marker. + + Note that if there were no red data segments received in the session + yet, including the case where the session was indeed fully green or + the pathological case where the entire red-part of the block gets + lost but at least the green data segment marked EOB is received (the + LTP receiver has no indication of whether the session had a red-part + transmission), the LTP receiver assumes the "RP rcvd. fully" + condition to be true and moves to the CLOSED state from the + WAIT_RP_REC state. + + In the WAIT_RP_REC state, the LTP receiver may receive the + retransmitted red data segments. Upon receiving red data segments + marked CP, it queues the responding RS segment for transmission based + on either internal procedure Retransmit RS (Section 6.8) or Send + Reception Report (Section 6.11) depending on whether the CP was found + to be a retransmission or not, respectively. The internal procedure + Start RS Timer is invoked upon receiving a link state cue indicating + the beginning of transmission of the RS segment. If an RA segment is + received, the RS timer corresponding to the report segment mentioned + is canceled and the LTP receiver stays in the state until the entire + red-part is received. + + In the sequence of state transitions beginning at the CX marker, the + CR segment with the given reason-code (depending on how the sequence + is entered) is queued for transmission, and the CR timer is started + upon reception of the link state cue indicating actual transmission + following the internal procedure Start Cancel Timer (Section 6.15). + If the CAR segment is received from the LTP sender, the LTP receiver + returns to the CLOSED state (via the Cncld marker) following the + internal procedure Stop Cancel Timer (Section 6.18). If the CR timer + expires asynchronously, the internal procedure Retransmit + Cancellation Segment (Section 6.16) is followed: + + + +Ramadas, et al. Experimental [Page 47] + +RFC 5326 LTP - Specification September 2008 + + + - A check is made to see if the retransmission limit set by the + network management for the number of CR segments per session has + been exceeded. If so, the LTP receiver returns to the CLOSED + state following the Cncld marker. Otherwise, a CR segment is + scheduled for retransmission with the CR timer being started + following the internal procedure Start Cancel Timer (Section + 6.15) upon reception of a link state cue indicating actual + transmission. + + The LTP receiver might also receive a retransmitted CS segment at the + CLOSED state (either if the CAS segment previously transmitted was + lost or if the CS timer expired prematurely at the LTP sender). In + such a case, the CAS is scheduled for retransmission. + +9. Security Considerations + +9.1. Denial of Service Considerations + + Implementers SHOULD consider the likelihood of the following Denial + of Service (DoS) attacks: + + - A fake Cx could be inserted, thus bringing down a session. + + - Various acknowledgment segments (RA, RS, etc.) could be deleted, + causing timers to expire, and having the potential to disable + communication altogether if done with a knowledge of the + communications schedule. This could be achieved either by + mounting a DoS attack on a lower-layer service in order to + prevent it from sending an acknowledgment segment, or by simply + jamming the transmission (all of which are more likely for + terrestrial applications of LTP). + + - An attacker might also corrupt some bits, which is tantamount to + deleting that segment. + + - An attacker may flood an LTP engine with segments for the + internal operations queue and prevent transmission of legitimate + data segments. + + + + + + + + + + + + + +Ramadas, et al. Experimental [Page 48] + +RFC 5326 LTP - Specification September 2008 + + + - An attacker could attempt to fill up the storage in an engine by + sending many large messages to it. In terrestrial LTP + applications, this may be much more serious since spotting the + additional traffic may not be possible from any network + management point. + + If any of the above DoS attacks is likely, then one or more of the + following anti-DoS mechanisms ought to be employed: + + - Session numbers SHOULD be partly random making it harder to + insert valid segments. + + - An engine that suspects that either it or its peer is under DoS + attack could frequently checkpoint its data segments (if it were + the sender) or send asynchronous RSs (if it were the receiver), + thus eliciting an earlier response from its peer or timing out + earlier due to the failure of an attacker to respond. + + - Serial numbers (checkpoint serial numbers, report serial + numbers) MUST begin each session anew using random numbers + rather than from 0. + + - The authentication header [LTPEXT]. + +9.2. Replay Handling + + The following algorithm is given as an example of how an LTP + implementation MAY handle replays. + + 1. On receipt of an LTP segment, check against a cache for replay. + If this is a replay segment and if a pre-cooked response is + available (stored from the last time this segment was processed), + then send the pre-cooked response. If there is no pre-cooked + response, then silently drop the inbound segment. This can all be + done without attempting to decode the buffer. + + 2. If the inbound segment does not decode correctly, then silently + drop the segment. If the segment decodes properly, then add its + hash to the replay cache and return a handle to the entry. + + 3. For those cases where a pre-cooked response should be stored, + store the response using the handle received from the previous + step. These cases include: + + (a) when the inbound packet is a CP segment, the RS segment sent + in response gets stored as pre-cooked, + + + + + +Ramadas, et al. Experimental [Page 49] + +RFC 5326 LTP - Specification September 2008 + + + (b) when the Incoming packet is an RS segment, the RA segment is + stored as pre-cooked, and + + (c) when the incoming packet is a Cx segment, the CAx segment sent + in response gets stored pre-cooked. + + 4. Occasionally clean out the replay cache -- how frequently this + happens is an implementation issue. + + The downside of this algorithm is that receiving a totally bogus + segment still results in a replay cache search and attempted LTP + decode operation. It is not clear that it is possible to do much + better though, since all an attacker would have to do to get past the + replay cache would be to tweak a single bit in the inbound segment + each time, which is certainly cheaper than the hash+lookup+decode + combination, though also certainly more expensive than simply sending + the same octets many times. + + The benefit of doing this is that implementers no longer need to + analyze many bugs/attacks based on replaying packets, which in + combination with the use of LTP authentication should defeat many + attempted DoS attacks. + +9.3. Implementation Considerations + + SDNV + + Implementations SHOULD make sanity checks on SDNV length fields + and SHOULD check that no SDNV field is too long when compared with + the overall segment length. + + Implementations SHOULD check that SDNV values are within suitable + ranges where possible. + + Byte ranges + + Various report and other segments contain offset and length + fields. Implementations MUST ensure that these are consistent and + sane. + + Randomness + + Various fields in LTP (e.g., serial numbers) MUST be initialized + using random values. Good sources of randomness that are not + easily guessable SHOULD be used [ESC05]. The collision of random + values is subject to the birthday paradox, which means that a + collision is likely after roughly the square root of the space has + been seen (e.g., 2^16 in the case of a 32-bit random value). + + + +Ramadas, et al. Experimental [Page 50] + +RFC 5326 LTP - Specification September 2008 + + + Implementers MUST ensure that they use sufficiently long random + values so that the birthday paradox doesn't cause a problem in + their environment. + +10. IANA Considerations + +10.1. UDP Port Number for LTP + + The UDP port number 1113 with the name "ltp-deepspace" has been + reserved for LTP deployments. An LTP implementation may be + implemented to operate over UDP datagrams using this port number for + study and testing over the Internet. + +10.2. LTP Extension Tag Registry + + The IANA has created and now maintains a registry for known LTP + Extension Tags (as indicated in Section 3.1). The registry has been + populated using the initial values given in Section 3.1 above. IANA + may assign LTP Extension Tag values from the range 0x02-0xAF + (inclusive) using the Specification Required rule [GUIDE]. The + specification concerned can be an RFC (whether Standards Track, + Experimental, or Informational), or a specification from any other + standards development organization recognized by IANA or with a + liaison with the IESG, specifically including CCSDS + (http://www.ccsds.org/). Any use of Reserved values (0xB0-0xBF + inclusive) requires an update this specification. + +11. Acknowledgments + + Many thanks to Tim Ray, Vint Cerf, Bob Durst, Kevin Fall, Adrian + Hooke, Keith Scott, Leigh Torgerson, Eric Travis, and Howie Weiss for + their thoughts on this protocol and its role in Delay-Tolerant + Networking architecture. + + Part of the research described in this document was carried out at + the Jet Propulsion Laboratory, California Institute of Technology, + under a contract with the National Aeronautics and Space + Administration. This work was performed under DOD Contract DAA-B07- + 00-CC201, DARPA AO H912; JPL Task Plan No. 80-5045, DARPA AO H870; + and NASA Contract NAS7-1407. + + Thanks are also due to Shawn Ostermann, Hans Kruse, Dovel Myers, and + Jayram Deshpande at Ohio University for their suggestions and advice + in making various design decisions. This work was done when + Manikantan Ramadas was a graduate student at the EECS Dept., Ohio + University, in the Internetworking Research Group Laboratory. + + + + + +Ramadas, et al. Experimental [Page 51] + +RFC 5326 LTP - Specification September 2008 + + + Part of this work was carried out at Trinity College Dublin as part + of the SeNDT contract funded by Enterprise Ireland's research + innovation fund. + +12. References + +12.1. Normative References + + [B97] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [GUIDE] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, May + 2008. + + [LTPMTV] Burleigh, S., Ramadas, M., and S. Farrell,"Licklider + Transmission Protocol - Motivation", RFC 5325, September + 2008. + + [LTPEXT] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider + Transmission Protocol - Security Extensions", RFC 5327, + September 2008. + +12.2. Informative References + + [ASN1] Abstract Syntax Notation One (ASN.1). ASN.1 Encoding Rules: + Specification of Basic Encoding Rules (BER), Canonical + Encoding Rules (CER), and Distinguished Encoding Rules + (DER). ITU-T Rec. X.690 (2002) | ISO/IEC 8825-1:2002. + + [BP] Scott, K. and S. Burleigh, "Bundle Protocol Specification", + RFC 5050, November 2007. + + [DTN] K. Fall, "A Delay-Tolerant Network Architecture for + Challenged Internets", In Proceedings of ACM SIGCOMM 2003, + Karlsruhe, Germany, Aug 2003. + + [ESC05] D. Eastlake, J. Schiller and S. Crockerr, "Randomness + Recommendations for Security", RFC 4086, June 2005. + + [SACK] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow, "TCP + Selective Acknowledgement Options", RFC 2018, October 1996. + + + + + + + + + +Ramadas, et al. Experimental [Page 52] + +RFC 5326 LTP - Specification September 2008 + + +Authors' Addresses + + Manikantan Ramadas + ISRO Telemetry Tracking and Command Network (ISTRAC) + Indian Space Research Organization (ISRO) + Plot # 12 & 13, 3rd Main, 2nd Phase + Peenya Industrial Area + Bangalore 560097 + India + Telephone: +91 80 2364 2602 + EMail: mramadas@gmail.com + + Scott C. Burleigh + Jet Propulsion Laboratory + 4800 Oak Grove Drive + M/S: 301-490 + Pasadena, CA 91109-8099 + Telephone: +1 (818) 393-3353 + Fax: +1 (818) 354-1075 + EMail: Scott.Burleigh@jpl.nasa.gov + + Stephen Farrell + Computer Science Department + Trinity College Dublin + Ireland + Telephone: +353-1-896-1761 + EMail: stephen.farrell@cs.tcd.ie + + + + + + + + + + + + + + + + + + + + + + + + +Ramadas, et al. Experimental [Page 53] + +RFC 5326 LTP - Specification September 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, + and except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Ramadas, et al. Experimental [Page 54] + |