RFC1581 日本語訳

Network Working Group                                           G. Meyer
Request for Comments: 1581                                Spider Systems
Category: Informational                                    February 1994

コメントを求めるワーキンググループG.マイヤー要求をネットワークでつないでください: 1581年のクモのシステムカテゴリ: 情報の1994年2月

   Protocol Analysis for Extensions to RIP to Support Demand Circuits

拡大が要求が回路であるとサポートするために裂くプロトコル分析

Status of this Memo

このMemoの状態

   This document provides information for the Internet community.  This
   document does not specify an Internet standard of any kind.
   Distribution of this document is unlimited.

このドキュメントはインターネットコミュニティのための情報を提供します。 このドキュメントはどんな種類のインターネット標準も指定しません。 このドキュメントの分配は無制限です。

Abstract

要約

   As required by Routing Protocol Criteria [1], this report documents
   the key features of Routing over Demand Circuits on Wide Area
   Networks - RIP [2] and the current implementation experience.

ルート設定プロトコルCriteria[1]で、このレポートはワイドエリアネットワークにDemand Circuitsの上のルート設定に関する重要な特色を記録します--必要に応じて、RIP[2]と現在の実装経験。

Acknowledgements

承認

   I would like to thank colleagues at Spider, in particular Richard
   Edmonstone and Alan Turland who developed Spider's IP RIP and IPX RIP
   and SAP implementations.

Spiderで同僚に感謝申し上げます、SpiderのIP RIP、IPX RIP、およびSAP実装を開発した特定のリチャードEdmonstoneとアランTurlandで。

1. Protocol Documents

1. プロトコルドキュメント

   "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).  Network management extensions for Demand RIP are described
   in RIP Version 2 MIB Extensions [5].

「Support Demand CircuitsへのRIPへの拡大」[2]は「ルート設定インターネットプロトコル」(RIP)[3]と「ワイドエリアネットワーク(WAN)で、より費用効率よく実行するのを許容するリップ-2インチ[4]」に増進を示します。 Demand RIPのためのネットワークマネージメント拡大はRIPバージョン2MIB Extensions[5]で説明されます。

2. Applicability

2. 適用性

   Demand RIP requires that there is an underlying mechanism for
   determining unreachability in a finite predictable period.

要求RIPは、有限予測できる時代に「非-可到達性」を決定するための発症機序があるのを必要とします。

   The demand 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。

   o  Point-to-point links supporting PPP link quality monitoring or
      echo request to determine link failure.

o PPPをサポートするポイントツーポイント接続が上質のモニターかリンクの故障を決定するというエコー要求をリンクします。

Meyer                                                           [Page 1]

RFC 1581                       Demand RIP                  February 1994

マイヤー[1ページ]RFC1581は裂け目の1994年2月を要求します。

   A demand 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 or fixed point-to-point links; 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.  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を作動させます。 周期的な'放送'を使用することの代わりに、引き起こされたアップデートとして情報を送るだけです。 提案は基本的なコネクション型サービスが接続性のフィードバックを提供する特徴を利用します。

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 and fragment 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.

回路マネージャが接続にならないなら、回路下に指示をルーティングアプリケーションに送ります。 そして、回路マネージャは、取引関係を築くのを(増加すること)の間隔で、試みるでしょう。 うまくいくとき、指示への回路をルーティングアプリケーションに送ります。

3.3 Presumption of Reachability

3.3 可到達性の推定

   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:

安定したネットワークでは、回路の上にルーティング情報を伝播するという要件が全くないので、どんなルーティング情報も回路で受け取られていている(存在)でないなら以下のことと思われます。

Meyer                                                           [Page 2]

RFC 1581                       Demand RIP                  February 1994

マイヤー[2ページ]RFC1581は裂け目の1994年2月を要求します。

   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.4 Routing Information Flow Control

3.4経路情報フロー制御

   If the circuit manager reports a circuit as down, the routing
   application is flow controlled from sending further information on
   the circuit.

回路マネージャが下がっている同じくらい回路を報告するなら、ルーティングアプリケーションは回路に関する詳細を送るので制御された流れです。

   To prevent transmit queue overflow and also to avoid 'predictable'
   circuit down messages, the routing application can also optionally
   limit the rate of sending routing messages to an interface.

防ぐ、待ち行列オーバーフローを伝えてください。そうすれば、また、また、回路の'予測できる'下にメッセージを避けるために、ルーティングアプリケーションは任意に送付ルーティング・メッセージのレートをインタフェースに制限できます。

4. Implementations

4. 実装

   At this stage there is only believed to be one completed
   implementation.

現在のところ、1つの完成した実装があると信じられているだけです。

   The Spider Systems' implementation supports all the features outlined
   for IP RIP-1, IPX RIP and IPX SAP.  RIP-2 is not currently supported.
   It has been tested against itself on X.25 and ISDN WANs.  It has also
   been tested in operation with various router and host RIP-1, IPX RIP
   and IPX SAP implementations on Ethernet LANs.

Spider Systemsの実装はIP RIP-1、IPX RIP、およびIPX SAPのために概説されたすべての特徴をサポートします。 RIP-2は現在、サポートされません。 それはX.25とISDN WANでそれ自体に対してテストされました。 また、それはイーサネットLANで様々なルータ、ホストRIP-1、IPX RIP、およびIPX SAP実装で稼働中でありテストされました。

   Two other Novell-only implementations are known to be under
   development.

他の2つのノベルだけ実装が開発中であることが知られています。

5. Restrictions

5. 制限

   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であるならいつもそうするでしょうに。

Meyer                                                           [Page 3]

RFC 1581                       Demand RIP                  February 1994

マイヤー[3ページ]RFC1581は裂け目の1994年2月を要求します。

6. Security Considerations

6. セキュリティ問題

   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] 適切であるところに追加担保を提供できます。

7. References

7. 参照

   [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., "Extensions to RIP to Support Demand Circuits", RFC
       1582, Spider Systems, February 1994.

[2] マイヤー。 G.、「要求が回路であるとサポートするために裂く拡大」、RFC1582、クモのシステム、1994年2月。

   [3] Hedrick. C., "Routing Information Protocol", STD 34, RFC 1058,
       Rutgers University, June 1988.

[3] ヘドリック。 C. STD34、「情報プロトコルを発送すること」でのRFC1058、ラトガース大学、1988年6月。

   [4] Malkin. G., "RIP Version 2 - Carrying Additional Information",
       RFC 1388, Xylogics, January 1993.

[4] マルキン。 G.、「追加情報を運んで、バージョン2をコピーしてください」、RFC1388、Xylogics、1月1993日

   [5] Malkin. G., and F. Baker, "RIP Version 2 MIB Extensions", RFC
       1389, Xylogics, ACC, January 1993.

[5] マルキン。 G.、およびF.ベイカー、「裂け目のバージョン2MIB拡張子」、RFC1389、Xylogics、ACC、1993年1月。

Author's  Address

作者のアドレス

       Gerry Meyer
       Spider Systems
       Stanwell Street
       Edinburgh EH6 5NG
       Scotland, UK

ゲリー・マイヤー・Spider Systems Stanwell通りエディンバラEH6 5NGスコットランド、イギリス

       Phone: (UK) 31 554 9424
       Fax:   (UK) 31 554 0649
       EMail: gerry@spider.co.uk

以下に電話をしてください。 (イギリス) 31 554 9424Fax: (イギリス) 31 554 0649はメールされます: gerry@spider.co.uk

Meyer                                                           [Page 4]

マイヤー[4ページ]