RFC1582 日本語訳
1582 Extensions to RIP to Support Demand Circuits. G. Meyer. February 1994. (Format: TXT=63271 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Meyer Request for Comments: 1582 Spider Systems Category: Standards Track February 1994
コメントを求めるワーキンググループG.マイヤー要求をネットワークでつないでください: 1582年のクモのシステムカテゴリ: 標準化過程1994年2月
Extensions to RIP to Support Demand Circuits
要求が回路であるとサポートするために裂く拡大
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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
Running routing protocols on connection oriented Public Data Networks, for example X.25 packet switched networks or ISDN, can be expensive if the standard form of periodic broadcasting of routing information is adhered to. The high cost arises because a connection has to all practical intents and purposes be kept open to every destination to which routing information is to be sent, whether or not it is being used to carry user data.
ルーティング情報の周期的な放送の標準形式が固く守られるなら、接続の指向のPublic Data Networksでの実行しているルーティング・プロトコル(例えば、X.25パケット交換網かISDN)は、高価である場合があります。 接続が送られるルーティング情報がことであるあらゆる目的地への戸外であることがすべての実用的な「不-テント」と目的に保たれたので、高い費用は起こります、それが利用者データを運ぶのに使用されているか否かに関係なく。
Routing information may also fail to be propagated if the number of destinations to which the routing information is to be sent exceeds the number of channels available to the router on the Wide Area Network (WAN).
また、送られるルーティング情報がことである目的地の数がワイドエリアネットワーク(WAN)のルータに利用可能なチャンネルの数を超えているなら、ルート設定情報は伝播されないかもしれません。
This memo defines a generalized modification which can be applied to Bellman-Ford (or distance vector) algorithm information broadcasting protocols, for example IP RIP, Netware RIP or Netware SAP, which overcomes the limitations of the traditional methods described above.
このメモはプロトコルを放送するBellman-フォード(または、距離ベクトル)アルゴリズム情報に適用できる、一般化された変更、例えば、IP RIP、Netware RIPまたはNetware SAPを定義します。(それは、上で説明された伝統的方法の限界を克服します)。
The routing protocols support a purely triggered update mechanism on demand circuits on WANs. The protocols run UNMODIFIED on LANs or fixed point-to-point links.
ルーティング・プロトコルは、純粋に引き起こされたアップデートメカニズムがWANのオンデマンドの回路であるとサポートします。 プロトコルは定点からLANかポイントへのリンクにUNMODIFIEDを実行します。
Routing information is sent on the WAN when the routing database is modified by new routing information received from another interface. When this happens a (triggered) update is sent to a list of destinations on other WAN interfaces. Because routing protocols are datagram based they are not guaranteed to be received by the peer router on the WAN. An acknowledgement and retransmission mechanism is provided to ensure that routing updates are received.
WANでルーティングデータベースがいつ別のインタフェースから受け取られた新しいルーティング情報によって変更されるかというルート設定情報を送ります。 これが起こるとき、他のWANインタフェースで(引き起こされます)アップデートを目的地のリストに送ります。 ルーティング・プロトコルが基づくデータグラムであるので、それらはWANに同輩ルータで受け取るために保証されません。 ルーティングアップデートが受け取られているのを保証するために承認と「再-トランスミッション」メカニズムを提供します。
Meyer [Page 1] RFC 1582 Demand RIP February 1994
マイヤー[1ページ]RFC1582は裂け目の1994年2月を要求します。
The WAN circuit manager advises the routing applications on the reachability and non-reachability of destinations on the WAN.
WAN回路マネージャはWANで目的地の可到達性と非の可到達性に関してルーティングアプリケーションを教えます。
Acknowledgements
承認
I would like to thank colleagues at Spider, in particular Richard Edmonstone, Tom Daniel and Alam Turland, Yakov Rekhter (IBM), Martha Steenstrup (BBN), and members of the RIP-2 working group of the IETF for stimulating discussions and comments which helped to clarify this memo.
このメモをはっきりさせるのを助けた刺激的な議論とコメントについてSpiderと特にリチャードEdmonstoneとトム・ダニエルとAlam Turland、ヤコフRekhterの同僚(IBM)、マーサ・ステーンストルプ(BBN)、およびIETFのRIP-2ワーキンググループのメンバーに感謝申し上げます。
Conventions
コンベンション
The following language conventions are used in the items of specification in this document:
以下の言語コンベンションは仕様に関する条項で本書では使用されます:
o MUST -- the item is an absolute requirement of the specification.
MUST is only used where it is actually required for interoperation,
not to try to impose a particular method on implementors
where not required for interoperability.
o --項目は仕様に関する絶対条件であるに違いありません。 それがinteroperationに相互運用性に必要でないところで特定のメソッドを作成者に課そうとしないために実際に必要であるところで使用するだけでよいです。
o SHOULD -- the item should be followed for all but exceptional cir-
cumstances.
o SHOULD--商品はほとんど例外的なcir- cumstancesのために従われるべきです。
o MAY or optional -- the item is truly optional and may be followed
or ignored according to the needs of the implementor.
o 5月か任意である、--作成者の必要性に従って、商品は、本当に、任意であり、従われているか、または無視されるかもしれません。
The words "should" and "may" are also used, in lower case, in their more ordinary senses.
また、単語の“should"と“may"は彼らの、より普通の意味で小文字に使用されます。
Table of Contents
目次
1. Introduction ........................................... 3
2. Running a routing Protocol on the WAN .................. 4
2.1. Overview ......................................... 4
2.2. Presumption of Reachability ...................... 6
2.3. WAN Router list .................................. 7
2.4. Triggered Updates and Unreliable Delivery ........ 8
2.5. Guaranteeing delivery of Routing Updates ......... 8
2.6. The Routing Database ............................. 9
2.7. New Packet Types ................................. 10
2.8. Fragmentation .................................... 12
2.9. Preventing Queue Overload ........................ 13
3. IP Routing Information Protocol Version 1 .............. 13
4. IP Routing Information Protocol Version 2 .............. 16
5. Netware Routing Information Protocol ................... 17
6. Netware Service Advertising Protocol ................... 20
7. Timers ................................................. 24
1. 序論… 3 2. ルーティングプロトコルをWANに実行します… 4 2.1. 概要… 4 2.2. 可到達性の推定… 6 2.3. WAN Routerは記載します… 7 2.4. アップデートと頼り無い配送の引き金となります… 8 2.5. ルート設定Updatesについて荷渡しを保証します… 8 2.6. ルート設定データベース… 9 2.7. 新しいパケットはタイプされます… 10 2.8. 断片化… 12 2.9. 待ち行列オーバーロードを防ぎます… 13 3. IPルーティング情報プロトコルバージョン1… 13 4. IPルーティング情報プロトコルバージョン2… 16 5. ネットウェア経路情報プロトコル… 17 6. ネットウェアサービス広告プロトコル… 20 7. タイマ… 24
Meyer [Page 2] RFC 1582 Demand RIP February 1994
マイヤー[2ページ]RFC1582は裂け目の1994年2月を要求します。
7.1. Database Timer ................................... 24
7.2. Retransmission Timer ............................. 25
7.3. Reassembly Timer ................................. 26
8. Implementation Considerations ...........................27
9. Security Considerations ................................ 27
10. References ............................................. 28
11. Author's Address ....................................... 29
7.1. データベースタイマ… 24 7.2. Retransmissionタイマ… 25 7.3. Reassemblyタイマ… 26 8. 実装問題…27 9. セキュリティ問題… 27 10. 参照… 28 11. 作者のアドレス… 29
1. Introduction
1. 序論
Routers are used on connection oriented networks, such as X.25 packet switched networks and ISDN networks, to allow potential connectivity to a large number of remote destinations. Circuits on the Wide Area Network (WAN) are established on demand and are relinquished when the traffic subsides. Depending on the application, the connection between any two sites for user data might actually be short and relatively infrequent.
ルータは、多くの遠く離れた目的地に潜在的接続性を許容するのにX.25パケット交換網やISDNネットワークなどの接続指向のネットワークで使用されます。 ワイドエリアネットワーク(WAN)の回路を要求に応じて設立して、トラフィックが静まるとき、放棄します。 アプリケーションによって、利用者データのためのどんな2つのサイトの間の関係は、実際に短くて、比較的珍しいかもしれません。
Practical experience of routing shows that periodic 'broadcasting' of routing updates on the WAN is unsatisfactory on several counts:
ルーティングの実用的な経験は、WANのルーティングアップデートの周期的な'放送'がいくつかの点で不十分であることを示します:
o Running a routing protocol like RIP is expensive if the standard
form of transmitting routing information to every next hop router
every 30 seconds is adhered to. The more routers there are
wishing to exchange information the worse the problem. If there
are N routers on the WAN, N * (N - 1) routing updates are sent over
N * (N - 1)/2 connections every broadcast period.
o 30秒毎に次のあらゆるホップルータに情報を発送する伝えることの標準形式が固く守られるなら、RIPのようなルーティング・プロトコルを実行するのは高価です。 そこの、より多くのルータが情報交換したがっていれば、問題は、より悪いです。 NルータがWANにあれば、いつも放送の期間にN*(N--1)ルーティングアップデートはN*に上送られた(N--1)/2接続です。
The expense arises because a circuit has to be kept open to each
destination to which routing information is to be sent. Routing
updates are sufficiently frequent that little benefit is obtainable
on most networks by attempting to set up a call purely for
the duration of the routing update. (There are often minimum call
charges, or there is a charge to set up a call irrespective of
what data is sent.)
回路が送られるルーティング情報がことである各目的地に開かれているように保たれなければならないので、費用は起こります。 ルート設定アップデートは十分頻繁です。ルーティングアップデートの持続時間のために純粋に呼び出しをセットアップするのを試みることによって、そんなに少ない利益がほとんどのネットワークで入手可能です。 (最小の通話料がしばしばあるか、またはどんなデータを送るかの如何にかかわらず呼び出しをセットアップするために、充電があります。)
The option of reducing the 'broadcast' frequency, while reducing
the cost, would make the system less responsive.
生産費を切り下げている間、'放送'頻度を減少させるオプションで、システムは、より敏感でなくなるでしょう。
o The number of networks to be connected (N) on the WAN can easily
exceed the number of simultaneous calls (M) which the interface
can support. If this happens the routing 'broadcast' will only
reach M next hop routers, and (N - M) next hop routers will not
receive the routing update.
o WANの接続(N)であるネットワークの数は容易にインタフェースがサポートすることができる同時の呼び出し(M)の数を超えることができます。 これが起こるなら、ルーティング'放送'は次のホップルータを範囲Mだけに望んでいます、そして、次の(N--M)ホップルータはルーティングアップデートを受けないでしょう。
A basic rate ISDN interface can support 2 simultaneous calls, and
even the number of logical channels most users subscribe to on an
X.25 network is not large. There is no fundamental reason why
基本料金ISDNインタフェースは2つの同時の呼び出しをサポートすることができます、そして、ほとんどのユーザがX.25ネットワークで加入する論理チャネルの数さえ大きくはありません。 どんな基本的な理由もありません。
Meyer [Page 3] RFC 1582 Demand RIP February 1994
マイヤー[3ページ]RFC1582は裂け目の1994年2月を要求します。
routing protocols should restrict the user to routing between so
few sites.
ルーティング・プロトコルはユーザをとてもわずかなサイトの間のルーティングに制限するべきです。
o Since there is no broadcast facility on the WAN, 'broadcasting' of
routing information actually consists of sending the updates
separately to all known locations. This means that N routing
updates are queued for transmission on the WAN link (in addition
to any data which might be queued).
o 放送施設が全くWANにないので、ルーティング情報の'放送'であることは実際に別々にすべての知られている位置にアップデートを送るのから成ります。 これは、NルーティングアップデートがトランスミッションのためにWANリンク(列に並ばせられるどんなデータに加えた)の上に列に並ばせられることを意味します。
Routers take a pragmatic view on queuing datagrams for the WAN.
If the queue length gets too long, so that datagrams at the end of
the queue would take too long be transmitted in a reasonable time
(say 1 to 2 seconds) the router may start discarding them. On an
X.25 network, with slow line speeds (perhaps 9600 baud), it may
not take too many routing updates to fulfill this condition if the
link is also actively being used to carry user data.
ルータはWANのためにデータグラムを列に並ばせることに関する実践的な意見を取ります。 待ち行列の長さが長くなり過ぎるなら、また、待ち行列の終わりのデータグラムに時間がかかるように、ルータがそれらを捨て始めるかもしれない妥当な時代(1〜2秒言う)で、伝えられてください。 X.25ネットワークでは、遅いライン・スピード(恐らく9600ボー)で、また、リンクが利用者データを運ぶのに活発に使用されているなら、この条件を達成するのにあまりに多くのルーティングアップデートを要しないかもしれません。
This memo addresses all the above problems.
このメモはそのすべての上の問題を訴えます。
The approach taken is to modify the routing protocols so as to send information on the WAN only when there has been an update to the routing database OR a change in the reachability of a next hop router is indicated by the task which manages connections on the WAN.
取られたアプローチはルーティングデータベースORへのアップデートがあったときだけ、WANの情報を送るようにルーティング・プロトコルを変更するために、次のホップルータの可到達性における変化がWANで接続を管理するタスクによって示されるということです。
Because datagrams are not guaranteed to get through on all WAN media, an acknowledgement and retransmission system is required to provide reliability.
データグラムがすべてのWANのメディア、承認、および「再-トランスミッション」を通るために保証されないので、システムが信頼性を提供するのに必要です。
This memo describes the modifications required for Bellman-Ford (or distance vector) algorithm information broadcasting protocols, such as IP RIP [1,2] or Netware RIP and SAP [3] on the WAN. The protocols run unmodified on Local Area Networks (LANs) or fixed point-to-point links, and so interoperate transparently with implementations adhering to the original specifications.
このメモはプロトコルを放送するBellman-フォード(または、距離ベクトル)アルゴリズム情報に必要である変更について説明します、WANのIP RIP[1、2]やNetware RIPやSAP[3]のように。 透過的に実装が正式仕様書を固く守っていて、プロトコルは、ローカル・エリア・ネットワーク(LAN)か定点からポイントへのリンクの上に変更されていなく稼働しているので、共同利用します。
2. Running Routing Protocols on the WAN
2. ルーティング・プロトコルをWANに実行します。
2.1 Overview
2.1 概要
Multiprotocol routers are used on connection oriented Wide Area Networks (WANs), such as X.25 packet switched networks and ISDN networks, to interconnect LANs. By using the multiplexing properties of the underlying WAN technology, several LANs can be interconnected simultaneously through a single physical interface on the router.
Multiprotocolルータは接続の指向のワイドエリアネットワーク(WAN)で使用されます、X.25パケット交換網やISDNネットワークのように、内部連絡LANに。 基本的なWAN技術のマルチプレクシングの特性を使用することによって、いくつかのLANが同時に、ルータの単一の物理インターフェースを通してインタコネクトされることができます。
A circuit manager provides an interface between the connectionless network layers (IP, IPX, CLNP etc) and the connection oriented WAN (X.25 or ISDN). Figure 1 shows a schematic representative stack
回路マネージャはコネクションレスなネットワーク層(IP、CLNP IPXなど)と接続とのインタフェースに指向のWAN(X.25かISDN)を提供します。 図1は概要の代表しているスタックを示しています。
Meyer [Page 4] RFC 1582 Demand RIP February 1994
マイヤー[4ページ]RFC1582は裂け目の1994年2月を要求します。
showing the relationship between routing protocols, the network layers, the circuit manager and the connection oriented WAN.
ルーティング・プロトコルと、ネットワーク層と、回路マネージャと接続との関係を示していると、WANは適応しました。
-------------- --------- ---------
| RIP | | RIP | | SAP |
-------------- --------- ---------
| | |
-------------- | |
| UDP | | |
-------------- | |
| | |
-------------- ----------------
| IP | | IPX |
-------------- ----------------
| |
-------------------------------------------
| Circuit Manager |
-------------------------------------------
||||||||||
||||||||||
---------------------------
| Connection Oriented |
| WAN stack |
---------------------------
-------------- --------- --------- | 裂け目| | 裂け目| | SAP| -------------- --------- --------- | | | -------------- | | | UDP| | | -------------- | | | | | -------------- ---------------- | IP| | IPX| -------------- ---------------- | | ------------------------------------------- | 回路マネージャ| ------------------------------------------- |||||||||| |||||||||| --------------------------- | 適応する接続| | WANスタック| ---------------------------
A WAN circuit manager will support a variety of network layer
protocols, on its upper interface. On its lower interface, it
may support one or more subnetworks. A subnetwork may support a
number of Virtual Circuits.
WAN回路マネージャは、上側のインタフェースでさまざまなネットワーク層がプロトコルであるとサポートするでしょう。 下側のインタフェースでは、それは1つ以上のサブネットワークをサポートするかもしれません。 サブネットワークは多くのVirtual Circuitsをサポートするかもしれません。
Figure 1. Representative Multiprotocol Router stack
図1。 代表しているMultiprotocol Routerスタック
The router has a translation table which relates the network layer address of the next hop router to the physical address used to establish a Virtual Circuit (VC) to it. Datagrams may be encapsulated in a header to distinguish the network layer protocol [5].
ルータはVirtual Circuitを証明するのに使用される物理アドレス(VC)に次のホップルータのネットワーク層アドレスを関係づける変換テーブルをそれに持っています。 データグラムは、ネットワーク層プロトコル[5]を区別するためにヘッダーでカプセル化されるかもしれません。
The circuit manager takes datagrams from the connectionless network layer protocols and (if one is not currently available) opens a VC to the next hop router. A VC can carry all traffic between two end- point routers for a given network layer protocol (or with appropriate encapsulation all network layer protocols). An idle timer is used to close the VC when the datagrams stop arriving at the circuit manager.
回路マネージャは、コネクションレスなネットワーク層プロトコルからデータグラムを取って、次のホップルータにVCを開きます(1つが現在利用可能でないなら)。 VCは与えられたネットワーク層プロトコル(または、適切なカプセル化によるすべてのネットワーク層プロトコル)のために2つの終わりのポイントルータの間まですべてのトラフィックを運ぶことができます。 データグラムが、回路マネージャに到着するのを止めると、使用されていないタイマは、VCを閉じるのに使用されます。
Running routing protocols on the WAN has traditionally consisted of making small modifications to the methods used on LANs. Where
ルーティング・プロトコルをWANに実行するのはLANで使用されるメソッドへの小さい変更をするのから伝統的に成りました。 どこ
Meyer [Page 5] RFC 1582 Demand RIP February 1994
マイヤー[5ページ]RFC1582は裂け目の1994年2月を要求します。
routing information would be broadcast periodically on a LAN interface, it is converted to a series of periodic updates sent to a list of addresses on the WAN.
ルーティング情報はLANインタフェースで定期的に放送されて、それはWANで住所録に送られた一連の周期的なアップデートに変換されます。
This memo targets two areas:
このメモは2つの領域を狙います:
o Eliminating the overkill inherent in periodic transmission of
routing updates.
o ルーティングアップデートの周期的な送信に固有の過剰殺傷を排除します。
o Overcoming the bandwidth limitations on the WAN: the number of
simultaneous VCs to next hop routers and restricted data
throughput which the WAN link can support.
o WANで帯域幅限界を克服します: 同時のVCsの数はルータとWANリンクがサポートすることができる秘密データスループットを次に飛び越します。
The first of these is overcome by transmitting routing updates (called routing responses) only when required:
必要である場合にだけルーティングアップデート(ルーティング応答と呼ばれる)を伝えることによって、これらの1番目に打ち勝たれます:
o Firstly, when a specific request for a routing update has been
received.
o ルーティングを求める特定の要求であるときに、まず第一に、アップデートを受けました。
o Secondly, when the routing database is modified by new
information from another interface.
o ルーティングデータベースが別のものからの新情報によって変更されたら第二に、連結してください。
Update information received in this way is not normally
propagated on other interfaces immediately, but is delayed for a
few seconds to allow information from several updates to be
grouped.
このように受け取られたアップデート情報は、すぐに他のインタフェースで通常伝播されませんが、いくつかのアップデートからの情報が分類されるのを許容するために数秒間遅れます。
o Thirdly, when the circuit manager indicates that a destination
has changed from an unreachable (circuit down) to a reachable
(circuit up) state.
o 三番目に、回路マネージャがいつそのaの目的地を示すかはaに手の届かない(回路が下にある状態で)届いている(回路が上にある状態で)状態から変化しました。
Because of the inherent unreliability of a datagram based system, both routing requests and routing responses require acknowledgement, and retransmission in the event of NOT receiving an acknowledgement.
データグラムの固有の非信頼性のために、承認を受けないことの場合、ベースのシステム、ともに掘っている要求、およびルーティング応答は承認、および「再-トランスミッション」を必要とします。
To overcome the bandwidth limitations the routing application can perform a form of self-imposed flow control, to spread routing updates out over a period of time.
帯域幅限界を克服するために、ルーティングアプリケーションは自ら課しているフロー制御のフォームを実行できます、期間の間の普及のルーティングアップデートに。
2.2 Presumption of Reachability
2.2 可到達性の推定
If a routing update is received from a next hop router on the WAN, entries in the update are thereafter always considered to be reachable, unless proven otherwise:
WANで次のホップルータからルーティングアップデートを受けるなら、その後届くとアップデートにおけるエントリーをいつも考えます、そうでないのは立証されない場合:
o If in the normal course of routing datagrams, the circuit manager
fails to establish a connection to the next hop router, it
notifies the routing application that the next hop router is not
o 次のホップルータがルーティングアプリケーションですが、ルーティングデータグラムの常軌では、回路マネージャが次のホップルータに取引関係を築かないように通知するなら
Meyer [Page 6] RFC 1582 Demand RIP February 1994
マイヤー[6ページ]RFC1582は裂け目の1994年2月を要求します。
reachable through an internal circuit down message.
回路の内部の下にメッセージを通して届きます。
The routing application then goes through a process of timing out
database entries to make them unreachable in the routing sense.
そして、ルーティングアプリケーションは、それらをルーティング意味で手が届かなくするようにデータベースエントリーからタイミングの経過に直面しています。
o If the circuit manager is subsequently able to establish a
connec tion to the next hop router, it will notify the routing
applica tion that the next hop router is reachable through an
internal circuit up message.
o サーキットマネージャが次に次のホップルータにconnec tionを設立できると、それは、次のホップルータに内部のサーキットを通してメッセージに届いているようにルーティングapplica tionに通知するでしょう。
The routing application will then exchange messages with the next
hop router so as to re-prime their respective routing databases
with up-to-date information.
そして、ルーティングアプリケーションは、最新情報でそれらのそれぞれのルーティングデータベースを再用意するために次のホップルータとメッセージを交換するでしょう。
Handling of circuit up and circuit down messages requires that the circuit manager takes responsibility for establishing (or reestablishing) the connection in the event of a next hop router becoming unreachable. A description of the processes the circuit manager adopts to perform this task is outside the scope of this memo.
サーキットとメッセージの下側へのサーキットの取り扱いは、サーキットマネージャが手が届かなくなる次のホップルータの場合、接続を確立するのに(または、復職)責任を取るのを必要とします。 このメモの範囲の外にサーキットマネージャがこのタスクを実行するために採用する過程の記述があります。
2.3 WAN Router list
2.3 WAN Routerは記載します。
The routing task MAY be provided with a list of routers to send routing updates to on the WAN. It will comprise of the logical addresses of next hop routers for which the router has a logical to physical address mapping. Entries in the list SHOULD be categorized (on a per-peer basis) as follows:
WANでルーティングアップデートを送るルータのリストをルーティングタスクに提供するかもしれません。 それは次のホップの論理アドレスでルータがaを物理アドレスマッピングに論理的にするルータを包括するでしょう。 エントリー、リストSHOULDでは、以下の通り分類されてください(1同輩あたり1個のベースで):
o Running the standard routing protocol, namely transmitting
updates periodically with the packet formats used in LAN
broadcasts.
o すなわち、パケット・フォーマットがLAN放送に使用されている状態で定期的にアップデートを伝えて、標準のルーティング・プロトコルを走らせます。
This option is supported to allow interoperability with existing
routing implementations, and might also be appropriate if some
of the destinations are using Permanent Virtual Circuits (PVCs)
rather than SVCs.
このオプションも、既存のルーティング実現がある相互運用性を許容するために支持されて、また、目的地のいくつかがSVCsよりむしろPermanent Virtual Circuits(PVCs)を使用しているなら、適切であるかもしれません。
o Running the triggered update routing protocol proposed in this
memo.
o 引き起こされたアップデートルーティング・プロトコルを走らせるのはこのメモで提案しました。
Omitting an address from both of these categories is equivalent to not running the routing protocols.
これらのカテゴリの両方からのアドレスを省略するのはルーティング・プロトコルを走らせないのに同等です。
If routing packets arrive from a destination not supporting the appropriate variant they MUST be discarded.
ルーティングパケットが適切な異形を支持しない目的地から到着するなら、それらを捨てなければなりません。
Meyer [Page 7] RFC 1582 Demand RIP February 1994
マイヤー[7ページ]RFC1582は裂け目の1994年2月を要求します。
2.4 Triggered Updates and Unreliable Delivery
2.4 引き起こされたアップデートと頼り無い配送
If triggered update information is sent to next hop routers on the WAN only once it can fail to arrive for one of the following reasons:
引き起こすなら、それが以下の理由の1つによっていったん到着しなかったことができただけあとにWANに関するルータが次に跳ぶためにアップデート情報を送ります:
o A free VC resource might not be available, because of a
restricted number of X.25 logical channels or ISDN B-channels.
o 無料のVCリソースは制限された数のX.25論理チャネルかISDN B-チャンネルのために利用可能でないかもしれません。
o The transmit queue might be full - requiring the datagram to be
discarded.
o 伝わってください。データグラムが捨てられるのが必要であることで、待ち行列は完全であるかもしれません。
o The VC might be pre-empted (in favour of establishing a VC to
another next hop router) while the datagram is in a queue,
resulting in the queue being flushed and the datagram
discarded.
o 洗い流される待ち行列をもたらして、データグラムが待ち行列であって、データグラムが捨てられていた間、VCは先取りされるかもしれません(次に別のものにVCを設立することを支持して、ルータを飛び越してください)。
o In cases where the method of transport is not guaranteed, for
example with PPP where there is no acknowledgement and
retransmission of HDLC frames, a corrupted frame will result in
the loss of the datagram.
o 輸送の方法が例えば、HDLCフレームの承認と「再-トランスミッション」が全くないPPPと共に保証されない場合では、崩壊したフレームはデータグラムの損失をもたらすでしょう。
2.5 Guaranteeing delivery of Routing Updates
2.5 ルート設定Updatesについて荷渡しを保証すること。
To guarantee delivery of routing updates on the WAN an acknowledgement and retransmission scheme MUST be used:
WANにおけるルーティングアップデートの配送に承認と「再-トランスミッション」計画を保証するのは使用されているに違いありません:
o Send a routing update to a next hop router on the WAN.
o WANで次のホップルータにルーティングアップデートを送ってください。
o The other router responds with an acknowledgement packet.
o もう片方のルータは確認応答パケットで応じます。
The original router receives the acknowledgement.
オリジナルのルータは承認を受けます。
o Otherwise the original router retransmits the update until an
acknowledgement is received.
o さもなければ、承認が受け取られているまで、オリジナルのルータはアップデートを再送します。
Retransmission timer values are covered in section 7.
再送信タイマー値はセクション7でカバーされています。
In cases where the routing database is modified before an
acknowledgement is received a new routing update with an
updated sequence number is sent out. If an acknowledgement for
the old routing update is received it is ignored.
承認が受け取られている前にルーティングデータベースが変更されている場合では、アップデートされた一連番号がある新しいルーティングアップデートを出します。 古いルーティングアップデートのための承認が受け取られているなら、それは無視されます。
o A router only updates its routing database when it receives a
complete update, which may consist of several fragments. Each
fragment is individually acknowledged.
o 完全なアップデート(数個の断片から成るかもしれない)を受けるときだけ、ルータはルーティングデータベースをアップデートします。 各断片は個別に承認されます。
The above mechanism caters for cases where the datagram is lost because of a frame error or is discarded because of an over-full
上のメカニズムはデータグラムがフレーム誤りでなくされているか、または過剰満のために捨てられるケースを満たします。
Meyer [Page 8] RFC 1582 Demand RIP February 1994
マイヤー[8ページ]RFC1582は裂け目の1994年2月を要求します。
queue. The routing update and acknowledgement will eventually both get through.
列を作ってください。 ルーティングアップデートと承認は結局、ともに通るでしょう。
In cases where the circuit manager cannot establish a connection, a mechanism is provided to allow the circuit manager to inform the routing task of the failure to make a connection so that it can suppress retransmissions until a circuit becomes available.
サーキットマネージャが取引関係を築くことができない場合では、サーキットマネージャがサーキットが利用可能になるまで「再-トランスミッション」を抑圧できるように接続を作らないことに関するルーティングタスクを知らせるのを許容するためにメカニズムを提供します。
2.6 The Routing Database
2.6 ルート設定データベース
A requirement of using triggered updates for propagating routing information is that NO routing information ever gets LOST or DISCARDED.
ルーティング情報を伝播するのに引き起こされたアップデートを使用する要件はどんなルーティング情報もLOSTかDISCARDEDを手に入れないということです。
The routing database MUST adopt one of the following strategies:
ルーティングデータベースは以下の戦略の1つを採用しなければなりません:
o It must keep ALL alternative routing information it learns from
any routing updates from the LAN and the WAN, so that if the
best route disappears an alternative route (if available) can
replace it as the new best route.
o それはどんなルーティングアップデートからもLANとWANから学ぶすべての代替のルーティング情報を妨げなければなりません、最も良いルートが見えなくなるなら代替のルート(利用可能であるなら)が新しい最も良いルートとしてそれに取って代わることができるように。
o If the amount of memory this consumes is problematic the routing
application must keep SOME alternative routing information - say
a best route and two alternatives.
o これが消費するメモリー容量が問題が多いなら、ルーティングアプリケーションは、SOMEが代替のルーティング情報であることを保たなければなりません--最も良いルートと2つの選択肢を示してください。
If the router ever has to discard routing information about a
route it should note the fact. If the routes that have been
kept disappear because they have become unreachable, the router
MUST issue a request on all interfaces to try and obtain
discarded alternatives.
ルータがルートのルーティング情報を捨てなければならないなら、それは事実に注意するべきです。 保たれたルートが手が届かなくなったので見えなくなるなら、ルータは捨てられた代替手段を得てみるというすべてのインタフェースに関する要求を出さなければなりません。
It is recommended that the request is issued BEFORE all routes
to a destination have been lost.
要求がBEFOREが発行されて、目的地へのすべてのルートがなくされたということであることはお勧めです。
Entries in the routing database can either be permanent or temporary. Entries learned from broadcasts on LANs are temporary. They will expire if not periodically refreshed by further broadcasts.
ルーティングデータベースにおけるエントリーは、永久的であるか、または一時的である場合があります。 LANで放送から学習されたエントリーは一時的です。 さらなる放送で定期的にリフレッシュされないと、彼らは期限が切れるでしょう。
Entries learned from a triggered response on the WAN are 'permanent'. They MUST not time out in the normal course of events. The entries state MUST be changed to 'temporary' by the following events:
WANで引き起こされた応答から学習されたエントリーは'永久的です'。 それらはそうしなければなりません。正常なすう勢のタイムアウトでない。 エントリー州は以下の出来事で'一時的に'変わらなければなりません:
o The arrival of a routing update containing the entry set to
unreachable.
o エントリーを含むルーティングアップデートの到着は手の届かなくセットしました。
The normal hold down timer MUST be started, after which the
entry disappears from the routing database.
正常な抑制タイマ(エントリーはルーティングデータベースから見えなくなる)を始動しなければなりません。
Meyer [Page 9] RFC 1582 Demand RIP February 1994
マイヤー[9ページ]RFC1582は裂け目の1994年2月を要求します。
o The arrival of a routing update with the entry absent.
o エントリーが休んでいるルーティングアップデートの到着。
If the hold down timer is not already running, the entry MUST be
set to unreachable and the hold down timer started.
タイマの下側への保持が既に走行でないなら、手の届かなくエントリーを設定しなければなりませんでした、そして、タイマの下側への保持は始まりました。
o A message sent from the circuit manager, to indicate that it
failed to make a connection in normal running.
o メッセージは、正常な走行における接続を作らなかったのを示すためにサーキットマネージャから発信しました。
The routing table MUST be scanned for all routes via that next
hop router. Aging of these routing entries MUST commence. If
the aging timer expires the entry MUST be set to unreachable and
the hold down timer started. If the hold down timer expires the
entry disappears from the routing database.
その次のホップルータですべてのルートに経路指定テーブルをスキャンしなければなりません。 これらのルーティングエントリーの年をとることは始まらなければなりません。 老朽化しているタイマが期限が切れるなら、手の届かなくエントリーを設定しなければなりませんでした、そして、抑制タイマは始動しました。 抑制タイマが期限が切れるなら、エントリーはルーティングデータベースから見えなくなります。
o If the interface goes down, the circuit manager should indicate
that all circuits on that interface have gone down.
o インタフェースが落ちるなら、サーキットマネージャは、そのインタフェースのすべてのサーキットが落ちたのを示すべきです。
Database timer values are covered in section 7.
データベースタイマ値はセクション7でカバーされています。
2.7 New Packet Types
2.7 新しいパケットタイプ
To support triggered updates, three new packet types MUST be supported:
引き起こされたアップデートを支持するために、3つの新しいパケットタイプを支持しなければなりません:
TRIGGERED REQUEST
引き起こされた要求
A request to the responding system to send all
appropriate elements in its routing database.
ルーティングデータベースですべての適切な要素を送る応じるシステムへの要求。
A triggered request is retransmitted at periodic
intervals until a triggered response is received.
引き起こされた応答が受け取られているまで、引き起こされた要求は周期的な間隔で、再送されます。
Routing requests are transmitted in the following
circumstances:
ルート設定要求は下記の事情の中で伝えられます:
o Firstly when the router is powered on.
o いつ、まず第一に、ルータがあるかは電源を入れました。
o Secondly when the circuit manager indicates a
destination has been in an unreachable (circuit down)
state for an extended period and changes to a
reachable (circuit up) state.
o サーキットマネージャが第二にいつ目的地を示すかが長期間と届いている(サーキットが上にある状態で)状態への変化のための手の届かない(サーキットが下にある状態で)状態にありました。
o Thirdly in the event of all routing update fragments
failing to arrive within a set period.
o 三番目に、すべてのルーティングの場合、セットの期間以内に到着しない断片をアップデートしてください。
o It may also send triggered requests at other times to
compensate for discarding non-optimal routing
information.
o また、それは非最適ルーティング情報を捨てる補う他の時に引き起こされた要求を送るかもしれません。
Meyer [Page 10] RFC 1582 Demand RIP February 1994
マイヤー[10ページ]RFC1582は裂け目の1994年2月を要求します。
TRIGGERED RESPONSE
引き起こされた応答
A message containing all appropriate elements of the
routing database. An appropriate element is an entry
NOT learned from the interface to which the routing
information is being sent out. This is known as "split
horizon".
ルーティングデータベースのすべての適切な原理を含むメッセージ。 適切な要素はルーティング情報が出されているインタフェースから学習されなかったエントリーです。 これは「分裂地平線」として知られています。
Stability is improved by adding "poisoned reverse" on
routes learned from a destination. This consists of also
including some routes learned from a destination in
routing updates sent back to that destination, but
setting the routes as unreachable. A route is only
poisoned if it is the best route (rather than an inferior
alternative route) in the database.
安定性は、目的地から学習されたルートの上で「当たっている逆」を加えることによって、改良されます。 これはまた、その目的地が送り返されますが、手の届かないとしてルートを設定しながらルーティングアップデートに目的地から学習されたいくつかのルートを含んでいるのから成ります。 ルートはそれがデータベースで最も良いルート(粗悪な代替のルートよりむしろ)である場合にだけ毒を入れられます。
A triggered response message may be sent in response to a
triggered request, or it may be an update message issued
because of a change in the routing database.
引き起こされた要求に対応して引き起こされた応答メッセージを送るかもしれませんか、それはルーティングデータベースにおける変化のために発行されたアップデートメッセージであるかもしれません。
A triggered response message MUST be sent in response to
a triggered request message even if there are no routes
to propagate. This would be the case for a host which
had a WAN interface only, but which wished to run the
triggered update protocol.
伝播するルートが全くなくても、引き起こされた要求メッセージに対応して引き起こされた応答メッセージを送らなければなりません。 これはWANインタフェースしか持っていませんでしたが、引き起こされたアップデートプロトコルを走らせたがっていたホストのためのそうでしょう。
A triggered response is retransmitted at periodic
intervals until a triggered acknowledgement is received.
引き起こされた承認が受け取られているまで、引き起こされた応答は周期的な間隔で、再送されます。
TRIGGERED ACKNOWLEDGEMENT
引き起こされた承認
A message sent in response to every triggered response
packet received.
あらゆる引き起こされた応答パケットに対応して送られたメッセージは受信されました。
Triggered response and triggered acknowledgement packets MUST contain additional fields for a sequence number, fragment number and number of fragments.
引き起こされた応答と引き起こされた確認応答パケットは断片の一連番号、断片番号、および数のための追加分野を含まなければなりません。
If a triggered request or response is not acknowledged after 10 retransmissions, routes to the destination should be marked as unreachable for the duration of a hold down timer before being deleted.
引き起こされた要求か応答が10「再-トランスミッション」の後に承諾されないなら、削除される前に目的地へのルートは抑制タイマの持続時間に手の届かないとしてマークされるべきです。
The destination should then be polled at a lower frequency using triggered request packets. When a triggered response is received, the router should prime the next hop router my sending its routing database through triggered response packets.
そして、下側の頻度で引き起こされたリクエスト・パケットを使用することで目的地は投票されるべきです。 受けられた、引き起こされた応答、ルータがそうするべきであるとき、次のホップルータを用意してください。私は引き起こされた応答パケットを通してルーティングデータベースを送ります。
Meyer [Page 11] RFC 1582 Demand RIP February 1994
マイヤー[11ページ]RFC1582は裂け目の1994年2月を要求します。
Strictly speaking polling should occur indefinitely to guarantee database integrity. However the administrator MAY wish the router to cease polling after a few attempts believing that the lack of response is due to a mis-configuration of the next hop router. The destination should be marked as NOT supporting the mechanism and no further routing messages should be sent to that destination.
厳密に言うと、世論調査は無期限に保証データベース保全の心に浮かぶべきです。 しかしながら、無反応が次のホップルータの誤構成のためであると信じているいくつかの試みの後に投票して、管理者は、ルータがやんで欲しいかもしれません。 メカニズムにもかかわらず、さらなるルーティング・メッセージを全く支持しないのをその目的地に送るべきであるとき、目的地を示すべきです。
Before marking the destination as not supporting the mechanism, at least 5 triggered request polls (without acknowledgement) should be sent.
メカニズムをサポートしない少なくとも引き起こされた5として目的地を示す前に、投票(承認のない)が送られるべきであるよう要求してください。
If a destination marked as not supporting the mechanism, subsequently sends a valid 'triggered' message, the destination should be marked as supporting the mechanism once more (to allow for the next hop router's configuration being changed). It should be sent a triggered request and a triggered response to obtain and propagate up-to-date routing information.
マークされて、メカニズムであり支持しないとして、有効な'引き金となられた'メッセージが目的地であるなら次に発信して、目的地はもう一度(変えられる次のホップルータの構成を考慮する)メカニズムをサポートするとして示されるべきです。 最新のルーティング情報を得て、伝播するために引き起こされた要求と引き起こされた応答をそれに送るべきです。
2.8 Fragmentation
2.8 断片化
If a routing update is sufficiently large, the information MUST be fragmented over several triggered response packets:
ルーティングアップデートが十分大きいなら、いくつかの引き起こされた応答パケットの上で情報を断片化しなければなりません:
o Each fragment MUST be individually acknowledged with a triggered
acknowledgement packet.
o 引き起こされた確認応答パケットで個別に各断片を承認しなければなりません。
The sender of the routing update MUST periodically retransmit
fragments which have not been acknowledged (or until the
destination is marked as not supporting the mechanism).
ルーティングアップデートの送付者は定期的に承認されていない断片を再送しなければなりません(目的地がメカニズムをサポートしないので著しくなるまで)。
o A router receiving fragments MUST re-assemble them before
updating its routing database.
o ルーティングデータベースをアップデートする前に、断片を受けるルータはそれらを組み立て直さなければなりません。
o If all fragments are not received within four times the
retransmit period, they MUST be discarded.
o 4回以内ですべての断片を受け取るというわけではない、以上を再送してください、そして、それらを捨てなければなりません。
A triggered request packet MUST then be sent to the originator
of the routing update.
そして、ルーティングアップデートの創始者に引き起こされたリクエスト・パケットを送らなければなりません。
On receiving the triggered request packet, the originator of the
routing update MUST retransmit ALL fragments.
引き起こされたリクエスト・パケットを受けると、ルーティングアップデートの創始者はすべての断片を再送しなければなりません。
o If a fragment with an updated sequence number is received, ALL
fragments with the earlier sequence number MUST be discarded.
o アップデートされた一連番号がある断片が受け取られているなら、以前の一連番号があるすべての断片を捨てなければなりません。
An updated sequence number is defined as any sequence number
that is different. There is no concept of the value of the
sequence number conveying its age.
アップデートされた一連番号はどんな異なった一連番号とも定義されます。 時代を運ぶ一連番号の値の概念が全くありません。
Meyer [Page 12] RFC 1582 Demand RIP February 1994
マイヤー[12ページ]RFC1582は裂け目の1994年2月を要求します。
Fragmentation timer values are covered in section 7.
断片化タイマ値はセクション7でカバーされています。
2.9 Preventing Queue Overload
2.9 待ち行列オーバーロードを防ぐこと。
In order to prevent too many routing messages being queued at a WAN interface, the routing task MAY operate a scheme whereby 'broadcasting' of a triggered request or triggered response to a WAN interface is staggered. All routing requests or routing responses are not sent to ALL next hop routers on the interface in a single batch:
あまりに多くのルーティング・メッセージがWANインタフェースに列に並ばせられるのを防ぐために、ルーティングタスクはWANインタフェースへの引き起こされた要求か引き起こされた応答の'放送'であることがよろめかせられている計画を操作するかもしれません。 すべてのルーティング要求かルーティング応答がルータがただ一つのバッチにおけるインタフェースを次にすべて跳ぶために送られません:
o The routing task should limit the number of outstanding triggered
request messages for which a triggered response has not been
received.
o ルーティングタスクは引き起こされた応答が受けられていない傑出している引き起こされた要求メッセージの数を制限するべきです。
o The routing task should limit the number of outstanding triggered
response messages for which a triggered acknowledgement has not
been received.
o ルーティングタスクは引き起こされた承認が受けられていない傑出している引き起こされた応答メッセージの数を制限するべきです。
As outstanding messages are appropriately acknowledged, further messages can be sent out to other next hop routers, until all next hop routers have been sent the message and have acknowledged it.
適切に傑出しているメッセージを承認するとき、他の次のホップルータにさらなるメッセージを出すことができます、次のホップルータがメッセージを送って、それを承認するまで。
The maximum number of outstanding messages transmitted without acknowledgement is a function of the link speed and the number of other routing protocols operating the triggered update mechanism.
承認なしで送られた傑出しているメッセージの最大数はリンク速度と他のルーティング・プロトコルの数が引き起こされたアップデートメカニズムを操作する機能です。
Messages should always be acknowledged immediately (even if it causes the limit to be exceeded), since a connection is almost certainly available. This has the potential benefit of allowing the VC to close sooner (on its idle timer).
メッセージはすぐにいつも承認されるべきです(それで限界を超えてもさえ)、接続がほぼ確実に手があいているので。 これには、VCが、より早さに(使用されていないタイマに関して)閉じるのを許容する潜在的利益があります。
Sending all triggered request fragments to a destination at once is also beneficial.
また、すぐにすべての引き起こされた要求断片を目的地に送るのも有益です。
3. IP Routing Information Protocol Version 1
3. IPルーティング情報プロトコルバージョン1
This section should be read in conjunction with reference [1].
このセクションは参照[1]に関連して読まれるべきです。
IP RIP is a UDP-based protocol which generally sends and receives datagrams on UDP port number 520.
IP RIPは一般に、UDPポートNo.520でデータグラムを送って、受けるUDPベースのプロトコルです。
To support the mechanism outlined in this proposal the packet format for RIP version 1 [1] is modified as shown in Figure 2.
この提案に概説されたメカニズムをサポートするために、RIPバージョン1[1]のためのパケット・フォーマットは図2に示されるように変更されています。
Every Routing Information Protocol datagram contains the following:
あらゆるルーティング情報プロトコルデータグラムが以下を含んでいます:
Meyer [Page 13] RFC 1582 Demand RIP February 1994
マイヤー[13ページ]RFC1582は裂け目の1994年2月を要求します。
COMMAND Commands supported in RIP Version 1 are: request (1),
response (2), traceon (3), traceoff (4), SUN reserved (5).
The fields sequence number, fragment number and number of
fragments MUST NOT be included in packets with these
command values.
RIPバージョン1でサポートされたCOMMAND Commandsは以下の通りです。 (1)、応答(2)、traceon(3)、traceoff(4)、SUNの予約された(5)を要求してください。 パケットにこれらのコマンド値で断片の分野一連番号、断片番号、および数を含んではいけません。
The following new commands (with values in brackets) are
required:
以下の新しいコマンド(値が括弧にある)が必要です:
TRIGGERED REQUEST (6)
引き起こされた要求(6)
A request for the responding system to send all of its
routing database.
応じるシステムがルーティングデータベースのすべてを送るという要求。
Only the first 4 octets of the packet format shown in
figure 2 are sent, since all routing information is
implied by this request type.
図に情報をすべて発送して以来2が送られるのが示されたパケット・フォーマットの最初の4つの八重奏だけがこの要求タイプによって暗示されます。
TRIGGERED RESPONSE (7)
引き起こされた応答(7)
A message containing all of the sender's routing
database, excluding those entries learned from the
interface to which the routing information is being
sent.
ルーティング情報が送られるインタフェースから学習されたそれらのエントリーを除いて、送付者のルーティングデータベースのすべてを含むメッセージ。
This message may be sent in response to a triggered
request, or it may be an update message resulting
from a change in the routing database.
引き起こされた要求に対応してこのメッセージを送るかもしれませんか、それはルーティングデータベースにおける変化から生じるアップデートメッセージであるかもしれません。
A triggered response message MUST be sent in response
to a triggered request message even if there are no
routes to propagate. This would be the case for a
host which had a WAN interface only, but which wished
to run the triggered update protocol.
伝播するルートが全くなくても、引き起こされた要求メッセージに対応して引き起こされた応答メッセージを送らなければなりません。 これはWANインタフェースしか持っていませんでしたが、引き起こされたアップデートプロトコルを実行したがっていたホストのためのそうでしょう。
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| command (1) | version (1) | must be zero (2) |
+---------------+---------------+-------------------------------+
0 1 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コマンド(1)| バージョン(1)| ゼロが(2)であったならそうしなければなりません。| +---------------+---------------+-------------------------------+
The following new fields are inserted for some commands
以下の新しい野原はいくつかのコマンドのために挿入されます。
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sequence number (2) | fragment (1) |no of frags (1)|
+-------------------------------+-------------------------------+
0 1 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号(2)| 断片(1)|(1)を破片手榴弾で殺傷します。| +-------------------------------+-------------------------------+
Meyer [Page 14] RFC 1582 Demand RIP February 1994
マイヤー[14ページ]RFC1582は裂け目の1994年2月を要求します。
Followed by up to 25 routing entries (each 20 octets)
最大25のルーティングエントリーがあとに続いています。(各20の八重奏)
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| address family identifier (2) | must be zero (2) |
+-------------------------------+-------------------------------+
| IP address (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| must be zero (4) |
+---------------------------------------------------------------+
| metric (4) |
+---------------------------------------------------------------+
.
.
0 1 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレスファミリー識別子(2)| ゼロが(2)であったならそうしなければなりません。| +-------------------------------+-------------------------------+ | IPアドレス(4)| +---------------------------------------------------------------+ | ゼロが(4)であったならそうしなければなりません。| +---------------------------------------------------------------+ | ゼロが(4)であったならそうしなければなりません。| +---------------------------------------------------------------+ | メートル法の(4)| +---------------------------------------------------------------+ . .
The format of an IP RIP datagram in octets, with each tick mark
representing one bit. All fields are in network order.
各ダニ麻痺が1ビットを表している八重奏における、IP RIPデータグラムの形式。 すべての分野がネットワークオーダーにあります。
The four octets: sequence number (2), fragment number (1) and
number of fragments (1) are not present in the original RIP
specification. They are only present if command takes the
values 7 or 8.
4つの八重奏: 断片(1)の一連番号(2)、断片番号(1)、および数は当初のRIP仕様に存在していません。 コマンドが値7か8を取る場合にだけ、それらは存在しています。
Figure 2. IP Routing Information Protocol packet format
図2。 IPルーティング情報プロトコルパケット・フォーマット
TRIGGERED ACKNOWLEDGEMENT (8)
引き起こされた承認(8)
A message sent in response to every triggered response
packet received.
あらゆる引き起こされた応答パケットに対応して送られたメッセージは受信されました。
Only the first 8 octets of the packet format shown in
figure 2 are sent.
2が中で計算するのが示されたパケット・フォーマットの最初の8つの八重奏だけを送ります。
VERSION In this instance Version 1.
バージョンInはこのインスタンスバージョン1です。
SEQUENCE NUMBER
一連番号
This is a new field inserted if command takes the values 7
or 8.
これはコマンドが値7か8を取るなら挿入された新しい野原です。
The sequence number MUST be incremented every time updated
information is sent out on a WAN. The sequence number
wraps round at 65535.
WANでアップデートされた情報を出すときはいつも、一連番号を増加しなければなりません。 一連番号は65535でラウンドを包装します。
Meyer [Page 15] RFC 1582 Demand RIP February 1994
マイヤー[15ページ]RFC1582は裂け目の1994年2月を要求します。
When a triggered acknowledgement is sent the sequence
number is set to the same value as the triggered response
packet being acknowledged.
引き起こされた承認を送るとき、承認されていて、引き起こされた応答パケットと同じ値に一連番号を設定します。
The sequence number MUST be identical over fragments. If a
fragment is retransmitted the sequence number MUST not
change.
一連番号は断片の上に同じであるに違いありません。 断片が再送されるなら、一連番号は変化してはいけません。
FRAGMENT NUMBER
断片番号
The fragment number is one for the first fragment of a
routing update, and is incremented for each subsequent
fragment. A fragment can contain up to 25 routing entries.
断片番号は、ルーティングアップデートの最初の断片のためのものであり、それぞれのその後の断片のために増加されます。 断片は最大25のルーティングエントリーを含むことができます。
When a triggered acknowledgement is sent the fragment
number is set to the same value as the triggered response
packet being acknowledged.
引き起こされた承認を送るとき、承認されていて、引き起こされた応答パケットと同じ値に断片番号を設定します。
NUMBER OF FRAGMENTS
断片の数
In a triggered response packet this indicates the number of
packets required to complete the routing update.
引き起こされた応答パケットでは、これは、パケットの数がルーティングアップデートを終了するのが必要であることを示します。
This field has no relevance for triggered acknowledgement
packets so should be set to zero.
この分野は合わせてくださいしたがってパケットが設定されるべきであるゼロ引き起こされた承認のために関連性がありません。
For triggered response packets the rest of the datagram contains a list of destinations, with information about each. Each entry in this list contains the address family identifier (2 for IP), a destination network or host, and the metric for it. The packet format is intended to allow RIP to carry routing information for several different protocols, identifiable by the family identifier.
引き起こされた応答パケットに関しては、データグラムの残りはおよそそれぞれ情報で目的地のリストを含んでいます。 このリストにおける各エントリーはそれのためのアドレスファミリー識別子(IPのための2)か送信先ネットワークかホストと、メートル法を含んでいます。 パケット・フォーマットが、RIPがいくつかの異なったプロトコルのためのルーティング情報を運ぶのを許容することを意図します、ファミリー識別子で、身元保証可能です。
The IP address is the usual Internet address, stored as 4 octets in network order. The metric field contains a value between 1 and 15 inclusive, specifying the current metric for the destination, or the value 16 (representing 'infinity'), which indicates that the destination is not reachable. Each route sent by a router supersedes any previous route to the same destination from the same router.
IPアドレスはネットワークオーダーにおける4つの八重奏として保存された普通のインターネット・アドレスです。 メートル法の分野は包括的に値を1と15の間含んでいます、目的地における、メートル法の電流、または値16('無限'を表す)(目的地が届いていないのを示す)を指定して。 ルータによって送られた各ルートは同じルータから同じ目的地にどんな前のルートにも取って代わります。
The maximum datagram size is 508 octets, excluding UDP and IP headers.
UDPとIPヘッダーを除いて、最大のデータグラムサイズは508の八重奏です。
4. IP Routing Information Protocol Version 2
4. IPルーティング情報プロトコルバージョン2
An enhancement to IP RIP to include subnetting has recently become available [2]. This section only describes differences from that RFC.
サブネッティングを含むIP RIPへの増進は最近、利用可能な[2]になりました。 このセクションはそのRFCから違いについて説明するだけです。
Meyer [Page 16] RFC 1582 Demand RIP February 1994
マイヤー[16ページ]RFC1582は裂け目の1994年2月を要求します。
The triggered update mechanism can be supported by including the triggered request (6), triggered response (7) and triggered acknowledgement (8) commands described in the previous section.
引き起こされた要求(6)を含んでいることによって、引き起こされたアップデートメカニズムをサポートできます、と引き起こされた応答(7)と引き起こされた承認(8)命令は前項で説明しました。
The sequence number, fragment number and number of fragments fields are included in triggered response and triggered acknowledgement commands.
分野が含まれている断片の一連番号、断片番号、および数は、応答の引き金となって、承認命令の引き金となりました。
The triggered request packet should also contain the 4 extra octets corresponding to the sequence number, fragment number and number of fragments fields - but set to zero.
また、引き起こされたリクエスト・パケットは断片の一連番号、断片番号、および数に対応するのがさばく4つの付加的な八重奏を含むはずです--しかし、ゼロに、セットしました。
Because additional security information is included in RIP Version 2 packets, this MUST be appended to the triggered request and triggered acknowledgement packets, as well as being present in the triggered response packet.
追加担保情報がRIPバージョン2パケットに含まれているので、引き起こされた応答パケットで存在していることと同様に引き起こされた要求と引き起こされた確認応答パケットにこれを追加しなければなりません。
The version number becomes 2. Other aspects of packet layout follow reference [2].
バージョン番号は2になります。 パケットレイアウトの他の局面は参照[2]に続きます。
5. Netware Routing Information Protocol
5. ネットウェア経路情報プロトコル
This section should be read in conjunction with references [3], since it only describes differences from the specification.
仕様から違いについて説明するだけであるので、このセクションは参照[3]に関連して読まれるべきです。
Netware [3] is the trade name of Novell Research's protocols for computer communication which are derived and extended from Xerox Network System's (XNS) protocols [4].
ネットウェア[3]はコンピュータコミュニケーションのためのゼロックスNetwork System(XNS)のプロトコル[4]から引き出されて、広げられるノベルResearchのプロトコルの商号です。
Netware supports a mechanism that allows routers on an internetwork to exchange routing information using the Routing Information Protocol (RIP) which runs over the Internetwork Packet Exchange (IPX) protocol using socket number 453h.
ネットウェアはインターネットワークに関するルータがソケット番号453hを使用することでInternetwork Packet Exchange(IPX)プロトコルをひくルーティング情報プロトコル(RIP)を使用することでルーティング情報を交換できるメカニズムをサポートします。
Netware RIP and IP RIP share a common heritage, in that they are both based on XNS RIP, but there is some divergence, mostly at the packet format level to reflect the differing addressing schemes.
ともにXNS RIPに基づいていますが、体系を扱いながら相違を反映するために何らかの分岐がほとんどパケット・フォーマットレベルにあるので、ネットウェアRIPとIP RIPは一般的な遺産を分担します。
The triggered update mechanism can be applied to Netware RIP. To support the mechanism outlined in this proposal the packet format for Netware RIP is modified as shown in Figure 3.
引き起こされたアップデートメカニズムをNetware RIPに適用できます。 この提案に概説されたメカニズムをサポートするために、Netware RIPのためのパケット・フォーマットは図3に示されるように変更されています。
Every datagram contains the following:
あらゆるデータグラムが以下を含んでいます:
Meyer [Page 17] RFC 1582 Demand RIP February 1994
マイヤー[17ページ]RFC1582は裂け目の1994年2月を要求します。
RIP OPERATION
操作を裂いてください。
Operations supported in standard Netware RIP are: request
(1) and response (2).
標準のNetware RIPでサポートされた操作は以下の通りです。 (1)と応答(2)を要求してください。
The fields sequence number, fragment number and number of
fragments MUST NOT be included in packets with these
operation values.
パケットにこれらの操作値で断片の分野一連番号、断片番号、および数を含んではいけません。
The following new operations are required (with values
chosen to be the same as for IP RIP commands):
以下の新しい操作が必要です(値がIP RIPコマンドのように同じになるように選ばれている状態で):
0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| operation (2) |
+---------------+---------------+
0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 操作(2)| +---------------+---------------+
The following new fields are inserted for some operations
以下の新しい野原はいくつかの操作のために挿入されます。
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sequence number (2) | fragment (1) |no of frags (1)|
+-------------------------------+-------------------------------+
0 1 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号(2)| 断片(1)|(1)を破片手榴弾で殺傷します。| +-------------------------------+-------------------------------+
Followed by up to 50 routing entries (each 8 octets)
最大50のルーティングエントリーがあとに続いています。(各8つの八重奏)
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| network number (4) |
+---------------------------------------------------------------+
| number of hops (2) | number of ticks (2) |
+---------------------------------------------------------------+
.
.
0 1 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ネットワーク・ナンバー(4)| +---------------------------------------------------------------+ | ホップ(2)の数| カチカチする音(2)の数| +---------------------------------------------------------------+ . .
The format of a Netware RIP datagram in octets, with each tick
mark representing one bit. All fields are in network order.
各ダニ麻痺が1ビットを表している八重奏における、Netware RIPデータグラムの形式。 すべての分野がネットワークオーダーにあります。
The four octets: sequence number (2), fragment number (1) and
number of fragments (1) are not present in the original RIP
specification. They are only present if operation takes the
values 7 or 8.
4つの八重奏: 断片(1)の一連番号(2)、断片番号(1)、および数は当初のRIP仕様に存在していません。 操作が値7か8を取る場合にだけ、それらは存在しています。
Figure 3. Netware Routing Information Protocol packet format
図3。 ネットウェアルーティング情報プロトコルパケット・フォーマット
Meyer [Page 18] RFC 1582 Demand RIP February 1994
マイヤー[18ページ]RFC1582は裂け目の1994年2月を要求します。
TRIGGERED REQUEST (6)
引き起こされた要求(6)
A request for the responding system to send all of its
routing database.
応じるシステムがルーティングデータベースのすべてを送るという要求。
Only the first 2 octets of the packet format shown in
figure 3 are sent, since all routing information is
implied by this request type.
図に情報をすべて発送して以来3が送られるのが示されたパケット・フォーマットの最初の2つの八重奏だけがこの要求タイプによって暗示されます。
TRIGGERED RESPONSE (7)
引き起こされた応答(7)
A message containing all of the sender's routing
database, excluding those entries learned from the
interface to which the routing information is being
sent.
ルーティング情報が送られるインタフェースから学習されたそれらのエントリーを除いて、送付者のルーティングデータベースのすべてを含むメッセージ。
This message may be sent in response to a triggered
request, or it may be an update message resulting
from a change in the routing database.
引き起こされた要求に対応してこのメッセージを送るかもしれませんか、それはルーティングデータベースにおける変化から生じるアップデートメッセージであるかもしれません。
A triggered response message MUST be sent in response
to a triggered request message even if there are no
routes to propagate. This would be the case for a
host which had a WAN interface only, but which wished
to run the triggered update protocol.
伝播するルートが全くなくても、引き起こされた要求メッセージに対応して引き起こされた応答メッセージを送らなければなりません。 これはWANインタフェースしか持っていませんでしたが、引き起こされたアップデートプロトコルを実行したがっていたホストのためのそうでしょう。
TRIGGERED ACKNOWLEDGEMENT (8)
引き起こされた承認(8)
A message sent in response to every triggered
response packet received.
あらゆる引き起こされた応答パケットに対応して送られたメッセージは受信されました。
Only the first 6 octets of the packet format shown in
figure 3 are sent.
3が中で計算するのが示されたパケット・フォーマットの最初の6つの八重奏だけを送ります。
SEQUENCE NUMBER
一連番号
This is a new field inserted if operation takes the
values 7 or 8.
これは操作が値7か8を取るなら挿入された新しい野原です。
The sequence number MUST be incremented every time
updated information is sent out on a WAN. The sequence
number wraps round at 65535.
WANでアップデートされた情報を出すときはいつも、一連番号を増加しなければなりません。 一連番号は65535でラウンドを包装します。
When a triggered acknowledgement is sent the sequence
number is set to the same value as the triggered response
packet being acknowledged.
引き起こされた承認を送るとき、承認されていて、引き起こされた応答パケットと同じ値に一連番号を設定します。
Meyer [Page 19] RFC 1582 Demand RIP February 1994
マイヤー[19ページ]RFC1582は裂け目の1994年2月を要求します。
The sequence number MUST be identical over fragments. If
a fragment is retransmitted the sequence number MUST not
change.
一連番号は断片の上に同じであるに違いありません。 断片が再送されるなら、一連番号は変化してはいけません。
FRAGMENT NUMBER
断片番号
The fragment number is one for the first fragment of a
routing update, and is incremented for each subsequent
fragment. A fragment can contain up to 50 routing entries.
断片番号は、ルーティングアップデートの最初の断片のためのものであり、それぞれのその後の断片のために増加されます。 断片は最大50のルーティングエントリーを含むことができます。
When a triggered acknowledgement is sent the fragment
number is set to the same value as the triggered response
packet being acknowledged.
引き起こされた承認を送るとき、承認されていて、引き起こされた応答パケットと同じ値に断片番号を設定します。
NUMBER OF FRAGMENTS
断片の数
In a triggered response packet this indicates the number
of packets required to complete the routing update.
引き起こされた応答パケットでは、これは、パケットの数がルーティングアップデートを終了するのが必要であることを示します。
This field has no relevance for triggered acknowledgement
packets so should be set to zero.
この分野は合わせてくださいしたがってパケットが設定されるべきであるゼロ引き起こされた承認のために関連性がありません。
For triggered response packets the rest of the datagram contains a list of networks, with information about each. Each entry in this list contains a destination network, and the number of hops and number of ticks for each.
引き起こされた応答パケットに関しては、データグラムの残りはおよそそれぞれ情報でネットワークのリストを含んでいます。 このリストにおける各エントリーは送信先ネットワーク、ホップの数、およびそれぞれのためのカチカチする音の数を含んでいます。
The maximum datagram size is 406 octets, excluding the IPX header (a further 30 octets).
IPXヘッダー(より遠い30の八重奏)を除いて、最大のデータグラムサイズは406の八重奏です。
6. Netware Service Advertising Protocol
6. ネットウェアサービス広告プロトコル
This section should be read in conjunction with references [3], since it only describes differences from the specification.
仕様から違いについて説明するだけであるので、このセクションは参照[3]に関連して読まれるべきです。
Netware [3] also supports a mechanism that allows servers on an internetwork to advertise their services by name and type using the Service Advertising Protocol (SAP) which runs over the Internetwork Packet Exchange (IPX) protocol using socket number 452h.
また、ネットウェア[3]は名前の彼らのサービスの広告を出して、ソケット番号452hを使用することでInternetwork Packet Exchange(IPX)プロトコルをひくサービス通知プロトコル(SAP)を使用することでタイプするためにインターネットワークにサーバを許容するメカニズムをサポートします。
SAP operates on similar principals to running RIP. Routers act as SAP agents, collecting service information from different networks and relay it to interested parties.
SAPは実行しているRIPとして同様の主体を運用します。 ルータは、異なったネットワークからサービス情報を集めて、SAPのエージェントとして務めて、利害関係者にそれをリレーします。
To support the triggered update mechanism outlined in this proposal the packet format for Netware SAP is modified as shown in Figure 4.
この提案に概説された引き起こされたアップデートメカニズムをサポートするために、Netware SAPのためのパケット・フォーマットは図4に示されるように変更されています。
Every Service Advertising Protocol datagram contains the following:
あらゆるサービス通知プロトコルデータグラムが以下を含んでいます:
Meyer [Page 20] RFC 1582 Demand RIP February 1994
マイヤー[20ページ]RFC1582は裂け目の1994年2月を要求します。
SAP OPERATION
SAP操作
Operations supported in standard Netware SAP are: general
service query (1), general service response (2), nearest
service query (3) and nearest service response (4).
標準のNetware SAPでサポートされた操作は以下の通りです。 一般的なサービス質問(1)、最もサービスにおける一般的なサービス応答(2)は(3)と最も近いサービス応答(4)について質問します。
The fields sequence number, fragment number and number of
fragments MUST NOT be included in packets with these
operation values.
パケットにこれらの操作値で断片の分野一連番号、断片番号、および数を含んではいけません。
The following new operations are required:
以下の新しい操作が必要です:
TRIGGERED GENERAL SERVICE QUERY (6)
引き起こされたゼネラルサービスの質問(6)
A request for the responding system to send the
identities of all servers of all types.
応じるシステムがすべてのタイプのすべてのサーバのアイデンティティを送るという要求。
Only the first 2 octets of the packet format shown in
figure 4 are sent, since all service types are
implied by this request type.
4が中で計算するのが示されたパケット・フォーマットの最初の2つの八重奏だけを送ります、すべてのサービスタイプがこの要求タイプによって暗示されるので。
0 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| operation (2) |
+---------------+---------------+
0 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 操作(2)| +---------------+---------------+
The following new fields are inserted for some operations
以下の新しい野原はいくつかの操作のために挿入されます。
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sequence number (2) | fragment (1) |no of frags (1)|
+-------------------------------+-------------------------------+
0 1 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号(2)| 断片(1)|(1)を破片手榴弾で殺傷します。| +-------------------------------+-------------------------------+
Meyer [Page 21] RFC 1582 Demand RIP February 1994
マイヤー[21ページ]RFC1582は裂け目の1994年2月を要求します。
Followed by up to 8 service entries (each 66 octets)
最大8つのサービスエントリーがあとに続いています。(各66の八重奏)
0 1 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Type (4) |
+---------------------------------------------------------------+
| Service Name (48) |
+ +
.
| . |
+---------------------------------------------------------------+
| Network Address (4) |
+---------------------------------------------------------------+
| Node Address (6) |
+ +-------------------------------+
| | Socket Address (2) |
+---------------------------------------------------------------+
| Hops to Server (2) |
+-------------------------------+
.
.
0 1 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サービスタイプ(4)| +---------------------------------------------------------------+ | サービス名(48)| + + . | . | +---------------------------------------------------------------+ | ネットワーク・アドレス(4)| +---------------------------------------------------------------+ | ノードアドレス(6)| + +-------------------------------+ | | ソケットアドレス(2)| +---------------------------------------------------------------+ | サーバ(2)へのホップス| +-------------------------------+ . .
The format of a Netware SAP datagram in octets, with each tick
mark representing one bit. All fields are in network order.
各ダニ麻痺が1ビットを表している八重奏における、Netware SAPデータグラムの形式。 すべての分野がネットワークオーダーにあります。
The four octets: sequence number (2), fragment number (1) and
number of fragments (1) are not present in the original SAP
specification. They are only present if operation takes the
values 7 or 8.
4つの八重奏: 断片(1)の一連番号(2)、断片番号(1)、および数は当初のSAP仕様に存在していません。 操作が値7か8を取る場合にだけ、それらは存在しています。
Figure 4. Netware Service Advertising Protocol packet format
図4。 ネットウェアサービス通知プロトコルパケット・フォーマット
TRIGGERED GENERAL SERVICE RESPONSE (7)
引き起こされたゼネラルサービスの応答(7)
A message containing all of the sender's services
table, excluding those entries learned from the
interface to which the service advertising
information is being sent out.
サービス広告情報が出されているインタフェースから学習されたそれらのエントリーを除いて、送付者のサービステーブルのすべてを含むメッセージ。
This message may be sent in response to a triggered
general service query, or it may be an update message
resulting from a change in the service advertising
database.
引き起こされた一般的なサービス質問に対応してこのメッセージを送るかもしれませんか、それはサービス広告データベースにおける変化から生じるアップデートメッセージであるかもしれません。
Meyer [Page 22] RFC 1582 Demand RIP February 1994
マイヤー[22ページ]RFC1582は裂け目の1994年2月を要求します。
A triggered general service response message MUST be
sent in response to a triggered general request
message even if there are no services to advertise.
This would be the case for a router with a LAN
network which had work stations but no servers on it.
広告を出すサービスが全くなくても、引き起こされた一般的な要求メッセージに対応して引き起こされた一般的なサービス応答メッセージを送らなければなりません。 これはワークステーションを持っていましたが、それにどんなサーバも持っていなかったLANネットワークがあるルータのためのそうでしょう。
TRIGGERED GENERAL SERVICE ACKNOWLEDGEMENT (8)
引き起こされたゼネラルサービスの承認(8)
A message sent in response to every triggered general
service response packet received.
あらゆる引き起こされた一般的なサービス応答パケットに対応して送られたメッセージは受信されました。
Only the first 6 octets of the packet format shown in
figure 4 are sent.
4が中で計算するのが示されたパケット・フォーマットの最初の6つの八重奏だけを送ります。
SEQUENCE NUMBER
一連番号
This is a new field inserted if operation takes the values
7 or 8.
これは操作が値7か8を取るなら挿入された新しい野原です。
The sequence number MUST be incremented every time updated
information is sent out on a WAN. The sequence number
wraps round at 65535.
WANでアップデートされた情報を出すときはいつも、一連番号を増加しなければなりません。 一連番号は65535でラウンドを包装します。
When a triggered general service acknowledgement is sent
the sequence number is set to the same value as the
triggered general service response packet being
acknowledged.
引き起こされた一般的なサービス承認を送るとき、承認されていて、引き起こされた一般的なサービス応答パケットと同じ値に一連番号を設定します。
The sequence number MUST be identical over fragments. If
a fragment is retransmitted the sequence number MUST not
change.
一連番号は断片の上に同じであるに違いありません。 断片が再送されるなら、一連番号は変化してはいけません。
FRAGMENT NUMBER
断片番号
The fragment number is one for the first fragment of a
triggered general service response update, and is
incremented for each subsequent fragment. A fragment can
contain up to 8 service entries.
断片番号は、引き起こされた一般的なサービス応答アップデートの最初の断片のためのものであり、それぞれのその後の断片のために増加されます。 断片は最大8つのサービスエントリーを含むことができます。
When a triggered general service acknowledgement is sent,
the fragment number is set to the same value as the
triggered general service response packet being
acknowledged.
引き起こされた一般的なサービス承認を送るとき、承認されていて、引き起こされた一般的なサービス応答パケットと同じ値に断片番号を設定します。
NUMBER OF FRAGMENTS
断片の数
In a triggered response packet this indicates the number of
packets required to complete the service update.
引き起こされた応答パケットでは、これは、パケットの数がサービスアップデートを終了するのが必要であることを示します。
Meyer [Page 23] RFC 1582 Demand RIP February 1994
マイヤー[23ページ]RFC1582は裂け目の1994年2月を要求します。
This field has no relevance for triggered acknowledgement
packets so should be set to zero.
この分野は合わせてくださいしたがってパケットが設定されるべきであるゼロ引き起こされた承認のために関連性がありません。
For triggered general service response packets the rest of the datagram contains a list of services, with information about each. Each entry in this list contains the service type, service name, full address (network, node and socket), and the number of hops to the server.
引き起こされた一般的なサービス応答パケットに関しては、データグラムの残りはおよそそれぞれ情報でサービスのリストを含んでいます。 このリストにおける各エントリーはホップのサービスタイプ、サービス名、完全なアドレス(ネットワーク、ノード、およびソケット)、および数をサーバに含んでいます。
The maximum datagram size is 534 octets, excluding the IPX header (a further 30 octets).
IPXヘッダー(より遠い30の八重奏)を除いて、最大のデータグラムサイズは534の八重奏です。
7. Timers
7. タイマ
A number of timers are supported to handle the triggered update mechanism:
多くのタイマが引き起こされたアップデートメカニズムを扱うために支えられます:
o Database timers.
o データベースタイマ。
o Retransmission timer.
o 再送信タイマー。
o Reassembly timer.
o Reassemblyタイマ。
In this section appropriate timer values for IP RIP are suggested.
このセクションで、IP RIPのための適切なタイマ値は示されます。
For other routing protocols, only the database timer should need to take different values. The database timer values are chosen to match equivalent timer operation for using the protocol on a LAN. The behaviour of a routing entry when a timer is running becomes indistinguishable from a routing entry learned from a broadcast update.
他のルーティング・プロトコルのために、データベースタイマだけが、異価を取る必要があるはずです。 データベースタイマ値は、同等なタイマ操作に合うようにLANでプロトコルを使用するのに選ばれています。 タイマが動いているとき、ルーティングエントリーのふるまいは放送アップデートから学習されたルーティングエントリーから区別がつかなくなります。
Implementations MAY make timer values configurable - and hence different from the values suggested here - but interoperability requires that all timers on a sub-network should be the same in all routers.
実装で、構成可能であって、したがって、ここに示された値とタイマ値を異ならせるかもしれませんが、相互運用性は、サブネットワークのすべてのタイマがすべてのルータで同じであるべきであることを必要とします。
7.1 Database Timers
7.1 データベースタイマ
Routes learned by a triggered response command (7) are normally considered to be permanent - that is they do NOT time out unless activated by one of the following events:
通常、引き起こされた応答命令(7)で学習されたルートが永久的であると考えられます--すなわち、以下のイベントの1つによって動かされない場合、どんなタイムアウトもしません:
o If the circuit manager indicates that a next hop router cannot be
contacted, all routes learned from that next hop router should
start timing out as if they had (just) been learned from a
conventional response command (2).
o 回路マネージャが、次のホップルータに連絡できないのを示すなら、すべてのルートが、それからまるでそれらが(まさしく)従来の応答命令(2)から学習されたかのように次のホップルータがタイミングを始めるべきであることを学びました。
Meyer [Page 24] RFC 1582 Demand RIP February 1994
マイヤー[24ページ]RFC1582は裂け目の1994年2月を要求します。
Namely each route exists while the database entry timer is
running and is advertised on other interfaces as if still
present. The route is then advertised as unreachable while a
further hold down timer is allowed to expire, at which point the
entry is deleted.
すなわち、各ルートはデータベースエントリータイマが動いている間、存在していて、まるでまだ存在しているかのように他のインタフェースに広告を出します。 タイマの下側へのさらなる保持は期限が切れることができて、そのポイントでエントリーを削除しますが、そして、手の届かないとしてルートの広告を出します。
If the circuit manager indicates that the next hop router can be
contacted while the database entry timer is running, the routes
are reinstated as permanent entries.
回路マネージャが、データベースエントリータイマが動いている間次のホップルータに連絡できるのを示すなら、ルートは永久的なエントリーとして復職します。
If the database entry timer has expired and the circuit manager
indicates that the next hop router is reachable, the routing
application MUST issue a triggered request. The routes will be
reinstated on the basis of any triggered response packet(s)
received.
データベースエントリータイマが呼吸が絶えて、回路マネージャが、次のホップルータが届いているのを示すなら、ルーティングアプリケーションは引き起こされた要求を出さなければなりません。 ルートは(s)が受けたどんな引き起こされた応答パケットに基づいて復職するでしょう。
o If a triggered response packet is received in which a route is
marked unreachable, the hold down timer MUST be started and the
entry is advertised as unreachable on other interfaces. On
expiry of the hold down timer the entry is deleted.
o 引き起こされた応答パケットが受け取られているなら、ルートがどれであるかで手が届かないとマークされて、タイマで保持を始めなければなりません、そして、他のインタフェースで手の届かないとしてエントリーの広告を出します。 抑制タイマの満期に、エントリーは削除されます。
If a triggered response packet is received in which an existing
route is ABSENT, the hold down timer MUST also be started and
the entry is advertised as unreachable on other interfaces. On
expiry of the hold down timer the entry is deleted.
引き起こされた応答パケットが受け取られているなら、他のインタフェースで手の届かないとしてABSENT、また、タイマの下側への保持が既存のルートがどれであるかで開始しなければならないか、そして、エントリーの広告を出します。 抑制タイマの満期に、エントリーは削除されます。
For IP RIP the hold down timer should always run for 120 seconds, to be consistent with RIP usage on broadcast networks. The database entry timer should by default run for 180 seconds. The network can be made more responsive by reducing the database entry timer value. However, making this timer too short can lead to network instabilities. The duration of the database entry timer allows a period of grace in which contention for network resources can be resolved by the circuit manager.
IP RIPに関しては、タイマの下側への保持は、放送網のRIP用法と一致しているように120秒いつも立候補するべきです。 データベースエントリータイマはデフォルトで180秒立候補するはずです。 データベースエントリータイマ価値を減少させることによって、ネットワークをより敏感にすることができます。 しかしながら、このタイマを短くし過ぎるのはネットワークの不安定性に通じることができます。 データベースエントリータイマの持続時間は回路マネージャがネットワーク資源のための主張を決議できる優雅の期間を許容します。
7.2 Retransmission Timer
7.2 再送信タイマー
The routing task runs a retransmission timer:
ルーティングタスクは再送信タイマーを動かします:
o When a triggered request is sent it will be retransmitted
periodically while a triggered response packet is not received.
o 引き起こされた要求を送るとき、引き起こされた応答パケットが受け取られていない間、定期的にそれを再送するでしょう。
o When a triggered response is sent a note of the sequence number
and fragment number(s) of the routing update is kept.
o いつ、一連番号の注意を引き起こされた応答に送るか、そして、ルーティングアップデートの断片番号は保たれます。
Fragments will be retransmitted at periodic intervals while a
triggered acknowledgement packet is not received for the
appropriate fragment.
引き起こされた確認応答パケットが適切な断片のために受け取られていない間、断片は周期的な間隔で、再送されるでしょう。
Meyer [Page 25] RFC 1582 Demand RIP February 1994
マイヤー[25ページ]RFC1582は裂け目の1994年2月を要求します。
With call set up time on the WAN being of the order of a second, a value of 5 seconds for the retransmission timer is appropriate.
呼び出しで、WANの1秒の注文では、再送信タイマーのための5秒の値が適切であるということである時間をセットアップしてください。
If no response is received after 10 retransmissions, routes via the next hop router are marked as unreachable, the hold down timer MUST be started and the entry is advertised as unreachable on other interfaces. On expiry of the hold down timer the entry is deleted.
10「再-トランスミッション」の後に応答を全く受けないなら、手の届かないとして次のホップルータを通したルートをマークします、そして、タイマの下側への保持を始めなければなりません、そして、他のインタフェースで手の届かないとしてエントリーの広告を出します。 抑制タイマの満期に、エントリーは削除されます。
The next hop router is then polled using a triggered request packet at 60 second intervals. If a response is received the routers should exchange routing information using triggered response packets.
そして、60回の2番目の間隔を置いて引き起こされたリクエスト・パケットを使用することで次のホップルータは投票されます。 応答が受け取られているなら、ルータは、引き起こされた応答パケットを使用することでルーティング情報を交換するべきです。
It may not be desirable to poll indefinitely, since a lack of response (when a circuit is up) is most likely caused by incorrect configuration of the next hop router. An administrator definable number of polls (5 or greater) should be provided.
無期限に投票するのは望ましくないかもしれません、無反応(回路が上がっているとき)がたぶん次のホップルータの不正確な構成によって引き起こされるので。 管理者の定義可能な番号の投票(5以上)を提供するべきです。
If the circuit manager indicates that the next hop router is unreachable, the retransmission is suppressed until the circuit manager indicates that the next hop router is reachable once more. Counting of the number of retransmissions continues from where it left off prior to the circuit down indication.
回路マネージャが、次のホップルータが手が届かないのを示すなら、回路マネージャが、次のホップルータがもう一度届いているのを示すまで、「再-トランスミッション」は抑圧されます。 「再-トランスミッション」の数の勘定はそれが回路下に指示の前にやめられたところから続きます。
7.3 Reassembly Timer
7.3 Reassemblyタイマ
When a router receives a triggered response update it MUST acknowledge each fragment. If the routing update is fragmented over more than one packet, the receiving router MUST store the fragments until ALL fragments are received.
ルータが引き起こされた応答アップデートを受けるとき、それは各断片を承認しなければなりません。 ルーティングアップデートが1つ以上のパケットの上で断片化されるなら、すべての断片が受け取られているまで、受信ルータは断片を保存しなければなりません。
On receiving the first fragment a timer should be started. If all fragments of the routing update are not received within that period they are discarded - and a triggered request is sent back to the originator (with retransmissions if necessary). The originator MUST then resend ALL triggered response fragments.
最初の断片を受けると、タイマは始動されるべきです。 その期間中にルーティングアップデートのすべての断片を受け取るというわけではないならそれらが捨てて、引き起こされた要求を創始者に送り返す、(「再-トランスミッション」、必要なら) そして、創始者はすべての引き起こされた応答断片を再送しなければなりません。
The reassembly timer should be set to four times the value of the retransmission timer. With a suggested retransmission timer value of 5 seconds, the suggested reassembly timer value SHOULD be 20 seconds.
再アセンブリタイマは再送信タイマーの値の4倍に設定されるべきです。 提案された再送信タイマーで、5秒の値、提案された再アセンブリタイマは20が秒であったならSHOULDを評価します。
Implementations MAY allow the reassembly timer and retransmission timer to be configurable (in the 1:4 ratio), but interoperability will be compromised on WANs where all participating routers DO NOT support the same values for these timers.
実装は、再アセンブリタイマと再送信タイマーが構成可能であることを(1:4比における)許容するかもしれませんが、すべて参加しているルータがこれらのタイマのために同じ値をサポートしないところで相互運用性はWANで感染されるでしょう。
Fragments MUST also be discarded if a new fragment with a different sequence number is received. A triggered request MUST not be sent in this instance.
また、異なった一連番号がある新しい断片が受け取られているなら、断片を捨てなければなりません。 この場合引き起こされた要求を送ってはいけません。
Meyer [Page 26] RFC 1582 Demand RIP February 1994
マイヤー[26ページ]RFC1582は裂け目の1994年2月を要求します。
8. Implementation Considerations
8. 実装問題
In the implementation described in this memo, it is assumed that there is a close binding between the circuit manager and the routing applications - that they are in some way the same 'program'. This is not necessarily true of all products which are routers.
このメモで説明された実装では、回路マネージャとルーティングアプリケーションの間には、厳密な結合があると思われます--それらは同じくらいが'プログラムを作る'何らかの方法であります。 これは必ずルータであるすべての製品に関して本当であるというわけではありません。
In particular there are UNIX host implementations in which the routing application is distinct from the kernel, where the circuit manager is likely to be installed. In such systems it is possible to stop (or crash) the routing applications independently of what is happening in the kernel.
ルーティングアプリケーションがカーネルと異なっているUNIXホスト導入が特にあります。そこでは、回路マネージャがインストールされそうです。 そのようなシステムでは、カーネルで起こっていることの如何にかかわらずルーティングアプリケーションを止めるのは(ダウンしてください)可能です。
Other implementations might have the circuit manager on a separate card which again may give the circuit manager a life of its own.
他の実装には、回路マネージャが再びそれ自身の寿命を回路マネージャに与えるかもしれない別々のカードにいるかもしれません。
In implementations where the applications and circuit manager have independent lives, a keep-alive mechanism MUST be provided between the applications and the circuit manager, so that if the application or network layer dies and is subsequently re-started they can resynchronize their state tables.
実装では、アプリケーションと回路マネージャが独立している寿命を過すところでアプリケーションと回路マネージャの間に生きている生活費メカニズムを提供しなければなりません、アプリケーションかネットワーク層が死んで、次に再開されるなら自己のステートテーブルを再連動させることができるように。
Ideally, when an application dies, the circuit manager should close all existing VCs appropriate to the application and make no further outgoing calls and reject incoming calls until the application is running again.
理想的に、アプリケーションが死ぬと、アプリケーションが再び稼働するまで、回路マネージャは、アプリケーションに適切なすべての既存のVCsを閉じて、これ以上発信電話をしないで、かかってきた電話を拒絶するべきです。
If the circuit manager is using some form of encapsulation, several applications may be sharing the same VC. If this is the case the circuit manager may wish to filter out datagrams for the appropriate network layer if only one of the applications is affected. But this is not an ideal solution.
回路マネージャが何らかのフォームのカプセル化を使用しているなら、いくつかのアプリケーションが同じVCを共有しているかもしれません。 これがそうなら、回路マネージャが1だけであるなら適切なネットワーク層のためにデータグラムを無視したがっているかもしれないアプリケーションのケースは影響を受けます。 しかし、これは理想的な解決ではありません。
Conversely if the application believes the circuit manager has died, it should mark all routes via the circuit manager as unreachable and advertise them on other interfaces for the duration of the hold down timer before deleting them.
逆に、アプリケーションが、回路マネージャが死んだと信じているなら、それは、手の届かないとしての回路マネージャを通してすべてのルートをマークして、それらを削除する前に、保持の持続時間のために他のインタフェースにタイマの下側にそれらの広告を出すべきです。
9. Security Considerations
9. セキュリティ問題
Security is provided my a number of aspects:
私の局面のa番号をセキュリティに提供します:
o The circuit manager is required to be provided with a list of
physical addresses to enable it to establish a call to the next
hop router on an X.25 SVC or ISDN B-channel.
o 物理アドレスのリストは、X.25 SVCかISDN B-チャンネルの上に次のホップルータに呼び出しを確立するのを可能にするために回路マネージャは提供されなければなりません。
The circuit manager SHOULD only allow incoming calls to be
accepted from the same well defined list of routers.
回路マネージャSHOULDはルータの同じよく定義されたリストから受け入れられるというかかってきた電話を許容するだけです。
Meyer [Page 27] RFC 1582 Demand RIP February 1994
マイヤー[27ページ]RFC1582は裂け目の1994年2月を要求します。
Elsewhere in the system there will be a set of logical address
and physical address tuples to enable the network protocols to
run over the correct circuit. This may be a lookup table, or in
some instances there may be an algorithmic conversion between
the two addresses.
システムのほかの場所に、ネットワーク・プロトコルが正しい回路の上に実行するのを可能にする論理アドレスと物理アドレスtuplesの1セットがあるでしょう。 これはルックアップ表であるかもしれません、または2つのアドレスの間には、アルゴリズムの変換がある場合にあるかもしれません。
o The routing (or service advertising) task MUST be provided with a
list of logical addresses to which triggered updates are to be
sent on the WAN. The list MAY be a subset of the list of next
hop routers maintained by the circuit manager.
o WANで送られる引き起こされたアップデートがことである論理アドレスのリストをルーティング(または、サービス広告)タスクに提供しなければなりません。 リストは回路マネージャによって維持された次のホップルータのリストの部分集合であるかもしれません。
There MAY also be a separate list of next hop routers to which
traditional broadcasts of routing (or service advertising)
updates should be sent. Next hop routers omitted from either
list are assumed to be not participating in routing (or service
advertising) updates.
また、ルーティング(または、サービス広告)アップデートの伝統的な放送が送られるべきである次のホップルータの別々のリストがあるかもしれません。 どちらのリストからも省略された次のホップルータがルーティング(または、サービス広告)アップデートに参加していないと思われます。
The list (or lists) doubles as a list of routers from which
routing updates are allowed to be received from the WAN. Any
routing information received from a router not in the
appropriate list MUST be discarded.
リスト(または、リスト)をルーティングアップデートがWANから受け取ることができるルータのリストの役目も兼ねます。 適切なリストでルータから受け取られた少しのルーティング情報も捨ててはいけません。
10. References
10. 参照
[1] Hedrick. C., "Routing Information Protocol", STD 34, RFC 1058,
Rutgers University, June 1988.
[1] ヘドリック。 C. STD34、「情報プロトコルを発送すること」でのRFC1058、ラトガース大学、1988年6月。
[2] Malkin. G., "RIP Version 2 - Carrying Additional Information",
RFC 1388, Xylogics, January 1993.
[2] マルキン。 G.、「追加情報を運んで、バージョン2をコピーしてください」、RFC1388、Xylogics、1月1993日
[3] Novell Incorporated., "IPX Router Specification", Version 1.10,
October 1992.
[3] ノベルが法人組織にした、「IPXルータ仕様」、バージョン1.10、10月1992
[4] Xerox Corporation., "Internet Transport Protocols", Xerox System
Integration Standard XSIS 028112, December 1981.
[4]ゼロックス社、「インターネットトランスポート・プロトコル」、ゼロックスのシステムインテグレーションの標準のXSIS028112、12月1981日
[5] Malis. A., Robinson. D., and R. Ullmann, "Multiprotocol
Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356, BBN
Communications, Computervision Systems Integration, Process
Software Corporation, August 1992.
[5] Malis。 A.、ロビンソン。 D.、およびR.ウルマン、「Multiprotocolはパケット形態によるX.25とISDNで内部連絡します」、RFC1356、BBNコミュニケーション、Computervisionシステム・インテグレーション、プロセスソフトウェア社、1992年8月。
Meyer [Page 28] RFC 1582 Demand RIP February 1994
マイヤー[28ページ]RFC1582は裂け目の1994年2月を要求します。
11. Author's Address
11. 作者のアドレス
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 29]
マイヤー[29ページ]
一覧
スポンサーリンク
