[要約] RFC 7122は、DTN Bundle ProtocolとLicklider Transmission Protocol（LTP）のためのデータグラム収束層に関するものです。このRFCの目的は、遅延や障害に対応するネットワーキング環境でのデータ転送を効率的に行うためのガイドラインを提供することです。
Internet Research Task Force (IRTF) H. Kruse
Request for Comments: 7122 Ohio University
Category: Experimental S. Jero
ISSN: 2070-1721 Purdue University
S. Ostermann
Ohio University
March 2014
Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP)
遅延および破壊耐性ネットワーキング（DTN）バンドルプロトコルとLicklider伝送プロトコル（LTP）のためのデータグラム収束層
Abstract
概要
This document specifies the preferred method for transporting Delay-and Disruption-Tolerant Networking (DTN) protocol data over the Internet using datagrams. It covers convergence layers for the Bundle Protocol (RFC 5050), as well as the transportation of segments using the Licklider Transmission Protocol (LTP) (RFC 5326). 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. This document is a product of the Delay-Tolerant Networking Research Group (DTNRG) and represents the consensus of the DTNRG.
このドキュメントでは、データグラムを使用してインターネット上で遅延および破壊耐性ネットワーク（DTN）プロトコルデータを転送するための推奨される方法を指定します。バンドルプロトコル（RFC 5050）のコンバージェンスレイヤー、およびLicklider Transmission Protocol（LTP）（RFC 5326）を使用したセグメントのトランスポートについて説明します。 UDPとデータグラム輻輳制御プロトコル（DCCP）は、議論されるデータグラムプロトコルの候補です。 UDPは、ローカルネットワークでのみ、またはDTNノードが明示的な輻輳制御を実装している場合にのみ使用できます。 DCCPは輻輳制御問題に対処し、可能な限りその使用をお勧めします。このドキュメントは、Delay-Tolerant Networking Research Group（DTNRG）の製品であり、DTNRGの合意を表します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Delay-Tolerant Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。この文書は、Internet Research Task Force（IRTF）の製品です。 IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適さない可能性があります。このRFCは、インターネット研究タスクフォース（IRTF）の遅延耐性ネットワーキング研究グループの合意を表します。 IRSGによる公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7122.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7122で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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 to this document.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. General Recommendation . . . . . . . . . . . . . . . . . . . 4
3. Recommendations for Implementers . . . . . . . . . . . . . . 6
3.1. How and Where to Deal with Fragmentation . . . . . . . . 6
3.1.1. DCCP . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Bundle Protocol over a Datagram Convergence Layer . . . . 6
3.2.1. DCCP . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. LTP over Datagrams . . . . . . . . . . . . . . . . . . . 7
3.3.1. DCCP . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Keep-Alive Option . . . . . . . . . . . . . . . . . . . . 7
3.5. Checksums . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5.1. DCCP . . . . . . . . . . . . . . . . . . . . . . . . 8
3.5.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.6. DCCP Congestion Control Modules . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 10
DTN communication protocols include the Bundle Protocol described in RFC 5050 [RFC5050], which provides transmission of application data blocks ("bundles") through optional intermediate custody transfer, and the Licklider Transmission Protocol (LTP) -- LTP Motivation [RFC5325], LTP Specification [RFC5326], and LTP Security [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. "Delay Tolerant Networking TCP Convergence Layer Protocol" [CLAYER] defines a method for transporting bundles over TCP. This document 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.
DTN通信プロトコルには、オプションの中間カストディ転送によるアプリケーションデータブロック（「バンドル」）の送信を提供するRFC 5050 [RFC5050]で記述されているバンドルプロトコル、およびLicklider送信プロトコル（LTP）-LTPモチベーション[RFC5325]、LTPが含まれます。仕様[RFC5326]、およびLTPセキュリティ[RFC5327]-ポイントツーポイントリンクでバンドルを確実かつ効率的に送信するために使用できます。多くの場合、インターネットプロトコルリンクを介してこれらのプロトコルをテストすることが望まれます。 "Delay Tolerant Networking TCP Convergence Layer Protocol" [CLAYER]は、TCPでバンドルを転送する方法を定義しています。このドキュメントでは、TCPの代わりにデータグラムを使用して、バンドルまたはLTPブロックのいずれかをインターネット経由で送信するための推奨方法を指定します。図1は、DTNドキュメントで説明されている一般的なプロトコルレイヤーを示しています。 DTNアプリケーションはバンドルプロトコルレイヤーと対話し、バンドルプロトコルレイヤーは収束レイヤーを使用してバンドルを送信する準備をします。コンバージェンスレイヤーは、通常、より低いレベルのプロトコルに依存して伝送を実行します。
+-----------------------------------------+
| |
| DTN Application |
| |
+-----------------------------------------+
+-----------------------------------------+
| |
| Bundle Protocol (BP) |
| |
+-----------------------------------------+
+-----------------------------------------+
| |
| Convergence Layer Adapter (CL) |
| |
+-----------------------------------------+
+-----------------------------------------+
| |
| Local Data-Link Layer (Transport) |
| |
+-----------------------------------------+
Figure 1: Generic Protocol Stack for DTN
図1：DTNの汎用プロトコルスタック
This document provides guidance for implementation of the two protocol stacks illustrated in Figure 2. In Figure 2(a), the Convergence Layer Adapter 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.
このドキュメントは、図2に示す2つのプロトコルスタックの実装に関するガイダンスを提供します。図2（a）では、コンバージェンスレイヤーアダプターは、インターネット上でバンドルを直接転送するためのUDPまたはDCCPです。図2（b）では、コンバージェンスレイヤーアダプターはLTPであり、ローカルデータリンクレイヤーとしてUDPまたはDCCPを使用します。
+-------------+ +-------------+
| | | |
| DTN App | | DTN App |
| | | |
+-------------+ +-------------+
+-------------+ +-------------+
| | | |
| BP | | BP |
| | | |
+-------------+ +-------------+
+-------------+ +-------------+
| | | |
| UDP/DCCP | | LTP |
| | | |
+-------------+ +-------------+
+-------------+
| |
| UDP/DCCP |
| |
+-------------+
(a) (b)
（a）（b）
Figure 2: Protocol Stacks Addressed in this Document
図2：このドキュメントで扱われているプロトコルスタック
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
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.
インターネット経由でDTNプロトコルを利用するには、テストの目的であれ、より大きなネットワークパスの一部であれ、それらを標準のインターネットプロトコルにカプセル化して、インターネット経由で簡単に移動できるようにする必要があります。これは、エンドポイントアドレス指定を提供しないLTPに特に当てはまります。 DTNプロトコルは独自の信頼性メカニズムを提供する場合があるため、このカプセル化の選択は、冗長性を回避するために慎重に行う必要があります。
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 RFC 5050 [RFC5050]). In situations where TCP will work effectively in communications between pairs of DTN nodes, use of the TCP convergence layer [CLAYER] 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.
輻輳制御は、インターネットが引き続き機能するために、特にデータが任意の高速データレートで送信される状況で不可欠です。バンドルプロトコルは、信頼性の高い配信のプロビジョニングと、暗黙的に、使用されるコンバージェンスレイヤーに輻輳制御を委任します（RFC 5050 [RFC5050]のセクション7.2）。 DTNノードのペア間の通信でTCPが効果的に機能する状況では、TCPコンバージェンスレイヤー[CLAYER]を使用すると、バンドルのトランスポートに必要な信頼性と輻輳制御が提供され、インターネットでのデフォルトの選択になります。バンドルをデータグラムに直接カプセル化し、UDPまたはDCCPを使用するなどの代替策は、信頼性が制限され、UDPの場合は輻輳制御がないため、一般に適切ではありません。
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.
一方、LTPは独自の形式の信頼性を提供します。特にテストの目的では、すでに信頼性を提供しているTCPなどのプロトコル上でLTPを実行することは意味がありません。さらに、LTP over TCPを実行すると、ユーザーが利用できる柔軟性が低下します。LTPは、どのデータが確実に配信され、どのデータがベストエフォートで配信されるかを制御できるため、TCPにはない機能です。そのため、信頼性の低いプロトコルでLTPを実行することをお勧めします。
One solution would be to use UDP. UDP provides no reliability, allowing LTP to manage that itself. However, UDP also 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 "Congestion Control Principles" [RFC2914], "Unicast UDP Usage Guidelines" [RFC5405], and "Queue Management and Congestion Avoidance" [RFC2309], 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.
1つの解決策は、UDPを使用することです。 UDPは信頼性を提供しないため、LTPはそれ自体を管理できます。ただし、UDPは輻輳制御も提供しません。 LTPは固定レートの無線リンク上で動作するように設計されているため、レート制御は提供されますが、輻輳制御は提供されません。ネットワーク接続での輻輳制御の欠如は、人為的に高い損失率や深刻な公平性の問題を引き起こす可能性がある主要な問題です。以前の標準文書は、インターネットで使用されるプロトコルの輻輳制御を推奨することについては全会一致です。「輻輳制御の原則」[RFC2914]、「ユニキャストUDP使用ガイドライン」[RFC5405]、および「キュー管理と輻輳回避」[RFC2309]を参照してください。とりわけ。特にRFC 5405は、「より高い、無制限のデータレートで動作できるアプリケーション」に対して、輻輳制御を「不可欠」と呼びます。したがって、UDPを使用してLTPセグメントまたはバンドルを隔離されたネットワークの外に転送することを許可するすべてのバンドルプロトコル実装は、重要な量のデータを送信するために、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.
あるいは、データグラム輻輳制御プロトコル（DCCP）[RFC4340]は、インターネットを通過するが失われたデータの再送信を望まないアプリケーションに対して信頼性なしに輻輳制御を提供するように特別に設計されました。したがって、可能であれば、DCCPを使用してLTPセグメントをインターネット経由で転送することをお勧めします。
The Bundle Protocol allows bundles with sizes limited only by node resource constraints. In IPv4, the maximum size of a UDP datagram is nearly 64 KB. In IPv6, when using jumbograms [RFC2675], UDP datagrams can technically be up to 4 GB in size [RFC2147], although this option is rarely used. (Note: RFC 2147 was obsoleted by RFC 2675.) It is well understood that sending large IP datagrams that must be fragmented by the network has enormous efficiency penalties [Kent87]. The Bundle Protocol specification provides a bundle fragmentation concept [RFC5050] 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.
バンドルプロトコルは、ノードリソースの制約によってのみ制限されるサイズのバンドルを許可します。 IPv4では、UDPデータグラムの最大サイズは約64 KBです。 IPv6では、ジャンボグラムを使用する場合[RFC2675]、UDPデータグラムのサイズは技術的には最大4 GB [RFC2147]になる可能性がありますが、このオプションはほとんど使用されません。 （注：RFC 2147はRFC 2675に置き換えられました。）ネットワークでフラグメント化する必要がある大きなIPデータグラムを送信すると、効率が大幅に低下することはよく理解されています[Kent87]。バンドルプロトコル仕様は、大きなフラグメントをバンドルフラグメントに分割できるようにするバンドルフラグメンテーションコンセプト[RFC5050]を提供します。バンドルプロトコルがDCCPまたはUDPでカプセル化されている場合は、IP層でフラグメント化する必要のないデータグラムにカプセル化できるように、十分に小さいサイズの各フラグメントを作成する必要があります（SHOULD）。
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.
IPフラグメンテーションは、IPパスMTUディスカバリー[RFC1191] [RFC1981]を使用することで回避できます。これは、ネットワーク内のルーターからのICMP Packet Too Big（PTB）メッセージの確定的配信に依存します。ブラックホール[RFC2923]と呼ばれる条件を回避するために、PTBメッセージを使用せずにIPパスMTUを決定するための新しい仕様が[RFC4821]で利用可能です。このドキュメントでは、断片化を回避するメカニズムを推奨することはしません。このセクションの情報は、実装者のために含まれています。
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 a single MTU-sized datagram.
DCCP実装はIPフラグメンテーションをサポートする必要がなく、デフォルトで有効にすることが許可されていないため、DCCPコンバージェンスレイヤー（以降、「CL」を使用します）は、単一のMTUサイズとして送信できないデータセグメントを受け入れてはなりませんデータグラム。
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.
LTP CLがデータグラム配信にUDPを使用している場合、前述のように、フラグメント化する必要のあるUDPデータグラムになるセグメントを作成しないでください。
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.
一般に、IPネットワークでは、データグラムCLでのバンドルプロトコルの使用は推奨されません。バンドルは（ほぼ）任意の長さにすることができ、バンドルプロトコルには効果的な再送信メカニズムが含まれていません。可能な限り、バンドルプロトコルは、TCPコンバージェンスレイヤーまたはLTPを介して操作する必要があります（SHOULD）。
If a datagram CL is used for transmission of bundles, every datagram MUST contain exactly one bundle or 4 octets of zero bits 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.
バンドルの送信にデータグラムCLが使用される場合、すべてのデータグラムは、キープアライブとして、厳密に1つのバンドルまたはゼロビットの4オクテットを含む必要があります。パスMTUに対して大きすぎるバンドルは、IPの断片化を防ぐために、バンドルプロトコルレイヤーで断片化および再構築する必要があります（SHOULD）。
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.
バンドルプロトコル用のDCCP CLは、IANAが割り当てたポート4556 / DCCPとサービスコード1685351985を使用する必要があります（SHOULD）。他のポート番号とサービスコードの使用は実装固有です。
The UDP CL for Bundle Protocol use SHOULD use the IANA-assigned port 4556/UDP; the use of other port numbers is implementation specific.
バンドルプロトコル用のUDP CLは、IANAが割り当てたポート4556 / UDPを使用する必要があります（SHOULD）。他のポート番号の使用は実装固有です。
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" (RFC 5325 [RFC5325]); 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 4 octets of zero bits 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.
LTPは、DTN内のポイントツーポイントプロトコルとして設計されており、固有の確認応答および再送信機能を提供します。 LTPセグメントは、「ローカルデータリンク層」（RFC 5325 [RFC5325]）を介して転送されます。これ以降、「トランスポート」という用語を使用します。データグラムを使用したLTPの転送は適切な選択です。データグラムトランスポートを使用してLTPセグメントを送信する場合、すべてのデータグラムには、キープアライブとして1つのLTPセグメントまたはゼロビットの4オクテットが含まれている必要があります。 LTPは、すべてのLTPセグメントが、前述のIPフラグメンテーションを必要としない単一のパケットに適合することを保証するような方法でセグメンテーションを実行する必要があります。
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.
LTPのDCCPトランスポートは、IANAが割り当てたポート1113 / DCCPとサービスコード7107696を使用する必要があります（SHOULD）。他のポート番号とサービスコードの使用は実装固有です。
The UDP transport for LTP SHOULD use the IANA-assigned port 1113/UDP; the use of other port numbers is implementation specific.
LTPのUDPトランスポートは、IANAが割り当てたポート1113 / UDPを使用する必要があります（SHOULD）。他のポート番号の使用は実装固有です。
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 document. 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 is 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 seconds, and MUST NOT be configured shorter than 15 seconds.
UDPまたはDCCP CLまたはトランスポートが、延長されたアイドル期間中に「キープアライブ」パケットを送信することが望ましい場合があります。これは、宛先の連絡先テーブルエントリを更新したり、NATのアドレスマッピングやファイアウォールのダイナミックアクセスルールを維持したりするために必要になる場合があります。したがって、CLまたはトランスポートは、正確に4オクテットのゼロビットを含むデータグラムを送信できます。このようなパケットを受信するCLまたはトランスポートは、このパケットを破棄する必要があります。受信側のCLまたはトランスポートは、状態テーブルのローカル保守を実行できます。これらのメンテナンス機能については、このドキュメントでは扱いません。バンドルまたはセグメントを運ぶパケットには、常に4オクテットを超える情報（バンドルまたはLTPヘッダーのいずれか）が含まれることに注意してください。したがって、キープアライブパケットが実際のデータパケットと間違われることはありません。バンドルエージェントのペア間の双方向の通信にUDPまたはDCCPが使用されている場合、2方向のキープアライブの送信と処理は独立して行われます。キープアライブ間隔は構成可能である必要があり（SHOULD）、デフォルトは15秒である必要があり、15秒より短く構成してはなりません（MUST NOT）。
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.
コアバンドルプロトコル仕様とコアLTP仕様はどちらも、消去チャネル、つまりパケットを正しく配信するかまったく配信しないチャネルを介して送信していることを前提としています。
A DCCP transmitter MUST, therefore, ensure that the entire packet is checksummed by setting the Checksum Coverage to zero. Likewise, the DCCP receiver MUST ignore all packets with partial checksum coverage.
したがって、DCCPトランスミッタは、チェックサムカバレッジをゼロに設定することにより、パケット全体がチェックサムされることを確認する必要があります。同様に、DCCPレシーバーは、チェックサムが部分的にカバーされているすべてのパケットを無視する必要があります。
A UDP transmitter, therefore, MUST NOT disable UDP checksums, and the UDP receiver MUST NOT disable the checking of received UDP checksums.
したがって、UDPトランスミッターはUDPチェックサムを無効にしてはならず（MUST NOT）、UDPレシーバーは受信したUDPチェックサムのチェックを無効にしてはなりません（MUST NOT）。
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.
UDPチェックサムが有効になっている場合でも、UDPパケットが破損する可能性はわずかです。環境によっては、LTPまたはバンドルプロトコルが破損した入力をときどき受信することが許容される場合があります。ただし、一般に、UDP実装では、メッセージの破損を防ぐために、バンドルプロトコルまたはLTPで利用可能なオプションのセキュリティ拡張機能を使用する必要があります（SHOULD）。
DCCP supports pluggable congestion control modules in order to optimize its 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 and transports SHOULD use TCP-like Congestion Control (CCID2) by default.
DCCPは、特定の環境に対する動作を最適化するために、プラグイン可能な輻輳制御モジュールをサポートしています。最も一般的な2つの輻輳制御モジュール（CCID）は、TCPのような輻輳制御（CCID2）[RFC4341]とTCPフレンドリーレート制御（CCID3）[RFC4342]です。 TCPのような輻輳制御は、TCPの輻輳制御を可能な限りエミュレートするように設計されています。 TCPフレンドリーレートコントロールは、送信レートの急激な変化を避けたいアプリケーションを対象としていますが、データをできるだけ早く送信したいアプリケーションに推奨されます。 DTNのユースケースは最初のケースに当てはまるように見えるため、DCCP CLおよびトランスポートは、デフォルトでTCPのような輻輳制御（CCID2）を使用する必要があります（SHOULD）。
Port number assignments 1113/UDP and 4556/UDP have been registered with IANA. The assignment for 1113/UDP referenced [RFC5326]; this entry has been changed to add the present document in addition to [RFC5326]. The assignment of 4556/UDP had no reference; this entry has been changed to point to the present document. The service name for 4556/UDP has been changed from dtn-bundle-udp to dtn-bundle. Port number 1113/DCCP (ltp-deepspace) with Service Code 7107696 has been assigned for the transport of LTP. Port number 4556/DCCP (dtn-bundle) with Service Code 1685351985 has been assigned for the transport of bundles. The port number assignment for 4556/TCP is addressed in the [CLAYER] document.
ポート番号割り当て1113 / UDPおよび4556 / UDPはIANAに登録されています。 1113 / UDPの割り当ては[RFC5326]を参照しました。このエントリは、[RFC5326]に加えて現在のドキュメントを追加するように変更されました。 4556 / UDPの割り当てには参照がありませんでした。このエントリは、現在のドキュメントを指すように変更されました。 4556 / UDPのサービス名がdtn-bundle-udpからdtn-bundleに変更されました。 LTPのトランスポートには、サービスコード7107696のポート番号1113 / DCCP（ltp-deepspace）が割り当てられています。バンドルのトランスポートには、サービスコード1685351985のポート番号4556 / DCCP（dtn-bundle）が割り当てられています。 4556 / TCPのポート番号の割り当てについては、[CLAYER]ドキュメントで説明されています。
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.
このメモは、DTNアプリケーションデータを転送するためのデータグラムの使用について説明しています。ホストは、未知のソースからのパケットを受け入れて処理する必要があるという立場にある可能性があります。 DTNエンドポイントIDは、バンドルがDCCPまたはUDPパケットから取得された後にのみ検出できます。ホストは、悪意のあるホストが未知のデータをアプリケーションに挿入するのを防ぐために、DTN仕様で利用可能な認証方法を使用する必要があります（SHOULD）。
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.
ホストは、既知のLTPまたはバンドルプロトコルポートでDCCPまたはUDPデータをリッスンして処理する必要があります。悪意のあるホストがデータグラムを高速で送信し、受信ホストがそのリソースを使用してこのデータを処理および認証しようとするサービス拒否シナリオが存在します。可能な限り、ホストはIPアドレスフィルタリングを使用して、パケットの発信元を既知のホストに制限する必要があります（SHOULD）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2147] Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147, May 1997.
[RFC2147] Borman、D。、「TCP and UDP over IPv6 Jumbograms」、RFC 2147、1997年5月。
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", RFC 2675, August 1999.
[RFC2675] Borman、D.、Deering、S。、およびR. Hinden、「IPv6 Jumbograms」、RFC 2675、1999年8月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram Congestion Control Protocol（DCCP）」、RFC 4340、2006年3月。
[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.
[RFC4341] Floyd、S。およびE. Kohler、「Profile for Datagram Congestion Control Protocol（DCCP）Congestion Control ID 2：TCP-like Congestion Control」、RFC 4341、2006年3月。
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, November 2007.
[RFC5050]スコット、KおよびS.バーレイ、「バンドルプロトコル仕様」、RFC 5050、2007年11月。
[RFC5325] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider Transmission Protocol - Motivation", RFC 5325, September 2008.
[RFC5325] Burleigh、S.、Ramadas、M。、およびS. Farrell、「Licklider Transmission Protocol-Motivation」、RFC 5325、2008年9月。
[RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider Transmission Protocol - Specification", RFC 5326, September 2008.
[RFC5326] Ramadas、M.、Burleigh、S。、およびS. Farrell、「Licklider Transmission Protocol-Specification」、RFC 5326、2008年9月。
[RFC5327] Farrell, S., Ramadas, M., and S. Burleigh, "Licklider Transmission Protocol - Security Extensions", RFC 5327, September 2008.
[RFC5327] Farrell、S.、Ramadas、M。、およびS. Burleigh、「Licklider Transmission Protocol-Security Extensions」、RFC 5327、2008年9月。
[CLAYER] Demmer, M., Ott, J., and S. Perreault, "Delay Tolerant Networking TCP Convergence Layer Protocol", Work in Progress, January 2014.
[CLAYER] Demmer、M.、Ott、J。、およびS. Perreault、「Delay Tolerant Networking TCP Convergence Layer Protocol」、Work in Progress、2014年1月。
[Kent87] Kent, C. and J. Mogul, "Fragmentation considered harmful", SIGCOMM '87, Proceedings of the ACM workshop on Frontiers in computer communications technology, 1987, <http://doi.acm.org/10.1145/55482.55524>.
[Kent87] Kent、C。およびJ. Mogul、「フラグメンテーションは有害と見なされます」、SIGCOMM '87、Proceedings on the ACM Workshop on Frontiers in computercommunications、1987、<http://doi.acm.org/10.1145/55482.55524 >。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU discovery」、RFC 1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のパスMTUディスカバリ」、RFC 1981、1996年8月。
[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.
[RFC2309]ブレーデン、B。、クラーク、D。、クロウクロフト、J。、デイビー、B。、ディアリング、S。、エストリン、D。、フロイド、S。、ジェイコブソン、V。、ミンシャル、G。、パートリッジ、 C.、Peterson、L.、Ramakrishnan、K.、Shenker、S.、Wroclawski、J。、およびL. Zhang、「インターネットでのキュー管理と輻輳回避に関する推奨事項」、RFC 2309、1998年4月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S。、「輻輳制御原則」、BCP 41、RFC 2914、2000年9月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923] Lahey、K。、「Path MTU Discoveryに関するTCPの問題」、RFC 2923、2000年9月。
[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.
[RFC4342] Floyd、S.、Kohler、E。、およびJ. Padhye、「Profile for Datagram Congestion Control Protocol（DCCP）Congestion Control ID 3：TCP-Friendly Rate Control（TFRC）」、RFC 4342、2006年3月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、2007年3月。
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008.
[RFC5405] Eggert、L。およびG. Fairhurst、「アプリケーション設計者のためのユニキャストUDP使用ガイドライン」、BCP 145、RFC 5405、2008年11月。
Authors' Addresses
著者のアドレス
Hans Kruse Ohio University 31 S. Court Street, Rm 150 Athens, OH 45701 United States
Hans Kruse Ohio University 31 S. Court Street、Rm 150 Athens、OH 45701 United States
Phone: +1 740 593 4891
EMail: kruse@ohio.edu
Samuel Jero Purdue University West Lafayette, IN 47907 United States
Samuel Jero Purdue大学West Lafayette、IN 47907アメリカ合衆国
EMail: sjero@purdue.edu
Shawn Ostermann Ohio University Stocker Engineering Center Athens, OH 45701 United States
Shawn Ostermannオハイオ大学ストッカーエンジニアリングセンターアテネ、OH 45701アメリカ合衆国
Phone: +1 740 593 1566
EMail: ostermann@eecs.ohiou.edu