[要約] RFC 2745は、RSVP（Resource Reservation Protocol）の診断メッセージに関する情報を提供しています。このRFCの目的は、ネットワークの状態や問題を特定し、RSVPのパフォーマンスを向上させるための診断手法を提供することです。
Network Working Group A. Terzis
Request for Comments: 2745 UCLA
Category: Standards Track B. Braden
ISI
S. Vincent
Cisco Systems
L. Zhang
UCLA
January 2000
RSVP Diagnostic Messages
RSVP診断メッセージ
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This document specifies the RSVP diagnostic facility, which allows a user to collect information about the RSVP state along a path. This specification describes the functionality, diagnostic message formats, and processing rules.
このドキュメントは、RSVP診断施設を指定します。これにより、ユーザーはパスに沿ってRSVP状態に関する情報を収集できます。この仕様では、機能、診断メッセージ形式、および処理ルールについて説明します。
In the basic RSVP protocol [RSVP], error messages are the only means for an end host to receive feedback regarding a failure in setting up either path state or reservation state. An error message carries back only the information from the failed point, without any information about the state at other hops before or after the failure. In the absence of failures, a host receives no feedback regarding the details of a reservation that has been put in place, such as whether, or where, or how, its own reservation request is being merged with that of others. Such missing information can be highly desirable for debugging purposes, or for network resource management in general.
基本的なRSVPプロトコル[RSVP]では、エラーメッセージは、パス状態または予約状態のセットアップの障害に関するフィードバックをエンドホストが受信する唯一の手段です。エラーメッセージは、失敗したポイントからの情報のみを持ち帰り、失敗の前後に他のホップの状態に関する情報はありません。障害がない場合、ホストは、独自の予約要求が他の人のリクエストと融合されているかどうか、どこで、どのように、どのように、どのように、どのように、どのように、どのように導入されているかについての予約の詳細に関するフィードバックを受け取りません。このような欠落した情報は、デバッグの目的、または一般的なネットワークリソース管理のために非常に望ましい場合があります。
This document specifies the RSVP diagnostic facility, which is designed to fill this information gap. The diagnostic facility can be used to collect and report RSVP state information along the path from a receiver to a specific sender. It uses Diagnostic messages that are independent of other RSVP control messages and produce no side-effects; that is, they do not change any RSVP state at either nodes or hosts. Similarly, they provide not an error report but rather a collection of requested RSVP state information.
このドキュメントは、この情報ギャップを埋めるように設計されたRSVP診断施設を指定します。診断施設は、受信者から特定の送信者へのパスに沿ったRSVP状態情報を収集および報告するために使用できます。他のRSVP制御メッセージに依存しない診断メッセージを使用し、副作用を生成しません。つまり、ノードまたはホストのいずれかでRSVP状態を変更しません。同様に、それらはエラーレポートではなく、要求されたRSVP状態情報のコレクションを提供します。
The RSVP diagnostic facility was designed with the following goals:
RSVP診断施設は、次の目標で設計されました。
- To collect RSVP state information from every RSVP-capable hop along a path defined by path state, either for an existing reservation or before a reservation request is made. More specifically, we want to be able to collect information about flowspecs, refresh timer values, and reservation merging at each hop along the path.
- 既存の予約または予約要求が行われる前に、パス状態によって定義されたパスに沿って、すべてのRSVP対応ホップからRSVP状態情報を収集する。具体的には、パスに沿って各ホップでのフロースペック、更新、予約に関する情報を収集できるようにしたいと考えています。
- To collect the IP hop count across each non-RSVP cloud.
- 各非RSVPクラウド全体でIPホップカウントを収集します。
- To avoid diagnostic packet implosion or explosion.
- 診断パケットの爆発または爆発を避けるため。
The following is specifically identified as a non-goal:
以下は、非ゴールとして具体的に識別されます。
- Checking the resource availability along a path. Such functionality may be useful for future reservation requests, but it would require modifications to existing admission control modules that is beyond the scope of RSVP.
- パスに沿ってリソースの可用性を確認します。このような機能は、将来の予約リクエストに役立つ場合がありますが、RSVPの範囲を超えた既存の入場制御モジュールの変更が必要です。
The diagnostic facility introduces two new RSVP message types: Diagnostic Request (DREQ) and Diagnostic Reply (DREP). A DREQ message can be originated by a client in a "requester" host, which may or may not be a participant of the RSVP session to be diagnosed. A client in the requester host invokes the RSVP diagnostic facility by generating a DREQ packet and sending it towards the LAST-HOP node, which should be on the RSVP path to be diagnosed. This DREQ packet specifies the RSVP session and a sender host for that session. Starting from the LAST-HOP, the DREQ packet collects information hop-by-hop as it is forwarded towards the sender (see Figure 1), until it reaches the ending node. Specifically, each RSVP-capable hop adds to the DREQ message a response (DIAG_RESPONSE) object containing local RSVP state for the specified RSVP session.
診断施設では、2つの新しいRSVPメッセージタイプを導入します：診断要求（DREQ）と診断返信（DREP）。DREQメッセージは、診断されるRSVPセッションの参加者である場合とそうでない場合がある「リクエスター」ホストのクライアントによって発信できます。Requesterホストのクライアントは、DREQパケットを生成し、ラストホップノードに送信することにより、RSVP診断施設を呼び出します。これは、診断するRSVPパスにあるはずです。このDREQパケットは、そのセッションのRSVPセッションと送信者ホストを指定します。ラストホップから始めて、DREQパケットは、エンディングノードに到達するまで、送信者に転送されるため、情報ホップバイホップを収集します。具体的には、各RSVP対応ホップは、指定されたRSVPセッションにローカルRSVP状態を含む応答（DIAG_RESPONSE）オブジェクトをDREQメッセージに追加します。
When the DREQ packet reaches the ending node, the message type is changed to Diagnostic Reply (DREP) and the completed response is sent to the original requester node. Partial responses may also be returned before the DREQ packet reaches the ending node if an error condition along the path, such as "no path state", prevents further forwarding of the DREQ packet. To avoid packet implosion or explosion, all diagnostic packets are forwarded via unicast only.
DREQパケットがエンディングノードに到達すると、メッセージタイプが診断応答（DREP）に変更され、完成した応答が元のリクエストノードに送信されます。「パス状態なし」などのパスに沿ったエラー条件がDREQパケットのさらなる転送を防ぐと、DREQパケットがエンディングノードに到達する前に、部分的な応答が返される場合があります。パケットの爆発や爆発を避けるために、すべての診断パケットはユニキャストのみを介して転送されます。
Thus, there are generally three nodes (hosts and/or routers) involved in performing the diagnostic function: the requester node, the starting node, and the ending node, as shown in Figure 1. It is possible that the client invoking the diagnosis function may reside directly on the starting node, in which case that the first two nodes are the same. The starting node is named "LAST-HOP", meaning the last-hop of the path segment to be diagnosed. The LAST-HOP node can be either a receiver node or an intermediate node along the path. The ending node is usually the specified sender host. However, the client can limit the length of the path segment to be diagnosed by specifying a hop-count limit in the DREQ message.
したがって、一般に、図1に示すように、診断機能の実行に関与する3つのノード（ホストおよび/またはルーター）が診断機能の実行に関与します。最初の2つのノードが同じである場合、開始ノードに直接存在する場合があります。開始ノードは「ラストホップ」と呼ばれます。これは、診断されるパスセグメントの最終ホップを意味します。最終ホップノードは、パスに沿ったレシーバーノードまたは中間ノードのいずれかです。エンディングノードは通常、指定された送信者ホストです。ただし、クライアントは、DREQメッセージのホップカウント制限を指定することにより、診断されるパスセグメントの長さを制限できます。
LAST-HOP Ending
Receiver node node Sender
__ __ __ __ __
| |---------| |------>| |--> ...-->| |--> ...---->| |
|__| |__| DREQ |__| DREQ |__| DREQ |__|
^ . |
| . |
| DREQ . DREP | DREP
| . |
_|_ DREP V V
Requester | | <------------------------------------
(client) |___|
Figure 1
図1
DREP packets can be unicast from the ending node back to the requester either directly or hop-by-hop along the reverse of the path taken by the DREQ message to the LAST-HOP, and thence to the requester. The direct return is faster and more efficient, but the hop-by-hop reverse-path route may be the only choice if the packets have to cross firewalls. Hop-by-hop return is accomplished using an optional ROUTE object, which is built incrementally to contain a list of node addresses that the DREQ packet has passed through. The ROUTE object is then used in reverse as a source route to forward the DREP hop-by-hop back to the LAST-HOP node.
DREPパケットは、エンディングノードからリクエスターに直接戻るか、DREQメッセージが最後のホップに、そしてその後リクエスターに撮影したパスの逆に沿ってホップバイホップに戻ることができます。直接リターンはより速く、より効率的ですが、パケットがファイアウォールを横断する必要がある場合、ホップバイホップのリバースパスルートが唯一の選択肢かもしれません。ホップバイホップリターンは、DREQパケットが通過したノードアドレスのリストを含むために段階的に構築されるオプションのルートオブジェクトを使用して達成されます。ルートオブジェクトは、DREPホップバイホップをラストホップノードに戻すために、ソースルートとして逆に使用されます。
A DREQ message always consists of a single unfragmented IP datagram. On the other hand, one DREQ message can generate multiple DREP packets, each containing a fragment of the total DREQ message. When the path consists of many hops, the total length of a DREP message will exceed the MTU size before reaching the ending node; thus, the message has to be fragmented. Relying on IP fragmentation and reassembly, however, can be problematic, especially when DREP messages are returned to the requester hop-by-hop, in which case fragmentation/reassembly would have to be performed at every hop. To avoid such excessive overhead, we let the requester define a default path MTU size that is carried in every DREQ packet. If an intermediate node finds that the default MTU size is bigger than the MTU of the incoming interface, it reduces the default MTU size to the MTU size of the incoming interface. If an intermediate node detects that a DREQ packet size is larger than the default MTU size, it returns to the requester (in either manner described above) a DREP fragment containing accumulated responses. It then removes these responses from the DREQ and continues to forward it. The requester node can reassemble the resulting DREP fragments into a complete DREP message.
DREQメッセージは、常に単一のフラージメントされていないIPデータグラムで構成されています。一方、1つのDREQメッセージは、それぞれがTotal DREQメッセージのフラグメントを含む複数のDREPパケットを生成できます。パスが多くのホップで構成されている場合、DREPメッセージの合計長さは、終了ノードに到達する前にMTUサイズを超えます。したがって、メッセージを断片化する必要があります。ただし、IPの断片化と再組み立てに依存すると、特にDREPメッセージがリクエスターホップバイホップに返される場合は問題があります。この場合、すべてのホップで断片化/再組み立てを実行する必要があります。このような過度のオーバーヘッドを回避するために、すべてのDREQパケットで運ばれるデフォルトパスMTUサイズを要求者に定義させます。中間ノードが、デフォルトのMTUサイズが着信インターフェイスのMTUよりも大きいことを発見した場合、デフォルトのMTUサイズを着信インターフェイスのMTUサイズに削減します。中間ノードがDREQパケットサイズがデフォルトのMTUサイズよりも大きいことを検出すると、累積応答を含むDREPフラグメントを要求者（上記のいずれかの方法で）に戻します。次に、これらの応答をDreqから削除し、転送し続けます。リクエスターノードは、結果のDREPフラグメントを完全なDREPメッセージに再組み立てることができます。
When discussing diagnostic packet handling, this document uses direction terminology that is consistent with the RSVP functional specification [RSVP], relative to the direction of data packet flow. Thus, a DREQ packet enters a node through an "outgoing interface" and is forwarded towards the sender through an "incoming interface", because DREQ packets travel in the reverse direction to the data flow.
診断パケット処理について議論するとき、このドキュメントでは、データパケットフローの方向と比較して、RSVP機能仕様[RSVP]と一致する方向用語を使用します。したがって、DREQパケットは「発信インターフェイス」を介してノードに入り、DREQパケットがデータフローまで逆方向に移動するため、「着信インターフェイス」を介して送信者に転送されます。
Notice that DREQ packets can be forwarded only after the RSVP path state has been set up. If no path state exists, one may resort to the traceroute or mtrace facility to examine whether the unicast/multicast routing is working correctly.
DREQパケットは、RSVPパス状態がセットアップされた後にのみ転送できることに注意してください。パス状態が存在しない場合、Unicast/Multicastルーティングが正しく機能しているかどうかを調べるために、TracerouteまたはMtrace施設に頼ることができます。
Like other RSVP messages, DREQ and DREP messages consist of an RSVP Common Header followed by a variable set of typed RSVP data objects. The following sequence must be used:
他のRSVPメッセージと同様に、DREQおよびDREPメッセージは、RSVP共通ヘッダーに続いて、タイプされたRSVPデータオブジェクトの変数セットで構成されています。次のシーケンスを使用する必要があります。
+-----------------------------------+
| RSVP Common Header |
+-----------------------------------+
| Session object |
+-----------------------------------+
| Next-Hop RSVP_HOP object |
+-----------------------------------+
| DIAGNOSTIC object |
+-----------------------------------+
| (optional) DIAG_SELECT object |
+-----------------------------------+
| (optional) ROUTE object |
+-----------------------------------+
| zero or more DIAG_RESPONSE objects|
+-----------------------------------+
The session object identifies the RSVP session for which the state information is being collected. We describe each of the other parts.
セッションオブジェクトは、状態情報が収集されているRSVPセッションを識別します。他の各部分について説明します。
The RSVP message common header is defined in [RSVP]. The following specific exceptions and extensions are needed for DREP and DREQ.
RSVPメッセージ共通ヘッダーは[RSVP]で定義されています。DrepとDreqには、次の特定の例外と拡張機能が必要です。
Type field: define:
タイプフィールド：定義：
Type = 8: DREQ Diagnostic Request
タイプ= 8：DREQ診断リクエスト
Type = 9: DREP Diagnostic Reply
タイプ= 9：DREP診断返信
RSVP length:
RSVP長さ：
If this is a DREP message and the MF flag in the DIAGNOSTIC object (see below) is set, this field indicates the length of this single DREP fragment rather than the total length of the complete DREP reply message (which cannot generally be known in advance).
これがDREPメッセージであり、診断オブジェクトのMFフラグ（以下を参照）が設定されている場合、このフィールドは、完全なDREP応答メッセージの総長ではなく、この単一のDrepフラグメントの長さを示します（これは一般的に事前にはわかりません。）。
This RSVP_HOP object carries the LIH of the interface through which the DREQ should be received at the upstream node. This object is updated hop-by hop. It is used for the same reasons that a RESV message contains an RSVP_HOP object: to distinguish logical interfaces and avoid problems caused by routing asymmetries and non-RSVP clouds.
このRSVP_HOPオブジェクトは、上流ノードでDREQを受信するインターフェイスのLIHを運びます。このオブジェクトは、ホップごとに更新されます。RESVメッセージにRSVP_HOPオブジェクトが含まれているのと同じ理由で使用されます。論理インターフェイスを区別し、非対称性と非RSVPクラウドをルーティングすることによって引き起こされる問題を回避します。
While the IP address is not really used during DREQ processing, for consistency with the use of the RSVP_HOP object in other RSVP messages, the IP address in the RSVP_HOP object to contain the address of the interface through which the DREQ was sent.
IPアドレスは、DREQ処理中に実際には使用されていませんが、他のRSVPメッセージでRSVP_HOPオブジェクトを使用するために一貫性がありますが、RSVP_HOPオブジェクトのIPアドレスは、DREQが送信されたインターフェイスのアドレスを含むようにします。
A DIAGNOSTIC object contains the common diagnostic control information in both DREQ and DREP messages.
診断オブジェクトには、DREQメッセージとDREPメッセージの両方に一般的な診断制御情報が含まれています。
o IPv4 DIAGNOSTIC object: Class = 30, C-Type = 1
o IPv4診断オブジェクト：class = 30、c-type = 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-RSVP-hops | RSVP-hop-count| Reserved |MF|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+---------------+---------------+---------------+---------------+
| Path MTU | Fragment Offset |
+---------------+---------------+---------------+---------------+
| LAST-HOP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SENDER_TEMPLATE object |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Requester FILTER_SPEC object |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Here all IP addresses use the 4 byte IPv4 format, both explicitly in the LAST-HOP Address and by using the IPv4 forms of the embedded FILTER_SPEC and RSVP_HOP objects.
ここでは、すべてのIPアドレスが4バイトIPv4形式を使用します。両方とも、最後のホップアドレスで明示的に、また埋め込まれたfilter_specおよびrsvp_hopオブジェクトのIPv4フォームを使用します。
o IPv6 DIAGNOSTIC object: Class = 30, C-Type = 2
o IPv6診断オブジェクト：class = 30、c-type = 2
The format is the same, except all explicit and embedded IP addresses are 16 byte IPv6 addresses.
形式は同じですが、すべての明示的なIPアドレスと埋め込みのすべてのアドレスが16バイトIPv6アドレスです。
The fields are as follows:
フィールドは次のとおりです。
Max-RSVP-hops
max-rsvp-hops
An octet specifying the maximum number of RSVP hops over which information will be collected. If an error condition in the middle of the path prevents the DREQ packet from reaching the specified ending node, the Max-RSVP-hops field may be used to perform an expanding-length search to reach the point just before the problem. If this value is 1, the starting node and the ending node of the query will be the same. If it is zero, there is no hop limit.
RSVPホップの最大数を指定したオクテットは、どの情報が収集されるかについてです。パスの中央にあるエラー条件がDREQパケットが指定されたエンディングノードに到達するのを防ぐ場合、MAX-RSVP-HOPSフィールドを使用して、拡張長の検索を実行して問題の直前にポイントに到達することができます。この値が1の場合、クエリの開始ノードと終了ノードは同じになります。ゼロの場合、ホップ制限はありません。
RSVP-hop-count
rsvp-hop-count
Records the number of RSVP hops that have been traversed so far. If the starting and ending nodes are the same, this value will be 1 in the resulting DREP message.
これまでに横断されてきたRSVPホップの数を記録します。開始ノードと終了ノードが同じ場合、この値は結果のDREPメッセージで1になります。
Fragment Offset
フラグメントオフセット
Indicates where this DREP fragment belongs in the complete DREP message, measured in octets. The first fragment has offset zero. Fragment Offset is used also to determine if a DREQ message containing zero DIAG_RESPONSE objects should be processed at an RSVP capable node.
このDrepフラグメントがオクテットで測定された完全なDrepメッセージのどこに属しているかを示します。最初のフラグメントにはオフセットゼロがあります。フラグメントオフセットは、ゼロDIAG_RESPONSEオブジェクトを含むDREQメッセージをRSVP対応ノードで処理する必要があるかどうかを判断するためにも使用されます。
MF flag
MFフラグ
Flag means "more fragments". It must be set to zero (0) in all DREQ messages. It must be set to one (1) in all DREP packets that carry partial results and are returned by intermediate nodes due to the MTU limit. When the DREQ message is converted to a DREP message in the ending node, the MF flag must remain zero.
フラグは「より多くの断片」を意味します。すべてのDREQメッセージでゼロ（0）に設定する必要があります。部分的な結果をもたらすすべてのDrepパケットで1つの（1）に設定する必要があり、MTU制限により中間ノードによって返される必要があります。DREQメッセージが終了ノードのDREPメッセージに変換される場合、MFフラグはゼロのままでなければなりません。
Request ID
リクエストID
Identifies an individual DREQ message and the corresponding DREP message (or all the fragments of the reply message).
個々のDREQメッセージと対応するDREPメッセージ（または応答メッセージのすべてのフラグメント）を識別します。
One possible way to define the Request ID would use 16 bits to specify the ID of the process making the query and 16 bits to distinguish different queries from this process.
リクエストIDを定義する1つの可能な方法は、16ビットを使用してプロセスのIDを指定し、クエリを作成し、16ビットを作成して、このプロセスと異なるクエリを区別します。
Path MTU
パスmtu
Specifies a default MTU size in octets for DREP and DREQ messages. This value should not be smaller than the size of the "base" DREQ packet. A "base" DREQ packet is one that contains a Common Header, a Session object, a Next-Hop RSVP_HOP object, a DIAGNOSTIC object, an empty ROUTE object and a single default DIAG_RESPONSE (see below). The assumption made here is that a diagnostic packet of this size can always be forwarded without IP fragmentation.
DREPおよびDREQメッセージのオクテットでデフォルトのMTUサイズを指定します。この値は、「ベース」DREQパケットのサイズよりも小さくてはなりません。「ベース」DREQパケットは、共通のヘッダー、セッションオブジェクト、次のホップRSVP_HOPオブジェクト、診断オブジェクト、空のルートオブジェクト、単一のデフォルトのDIAG_Responseを含むものです（以下を参照）。ここで行われた仮定は、このサイズの診断パケットは、IPの断片化なしで常に転送できるということです。
LAST-HOP Address
ラストホップアドレス
The IP address of the LAST-HOP node. The DREQ message starts collecting information at this node and proceeds toward the sender.
ラストホップノードのIPアドレス。DREQメッセージは、このノードで情報の収集を開始し、送信者に向かって進みます。
SENDER_TEMPLATE object
sender_templateオブジェクト
This IPv4/IPv6 SENDER_TEMPLATE object contains the IP address and the port of a sender for the session being diagnosed. The DREQ packet is forwarded hop-by-hop towards this address.
このIPv4/IPv6 Sender_Templateオブジェクトには、診断されているセッションのIPアドレスと送信者のポートが含まれています。Dreqパケットは、このアドレスにホップバイホップに転送されます。
Requester FILTER_SPEC Object
requester filter_specオブジェクト
This IPv4/IPv6 FILTER_SPEC object contains the IP address and the port from which the request originated and to which the DREP message(s) should be sent.
このIPv4/IPv6 Filter_Specオブジェクトには、IPアドレスとリクエストが発信され、DREPメッセージが送信されるポートが含まれています。
o DIAG_SELECT Class = 33, C-Type = 1.
o diag_select class = 33、c-type = 1。
A Diagnostic message may optionally contain a DIAG_SELECT object to specify which specific RSVP objects should be reported in a DIAG_RESPONSE object. In the absence of a DIAG_SELECT object, the DIAG_RESPONSE object added by the node will contain a default set of object types (see DIAG_RESPONSE object below).
診断メッセージには、DIAG_SELECTオブジェクトがオプションで含まれている場合があり、DIAG_Responseオブジェクトでどの特定のRSVPオブジェクトを報告するかを指定できます。DIAG_SELECTオブジェクトがない場合、ノードによって追加されたDIAG_RESPONSEオブジェクトには、オブジェクトタイプのデフォルトセットが含まれます（以下のDIAG_RESPONSEオブジェクトを参照）。
The DIAG_SELECT object contains a list of [Class, C-type] pairs, in the following format:
DIAG_SELECTオブジェクトには、次の形式で[クラス、Cタイプ]ペアのリストが含まれています。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| class | C-Type | class | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| class | C-Type | class | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When a DIAG_SELECT object is included in a DREQ message, each RSVP node along the path will add a DIAG_RESPONSE object containing response objects (see below) whose classes and C-Types match entries in the DIAG_SELECT list (and are from matching path and reservation state). A C-type octet of zero is a 'wildcard', matching any C-Type associated with the associated class.
DIAG_SELECTオブジェクトがDREQメッセージに含まれている場合、パスに沿った各RSVPノードは、DIAG_SELECTリストのクラスとCタイプが一致する（およびマッチングパスと予約状態からのクラスとCタイプが1つの応答オブジェクトを含むDIAG_RESPONSEオブジェクト（以下を参照）を追加します。）。ゼロのC型オクテットは「ワイルドカード」であり、関連するクラスに関連付けられたCタイプと一致します。
Depending on the type of objects requested, a node can find the associated information in the path or reservation state stored for the session described in the SESSION object. Specifically, information for the RSVP_HOP,SENDER_TEMPLATE, SENDER_TSPEC, ADSPEC objects can be extracted from the node's path state, while information for the FLOWSPEC, FILTER_SPEC, CONFIRM, STYLE and SCOPE objects can be found in the node's reservation state (if existent).
要求されたオブジェクトのタイプに応じて、ノードは、セッションオブジェクトに記載されているセッションに保存されているパスまたは予約状態に関連する情報を見つけることができます。具体的には、rsvp_hop、sender_template、sender_tspec、adspecオブジェクトの情報はノードのパス状態から抽出できますが、flowspec、filter_spec、確認、スタイル、スコープオブジェクトの情報は、ノードの予約状態（存在する場合）にあります。
If the number of [Class, C-Type] pairs is odd, the last two octets of the DIAG_SELECT object must be zero. A maximum DIAG_SELECT object is one that contains the [Class, C-type] pairs for all the RSVP objects that can be requested in a Diagnostic query.
[クラス、Cタイプ]ペアの数が奇妙な場合、DIAG_SELECTオブジェクトの最後の2オクテットはゼロでなければなりません。最大DIAG_SELECTオブジェクトは、診断クエリで要求できるすべてのRSVPオブジェクトの[クラス、Cタイプ]ペアを含むものです。
A diagnostic message may contain a ROUTE object, which is used to record the route of the DREQ message and as a source route for returning the DREP message(s) hop-by-hop.
診断メッセージには、DREQメッセージのルートを記録するために使用されるルートオブジェクトと、DREPメッセージ（S）のホップバイホップを返すためのソースルートとして使用される場合があります。
o IPv4 ROUTE object: Class = 31, C-Type = 1.
o IPv4ルートオブジェクト：class = 31、c-type = 1。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | R-pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ RSVP Node List |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This message signifies how the reply should be returned. If it does not exist in the DREQ packet then DREP packets should be sent to the requester directly. If it does exist, DREP packets must be returned hop-by-hop along the reverse path to the LAST-HOP node and thence to the requester node.
このメッセージは、返信を返す方法を示しています。DREQパケットに存在しない場合は、DREPパケットをリクエスターに直接送信する必要があります。それが存在する場合、DREPパケットは、ラストホップノードへの逆パスに沿ってホップバイホップを返し、それからリクエスターノードに戻す必要があります。
An empty ROUTE object is one that has an empty RSVP Node list and R-pointer is equal to zero.
空のルートオブジェクトは、空のRSVPノードリストがあり、Rポインターがゼロに等しいものです。
RSVP Node List
RSVPノードリスト
A list of RSVP node IPv4 addresses. The number of addresses in this list can be computed from the object size.
RSVPノードIPv4アドレスのリスト。このリストのアドレスの数は、オブジェクトサイズから計算できます。
R-pointer
Rポインター
Used in DREP messages only (see Section 4.2 for details), but it is incremented as each hop adds its incoming interface address in the ROUTE object.
DREPメッセージのみで使用されます（詳細についてはセクション4.2を参照）が、各ホップがルートオブジェクトに着信インターフェイスアドレスを追加すると増加します。
o IPv6 ROUTE object: Class = 31, C-Type = 2
o IPv6ルートオブジェクト：class = 31、c-type = 2
The same, except RSVP Node List contains IPv6 addresses.
同じことが、RSVPノードリストにIPv6アドレスが含まれていることを除いて。
In a DREQ message, RSVP Node List specifies all RSVP hops between the LAST-HOP address specified in the DIAGNOSTIC object, and the last RSVP node the DREQ message has visited. In a DREP message, RSVP Node List specifies all RSVP hops between the LAST-HOP and the node that returns this DREP message.
DREQメッセージで、RSVPノードリストは、診断オブジェクトで指定された最終ホップアドレスと、DREQメッセージがアクセスした最後のRSVPノード間のすべてのRSVPホップを指定します。DREPメッセージで、RSVPノードリストは、このDREPメッセージを返すラストホップとノードの間のすべてのRSVPホップを指定します。
Each RSVP node attaches a DIAG_RESPONSE object to each DREQ message it receives, before forwarding the message. The DIAG_RESPONSE object contains the state to be reported for this node. It has a fixed-format header and then a variable list of RSVP state objects, or "response objects".
各RSVPノードは、メッセージを転送する前に、受信する各DREQメッセージにDIAG_RESPONSEオブジェクトを添付します。DIAG_RESPONSEオブジェクトには、このノードについて報告される状態が含まれています。固定フォーマットヘッダー、次にRSVP状態オブジェクトの変数リスト、または「応答オブジェクト」があります。
o IPv4 DIAG_RESPONSE object: Class = 32, C-Type = 1.
o IPv4 DIAG_RESPONSEオブジェクト：class = 32、c-type = 1。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DREQ Arrival Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Incoming Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outgoing Interface Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Previous-RSVP-Hop Router Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| D-TTL |M|R-err| K | Timer value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| (optional) TUNNEL object |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Response objects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o IPv6 DIAG_RESPONSE object: Class = 32, C-Type = 2.
o IPv6 DIAG_RESPONSEオブジェクト：class = 32、c-type = 2。
This object has the same format, except that all explicit and embedded IP addresses are IPv6 addresses.
このオブジェクトは同じ形式を持っていますが、すべての明示的および埋め込まれたIPアドレスがIPv6アドレスであることを除きます。
The fields are as follows: DREQ Arrival Time
フィールドは次のとおりです。Dreq到着時間
A 32-bit NTP timestamp specifying the time the DREQ message arrived at this node. The 32-bit form of an NTP timestamp consists of the middle 32 bits of the full 64-bit form, that is, the low 16 bits of the integer part and the high 16 bits of the fractional part.
DREQメッセージがこのノードに到着した時間を指定する32ビットNTPタイムスタンプ。NTPタイムスタンプの32ビット形式は、64ビットフルフォームの中央の32ビット、つまり整数部の16ビットと分数部分の16ビットで構成されています。
Incoming Interface Address
着信インターフェイスアドレス
Specifies the IP address of the interface on which messages from the sender are expected to arrive, or 0 if unknown.
送信者からのメッセージが到着すると予想されるインターフェイスのIPアドレス、または不明の場合は0を指定します。
Outgoing Interface Address
発信インターフェイスアドレス
Specifies the IP address of the interface through which the DREQ message arrived and to which messages from the given sender and for the specified session address flow, or 0 if unknown.
DREQメッセージが到着し、指定された送信者からのメッセージ、および指定されたセッションアドレスフロー（不明の場合は0）のインターフェイスのIPアドレスを指定します。
Previous-RSVP-Hop Router Address
以前のRSVP-HOPルーターアドレス
Specifies the IP address from which this node receives RSVP PATH messages for this source, or 0 if unknown. This is also the interface to which the DREQ will be forwarded.
このノードがこのソースのRSVPパスメッセージを受信するIPアドレス、または不明の場合は0を指定します。これは、DREQが転送されるインターフェイスでもあります。
D-TTL
d-ttl
The number of IP hops this DREQ message traveled from the down-stream RSVP node to the current node.
このDREQメッセージの数は、ダウンストリームRSVPノードから現在のノードまで移動しました。
M flag
Mフラグ
A single-bit flag which indicates whether the reservation described by the response objects is merged with reservations from other down-stream interfaces when being forwarded upstream.
応答オブジェクトによって記述された予約が、上流に転送されるときに他のダウンストリームインターフェイスからの予約と融合されているかどうかを示す単一ビットフラグ。
R-error
r-error
A 3-bit field that indicates error conditions at a node. Currently defined values are:
ノードでのエラー条件を示す3ビットフィールド。現在定義されている値は次のとおりです。
0x00: no error 0x01: No PATH state 0x02: packet too big 0x04: ROUTE object too big
0x00：エラーなし0x01：パス状態なし0x02：パケットが大きすぎる0x04：ルートオブジェクトが大きすぎる
K
k
The refresh timer multiple (defined in [RSVP]).
更新タイマー倍（[rsvp]で定義）。
Timer value
タイマー値
The local refresh timer value in seconds.
秒単位のローカルリフレッシュタイマー値。
The set of response objects to be included at the end of the DIAG_RESPONSE object is determined by a DIAG_SELECT object, if one is present. If no DIAG_SELECT object is present, the response objects belong to the default list of classes:
DIAG_RESPONSEオブジェクトの最後に含まれる応答オブジェクトのセットは、存在する場合、DIAG_SELECTオブジェクトによって決定されます。DIAG_SELECTオブジェクトが存在しない場合、応答オブジェクトはクラスのデフォルトリストに属します。
SENDER_TSPEC object FILTER_SPEC object FLOWSPEC object STYLE object
sender_tspecオブジェクトFilter_SpecオブジェクトFlowsPecオブジェクトスタイルオブジェクト
Any C-Type present in the local RSVP state will be used. These response objects may be in any order but they must all be at the end of the DIAG_RESPONSE object.
ローカルRSVP状態に存在するC型が使用されます。これらの応答オブジェクトは任意の順序である場合がありますが、それらはすべてDIAG_RESPONSEオブジェクトの終わりにある必要があります。
A default DIAG_RESPONSE object is one containing the default list of classes described above.
デフォルトのDIAG_RESPONSEオブジェクトは、上記のクラスのデフォルトリストを含むものです。
The optional TUNNEL object should be inserted when a DREQ message arrives at an RSVP node that acts as a tunnel exit point.
オプションのトンネルオブジェクトは、トンネル出口ポイントとして機能するRSVPノードにDREQメッセージが到着するときに挿入する必要があります。
The TUNNEL object provides the mapping between the end-to-end RSVP session that is being diagnosed and the RSVP session over the tunnel. This mapping information allows the diagnosis client to conduct diagnosis over the involved tunnel session, by invoking a separate Diagnostic query for the corresponding Tunnel Session and Tunnel Sender. Keep in mind, however, that multiple end-to-end sessions may all map to one pre-configured tunnel session that may have totally different parameter settings.
トンネルオブジェクトは、診断されているエンドツーエンドのRSVPセッションとトンネル上のRSVPセッションの間のマッピングを提供します。このマッピング情報により、対応するトンネルセッションとトンネル送信者のために別の診断クエリを呼び出すことにより、診断クライアントが関係するトンネルセッションで診断を行うことができます。ただし、複数のエンドツーエンドセッションがすべて、まったく異なるパラメーター設定を持つ可能性のある1つの事前に構成されたトンネルセッションにマッピングされる可能性があることに注意してください。
The tunnel object is defined in the RSVP Tunnel Specification [RSVPTUN].
トンネルオブジェクトは、RSVPトンネル仕様[rsvptun]で定義されています。
DREQ messages are forwarded hop-by-hop via unicast from the LAST-HOP address to the Sender address, as specified in the DIAGNOSTIC object. If an RSVP capable node, other than the LAST-HOP node, receives a DREQ message that contains no DIAG_RESPONSE objects and has a zero Fragment Offset, the node should forward the DREQ packet towards the LAST-HOP without doing any of the processing mentioned below. The reason is that such conditions apply only for nodes downstream of the LAST-HOP where no information should be collected.
DREQメッセージは、診断オブジェクトで指定されているように、最終ホップアドレスから送信者アドレスへのユニキャストを介してホップバイホップに転送されます。ラストホップノード以外のRSVP対応ノードが、DIAG_RESPONSEオブジェクトを含み、フラグメントオフセットがゼロのDREQメッセージを受信した場合、ノードは以下に説明する処理を実行せずにDREQパケットを最終ホップに転送する必要があります。。その理由は、そのような条件が、情報を収集する必要がないラストホップの下流のノードにのみ適用されるためです。
Processing begins when a DREQ message, DREQ_in, arrives at a node.
処理は、DREQメッセージ、DREQ_INがノードに到着するときに始まります。
1. Create a new DIAG_RESPONSE object. Compute the IP hop count from the previous RSVP hop. This is done by subtracting the value of the TTL value in the IP header from Send_TTL in the RSVP common header. Save the result in the D-TTL field of the DIAG_RESPONSE object.
1. 新しいDIAG_RESPONSEオブジェクトを作成します。以前のRSVPホップからIPホップカウントを計算します。これは、RSVP共通ヘッダーのsend_ttlからIPヘッダーのTTL値の値を差し引くことによって行われます。結果をDIAG_RESPONSEオブジェクトのD-TTLフィールドに保存します。
2. Set the DREQ Arrival Time and the Outgoing Interface Address in the DIAG_RESPONSE object. If this node is the LAST-HOP, then the Out- going Interface Address field in the DIAG_RESPONSE object contains the following value depending on the session being diagnosed.
2. DIAG_RESPONSEオブジェクトにDREQの到着時間と発信インターフェイスアドレスを設定します。このノードが最終ホップである場合、DIAG_RESPONSEオブジェクトのアウトガーイングインターフェイスアドレスフィールドには、診断されているセッションに応じて次の値が含まれます。
* If the session in question is a unicast session, then the Out-going Interface Address field contains the address of the interface LAST-HOP uses to send PATH messages and data to the receiver specified by the session address.
* 問題のセッションがユニキャストセッションである場合、アウト進行中のインターフェイスアドレスフィールドには、ラストホップが使用するインターフェイスのアドレスが含まれており、セッションアドレスで指定されたレシーバーにパスメッセージとデータを送信します。
* Otherwise, if it is a multicast session and there is at least one receiver for this session, LAST_HOP should use the address of one of local interfaces used to reach one of the receivers.
* それ以外の場合、それがマルチキャストセッションであり、このセッションに少なくとも1つのレシーバーがある場合、last_hopはレシーバーの1つに到達するために使用されるローカルインターフェイスの1つのアドレスを使用する必要があります。
* Otherwise Outgoing Interface Address should be zero.
* それ以外の場合、発信インターフェイスアドレスはゼロにする必要があります。
3. Increment the RSVP-hop-count field in the DIAGNOSTIC message object by one.
3. 診断メッセージオブジェクトのrsvp-hop-countフィールドを1つずつ増やします。
4. If no PATH state exists for the specified session, set R-error = 0x01 (No PATH state) and goto step 7.
4. 指定されたセッションにパス状態が存在しない場合、R-Error = 0x01（パス状態なし）およびGOTOステップ7を設定します。
5. Set the rest of the fields in the DIAG_RESPONSE object. If DREQ_in contains a DIAG_SELECT object, the response object classes are those specified in the DIAG_SELECT; otherwise, they are SENDER_TSPEC, STYLE, and FLOWSPEC objects. If no reservation state exists for the specified RSVP session, the DIAG_RESPONSE object will contain no FLOWSPEC, FILTER_SPEC or STYLE object. If neither PATH nor reservation state exists for the specified RSVP session, then no response objects will be appended to the DIAG_RESPONSE object.
5. 残りのフィールドをDIAG_RESPONSEオブジェクトに設定します。DREQ_INにDIAG_SELECTオブジェクトが含まれている場合、応答オブジェクトクラスはDIAG_SELECTで指定されているものです。それ以外の場合、それらはsender_tspec、スタイル、およびflowspecオブジェクトです。指定されたRSVPセッションに予約状態が存在しない場合、DIAG_RESPONSEオブジェクトにはFlowsPec、Filter_Spec、またはスタイルオブジェクトが含まれません。指定されたRSVPセッションにパスも予約状態も存在しない場合、DIAG_Responseオブジェクトに応答オブジェクトが追加されません。
6. If RSVP-hop-count is less than Max-RSVP-hops and this node is not the sender, then the DREQ is eligible for forwarding; set the Path MTU to the min of the Path MTU and the MTU size of the incoming interface for the sender being diagnosed.
6. rsvp-hop-countがmax-rsvp-hopsよりも少なく、このノードが送信者ではない場合、Dreqは転送の対象となります。パスMTUをPATH MTUの最小に設定し、診断されている送信者の入っているインターフェイスのMTUサイズを設定します。
7. If the size of DREQ_in plus the size of the new DIAG_RESPONSE object plus the size of an IP address (if a ROUTE object exists and R-error= 0) is larger than Path MTU, then the new diagnostic message will be too large to be forwarded or returned without fragmentation; set the "packet too big" (0x02) error bit in DIAG_RESPONSE and goto Step SD1 in Send_DREP (below).
7. DREQ_INのサイズと新しいDIAG_RESPONSEオブジェクトのサイズとIPアドレスのサイズ（ルートオブジェクトが存在し、R-ERROR = 0）がPATH MTUよりも大きい場合、新しい診断メッセージは大きすぎて断片化せずに転送または返されます。diag_responseで「パケットが大きすぎる」（0x02）エラービットを設定し、send_drepでgoto step sd1（以下）に設定します。
8. If the "No PATH state" (0x01) error bit is set or if RSVP-hop-count is equal to Max-RSVP-hops or if this node is the sender, then the DREQ cannot be forwarded further; goto Step 10.
8. 「No Path State」（0x01）エラービットが設定されている場合、またはRSVP-Hop-CountがMAX-RSVP-HOPSに等しい場合、またはこのノードが送信者である場合、DREQをさらに転送することはできません。GOTOステップ10。
9. Forward the DREQ towards the sender, as follows. If a ROUTE object exists, append the "Incoming Interface Address" to the end of the ROUTE object and increment R-Pointer by one. Update the Next-Hop RSVP_HOP object, append the new DIAG_RESPONSE object to the list of DIAG_RESPONSE object, and update the message length field in the RSVP common header accordingly. Finally, recompute the checksum, forward DREQ_in to the next hop towards the sender, and return.
9. 次のように、DREQを送信者に転送します。ルートオブジェクトが存在する場合は、ルートオブジェクトの最後に「着信インターフェイスアドレス」を追加し、Rポインターを1つずつ増分します。Next-Hop RSVP_HOPオブジェクトを更新し、新しいDIAG_RESPONSEオブジェクトをDIAG_Responseオブジェクトのリストに追加し、RSVP共通ヘッダーのメッセージ長フィールドをそれに応じて更新します。最後に、チェックサムを再計算し、DREQ_INを送信者に向けて次のホップに転送し、戻ります。
10. Turn the DREQ into a DREP and return to the requester, as follows. Append the DIAG_RESPONSE object to the end of DREQ_in and update the packet length. If a ROUTE object is present in the message, decrement the R-pointer and set target address to the last address in the ROUTE object, otherwise set target address to the requester address. Change the Type Field in the Common header from DREQ to DREP. Finally, recompute the checksum, send the DREP to the target address, and return. Note that the MF bit must be off in this case.
10. 次のように、DreqをDreqをDrepに変え、Requesterに戻します。DREQ_INの終わりにDIAG_RESPONSEオブジェクトを追加し、パケットの長さを更新します。メッセージにルートオブジェクトが存在する場合は、R-pointerをDECTEMENT DECTEMENT ROUTEオブジェクトの最後のアドレスにターゲットアドレスを設定し、それ以外の場合はターゲットアドレスを要求者アドレスに設定します。共通ヘッダーのタイプフィールドをDreqからDrepに変更します。最後に、チェックサムを再計算し、ターゲットアドレスにDREPを送信し、戻ります。この場合、MFビットがオフにする必要があることに注意してください。
Send_DREP:
send_drep：
This sequence is entered if the DREQ message augmented with the new DIAG_RESPONSE object is too large to be forwarded towards the sender or, if it is not eligible for forwarding, too large to be returned as a DREP.
このシーケンスは、新しいDIAG_RESPONSEオブジェクトで補強されたDREQメッセージが送信者に向かって転送するには大きすぎる場合、または転送の資格がない場合は、DREPとして返されるには大きすぎる場合に入力されます。
SD1. Make a copy of DREQ_in and change the message type field from DREQ to DREP. Trim all DIAG_RESPONSE objects from DREQ_in and adjust the Fragment Offset. The DREP message contains the DIAG_RESPONSE objects accumulated by prior nodes.
SD1。Dreq_inのコピーを作成し、メッセージタイプフィールドをDreqからDrepに変更します。DREQ_INからすべてのDIAG_RESPONSEオブジェクトをトリミングし、フラグメントオフセットを調整します。DREPメッセージには、以前のノードによって蓄積されたDIAG_RESPONSEオブジェクトが含まれています。
SD2. Send the DREP message towards the requester, as follows. If a ROUTE object is present in the DREP message, decrement the R-pointer and set target address to the last address in the ROUTE object, otherwise set target address to the requester address. Set the MF bit, recompute the checksum and send the DREP message back to the target address.
SD2。次のように、requesterに向かってDrepメッセージを送信します。ルートオブジェクトがDREPメッセージに存在する場合は、R-pointerを減少させ、ルートオブジェクトの最後のアドレスにターゲットアドレスを設定し、それ以外の場合はターゲットアドレスを要求者アドレスに設定します。MFビットを設定し、チェックサムを再計算し、ターゲットアドレスにDrepメッセージを送り返します。
SD3. If the reduced size of DREQ_in plus the size of DIAG_RESPONSE plus the size of an IP address (if a ROUTE object exists) is smaller than or equal to Path MTU, then return to Step 8 of the main DREQ processing sequence above.
SD3。DREQ_INのサイズの縮小に加えて、DIAG_RESPONSEのサイズとIPアドレスのサイズ（ルートオブジェクトが存在する場合）がPATH MTU以下の場合は、上記のメインDREQ処理シーケンスのステップ8に戻ります。
SD4. If a ROUTE object exists, replace the ROUTE object in DREQ_in with an empty ROUTE object and turn on the "ROUTE object too big" (0x04) error bit in the DIAG_RESPONSE. In either case, return to Step 8 of the main DREQ processing sequence above.
SD4。ルートオブジェクトが存在する場合は、DREQ_INのルートオブジェクトを空のルートオブジェクトに置き換え、DIAG_RESPONSEで「ルートオブジェクトが大きすぎる」（0x04）エラービットをオンにします。どちらの場合でも、上記のメインDREQ処理シーケンスのステップ8に戻ります。
When a ROUTE object is present, DREP messages are forwarded hop-by-hop towards the requester, by reversing the route as listed in the ROUTE object. Otherwise, DREP messages are sent directly to the original requester.
ルートオブジェクトが存在する場合、ルートオブジェクトにリストされているようにルートを逆にすることにより、DREPメッセージはリクエスターにホップバイホップに転送されます。それ以外の場合、DREPメッセージは元の要求者に直接送信されます。
When a node receives a DREP message, it simply decreases R-pointer by one (address length), recomputes the checksum and forwards the message to the address pointed to by R-pointer in the route list. If a node, other than the LAST-HOP, receives a DREP packet where R-pointer is equal to zero, it must send it directly to the requester.
ノードがDREPメッセージを受信すると、R-Pointerが1つ（アドレスの長さ）を単純に減少させ、チェックサムを再構成し、ルートリストにR-Pointerで指摘されたアドレスにメッセージを転送します。ラストホップ以外のノードがrポインターがゼロに等しいDrepパケットを受信した場合、要求者に直接送信する必要があります。
When the LAST-HOP node receives a DREP message, it sends the message to the requester.
ラストホップノードがDREPメッセージを受信すると、リクエスターにメッセージを送信します。
Because the DREQ message carries the allowed MTU size of previous hops that the DREP messages will later traverse, this unique feature allows easy semantic fragmentation as described above. Whenever the DREQ message approaches the size of Path MTU, it can be trimmed before being forwarded again.
DREQメッセージには、DREPメッセージが後でトラバースするという以前のホップの許可されたMTUサイズが含まれているため、このユニークな機能により、上記のように簡単なセマンティックフラグメンテーションが可能になります。DreqメッセージがPath MTUのサイズに近づくたびに、再び転送する前にトリミングできます。
When a requester sends a DREQ message, the Path MTU field in the DIAGNOSTIC object can be set to a configured default value. It is possible that the original Path MTU value is chosen larger than the actual MTU value along some portion of the path being traced. Therefore each intermediate RSVP node must check the MTU value when processing a DREQ message. If the specified MTU value is larger than the MTU of the incoming interface (that the DREQ message will be forwarded to), the node changes the MTU value in the header to the smaller value.
要求者がDREQメッセージを送信すると、診断オブジェクトのPATH MTUフィールドを設定されたデフォルト値に設定できます。トレースされているパスの一部に沿って、実際のMTU値よりも大きい元のパスMTU値が選択される可能性があります。したがって、各中間RSVPノードは、DREQメッセージを処理するときにMTU値を確認する必要があります。指定されたMTU値が、着信インターフェイスのMTUよりも大きい場合（DREQメッセージが転送されること）、ノードはヘッダーのMTU値をより小さな値に変更します。
Whenever a DREQ message size becomes larger than the Path MTU value, an intermediate RSVP node makes a copy of the message, converts it to a DREP message to send back, and then trims off the partial results from the DREQ message. If in this case also the DREQ cannot be forwarded upstream due to a large ROUTE object, the "ROUTE object too big" is set and the ROUTE object is trimmed. As a result of the ROUTE object trimming, DREP(s) will come hop-by-hop up to this node and will then immediately be forwarded to the requester address.
DREQメッセージサイズがPATH MTU値よりも大きくなると、中間RSVPノードがメッセージのコピーを作成し、それをDREPメッセージに変換して送信し、DREQメッセージの部分的な結果をトリミングします。この場合、大きなルートオブジェクトのためにDREQを上流に転送できない場合、「ルートオブジェクトが大きすぎる」が設定され、ルートオブジェクトがトリミングされます。ルートオブジェクトのトリミングの結果として、Drep（s）はこのノードにホップバイホップに登場し、すぐにリクエスターアドレスに転送されます。
Even if the steps shown above are followed there are a few cases where fragmentation at the IP layer will happen. For example, non-RSVP hops with smaller MTUs may exist before LAST-HOP is reached, or if the response is sent directly back to requester (as opposed to hop by hop) the DREP may take a different route to the requester than the DREQ took from the requester. Another case is when there exists a link with MTU smaller than the minimum Path MTU value defined in Section 3.3.
上記の手順に従っていても、IPレイヤーでの断片化が発生するケースがいくつかあります。たとえば、Last-Hopに到達する前に、より小さなMTUを持つ非RSVPホップが存在する可能性があります。リクエスターから取った。別のケースは、セクション3.3で定義されている最小パスMTU値よりも小さいMTUのリンクが存在する場合です。
If an error condition prevents a DREP message from being forwarded further, the message is simply dropped.
エラー条件でDREPメッセージがさらに転送されるのを防ぐと、メッセージは単純に削除されます。
If an error condition, such as lack of PATH state, prevents a DREQ message from being forwarded further, the node must change the current message to DREP type and return it to the response address.
パス状態の欠如などのエラー条件で、DREQメッセージがさらに転送されるのを防ぐ場合、ノードは現在のメッセージをDREPタイプに変更し、応答アドレスに戻す必要があります。
Firewalls may cause problems in diagnostic message forwarding. Let us look at two different cases.
ファイアウォールは、診断メッセージ転送に問題を引き起こす可能性があります。2つの異なるケースを見てみましょう。
First, let us assume that the querier resides on a receiving host of the session to be examined. In this case, firewalls should not prevent the forwarding of the diagnostic messages in a hop-by-hop manner, assuming that proper holes have been punched on the firewall to allow hop-by-hop forwarding of other RSVP messages. The querier may start by not including a ROUTE object, which can give a faster response delivery and reduced overhead at intermediate nodes. However if no response is received, the querier may resend the DREQ message with a ROUTE object, specifying that a hop-by-hop reply should be sent.
まず、Querierが検査されるセッションの受信ホストに存在すると仮定しましょう。この場合、ファイアウォールは、他のRSVPメッセージのホップバイホップ転送を可能にするために、適切な穴がファイアウォールにパンチされていると仮定して、ホップバイホップの方法で診断メッセージの転送を防ぐべきではありません。Querierは、ルートオブジェクトを含めないことから始めることができます。これにより、応答の配信が速くなり、中間ノードでオーバーヘッドが削減されます。ただし、応答が受信されない場合、クエリエはルートオブジェクトでDREQメッセージを再送信する場合があり、ホップバイホップの返信を送信する必要があることを指定できます。
If the requester is a third party host and is separated from the LAST-HOP address by a firewall (either the requester is behind a firewall, or the LAST-HOP is a node behind a firewall, or both), at this time we do not know any other solution but to change the LAST-HOP to a node that is on the same side of the firewall as the requester.
リクエスターがサードパーティのホストであり、ファイアウォールによって最終ホップアドレスから分離されている場合（リクエスターがファイアウォールの背後にあるか、ラストホップがファイアウォールの背後にあるノード、またはその両方です）。他の解決策を知らないが、ラストホップをリクエスタと同じ側にあるノードに変更する。
One can easily collect information about the current timer value at each RSVP hop along the way. This will be very helpful in situations when the reservation state goes up and down frequently, to find out whether the state changes are due to improper setting of timer values, or K values (when across lossy links), or frequent routing changes.
途中で各RSVPホップで現在のタイマー値に関する情報を簡単に収集できます。これは、予約状態が頻繁に上下するときの状況では非常に役立ちます。状態の変更がタイマー値の不適切な設定、またはK値（損失のあるリンクを横切る場合）、または頻繁なルーティングの変更に起因するかどうかを調べます。
The D-TTL field in each DIAG_RESPONSE object shows the number of routing hops between adjacent RSVP nodes. Therefore any value greater than one indicates a non-RSVP cloud in between. Together with the arrival timestamps (assuming NTP works), this value can also give some vague, though not necessarily accurate, indication of how big that cloud might be. One might also find out all the intermediate non-RSVP nodes by running either unicast or multicast trace route.
各DIAG_RESPONSEオブジェクトのD-TTLフィールドには、隣接するRSVPノード間のルーティングホップの数が表示されます。したがって、1より大きい値は、その間の非RSVPクラウドを示します。到着タイムスタンプ（NTPが機能すると仮定）とともに、この値は、そのクラウドがどれほど大きいかを示す曖昧なものを示すこともできます。また、ユニキャストまたはマルチキャストトレースルートのいずれかを実行することにより、すべての中間の非RSVPノードを見つけることもできます。
The flowspec value in a DIAG_RESPONSE object specifies the amount of resources being reserved for the data stream defined by the filter spec in the same data block. When this value of adjacent DIAG_RESPONSE objects differs, that is, a downstream node Rd has a smaller value than its immediate upstream node Ru, it indicates a merge of reservation with RSVP request(s) from other down stream interface(s) at Rd. Further, in case of SE style reservation, one can examine how the different SE scopes get merged at each hop.
DIAG_RESPONSEオブジェクトのFlowsPec値は、同じデータブロックのフィルター仕様によって定義されたデータストリームに予約されているリソースの量を指定します。隣接するDIAG_RESPONSEオブジェクトのこの値が異なる場合、つまりダウンストリームノードRDの即時の上流ノードRUよりも値が少ない場合、RDの他のダウンストリームインターフェイス（S）からのRSVPリクエストとの予約のマージを示します。さらに、SEスタイルの予約の場合、各ホップで異なるSEスコープがどのようにマージされるかを調べることができます。
In particular, if a receiver sends a DREQ message before sending its own reservation, it can discover (1) how many RSVP hops there are along the path between the specified sender and itself, (2) how many of the hops already have some reservation by other receivers, and (3) possibly a rough prediction of how its reservation request might get merged with other existing ones.
特に、レシーバーが独自の予約を送信する前にDREQメッセージを送信した場合、（1）指定された送信者とそれ自体の間にパスに沿っているRSVPホップの数を発見できます。他のレシーバー、および（3）おそらく、その予約リクエストが他の既存の要求とどのように融合されるかについての大まかな予測。
In addition to examining the state of a working reservation, RSVP diagnostic messages are more likely to be invoked when things are not working correctly. For example, a receiver has reserved an adequate pipe for a specified incoming data stream, yet the observed delay or loss ratio is much higher than expected. In this case the receiver can use the diagnostic facility to examine the reservation state at each RSVP hop along the way to find out whether the RSVP state is set up correctly, whether there is any black-hole along the way that caused RSVP message losses, or whether there are non-RSVP clouds, and where they are, that may have caused the performance problem.
作業予約の状態を調べることに加えて、RSVP診断メッセージは、物事が正しく機能していないときに呼び出される可能性が高くなります。たとえば、レシーバーは指定された着信データストリームのための適切なパイプを予約していますが、観測された遅延または損失比は予想よりもはるかに高くなっています。この場合、受信者は診断施設を使用して、途中で各RSVPホップの予約状態を調べることができ、RSVPメッセージの損失を引き起こす方法に沿ってブラックホールがあるかどうか、RSVP状態が正しく設定されているかどうかを調べることができます。または、非RSVPクラウドがあるかどうか、およびそれらがどこにあるかが、パフォーマンスの問題を引き起こした可能性があります。
Since this diagnosis facility was developed and added to RSVP after a number of RSVP implementations were in place, it is possible, or even likely, that when performing RSVP diagnosis, one may encounter one or more RSVP-capable nodes that do not understand diagnostic messages and drop them. When this happens, the invoking client will get no response from its requests.
この診断施設が開発されてRSVPに追加されたため、多くのRSVP実装が実施された後、RSVP診断を実行する場合、診断メッセージを理解していない1つ以上のRSVP対応ノードに遭遇する可能性があります。そしてそれらを落とします。これが起こると、呼び出されるクライアントは要求から応答しません。
One way to by-pass such "legacy" RSVP nodes is to perform RSVP diagnosis repeatedly, guided by information from traceroute, or mtrace in case of multicast. When an RSVP diagnostic query times out (see next section), one may first use traceroute to get the list of nodes along the path, and then gradually increase the value of Max-RSVP-hops field in the DREQ message, starting from a low value until one no longer receives a response. One can then try RSVP diagnosis again by starting with the first node (which is further upstream towards the sender) after the unresponding one.
このような「レガシー」RSVPノードをバイパスする1つの方法は、マルチキャストの場合のTracerouteまたはMTRACEの情報に導かれて、RSVP診断を繰り返し実行することです。RSVP診断クエリがタイムアウトする場合（次のセクションを参照）、最初にTracerouteを使用してパスに沿ってノードのリストを取得し、次に低いメッセージから始まるDreqメッセージのMax-RSVP-Hopsフィールドの値を徐々に増やすことができます。値が応答を受信しないまで値。その後、反応のないものの後、最初のノード（これは送信者に向かってさらに上流にある）から始めることにより、RSVP診断を再度試すことができます。
There are two problem with the method mentioned above in the case of unicast sessions. Both problems are related to the fact that traceroute information provides the path from the requester to the sender. The first problem is that the LAST-HOP may not be on the path from the requester to the sender. In this case we can get information only from the portion of the path from the LAST-HOP to the sender which intersects with the path from the requester to the sender. If routers that are not on the intersection of the two paths don't have PATH state for the session being diagnosed then they will reply with R-error=0x01. The requester can overcome this problem by sending a DREQ to every router on the path (from itself to the sender) until it reaches the first router that belongs to the path from the sender to the LAST-HOP.
ユニキャストセッションの場合、上記の方法には2つの問題があります。両方の問題は、Traceroute情報がリクエスターから送信者へのパスを提供するという事実に関連しています。最初の問題は、最後のホップがリクエスターから送信者への道にない可能性があることです。この場合、パスの部分から最終ホップから送信者までのみ情報を取得できます。2つのパスの交差点にないルーターが診断されているセッションのパス状態がない場合、R-Error = 0x01で返信します。要求者は、送信者からラストホップまでのパスに属する最初のルーターに到達するまで、パス上のすべてのルーターに（それ自体）パス上のすべてのルーターにDREQを送信することにより、この問題を克服できます。
The second problem is that traceroute provides the path from the requester to the sender which, due to routing asymmetries, may be different than the path traffic from the sender to the LAST-HOP uses. There is (at least) one case where this asymmetry will cause the diagnosis to fail. We present this case below.
2番目の問題は、Tracerouteがリクエスターから送信者へのパスを提供することです。これは、ルーティングの非対称性により、送信者から最終ホップ使用までのパストラフィックとは異なる場合があります。（少なくとも）この非対称性により診断が失敗する場合があります。このケースを以下に示します。
Downstream Path Sender
__ __ __ __
Receiver +------| |<------| |<-- ...---| |-----| |
__ __ / |__| |__| |__| |__|
| |--....--|X |_/ ^
|__| |__| \ Router B |
Black \ __ |
Hole +----->| |---->---+
|__| Upstream Path
Router A
ルーターa
Figure 2
図2
Here the first hop upstream of the black hole is different on the upstream path and the downstream path. Traceroute will indicate router A as the previous hop (instead of router B which is the right one). Sending a DREQ to router A will result in A responding with R-error 0x01 (No PATH State). If the two paths converge again then the requester can use the solution proposed above to get any (partial) information from the rest of the path.
ここでは、ブラックホールの上流の最初のホップは、上流のパスとダウンストリームパスで異なります。Tracerouteは、ルーターAを前のホップとして示します（正しいルーターBの代わりに）。DREQをルーターAに送信すると、R-Error 0x01（パス状態なし）で応答します。2つのパスが再び収束する場合、要求者は上記のソリューションを使用して、残りのパスから（部分的な）情報を取得できます。
We don't have, for the moment, any complete solutions for the problematic scenarios described here.
現時点では、ここで説明する問題のあるシナリオの完全な解決策はありません。
6. Comments on Diagnostic Client Implementation.
6. 診断クライアントの実装に関するコメント。
Following the design principle that nodes in the network should not hold more than necessary state, RSVP nodes are responsible only for forwarding Diagnostic messages and filling DIAG_RESPONSE objects. Additional diagnostic functionality should be carried out by the diagnostic clients. Furthermore, if the diagnostic function is invoked from a third-party host, we should not require that host be running an RSVP daemon to perform the function. Below we sketch out the basic functions that a diagnostic client daemon should carry out.
ネットワーク内のノードが必要な状態を超えてはならないという設計原則に従って、RSVPノードは診断メッセージの転送とDIAG_RESPONSEオブジェクトの充填のみに責任を負います。追加の診断機能は、診断クライアントが実行する必要があります。さらに、診断機能がサードパーティのホストから呼び出された場合、ホストが関数を実行するためにRSVPデーモンを実行することを要求してはなりません。以下に、診断クライアントのデーモンが実行すべき基本的な機能をスケッチします。
1. Take input from the user about the session to be diagnosed, the last-hop and the sender address, the Max-RSVP-hops, and possibly the DIAG_SELECT list, create a DREQ message and send to the LAST-HOP RSVP node using raw IP message with protocol number 46 (RSVP). If the user specified that the response should be sent hop-by-hop include an empty ROUTE object to the DREQ message sent. Set the Path_MTU to the smaller of the user request and the MTU of the link through which the DREQ will be sent.
1. 診断されるセッション、最終ホップと送信者のアドレス、MAX-RSVP-HOPS、および場合によってはDIAG_SELECTリストについてユーザーから入力を受け取り、DREQメッセージを作成し、RAW IPを使用して最終ホップRSVPノードに送信しますプロトコル番号46（RSVP）のメッセージ。ユーザーが応答を送信する必要があることを指定した場合、ホップバイホップには、送信されるDREQメッセージに空のルートオブジェクトが含まれています。PATH_MTUをユーザー要求の小さなものと、DREQが送信されるリンクのMTUに設定します。
The port of the UDP socket on which the Diagnostic Client is listening for replies should be included in the Requester FILTER_SPEC object.
診断クライアントが返信を聞いているUDPソケットのポートは、Requester Filter_Specオブジェクトに含める必要があります。
2. Set a retransmission timer, waiting for the reply (one or more DREP messages). Listen to the specified UDP port for responses from the LAST-HOP RSVP node.
2. 返信タイマーを設定し、返信を待っています（1つ以上のDREPメッセージ）。最終ホップRSVPノードからの応答については、指定されたUDPポートを聞いてください。
The LAST-HOP RSVP node, upon receiving DREP messages, sends them to the Diagnostic Client as UDP packets, using the port supplied in the Requester FILTER_SPEC object.
Last-Hop RSVPノードは、DREPメッセージを受信すると、リクエスターFilter_Specオブジェクトに提供されたポートを使用して、UDPパケットとして診断クライアントに送信します。
3. Upon receiving a DREP message to an outstanding diagnostic request, the client should clear the retransmission timer, check to see if the reply contains the complete result of the requested diagnosis. If so, it should pass the result up to the invoking entity immediately.
3. 未解決の診断リクエストにDREPメッセージを受信すると、クライアントは再送信タイマーをクリアし、返信に要求された診断の完全な結果が含まれているかどうかを確認する必要があります。その場合、結果をすぐに呼び出しエンティティに渡す必要があります。
4. Reassemble DREP fragments. If the first reply to an outstanding diagnostic request contains only a fragment of the expected result, the client should set up a reassembly timer in a way similar to IP packet reassembly timer. If the timer goes off before all fragments arrive, the client should pass the partial result to the invoking entity.
4. Drep断片を再組み立てします。未解決の診断リクエストへの最初の返信に、期待される結果の断片のみが含まれている場合、クライアントはIPパケット再組み立てタイマーと同様の方法で再組み立てタイマーを設定する必要があります。すべてのフラグメントが到着する前にタイマーがオフになった場合、クライアントは部分的な結果を呼び出すエンティティに渡す必要があります。
5. Use retransmission and reassembly timers to gracefully handle packet losses and reply fragment scenarios.
5. 再送信を使用してタイマーを再組み立てして、パケットの損失を優雅に処理し、フラグメントシナリオに返信します。
In the absence of response to the first diagnostic request, a client should retransmit the request a few times. If all the retransmissions also fail, the client should invoke traceroute or mtrace to obtain the list of hops along the path segment to be diagnosed, and then perform an iteration of diagnosis with increasing hop count as suggested in Section 5.6 in order to cross RSVP-capable but diagnosis-incapable nodes.
最初の診断要求に対する応答がない場合、クライアントはリクエストを数回再送信する必要があります。すべての再送信も失敗した場合、クライアントは診断されるパスセグメントに沿ってホップのリストを取得して、RSVPを横断するためにセクション5.6で提案されているように、診断の増加と診断の反復を実行するために、トレーサーアウトまたはmTraceを呼び出す必要があります。有能であるが診断できないノード。
6. If all the above efforts fail, the client must notify the invoking entity.
6. 上記のすべての努力が失敗した場合、クライアントは呼び出しエンティティに通知する必要があります。
RSVP Diagnostics, as any other diagnostic tool, can be a security threat since it can reveal possibly sensitive RSVP state information to unwanted third parties.
RSVP診断は、他の診断ツールと同様に、不要な第三者に敏感なRSVP州情報を明らかにする可能性があるため、セキュリティの脅威になる可能性があります。
We feel that the threat is minimal, since as explained in the Introduction Diagnostics messages produce no side-effects and therefore they cannot change RSVP state in the nodes. In this respect RSVP Diagnostics is less a security threat than other diagnostic tools and protocols such as SNMP.
導入診断メッセージで説明されているように、副作用がないため、ノードでRSVP状態を変更できないため、脅威は最小限であると感じています。この点で、RSVP診断は、SNMPなどの他の診断ツールやプロトコルよりもセキュリティの脅威ではありません。
Furthermore, processing of Diagnostic messages can be disabled if it is felt that is a security threat.
さらに、セキュリティの脅威であると感じられた場合、診断メッセージの処理は無効になる可能性があります。
The idea of developing a diagnostic facility for RSVP was first suggested by Mark Handley of ACIRI. Many thanks to Lee Breslau of AT&T Labs and John Krawczyk of Nortel Networks for their valuable comments on the first draft of this memo. Lee Breslau, Bob Braden, and John Krawczyk contributed further comments after March 1996 IETF. Steven Berson provided valuable comments on various drafts of the memo. Tim Gleeson contributed an extensive list of editorial comments. We would also like to acknowledge Intel for providing a research grant as a partial support for this work. Subramaniam Vincent did most of this work while a graduate research assistant at the USC Information Sciences Institute (ISI).
RSVPの診断施設を開発するというアイデアは、AciriのMark Handleyによって最初に提案されました。AT＆T LabsのLee BreslauとNortel NetworksのJohn Krawczykに感謝します。このメモの最初のドラフトに関する貴重なコメントに感謝します。Lee Breslau、Bob Braden、およびJohn Krawczykは、1996年3月のIETFの後、さらなるコメントを提供しました。スティーブン・バーソンは、メモのさまざまなドラフトについて貴重なコメントを提供しました。ティム・グリーソンは、編集コメントの広範なリストに貢献しました。また、この作業の部分的なサポートとして研究助成金を提供してくれたIntelに感謝します。Subramaniam Vincentは、USC Information Sciences Institute（ISI）の大学院研究助手で、この作業のほとんどを行いました。
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997.
[RSVP] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル - バージョン1機能仕様」、RFC 2205、1997年9月。
[RSVPTUN] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[Rsvptun] Terzis、A.、Krawczyk、J.、Wroclawski、J。、およびL. Zhang、「RSVP Operation over IP Tunnels」、RFC 2746、2000年1月。
Andreas Terzis UCLA 4677 Boelter Hall Los Angeles, CA 90095
Andreas Terzis UCLA 4677 Boelter Hall Los Angeles、CA 90095
Phone: 310-267-2190 EMail: terzis@cs.ucla.edu
電話：310-267-2190メール：terzis@cs.ucla.edu
Bob Braden USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
Bob Braden USC Information Sciences Institute 4676 Admiralty Way Marina Del Rey、CA 90292
Phone: 310 822-1511 EMail: braden@isi.edu
電話：310 822-1511メール：braden@isi.edu
Subramaniam Vincent Cisco Systems 275, E Tasman Drive, MS SJC04/2/1 San Jose, CA 95134
Subramaniam Vincent Cisco Systems 275、E Tasman Drive、MS SJC04/2/1サンノゼ、CA 95134
Phone: 408 525 3474 EMail: svincent@cisco.com
電話：408 525 3474メール：svincent@cisco.com
Lixia Zhang UCLA 4531G Boelter Hall Los Angeles, CA 90095
Lixia Zhang UCLA 4531G Boelter Hall Los Angeles、CA 90095
Phone: 310-825-2695 EMail: lixia@cs.ucla.edu
電話：310-825-2695メール：lixia@cs.ucla.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。