RFC2091 日本語訳
2091 Triggered Extensions to RIP to Support Demand Circuits. G. Meyer,S. Sherry. January 1997. (Format: TXT=44835 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group G. Meyer
Request for Comments: 2091 Shiva
Category: Standards Track S. Sherry
Xyplex
January 1997
コメントを求めるワーキンググループG.マイヤー要求をネットワークでつないでください: 2091年のシバ神Category: 標準化過程S.シェリー酒のXyplex1997年1月
Triggered 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
要約
This document defines a modification which can be applied to Bellman-Ford (distance vector) algorithm information broadcasting protocols - for example IP RIP, Netware RIP or Netware SAP - which makes it feasible to run them on connection oriented Public Data Networks.
このドキュメントは接続の指向のPublic Data Networksにそれらを実行するのを可能にするプロトコル(例えば、IP RIP、Netware RIPまたはNetware SAP)を放送するBellman-フォード(距離ベクトル)アルゴリズム情報に適用できる変更を定義します。
This proposal has a number of efficiency advantages over the Demand RIP proposal (RFC 1582).
この提案には、Demand RIP提案(RFC1582)より多くの効率利点があります。
Acknowledgements
承認
The authors wish to thank Richard Edmonstone of Shiva, Joahanna Kruger of Xyplex, Steve Waters of DEC and Guenter Roeck of Conware for many comments and suggestions which improved this effort.
作者はこの取り組みを改良した多くのコメントと提案について12月のシバ神のリチャードEdmonstone、XyplexのJoahannaクルーガースティーブWatersとConwareのギュンターRoeckに感謝したがっています。
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
circumstances.
o SHOULD--商品はほとんど例外的な事情のために従われるべきです。
Meyer & Sherry Standards Track [Page 1] RFC 2091 Trigger RIP January 1997
標準化過程[1ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年1月に裂かれます。
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 ........................................... 2
2. Overview ............................................... 3
3. The Routing Database ................................... 5
3.1. Presumption of Reachability ...................... 6
3.2. Alternative Routes ............................... 6
3.3. Split Horizon with Poisoned Reverse .............. 7
3.4. Managing Updates ................................. 7
3.5. Retransmissions .................................. 7
4. New Packet Types ....................................... 8
4.1. Update Request (9) ............................... 9
4.2. Update Response (10) ............................. 9
4.3. Update Acknowledge (11) .......................... 10
5. Packet Formats ......................................... 10
5.1. Update Header .................................... 10
5.2. IP Routing Information Protocol Version 1 ........ 11
5.3. IP Routing Information Protocol Version 2 ........ 11
5.4. Netware Routing Information Protocol ............. 12
5.5. Netware Service Advertising Protocol ............. 12
6. Timers ................................................. 17
6.1. Database Timer ................................... 17
6.2. Hold Down Timer .................................. 17
6.3. Retransmission Timer ............................. 18
6.4. Over-subscription Timer .......................... 18
7. Security Considerations ................................ 19
Appendix A - Implementation Suggestion .................... 20
References ................................................ 21
Authors' Addresses ........................................ 22
1. 序論… 2 2. 概要… 3 3. ルート設定データベース… 5 3.1. 可到達性の推定… 6 3.2. 代替のルート… 6 3.3. 当たっている逆で地平線を分けてください… 7 3.4. アップデートを管理します… 7 3.5. Retransmissions… 7 4. 新しいパケットはタイプされます… 8 4.1. 要求(9)をアップデートしてください… 9 4.2. 応答(10)をアップデートしてください… 9 4.3. アップデートは(11)を承認します… 10 5. パケット形式… 10 5.1. ヘッダーをアップデートしてください… 10 5.2. IPルーティング情報プロトコルバージョン1… 11 5.3. IPルーティング情報プロトコルバージョン2… 11 5.4. ネットウェア経路情報プロトコル… 12 5.5. ネットウェアサービス広告プロトコル… 12 6. タイマ… 17 6.1. データベースタイマ… 17 6.2. タイマを押さえてください… 17 6.3. Retransmissionタイマ… 18 6.4. 過剰購読タイマ… 18 7. セキュリティ問題… 19 付録A--実装提案… 20の参照箇所… 21人の作者のアドレス… 22
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つのサイトの間の関係は、実際に短くて、比較的珍しいかもしれません。
Meyer & Sherry Standards Track [Page 2] RFC 2091 Trigger RIP January 1997
標準化過程[2ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年1月に裂かれます。
Periodic broadcasting by Bellman-Ford (distance vector) algorithm information broadcasting protocols IP RIP [1], IP RIP V2 [2] or Netware RIP and SAP [3] generally prevents WAN circuits from being closed. Even on fixed point-to-point links the overhead of periodic transmission of RIP - and even more so SAP broadcasts - can seriously interrupt normal data transfer simply through the quantity of information which hits the line every 30 or 60 seconds.
一般に、プロトコルIP RIP[1]かIP RIP V2[2]かNetware RIPとSAP[3]を放送するBellman-フォード(距離ベクトル)アルゴリズム情報による周期的な放送は、WAN回路が閉じられるのを防ぎます。 定点からポイントへのリンクの上にさえ、RIP(さらにそうであるSAP放送)の周期的なトランスミッションのオーバーヘッドは単に30秒か60秒毎に系列を打つ情報の量を通して真剣に正常なデータ転送を中断できます。
To overcome these limitations, this specification modifies the distance vector 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のメディア、承認、および「再-トランスミッション」を通るために保証されないので、システムが信頼性を提供するのに必要です。
The protocols run unmodified on Local Area Networks (LANs) and so interoperate transparently with implementations adhering to the original specifications.
透過的に実装が正式仕様書を固く守っていて、プロトコルは、ローカル・エリア・ネットワーク(LAN)で変更されていなく稼働しているので、共同利用します。
This proposal differs from Demand RIP [4] conceptually as follows:
この提案は以下の通り[4] 概念的にDemand RIPと異なっています:
o If a router has exchanged all routing information with its partner
and some routing information subsequently changes only the changed
information is sent to the partner.
o ルータがすべてのルーティング情報をパートナーと交換して、何らかのルーティング情報が次に変化するなら、変えられた情報だけをパートナーに送ります。
o The receiver of routes is able to apply all changes immediately
upon receiving information from a partner.
o ルートの受信機はすぐパートナーから情報を受け取るときのすべての変化を適用できます。
These differences lead to further reduced routing traffic and also require less memory than Demand RIP [4]. Demand RIP also has an upper limit of 255 fragments in an update which is lifted in Triggered RIP (which does not use fragmentation).
これらの違いはルーティングトラフィックをさらに減少させて、また、Demand RIP[4]より少ないメモリを必要とするのを導きます。 また、要求RIPはTriggered RIP(断片化を使用しない)で撤廃されるアップデートで255個の断片の上限を持っています。
2. Overview
2. 概要
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が同時に、ルータの単一の物理インターフェースを通してインタコネクトされることができます。
Meyer & Sherry Standards Track [Page 3] RFC 2091 Trigger RIP January 1997
標準化過程[3ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年1月に裂かれます。
A circuit manager provides an interface between the connectionless network layers, IP and IPX, and the connection oriented WAN, X.25, ISDN etc. Figure 1 shows a schematic representative stack showing the relationship between routing protocols, the network layers, the circuit manager and the connection oriented WAN.
回路マネージャはコネクションレスなネットワーク層と、IPと、IPXと、接続とのインタフェースに指向のWAN、ISDN X.25などを提供します。 図1は、概要の代表しているスタックが、ルーティング・プロトコルの間では、ネットワーク層、回路マネージャ、および接続が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.
ルータはVirtual Circuitを証明するのに使用される物理アドレス(VC)に次のホップルータのネットワーク層アドレスを関係づける変換テーブルをそれに持っています。
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 (or some other mechanism) is used to close the VC when the datagrams stop arriving at the circuit manager.
回路マネージャは、コネクションレスなネットワーク層プロトコルからデータグラムを取って、次のホップルータにVCを開きます(1つが現在利用可能でないなら)。 VCは与えられたネットワーク層プロトコル(または、適切なカプセル化によるすべてのネットワーク層プロトコル)のために2つの終わりのポイントルータの間まですべてのトラフィックを運ぶことができます。 データグラムが、回路マネージャに到着するのを止めると、使用されていないタイマ(または、ある他のメカニズム)は、VCを閉じるのに使用されます。
Meyer & Sherry Standards Track [Page 4] RFC 2091 Trigger RIP January 1997
標準化過程[4ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年1月に裂かれます。
If the circuit manager has data to forward (whether user data OR a routing update) and fails to obtain a VC it informs the routing application that the destination is unreachable (circuit down). The circuit manager is then expected to perform whatever is necessary to recover the link. Once successful, it informs the routing application (circuit up).
回路マネージャに転送するデータがある、(利用者データOR aルーティング最新版) そして、手が届かない状態で(回路が下にある状態で)目的地がルーティングアプリケーションですが、それが知らせるVCを入手するやり損ない。 そして、何がリンクを回収するのに必要であっても、回路マネージャが働くと予想されます。 かつてうまくいって、それはルーティングアプリケーション(回路が上にある状態で)を知らせます。
In Triggered RIP, routing updates are only transmitted on the WAN when required:
Triggered RIPでは、必要であると、ルーティングアップデートはWANで伝えられるだけです:
1 When a specific request for a routing update has been received.
1 ルーティングアップデートを求める特定の要求を受け取ったとき。
2 When the routing database is modified by new information from
another interface.
ルーティングデータベースが別のものからの新情報によって変更されるとき、2は連結します。
3 When the circuit manager indicates that a destination has changed
from an unreachable (circuit down) to a reachable (circuit up)
state.
3 回路マネージャがいつそのaの目的地を示すかはaに手の届かない(回路が下にある状態で)届いている(回路が上にある状態で)状態から変化しました。
4 And also when a unit is first powered on to ensure that at least
one update is sent. This can be thought of as a transition from
circuit down to circuit up. It MAY contain no routes or services,
and is used to flush routes or services from the peer's database.
4 そして、また、いつに関して、最初に、その少なくとも1つのアップデートを確実にするのをユニットを動かさせますか。 回路から回路まで上がっている変遷としてこれを考えることができます。 それは、どんなルートもサービスも含まないかもしれなくて、同輩のデータベースからルートかサービスを洗い流すのに使用されます。
In cases 1,3 and 4 the full contents of the database is sent. In case 2 only the latest changes are sent.
場合1、3、および4では、データベースの完全なコンテンツを送ります。 場合2だけでは、最新の変化を送ります。
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.
データグラムの固有の非信頼性のために、承認を受けないことの場合、ベースのシステム、ともに掘っている要求、およびルーティング応答は承認、および「再-トランスミッション」を必要とします。
3. The Routing Database
3. ルート設定データベース
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. Certain events can cause these routes to time out.
WANで引き起こされた応答から学習されたエントリーは'永久的です'。 それらはそうしなければなりません。正常なすう勢のタイムアウトでない。 あるイベントはこれらのルートをタイムアウトに引き起こす場合があります。
Meyer & Sherry Standards Track [Page 5] RFC 2091 Trigger RIP January 1997
標準化過程[5ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年1月に裂かれます。
3.1 Presumption of Reachability
3.1 可到達性の推定
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
reachable through an internal circuit down message.
o 回路マネージャがルーティングデータグラムの常軌に次のホップルータに取引関係を築かないなら、それは、次のホップルータに内部の回路を通してメッセージの下側に届いていないようにルーティングアプリケーションに通知します。
The database entries are first marked as temporary and aged
normally; Some implementations may choose to omit this initial
aging step. The routing application then marks the appropriate
database entries as unreachable for a hold down period (the normal
120 second RIP hold down timer).
データベースエントリーは、最初に、一時的であるとしてマークされて、通常、熟成します。 いくつかの実装が、この初期の古いステップを省略するのを選ぶかもしれません。 そして、ルーティングアプリケーションは、手の届かないとしての抑制の期間、適切なデータベースエントリーが(第2RIPがタイマの下側に保つ正常な120)であるとマークします。
o If the circuit manager is subsequently able to establish a
connection to the next hop router, it will notify the routing
application that the next hop router is reachable through an
internal circuit up message.
o 回路マネージャが次に次のホップルータに取引関係を築くことができると、それは、次のホップルータに内部の回路を通してメッセージに届いているようにルーティングアプリケーションに通知するでしょう。
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.
そして、ルーティングアプリケーションは、最新情報でそれらのそれぞれのルーティングデータベースを再用意するために次のホップルータとメッセージを交換するでしょう。
The next hop router may also be marked as unreachable if an excessive number of retransmissions of an update go unacknowledged (see section 6.3).
また、アップデートの「再-トランスミッション」の過度の数が認められなくなるなら(セクション6.3を見てください)、次のホップルータは手の届かないとしてマークされるかもしれません。
Handling of circuit up and circuit down messages requires that the circuit manager takes responsibility for establishing (or re- establishing) 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 document.
回路とメッセージの下側への回路の取り扱いは、回路マネージャが手が届かなくなる次のホップルータの場合、接続を確立するのに(または、再設立)責任を取るのを必要とします。 このドキュメントの範囲の外に回路マネージャがこのタスクを実行するために採用するプロセスの記述があります。
3.2 Alternative Routes
3.2 代替のルート
A requirement of using Triggered RIP for propagating routing information is that NO routing information ever gets LOST or DISCARDED. This means that all alternative routes SHOULD be retained.
ルーティング情報を伝播するのにTriggered RIPを使用する要件はどんなルーティング情報もLOSTかDISCARDEDを手に入れないということです。 これは、すべての代替のルートSHOULDが保有されることを意味します。
It MAY be possible to operate with a sub-set of all alternative routes, but this adds complexity to the protocol - which is NOT covered in this document.
すべての代替のルートの部分集合で作動するのが可能であるかもしれませんが、これはプロトコル(本書ではカバーされていない)に複雑さを追加します。
Meyer & Sherry Standards Track [Page 6] RFC 2091 Trigger RIP January 1997
標準化過程[6ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年1月に裂かれます。
3.3 Split Horizon with Poisoned Reverse
3.3 当たっている逆がある分裂地平線
The rules for Split Horizon with Poisoned Reverse MUST be used to determine whether and/or how a route is advertised on an interface running this protocol.
広告を出してルートがこのプロトコルを実行しながらインタフェースにどのように広告を出されるかを決定するのにPoisoned ReverseとSplit Horizonのための規則を使用しなければなりません。
Split Horizon consists of omitting routes learned from a peer when sending updates back to that peer. With Poisoned Reverse instead of omitting those routes, they are advertised as unreachable (setting the metric to infinity).
分裂Horizonはその同輩にアップデートを送り返すとき同輩から学習されたルートを省略するのから成ります。 それらのルートを省略することの代わりにPoisoned Reverseと共に、手の届かないとしてそれらの広告を出します(メートル法を無限で設定して)。
A route is only poisoned if it is the best route (rather than an inferior alternative route) in the database.
ルートはそれがデータベースで最も良いルート(粗悪な代替のルートよりむしろ)である場合にだけ毒を入れられます。
Poison Reverse is necessary because a router may be advertising a route to a network to its partner and then later learn a better route for the same network from the partner. Without Poison Reverse the partner will not know to discard the inferior route learned from the first router.
毒Reverseはルータがネットワークにルートの広告を出しているかもしれないのでパートナーにとって必要であり、次に、後で同じネットワークのためにパートナーから、より良いルートを学びます。 Poison Reverseがなければ、パートナーは、最初のルータから学習された粗悪なルートを捨てるのを知らないでしょう。
3.4 Managing Routing Updates
3.4 ルート設定アップデートを管理すること。
The routing database SHOULD be considered to be a sequence of elements ordered by the time it was last updated. If there is a change in the best route (i.e. a new route is added or a route's metric has changed), the route is reordered and given a new highest sequence number.
データベースSHOULDを発送して、それをアップデートする時までに注文された要素の系列であると考えられてください。 (変化が最も良いルートにあればすなわち、新しいルートが加えられてルートのものであるメートル法、変化した、)、新しい最も高い一連番号にルートを再命令して、与えます。
Sending updates to a peer consists of running through the database from the oldest entry to the newest entry. Once an entry has been sent and acknowledged it is generally never resent. As new routing information arrives, only the new information is sent.
アップデートを同輩に送るのは最も古いエントリーから最も新しいエントリーまでデータベースについてざっと調べるのから成ります。 いったんエントリーを送って、承諾すると、一般に、それを決して再送しません。 新しいルーティング情報が到着するとき、新情報だけを送ります。
3.5 Retransmissions
3.5 Retransmissions
Handling retransmission of updates is simplest if updates are restricted to never having more than one un-acknowledged update outstanding - "one packet in flight". A copy of the update packet can be kept and retransmitted until acknowledged - and then subsequent update packets are sent in turn until the full database (to date) has been sent and acknowledged.
アップデートが未払いの1つ以上の不承認のアップデートを決して持っていないのに制限されるなら、アップデートの取り扱い「再-トランスミッション」は最も簡単です--「飛行での1つのパケット。」 承認されるまでアップデートパケットの写しを保って、再送できて、完全なデータベースが送られて、(これまで)承認されるまで、次に、順番にその後のアップデートパケットを送ります。
Meyer & Sherry Standards Track [Page 7] RFC 2091 Trigger RIP January 1997
標準化過程[7ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年1月に裂かれます。
Things become more complicated if several packets are sent in quick succession without waiting for an acknowledgements between packets - "several packets in flight":
間断なくパケットの間の承認を待たないでいくつかのパケットを送るなら、いろいろなことは、より複雑になります--、「飛行でのいくつかのパケット」:
o If packets arrive out of order they could corrupt the peer's
database. If the underlying datalink layer bundles several VCs,
it MUST guarantee to NOT reorder datagrams.
o パケットが故障していた状態で到着するなら、それらは同輩のデータベースを崩壊させるかもしれません。 基本的なデータリンク層が数個のVCsを添付するなら、それはどんな追加注文にもデータグラムを保証してはいけません。
o If the elements making up a packet requiring retransmission change
because of an alteration in the database, stale incorrect
information could be sent (again new information could overtake
old information).
o 「再-トランスミッション」を必要とするパケットを作る要素がデータベースにおける変更のために変化するなら、聞き古した不正確な情報を送るかもしれません(一方、新情報は旧情報に追いつくかもしれません)。
To guard against this when 'retransmitting' a packet when the database is in flux the packet MUST be re-created from the database to contain only the subset of routes which currently apply. And if none of the routes still apply, nothing will be 'retransmitted'.
データベースが流動的であるときに、パケットを'再送する'とき、これに用心するために、現在適用されるルートの部分集合だけを含むデータベースからパケットを作り直さなければなりません。 そして、ルートのいずれもまだ適用されていないと、何も'再送されないでしょう'。
For simplicity of implementation we would advise having only one packet in flight. However if the 'round trip' for a response and acknowledgement is quite long this could significantly delay large updates. See Appendix A for an understanding of the additional complexity of managing several packets in flight.
実装の簡単さのために、私たちは、飛行で1つのパケットしか持っていないようにアドバイスするでしょう。 'しかしながら、'応答と承認がこれをかなり切望することであるので、旅行は周囲で大きいアップデートをかなり遅らせることができます。 飛行でいくつかのパケットを管理する追加複雑さの理解に関してAppendix Aを見てください。
4. New Packet Types
4. 新しいパケットタイプ
To support triggered updates, three new packet types MUST be supported. For IP RIP Version 1 [1] and IP RIP Version 2 [2] these are identified by the Command Field values shown:
引き起こされたアップデートをサポートするために、3つの新しいパケットタイプをサポートしなければなりません。 IP RIPバージョン1[1]とIP RIPバージョン2[2]に関しては、これらは示されたCommand Field値によって特定されます:
o 9 - Update Request
o 9--更新要求
o 10 - Update Response
o 10--アップデート応答
o 11 - Update Acknowledge
o 11--アップデート、承認
For Netware RIP and SAP [3] the equivalent Field to distinguish between packet types is called Operation and these take the same values.
Netware RIPとSAP[3]の同等なFieldがパケットタイプを見分けるのはOperationと呼ばれます、そして、これらは同じ値を取ります。
These Command and Operation types require the addition of a 4 octet Update header. All three packet types contain a Version, which MUST be 1. Update Response and Update Acknowledge also have a Sequence Number and a Flush Flag.
これらのCommandとOperationタイプは4八重奏Updateヘッダーの追加を必要とします。 すべての3つのパケットタイプがバージョンを含んでいます。(それは、1であるに違いありません)。 また、アップデートResponseとUpdate Acknowledgeには、Sequence NumberとFlush Flagがあります。
Meyer & Sherry Standards Track [Page 8] RFC 2091 Trigger RIP January 1997
標準化過程[8ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年1月に裂かれます。
4.1 Update Request
4.1 更新要求
The Update Request has the Command/Operation value 9.
Update Requestには、Command/操作値9があります。
It is a request to the peer system to send ALL appropriate elements in its routing database. It is retransmitted at periodic intervals (every 5 seconds) until an Update Response message is received with the Flush flag set.
それはルーティングデータベースですべての適切な要素を送る同輩システムへの要求です。 それはFlush旗のセットでUpdate Responseメッセージを受け取るまで周期的な間隔(5秒毎)で、再送されます。
An Update Request is transmitted in the following circumstances:
Update Requestは下記の事情の中で伝えられます:
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 and changes to a reachable
(circuit up) state.
o 回路マネージャが第二にいつ目的地を示すかは、手の届かない(回路が下にある状態で)状態にあって、届いている(回路が上にある状態で)状態に変化します。
An Update Request may also be sent at other times to compensate for discarding non-optimal routing information or if an Update Response continues to be unacknowledged (see section 6.3).
また、捨てている非最適ルーティング情報かそれともUpdate Responseがずっと認められないかどうかを(セクション6.3を見てください)代償する他の時にUpdate Requestを送るかもしれません。
4.2 Update Response
4.2 アップデート応答
The Update Response has the Command/Operation value 10.
Update Responseには、Command/操作値10があります。
It is a message containing zero or more routes in an update. It is retransmitted at periodic intervals until an Update Acknowledge is received.
それはゼロを含むメッセージであるか以上がアップデートでルートです。 Update Acknowledgeが受け取られているまで、それは周期的な間隔で、再送されます。
An Update Response message MUST be sent:
Update Responseメッセージを送らなければなりません:
o In response to an Update Request. The Update Response MUST have
the Flush flag set. Other Update Responses should NOT be sent
until an Update Acknowledge has been received acknowledging the
Flush flag.
o Update Requestに対応して。 Update ResponseはFlush旗を設定させなければなりません。 Flush旗を承認しながらUpdate Acknowledgeを受け取るまで他のUpdate Responsesを送るべきではありません。
The remainder of the database MUST then be sent as a series of
Update Responses with the Flush flag NOT set.
そして、Flush旗がセットしていなく、一連のUpdate Responsesとしてデータベースの残りを送らなければなりません。
o An Update Response with the Flush flag set MUST also be sent at
power on to flush the peer's routing table learned from a previous
incarnation. This Update Response SHOULD NOT contain any routes.
This avoids any possibility of an acknowledgement being received
to a response sent BEFORE the unit was restarted causing confusion
about which routes are being acknowledged.
o また、前の肉体化から学習された同輩の経路指定テーブルを洗い流すためにオンなパワーでFlush旗のセットがあるUpdate Responseを送らなければなりません。 このUpdate Response SHOULDはどんなルートも含んでいません。 これはBEFOREを送って、応答に受け取って、ユニットがルートが承認されている混乱を引き起こしながら再開されたという承認のどんな可能性も避けます。
Update Response messages continue to be sent any time there is fresh routing information to be propagated.
アップデートResponseメッセージは、伝播されるために新鮮なルーティング情報がある何時でも送られ続けています。
Meyer & Sherry Standards Track [Page 9] RFC 2091 Trigger RIP January 1997
標準化過程[9ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年1月に裂かれます。
Each new Update Response is given a different Sequence Number. The Sequence Number only has 'meaning' to the sender of the Update Response. The same Update Response sent to different peers MAY have a different Sequence Number.
それぞれの新しいUpdate Responseに異なったSequence Numberを与えます。 Sequence Numberは'意味'をUpdate Responseの送付者に持っているだけです。 異なった同輩に送られた同じUpdate Responseは異なったSequence Numberを持っているかもしれません。
An Update Response packet with the Flush flag set MUST be sent to a peer:
Flush旗のセットがあるUpdate Responseパケットを同輩に送らなければなりません:
o At power on.
o パワーでは、オンです。
o In response to an Update Request packet.
o Update Requestパケットに対応して。
o After transitioning from a circuit down to a circuit up state.
o 回路から移行した後に、状態に回路にダウンしてください。
After sending an Update Flush, the full database MUST be sent subsequently.
Update Flushを送った後に、次に、完全なデータベースを送らなければなりません。
4.3 Update Acknowledge
アップデートが承認する4.3
The Update Acknowledge has the Command/Operation value 11.
Update Acknowledgeには、Command/操作値11があります。
It is a message sent in response to every Update Response packet received. If the Update Response packet has the flush flag set then so should the Update Acknowledge packet.
それは受け取られたあらゆるUpdate Responseパケットに対応して送られたメッセージです。 Update Responseパケットで豊富な旗を設定するなら、Update Acknowledgeパケットもそうするべきです。
5. Packet Formats
5. パケット・フォーマット
5.1 Update Header
5.1 アップデートヘッダー
To support the mechanism outlined in this proposal the packet format for RIP Version 1 [1], RIP Version 2 [2] and Netware RIP and SAP [3] are modified to include an additional small header when using Commands Update Request (9), Update Response (10) and Update Acknowledge (11). Commands are called Operations in Netware.
RIPバージョンの1[1]、RIPバージョン2[2]、およびNetware RIPのためのパケット・フォーマットとSAP[3]がCommands Update Request(9)、Update Response(10)、およびUpdate Acknowledge(11)を使用するとき、追加小さいヘッダーを含むように変更されるというこの提案に概説されたメカニズムをサポートするために。 コマンドはNetwareにOperationsと呼ばれます。
Update Request (9):
要求(9)をアップデートしてください:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (1) | must be zero (3) |
+-------------------------------+-------------------------------+
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)| ゼロが(3)であったならそうしなければなりません。| +-------------------------------+-------------------------------+
Meyer & Sherry Standards Track [Page 10] RFC 2091 Trigger RIP January 1997
標準化過程[10ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年1月に裂かれます。
Update Response (10) and Update Acknowledge (11):
アップデート応答(10)とアップデートは(11)を承認します:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version (1) | Flush (1) | Sequence Number (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)| +-------------------------------+-------------------------------+
Four octet Update headers, with each tick mark representing one
bit. All fields are coded in network byte order (big-endian).
各ダニ麻痺が1ビットを表している4個の八重奏Updateヘッダー。 すべての分野がネットワークバイトオーダー(ビッグエンディアン)でコード化されます。
Figure 2. Update Headers.
図2。 ヘッダーをアップデートしてください。
Version MUST be 1 in all headers. Any packets received for a different Version MUST be silently discarded.
バージョンはすべてのヘッダーの1であるに違いありません。 静かに異なったバージョンのために受け取られたどんなパケットも捨てなければなりません。
The Sequence Number MUST be incremented every time a new Update Response packet is sent on the WAN. The Sequence Number is unchanged for retransmissions. The Sequence Number wraps round at 65535.
WANで新しいUpdate Responseパケットを送るときはいつも、Sequence Numberを増加しなければなりません。 「再-トランスミッション」に、Sequence Numberは変わりがありません。 Sequence Numberは65535でラウンドを包装します。
Flush is set to 1 in an Update Response if the peer is required to start timing out its entries - otherwise it is set to zero. Any other values MUST be silently discarded.
同輩が、エントリーから調節するのを出発しなければならないなら、水洗はUpdate Responseの1に設定されます--さもなければ、それはゼロに設定されます。 静かにいかなる他の値も捨てなければなりません。
The peer returns an Update Acknowledge containing the same Sequence Number and Flush.
同輩は同じSequence NumberとFlushを含むUpdate Acknowledgeを返します。
5.2 IP Routing Information Protocol Version 1
5.2 IPルーティング情報プロトコルバージョン1
IP RIP [1] is a UDP-based protocol which generally sends and receives datagrams on UDP port number 520.
IP RIP[1]は一般に、UDPポートNo.520でデータグラムを送って、受けるUDPベースのプロトコルです。
To support the mechanism outlined in this proposal the packet format for RIP Version 1 [1] is modified when using Commands Update Request (9), Update Response (10) and Update Acknowledge (11). See Figure 3.
Commands Update Request(9)、Update Response(10)、およびUpdate Acknowledge(11)を使用するとき、パケットがRIPバージョンのためにフォーマットするこの提案に概説されたメカニズムをサポートするために、1[1]が変更されています。 図3を参照してください。
5.3 IP Routing Information Protocol Version 2
5.3 IPルーティング情報プロトコルバージョン2
IP RIP Version 2 [2] is an enhancement to IP RIP Version 1 which allows RIP updates to include subnetting information.
IP RIPバージョン2[2]はRIPアップデートがサブネッティング情報を含むことができるIP RIPバージョン1への増進です。
To support the mechanism outlined in this proposal the packet format for RIP Version 2 [2] is modified when using Commands Update Request (9), Update Response (10) and Update Acknowledge (11). See Figure 4.
Commands Update Request(9)、Update Response(10)、およびUpdate Acknowledge(11)を使用するとき、パケットがRIPバージョンのためにフォーマットするこの提案に概説されたメカニズムをサポートするために、2[2]は変更されています。 図4を参照してください。
Meyer & Sherry Standards Track [Page 11] RFC 2091 Trigger RIP January 1997
標準化過程[11ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年1月に裂かれます。
5.4 Netware Routing Information Protocol
5.4 ネットウェアルーティング情報プロトコル
Netware [3] 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.
ネットウェア[3]はインターネットワークに関するルータがソケット番号453hを使用することでInternetwork Packet Exchange(IPX)プロトコルをひくルーティング情報プロトコル(RIP)を使用することでルーティング情報を交換できるメカニズムをサポートします。
To support the mechanism outlined in this proposal the packet format for Novell RIP [3] is modified when using Operations Update Request (9), Update Response (10) and Update Acknowledge (11). See Figure 5.
Operations Update Request(9)、Update Response(10)、およびUpdate Acknowledge(11)を使用するとき、この提案に概説されたメカニズムをサポートするために、ノベルRIP[3]のためのパケット・フォーマットは変更されています。 図5を参照してください。
5.5 Netware Service Advertising Protocol
5.5 ネットウェアサービス通知プロトコル
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. 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.
また、ネットウェア[3]は名前の彼らのサービスの広告を出して、ソケット番号452hを使用することでInternetwork Packet Exchange(IPX)プロトコルをひくサービス通知プロトコル(SAP)を使用することでタイプするためにインターネットワークにサーバを許容するメカニズムをサポートします。 SAPは実行しているRIPとして同様の主体を運用します。 ルータは、異なったネットワークからサービス情報を集めて、SAPのエージェントとして務めて、利害関係者にそれをリレーします。
To support the mechanism outlined in this proposal the packet format for Novell SAP [3] is modified when using Operations Update Request (9), Update Response (10) and Update Acknowledge (11). See Figure 6.
Operations Update Request(9)、Update Response(10)、およびUpdate Acknowledge(11)を使用するとき、この提案に概説されたメカニズムをサポートするために、ノベルSAP[3]のためのパケット・フォーマットは変更されています。 図6を参照してください。
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) | RIP 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)であったならそうしなければなりません。| +---------------+---------------+-------------------------------+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Header (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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アップデートヘッダー(4)| +-------------------------------+-------------------------------+
Meyer & Sherry Standards Track [Page 12] RFC 2091 Trigger RIP January 1997
標準化過程[12ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年1月に裂かれます。
Update Response then has up to 25 routing entries (each 20 octets):
次に、アップデートResponseには、最大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 coded in network byte order
(big-endian).
各ダニ麻痺が1ビットを表している八重奏における、IP RIPデータグラムの形式。 すべての分野がネットワークバイトオーダー(ビッグエンディアン)でコード化されます。
The four octets of the Update header are included in Update Request
(Command 9), Update Response (10) and Update Acknowledge (11)
packets. They are not present in packet types in the original RIP
Version 1 specification.
Updateヘッダーの4つの八重奏がUpdate Request(コマンド9)、Update Response(10)、およびUpdate Acknowledge(11)パケットに含まれています。 それらはオリジナルのRIPバージョン1仕様によるパケットタイプで存在していません。
Figure 3. IP RIP Version 1 packet format
図3。 IP RIPバージョン1パケット・フォーマット
Meyer & Sherry Standards Track [Page 13] RFC 2091 Trigger RIP January 1997
標準化過程[13ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Command (1) |RIP 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)であったならそうしなければなりません。| +---------------+---------------+-------------------------------+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Header (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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アップデートヘッダー(4)| +-------------------------------+-------------------------------+
Update Response then has up to 25 routing entries (each 20 octets):
次に、アップデートResponseには、最大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) | Route Tag (2) |
+-------------------------------+-------------------------------+
| IP address (4) |
+---------------------------------------------------------------+
| Subnet Mask (4) |
+---------------------------------------------------------------+
| Next Hop (4) - must be zero |
+---------------------------------------------------------------+
| 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)| +---------------------------------------------------------------+ | 次のHop(4)--ゼロでなければなりません。| +---------------------------------------------------------------+ | メートル法の(4)| +---------------------------------------------------------------+ . .
The format of an IP RIP Version 2 datagram in octets, with each
tick mark representing one bit. All fields are coded in network
byte order (big-endian).
各ダニ麻痺が1ビットを表している八重奏における、IP RIPバージョン2データグラムの形式。 すべての分野がネットワークバイトオーダー(ビッグエンディアン)でコード化されます。
The four octets of the Update header are included in Update Request
(Command 9), Update Response (10) and Update Acknowledge (11)
Packets. They are not present in packet types in the original RIP
Version 2 specification.
Updateヘッダーの4つの八重奏がUpdate Request(コマンド9)、Update Response(10)、およびUpdate Acknowledge(11)パケットに含まれています。 それらはオリジナルのRIPバージョン2仕様によるパケットタイプで存在していません。
Next Hop MUST be zero, since Triggered RIP can NOT advertise routes
on behalf of other WAN routers.
Triggered RIPが他のWANルータを代表してルートの広告を出すことができないので、次のHopはゼロであるに違いありません。
If authentication is used it immediately follows the Update header.
認証が使用されているなら、それはすぐに、Updateヘッダーに続きます。
Figure 4. IP RIP Version 2 packet format
図4。 IP RIPバージョン2パケット・フォーマット
Meyer & Sherry Standards Track [Page 14] RFC 2091 Trigger RIP January 1997
標準化過程[14ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年1月に裂かれます。
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)| +---------------+---------------+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Header (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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アップデートヘッダー(4)| +-------------------------------+-------------------------------+
Update Response then has up to 50 routing entries (each 8 octets):
次に、アップデートResponseには、最大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 coded in network byte order
(big-endian).
各ダニ麻痺が1ビットを表している八重奏における、Netware RIPデータグラムの形式。 すべての分野がネットワークバイトオーダー(ビッグエンディアン)でコード化されます。
The four octets of the Update header are included in Update Request
(Operation 9), Update Response (10) and Update Acknowledge (11)
packets. They are not present in packet types in the original
Novell RIP specification.
Updateヘッダーの4つの八重奏がUpdate Request(操作9)、Update Response(10)、およびUpdate Acknowledge(11)パケットに含まれています。 それらは当初のノベルRIP仕様によるパケットタイプで存在していません。
Figure 5. Netware RIP packet format
図5。 ネットウェアRIPパケット・フォーマット
Meyer & Sherry Standards Track [Page 15] RFC 2091 Trigger RIP January 1997
標準化過程[15ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年1月に裂かれます。
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)| +---------------+---------------+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Update Header (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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アップデートヘッダー(4)| +-------------------------------+-------------------------------+
Update Response then has up to 8 service entries (each 64 octets):
次に、アップデートResponseには、最大8つのサービスエントリー(各64の八重奏)があります:
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 (2) | |
+-------------------------------+ |
| Service Name (48) |
| . |
.
. +-------------------------------+
| . | Network Address (4) |
+-------------------------------+-------------------------------+
| Network Address (cont) | |
+-------------------------------+ |
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サービスタイプ(2)| | +-------------------------------+ | | サービス名(48)| | . | . . +-------------------------------+ | . | ネットワーク・アドレス(4)| +-------------------------------+-------------------------------+ | ネットワーク・アドレス(cont)| | +-------------------------------+ | | ノードアドレス(6)| +-------------------------------+-------------------------------+ | ソケットアドレス(2)| サーバ(2)へのホップス| +-------------------------------+-------------------------------+ . .
The format of a Netware SAP datagram in octets, with each tick mark
representing one bit. All fields are coded in network byte order
(big-endian).
各ダニ麻痺が1ビットを表している八重奏における、Netware SAPデータグラムの形式。 すべての分野がネットワークバイトオーダー(ビッグエンディアン)でコード化されます。
The four octets of the Update header are included in Update Request
(Operation 9), Update Response (10) and Update Acknowledge (11)
packets. They are not present in packet types in the original
Novell SAP specification.
Updateヘッダーの4つの八重奏がUpdate Request(操作9)、Update Response(10)、およびUpdate Acknowledge(11)パケットに含まれています。 それらは当初のノベルSAP仕様によるパケットタイプで存在していません。
Figure 6. Netware SAP packet format
図6。 ネットウェアSAPパケット・フォーマット
Meyer & Sherry Standards Track [Page 16] RFC 2091 Trigger RIP January 1997
標準化過程[16ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年1月に裂かれます。
6. Timers
6. タイマ
Three timers are supported to handle the triggered update mechanism:
3個のタイマが引き起こされたアップデートメカニズムを扱うために支えられます:
o Database timer.
o データベースタイマ。
o Hold down timer.
o タイマを押さえてください。
o Retransmission timer.
o 再送信タイマー。
An optional over-subscription timer MAY also be supported.
また、任意の過剰購読タイマは支えられるかもしれません。
6.1 Database Timer
6.1 データベースタイマ
Routes learned by an Update Response are normally considered to be permanent.
通常、Update Responseによって学習されたルートが永久的であると考えられます。
When an Update Response with the Flush flag set is received, 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).
Flush旗のセットがあるUpdate Responseが受け取られているとき、すべてのルートが、それからまるでそれらが(まさしく)従来のResponse(コマンド2)から学習されたかのように次のホップルータがタイミングを始めるべきであることを学びました。
Namely each route exists while the database entry timer (usually 180 seconds) 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.
すなわち、各ルートはデータベースエントリータイマ(通常180秒)が動いている間、存在していて、まるでまだ存在しているかのように他のインタフェースに広告を出します。 一層の抑制タイマは期限が切れることができますが、そして、手の届かないとしてルートの広告を出します。
6.2 Hold down Timer
6.2 抑制タイマ
A hold down timer of 120 seconds is started on a route:
120秒の抑制タイマはルートを始動します:
o When the database timer for the route expires.
o ルートへのデータベースタイマが期限が切れると。
o When a formerly reachable route changes to unreachable in an
incoming response.
o 以前届いているルートが入って来る応答で手の届かなく変化すると。
o When a circuit down is received from the circuit manager.
o 回路であるときに、回路マネージャから下にを受け取ります。
While the hold down timer is running routes are advertised as unreachable on other interfaces.
抑制タイマが動いている間、他のインタフェースで手の届かないとしてルートの広告を出します。
When the hold down timer expires the route MAY be deleted from the database PROVIDING its unreachability has been successfully propagated to all WAN destinations, or the remaining WAN destinations are in a circuit down state. If a route can not be deleted when the hold-down timer expires, it MAY subsequently be deleted when each and every peer is either up-to-date or is in a circuit down state.
タイマの下側への保持が期限が切れると、ルートはデータベースPROVIDINGから削除されて、「非-可到達性」が首尾よくすべてのWANの目的地に伝播されたということであるかもしれませんか残っているWANの目的地が回路下に州にあります。 ありとあらゆる同輩が最新であるか、または回路下に州にいるとき、抑制タイマが期限が切れるとき、ルートを削除できないなら、それは次に、削除されるかもしれません。
Meyer & Sherry Standards Track [Page 17] RFC 2091 Trigger RIP January 1997
標準化過程[17ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年1月に裂かれます。
If the hold down timer is already running it is NOT reset by any events which would start the hold down timer.
タイマの下側への保持が既に稼働しているなら、それはタイマで保持を始めるどんなイベントによってもリセットされません。
6.3 Retransmission Timer
6.3 再送信タイマー
The routing task runs a retransmission timer:
ルーティングタスクは再送信タイマーを動かします:
o An Update Request packet is retransmitted periodically until an
Update Flush packet is received. An Update Flush packet is an
Update Response packet with the Flush field set. It need not
contain routes.
o Update Flushパケットが受け取られているまで、Update Requestパケットは定期的に再送されます。 Update FlushパケットはFlush分野セットがあるUpdate Responseパケットです。 それはルートを含む必要はありません。
o An Update Response packet is retransmitted periodically until an
Update Acknowledge packet is received containing the same Sequence
Number.
o Update Acknowledgeパケットが同じSequence Numberを含むのにおいて受け取られているまで、Update Responseパケットは定期的に再送されます。
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秒の値が適切であるということである時間をセットアップしてください。
To prevent against failures in the circuit manager a limit SHOULD be placed on the number of retransmissions. If no response has been received after a configurable length of time (say 180 seconds) routes via the next hop router are marked as unreachable, the hold down timer is started and the entry is advertised as unreachable on other interfaces.
回路マネージャで失敗に対して限界SHOULDを防ぐには、「再-トランスミッション」の数に置かれてください。 手の届かないとして次のホップルータを通した構成可能な長さの時間(180秒言う)ルートをマークした後に応答を全く受けていないなら、タイマの下側への保持を始めます、そして、他のインタフェースで手の届かないとしてエントリーの広告を出します。
The next hop router may then be polled with Update Requests at a reduced frequency. A suitable poll interval would be of the order of minutes rather than seconds. Alternatively an Update Request could be initiated by administrative action. When a response is received the routers should perform a complete exchange of routing information.
そして、次のホップルータはUpdate Requestsと共に換算周波数で投票されるかもしれません。 適当な投票間隔は秒よりむしろ数分の注文のものでしょう。 管理動作であるいはまたUpdate Requestを開始できるでしょう。 応答が受け取られているとき、ルータはルーティング情報の完全交換を実行するべきです。
6.4 Over-subscription Timer
6.4 過剰購読タイマ
Over-subscription is where there are more next hop routers to send updates to on the WAN than there are channels. For example 3 next hop routers accessed by an ISDN Basic Rate Interface (BRI) which can only support 2 calls simultaneously.
過剰購読はチャンネルがあるよりWANのアップデートを送るために次のさらに多くのホップルータがあるところです。 例えば2しかサポートすることができないISDN Basic Rate Interface(BRI)からルータがアクセスした次の3ホップは同時に、呼びます。
To avoid route oscillation routes may NOT be marked unreachable immediately on receiving a circuit down message from the circuit manager. A timeout MAY be used to delay marking the routes unreachable for sufficiently long to allow the calls to 'time division multiplex' over the available channels. A timeout as long as the regular 180 second RIP route timeout MAY be suitable. In general the greater the over-subscription, the longer the time out should be.
ルート振動ルートを避けるのはすぐ回路マネージャから回路下にメッセージを受け取るとき手が届かないとマークされないかもしれません。 タイムアウトは、利用可能なチャンネルの上に'時分割多重'に呼び出しを許すためにルートが十分長い間手が届かないとマークするのを遅らせるのに使用されるかもしれません。 RIPがタイムアウトを発送する通常の180秒としての長い同じくらいタイムアウトは適当であるかもしれません。 一般に、過剰購読が大きければ大きいほど、タイムアウトは、より長いはずです。
Meyer & Sherry Standards Track [Page 18] RFC 2091 Trigger RIP January 1997
標準化過程[18ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年1月に裂かれます。
Implementations wishing to support over-subscription may implement the delay within the circuit manager or within the routing application.
過剰購読をサポートしたがっている実装は回路マネージャ以内かルーティングアプリケーションの中で遅れを実装するかもしれません。
If the delay is implemented within the routing application the routing entries MUST NOT start timing out during the delay. This allows the circuit up message to be ignored if the timeout after receiving the circuit down has still to expire. This avoids any confusion if the peer had previously issued a Route Flush command and was part way through an update.
遅れがルーティングアプリケーションの中で実装されるなら、ルーティングエントリーは遅れの間、タイミングを始めてはいけません。 これは下にがまだ吐き出さなければならない回路を受けた後のタイムアウトであるなら無視されるべきメッセージに回路を許容します。 同輩が以前に、Route Flushコマンドを発行して、部分的にアップデートでいたなら、これはどんな混乱も避けます。
7. Security Considerations
7. セキュリティ問題
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. The circuit manager SHOULD only allow incoming calls to be accepted from the same well defined list of routers.
物理アドレスのリストは、次のホップルータに呼び出しを確立するのを可能にするために回路マネージャは提供されなければなりません。 回路マネージャSHOULDはルータの同じよく定義されたリストから受け入れられるというかかってきた電話を許容するだけです。
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つのアドレスの間には、アルゴリズムの変換がある場合にあるかもしれません。
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.
WANで送られる引き起こされたアップデートがことである論理アドレスのリストをルーティング(または、サービス広告)タスクに提供しなければなりません。 リストは回路マネージャによって維持された次のホップルータのリストの部分集合であるかもしれません。
RIP Version 2 also allows further authentication of Triggered RIP packets.
また、RIPバージョン2はTriggered RIPパケットのさらなる認証を許します。
Meyer & Sherry Standards Track [Page 19] RFC 2091 Trigger RIP January 1997
標準化過程[19ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年1月に裂かれます。
Appendix A - Implementation Suggestion
付録A--実装提案
This section suggests how the database might be structured to handle Triggered RIP.
このセクションはデータベースがTriggered RIPを扱うためにどう構造化されるかもしれないかを示します。
Each entry in the database is given a unique route number. Every time a best route to a network changes, a global route number is incremented and the changed route is given the new route number. Note that this route number is completely internal to the router and has no bearing on the Sequence Number sent in Update Responses sent to the peer.
ユニークな路線番号を各データベースへの登録に与えます。 ネットワークへの最も良いルートが変化するときはいつも、グローバルな路線番号は増加しています、そして、新しい路線番号を変えられたルートに与えます。 この路線番号がルータに完全に内部であり、同輩に送られたUpdate Responsesで送られたSequence Numberに堪えないことを持っていることに注意してください。
The route number size should be large enough so as not to wrap round - or the routes can be renumbered before it becomes a problem. Re- numbering requires that the database environment is stable (No Update Responses are queued awaiting Acknowledgement)
路線番号サイズがラウンドを包装しないように十分大きいはずですか、または問題になる前にルートの番号を付け替えられることができます。 再付番は、データベース環境が安定しているのを必要とします。(Update Responsesは全くAcknowledgementを待ちながら、列に並ばせられません)
Is is probably easier to manage the routes if they are also chained together using a pointer to a later (and possibly also a pointer to an earlier) entry which reflect the route number/age.
また、それらが後でaに指針を使用することで一緒にチェーニングされるならルートを管理するのがたぶんより簡単である、(ことによるとまた、指針、 より早い) 路線番号/時代を反映するエントリー。
Performing a complete update then consists of running though the routes from the oldest to the latest and sending them out in Update Responses. Subsequent changes to the database are treated as sending out only the changed entries (from the previous latest to the new latest).
その時完全なアップデートを実行するのはもっとも、最も古いのから最新のものまでルートを動かして、Update Responsesでそれらを出すのから成ります。 データベースへのその後の変化は変えられたエントリー(前の最新のものから新しい最新のものまでの)だけを出すとして扱われます。
When allowing for several packets in flight care must be taken with retransmissions. An Update Response 'retransmission' MAY be different from the original. When transmitting a sequence of Update Responses each Response packet contains a number of routes which is a represented by a series of routes with consecutive route numbers. Consider sending three Update Responses with Sequence numbers 10,11 and 12 each containing 10 routes:
飛行でいくつかのパケットを考慮するとき、「再-トランスミッション」で注意しなければなりません。 Update Response'「再-トランスミッション」'はオリジナルと異なっているかもしれません。 Update Responsesの系列を伝えるとき、それぞれのResponseパケットは連続した路線番号で一連のルートで表されたaである多くのルートを含んでいます。 それぞれ10のルートを含むSequence No.10、11、および12と共に3Update Responsesを送ると考えてください:
Sequence Number Routes represented by Route Numbers
Route民数記によって表された系列Number Routes
10 101, 102, 103, 104, 105, 106, 107, 108, 109, 110
10 101, 102, 103, 104, 105, 106, 107, 108, 109, 110
11 111, 112, 113, 114, 115, 116, 117, 118, 119, 120
11 111, 112, 113, 114, 115, 116, 117, 118, 119, 120
12 121, 122, 123, 124, 125, 126, 127, 128, 129, 130
12 121, 122, 123, 124, 125, 126, 127, 128, 129, 130
Meyer & Sherry Standards Track [Page 20] RFC 2091 Trigger RIP January 1997
標準化過程[20ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年1月に裂かれます。
If these Update Responses are NOT acknowledged, but in the meantime the routing database has changed and the routes represented by route numbers 104, 112 - 116 and 127 have changed and been assigned new route numbers 131 - 137, the retransmission will look like:
これらのUpdate Responsesが承認されませんが、差し当たり、ルーティングデータベースが変化していて、116と104、112--127が変えた路線番号によって表されて、131--137、「再-トランスミッション」がそうする新しい路線番号が割り当てられたルートに似ているなら:
Sequence Number Routes represented by Route Numbers
Route民数記によって表された系列Number Routes
10 101, 102, 103, 105, 106, 107, 108, 109, 110
10 101, 102, 103, 105, 106, 107, 108, 109, 110
11 111, 117, 118, 119, 120
11 111, 117, 118, 119, 120
12 121, 122, 123, 124, 125, 126, 128, 129, 130
12 121, 122, 123, 124, 125, 126, 128, 129, 130
13 131, 132, 133, 134, 135, 136, 137
13 131, 132, 133, 134, 135, 136, 137
To perform a retransmission it is VERY IMPORTANT that the
retransmission contains only the SUB-SET of route numbers which
currently apply. If there are NO suitable routes to send, it is not
necessary to send an empty retransmission.
「再-トランスミッション」を実行するために、「再-トランスミッション」が現在適用される路線番号のSUB-SETだけを含んでいるのは、VERY IMPORTANTです。 送るどんな適当なルートもなければ、空の「再-トランスミッション」を送るのは必要ではありません。
An alternative 'retransmission' strategy is to always use different sequence numbers when resending updates. Consider transmitting packets with sequence numbers 10 through 20 - and responses are received from all packets except those with sequence numbers 14 and 17. In this case only the data in packets 10 through 13 can be considered to be acknowledged. The data from packet 14 onwards MUST be re-sent and given new sequence numbers starting at 21.
代替の'「再-トランスミッション」'戦略はアップデートを再送するとき、いつも異なった一連番号を使用することです。 一連番号で10〜20にパケットを伝えて、応答がそれら以外のすべてのパケットから一連番号14と17で受けられると考えてください。 この場合、パケット10〜13のデータだけが承認されると考えることができます。 パケット14からのデータは前方へそうであるに違いありません。21時に始まる新しい一連番号を、憤慨して、与えます。
References
参照
[1] Hedrick. C., "Routing Information Protocol", RFC 1058, Rutgers
University, June 1988.
[1] ヘドリック。 C. RFC1058、ラトガース大学、「情報プロトコルを発送すること」での1988年6月。
[2] Malkin. G., "RIP Version 2 - Carrying Additional Information",
RFC 1723, Xylogics, November 1994.
[2] マルキン。 G.、「追加情報を運んで、バージョン2をコピーしてください」、RFC1723、Xylogics、11月1994日
[3] Novell Incorporated., "IPX Router Specification", Version 1.20,
October 1993.
[3] ノベルが法人組織にした、「IPXルータ仕様」、バージョン1.20、10月1993
[4] Meyer. G., "Extensions to RIP to Support Demand Circuits",
Spider Systems, February 1994.
[4] マイヤー。 G.、「要求が回路であるとサポートするために裂く拡大」、クモのシステム、1994年2月。
Meyer & Sherry Standards Track [Page 21] RFC 2091 Trigger RIP January 1997
標準化過程[21ページ]RFC2091が引き金となるマイヤーとシェリー酒は1997年1月に裂かれます。
Authors' Address:
作者のアドレス:
Gerry Meyer Shiva Stanwell Street Edinburgh EH6 5NG Scotland, UK
ゲリー・マイヤー・シバ神Stanwell通りエディンバラEH6 5NGスコットランド、イギリス
Phone: (UK) 131 554 9424 Fax: (UK) 131 467 7749 Email: gerry@europe.shiva.com
以下に電話をしてください。 (イギリス) 131 554、9424Fax: (イギリス) 7749年の131 467メール: gerry@europe.shiva.com
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
Meyer & Sherry Standards Track [Page 22]
マイヤーとシェリー酒の標準化過程[22ページ]
一覧
スポンサーリンク
