Internet DRAFT - draft-bsipos-dtn-ppp-ltp-clayer

draft-bsipos-dtn-ppp-ltp-clayer







Internet Research Task Force (IRTF)                             B. Sipos
Internet-Draft                                           RKF Engineering
Intended status: Experimental                           January 13, 2016
Expires: July 16, 2016


                 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.





Sipos                     Expires July 16, 2016                 [Page 1]

Internet-Draft    Using PPP as an LTP Convergence Layer     January 2016


Table of Contents

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

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).



Sipos                     Expires July 16, 2016                 [Page 2]

Internet-Draft    Using PPP as an LTP Convergence Layer     January 2016


   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.







Sipos                     Expires July 16, 2016                 [Page 3]

Internet-Draft    Using PPP as an LTP Convergence Layer     January 2016


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

   [RFC1661]  Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
              STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
              <http://www.rfc-editor.org/info/rfc1661>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5326]  Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
              Transmission Protocol - Specification", RFC 5326,
              DOI 10.17487/RFC5326, September 2008,
              <http://www.rfc-editor.org/info/rfc5326>.

   [refs.IANA-PPP]
              IANA, "Point-to-Point (PPP) Protocol Field Assignemnts",
              November 2012.

5.2.  Informative References

   [RFC1662]  Simpson, W., Ed., "PPP in HDLC-like Framing", STD 51,
              RFC 1662, DOI 10.17487/RFC1662, July 1994,
              <http://www.rfc-editor.org/info/rfc1662>.

   [RFC5325]  Burleigh, S., Ramadas, M., and S. Farrell, "Licklider
              Transmission Protocol - Motivation", RFC 5325,
              DOI 10.17487/RFC5325, September 2008,
              <http://www.rfc-editor.org/info/rfc5325>.

   [RFC5327]  Farrell, S., Ramadas, M., and S. Burleigh, "Licklider
              Transmission Protocol - Security Extensions", RFC 5327,
              DOI 10.17487/RFC5327, September 2008,
              <http://www.rfc-editor.org/info/rfc5327>.



Sipos                     Expires July 16, 2016                 [Page 4]

Internet-Draft    Using PPP as an LTP Convergence Layer     January 2016


Author's Address

   Brian Sipos
   RKF Engineering Solutions, LLC
   1229 19th Street NW
   Wasington, DC  20036
   US

   Email: BSipos@rkf-eng.com










































Sipos                     Expires July 16, 2016                 [Page 5]