tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 5326

 Errata 
Experimental
Pages: 54
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IRTF

Licklider Transmission Protocol - Specification

Part 1 of 2, p. 1 to 24
None       Next RFC Part

 


Top       ToC       Page 1 
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.

Top       Page 2 
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

Top      ToC       Page 3 
      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.

Top      ToC       Page 4 
   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

Top      ToC       Page 5 
   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

Top      ToC       Page 6 
   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.

Top      ToC       Page 7 
   (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.

Top      ToC       Page 8 
   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

Top      ToC       Page 9 
   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.

Top      ToC       Page 10 
      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.

Top      ToC       Page 11 
      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.

Top      ToC       Page 12 
   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

Top      ToC       Page 13 
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

Top      ToC       Page 14 
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.

Top      ToC       Page 15 
   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.

Top      ToC       Page 16 
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.

Top      ToC       Page 17 
   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.

Top      ToC       Page 18 
   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.

Top      ToC       Page 19 
   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.

Top      ToC       Page 20 
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.

Top      ToC       Page 21 
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

Top      ToC       Page 22 
   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.

Top      ToC       Page 23 
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.

Top      ToC       Page 24 
   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.



(page 24 continued on part 2)

Next RFC Part