One document matched: draft-burleigh-dtnrg-ltpcl-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 14:02:33 |