RFC2092 日本語訳
2092 Protocol Analysis for Triggered RIP. S. Sherry, G. Meyer. January 1997. (Format: TXT=10865 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Sherry
Request for Comments: 2092 Xyplex
Category: Informational G. Meyer
Shiva
January 1997
コメントを求めるワーキンググループS.シェリー酒の要求をネットワークでつないでください: 2092年のXyplexカテゴリ: 情報のG.マイヤーシバ神1997年1月
Protocol Analysis for Triggered RIP
引き起こされた裂け目のためのプロトコル分析
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
As required by Routing Protocol Criteria [1], this report documents the key features of Triggered Extensions to RIP to Support Demand Circuits [2] and the current implementation experience.
必要に応じて、ルート設定プロトコルCriteria[1]で、このレポートはSupport Demand Circuits[2]と現在の実現経験へのRIPにTriggered Extensionsに関する重要な特色を記録します。
As a result of the improved characteristics of Triggered RIP, it is proposed that Demand RIP [5] be obsoleted.
Triggered RIPの改良された特性の結果、Demand RIP[5]が時代遅れにされるよう提案されます。
Acknowledgements
承認
The authors wish to thank Johanna Kruger and Jim Pearl of Xyplex for many comments and suggestions which improved this effort.
作者はこの努力を改良した多くのコメントと提案についてXyplexのヨハンナ・クルーガーとジムPearlに感謝したがっています。
1. Protocol Documents
1. プロトコルドキュメント
"Triggered Extensions to RIP to Support Demand Circuits" [2] suggests an enhancement to the "Routing Internet Protocol" (RIP) [3] and "RIP-2" [4] to allow them to run more cost-effectively on Wide Area Networks (WANs).
「Support Demand CircuitsへのRIPへの引き起こされたExtensions」[2]は「ルート設定インターネットプロトコル」(RIP)[3]と「ワイドエリアネットワーク(WAN)をより費用効率よく走るのを許容するリップ-2インチ[4]」に増進を示します。
2. Applicability
2. 適用性
Triggered RIP requires that there is an underlying mechanism for determining unreachability in a finite predictable period.
引き起こされたRIPは、有限予測できる時代に「非-可到達性」を決定するための発症機序があるのを必要とします。
The triggered extensions to RIP are particularly appropriate for WANs where the cost - either financial or packet overhead - would make periodic transmission of routing (or service advertising) updates unacceptable:
WANには、RIPへの引き起こされた拡大は費用(財政的であるかパケットオーバーヘッド)がルーティング(または、サービス広告)アップデートの周期的な送信を容認できなくするところで特に適切です:
o Connection oriented Public Data Networks - for example X.25 packet
switched networks or ISDN.
o 接続はPublic Data Networksを適応させました--例えば、X.25パケット交換網かISDN。
Sherry & Meyer Informational [Page 1] RFC 2092 Triggered RIP Protocol Analysis January 1997
[1ページ]RFC2092の引き起こされた裂け目のプロトコル分析1997年1月の情報のシェリー酒とマイヤー
o Point-to-point links supporting PPP link quality monitoring or
echo request to determine link failure.
o PPPを支持するポイントツーポイント接続が上質のモニターかリンクの故障を決定するというエコー要求をリンクします。
A triggered RIP implementation runs standard RIP on Local Area Networks (LANs) allowing them to interoperate transparently with implementations adhering to the original specifications.
実現が正式仕様書を固く守っていて彼らが透明に共同利用するのを許容しながら、引き起こされたRIP実現はローカル・エリア・ネットワーク(LAN)で標準のRIPを走らせます。
3. Key Features
3. 重要な特色
The proposal shares the same basic algorithms as RIP or RIP-2 when running on LANs; Packet formats, broadcast frequency, triggered update operation and database timeouts are all unmodified.
LANで動くとき、提案はRIPかRIP-2と同じ基本的なアルゴリズムを共有します。 パケット・フォーマット(放送頻度)はアップデート操作の引き金となりました、そして、データベースタイムアウトはすべて変更されていません。
The new features operate on WANs which use switched circuits on demand to achieve intermittent connectivity; Or on permanent WAN connections where there is a desire to keep routing packet overhead to a minimum. Instead of using periodic 'broadcasts', information is only sent as triggered updates. The proposal makes use of features of the underlying connection oriented service to provide feedback on connectivity.
新機能は間欠接続性を達成することにおけるオンデマンドの交換回線網を使用するWANを作動させます。 または、永久的なWAN接続のときに、そこのどこがルーティングパケットオーバーヘッドを最小に抑える願望であるか。 周期的な'放送'を使用することの代わりに、引き起こされたアップデートとして情報を送るだけです。 提案は基本的なコネクション型サービスが接続性のフィードバックを提供する特徴を利用します。
3.1 Triggered Updates
3.1 引き起こされたアップデート
Updates are only sent on the WAN when an event changes the routing database. Each update is retransmitted until acknowledged. Information received in an update is not timed out.
出来事がルーティングデータベースを変えるときだけ、WANでアップデートを送ります。 各アップデートは承認されるまで再送されます。 アップデートで受け取られた情報は外で調節されていません。
The packet format of a RIP response is modified (with a different unique command field) to include sequence number information. An acknowledgement packet is also defined.
RIP応答のパケット・フォーマットは、一連番号情報を含むように変更されます(異なったユニークなコマンド欄で)。 また、確認応答パケットは定義されます。
3.2 Circuit Manager
3.2 サーキットマネージャ
The circuit manager running below the IP network layer is responsible for establishing a circuit to the next hop router whenever there is data (or a routing update) to transfer. After a period of inactivity the circuit will be closed by the circuit manager.
IPネットワーク層の下へ走っているサーキットマネージャは移すデータ(または、ルーティングアップデート)があるときはいつも、次のホップルータにサーキットを確立するのに責任があります。 不活発の期間の後に、サーキットはサーキットマネージャによって閉じられるでしょう。
If the circuit manager fails to make a connection a circuit down indication is sent to the routing application. The circuit manager will then attempt at (increasing) intervals to establish a connection. When successful a circuit up indication is sent to the routing application.
サーキットマネージャが接続にならないなら、サーキット下に指示をルーティングアプリケーションに送ります。 そして、サーキットマネージャは、取引関係を築くのを(増加すること)の間隔で、試みるでしょう。 うまくいくとき、指示へのサーキットをルーティングアプリケーションに送ります。
Sherry & Meyer Informational [Page 2] RFC 2092 Triggered RIP Protocol Analysis January 1997
[2ページ]RFC2092の引き起こされた裂け目のプロトコル分析1997年1月の情報のシェリー酒とマイヤー
3.3 Technology Restrictions
3.3 技術制限
There is a small but nontrivial possiblility of an incorrectly configured or poorly operating link causing severe data loss, resulting in a 'black hole' in routing. This is often unidirectional - the link that route updates cross works properly, but not the return path.
不当に構成されたか、操作リンクの引き起こす不十分に厳しいデータの損失の小さい、しかし、重要なpossiblilityがあります、ルーティングで'ブラックホール'をもたらして。 しばしばこれは単方向です--ルートアップデートが越えるリンクが適切に働いていますが、リターンパスは働いていません。
Triggered RIP will NOT fuction properly (and should NOT be used) if a routing information will be retained/advertised for an arbitrarily long period of time (until an update in the opposite direction fails to obtain a response).
ルーティング情報が時間の任意に長い期間、保有されるか、または広告に掲載されるなら(逆方向へのアップデートが応答を得ないまで)、引き起こされたRIPは適切(そして、使用するべきでない)にどんなfuctionも望んでいません。
To detect black holes in technologies which use PPP encapsulation, either Echo Request/Response or Link Quality Monitoring should be used. When a black hole is detected a circuit down indication must be sent to the routing application.
PPPカプセル化を使用する技術でブラックホールを検出するために、Echo Request/応答かLink Quality Monitoringのどちらかが使用されるべきです。 ブラックホールを検出するとき、サーキット下に指示をルーティングアプリケーションに送らなければなりません。
Current (and future) technologies which do not use PPP, need to use an equivalent 'are-you-there' mechanism - or should NOT be used with Triggered RIP.
PPPを使用しない現在の、そして、(将来)の技術、同等な'あなたはそこにいる'メカニズムを使用するのが必要であるべきでない、Triggered RIPと共に使用するべきではありません。
3.4 Presumption of Reachability
3.4 可到達性の推定
In a stable network there is no requirement to propagate routing information on a circuit, so if no routing information is (being) received on a circuit it is assumed that:
安定したネットワークでは、サーキットの上にルーティング情報を伝播するという要件が全くないので、どんなルーティング情報もサーキットで受け取られていている(存在)でないなら以下のことと思われます。
o The most recently received information is accurate.
o 最も最近受信された情報は正確です。
o The intervening path is operational (although there may be no
current connection).
o 介入している経路は操作上です(どんな現在の接続もないかもしれませんが)。
If the circuit manager determines that the intervening path is NOT operational routing information previously received on that circuit is timed out. It is worth stressing that it can be ANY routed datagram which triggers the event.
サーキットマネージャが、介入している経路がNOTの操作上のルーティングであると決心しているなら、以前にそのサーキットの上に受け取られた情報は外で調節されています。 それが出来事の引き金となるどんな発送されたデータグラムであるかもしれないとも強調する価値があります。
When the circuit manager re-establishes a connection, the application exchanges full routing information with its peer.
サーキットマネージャが接続を復職させるとき、アプリケーションは完全なルーティング情報を同輩と交換します。
3.5 Routing Information Flow Control
3.5経路情報フロー制御
If the circuit manager reports a circuit as down, the routing application is flow controlled from sending further information on the circuit.
サーキットマネージャが下がっている同じくらいサーキットを報告するなら、ルーティングアプリケーションはサーキットに関する詳細を送るので制御された流れです。
Sherry & Meyer Informational [Page 3] RFC 2092 Triggered RIP Protocol Analysis January 1997
[3ページ]RFC2092の引き起こされた裂け目のプロトコル分析1997年1月の情報のシェリー酒とマイヤー
4. Relationship to Demand RIP
4. 裂くように要求する関係
The Triggered RIP proposal [2] has a number of efficiency advantages over the Demand RIP proposal [5]:
Triggered RIP提案[2]には、Demand RIP提案[5]より多くの効率利点があります:
o When routing information changes Demand RIP sends the full
database to its partner.
o 情報変化を発送するとき、Demand RIPは完全なデータベースをパートナーに送ります。
Once a router has exchanged all routing information with its
partner, Triggered RIP sends only the changed information to the
partner. This can dramatically decrease the quantity of
information requiring propagation when a route change occurs.
ルータがいったんすべてのルーティング情報をパートナーと交換すると、Triggered RIPは変えられた情報だけをパートナーに送ります。 これはルート変化が起こると伝播を必要とする情報の量を劇的に減少させることができます。
o Demand RIP requires a full routing update to be stored by the
receiver, before applying changes to the routing database.
o 要求RIPは、ルーティングデータベースに変化を適用する前に完全なルーティングアップデートが受信機によって格納されるのを必要とします。
A Triggered RIP receiver is able to apply all changes immediately
upon receiving each packet from its partner. Systems therefore
need to use less memory than Demand RIP.
Triggered RIP受信機はすぐパートナーから各パケットを受けるときのすべての変化を適用できます。 したがって、システムは、Demand RIPより少ないメモリを使用する必要があります。
o Demand RIP has an upper limit of 255 fragments in an update. This
sets an upper limit on the sizes of routing and service
advertising databases which can be propagated.
o 要求RIPはアップデートで255個の断片の上限を持っています。 これはルーティングと伝播できるサービス広告データベースのサイズに上限を設定します。
This restriction is lifted in Triggered RIP (which does not use
fragmentation).
この制限はTriggered RIP(断片化を使用しない)で提案されます。
In all other respects Demand RIP and Triggered RIP perform the same function.
全部で、他のあいさつのDemand RIPとTriggered RIPは同じ機能を実行します。
5. Obsoleting Demand RIP
5. 要求を時代遅れにして、裂いてください。
While it is possible that systems could be able to support Demand RIP and Triggered RIP, the internal maintenance of structures is likely to differ significantly. The method of propagating the information also differs significantly. In practice it is unlikely that systems would support Demand RIP and Triggered RIP.
システムがDemand RIPとTriggered RIPを支持できるかもしれないのが、可能ですが、構造の内部の維持は有意差がありそうです。 また、情報を伝播する方法は有意差があります。 実際には、システムがDemand RIPとTriggered RIPを支持するのは、ありそうもないです。
As a result of the improved characteristics of Triggered RIP, it is proposed that Demand RIP [5] be obsoleted.
Triggered RIPの改良された特性の結果、Demand RIP[5]が時代遅れにされるよう提案されます。
6. Implementations
6. 実現
At this stage there are believed to be two completed implementation.
あるこの段階では、信じられていて、2であることは実現を終了しました。
Sherry & Meyer Informational [Page 4] RFC 2092 Triggered RIP Protocol Analysis January 1997
[4ページ]RFC2092の引き起こされた裂け目のプロトコル分析1997年1月の情報のシェリー酒とマイヤー
The Xyplex implementation supports all the features outlined for IP RIP-1, IP RIP-2, IPX RIP, and IPX SAP. However, it only supports one outstanding acknowledgement per partner. The implementation has been tested against itself on X.25, ISDN, Frame Relay, V42bis CSU/DSUs, and asynchronous modems. It has also been tested in operation with various router and host implementations on Ethernet LANs.
Xyplex実現はIP RIP-1、IP RIP-2、IPX RIP、およびIPX SAPのために概説されたすべての特徴を支持します。 しかしながら、それは1パートナーあたり1つの傑出している承認しか支持しません。 実現はX.25、ISDN、Frame Relay、V42bis CSU/DSUs、および非同期モデムの上でそれ自体に対してテストされました。また、様々なルータとホスト実現がイーサネットLANにある状態で、それは稼働中でありテストされました。
The DEC implementation supports IP RIP-1 over ISDN, Frame Relay, leased lines and V.25bis. The Xyplex and DEC IP RIP-1 implementations have been checked for interoperability over ISDN without problems.
12月の実現はISDN、Frame Relay、専用線、およびV.25bisの上でIP RIP-1を支持します。 相互運用性がないかどうかISDNの上で問題なしでXyplexとDEC IP RIP-1実現をチェックしてあります。
7. Restrictions
7. 制限
Demand RIP relies on the ability to place a call in either direction. Some dialup services - for example DTR dialing - allow calls to be made in one direction only.
要求RIPは電話をどちらの方向にもする能力を当てにします。 サービス(例えば、DTRのダイヤルする)が許容する何らかのダイアルアップが、一方向だけに作られているために呼びます。
Demand RIP can not operate with third-party advertisement of routes on the WAN. The next hop IP address in RIP-2 should always be 0.0.0.0 for any routes advertised on the WAN.
ルートの第三者広告がWANにある状態で、要求RIPは作動できません。 RIP-2の次のホップIPアドレスは0.0がどんなルートへの.0もWANに広告を出した.0であるならいつもそうするでしょうに。
8. Security Considerations
8. セキュリティ問題
Security is provided through authentication of the logical and physical address of the sender of the routing update. Incoming call requests are matched by the circuit manager against a list of physical addresses (used to make outgoing calls). The routing application makes a further check against the logical address of an incoming update.
論理的認証とルーティングアップデートの送付者の物理アドレスを通してセキュリティを提供します。 かかってきた電話要求はサーキットマネージャが物理アドレス(以前はよく発信電話をしていた)のリストに取り組まされます。 ルーティングアプリケーションは入って来るアップデートの論理アドレスに対してさらなるチェックをします。
Additional security can be provided by RIP-2 authentication [2] where appropriate.
RIP-2認証で[2] 適切であるところに追加担保を提供できます。
Sherry & Meyer Informational [Page 5] RFC 2092 Triggered RIP Protocol Analysis January 1997
[5ページ]RFC2092の引き起こされた裂け目のプロトコル分析1997年1月の情報のシェリー酒とマイヤー
References
参照
[1] Hinden, R., "Internet Engineering Task Force Internet Routing
Protocol Standardization Criteria", RFC 1264, Bolt Beranek and
Newman, Inc, October 1991.
[1] Hinden、R.、「インターネット・エンジニアリング・タスク・フォースインターネットルーティング・プロトコル標準化評価基準」(RFC1264)はBeranekとニューマンをボルトで締めます、Inc、1991年10月。
[2] Meyer. G.M. and Sherry, S., "Triggered Extensions to RIP to
Support Demand Circuits", RFC 2091, Shiva and Xyplex, Aug 1995.
[2] マイヤー。 G.M.とシェリー酒とS.と「要求サーキットを支えるために裂く引き起こされた拡大」とRFC2091とシバ神とXyplex、1995年8月。
[3] Hedrick. C., "Routing Information Protocol", RFC 1058, Rutgers
University, June 1988.
[3] ヘドリック。 C. RFC1058、ラトガース大学、「情報プロトコルを発送すること」での1988年6月。
[4] Malkin. G., "RIP Version 2 - Carrying Additional Information",
RFC 1723, Xylogics, November 1994.
[4] マルキン。 G.、「追加情報を運んで、バージョン2をコピーしてください」、RFC1723、Xylogics、11月1994日
[5] Meyer. G., "Extensions to RIP to Support Demand Circuits",
Spider Systems, February 1994.
[5] マイヤー。 G.、「要求サーキットを支えるために裂く拡大」、クモのシステム、1994年2月。
Authors' Address:
作者のアドレス:
Steve Sherry
Xyplex
295 Foster St.
Littleton, MA 01460
聖リトルトン、スティーブシェリー酒のXyplex295フォスターMA 01460
Phone: (US) 508 952 4745
Fax: (US) 508 952 4887
Email: shs@xyplex.com
以下に電話をしてください。 (米国) 508 952、4745Fax: (米国) 4887年の508 952メール: shs@xyplex.com
Gerry Meyer
Shiva Europe Ltd
Stanwell Street
Edinburgh EH6 5NG
Scotland, UK
ゲリー・マイヤー・シバ神ヨーロッパLtd Stanwell通りエディンバラEH6 5NGスコットランド、イギリス
Phone: (UK) 131 561 4223
Fax: (UK) 131 561 4083
Email: gerry@europe.shiva.com
以下に電話をしてください。 (イギリス) 131 561、4223Fax: (イギリス) 4083年の131 561メール: gerry@europe.shiva.com
Sherry & Meyer Informational [Page 6]
シェリー酒とマイヤーInformationalです。[6ページ]
一覧
スポンサーリンク
