[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

DTNRG                                                           H. Kruse
Internet-Draft                                              S. Ostermann
Intended status: Experimental                            Ohio University
Expires: May 23, 2009                                  November 19, 2008


      UDP Convergence Layers for the DTN Bundle and LTP Protocols
                     draft-irtf-dtnrg-udp-clayer-00

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 May 23, 2009.

Abstract

   This document specifies the use of the User Datagram Protocol (UDP)
   as a method for transporting DTN protocol data over the Internet.
   The specification covers both the use of UDP as a convergence layer
   for the Bundle Protocol as well as the use of UDP to carry LTP
   segments.










Kruse & Ostermann         Expires May 23, 2009                  [Page 1]


Internet-Draft       UDP Convergence Layers for DTN        November 2008


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  General UDP Considerations  . . . . . . . . . . . . . . . . . . 3
     2.1.  UDP Checksums are Required  . . . . . . . . . . . . . . . . 3
     2.2.  Congestion Control  . . . . . . . . . . . . . . . . . . . . 3
     2.3.  How and Where to Deal with Fragmentation  . . . . . . . . . 4
     2.4.  Keep Alive Option . . . . . . . . . . . . . . . . . . . . . 5
   3.  Bundle Protocol over UDP Convergence Layer  . . . . . . . . . . 5
   4.  LTP over UDP Convergence Layer  . . . . . . . . . . . . . . . . 5
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8
































Kruse & Ostermann         Expires May 23, 2009                  [Page 2]


Internet-Draft       UDP Convergence Layers for DTN        November 2008


1.  Introduction

   Delay/Disruption Tolerant Network (DTN) communication protocols
   include the Bundle Protocol described in RFC 5050 [RFC5050], which
   provides reliable transmission of application data blocks (bundles)
   with optional intermediate custody transfer, and the Licklider
   Transport Protocol (LTP), RFCs 5325 [RFC5325], 5326 [RFC5326], and
   5327 [RFC5327] which can be used to transmit bundles reliably and
   efficiently over a point to point link.  It is often desirable to
   test these protocols over Internet Protocol links.
   draft-irtf-dtnrg-tcp-clayer [I-D.irtf-dtnrg-tcp-clayer] defines a
   method for transporting bundles over TCP.  This draft specifies the
   convergence layer for transmitting either bundles or LTP blocks over
   UDP.

1.1.  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].


2.  General UDP Considerations

2.1.  UDP Checksums are Required

   Both the core bundle protocol specification and core LTP
   specification assume that they are transmitting over an erasure
   channel, i.e. a channel that either delivers packets correctly or not
   at all.  The UDP CL transmitter therefore MUST NOT disable UDP
   checksums, and the UDP CL receiver MUST NOT disable checking of
   received UDP checksums.

   Even when UDP checksums are enabled a small probablity of UDP packet
   corruption remains.  In some environments it may be acceptable for
   LTP or the bundle protocol to occasionally receive corrcupted input.
   In general, however, a UDP CL implementation SHOULD use optional
   security extensions available in the bundle protocol or LTP to
   protect against message corruption (see the protocol specific
   sections below).

2.2.  Congestion Control

   UDP operates on a packet by packet, best effort delivery basis.  It
   provides no congestion control.  When the bundle protocol or LTP are
   operated over UDP, the lack of congestion control can interfere with
   other traffic in the network, and will be particularly harmful to
   traffic that does obey congestion control.  If the UDP CL is used to



Kruse & Ostermann         Expires May 23, 2009                  [Page 3]


Internet-Draft       UDP Convergence Layers for DTN        November 2008


   send more than a very small number of packets at a time, it either
   SHOULD NOT be used outside an isolated network, or it MUST implement
   congestion control procedures as outlined in RFC 5405.

2.3.  How and Where to Deal with Fragmentation

   The bundling protocol allows bundles with sizes limited only by node
   resource constraints.  In IPv4, the maximum size of a UDP datagram is
   nearly 64KB.  In IPv6, when using jumbograms [RFC2675], UDP datagrams
   can be up to 4GB in size [RFC2147].  It is well understood that
   sending large IP datagrams that must be fragmented by the network has
   enormous efficiency penalties [Kent88].  The primary efficiency
   penalty is increased loss probability.  When a large datagram is
   broken into a number of fragments, the original datagram can only be
   recreated if all the fragments arrive at the ultimate destination for
   reassembly.  When transmitted over a network with a packet loss
   probability of 2%, for example, a single, unfragmented datagram will
   arrive with probability 98%; a large datagram fragmented into 10
   fragments will have all of its fragments arrive with probability
   98%**10, giving a datagram arrival probability of only 81.7%.  The
   higher-level protocol using UDP for delivery can retransmit lost UDP
   datagrams, but cannot retransmit lost IP datagram fragments.
   Therefore, retransmitting large, lost datagrams because of a small
   number of missing fragments can require many more packets than
   retransmitting a number of smaller, unfragmented datagrams because
   only the missing pieces need to be retransmitted.  The other
   efficiency penalty paid by fragmentation that would be significant
   for DTN is the resources (time, complexity, and memory) required for
   IP reassembly.

   When an LTP CL is using UDP for datagram delivery, it SHOULD NOT
   create segments that will result in UDP datagrams that will need to
   be fragmented, as discussed above.  When using UDP directly as a CL,
   the software SHOULD NOT directly encapsulate large bundles into large
   UDP datagrams that would need to be fragmented, as discussed above.
   In the latter case, the bundle protocol specification provides a
   bundle fragmentation concept [RFC5050] that allows a large bundle to
   be divided into bundle fragments, each of which SHOULD be created of
   sufficiently small size that it can then be encapsulated into a UDP
   datagram that will not need to be fragmented.

   Without information from elsewhere in the networking stack about path
   MTU, the protocol can assume a minimum path MTU that would allow 512
   bytes of UDP data [RFC0791] over IPv4 or (1280-(UDP and IP header
   sizes)) bytes [RFC1883] over IPv6.






Kruse & Ostermann         Expires May 23, 2009                  [Page 4]


Internet-Draft       UDP Convergence Layers for DTN        November 2008


2.4.  Keep Alive Option

   It may be desirable for a UDP CL to send "keep-alive" packets during
   extended idle periods.  This may be needed to refresh a contact table
   entry at the destination, or to maintain an address mapping in a NAT
   or a dynamic access rule in a firewall.  Therefore, a UDP CL MAY send
   a UDP packet containing exactly 4 octets of zero bits.  A UDP CL
   receiving such a packet MUST discard this packet; the receiving CL
   may then perform local maintenance of its state tables, these
   maintenance functions are not covered in this draft.  Note that
   "real" CL packets will always contain more than 4 octets of
   information (either the bundle or the LTP header); keep-alives will
   therefore never be mistaken for actual data packets.


3.  Bundle Protocol over UDP Convergence Layer

   In general, the use of the bundle protocol over a UDP CL is
   discouraged.  Bundles can be of (almost) arbitrary length, and the
   bundle protocol does not include an effective retransmission
   mechanism.  Whenever possible the bundle protocol SHOULD be operated
   over the TCP Convergence Layer or over LTP.

   If a UDP CL is used for transmission of bundles, every UDP packet
   MUST contain exactly one bundle or four zero octets as a keep-alive.
   The UDP CL SHOULD use avalailable operating system services to obtain
   the largest supported UDP packet size, and MAY use the default UDP
   packet size limit if path-specific information is not available.  For
   bundles that are too large for the supported UDP packet size, the
   bundle protocol fragmentation process SHOULD be used transmit the
   large bundle.

   The UDP CL for bundle protocol use SHOULD use the IANA assigned port
   4556/UDP; the use of other port numbers is implementation specific.


4.  LTP over UDP Convergence Layer

   LTP is designed as a point to point protocol within DTN, and it
   provides intrinsic acknowledgement and retransmission facilities.
   Transmission of LTP over a UDP CL is therefore the most appropriate
   choice.  When a UDP CL is used to transmit LTP data, every UDP packet
   MUST contain exactly one LTP segment or four zero octets as a keep-
   alive.  The UDP CL SHOULD use avalailable operating system services
   to obtain the largest supported UDP packet size, and MAY use the
   default UDP packet size limit if path-specific information is not
   available.  LTP MUST perform segmentation in such a way as to insure
   that every LTP segments fits into a UDP packet.



Kruse & Ostermann         Expires May 23, 2009                  [Page 5]


Internet-Draft       UDP Convergence Layers for DTN        November 2008


   The UDP CL for LTP SHOULD use the IANA assigned port 1113/UDP; the
   use of other port numbers is implementation specific.


5.  Acknowledgements


6.  IANA Considerations

   This memo includes no request to IANA.


7.  Security Considerations

   This memo describes the use of UDP to transport DTN applications
   data.  Hosts may be in a position of having to accept and process UDP
   packet from unknown sources; the DTN Endpoint ID can be discovered
   only after the bundle has been retrieved from the UDP packet.  Hosts
   SHOULD use authentication methods available in the DTN specifications
   to prevent malicious hosts from inserting unknown data into the
   application.

   Hosts need to listen for and process UDP data on the known LTP or
   bundle protocol ports.  A denial of service scenario exists where a
   malicious host send UDP packets at a high rate, forcing the receiving
   hosts to use its resources to process and attempt to authenticate
   these data.  Whenever possible, hosts SHOULD use IP address filtering
   to limit the origin of packets to known hosts.


8.  References

8.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC1883]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 1883, December 1995.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2147]  Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147,
              May 1997.

   [RFC2675]  Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
              RFC 2675, August 1999.



Kruse & Ostermann         Expires May 23, 2009                  [Page 6]


Internet-Draft       UDP Convergence Layers for DTN        November 2008


   [RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", RFC 5050, November 2007.

   [RFC5325]  Burleigh, S., Ramadas, M., and S. Farrell, "Licklider
              Transmission Protocol - Motivation", RFC 5325,
              September 2008.

   [RFC5326]  Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
              Transmission Protocol - Specification", RFC 5326,
              September 2008.

   [RFC5327]  Farrell, S., Ramadas, M., and S. Burleigh, "Licklider
              Transmission Protocol - Security Extensions", RFC 5327,
              September 2008.

8.2.  Informative References

   [I-D.irtf-dtnrg-tcp-clayer]
              Demmer, M. and J. Ott, "Delay Tolerant Networking TCP
              Convergence Layer Protocol",
              draft-irtf-dtnrg-tcp-clayer-02 (work in progress),
              November 2008.

   [Kent88]   Kent, C. and J. Mogul, "Fragmentation considered
              harmful.", 1988, <http://doi.acm.org/10.1145/55482.55524>.


Authors' Addresses

   Hans Kruse
   Ohio University
   292 Lindley Hall
   Athens, OH  45701
   United States

   Phone: +1 740 593 4891
   Email: kruse@ohiou.edu


   Shawn Ostermann
   Ohio University
   Stoecker Engineering Center
   Athens, OH  45701
   United States

   Phone: +1 740 593 1566
   Email: ostermann@eecs.ohiou.edu




Kruse & Ostermann         Expires May 23, 2009                  [Page 7]


Internet-Draft       UDP Convergence Layers for DTN        November 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.











Kruse & Ostermann         Expires May 23, 2009                  [Page 8]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/