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]
