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]