1 / 13

Licklider Transmission Protocol (LTP)

Licklider Transmission Protocol (LTP). A point-to-point protocol for DTNs Think of it as somewhere from layer 2 up to maybe layer 4! LTP is highly stateful Needed to avoid negotiation exchanges Primarily aimed at deep space DTNs but can also (I claim!) be used for many terrestrial cases

fairly
Download Presentation

Licklider Transmission Protocol (LTP)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Licklider Transmission Protocol (LTP) • A point-to-point protocol for DTNs • Think of it as somewhere from layer 2 up to maybe layer 4! • LTP is highly stateful • Needed to avoid negotiation exchanges • Primarily aimed at deep space DTNs but can also (I claim!) be used for many terrestrial cases • Encoding is terse and binary

  2. LTP layering • LTP runs on top of some MAC layer or deep space physical layer • LTP assumes lower layer “cues” are provided so that some infrastructure (e.g. ephemeris handler + scheduler) tells the stack when to expect to receive or transmit with a given peer.

  3. LTP Segment Bit 0 1 2 3 4 5 6 7 ^ +-----+-----+-----+-----+-----+-----+-----+-----+ | | Version number | Segment Type Flags | | +-----------------------+-----------------------+ | | | | / Session ID \ | \ / Header +-----------------------+-----------------------+ | | Header Extension Cnt. | Trailer Extension Cnt.| | +-----------------------+-----------------------+ | | | | / Header Extensions \ | \ / V +-----------------------------------------------+ | | | | | | | Segment Content | / \ \ / | | | | | | ^ +-----------------------------------------------+ | | | Trailer / Trailer Extensions \ | \ / V +-----------------------------------------------+

  4. LTP Encoding • Many fields use so-called Self-Delimiting Numeric Values (SDNV) • Also used in bundling protocol • Based on ASN.1 BER encoding of OID arcs • Might change in future • But so long as the same thing's used everywhere that's ok

  5. LTP features • Sessions/Segments • A single “block” is sent per “session” using multiple “segments” • Segment size is limited by the underlying MTU • Session-ID is src-ID + number • Recommended to use a (P)RNG for the number • Red/green parts • Data is ACKed (red) or not (green) • Not ACKing is easier, but doesn't fulfill all appn. Requirements • Red part first (if any), then green (if any) • Each segment in a session is entirely red or entirely green

  6. Red/Green motivation • Lots of science data formats (e.g. images) put important information (e.g. codec, timing, orientation) at the start, followed by lots of less important detail (pixels) • Loose the codec information and the rest is useless • Losing a pixel or two (hundred) isn't that bad • Want to have ACKs for the start of the block but not the entire block • Caller or config. determines which, if any, segments are red. Others are green.

  7. LTP segment types • Data segment (tx->rx) • Can be Red or Green • Report segment (rx->tx) • Report ACK segment (tx->rx) • Cancel segments (tx/rx differ) • Required for loopback • Cancel ACK segments

  8. Data segments • Subset of block's bytes (offset, length) • Flags can indicate: • End of Red Part • End of Block • EORP and EOB require report (ACK) • Unless zero red bytes

  9. Reports • Each report contains a set of scopes, each of which informs the transmitter that some (red)bytes have arrived safely • Report segment has a serial number (RSN) • Report segments always ACKed using RSN • Wrinkle: reporting the “full” state might require >1 rx->tx MTU so a single “report” might need >1 RS • Spec. has some hyper-efficient ways to handle this for deep space reasons • Also allows for more “full” reporting where bandwidth less constrained

  10. Retransmission • Re-txing based on timeouts and counters • If EORP/EOB sent but no ACK (RS) • If RS sent but no RA • If Cx sent but no CAx • Timers use “punctuated” time • Only decremented during periods when data could actually be arriving from the peer • E.g. Not decremented while peer is turned off

  11. Denial of Service • LTP nodes can be very badly affected by DoS • Took a couple of weeks to reboot MER Spirit when OS had no file handles left • Anti-DoS features: • Random bits recommended in Session ID • Recommended random bits in report serial numbers • Initial version had both being guessable and so potential targets for off-path attacks • Like TCP SYN flooding • Replay detection algorithm (sample) • Cookies (next slide)

  12. LTP extensions • Both header and trailer extensions allowed • LTP authentication extension • Header: ciphersuite • Trailer: MAC/Signature • LTP cookie extension • DoS would be very bad for a deep space host • Cookies aiming to protect against off-path attacks using a header extension, once turned on, only segments with cookie accepted

  13. LTP status • LTP specified in 3 drafts • draft-irtf-dtnrg-ltp-03.txt main spec. • draft-irtf-dtnrg-ltp-motivation-01 reasons for stuff • Draft-irtf-dtnrg-ltp-extensions-01 extensions • Main spec and motivation are just about ready for last call • Extensions a little later (sync. security stuff) • At least two implementations I know of

More Related