Internet DRAFT - draft-burleigh-dtnrg-ltpcl

draft-burleigh-dtnrg-ltpcl







Network Working Group                                        S. Burleigh
Internet-DraftJet Propulsion Laboratory, California Institute of Technol
Intended status: Experimental                             April 25, 2013
Expires: October 27, 2013


    Delay-Tolerant Networking LTP Convergence Layer (LTPCL) Adapter
                     draft-burleigh-dtnrg-ltpcl-05

Abstract

   This document describes the procedures by which the Licklider
   Transmission Protocol (LTP) is used as a "convergence-layer" protocol
   to convey Delay-Tolerant Networking (DTN) "bundles" between DTN
   nodes.

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

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 October 27, 2013.

Copyright Notice

   Copyright (c) 2013 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



Burleigh                Expires October 27, 2013                [Page 1]

Internet-Draft                   LTPCL                        April 2013


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  LTP Engine Configuration  . . . . . . . . . . . . . . . .   4
     2.2.  Bundle Transmission . . . . . . . . . . . . . . . . . . .   4
     2.3.  Bundle Reception  . . . . . . . . . . . . . . . . . . . .   5
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   5.  Acknowledgment  . . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   This document describes the procedures by which the Licklider
   Transmission Protocol (LTP)) [RFC5326] is used as a "convergence-
   layer" protocol to convey Delay-Tolerant Networking (DTN) Bundle
   Protocol (BP) [RFC5050] "bundles" between DTN nodes.

   BP is designed to enable end-to-end forwarding of a unit of user
   data, encapsulated in a bundle, from one DTN node to another,
   possibly indirectly through the agency of other DTN nodes that relay
   the bundle among themselves toward the destination node.  Conveyance
   of a bundle directly from one node to a second node -- either a relay
   node or the final destination -- is accomplished by the sending
   node's invocation of the transmission services of some underlying
   "convergence-layer" protocol stack.

   A virtually limitless variety of convergence-layer stacks may be
   utilized in support of BP for this purpose, each one achieving inter-
   node bundle flow in a way that is suited to the particular
   communications infrastructure to which both the sending and receiving
   nodes have access.

   Convergence-layer stacks are typically characterized by the highest-
   layer standard protocol in the stack, i.e., the protocol that is
   immediately below BP, which is commonly called the "convergence-layer
   protocol."  To assure interoperability among nodes that utilize a
   common convergence-layer protocol, it is necessary to agree on the
   procedures by which bundles are encapsulated in the protocol data
   units of the convergence-layer protocol and reconstructed from those



Burleigh                Expires October 27, 2013                [Page 2]

Internet-Draft                   LTPCL                        April 2013


   protocol data units upon reception; these procedures are performed by
   a "convergence-layer adapter" that conforms to a standardized
   convergence-layer adapter specification.  (Note that convergence-
   layer adapter standardization is necessary for BP node interoperation
   but is in itself not sufficient: agreement on the configuration of
   protocols at all layers below the convergence-layer protocol is also
   necessary.  Mechanisms for achieving this agreement are beyond the
   scope of this document.)

   This document, the LTP convergence-layer adapter specification,
   defines standard procedures for encapsulating bundles in LTP segments
   and reconstructing bundles from received LTP segments.

2.  Specification

   In general, LTP operates as follows: an LTP "sender" engine generates
   one or more data "segments" from a "block" of client service data and
   conducts a segment transmission "session" that ultimately enables
   reconstruction of the client service data block, from received
   segments, at the "receiver" engine.

   Each block comprises a "red-part" of zero or more octets, to which
   reliable transmission procedures must be applied, immediately
   followed by a "green-part" of zero or more octets, to which only
   "best efforts" transmission procedures need be applied.  The length
   of the red-part of a block is termed the block's "red length."  The
   length of the green-part of a block is termed the block's "green
   length."  The length of a block is the sum of its red length and
   green length.  Each LTP data segment encapsulates part (or all) of
   the red-part of a block or part (or all) of the green-part of a
   block, but never both.  LTP data segments that encapsulate red-part
   data are termed "red segments."  LTP data segments that encapsulate
   green-part data are termed "green segments."

   The LTP specification implicitly mandates the reassembly of the red-
   part of a block into a contiguous byte array from received red
   segments, but it does not mandate the reassembly of the green-part
   from received green segments.  That is, any required reassembly of
   "green" service data is the responsibility of the client service - in
   this case, the LTP convergence-layer adapter.

   Specific procedures for invoking LTP to send bundles are as follows.









Burleigh                Expires October 27, 2013                [Page 3]

Internet-Draft                   LTPCL                        April 2013


2.1.  LTP Engine Configuration

   If the BP node that utilizes a given LTP engine is a member of one or
   more endpoints identified by CBHE-conformant endpoint IDs, then the
   engine number of that LTP engine MAY be identical to the node number
   that is common to those endpoint IDs.  This convention can simplify
   network management in some environments.

   Otherwise, the LTP engine number MAY be interpreted as the node
   number that identifies this node, in any context where some such
   identifying node number may be useful.

2.2.  Bundle Transmission

   The client service data block that the LTP convergence-layer adapter
   (LTPCLA) passes to the LTP sender engine for transmission MUST
   comprise only one or more complete "conformant" bundles.
   ("Conformant" bundles are bundles that conform to the Bundle Protocol
   specification [RFC5050].)  The total length of the block MUST be
   equal to the sum of the lengths of all bundles in the block.

   The client service data block passed to the LTP sender engine by
   LTPCLA MUST contain exactly one of the following:

   o  A single conformant bundle of length L for which only best-efforts
      transmission is intended.  In this case, the red length of the
      block is zero and the green length of the block is L.

   o  A single conformant bundle of length L comprising N bytes (0 < N <
      L) for which reliable transmission is intended followed by (L - N)
      bytes for which only best-efforts transmission is intended.  In
      this case, the red length of the block is N and the green length
      of the block is (L - N).

   o  A single conformant bundle of length L for which reliable
      transmission is intended.  In this case, the red length of the
      block is L and the green length of the block is zero.

   o  The concatenation of two or more conformant bundles for which
      reliable transmission is intended, the sum of whose lengths is L.
      In this case, the red length of the block is L and the green
      length of the block is zero.

   Note that the length of a bundle in a client service data block is
   not constrained in any way by the lengths of the LTP data segments in
   which portions of the block will be transmitted.





Burleigh                Expires October 27, 2013                [Page 4]

Internet-Draft                   LTPCL                        April 2013


   An LTP sender engine MAY impose an upper limit on the red length of a
   block.  Mechanisms by which LTPCLA may determine the block red length
   limit are an implementation matter.

   The client service ID number passed by LTPCLA to LTP with each block
   MUST be 1, signifying that the client service is the Bundle Protocol.

   Upon reception of a transmission-session completion notice from the
   LTP receiver engine, LTPCLA MUST inform the bundle protocol agent
   that data sending procedures with regard to all bundles in the
   corresponding block have concluded.

   Procedures to be performed upon reception of a transmission-session
   cancellation notice from the LTP receiver engine are an
   implementation matter, but in particular LTPCLA MUST NOT inform the
   bundle protocol agent that data sending procedures with regard to all
   bundles in the corresponding block have concluded.  LTPCLA MAY advise
   the bundle protocol agent to repeat steps 2 though 6 of the Bundle
   Forwarding procedure defined in section 5.4 of RFC 5050, for each
   bundle in the block, in this event.

   Procedures to be performed by LTPCLA upon reception of transmission-
   session start notices and initial-transmission completion notices are
   an implementation matter.

2.3.  Bundle Reception

   Upon reception of a red-part reception notice from the LTP receiver
   engine:

   a.  The red-part reception notice's client service data is the
       reassembled red-part of a client service data block.

   b.  If the last byte of the red-part is the last byte of the block,
       LTPCLA MUST initiate bundle reception procedures (complying with
       RFC 5050) once for each conformant bundle in the continuous
       sequence of complete conformant bundles beginning at the first
       octet of the red-part reception notice's client service data (the
       reassembled red-part of the block).  The total length of a
       conformant bundle is the sum of the lengths of all BP blocks (not
       to be confused with LTP blocks) in that bundle, and the length of
       each conformant BP block can always be determined by inspection
       of the initial octets of the block.  Inability to determine the
       length of a BP block in the red-part of an LTP block signifies
       that the immediately prior complete bundle, if any, was the last
       conformant bundle in the block's red-part; in this case, LTPCLA
       MUST discard all data in the block following that last conformant
       bundle.



Burleigh                Expires October 27, 2013                [Page 5]

Internet-Draft                   LTPCL                        April 2013


   c.  Otherwise, LTPCLA MUST interpret the red-part as the initial N
       bytes of a single bundle that is being conveyed via this block,
       where N is the length of the red-part.  LTPCLA SHOULD retain
       these N bytes of data for the purpose of reconstructing the
       bundle; alternatively, LTPCLA MAY discard the entire red-part.
       The latter option is preferable when there is a non-negligible
       probability that subsequent arrival of green-part segments will
       not occur in time to prevent block reassembly storage resource
       consumption from exhausting available storage, as might result
       from some kinds of denial-of-service attack as discussed in
       section 4.

   Upon reception of a green-part segment arrival notice from the LTP
   receiver engine:

   a.  LTPCLA SHOULD discard all data retained for the purpose of
       reconstructing the bundle(s) encapsulated in all other blocks for
       which green data are still unreceived.  Green segments nominally
       arrive in transmission order, and they are never retransmitted,
       so the arrival of a green segment for one block nominally
       indicates that no further green segments will be received for any
       other block that is still pending reassembly.

   b.  The "expected offset" for the first green segment received for
       any block is the red length of the block; the expected offset for
       every other green segment received for a block is the sum of the
       offset and length of whichever previously received green segment
       for that block had the largest offset.

       *  When a green-part segment arrival notice indicates an offset
          that is less than the expected offset for that segment, the
          notice's client service data MAY be discarded or it MAY be
          retained for the purposes of reconstructing the bundle
          encapsulated in the affected block, an implementation
          decision.

       *  When a green-part segment arrival notice indicates an offset
          that is equal to the expected offset for that segment, the
          notice's client service data MUST be retained for the purposes
          of reconstructing the bundle encapsulated in the affected
          block.

       *  When a green-part segment arrival notice indicates an offset
          that is greater than the expected offset for that segment, the
          notice's client service data MUST be retained for the purposes
          of reconstructing the bundle encapsulated in the affected
          block and the fact that a gap in client service data reception
          was detected SHOULD be reported if and when the bundle



Burleigh                Expires October 27, 2013                [Page 6]

Internet-Draft                   LTPCL                        April 2013


          encapsulated in that block is received.  The manner in which
          this information is reported is an implementation matter.

   c.  When a green-part segment arrival notice indicates that the last
       byte of the notice's client service data is the last byte of the
       block, LTPCLA MUST initiate bundle reception procedures
       (complying with RFC 5050) for the bundle that is encapsulated in
       this block (regardless of whether or not gaps in the block were
       detected) and then MUST discard this notice's client service data
       and all retained data for this block.

   Upon reception of a reception-session cancellation notice, LTPCLA
   MUST discard all data retained for the purpose of reconstructing the
   bundle conveyed in the affected block.

   Procedures to be performed by LTPCLA upon reception of reception-
   session start notices are an implementation matter.

3.  IANA Considerations

   This document has no IANA considerations.

4.  Security Considerations

   As noted in section 2.3 above, LTPCLA reception of a partially-red
   bundle introduces the possibility of a denial-of-service attack.  An
   attacker could transmit an unlimited number of LTP red segments, each
   of which is flagged as end-of-red-part but not end-of-block, without
   ever sending any green segments at all.  If the attacked node chooses
   to retain all of these completely received red-parts in hopes of
   reassembling the original bundles that they are apparently pieces of,
   without ever receiving any green segments that would cause the
   retained data to be discarded, it may eventually exhaust its storage
   resources and cease operation.  LTP authentication as documented in
   [RFC5327] could reduce the chance that such an attack might succeed,
   making partially-red bundle reception safer.

   Otherwise, LTPCLA introduces no new security considerations beyond
   those discussed in the DTN Bundle Protocol and Licklider Transmission
   Protocol specifications.

5.  Acknowledgment

   Stephen Farrell's and Keith Scott's many helpful observations on this
   specification are gratefully acknowledged.

6.  Normative References




Burleigh                Expires October 27, 2013                [Page 7]

Internet-Draft                   LTPCL                        April 2013


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, RFC
              3986, January 2005.

   [RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", RFC 5050, November 2007.

   [RFC5326]  Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
              Transmission Protocol - Specification", RFC 5326,
              September 2008.

   [RFC5327]  Farrell, S., Ramadas, M., and S. Burleigh, "Licklider
              Transmission Protocol - Security Extensions", RFC 5327,
              September 2008.

Author's Address

   Scott Burleigh
   Jet Propulsion Laboratory, California Institute of Technology
   4800 Oak Grove Drive, m/s 301-490
   Pasadena, CA  91109
   USA

   Phone: +1 818 393 3353
   Email: Scott.C.Burleigh@jpl.nasa.gov






















Burleigh                Expires October 27, 2013                [Page 8]