DTN Research Group D. Kutscher
Internet-Draft K. Loos
Intended status: Experimental TZI
Expires: October 18, 2007 J. Greifenberg
Dampsoft GmbH
April 16, 2007
Uni-DTN: A DTN Convergence Layer Protocol for Unidirectional Transport
draft-kutscher-dtnrg-uni-clayer-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 October 18, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Kutscher, et al. Expires October 18, 2007 [Page 1]
Internet-Draft DTN CL for Unidirectional Transport April 2007
Abstract
This document specifies Uni-DTN, a DTN convergence layer protocol for
unidirectional transports. The protocol is based on FLUTE (File
Delivery over Unidirectional Transport).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this Document . . . . . . . . . . . . . . 5
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6
3.1. FLUTE . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Usage of FLUTE . . . . . . . . . . . . . . . . . . . . . . 7
4. Requirements for Uni-DTN Senders and Receivers . . . . . . . . 8
4.1. Usage of FLUTE FDT Fields in Uni-DTN . . . . . . . . . . . 8
4.1.1. Usage of Existing FDT File Element Attributes . . . . 8
4.2. FDT Instance Extension Elements . . . . . . . . . . . . . 10
5. Recommended Sender Behavior . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Kutscher, et al. Expires October 18, 2007 [Page 2]
Internet-Draft DTN CL for Unidirectional Transport April 2007
1. Introduction
This document describes the FLUTE-based DTN convergence layer
protocol for unidirectional transport. DTN (Delay Tolerant
Networking) is an end-to-end architecture providing communications in
and/or through highly stressed environments, including those with
intermittent connectivity, long and/or variable delays, and high bit
error rates. The DTN architecture is specified in [RFC4838].
Unidirectional transport refers to communication over networks
without any return channel. Unidirectional communication is relevant
to many DTN communications scenarios such as satellite-based
communications or terrestrial broadcast communications, i.e.,
environments that are typically classified as challenged networks.
In unidirectional networks, reliability and flow control cannot be
achieved by return-channel-based mechanisms. It should be noted that
this applies to both unicast and multicast networks. Reliable
multicast transport protocols often apply techniques such as forward
error correction (FEC) and periodic retransmissions to increase
reliability without receiver-feedback. For receiver-based rate-
control, mechanisms such as layered coding may be applied, where
receivers can select an appropriate aggregate reception rate by
receiving on a (sub) set of channels. In networks that support
appropriate multicast routing and signaling this can also be applied
to achieve congestion control.
This document specifies the transmission of DTN bundles over a
specific multicast transport protocol: FLUTE (File Delivery over
Unidirectional Transport), which is specified in [RFC3926]. FLUTE is
a protocol for the unidirectional delivery of files over the
Internet. It is a reliable multicast protocol that builds on
Asynchronous Layered Coding (ALC), a protocol building block for
massively scalable multicast distribution. ALC is specified in
[RFC3450]. Whereas ALC specifies the transport of arbitrary binary
objects, FLUTE specifies file delivery sessions on top of ALC in
conjunction with in-band signaling of the transport parameters, the
file properties, and details about the multiplexing of multiple files
within a session. ALC is a protocol instantiation of Layered Coding
Transport building block (LCT) [RFC3451].
Note that this specification defines a DTN convergence layer for
undirectional transport over both unicast and multicast networks.
The rest of this specification is structured as follows: Section 3
provides an overview of the usage of FLUTE within Uni-DTN and
Section 4 provides the actual specification of sender and receiver
requirements. Section 5 describes additional (optional)
recommendations for sender behavior and Section 6 discusses security
Kutscher, et al. Expires October 18, 2007 [Page 3]
Internet-Draft DTN CL for Unidirectional Transport April 2007
considerations.
Kutscher, et al. Expires October 18, 2007 [Page 4]
Internet-Draft DTN CL for Unidirectional Transport April 2007
2. Conventions used in this Document
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].
Kutscher, et al. Expires October 18, 2007 [Page 5]
Internet-Draft DTN CL for Unidirectional Transport April 2007
3. Overview of Operation
Uni-DTN can be applied to several DTN communication scenarios. FLUTE
itself can be applied to unidirectional transport in both IP unicast
and IP multicast networks. The DTN architecture also has a notion of
multicast delivery for DTN bundles, i.e., a DTN endpoint identifier
(EID) may to refer to one or more DTN nodes. It should be noted
that, in principle, the notions of FLUTE multicast and DTN multicast
are orthogonal to each other, i.e., it is possible to forward a DTN
bundle with a singleton destination over a multicast FLUTE channel,
but it also possible to treat a unicast FLUTE channel as a point-to-
point DTN link that is used to convey both unicast and multicast DTN
bundles. This specification does not mandate a specific usage of
FLUTE with respect to unicast/multicast distribution or to the usage
of Uni-DTN as a convergence layer link in DTN scenarios.
3.1. FLUTE
FLUTE is a file delivery protocol for unidirectional transport. From
the underlying ALC/LCT building blocks, FLUTE inherits the concepts
of a session, which is named "file delivery session" in FLUTE. As
defined by [RFC3926] a session consists of a set of logically grouped
ALC/LCT channels associated with a single sender sending packets with
ALC/LCT headers for one or more objects. An ALC/LCT channel is
defined by the combination of a sender and an address associated with
the channel by the sender. For FLUTE, the objects transmitted in
ALC/LCT sessions are either files or File Delivery Tables (FDTs), a
concept introduced by FLUTE for specifying properties of the
transmitted files (or the delivery itself) such as file size, FEC
parameter specifications, aggregate sending rate, file
identification, MIME type etc. Multiple files may be transmitted in
a single session. This means, the FDT of a FLUTE session is a set of
description entries for the files to be delivered in a corresponding
FLUTE session. Within a FLUTE file delivery session the FDT is
transmitted as FDT Instances, i.e., subsets of the complete FDT.
Each FDT Instance contains one more complete file description entries
of the FDT.
An FDT Instance is an XML element named "FDT-Instance" that may
provide zero, one, or multiple "File" child elements. The file
properties are specified as XML attributes of these "File" elements.
Please refer to [RFC3926] for the complete schema definition and a
sample FDT. The attribute set of "File" elements is extensible,
e.g., for specifying additional properties that are required for
specific applications. The Uni-DTN convergence layer leverages this
extension mechanisms for specific attributes for the convergence
layers protocol services. These extension are specified in
Section 4.1.
Kutscher, et al. Expires October 18, 2007 [Page 6]
Internet-Draft DTN CL for Unidirectional Transport April 2007
3.2. Usage of FLUTE
The Uni-DTN convergence layer is based on FLUTE's notion of file
delivery sessions. A Uni-DTN CL link is mapped to a FLUTE file
delivery session, and DTN bundles are delivered as files in these
sessions.
Especially in multicast scenarios, FLUTE is typically used in a
periodic transmission mode, i.e., files are transmitted more than
once in order to give late-joiners in a session the chance to receive
them completely, and also to compensate for transmission problems.
It is expected that Uni-DTN will be used in a similar fashion, i.e.,
for long-lived sessions where files are periodically transmitted.
The number of retransmissions as well as other FLUTE and ALC/LCT
parameters such as sending rate, FEC parameters etc. are completely
application specific and not specified in this document.
ALC/LCT has a concept of channels and congestion control. A FLUTE
session can be constituted of one or multiple channels, with and
without ALC-provided congestion control. This specification imposes
no further regulations how FLUTE and Uni-DTN is used with respect to
these capabilities, i.e., a Uni-DTN convergence layer can be
configured to use one or multiple channels -- this decision is
application dependent. It should be noted though that both sender
and receiver must have the same configuration of the FLUTE session.
This configuration is typically conveyed out of band, and it may be
represented in a description format such as the SDP descriptors for
FLUTE specified in [I-D.mehta-rmt-flute-sdp]. This document does not
specify the format and the transport of these configuration
specifications.
It should be noted that, although Uni-DTN provides a unidirectional
DTN bundle transport only, DTN transport services such as custody
transfer that rely on bi-directional communications, are not
necessarily excluded in DTN scenarios that use Uni-DTN links. It
depends on the specific connectivity graph in a given DTN scenario,
e.g., on the existence of DTN paths between custodians, whether
custody transfer can be provided. In other words, the Uni-DTN
convergence layer is agnostic to bundle layer services.
Kutscher, et al. Expires October 18, 2007 [Page 7]
Internet-Draft DTN CL for Unidirectional Transport April 2007
4. Requirements for Uni-DTN Senders and Receivers
This section specified requirements for Uni-DTN sender and receivers.
First, we specify general sender and receiver behavior, and in
Section 4.1 and Section 4.2 we specify required FLUTE FDT attributes.
Each bundle MUST be sent as one file in a FLUTE session.
A sender can choose to send a single bundle multiple times, e.g.,
for periodic retransmissions in multicast scenarios. When a
bundle has expired, i.e., when the current time is greater than
the bundle's creation time plus its lifetime as specified in the
primary bundle block as specified in [I-D.irtf-dtnrg-bundle-spec],
transmission of the bundle MUST be stopped. Ongoing transmission
of expired bundles MUST be canceled.
If a DTN bundle implementation provides multiple Uni-DTN links,
bundles with the same destination EID SHOULD be sent over the same
FLUTE session.
Senders and receivers MUST support the FDT attributes specified in
Section 4.1 and Section 4.2, according to the given requirements
levels specified in those sections.
4.1. Usage of FLUTE FDT Fields in Uni-DTN
This section specifies the usage of the FLUTE FDT. In particular, it
is specified, how the existing FDT File elements are used by Uni-DTN
and which extension elements are used. We distinguish between
REQUIRED and OPTIONAL elements. All elements described here MUST be
supported by receivers. The specified requirement level given in the
attribute specification refers to sender requirements.
4.1.1. Usage of Existing FDT File Element Attributes
[RFC3926] specifies the following File element attributes that MUST/
SHOULD be used in FDT File element instances for Uni-DTN:
TOI
The Transmission Object Identifier is an identifier for the file
(the object) transmitted over ALC/LCT. It MUST be present. The
TOI MUST be unique in a delivery session, and values greater than
0 are used for file objects. This specification does not impose
any particular requirement on the generation of TOIs beyond
[RFC3926].
Kutscher, et al. Expires October 18, 2007 [Page 8]
Internet-Draft DTN CL for Unidirectional Transport April 2007
Content-Location
The Content-Location attribute is used for identifying the file
uniquely. It MUST be present. It MUST be a URI [RFC3986]. For
Uni-DTN, the Content-Location MUST be a unique identifier for all
DTN bundles sent from the FLUTE sender. The identifier MUST be
unique across all Uni-DTN convergence layers links of this sender,
i.e., unique across all FLUTE sessions. The identifier SHOULD be
constructed as follows:
uni-dtn://<seid>/<cts>/<cts-seq-num>/<frag-offset>
The URI scheme MUST be set to uni-dtn.
<seid> MUST be set to the DTN EID of the originator of the
bundle.
<cts> MUST be set to the bundle Creation Timestamp as defined
by [I-D.irtf-dtnrg-bundle-spec].
<cts-seq-num> MUST be to the bundle Creation Timestamp Sequence
Number as defined by [I-D.irtf-dtnrg-bundle-spec].
<frag-offset> MUST be set to the bundle Fragment Offset as
defined by [I-D.irtf-dtnrg-bundle-spec]. If the Fragment
Offset is not present in the bundle, the leading slash and the
<fragment-offset> MUST be omitted from the Content-Location
attribute.
The following characters of the Content-Location URI MUST be
percent-encoded as specified by [RFC3986]: ":", "/", "?", "#",
"[", "]", "@" "!", "$", "&", "'", "(", ")" , "*", "+", ",",
";", "=". This is the "reserved" character class as specified
by [RFC3986].
Content-Type
The Content-Type attribute is defined as optional in [RFC3926].
However, for Uni-DTN FLUTE sessions it MUST be present for all
files that represent DTN bundles. It MUST be set to "application/
x-dtn".
Kutscher, et al. Expires October 18, 2007 [Page 9]
Internet-Draft DTN CL for Unidirectional Transport April 2007
Content-Length
The Content-Length attribute is defined as optional in [RFC3926].
However, for Uni-DTN FLUTE sessions it SHOULD be present for all
files that represent DTN bundles. If it is present, it MUST be
set to the length of the transmitted bundle fragment.
4.2. FDT Instance Extension Elements
In addition to the existing FDT file attributes specified by
[RFC3926], this document specifies the following extension attributes
that MUST/SHOULD be used in FDT File element instances for Uni-DTN.
We distinguish between REQUIRED and OPTIONAL elements. All elements
described here MUST be supported by receivers. The specified
requirement level given in the attribute specification refers to
sender requirements.
Destination-EID
type: xs-string
The Destination-EID attribute is used to specify the destination
endpoint identifier for the DTN bundle. It MUST be present and
MUST take the value of the complete destination endpoint
identifier (scheme name and scheme specific part) as defined by
[I-D.irtf-dtnrg-bundle-spec].
Router-EID
type: xs-string
The Router-EID attribute is used to specify the endpoint
identifier of the bundle router that is sending the bundle over
the Uni-DTN link. Uni-DTN senders SHOULD set this attribute to
the complete value of their endpoint identifier (scheme name and
scheme specific part).
XML-Schema definitions for these attributes will be provided in a
future version of this document.
Kutscher, et al. Expires October 18, 2007 [Page 10]
Internet-Draft DTN CL for Unidirectional Transport April 2007
5. Recommended Sender Behavior
The DTN bundle specification [I-D.irtf-dtnrg-bundle-spec] defines a
two bit priority field with three service classes ("bulk", "normal",
and "expedited") that indicate a bundle's relative priority. Sender
implementations SHOULD map these priorities to bandwidth fractions
for different files objects in order to achieve a differentiation in
sending rates. However since different sending rates per file is
unspecified within FLUTE, such a behavior is FLUTE sender
implementation-specific and hence OPTIONAL for Uni-DTN
implementations.
Kutscher, et al. Expires October 18, 2007 [Page 11]
Internet-Draft DTN CL for Unidirectional Transport April 2007
6. Security Considerations
The security considerations of FLUTE [RFC3926] also apply to Uni-DTN.
In addition to these considerations, it should be noted that
receivers cannot be sure that a received object that has been
transferred over a Uni-DTN link is really a DTN bundle, even if so
signaled in the FDT Instance attribute. The specification provided
in this document does not provide any support against malicious
senders, man-in-the-middle attacks etc. Some of these concerns may
be mitigated through the use of the Bundle Security Protocols
[I-D.irtf-dtnrg-bundle-security]. The Bundle Authentication Header
can be used to secure the exchange of bundles between DTN nodes.
Kutscher, et al. Expires October 18, 2007 [Page 12]
Internet-Draft DTN CL for Unidirectional Transport April 2007
7. IANA Considerations
This document has no actions for IANA.
Kutscher, et al. Expires October 18, 2007 [Page 13]
Internet-Draft DTN CL for Unidirectional Transport April 2007
8. References
8.1. Normative References
[I-D.irtf-dtnrg-bundle-security]
Symington, S., "Bundle Security Protocol Specification",
draft-irtf-dtnrg-bundle-security-02 (work in progress),
October 2006.
[I-D.irtf-dtnrg-bundle-spec]
Scott, K. and S. Burleigh, "Bundle Protocol
Specification", draft-irtf-dtnrg-bundle-spec-08 (work in
progress), December 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and J.
Crowcroft, "Asynchronous Layered Coding (ALC) Protocol
Instantiation", RFC 3450, December 2002.
[RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley,
M., and J. Crowcroft, "Layered Coding Transport (LCT)
Building Block", RFC 3451, December 2002.
[RFC3926] Paila, T., Luby, M., Lehtonen, R., Roca, V., and R. Walsh,
"FLUTE - File Delivery over Unidirectional Transport",
RFC 3926, October 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, April 2007.
8.2. Informative References
[I-D.mehta-rmt-flute-sdp]
Mehta, H., "SDP Descriptors for FLUTE",
draft-mehta-rmt-flute-sdp-05 (work in progress),
January 2006.
Kutscher, et al. Expires October 18, 2007 [Page 14]
Internet-Draft DTN CL for Unidirectional Transport April 2007
Authors' Addresses
Dirk Kutscher
TZI
Postfach 330440
Bremen 28334
Germany
Email: dku@tzi.org
Kevin Loos
TZI
Postfach 330440
Bremen 28334
Germany
Email: logic@tzi.org
Janico Greifenberg
Dampsoft GmbH
Vogelsang 1
Damp 24351
Germany
Email: jgre@jgre.org
Kutscher, et al. Expires October 18, 2007 [Page 15]
Internet-Draft DTN CL for Unidirectional Transport April 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Kutscher, et al. Expires October 18, 2007 [Page 16]