RFC2745 日本語訳
2745 RSVP Diagnostic Messages. A. Terzis, B. Braden, S. Vincent, L.Zhang. January 2000. (Format: TXT=52256 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Terzisがコメントのために要求するワーキンググループA.をネットワークでつないでください: 2745年のUCLAカテゴリ: 標準化過程B.ブレーデンISI S.ヴィンセントシスコシステムズL.チャンUCLA2000年1月
RSVP Diagnostic Messages
RSVP診断メッセージ
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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状態の情報を集めることができます)。 この仕様は機能性、診断メッセージ形式、および処理規則について説明します。
1. Introduction
1. 序論
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]では、エラーメッセージは終わりのホストが失敗に関して経路州か予約状態のどちらかを設立する際に反響を調べる唯一の手段です。 エラーメッセージは失敗したポイントから情報だけを戻します、失敗の前または後に他のホップの状態の少しも情報なしで。 失敗がないときホストは適所に置かれた予約の細目に関するフィードバックを全く受けません、あれほど、または、要求が他のもののものに合併されているというどこ、またはどのように、それ自身の条件。 デバッグ目的、または一般に、ネットワーク資源管理には、そのようななくなった情報は非常に望ましい場合があります。
Terzis, et al. Standards Track [Page 1] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis、他 規格はRSVP診断メッセージ2000年1月にRFC2745を追跡します[1ページ]。
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の如何にかかわらずコントロールメッセージであり、副作用を全く発生させないDiagnosticメッセージを使用します。 すなわち、彼らはノードかホストのどちらかの少しの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州の情報を集めるために、予約の要請は作られています。 より明確に、私たちはflowspecsの情報を集めることができるようになりたくて、タイマ値、および経路に沿った各ホップで合併する予約をリフレッシュしてください。
- To collect the IP hop count across each non-RSVP cloud.
- IPホップを集めるには、それぞれの非RSVP雲の向こう側に数えてください。
- 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の範囲にある既存の入場コントロールモジュールへの変更を必要とするでしょう。
2. Overview
2. 概要
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セッションの関係者であるかもしれません)。 リクエスタホストというクライアントは、LAST-HOPノードに向かってDREQパケットを生成して、それを送ることによって、RSVPの診断施設を呼び出します。診断されるために、ノードはRSVP経路にあるはずです。 このDREQパケットはそのセッションとしてRSVPセッションと送付者ホストを指定します。 LAST-HOPから始めて、送付者に向かってそれを送るとき(図1を見てください)、DREQパケットはホップごとに情報を集めます、終わりのノードに達するまで。 明確に、それぞれのRSVPできるホップは指定されたRSVPセッションのために地方のRSVP状態を含む応答(DIAG_RESPONSE)オブジェクトをDREQメッセージに追加します。
Terzis, et al. Standards Track [Page 2] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis、他 規格はRSVP診断メッセージ2000年1月にRFC2745を追跡します[2ページ]。
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パケットが終わりのノードに達するとき、メッセージタイプはDiagnostic Reply(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.
したがって、一般に、診断機能を実行するのにかかわる3つのノード(ホスト、そして/または、ルータ)があります: 図1のリクエスタノード、始めのノード、および示されるとしての終わりのノード。 最初の2つのノードが同じであることは、どの場合に診断機能を呼び出しているクライアントが始めのノードの直接上に住むかもしれないのが可能であるか。 経路セグメントの最後のホップが診断されることを意味して、始めのノードは「最後のホップ」と命名されます。 LAST-HOPノードは、経路に沿った受信機ノードか中間的ノードのどちらかであるかもしれません。 通常、終わりのノードは指定された送付者ホストです。 しかしながら、クライアントは、DREQメッセージにおけるホップカウント限界を指定することによって診断されるために経路セグメントの長さを制限できます。
LAST-HOP Ending
Receiver node node Sender
__ __ __ __ __
| |---------| |------>| |--> ...-->| |--> ...---->| |
|__| |__| DREQ |__| DREQ |__| DREQ |__|
^ . |
| . |
| DREQ . DREP | DREP
| . |
_|_ DREP V V
Requester | | <------------------------------------
(client) |___|
LAST-HOP Ending ReceiverノードノードSender__ __ __ __ __| |---------| |、-、-、-、-、--、>| |-->…-->| |-->…---->|、| |__| |__| DREQ|__| DREQ|__| DREQ|__| ^ . | | . | | DREQ DREP| DREP| . | _|_ DREP V Vリクエスタ| | <------------------------------------ (クライアント) |___|
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メッセージによってLAST-HOPと、そして、そこからリクエスタに取られた経路の逆に沿ったユニキャストであるかもしれません。 ダイレクトリターンは、より速くて、より効率的ですが、パケットがファイアウォールを越えなければならないなら、ホップごとの逆経路ルートは唯一の選択であるかもしれません。 ホップごとのリターンは任意のROUTEオブジェクト(DREQパケットが通り抜けたノードアドレスのリストを含むように増加して造られる)を使用するのに優れています。 そして、ROUTEオブジェクトは、LAST-HOPノードへのホップごとのDREPを進めるのに送信元経路として逆であり使用されます。
Terzis, et al. Standards Track [Page 3] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis、他 規格はRSVP診断メッセージ2000年1月にRFC2745を追跡します[3ページ]。
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メッセージが複数のDREPパケットを生成することができます、それぞれ総DREQメッセージの断片を含んでいて。 経路が多くのホップから成ると、終わりのノードに達する前に、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.
RSVP経路州が設立された後にだけDREQパケットを進めることができるのに注意してください。 経路州が全く存在していないなら、ユニキャスト/マルチキャストルーティングが正しく働くかどうか調べるためにトレースルートかmtrace施設に頼るかもしれません。
3. Diagnostic Packet Format
3. 診断パケット・フォーマット
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 Common Headerから成ります。 以下の系列を使用しなければなりません:
Terzis, et al. Standards Track [Page 4] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis、他 規格はRSVP診断メッセージ2000年1月にRFC2745を追跡します[4ページ]。
+-----------------------------------+
| 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|
+-----------------------------------+
+-----------------------------------+ | RSVPの一般的なヘッダー| +-----------------------------------+ | セッションオブジェクト| +-----------------------------------+ | 次のホップRSVP_HOPオブジェクト| +-----------------------------------+ | DIAGNOSTICオブジェクト| +-----------------------------------+ | (任意)です。 DIAG_SELECTオブジェクト| +-----------------------------------+ | (任意)です。 ROUTEオブジェクト| +-----------------------------------+ | ゼロか、より多くのDIAG_RESPONSEオブジェクト| +-----------------------------------+
The session object identifies the RSVP session for which the state information is being collected. We describe each of the other parts.
セッションオブジェクトは州の情報が集められているRSVPセッションを特定します。 私たちはそれぞれの他の部品について説明します。
3.1. RSVP Message Common Header
3.1. 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メッセージであり、DIAGNOSTICオブジェクト(以下を見る)のMF旗が設定されるなら、この分野は完全なDREP応答メッセージ(一般に、あらかじめ、知ることができない)の全長よりむしろこのただ一つのDREP断片の長さを示します。
3.2. Next-Hop RSVP_HOP Object
3.2. 次のホップRSVP_ホップオブジェクト
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によって引き起こされた問題を避けるのは曇ります。
Terzis, et al. Standards Track [Page 5] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis、他 規格はRSVP診断メッセージ2000年1月にRFC2745を追跡します[5ページ]。
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_HOPの使用がある一貫性には、他のRSVPメッセージ(DREQが送られたインタフェースのアドレスを含むRSVP_HOPオブジェクトのIPアドレス)で反対してください。
3.3. DIAGNOSTIC Object
3.3. 診断オブジェクト
A DIAGNOSTIC object contains the common diagnostic control information in both DREQ and DREP messages.
DIAGNOSTICオブジェクトはDREQとDREPメッセージの両方に一般的な診断制御情報を含んでいます。
o IPv4 DIAGNOSTIC object: Class = 30, C-Type = 1
o IPv4 DIAGNOSTICは反対します: クラスは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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | マックスRSVPホップ| RSVPホップカウント| 予約されます。|mf| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IDを要求してください。| +---------------+---------------+---------------+---------------+ | 経路MTU| 断片オフセット| +---------------+---------------+---------------+---------------+ | 最後にアドレスを飛び越してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | SENDER_TEMPLATEオブジェクト| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | リクエスタFILTER_SPECオブジェクト| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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形式であると扱って、両方が、LAST-HOP Addressと埋め込まれたFILTER_SPECとRSVP_HOPのIPv4フォームを使用することによって、明らかに反対します。
o IPv6 DIAGNOSTIC object: Class = 30, C-Type = 2
o IPv6 DIAGNOSTICは反対します: クラスは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
どの情報の上でRSVPホップの最大数を指定する八重奏は集められるでしょう。 経路の中央のエラー条件が、DREQパケットが指定された終わりのノードに達するのを防ぐなら、マックスRSVPホップ分野は、ちょうど以前ポイントに達するように拡張長さの検索を実行するのに使用されるかもしれません。
Terzis, et al. Standards Track [Page 6] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis、他 規格はRSVP診断メッセージ2000年1月にRFC2745を追跡します[6ページ]。
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.
問題。 この値が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断片があるところでは、示します。 最初の断片はゼロを相殺しました。 断片Offsetは、また、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.
Request IDを定義する1つの可能な方法が、プロセスのIDを指定するのにこのプロセスと異なった質問を区別するために質問と16ビットを作りながら、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パケットはCommon Header、Sessionオブジェクト、Next-ホップRSVP_HOPオブジェクト、DIAGNOSTICオブジェクト、空のROUTEオブジェクト、および独身のデフォルトDIAG_RESPONSEを含むもの(以下を見る)です。 ここでされた仮定はIP断片化なしでこのサイズの診断パケットをいつも進めることができるということです。
Terzis, et al. Standards Track [Page 7] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis、他 規格はRSVP診断メッセージ2000年1月にRFC2745を追跡します[7ページ]。
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.
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
リクエスタフィルタ_仕様オブジェクト
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オブジェクトは要求が起因して、DREPメッセージが送られるべきであるIPアドレスとポートを含んでいます。
3.4. DIAG_SELECT Object
3.4. DIAG_選択オブジェクト
o DIAG_SELECT Class = 33, C-Type = 1.
o DIAGの_の選んだクラスは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).
Diagnosticメッセージは任意にどの特定のRSVPオブジェクトがDIAG_RESPONSEオブジェクトで報告されるべきであるかを指定する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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クラス| C-タイプ| クラス| C-タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | クラス| C-タイプ| クラス| C-タイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ノードはクラスとC-タイプがDIAG_SELECTリスト(そして、合っている経路と予約状態から、ある)におけるエントリーに合っている応答オブジェクト(以下を見る)を含むDIAG_RESPONSEオブジェクトを加えるでしょう。 ゼロのC-タイプ八重奏は関連クラスに関連しているどんなC-タイプにも合っている'ワイルドカード'です。
Terzis, et al. Standards Track [Page 8] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis、他 規格はRSVP診断メッセージ2000年1月にRFC2745を追跡します[8ページ]。
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).
要求されたオブジェクトのタイプに頼っていて、ノードはSESSIONオブジェクトで説明されたセッションのために保存された経路か予約状態で関連情報を見つけることができます。 RSVP_HOPのための明確に情報、SENDER_TEMPLATE、SENDER_TSPEC、ノードの経路州からADSPECオブジェクトを抽出できます、ノードの予約状態でFLOWSPEC、FILTER_SPEC、CONFIRM、様式、およびSCOPEオブジェクトのための情報を見つけることができますが(目下なら)。
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オブジェクトはDiagnostic質問で要求できるすべてのRSVPオブジェクトのための[クラス、Cタイプ]組を含むものです。
3.5. ROUTE Object
3.5. ルートオブジェクト
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.
診断メッセージはROUTEオブジェクトを含むかもしれません、そして、戻るための送信元経路として、DREPメッセージはホップで跳びます。(オブジェクトは、DREQメッセージのルートを記録するのに使用されます)。
o IPv4 ROUTE object: Class = 31, C-Type = 1.
o IPv4 ROUTEは反対します: クラスは31、C-タイプ=1と等しいです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved | R-pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ RSVP Node List |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 予約されます。| R-指針| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + RSVPノードリスト| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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パケットをリクエスタに送るべきです。 存在しているなら、ホップごとに逆の経路に沿ってLAST-HOPノードと、そして、そこからリクエスタノードにDREPパケットを返さなければなりません。
An empty ROUTE object is one that has an empty RSVP Node list and R- pointer is equal to zero.
空のROUTEオブジェクトは空のRSVP Nodeリストを持っているものです、そして、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オブジェクトで入って来るインターフェース・アドレスを加えるのに従って、それは増加されています。
Terzis, et al. Standards Track [Page 9] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis、他 規格はRSVP診断メッセージ2000年1月にRFC2745を追跡します[9ページ]。
o IPv6 ROUTE object: Class = 31, C-Type = 2
o IPv6 ROUTEは反対します: クラスは31、C-タイプ=2と等しいです。
The same, except RSVP Node List contains IPv6 addresses.
同じように、RSVP Node Listを除いてください。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 Node ListはDIAGNOSTICオブジェクトで指定されたLAST-HOPアドレスと、DREQメッセージが訪問した最後のRSVPノードの間のすべてのRSVPホップを指定します。 DREPメッセージでは、RSVP Node ListはLAST-HOPとこのDREPメッセージを返すノードの間のすべてのRSVPホップを指定します。
3.6. DIAG_RESPONSE Object
3.6. DIAG_応答オブジェクト
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は反対します: クラスは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 //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DREQ到着時間| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 入って来るインターフェース・アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 外向的なインターフェース・アドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 前のRSVPホップルータアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | D-TTL|M|Rで間違えてください。| K| タイマ値| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | (任意)です。 TUNNELオブジェクト| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | //応答オブジェクト//| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o IPv6 DIAG_RESPONSE object: Class = 32, C-Type = 2.
o IPv6 DIAG_RESPONSEは反対します: クラスは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:
分野は以下の通りです:
Terzis, et al. Standards Track [Page 10] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis、他 規格はRSVP診断メッセージ2000年1月にRFC2745を追跡します[10ページ]。
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.
未知であるなら、送付者からのメッセージが到着すると予想されるインタフェース、または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.
未知であるなら、このノードがこのソース、または0つのソースへのRSVP PATHメッセージを受け取る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.
このDREQメッセージが下であるのから旅行したIPホップの数は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.
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:
A 3-bit field that indicates error conditions at a node. Currently defined values are:
0x00: no error
0x01: No PATH state
0x02: packet too big
0x04: ROUTE object too big
0x00: no error 0x01: No PATH state 0x02: packet too big 0x04: ROUTE object too big
Terzis, et al. Standards Track [Page 11] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis, et al. Standards Track [Page 11] RFC 2745 RSVP Diagnostic Messages January 2000
K
K
The refresh timer multiple (defined in [RSVP]).
The refresh timer multiple (defined in [RSVP]).
Timer value
Timer value
The local refresh timer value in seconds.
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:
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:
SENDER_TSPEC object FILTER_SPEC object FLOWSPEC object
STYLE object
SENDER_TSPEC object FILTER_SPEC object FLOWSPEC object STYLE object
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.
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.
A default DIAG_RESPONSE object is one containing the default list of classes described above.
A default DIAG_RESPONSE object is one containing the default list of classes described above.
3.7. TUNNEL Object
3.7. TUNNEL Object
The optional TUNNEL object should be inserted when a DREQ message arrives at an RSVP node that acts as a tunnel exit point.
The optional TUNNEL object should be inserted when a DREQ message arrives at an RSVP node that acts as a tunnel exit point.
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.
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.
The tunnel object is defined in the RSVP Tunnel Specification [RSVPTUN].
The tunnel object is defined in the RSVP Tunnel Specification [RSVPTUN].
4. Diagnostic Packet Forwarding Rules
4. Diagnostic Packet Forwarding Rules
4.1. DREQ Packet Forwarding
4.1. DREQ Packet Forwarding
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 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
Terzis, et al. Standards Track [Page 12] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis, et al. Standards Track [Page 12] RFC 2745 RSVP Diagnostic Messages January 2000
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.
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.
Processing begins when a DREQ message, DREQ_in, arrives at a node.
Processing begins when a DREQ message, DREQ_in, arrives at a node.
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. 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. 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.
* 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.
* 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.
* 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.
* Otherwise Outgoing Interface Address should be zero.
* Otherwise Outgoing Interface Address should be zero.
3. Increment the RSVP-hop-count field in the DIAGNOSTIC message
object by one.
3. Increment the RSVP-hop-count field in the DIAGNOSTIC message object by one.
4. If no PATH state exists for the specified session, set R-error
= 0x01 (No PATH state) and goto step 7.
4. If no PATH state exists for the specified session, set R-error = 0x01 (No PATH state) and goto step 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. 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.
Terzis, et al. Standards Track [Page 13] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis, et al. Standards Track [Page 13] RFC 2745 RSVP Diagnostic Messages January 2000
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. 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.
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. 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).
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. 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.
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. 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.
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. 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.
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.
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.
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. 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.
Terzis, et al. Standards Track [Page 14] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis, et al. Standards Track [Page 14] RFC 2745 RSVP Diagnostic Messages January 2000
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. 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.
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. 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.
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. 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.
4.2. DREP Forwarding
4.2. DREP Forwarding
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.
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.
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.
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.
When the LAST-HOP node receives a DREP message, it sends the message to the requester.
When the LAST-HOP node receives a DREP message, it sends the message to the requester.
4.3. MTU Selection and Adjustment
4.3. MTU Selection and Adjustment
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.
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.
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
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
Terzis, et al. Standards Track [Page 15] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis, et al. Standards Track [Page 15] RFC 2745 RSVP Diagnostic Messages January 2000
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.
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.
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.
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.
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.
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.
4.4. Errors
4.4. Errors
If an error condition prevents a DREP message from being forwarded further, the message is simply dropped.
If an error condition prevents a DREP message from being forwarded further, the message is simply dropped.
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.
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.
5. Problem Diagnosis by Using RSVP Diagnostic Facility
5. Problem Diagnosis by Using RSVP Diagnostic Facility
5.1. Across Firewalls
5.1. Across Firewalls
Firewalls may cause problems in diagnostic message forwarding. Let us look at two different cases.
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.
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.
Terzis, et al. Standards Track [Page 16] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis, et al. Standards Track [Page 16] RFC 2745 RSVP Diagnostic Messages January 2000
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.
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.
5.2. Examination of RSVP Timers
5.2. Examination of RSVP Timers
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.
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.
5.3. Discovering Non-RSVP Clouds
5.3. Discovering Non-RSVP Clouds
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.
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.
5.4. Discovering Reservation Merges
5.4. Discovering Reservation Merges
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.
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.
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.
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.
Terzis, et al. Standards Track [Page 17] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis, et al. Standards Track [Page 17] RFC 2745 RSVP Diagnostic Messages January 2000
5.5. Error Diagnosis
5.5. Error Diagnosis
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.
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.
5.6. Crossing "Legacy" RSVP Routers
5.6. Crossing "Legacy" RSVP Routers
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.
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.
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.
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.
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.
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.
Terzis, et al. Standards Track [Page 18] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis, et al. Standards Track [Page 18] RFC 2745 RSVP Diagnostic Messages January 2000
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.
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.
Downstream Path Sender
__ __ __ __
Receiver +------| |<------| |<-- ...---| |-----| |
__ __ / |__| |__| |__| |__|
| |--....--|X |_/ ^
|__| |__| \ Router B |
Black \ __ |
Hole +----->| |---->---+
|__| Upstream Path
Downstream Path Sender __ __ __ __ Receiver +------| |<------| |<-- ...---| |-----| | __ __ / |__| |__| |__| |__| | |--....--|X |_/ ^ |__| |__| \ Router B | Black \ __ | Hole +----->| |---->---+ |__| Upstream Path
Router A
Router A
Figure 2
Figure 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.
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.
We don't have, for the moment, any complete solutions for the problematic scenarios described here.
We don't have, for the moment, any complete solutions for the problematic scenarios described here.
6. Comments on Diagnostic Client Implementation.
6. Comments on Diagnostic Client Implementation.
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.
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.
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. 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
Terzis, et al. Standards Track [Page 19] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis, et al. Standards Track [Page 19] RFC 2745 RSVP Diagnostic Messages January 2000
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 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.
The port of the UDP socket on which the Diagnostic Client is
listening for replies should be included in the Requester
FILTER_SPEC object.
The port of the UDP socket on which the Diagnostic Client is listening for replies should be included in the Requester FILTER_SPEC object.
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. 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.
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.
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.
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. 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.
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. 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.
5. Use retransmission and reassembly timers to gracefully handle
packet losses and reply fragment scenarios.
5. Use retransmission and reassembly timers to gracefully handle packet losses and reply fragment scenarios.
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.
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.
6. If all the above efforts fail, the client must notify the
invoking entity.
6. If all the above efforts fail, the client must notify the invoking entity.
Terzis, et al. Standards Track [Page 20] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis, et al. Standards Track [Page 20] RFC 2745 RSVP Diagnostic Messages January 2000
7. Security Considerations
7. Security Considerations
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 Diagnostics, as any other diagnostic tool, can be a security threat since it can reveal possibly sensitive RSVP state information to unwanted third parties.
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.
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.
Furthermore, processing of Diagnostic messages can be disabled if it is felt that is a security threat.
Furthermore, processing of Diagnostic messages can be disabled if it is felt that is a security threat.
8. Acknowledgments
8. Acknowledgments
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).
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).
9. References
9. References
[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. and S. Jamin, "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997.
[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.チャン、「IP Tunnelsの上のRSVP操作」、RFC2746、2000年1月。
Terzis, et al. Standards Track [Page 21] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis、他 規格はRSVP診断メッセージ2000年1月にRFC2745を追跡します[21ページ]。
10. Authors' Addresses
10. 作者のアドレス
Andreas Terzis UCLA 4677 Boelter Hall Los Angeles, CA 90095
アンドレアスTerzis UCLA4677Boelter Hallロサンゼルス、カリフォルニア 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
ボブブレーデンUSC情報Sciences Institute4676海軍本部Wayマリナデルレイ、カリフォルニア 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
MS SJC04/2/1サンノゼ、カリフォルニア サブラマニアムヴィンセントシスコシステムズ275、Eタスマンのドライブ、95134
Phone: 408 525 3474 EMail: svincent@cisco.com
以下に電話をしてください。 3474年の408 525メール: svincent@cisco.com
Lixia Zhang UCLA 4531G Boelter Hall Los Angeles, CA 90095
Lixiaチャン・UCLA 4531G Boelter Hallロサンゼルス、カリフォルニア 90095
Phone: 310-825-2695 EMail: lixia@cs.ucla.edu
以下に電話をしてください。 310-825-2695 メールしてください: lixia@cs.ucla.edu
Terzis, et al. Standards Track [Page 22] RFC 2745 RSVP Diagnostic Messages January 2000
Terzis、他 規格はRSVP診断メッセージ2000年1月にRFC2745を追跡します[22ページ]。
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Terzis, et al. Standards Track [Page 23]
Terzis、他 標準化過程[23ページ]
一覧
スポンサーリンク
