Using PPP as an LTP Convergence Layer
draft-bsipos-dtn-ppp-ltp-clayer-00

Abstract

This document specifies a method for transporting Licklider Transmission Protocol segments over a Point-to-Point Protocol data link.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 16, 2016.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Requirements Language
• 2. LTP Over PPP
• 2.1. PPP Requirements
• 2.2. LTP Requirements
• 3. IANA Considerations
• 4. Security Considerations
• 5. References
• 5.1. Normative References
• 5.2. Informative References
• Author's Address

1. Introduction

The Licklider Transmission Protocol (LTP) provides a reliable point-to-point datagram transfer function. According to the original LTP motivation [RFC5325] the LTP is "designed to run directly over a data-link layer protocol" with UDP/DCCP framing as a secondary transport mode. This document specifies the method of transporting LTP segments between two data link endpoints using the Point-to-Point Protocol (PPP).

1.1. Requirements Language

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 [RFC2119].

2. LTP Over PPP

In this use of LTP over PPP, each LTP segment acts as a service data unit (SDU) encapsulated within the PPP protocol data unit (PDU). This encapsulation imposes constraints on both layers as described below. LTP segments encoded according to [RFC5326] SHALL be transported over PPP according to [RFC1661] with LTP identified as a Network Layer Protocol.

2.1. PPP Requirements

There is no need for any Network Control Protocol negotiation before using LTP-over-PPP. A PPP connection MAY multiplex other Network Layer Protocols along with transport of LTP segments.

PPP does not directly provide a link-level data integrity check, and LTP relies upon the lower layer to guarantee integrity each LTP segment (each segment either arrives in whole or is dropped). Specifically, the use of Frame Check Sequence (FCS) of [RFC1662] ensures the integrity of PPP PDUs. Some form of data-link-level checksum SHALL be used to ensure the integrity of transported PDUs. Any received PDU which does not pass integrity check SHALL be dropped by the PPP engine.

The use of LTP over PPP SHOULD NOT interfere with any existing PPP extensions. The LTP header and/or data of the SDU MAY be compressed within the PPP PDU.

2.2. LTP Requirements

For simplicity, and to conform with the PPP tradition of one-PDU-one-SDU there is no multiple-segment packaing as allowed by LTP. LTP Engines have wide latitude regarding segment sizing, but in this case the PPP layer provides guidance regarding maximum allowed size. Each PPP PDU SHALL encapsulate exactly one LDP segment. The LTP Engine SHALL be informed of a change in negotiated PPP Maximum Receive Unit (MRU) size to adapt its LTP segment Maximum Transmit Unit (MTU) size. Where possible, LTP Engines SHOULD split data into segments no shorter than the MTU size.

The LTP segment structure encodes the size of each of its component elements, so any additional data following the last segment trailer is unused by the LTP Engine. In some cases it is beneficial to guarantee exact-sized PDUs, which can be accomodated with PPP padding as defined here. Each LTP segment sized less than the MTU MAY be appended with zero-valued octets up to the MTU size. An LTP Engine SHOULD NOT read any SDU content beyond the end of its final segment trailer.

The PPP data integrity checks are relatively weak, so a cryptographic-type integrity check at the LTP segment level improves robustness. This check avoids cases where PPP checksum passes but the data really has been either corrupted or tampered with. Specifically, the LTP Authentication extension of [RFC5327] provides an authenticated integrity check. Each LTP segment SHOULD contain an extension to verify the integrity of the data witin the segment.

3. IANA Considerations

The IANA Registry for PPP [refs.IANA-PPP] must have its "PPP DLL Protocol Numbers" table updated to reflect a new Protocol Field value for LTP as a Network Layer Protocol.

4. Security Considerations

Both PPP and LTP define extensions for authentication, confidentiality, and data integrity. This memo does require the use of some data link integrity check. This memo does not require the use of authentication or confidentiality at either layer.

Because LTP implements no congestion control mechanism, if the PPP link is shared betweeen LTP and other network protocols the LTP transport may cause denial-of-service to the other network protocols.

5. References

5.1. Normative References

5.2. Informative References

Author's Address