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
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.
著作権（C）インターネット協会（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.
診断要求（DREQ）と診断応答（DREP）：診断機能は、2つの新しいRSVPメッセージタイプを導入します。 DREQメッセージがまたはRSVPセッションの参加者が診断対象であってもなくてもよい「依頼者」のホスト、クライアントによって発信することができます。要求元ホストにクライアントがDREQパケットを生成し、診断するRSVPの経路上にあるべきで最終ホップノードに向けて送信することにより、RSVP診断機能を呼び出します。このDREQパケットは、RSVPセッションとそのセッションの送信元のホストを指定します。それは、送信者に向かって転送されるように、それが終了ノードに到達するまでLAST-HOPから出発して、DREQパケットは、（図1参照）の情報ホップバイホップを収集します。具体的には、各RSVP-可能なホップは、指定されたRSVPセッションのためにローカルRSVP状態を含むDREQメッセージ応答（DIAG_RESPONSE）オブジェクトに追加します。
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パケットが終了ノードに到達する前に、部分応答はまた、「NOパス状態」として返されることがあり、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.
このように、診断機能実行に関与する3つのノード（ホストおよび/またはルータ）は、一般的にあります。図1に示すように、要求元ノード、開始ノードと終了ノードが、クライアントが診断機能を呼び出すことが可能です最初の2つのノードが同じであること、その場合、開始ノードに直接存在してもよいです。開始ノードを診断するためのパスセグメントの最後のホップを意味し、「LAST-HOP」と命名されます。最後のホップノードは、受信ノードまたは経路に沿った中間ノードのいずれかとすることができます。終了ノードは、通常、指定した送信元ホストです。しかしながら、クライアントは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パケットはバックリクエスタにリクエスタ直接またはホップバイホップLAST-HOPにDREQメッセージによって取られる経路の逆に沿って、及びそこに終了ノードからユニキャストすることができます。直接リターンはより速く、より効率的であるが、パケットがファイアウォールを横断する必要がある場合、ホップバイホップリバースパスルートは唯一の選択肢であってもよいです。ホップバイホップリターンDREQパケットが通過したことをノードアドレスのリストを含むように漸増構築されているオプションのルートオブジェクトを使用して達成されます。 ROUTEオブジェクトは、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メッセージは、それぞれ総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パスの状態が設定された後にのみ転送することができることに注意してください。何パス状態が存在しない場合、一方がユニキャスト/マルチキャストルーティングが正しく動作しているかどうかを調べるためにトレースルート又は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フィールド：定義：
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の診断対象：クラス= 30、C-タイプ= 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アドレスを明示的にLAST-HOPアドレスに、組み込みFILTER_SPECとRSVP_HOPオブジェクトのIPv4の形式を使用して、両方の、4バイトのIPv4形式を使用します。
o IPv6 DIAGNOSTIC object: Class = 30, C-Type = 2
O IPv6の診断対象：クラス= 30、C-タイプ= 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
マックス・RSVP-ホップ
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パケットできない場合、最大RSVPホップフィールドは単に問題の前にポイントに到達するために拡張長さの検索を実行するために使用することができます。この値が1である場合、開始ノードとクエリの終了ノードが同じになります。それがゼロの場合、ホップの制限はありません。
RSVP-hop-count
RSVPホップカウント
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）に設定する必要があります。これは、部分的な結果を運ぶ起因MTU限界まで中間ノードによって返されるすべてのDREPパケット内の1つ（1）に設定されなければなりません。 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
LAST-HOP住所
The IP address of the LAST-HOP node. The DREQ message starts collecting information at this node and proceeds toward the sender.
LAST-HOPノードの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
リクエスタ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メッセージ（S）が送信されなければならないために含まれています。
o DIAG_SELECT Class = 33, C-Type = 1.
O DIAG_SELECTクラス= 33、C-タイプ= 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_RESPONSEオブジェクトに報告すべき特定のRSVPオブジェクトを指定するDIAG_SELECTオブジェクトを含んでいてもよいです。 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_RESPONSEオブジェクトを追加します（下記参照）、そのクラス及びC型は一致パスと予約状態からDIAG_SELECTリスト内のエントリと一致する（とされています）。ゼロの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).
要求されたオブジェクトの種類に応じて、ノードは、セッションオブジェクトに記述さセッションのために記憶されているパスまたは予約状態に関連する情報を見つけることができます。 FLOWSPEC、FILTER_SPEC、CONFIRM、STYLEおよびSCOPEオブジェクトの情報は、ノードの予約状態に見出すことができるが、具体的に、RSVP_HOPための情報は、SENDER_TEMPLATE、SENDER_TSPEC、ADSPECオブジェクトは（存在する場合）、ノードのパス状態から抽出することができます。
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メッセージ（単数または複数）を返すためのソースルートとしてれるルートオブジェクトを含むことができます。
o IPv4 ROUTE object: Class = 31, C-Type = 1.
O IPv4ルートオブジェクト：クラス= 31、C-タイプ= 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を参照）に使用されるが、各ホップがROUTEオブジェクトにその着信インターフェイスアドレスを追加すると、それがインクリメントされます。
o IPv6 ROUTE object: Class = 31, C-Type = 2
O IPv6ルートオブジェクト：クラス= 31、C-タイプ= 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ノードリストは、診断対象に指定されたLAST-HOPアドレス、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.
IPv4のDIAG_RESPONSEオブジェクトO：クラス= 32、C-タイプ= 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.
IPv6のDIAG_RESPONSEオブジェクトO：クラス= 32、C-タイプ= 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
ヘック到着時間
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ビット形式は、整数部の下位16ビットと分数部分の上位16ビットであり、完全な64ビット形式の中間の32ビットからなります。
Incoming Interface Address
着信インターフェイスアドレス
Specifies the IP address of the interface on which messages from the sender are expected to arrive, or 0 if unknown.
送信者からのメッセージが不明の場合は到着し、または0と予想されているインターフェイスのIPアドレスを指定します。
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ホップルータアドレス
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 PATHメッセージを受信、または0そこからIPアドレスを指定します。これはまた、DREQが転送されるとのインタフェースです。
D-TTL
D-TTL
The number of IP hops this DREQ message traveled from the down-stream RSVP node to the current node.
IPの数は、現在のノードにダウンストリームのRSVPノードから移動このDREQメッセージをホップ。
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-エラー
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
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_SELECTオブジェクトによって決定されるDIAG_RESPONSEオブジェクトの末尾に含まれます。何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.
DREQメッセージはトンネル出口点として機能RSVPノードに到着したときに任意TUNNELオブジェクトが挿入されるべきです。
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.
TUNNELオブジェクトは診断されているエンドツーエンドの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
診断対象に指定されDREQメッセージは、送信者のアドレスへの最後のホップアドレスからユニキャストを介してホップバイホップに転送されます。最後のホップノード以外のRSVP可能なノードは、何DIAG_RESPONSEオブジェクトを含まず、ゼロを有するDREQメッセージを受信した場合
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.
フラグメントオフセット、ノードは以下のような処理のいずれかを行うことなくLAST-HOPに対する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.
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. DREQ到着時間とDIAG_RESPONSEオブジェクト内の発信インタフェースアドレスを設定します。このノードは、LAST-HOPの場合は、OUT-は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.
問題のセッションがユニキャストセッションがある場合は*、その後、アウトゴーイングインターフェイスのアドレスフィールドには、LAST-HOPは、セッションアドレスで指定された受信機にPATHメッセージやデータを送信するために使用するインターフェイスのアドレスが含まれています。
* 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.
それはマルチキャストセッションであり、このセッションのための少なくとも一つの受信機がある場合*そうでない場合、LAST_HOPは、受信機のいずれかに到達するために使用されるローカルインタフェースの一つのアドレスを使用する必要があります。
* Otherwise Outgoing Interface Address should be zero.
*それ以外の場合は発信インターフェイスアドレスはゼロでなければなりません。
3. Increment the RSVP-hop-count field in the DIAGNOSTIC message object by one.
3つによって診断メッセージオブジェクト内のRSVPホップカウントフィールドをインクリメント。
4. If no PATH state exists for the specified session, set R-error = 0x01 (No PATH state) and goto step 7.
4.パスなし状態が指定されたセッションのために存在しない場合、Rエラー= 0×01（無PATH状態）と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、STYLE、およびFLOWSPECオブジェクトです。何の予約状態が指定されたRSVPセッションのために存在しない場合は、DIAG_RESPONSEオブジェクトにはFLOWSPEC、FILTER_SPECまたはSTYLEオブジェクトが含まれていません。 PATHや予約状態も指定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ホップカウントが最大-RSVP-ホップ未満であり、このノードが送信者でない場合は、DREQは、転送の対象です。パスMTUと診断された送信者のための着信インターフェイスの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-誤差= 0の場合）、パスMTUよりも大きい場合、新しい診断メッセージがあまりにも大きくなり断片化せずに転送または返されます。 Send_DREP（下記）にDIAG_RESPONSEとGotoステップSD1で「パケットが大きすぎる」（0x02の）エラービットをセットします。
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.「いいえパス状態が」（0×01）エラービットが設定されていない場合、またはRSVPホップカウントが最大RSVPホップに等しいか、またはこのノードが送信元である場合、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ポインタをインクリメントします。 、ネクストホップ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. DREPにDREQを回して、以下のように、要求元に戻ります。 DREQ_inの端部にDIAG_RESPONSEオブジェクトを追加し、パケット長を更新します。ルートオブジェクトがメッセージに存在する場合、要求元アドレスへのR-ポインタ及びルートオブジェクト内の最後のアドレスに設定されたターゲットアドレス、そうでなければ設定されたターゲットアドレスをデクリメント。 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.
それは、DREPとして返されるには大きすぎる転送する資格がない場合は、新しいDIAG_RESPONSEオブジェクトで拡張DREQメッセージは、送信者に向けて転送するには大きすぎる場合や、このシーケンスが入力されます。
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のコピーを作成し、DREPにDREQからのメッセージ・タイプ・フィールドを変更します。 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。以下のように、依頼者の方にDREPメッセージを送信します。ルートオブジェクトはDREPメッセージ内に存在する場合、要求元アドレスにそうでなければ設定されたターゲットアドレス、ルートオブジェクト内の最後のアドレスにR-ポインタと設定されたターゲットアドレスをデクリメント。 、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アドレスのサイズは、（ルートオブジェクトが存在する場合）よりも小さいまたはパス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。 ROUTEオブジェクトが存在する場合は、空のルートオブジェクトとDREQ_inにROUTEオブジェクトを交換し、DIAG_RESPONSEで「ROUTEオブジェクトが大きすぎる」（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ポインタ（アドレス長）を減少させるチェックサムを再計算し、アドレスにメッセージを転送するルートリストにおけるR-ポインタの指します。最終ホップ以外のノードは、R-ポインタがゼロに等しいDREPパケットを受信した場合、それが要求元に直接送信しなければなりません。
When the LAST-HOP node receives a DREP message, it sends the message to the requester.
最後のホップノードが深いメッセージを受信すると、要求元にメッセージを送信します。
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メッセージは前の許容MTUサイズはDREPメッセージが後横断することホップ運ぶので、上述したように、このユニークな特徴は、容易セマンティック断片化を可能にします。 DREQメッセージがパス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メッセージを送信すると、診断対象でパスMTUフィールドが設定されたデフォルト値に設定することができます。元のパスMTU値がトレースされる経路の一部に沿って実際のMTU値よりも大きく選択されることが可能です。 DREQメッセージを処理するとき、したがって各中間RSVPノードは、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メッセージサイズがパスMTU値よりも大きくなったときはいつでも、中間RSVPノードは、メッセージのコピーが、返送するDREPメッセージに変換し、その後DREQメッセージから部分的な結果をオフにトリミングさせます。この場合にも、DREQが大きいためROUTEオブジェクトに上流に転送することができない場合は、「ROUTEオブジェクトが大きすぎる」が設定されているとROUTEオブジェクトがトリミングされます。トリミングルートオブジェクトの結果として、DREP（複数可）は、このノードまでのホップバイホップ来ると直ちに要求元アドレスに転送されます。
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層での断片化が起こる場合がいくつかあります。例えば、非RSVPは、より小さなMTUでホップ最終ホップに到達する前、または応答がDREPがDREQよりリクエスタに異なる経路を取ることができる（ホップバイホップではなく）直接バック要求者に送信された場合に存在することができます依頼者から取りました。セクション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.
ファイアウォールは、診断メッセージの転送に問題が発生することがあります。私たちは二つの異なる例を見てみましょう。
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.
まず、私たちはクエリアが検討されるように、セッションの受信ホスト上に存在すると仮定してみましょう。この場合、ファイアウォールは適切な穴が他のRSVPメッセージのホップバイホップ転送を可能にするためにファイアウォールで打ち抜かれたと仮定し、ホップバイホップの方法で診断メッセージの転送を妨げるべきではありません。クエリアは、中間ノードに速い応答送達および減少オーバーヘッドを与えることができるルートオブジェクトを含まないことによって開始することができます。応答が受信されない場合は、クエリアは、ホップバイホップ応答が送信されるべきであることを指定して、ルートオブジェクトと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.
依頼者は、サードパーティのホストであると（依頼者がファイアウォールの背後にある、またはLAST-HOPがファイアウォールの背後にあるノードである、あるいはその両方）ファイアウォールによってLAST-HOPアドレスから分離され、この時点で私たちは、そうした場合他の解決策を知っているが、依頼者とファイアウォールの同じ側にあるノードにLAST-HOPを変更することがありません。
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オブジェクト内のフロースペック値は、同じデータ・ブロック内のフィルタ仕様によって定義されたデータストリームのために確保されたリソースの量を指定します。隣接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メッセージを送信した場合、特に、それはRSVPは、指定された送信者と自身との間の経路に沿って存在するホップ（1）どのように多く発見することができ、（2）どのように多くのホップは、既にいくつかの予約を持っています他の受信機、及び（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ノードへの一つの方法は、トレースルート、またはマルチキャストの場合にMTRACEからの情報によって導かれ、繰り返しRSVP診断を実行することです。 RSVP診断クエリがタイムアウト（次の節を参照）場合、一方が第一の経路に沿ったノードのリストを取得するためにトレースルートを使用することができ、その後徐々に低いから出発し、DREQメッセージに最大RSVPホップフィールドの値を増加させます1までの値は、もはや応答を受信しません。一つは、その後unrespondingの後に（送信者に向かってさらに上流にある）最初のノードから出発して再び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の情報が送信者への依頼者からのパスを提供するという事実に関連しています。第一の問題は、LAST-HOPが送信者に依頼者からの経路上にないかもしれないということです。このケースでは、送信者への依頼者からのパスと交差する送信者にのみLAST-HOPからのパスの部分からの情報を得ることができます。 2つのパスの交点上にないルータが診断されるセッションのためにPATH状態を持っていない場合、彼らはR-エラー= 0x01をして返信します。依頼者は、それがLAST-HOPへの送信者からのパスに属する最初のルータに到達するまで（自体から送信者への）パス上のすべてのルータに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.
第二の問題は、トレースルートが原因ルーティング非対称に、LAST-HOPの送信者からパストラフィック使用するよりも異なっていてもよく、送信者に依頼者からのパスを提供することです。この非対称性は診断が失敗する原因になります（少なくとも）1ケースがあります。私たちは、以下のこのケースを提示します。
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は（代わりに右の一つであるルータBの）前のホップとしてルータAを示すであろう。 AをルータにDREQを送信すると、R-エラーは0x01（パスなしの状態）で応答になります。 2つのパスが再度収束する場合、要求者は、パスの残りの部分から任意の（部分的な）情報を取得するために、上記提案された解決策を使用することができます。
We don't have, for the moment, any complete solutions for the problematic scenarios described here.
私たちは、一瞬のために、ここで説明する問題のシナリオのいずれかの完全なソリューションを持っていません。
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
1.、診断するセッションについてユーザ、最終ホップと送信者アドレス、マックス・RSVP-ホップ、そしておそらくDIAG_SELECTリストからの入力を取るDREQメッセージを作成し、使用して最終ホップRSVPノードに送りますプロトコル番号46（RSVP）と生のIPメッセージ。ユーザは応答が送信されるべきであることを指定した場合、ホップバイホップでの空のルートオブジェクトを含みます
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.
DREQメッセージが送られました。 DREQが送信されます、それを通してユーザの要求とリンクのMTUの小さい方にPath_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ソケットのポートは、リクエスタ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.応答（一つ以上のDREPメッセージ）を待って、再送タイマーを設定します。 LAST-HOPの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.
優れた診断要求にDREPメッセージを受信すると3、クライアントは応答が要求された診断の完全な結果が含まれているかどうかをチェックし、再送タイマをクリアする必要があります。もしそうなら、それはすぐに呼び出すエンティティまでの結果を渡す必要があります。
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.
最初の診断要求に応答がない場合には、クライアントが要求を数回再送信する必要があります。すべての再送も失敗した場合、クライアントが診断するパスセグメントに沿ったホップのリストを取得するためにトレースルートやMTRACEを起動して、交差するために、5.6節で提案されているようにホップ数の増加に伴って、診断の繰り返しを実行する必要がありRSVP-できるが、診断できないノード。
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のマーク・ハンドリーによって示唆されました。このメモの最初の草案に彼らの貴重なコメントのためのAT＆T Labs社のリーブレスラウとノーテルネットワークスのジョンKrawczykに感謝します。リーブレスラウ、ボブブレーデン、ジョンKrawczykは、1996年3月IETF後にさらなるコメントを貢献しました。スティーブン・ベルソンは、メモの様々なドラフトに貴重なコメントを提供しました。ティム・グリーソンは編集上のコメントの広範なリストを貢献しました。また、この作品のための部分的なサポートとして研究助成金を提供するためにインテルを確認したいと思います。 Subramaniamヴィンセントは、USC情報科学研究所（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]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.とS.ヤミン、 "リソース予約プロトコル - バージョン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.チャン、 "RSVPオペレーションオーバーIPトンネル"、RFC 2746、2000年1月。
Andreas Terzis UCLA 4677 Boelter Hall Los Angeles, CA 90095
アンドレアスTerzis UCLA 4677 Boelterホールロサンゼルス、CA 90095
Phone: 310-267-2190 EMail: terzis@cs.ucla.edu
電話：310-267-2190 Eメール：terzis@cs.ucla.edu
Bob Braden USC Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292
ボブブレーデンUSC情報科学研究所4676アドミラルティWayマリナデルレイ、CA 90292
Phone: 310 822-1511 EMail: braden@isi.edu
電話番号：310 822-1511 Eメール：braden@isi.edu
Subramaniam Vincent Cisco Systems 275, E Tasman Drive, MS SJC04/2/1 San Jose, CA 95134
Subramaniamヴィンセントシスコシステムズ275、Eタスマン・ドライブ、MS SJC04 / 2月1日サンノゼ、CA 95134
Phone: 408 525 3474 EMail: svincent@cisco.com
電話：408 525 3474 Eメール：svincent@cisco.com
Lixia Zhang UCLA 4531G Boelter Hall Los Angeles, CA 90095
L I老人張UCLA 4531ギガバイトOEホールロサンゼルス、CA 90095
Phone: 310-825-2695 EMail: lixia@cs.ucla.edu
電話：310-825-2695 Eメール：lixia@cs.ucla.edu
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。