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:///// The URI scheme MUST be set to uni-dtn. MUST be set to the DTN EID of the originator of the bundle. MUST be set to the bundle Creation Timestamp as defined by [I-D.irtf-dtnrg-bundle-spec]. MUST be to the bundle Creation Timestamp Sequence Number as defined by [I-D.irtf-dtnrg-bundle-spec]. 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 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]