RFC2092 日本語訳

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ページ]