Network Working Group S. Burleigh Internet-Draft Jet Propulsion Laboratory, Intended status: Experimental California Institute of Expires: July 2, 2010 Technology December 29, 2009 Delay-Tolerant Networking LTP Convergence Layer (LTPCL) Adapter draft-burleigh-dtnrg-ltpcl-00 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 to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 2, 2010. Copyright Notice Burleigh Expires July 2, 2010 [Page 1] Internet-Draft LTPCL December 2009 Copyright (c) 2009 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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Specification . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. LTP Engine Configuration . . . . . . . . . . . . . . . . . 4 2.2. Bundle Transmission . . . . . . . . . . . . . . . . . . . . 4 2.3. Bundle Reception . . . . . . . . . . . . . . . . . . . . . 6 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. Normative References . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Burleigh Expires July 2, 2010 [Page 2] Internet-Draft LTPCL December 2009 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 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 Burleigh Expires July 2, 2010 [Page 3] Internet-Draft LTPCL December 2009 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 must 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. For this reason, the service data in each green LTP data segment must be self-identifying so that the client service can either ingest the service data immediately or else use it in the reassembly of larger client service data objects that it can ingest. Specific procedures for invoking LTP to send bundles are as follows. 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 MUST be identical to the node number that is common to those endpoint IDs. 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. Burleigh Expires July 2, 2010 [Page 4] Internet-Draft LTPCL December 2009 Reliable transmission MAY be intended for none, some, or all of the bundles in a client service data block passed to the LTP sender engine by LTPCLA. Within each block, all bundles for which reliable transmission is intended -- termed "red" bundles for the purposes of this specification -- MUST occupy the block's red-part; all bundles for which best-efforts transmission is intended -- termed "green" bundles -- MUST occupy the block's green-part. The "red length" passed by LTPCLA to LTP with each block MUST be the sum of the lengths of all red bundles in the block. An LTP sender engine MAY impose an upper limit on red length. Mechanisms by which LTPCLA may determine maximum red length are an implementation matter. LTPCLA MAY request that the sending LTP engine segment the red-part of the block on bundle boundaries, i.e., it may request that the the first octet of each red bundle in the block occupy the first service data octet of a red segment. Note that a single red bundle MAY occupy the service data of multiple red segments. The requirement that green segment service data be self-identifying to the client service -- in this case, the Bundle Protocol -- implies that the service data of each green segment must be a single complete bundle, even if possibly a BP "fragment." Each green bundle in the block MUST therefore be small enough to fit inside the service data of a single LTP data segment, and LTPCLA MUST require that the sending LTP engine encapsulate each green bundle within the service data of a single LTP data segment. Mechanisms by which LTPCLA may determine the maximum green bundle size for a given LTP sender engine 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 cancellation notice from the LTP receiver engine, LTPCLA MAY initiate the custody transfer failure procedures of the BP node once for each bundle in the block for which custody transfer was requested. This mechanism enables custodial bundles to be reforwarded by the BP node in the event that the LTPCLA procedures fail to convey them to the receiver engine's BP node. Procedures to be performed by LTPCLA upon reception of transmission- session start notices, initial-transmission completion notices, and transmission-session completion notices are an implementation matter. Burleigh Expires July 2, 2010 [Page 5] Internet-Draft LTPCL December 2009 2.3. Bundle Reception Upon reception of a red-part reception notice from the LTP receiver engine, LTPCLA MUST initiate the bundle reception procedures of the BP node once for each bundle in the continuous sequence of conformant bundles beginning at the first octet of the red-part reception notice's client service data (the reassembled red-part of the block). LTPCLA MUST discard all client service data following the last octet of the last bundle in the continuous sequence of conformant bundles beginning at the first octet. Note that 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 BP block can be determined by inspection of the initial octets of the block. Inability to determine the length of a BP block signifies that the immediately prior complete bundle, if any, was the last bundle in the continuous sequence of conformant bundles beginning at the first octet of the red-part reception notice's client service data, and all subsequent data must be discarded. Upon reception of a green-part segment arrival notice from the LTP receiver engine, LTPCLA MUST initiate the bundle reception procedures of the BP node exactly once, for the single conformant bundle (if any) beginning at the first octet of the green-part segment arrival notice's client service data. LTPCLA MUST discard all client service data following the last octet of the conformant bundle beginning at the first octet (if any). Procedures to be performed by LTPCLA upon reception of reception- session start notices and reception-session cancellation notices are an implementation matter. 3. IANA Considerations This document has no IANA considerations. 4. Security Considerations LTPCLA introduces no new security considerations beyond those discussed in the DTN Bundle Protocol and Licklider Transmission Protocol specifications. Burleigh Expires July 2, 2010 [Page 6] Internet-Draft LTPCL December 2009 5. Normative References [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. 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 July 2, 2010 [Page 7]