One document matched: draft-irtf-dtnrg-dgram-clayer-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1191 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1191.xml">
<!ENTITY RFC1981 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1981.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2309 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2309.xml">
<!ENTITY RFC2914 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2914.xml">
<!ENTITY RFC2923 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2923.xml">
<!ENTITY RFC5325 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5325.xml">
<!ENTITY RFC5326 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5326.xml">
<!ENTITY RFC5327 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5327.xml">
<!ENTITY RFC5050 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5050.xml">
<!ENTITY RFC4340 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4340.xml">
<!ENTITY RFC4341 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4341.xml">
<!ENTITY RFC4342 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4342.xml">
<!ENTITY RFC5405 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5405.xml">
<!ENTITY RFC0791 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0791.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC2675 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2675.xml">
<!ENTITY RFC2147 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2147.xml">
<!ENTITY RFC0791 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.0791.xml">
<!ENTITY RFC1883 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1883.xml">
<!ENTITY RFC4821 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4821.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
<!ENTITY I-D.irtf-dtnrg-tcp-clayer SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-irtf-dtnrg-tcp-clayer-05.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="exp" docName="draft-irtf-dtnrg-dgram-clayer-04" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Internet Datagram Transport for DTN">Datagram Convergence Layers for the DTN Bundle and LTP Protocols</title>
<author fullname="Hans Kruse" initials="H.K."
surname="Kruse">
<organization>Ohio University</organization>
<address>
<postal>
<street>31 S. Court Street, Rm 150</street>
<city>Athens</city>
<region>OH</region>
<code>45701</code>
<country>United States</country>
</postal>
<phone>+1 740 593 4891</phone>
<email>kruse@ohio.edu</email>
</address>
</author>
<author fullname="Samuel Jero" initials="S.C.J."
surname="Jero">
<organization>Ohio University</organization>
<address>
<postal>
<street></street>
<city>Athens</city>
<region>Ohio</region>
<code>45701</code>
<country>United States</country>
</postal>
<email>sj323707@ohio.edu</email>
</address>
</author>
<author fullname="Shawn Ostermann" initials="S.D.O"
surname="Ostermann">
<organization>Ohio University</organization>
<address>
<postal>
<street>Stocker Engineering Center</street>
<city>Athens</city>
<region>OH</region>
<code>45701</code>
<country>United States</country>
</postal>
<phone>+1 740 593 1566</phone>
<email>ostermann@eecs.ohiou.edu</email>
</address>
</author>
<date day="6" month="July" year="2013" />
<!-- Meta-data Declarations -->
<area>IRTF</area>
<workgroup>DTNRG</workgroup>
<keyword>dtnrg</keyword>
<abstract>
<t>This document is a product of the Delay- and Distruption-Tolerant Networking Research Group
(DTNRG), and represents the consensus of the DTNRG.
It specifies the preferred method for transporting
Delay- and Disruption-Tolerant Networking (DTN) protocol data over the Internet using datagrams.
The specification
covers convergence layers for the Bundle Protocol (RFC 5050) as well
as the transportation of Licklider Transmission Protocol (LTP) (RFC 5326)
segments.
UDP and the Datagram Congestion Control Protocol
(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 addresses the congestion
control problem, and its use is recommended whenever possible.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> DTN communication protocols include the Bundle Protocol described in
<xref target="RFC5050">RFC 5050</xref>,
which provides transmission of application data blocks (Bundles) through optional intermediate custody transfer,
and the Licklider Transmission Protocol (LTP), RFCs <xref target="RFC5325">5325 (LTP Motivation)</xref>,
<xref target="RFC5326">5326 (LTP Specification)</xref>,
and <xref target="RFC5327">5327 (LTP Security)</xref>
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.
<xref target="I-D.irtf-dtnrg-tcp-clayer">draft-irtf-dtnrg-tcp-clayer</xref> 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.
Figure 1 shows the general protocol layering described in the DTN documents. DTN Applications interact with the Bundle Protocol Layer, which in turn uses a Convergence Layer to prepare a bundle for transmission. The Convergence Layer will typically rely on a lower level protocol to carry out the transmission.
<figure anchor="layers" title="Generic Protocol Stack for DTN" align="center">
<artwork>
+-----------------------------------------+
| |
| DTN Application |
| |
+-----------------------------------------+
+-----------------------------------------+
| |
| Bundle Protocol (BP) |
| |
+-----------------------------------------+
+-----------------------------------------+
| |
| Convergence Layer Adapter (CL) |
| |
+-----------------------------------------+
+-----------------------------------------+
| |
| Local Data Link Layer (Transport) |
| |
+-----------------------------------------+
</artwork>
</figure>
This document provides guidance for implementation of the two protocol stacks illustrated in figure 2.
In figure 2(a) the Convergence Layer Adapater is UDP or DCCP for direct transport of Bundles over the Internet.
In figure 2(b) the Convergence Layer Adapter is LTP, which then uses UDP or DCCP as the local data link layer.
<vspace blankLines='100' />
<figure anchor="implement" title="Protocol Stacks Addressed in this Document" align="center">
<artwork>
+-------------+ +-------------+
| | | |
| DTN App | | DTN App |
| | | |
+-------------+ +-------------+
+-------------+ +-------------+
| | | |
| BP | | BP |
| | | |
+-------------+ +-------------+
+-------------+ +-------------+
| | | |
| UDP/DCCP | | LTP |
| | | |
+-------------+ +-------------+
+-------------+
| |
| UDP/DCCP |
| |
+-------------+
(a) (b)
</artwork>
</figure>
</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="General Recommendation">
<t>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.</t>
<t>Congestion control is vital to the continued functioning of
the Internet, particularly for situations where data will be sent at
arbitrarily fast data rates. The Bundle Protocol delegates provision
of reliable delivery and, implicitly, congestion control to the
convergence layer used (Section 7.2 of <xref target="RFC5050">RFC 5050</xref>).
In situations
where TCP will work effectively in communications between pairs of
DTN nodes, use of the TCP convergence layer <xref target="I-D.irtf-dtnrg-tcp-clayer">draft-irtf-dtnrg-tcp-clayer</xref>
will provide the required reliability and congestion control for
transport of Bundles and would be the default choice in the Internet.
Alternatives such as encapsulating Bundles directly in datagrams and
using UDP or DCCP are not
generally appropriate because they offer limited reliability and, in the
case of UDP, no congestion control.</t>
<t>LTP, on the other hand, offers its 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.</t>
<t>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 provide 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 <xref target="RFC2914">"Congestion Control Principles"</xref>,
<xref target="RFC5405">"Unicast UDP Usage Guidelines"</xref>, and
<xref target="RFC2309">"Queue Management and Congestion Avoidance"</xref>,
among others. RFC 5405, in particular, calls congestion control "vital" for "applications that can
operate at higher, potentially unbounded data rates". Therefore, any Bundle Protocol
implementation permitting the use of UDP to transport LTP segments or Bundles outside an isolated network for the transmission of any non-trivial amounts of data
MUST implement congestion control consistent with RFC 5405.</t>
<t>Alternatively, the <xref target="RFC4340">Datagram Congestion Control Protocol (DCCP)</xref> 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.</t>
</section>
<section title="Recommendations for Implementers">
<section title="How and Where to Deal with Fragmentation">
<t>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 <xref target="RFC2675">jumbograms</xref>, UDP datagrams can technically be up to <xref target="RFC2147">
4GB in size</xref>, although this option is rarely used.
It is well understood that sending large IP datagrams that must be fragmented by the network has
enormous <xref target="Kent88">efficiency penalties</xref>.
The Bundle Protocol specification provides a <xref target="RFC5050">Bundle fragmentation concept</xref>
that allows a large Bundle to be divided into Bundle fragments. If the Bundle Protocol is being encapsulated in DCCP or UDP,
it therefore SHOULD create each fragment of sufficiently small size
that it can then be encapsulated into a datagram that will not need
to be fragmented at the IP layer.</t>
<t>
IP fragmentation can be avoided by using IP Path MTU Discovery [RFC1191][RFC1981], which depends on the deterministic delivery of ICMP Packet Too Big (PTB) messages from routers in the network. To bypass a
condition referred to as a black hole [RFC2923], a newer specification is available in [RFC4821] to determine
the IP Path MTU without the use of PTB messages. This document does not attempt to
recommend one fragmentation avoidance mechanism over another; the information in
this section is included for the benefit of implementers.
</t>
<section title="DCCP">
<t>Because DCCP implementations are not required to support IP fragmentation and are not allowed to enable it by default, a
DCCP Convergence Layer (we will use "CL" from here on) MUST NOT accept data segments that cannot be sent as one MTU sized datagram. </t>
</section>
<section title="UDP">
<t>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. </t>
</section>
</section>
<section title="Bundle Protocol over a Datagram Convergence Layer">
<t>In general, the use of the Bundle Protocol over a datagram CL is discouraged in IP networks. 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.</t>
<t>If a datagram CL is used for transmission of Bundles, every datagram MUST contain exactly one Bundle or
four zero octets as a keep-alive. Bundles that are too large for the path MTU SHOULD be fragmented and reassembled at the Bundle Protocol layer to prevent IP fragmentation.</t>
<section title="DCCP">
<t>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.</t>
</section>
<section title="UDP">
<t>The UDP CL for Bundle Protocol use SHOULD use the IANA assigned port 4556/UDP; the use of other port numbers is
implementation specific.</t>
</section>
</section>
<section title="LTP over Datagrams">
<t>LTP is designed as a point to point protocol within DTN, and it provides intrinsic acknowledgement and
retransmission facilities. LTP segments are transported over a "local data link layer" (<xref target="RFC5325">RFC 5325</xref>);
we will use the term "transport" from here on.
Transport of LTP using datagrams is an appropriate choice.
When a datagram transport is used to send LTP segments, every datagram MUST contain exactly one LTP segment or
four zero octets as a keep-alive.
LTP MUST perform segmentation in such a way as to ensure that every LTP segment fits into a single packet
which will not require IP fragmentation as discussed above.</t>
<section title="DCCP">
<t>The DCCP transport 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.</t>
</section>
<section title="UDP">
<t>The UDP transport for LTP SHOULD use the IANA assigned port 1113/UDP; the use of other port numbers is
implementation specific.</t>
</section>
</section>
<section title="Keep Alive Option">
<t>It may be desirable for a UDP or DCCP CL or transport 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 or transport MAY send a datagram containing exactly 4 octets of zero bits. The CL or transport receiving
such a packet MUST discard this packet; the receiving CL or transport may then perform local maintenance of its state tables, these
maintenance functions are not covered in this draft. Note that packets carrying Bundles or segments 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.
If UDP or DCCP are being used for communication in both directions between a pair
of Bundle agents, transmission and processing of keep-alives in the two directions
occurs independently. Keep-alive intervals SHOULD be configurable, SHOULD default to 15 sec, and MUST NOT be configured
shorter than 15 sec.
</t>
</section>
<section title="Checksums">
<t>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. </t>
<section title="DCCP">
<t>A DCCP transmitter MUST, therefore,
ensure that the entire packet is checksummed by setting the Checksum Coverage to 0. Likewise, the DCCP receiver MUST ignore
all packets with partial checksum coverage.</t>
</section>
<section title="UDP">
<t>A UDP transmitter therefore
MUST NOT disable UDP checksums, and the UDP receiver MUST NOT disable checking of received UDP checksums.</t>
<t>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 implementation SHOULD use optional security extensions available in the Bundle Protocol
or LTP to protect against message corruption.</t>
</section>
</section>
<!--
<section title="DCCP Availability">
<t>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
<xref target="RFC5405">RFC 5405</xref>.</t>
</section>
-->
<section title="DCCP Congestion Control Modules">
<t>DCCP supports pluggable congestion control modules in order to optimize its behavior to particular environments.
The two most common
congestion control modules (CCIDs) are <xref target="RFC4341">TCP-like Congestion Control (CCID2)</xref> and <xref target="RFC4342">
TCP-Friendly Rate Control (CCID3)</xref>. 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 and transports SHOULD use TCP-like Congestion Control (CCID2) by default.</t>
</section>
</section>
<!--
<section anchor="Acknowledgements" title="Acknowledgements">
<t></t>
</section>
-->
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>No further IANA actions are needed.
Port number assignments 1113/UDP and 4556/UDP have been registered with IANA.
Assigned port numbers are 1113/DCCP for the transport of LTP, and 4556/DCCP for the transport of
Bundles. Assigned DCCP Service Codes are 7107696 for tunneling LTP
and 1685351985 for tunneling Bundle Protocol.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
<t>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 their 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.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC0791;
&RFC1883;
&RFC2119;
&RFC2147;
&RFC2675;
&RFC4340;
&RFC4341;
&RFC5050;
&RFC5325;
&RFC5326;
&RFC5327;
</references>
<references title="Informative References">
&RFC1191;
&RFC1981;
&RFC2309;
&RFC2914;
&RFC2923;
&RFC4821;
&RFC5405;
&RFC4342;
&I-D.irtf-dtnrg-tcp-clayer;
<reference anchor="Kent88"
target="http://doi.acm.org/10.1145/55482.55524">
<front>
<title>Fragmentation considered harmful.</title>
<author initials="C.A." surname="Kent">
<organization></organization>
</author>
<author initials="J.C." surname="Mogul">
<organization></organization>
</author>
<date year="1988" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:43:44 |