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]
