DTNRG H. Kruse
Internet-Draft S. Jero
Intended status: Experimental S. Ostermann
Expires: March 5, 2013 Ohio University
Sep 2012
Datagram Convergence Layers for the DTN Bundle and LTP Protocols
draft-irtf-dtnrg-dgram-clayer-00
Abstract
This document specifies the preferred method for transporting DTN
protocol data over the Internet using datagrams. The specification
covers convergence layers for the Bundle Protocol as well as the
transportation of LTP segments. UDP and DCCP are the candidate
datagram protocols discussed. UDP can only be used on a local
network, or in cases where the DTN node implements explicit
congestion control. DCCP does address the congestion control
problem; however, the availability of implementations is limited.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on March 5, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Kruse, et al. Expires March 5, 2013 [Page 1]
Internet-Draft Internet Convergence Layers for DTN Sep 2012
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. General Recommendation . . . . . . . . . . . . . . . . . . . . 3
3. Recommendations for Implementers . . . . . . . . . . . . . . . 4
3.1. How and Where to Deal with Fragmentation . . . . . . . . . 4
3.1.1. DCCP . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Bundle Protocol over a Datagram Convergence Layer . . . . 5
3.2.1. DCCP . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. LTP over a Datagram Convergence Layer . . . . . . . . . . 6
3.3.1. DCCP . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Keep Alive Option . . . . . . . . . . . . . . . . . . . . 6
3.5. Checksums . . . . . . . . . . . . . . . . . . . . . . . . 6
3.5.1. DCCP . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6. DCCP Availability . . . . . . . . . . . . . . . . . . . . 7
3.7. DCCP Congestion Control Modules . . . . . . . . . . . . . 7
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Kruse, et al. Expires March 5, 2013 [Page 2]
Internet-Draft Internet Convergence Layers for DTN Sep 2012
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)
through optional intermediate custody transfer, and the Licklider
Transmission 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
preferred method for transmitting either bundles or LTP blocks across
the Internet using datagrams in place of TCP.
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 Recommendation
In order to utilize DTN protocols across the Internet, whether for
testing purposes or as part of a larger network path, it is necessary
to encapsulate them into a standard Internet protocol so that they
travel easily across the Internet. This is particularly true for
LTP, which provides no endpoint addressing. This encapsulation
choice needs to be made carefully in order to avoid redundancy, since
DTN protocols may provide their own reliability mechanisms.
TCP, a logical choice, guarantees reliability and provides congestion
control. Congestion control is vital to the continued functioning of
the Internet, particularly for situations where data will be sent at
arbitrarily fast data rates. Because the Bundle Protocol offers
neither congestion control nor reliability, TCP is the RECOMMENDED
choice for its encapsulation. draft-irtf-dtnrg-tcp-clayer
[I-D.irtf-dtnrg-tcp-clayer] defines the method for transporting
bundles over TCP.
LTP, on the other hand, offers it's own form of reliability.
Particularly for testing purposes, it makes no sense to run LTP over
a protocol, like TCP, that offers reliability already. In addition,
running LTP over TCP would reduce the flexibility available to users,
since LTP offers more control over what data is delivered reliably
and what data is delivered best effort, a feature that TCP lacks. As
such, it would be better to run LTP over an unreliable protocol.
Kruse, et al. Expires March 5, 2013 [Page 3]
Internet-Draft Internet Convergence Layers for DTN Sep 2012
One solution would be to use UDP. UDP provides no reliability,
allowing LTP to manage that itself. However, UDP does not provide
congestion control. Because LTP is designed to run over fixed rate
radio links it does provides rate control, but not congestion
control. Lack of congestion control in network connections is a
major problem that can cause artificially high loss rates and/or
serious fairness issues. Previous standards documents are unanimous
in recommending congestion control for protocols to be used on the
Internet, see RFCs 2914 [RFC2914], 5405 [RFC5405], and 2309
[RFC2309], among others. RFC 5405 [RFC5405], in particular, calls
congestion control "vital" for "applications that can operate at
higher, potentially unbounded data rates". Therefore, any
application using UDP to transport LTP segements or Bundles MUST
implement congestion control consistent with RFC 5405.
Alternatively, the Datagram Congestion Control Protocol (DCCP)
[RFC4340] was designed specifically to provide congestion control
without reliability for those applications that traverse the Internet
but do not desire to retransmit lost data. As such, it is
RECOMMENDED that, if possible, DCCP be used to transport LTP segments
across the Internet.
3. Recommendations for Implementers
3.1. How and Where to Deal with Fragmentation
The Bundle 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
Kruse, et al. Expires March 5, 2013 [Page 4]
Internet-Draft Internet Convergence Layers for DTN Sep 2012
for DTN is the resources (time, complexity, and memory) required for
IP reassembly. If the Bundle Protocol is being encapsulated in DCCP
or UDP, 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
datagram that will not need to be fragmented.
3.1.1. DCCP
Because DCCP implementations are not required to support IP
fragmentation and are not allowed to enable it by default, a DCCP CL
MUST NOT accept data segments that cannot be sent as one MTU sized
datagram.
3.1.2. UDP
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.
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.
3.2. Bundle Protocol over a Datagram Convergence Layer
In general, the use of the bundle protocol over a datagram 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 datagram CL is used for transmission of bundles, every packet
MUST contain exactly one bundle or four zero octets as a keep-alive.
The CL SHOULD use available operating system services to obtain the
largest supported packet size, and MAY use the default packet size
limit if path-specific information is not available. For bundles
that are too large for the supported packet size, the bundle protocol
fragmentation process SHOULD be used to transmit the large bundle.
3.2.1. DCCP
The DCCP CL for bundle protocol use SHOULD use the IANA assigned port
4556/DCCP and service code 1685351985; the use of other port numbers
and service codes is implementation specific.
Kruse, et al. Expires March 5, 2013 [Page 5]
Internet-Draft Internet Convergence Layers for DTN Sep 2012
3.2.2. UDP
The UDP CL for bundle protocol use SHOULD use the IANA assigned port
4556/UDP; the use of other port numbers is implementation specific.
3.3. LTP over a Datagram 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 datagram CL is therefore the most
appropriate choice. When a datagram CL is used to transmit LTP data,
every packet MUST contain exactly one LTP segment or four zero octets
as a keep-alive. The CL SHOULD use available operating system
services to obtain the largest supported packet size, and MAY use the
default 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 single packet.
3.3.1. DCCP
The DCCP CL for LTP SHOULD use the IANA assigned port 1113/DCCP and
service code 7107696; the use of other port numbers and service codes
is implementation specific.
3.3.2. UDP
The UDP CL for LTP SHOULD use the IANA assigned port 1113/UDP; the
use of other port numbers is implementation specific.
3.4. Keep Alive Option
It may be desirable for a UDP or DCCP 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,
the CL MAY send a packet containing exactly 4 octets of zero bits.
The 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-alive packets
will therefore never be mistaken for actual data packets.
3.5. Checksums
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
Kruse, et al. Expires March 5, 2013 [Page 6]
Internet-Draft Internet Convergence Layers for DTN Sep 2012
at all.
3.5.1. DCCP
A DCCP CL transmitter MUST, therefore, ensure that the entire packet
is checksummed by setting the Checksum Coverage to 0. Likewise, the
DCCP CL receiver MUST ignore all packets with partial checksum
coverage.
3.5.2. UDP
A 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 probability of UDP packet
corruption remains. In some environments it may be acceptable for
LTP or the bundle protocol to occasionally receive corrupted 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.
3.6. DCCP Availability
As of this writing, the most mature DCCP implementation seems to be
the one in the Linux Kernel. DCCP has, unfortunately, been slow in
making it's way into most of the major platforms. As a result, if no
DCCP implementation is available for a target platform, tunneling LTP
over UDP is acceptable. In such a case, the UDP CL either MUST NOT
be used outside an isolated network for the transmission of any non-
trivial amounts of data, or it MUST implement congestion control
procedures as outlined in RFC 5405 [RFC5405].
3.7. DCCP Congestion Control Modules
DCCP supports pluggable congestion control modules in order to
optimize it's behavior to particular environments. The two most
common congestion control modules (CCIDs) are TCP-like Congestion
Control (CCID2) [RFC4341] and TCP-Friendly Rate Control (CCID3)
[RFC4342]. TCP-like Congestion Control is designed to emulate TCP's
congestion control as much as possible. It is recommended for
applications that want to send data as quickly as possible, while
TCP-Friendly Rate Control is aimed at applications that want to avoid
sudden changes in sending rate. DTN use cases seem to fit more into
the first case so DCCP CL's SHOULD use TCP-like Congestion Control
(CCID2) by default.
Kruse, et al. Expires March 5, 2013 [Page 7]
Internet-Draft Internet Convergence Layers for DTN Sep 2012
4. Acknowledgements
5. IANA Considerations
Port number assignments 1113/UDP and 4556/UDP have been registered
with IANA. Port numbers 1113/DCCP for the transport of LTP, and
4556/DCCP for the transport of bundles have been requested. DCCP
Service Codes 7107696 for tunneling LTP and 1685351985 for tunneling
Bundle Protocol have been requested.
6. Security Considerations
This memo describes the use of datagrams to transport DTN application
data. Hosts may be in the position of having to accept and process
packets from unknown sources; the DTN Endpoint ID can be discovered
only after the bundle has been retrieved from the DCCP or 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 DCCP or UDP data on the known
LTP or bundle protocol ports. A denial of service scenario exists
where a malicious host sends datagrams at a high rate, forcing the
receiving hosts to use its resources to process and attempt to
authenticate this data. Whenever possible, hosts SHOULD use IP
address filtering to limit the origin of packets to known hosts.
7. References
7.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, et al. Expires March 5, 2013 [Page 8]
Internet-Draft Internet Convergence Layers for DTN Sep 2012
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion
Control Protocol (DCCP) Congestion Control ID 2: TCP-like
Congestion Control", RFC 4341, March 2006.
[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.
7.2. Informative References
[I-D.irtf-dtnrg-tcp-clayer]
Demmer, M., Ott, J., and S. Perreault, "Delay Tolerant
Networking TCP Convergence Layer Protocol",
draft-irtf-dtnrg-tcp-clayer-04 (work in progress),
August 2012.
[Kent88] Kent, C. and J. Mogul, "Fragmentation considered
harmful.", 1988, <http://doi.acm.org/10.1145/55482.55524>.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J., and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the
Internet", RFC 2309, April 1998.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, September 2000.
[RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for
Datagram Congestion Control Protocol (DCCP) Congestion
Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 4342,
March 2006.
Kruse, et al. Expires March 5, 2013 [Page 9]
Internet-Draft Internet Convergence Layers for DTN Sep 2012
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405,
November 2008.
Authors' Addresses
Hans Kruse
Ohio University
292 Lindley Hall
Athens, OH 45701
United States
Phone: +1 740 593 4891
Email: kruse@ohiou.edu
Samuel Jero
Ohio University
Athens, Ohio 45701
United States
Email: sj323707@ohio.edu
Shawn Ostermann
Ohio University
Stocker Engineering Center
Athens, OH 45701
United States
Phone: +1 740 593 1566
Email: ostermann@eecs.ohiou.edu
Kruse, et al. Expires March 5, 2013 [Page 10]
