RFC975 日本語訳
0975 Autonomous confederations. D.L. Mills. February 1986. (Format: TXT=28010 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group D. L. Mills
Request for Comments: 975 M/A-COM Linkabit
February 1986
L.工場がコメントのために要求するワーキンググループD.をネットワークでつないでください: 1986年2月の1COM Linkabitの975M/
Autonomous Confederations
自動同盟者
Status of This Memo
このメモの状態
This RFC proposes certain enhancements of the Exterior Gateway Protocol (EGP) to support a simple, multiple-level routing capability while preserving the robustness features of the current EGP model. It requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このRFCは、現在のEGPモデルの丈夫さ機能を保存している間、簡単で、複数のレベルのルーティング能力を支持するためにExteriorゲートウェイプロトコル(EGP)のある増進を提案します。 それは改良のための議論と提案を要求します。 このメモの分配は無制限です。
Overview
概観
The enhancements, which do not require retrofits in existing implementations in order to interoperate with enhanced implementations, in effect generalize the concept of core system to include multiple communities of autonomous systems, called autonomous confederations. Autonomous confederations maintain a higher degree of mutual trust than that assumed between autonomous systems in general, including reasonable protection against routing loops between the member systems, but allow the routing restrictions of the current EGP model to be relaxed.
自動同盟者は、事実上、増進(高められた実現で共同利用するために既存の実現における改装を必要としない)が自律システムの複数の共同体を含むようにコア・システムの概念を広めると呼びました。 自動同盟者は一般に、自律システムの間で想定されたそれより高度の信頼関係を維持します、メンバーシステムの間のルーティング輪に対する合理的な保護を含んでいて現在のEGPモデルのルーティング規制が緩和されるのを許容して。
The enhancements involve the "hop count" or distance field of the EGP Update message, the interpretation of which is not covered by the current EGP model. This field is given a special interpretation within each autonomous confederation to support up to three levels of routing, one within the autonomous system, a second within the autonomous confederation and an optional third within the universe of confederations.
増進はEGP Updateメッセージの「ホップカウント」か距離分野にかかわります。その解釈は現在のEGPモデルでカバーされていません。 同盟者の宇宙の中で最大3つのレベルのルーティング、自律システムの中の1、自動同盟者の中の1秒、および任意の3分の1を支持するためにそれぞれの自動同盟者の中でこの分野に特別な解釈をします。
1. Introduction and Background
1. 序論とバックグラウンド
The historical development of Internet exterior-gateway routing algorithms began with a rather rigid and restricted topological model which emphasized robustness and stability at the expense of routing dynamics and flexibility. Evolution of robust and dynamic routing algorithms has since proved extraordinarily difficult, probably due more to varying perceptions of service requirements than to engineering problems.
インターネット外のゲートウェイルーティング・アルゴリズムの歴史的な開発はルーティング力学と柔軟性を犠牲にして丈夫さと安定性を強調したかなり堅くて制限された位相モデルと共に始まりました。 強健、そして、ダイナミックルーティングアルゴリズムの発展は以来異常に難しいと判明しています、たぶん工学の問題よりサービス要件の異なった認知に当然です。
The original exterior-gateway model suggested in RFC-827 [1] and subsequently refined in RFC-888 [2] severely restricted the Internet topology essentially to a tree structure with root represented by the BBN-developed "core" gateway system. The most important characteristic of the model was that debilitating resource-consuming routing loops between clusters of gateways (called autonomous
RFC-827[1]に示されて、次にRFC-888で[2] 厳しく洗練されたオリジナルの外のゲートウェイモデルはインターネットトポロジーを本質的には根がBBNによって開発された「コア」ゲートウェイシステムによって表されている木構造に制限しました。 モデルの最も重要な特性が弱らせるリソースを消費するルーティングがゲートウェイのクラスタの間で輪にされるということであった、(自治であると呼ばれます。
Mills [Page 1]
工場[1ページ]
RFC 975 February 1986 Autonomous Confederations
RFC975 1986年2月自動同盟者
systems) could not occur in a tree-structured topology. However, the administrative and enforcement difficulties involved, not to mention the performance liabilities, made widespread implementation impractical.
システム) 木で構造化されたトポロジーに起こることができませんでした。 しかしながら、性能負債は言うまでもなくかかわる管理と実施困難で、広範囲の実現は非実用的になりました。
1.1. The Exterior Gateway Protocol
1.1. 外のゲートウェイプロトコル
Requirements for near-term interoperability between the BBN core
gateways and the remainder of the gateway population implemented
by other organizations required that an interim protocol be
developed with the capability of exchanging reachability
information, but not necessarily the capability to function as a
true routing algorithm. This protocol is called the Exterior
Gateway Protocol (EGP) and is documented in RFC-904 [3].
BBNコアゲートウェイの間の短期間相互運用性のための要件と他の組織によって実行されたゲートウェイ人口の残りは、当座のプロトコルが本当のルーティング・アルゴリズムとして機能する必ず能力ではなく、可到達性情報を交換する能力で開発されるのを必要としました。 このプロトコルは、Exteriorゲートウェイプロトコル(EGP)と呼ばれて、RFC-904[3]に記録されます。
EGP was not designed as a routing algorithm, since no agreement
could be reached on a trusted, common metric. However, EGP was
designed to provide high-quality reachability information, both
about neighbor gateways and about routes to non-neighbor gateways.
At the present state of development, dynamic routes are computed
only by the core system and provided to non-core gateways using
EGP only as an interface mechanism. Non-core gateways can provide
routes to the core system and even to other non-core gateways, but
cannot pass on "third-party" routes computed using data received
from other gateways.
EGPは、信じられたa、コモンの上でメートル法で合意に達することができなかったので、ルーティング・アルゴリズムとして設計されませんでした。 しかしながら、EGPは、隣人ゲートウェイとルートの高品質な可到達性情報を非隣人ゲートウェイに供給するように設計されました。 開発の現状では、単にインタフェースメカニズムとしてEGPを使用することでダイナミックなルートを単にコア・システムが計算して、中核でないゲートウェイに提供します。 中核でないゲートウェイは、コア・システムと、そして、他の中核でないゲートウェイにさえルートを供給できますが、他のゲートウェイから受け取られたデータを使用することで計算された「第三者」ルートを伝えることができません。
As operational experience with EGP has accumulated, it has become
clear that a more decentralized dynamic routing capability is
needed in order to avoid resource-consuming suboptimal routes. In
addition, there has long been resistance to the a-priori
assumption of a single core system, with implications of
suboptimal performance, administrative problems, impossible
enforcement and possible subversion. Whether or not this
resistance is real or justified, the important technical question
remains whether a more dynamic, distributed approach is possible
without significantly diluting stability and robustness.
EGPの運用経験が蓄積するのに従って、さらに分散しているダイナミックルーティング能力がリソースを消費する準最適のルートを避けるのに必要であるのは明確になりました。 さらに、準最適の性能、管理上の問題、不可能な実施、および可能な転覆の含意がある単芯システムの先験的な仮定への抵抗が長くありました。 この抵抗が本当であるか、または正当化されて、よりダイナミックで、分配されたアプローチが安定性と丈夫さをかなり希釈しないで可能であるかどうかという重要な技術的な問題は残っています。
This document proposes certain enhancements of EGP which
generalize the concept of core system to include multiple
communities of autonomous systems, called autonomous
confederations. Autonomous confederations maintain a higher
degree of mutual trust than that assumed between autonomous
systems in general, including reasonable protection against
routing loops between the member systems. The enhancements
involve the "hop count" or distance field of the EGP Update
自動同盟者は、このドキュメントが自律システムの複数の共同体を含むようにコア・システムの概念を広めるEGPのある増進を提案すると呼びました。 自動同盟者は一般に、自律システムの間で想定されたそれより高度の信頼関係を維持します、メンバーシステムの間のルーティング輪に対する合理的な保護を含んでいて。増進はEGP Updateの「ホップカウント」か距離分野にかかわります。
Mills [Page 2]
工場[2ページ]
RFC 975 February 1986 Autonomous Confederations
RFC975 1986年2月自動同盟者
message, which is given a special interpretation as described
later. Note that the interpretation of this field is not
specified in RFC-904, but is left as a matter for further study.
メッセージ。(特別な解釈が後で説明されるようにそのメッセージにされます)。 この分野の解釈がRFC-904で指定されませんが、さらなる研究への件として残されることに注意してください。
The interpretation of the distance field involves three levels of
metrics, in which the lowest level is available to the interior
gateway protocol (IGP) of the autonomous system itself to extend
the interior routes to the autonomous system boundary. The next
higher level selects preferred routes within the autonomous system
to those outside, while the third and highest selects preferred
routes within the autonomous confederation to those outside.
距離分野の解釈は、内部のルートを自律システム境界に広げるために、3つのレベルに関する測定基準にかかわります。(そこでは、最も低いレベルが自律システム自体の内部のゲートウェイプロトコル(IGP)に利用可能です)。 次の、より高いレベルは自律システムの中で都合のよいルートを外であるそれらに選択します、3番目で最も高いのは自動同盟者の中で都合のよいルートを外であるそれらに選択しますが。
The proposed model is believed compatible with the current
specifications and practices used in the Internet. In fact, the
entire present conglomeration of autonomous systems, including the
core system, can be represented as a single autonomous
confederation, with new confederations being formed from existing
and new systems as necessary.
提案されたモデルはインターネットで使用される現在の仕様と習慣と互換性があると信じられています。 事実上、独身の自動同盟者としてコア・システムを含む自律システムの全体の現在の凝集を表すことができます、新しい同盟者が必要に応じて存在と新しいシステムから形成されている状態で。
1.2. Routing Restrictions
1.2. ルート設定制限
It was the intent in RFC-904 that the stipulated routing
restrictions superceded all previous documents, including RFC-827
and RFC-888. The notion that a non-core gateway must not pass on
third-party information was suggested in planning meetings that
occured after the previous documents had been published and before
RFC-904 was finalized. This effectively obsoletes prior notions
of "stub" or any other asymmetry other than the third-party rule.
それは規定が制限を発送して、RFC-827とRFC-888を含む前のすべてのドキュメントをスーパー割譲したRFC-904の意図でした。 中核でないゲートウェイが第三者情報を伝えてはいけないという概念は前のドキュメントが発表されていた後とRFC-904が成立させられる前にoccuredされた企画ミーティングで示されました。 事実上、これは「スタッブ」の概念か第三者規則以外のいかなる他の非対称も優先的に時代遅れにします。
Thus, the only restrictions placed on a non-core gateway is that
in its EGP messages (a) a gateway can be listed only if it belongs
to the same autonomous system (internal neighbor) and (b) a net
can be listed only if it is reachable via gateways belonging to
that system. There are no other restrictions, overt or implied.
The specification does not address the design of the core system
or its gateways.
したがって、それがそのシステムに属しながらゲートウェイを通して届く場合にだけ、(b) (a) 同じ自律システム(内部の隣人)に属す場合にだけゲートウェイを記載できるというEGPメッセージとネットで入賞して、中核でないゲートウェイがそれであるという唯一の制限を記載できます。 明白であるか暗示している他のどんな制限もありません。 仕様はコア・システムかそのゲートウェイのデザインを記述しません。
The restrictions imply that, to insure full connectivity, every
non-core gateway must run EGP with a core gateway. Since the
present core-gateway implementation disallows other gateways on
EGP-neighbor paths, this further implies that every non-core
gateway must share a net in common with at least one core gateway.
制限は、完全な接続性を保障するために、あらゆる中核でないゲートウェイがコアゲートウェイでEGPを走らせなければならないのを含意します。 現在のコアゲートウェイ実現がEGP-隣人道の他のゲートウェイを禁じるので、これは、あらゆる中核でないゲートウェイが少なくとも1コア門と共用してネットを共有しなければならないのをさらに含意します。
Note that there is no a-priori prohibition on using EGP as an IGP,
or even on using EGP with a gateway of another non-core system,
IGPとしてEGPを使用するか、または別の中核でないシステムのゲートウェイと共にEGPを使用さえするとき、先験的な禁止が全くないことに注意してください。
Mills [Page 3]
工場[3ページ]
RFC 975 February 1986 Autonomous Confederations
RFC975 1986年2月自動同盟者
providing that the third-party rule is observed. If a gateway in
each system ran EGP with a gateway in every other system, the
notion of core system would be unneccessary and superflous.
第三者規則が守られるなら。 ゲートウェイが他のあらゆるシステムにある状態で各システムのゲートウェイがEGPを走らせるなら、コア・システムの概念は、unneccessaryとsuperflousでしょうに。
At one time during the evolution of the EGP model a strict
hierarchical topology (tree structure) of autonomous systems was
required, but this is not the case now. At one time it was
forbidden for two nets to be connected by gateways of two or more
systems, but this is not the case now. Autonomous systems are
sets of gateways, not nets or hosts, so that a given net or host
can be reachable via more than one system; however, every gateway
belongs to exactly one system.
ひところ、EGPモデルの発展の間自律システムの厳しい階層的なトポロジー(木構造)が必要でしたが、現在、これはそうではありません。 ひところ、2つのネットが2台以上のシステムのゲートウェイによって接続されるのが禁じられましたが、現在、これはそうではありません。 自律システムはネットかホストではなく、ゲートウェイのセットです、与えられたネットかホストが1台以上のシステムで届くように。 しかしながら、あらゆるゲートウェイがまさに1台のシステムに属します。
1.3. Examples and Problems
1.3. 例と問題
Consider the common case of two local-area nets A and B connected
to the ARPANET by gateways of different systems. Now assume A and
B are connected to each other by a gateway A-B belonging to the
same system as the A-ARPANET gateway, which could then list itself
and both the A and B nets in EGP messages sent to any other
gateway, since both are now reachable in its system. However, the
B-ARPANET gateway could list itself and only the B net, since the
A-B gateway is not in its system.
異系統のゲートウェイによってアルパネットに関連づけられた2つの局部ネットAとBのよくある例を考えてください。今度は、両方が現在システムで届いているので、AとBが次にEGPメッセージのAとBネットがいかなる他のゲートウェイにも送ったそれ自体と両方を記載できたA-アルパネットゲートウェイと同じシステムへのゲートウェイA-B属による互いに接されると仮定してください。 しかしながら、B-アルパネットゲートウェイはそれ自体とBネットだけを記載するかもしれません、A-Bゲートウェイがシステムにないので。
In principle, we could assume the existence of a second gateway
B-A belonging to the same system as the B-ARPANET gateway, which
would entitle it to list the A net as well; however, it may be
easier for both systems to sign a treaty and consider the A-B
gateway under joint administration. The implementation of the
treaty may not be trivial, however, since the joint gateway must
appear to other gateways as two distinct gateways, each with its
own autonomous-system number.
原則として、私たちはまた、Aネットを記載する権利を与えるだろうB-アルパネットゲートウェイと同じシステムへの2番目のゲートウェイB-A属の存在を仮定できました。 しかしながら、両方のシステムが条約に調印して、共同管理の下でA-Bゲートウェイを考えるのは、より簡単であるかもしれません。 しかしながら、共同ゲートウェイが異なった2つの門として他のゲートウェイに現れなければならないので、条約の実現は些細でないかもしれません、それぞれそれ自身の自律システム番号で。
Another case occurs when for some reason or other a system has no
path to a core gateway other than via another non-core system.
Consider a third local-are net C, together with gateway C-A
belonging to a system other than the A-ARPANET and B-ARPANET
gateways. According to the restrictions above, gateway C-A could
list net C in EGP messages sent to A-ARPANET, while A-ARPANET
could list ARPANET in messages sent to C-A, but not other nets
which it may learn about from the core. Thus, gateway C-A cannot
acquire full routing information unless it runs EGP directly with
a core gateway.
なんらかの理由でシステムが別の中核でないシステム以外のコアゲートウェイに経路を全く持っていないとき、別のケースは現れます。 3分の1を考えてください、ローカルと同じくらいの存在、A-アルパネットとB-アルパネットゲートウェイ以外のシステムへのゲートウェイC-A属と共にCを網で覆ってください。 上の制限に従ってゲートウェイ、C-A、それがコアから学ぶかもしれない他のネットではなく、A-アルパネットがC-Aに送られたメッセージのアルパネットを記載するかもしれませんが、A-アルパネットに送られたEGPメッセージのリストネットCはそうすることができました。 このようにして、ゲートウェイ、C-A、直接コアゲートウェイでEGPを走らせない場合、完全なルーティング情報を取得できません。
Mills [Page 4]
工場[4ページ]
RFC 975 February 1986 Autonomous Confederations
RFC975 1986年2月自動同盟者
2. Autonomous Systems and Confederations
2. 自律システムと同盟者
The second example above illustrates the need for a mechanism in which arbitrary routing information can be exchanged between non-core gateways without degrading the degree of robustness relative to a mutually agreed security model. One way of doing this is is to extend the existing single-core autonomous-system model to include multiple core systems. This requires both a topological model which can be used to define the scope of these systems together with a global, trusted metric that can be used to drive the routing computations. An appropriate topological model is described in the next section, while an appropriate metric is suggested in the following section.
中核でないゲートウェイの間で相談ずくの機密保護モデルに比例して丈夫さの度合いを下げないで任意のルーティング情報を交換できる2番目の例は上でメカニズムの必要性を例証します。 することのある方法は複数のコア・システムを含むように既存の単芯自律システムモデルを広げることです。これは、使用できるともにa位相的なモデルがaと共にグローバルなこれらのシステムの範囲を定義するのを必要として、メートル法で信じられて、ルーティング計算を追い立てるのにそれは使用できます。 適切な位相モデルが次のセクションで説明される、適切である、メートル法であることは、以下が区分する提案されたコネです。
2.1. Topological Models
2.1. 位相モデル
An "autonomous system" consists of a set of gateways, each of
which can reach any other gateway in the same system using paths
via gateways only in that system. The gateways of a system
cooperatively maintain a routing data base using an interior
gateway protocol (IGP) and a intra-system trusted routing
mechanism of no further concern here. The IGP is expected to
include security mechanisms to insure that only gateways of the
same system can acquire each other as neighbors.
「自律システム」は1セットのゲートウェイから成ります。そのシステムだけのゲートウェイを通して経路を使用することでそれは同じシステムでそれぞれいかなる他のゲートウェイにも達することができます。 システムのゲートウェイは、ここで内部のゲートウェイプロトコル(IGP)とさらなる関心がないイントラシステムの信じられたルーティングメカニズムを使用することで協力してルーティングデータベースを維持します。 IGPが同じシステムのゲートウェイだけが隣人として互いを取得できるのを保障するためにセキュリティー対策を含んでいると予想されます。
One or more gateways in an autonomous system can run EGP with one
or more gateways in a neighboring system. There is no restriction
on the number or configuration of EGP neighbor paths, other than
the requirement that each path involve only gateways of one system
or the other and not intrude on a third system. It is
specifically not required that EGP neighbors share a common
network, although most probably will.
1門以上が隣接しているシステムにある状態で、自律システムの1門以上はEGPを走らせることができます。 制限が全くEGP隣人道の数か構成にありません、各経路に1台のシステムかもう片方の唯一のゲートウェイにかかわって、3番目のシステムに立ち入らないという要件を除いて。 大部分がたぶん共有しますが、明確に必要でないことで、そのEGP隣人が一般的なネットワークを共有するということです。
An "autonomous confederation" consists of a set of autonomous
systems sharing a common security model; that is, they trust each
other to compute routes to other systems in the same
confederation. Each gateway in a confederation can reach any
other gateway in the same confederation using paths only in that
confederation. Although there is no restriction on the number or
configuration of EGP paths other than the above, it is expected
that some mechanism be available so that potential EGP neighbors
can discover whether they are in the same confederation. This
could be done by access-control lists, for example, or by
partitioning the set of system numbers.
「自動同盟者」は共通の安全保障モデルを共有する1セットの自律システムから成ります。 すなわち、彼らは、互いが同じ同盟者で他のシステムにルートを計算すると信じます。 その同盟者だけに経路を使用することで同盟者における各ゲートウェイは同じ同盟者でいかなる他のゲートウェイにも達することができます。 制限が全く上記を除いたEGP経路の数か構成にありませんが、潜在的EGP隣人が、彼らが同じ同盟者中であるかを発見できるくらい何らかのメカニズムが利用可能であると予想されます。 例えば、アクセスコントロールリストかシステム番号のセットを仕切ることによって、これができるでしょう。
A network is "directly reachable" from an autonomous system if a
gateway in that system has an interface to it. Every gateway in
そのシステムのゲートウェイがそれにインタフェースを持っているなら、ネットワークは自律システムから「直接届いています」。 中のあらゆるゲートウェイ
Mills [Page 5]
工場[5ページ]
RFC 975 February 1986 Autonomous Confederations
RFC975 1986年2月自動同盟者
that system is entitled to list all directly reachable networks in
EGP messages sent to any other system. In general, it may happen
that a particular network is directly reachable from more than one
system.
そのシステムはいかなる他のシステムにも送られたEGPメッセージのすべての直接届いているネットワークを記載する権利を与えられます。 一般に、特定のネットワークが1台以上のシステムから直接届いているのは起こるかもしれません。
A network is "reachable" from an autonomous system if it is
directly reachable from an autonomous system belonging to the same
confederation. A directly reachable net is always reachable from
the same system. Every gateway in that confederation is entitled
to list all reachable nets in EGP messages sent to any other
system. It may happen that a particular net is either directly
reachable or reachable from different confederations.
それが同じ同盟者のものである自律システムから直接届くなら、ネットワークは自律システムから「届いています」。 直接届いているネットは同じシステムからいつも届いています。 同盟者がEGPメッセージのすべての届いているネットを記載する権利を与えられるので、あらゆるゲートウェイがいかなる他のシステムにも発信しました。 特定のネットが異なった同盟者によって直接届くか、または届いているのが起こるかもしれません。
In order to preserve global routing stability in the Internet, it
is explicitly assumed that routes within an autonomous system to a
directly reachable net are always preferred over routes outside
that system and that routes within an autonomous confederation are
always preferred over routes outside that confederation. The
mechanism by which this is assured is described in the next
section.
インターネットにグローバルなルーティングの安定性を保存するために、直接届いているネットへの自律システムの中のルートがそのシステムの外におけるルートよりいつも好まれて、自動同盟者の中のルートがルートよりその同盟者の外でいつも好まれると明らかに思われます。 これが保証されるメカニズムは次のセクションで説明されます。
In general, EGP Update messages can include two lists of gateways,
one for those gateways belonging to the same system (internal
neighbors) and the other for gateways belonging to different
systems (external neighbors). Directly reachable nets must always
be associated with gateways of the same system, that is, with
internal neighbors, while non-directly reachable nets can be
associated with either internal or external neighbors. Nets that
are reachable, but not directly reachable, must always be
associated with gateways of the same confederation.
一般に、EGP Updateメッセージはゲートウェイ(体系が違うゲートウェイ(外部の隣人)のために同じシステム(内部の隣人)ともう片方に属すそれらのゲートウェイへの1)の2つのリストを含むことができます。 直接届いているネットはいつも同じシステムのゲートウェイに関連しているに違いありません、すなわち、内部の隣人と共に、非直接届いているネットを内部の、または、外部の隣人に関連づけることができますが。 届いていますが、直接届いていないネットはいつも同じ同盟者のゲートウェイに関連しているに違いありません。
2.2. Trusted Routing Metrics
2.2. 信じられたルート設定測定基準
There seems to be a general principle which characterizes
distributed systems: The "nearer" a thing is the more dynamic and
trustable it is, while the "farther" a thing is the more static
and suspicious it is. For instance, the concept of network is
intrinsic to the Internet model, as is the concept of gateways
which bind them together. A cluster of gateways "near" each other
(e.g. within an autonomous system) typically exchange routing
information using a high-performance routing algorithm capable of
sensitive monitoring of, and rapid adaptation to, changing
performance indicators such as queueing delays and link loading.
分散システムを特徴付ける一般的な原則はあるように思えます: それは、よりダイナミックであって、「信用-可能」です、それが、より静的であって、ものが「より遠けれ」ば」であるほど、疑わしげですがものが「より近けれ」ば」であるほど。 例えば、インターネットモデルに、ネットワークの概念は本質的です、それらを一緒にくくるゲートウェイの概念のように。 Aが敏感なモニターについて通常「近い」互い(例えば、自律システムの中の)の情報の使用しているa高性能ルーティング交換ルーティングアルゴリズムできるゲートウェイを群生させる、急速な適合、待ち行列遅れやリンク荷重などの成績指標を変えます。
However, clusters of gateways "far" from each other (e.g. widely
separated autonomous systems) usually need only coarse routing
information, possibly only "hints" on the best likely next hop to
しかしながら、通常、互い(例えば、遠くに切り離された自律システム)から「遠い」ゲートウェイのクラスタは粗いルーティング情報だけ、ことによるとベストのありそうな次が跳ぶ「ヒント」だけ、を必要とします。
Mills [Page 6]
工場[6ページ]
RFC 975 February 1986 Autonomous Confederations
RFC975 1986年2月自動同盟者
the general destination area. On the other hand, mutual suspicion
increases with distance, so these clusters may need elaborate
security considerations, including peer authentication,
confidentiality, secrecy and signature verification. In addition,
considerations of efficiency usually dictate that the allowable
network bandidth consumed by the routing protocol itself decreases
with distance. The price paid for both of these things typically
is in responsiveness, with the effect that the more distant
clusters are from each other, the less dynamic is the routing
algorithm.
一般的な目的地の地域。 他方では、距離に従って相互不信が増加するので、これらのクラスタは入念なセキュリティ問題を必要とするかもしれません、同輩認証、秘密性、秘密主義、および署名照合を含んでいて。 さらに、通常、効率の問題は、距離に従ってルーティング・プロトコル自体によって消費された許容できるネットワークbandidthが減少すると決めます。 反応性には代価を払われた価格のこれらのものの両方が通常あります、クラスタが遠方であれば遠方であるほど、互いから、ルーティング・アルゴリズムがそれほどダイナミックでないという効果で。
The above observations suggest a starting point for the evolution
of a globally acceptable routing metric. Assume the metric is
represented by an integer, with low values representing finer
distinctions "nearer" the gateway and high values coarser
distinctions "farther" from it. Values less than a globally
agreed constant X are associated with paths confined to the same
autonomous system as the sender, values greater than X but less
than another constant Y with paths confined to the autonomous
confederation of the sender and values greater than Y associated
with the remaining paths.
上の観測はメートル法でグローバルに許容できるルーティングの発展のための出発点を示します。 メートル法が「より遠くにそれからの、より下品な区別」整数、ゲートウェイ、および低値が「より近い」状態で、よりよい区別を表している高い値によって表されると仮定してください。 グローバルに同意された定数Xより少ない値は送付者(経路が送付者の自動同盟者に閉じ込められて、値がYより大きい別の定数Yが残っている経路と交際したよりXよりすばらしい、しかし、少ない値)として同じ自律システムに閉じ込められる経路に関連しています。
At each of these three levels - autonomous system, autonomous
confederation and universe of confederations - multiple routing
algorithms could be operated simultaneously, with each producing
for each destination net a possibly different subtree and metric
in the ranges specified above. However, within each system the
metric must have the same interpretation, so that other systems
can mitigate routes between multiple gateways in that system.
Likewise, within each confederation the metric must have the same
interpretation, so that other confederations can mitigate routes
to gateways in that confederation. Although all confederations
must agree on a common universe-of-confederations algorithm, not
all confederations need to use the same confederation-level
algorithm and not all systems in the same confederation need to
use the same system-level algorithm.
それぞれのこれらの3つのレベル(同盟者の自律システム、自動同盟者、および宇宙)では、複数のルーティング・アルゴリズムが、それぞれがそれぞれの目的地ネットのためにことによると異なった下位木を生産している状態で同時に、操作されていて上で指定された範囲でメートル法であるかもしれません。 しかしながら、各システムの中では、メートル法は同じ解釈を持たなければなりません、他のシステムがそのシステムの複数のゲートウェイの間のルートを緩和できるように。 同様に、各同盟者の中では、メートル法は同じ解釈を持たなければなりません、他の同盟者がその同盟者でルートをゲートウェイに緩和できるように。 すべての同盟者が一般的な同盟者の宇宙アルゴリズムに同意しなければなりませんが、すべての同盟者が、同じシステムレベルアルゴリズムを使用するのに同じ同盟者におけるシステムが必要とするすべてではなく、同じ同盟者レベルアルゴリズムを使用する必要があるというわけではありません。
3. Implementation Issues
3. 導入問題
The manner in which the eight-bit "hop count" or distance field in the EGP Update to be used is not specified in RFC-904, but left as a matter for further study. The above model provides both an interpretation of this field, as well as hints on how to design appropriate routing algorithms.
使用されるべきEGP Updateの8ビットの「ホップカウント」か距離野原がRFC-904で指定されませんが、さらなる研究への件として残される方法。 上のモデルはこの分野の解釈を両方に提供します、どう適切なルーティング・アルゴリズムを設計するかにおけるヒントと同様に。
For the sake of illustration, assume the values of X and Y above are 128 and 192 respectively. This means that the gateways in a
イラストのために、XとYの上の値がそれぞれ128と192であると仮定してください。 これがそれを意味する、aのゲートウェイ
Mills [Page 7]
工場[7ページ]
RFC 975 February 1986 Autonomous Confederations
RFC975 1986年2月自動同盟者
particular system will assign distance values less than 128 for directly-reachable nets and that exterior gateways can compare these values freely in order to select among these gateways. It also means that the gateways in all systems of a particular confederation will assign distance values between 128 and 192 for those nets not directly reachable in the system but reachable in the confederation. In the following it will be assumed that the various confederations can be distinguished by some feature of the 16-bit system-number field, perhaps by reserving a subfield.
特定のシステムが直接届いているネットのために距離値に128未満を割り当てて、外のゲートウェイが自由にこれらの値をたとえることができる、これらのゲートウェイの中で選択します。 また、それは、特定の同盟者のすべてのシステムのゲートウェイがシステムで直接届くのではなく、同盟者で届いているそれらのネットのために128〜192を距離値に割り当てることを意味します。 以下では、16ビットのシステムナンバーフィールドの何らかの特徴で様々な同盟者を区別できると思われるでしょう、恐らく部分体を予約することによって。
3.1. Data-Base Management Functions
3.1. データベースの管理機能
The following implementation model may clarify the above issues,
as well as present at least one way to organize the gateway data
base. The data base is organized as a routing table, the entries
of which include a net number together with a list of items, where
each item consists of (a) the gateway address, system number and
distance provided by an EGP neighbor, (b) a time-to-live counter,
local routing information and other information as necessary to
manage the data base.
以下の実現モデルは上記の問題をはっきりさせるかもしれません、ゲートウェイデータベースを有機化する現在の少なくとも1つの方法と同様に。 そのエントリーは項目のリストと共にネットの数を含んでいます。(そこでは、各個条が(a) ゲートウェイアドレスから成ります)。データベースは経路指定テーブルとして有機化せられます、とシステム番号と距離はデータベースを管理するために必要に応じてEGP隣人、(b) 生きる時間カウンタ、ローカルのルーティング情報、および他の情報で前提としました。
The routing table is updated each time an EGP Update message is
received from a neighbor and possibly by other means, such as the
system IGP. The message is first decoded into a list of quads
consisting of a network number, gateway address, system number and
distance. If the gateway address is internal to the neighbor
system, as determined from the EGP message, the system number of
the quad is set to that system; while, if not, the system number
is set to zero, indicating "external."
隣人とことによると他の手段でEGP Updateメッセージを受け取るたびに経路指定テーブルをアップデートします、システムIGPなどのように。 メッセージは最初に、ネットワーク・ナンバー、ゲートウェイアドレス、システム番号、および距離から成る回路のリストの中に解読されます。 ゲートウェイアドレスがEGPメッセージから決定するように隣人システムに内部であるなら、回路のシステム番号はそのシステムに設定されます。 そうでなければ、「外部であること」の形で示して、システム番号はゼロに設定されますが。
Next, a new value of distance is computed from the old value
provided in the message and subject to the following constraints:
If the system number matches the local system number, the new
value is determined by the rules for the system IGP but must be
less than 128. If not and either the system number belongs to the
same confederation or the system number is zero and the old
distance is less than 192, the value is determined by the rules
for the confederation EGP, but must be at least 128 and less than
192. Otherwise, the value is determined by the rules for the
(global) universe-of-federations EGP, but must be at least 192.
次に、距離の新しい値はメッセージと以下の規制を条件として提供された古い値から計算されます: システム番号がローカルシステム番号に合っているなら、新しい値は、システムIGPのために規則で決定しますが、128未満でなければなりません。 そうでなければ、システム番号が同じ同盟者のものであるかシステム番号がゼロであり、古い距離が192未満であり、値は、同盟者EGPのための規則で決定しますが、少なくとも128と192以下でなければなりません。 さもなければ、値は、規則で連邦のEGPの(グローバル)の宇宙に決定しますが、少なくとも192でなければなりません。
For each quad in the list the routing table is first searched for
matching net number and a new entry made if not already there.
Next, the list of items for that net number is searched for
matching gateway address and system number and a new entry made if
not already there. Finally, the distance field is recomputed, the
time-to-live field reset and local routing information inserted.
リストの各回路に関しては、経路指定テーブルは最初に、そうでなければそこで既にされた合っているネットの数と新しいエントリーを捜されます。 次に、既にそこでないなら、そのネットの数のための項目のリストはゲートウェイアドレス、システム番号、および新しいエントリーがしたマッチングを捜されます。 最終的に、距離分野が再計算されて、生きる時間分野は、情報が挿入したリセットとローカルのルーティングです。
Mills [Page 8]
工場[8ページ]
RFC 975 February 1986 Autonomous Confederations
RFC975 1986年2月自動同盟者
The time-to-live fields of all items in each list are incremented
on a regular basis. If a field exceeds a preset maximum, the item
is discarded; while, if all items on a list are discarded, the
entire entry including net number is discarded.
各リストのすべての項目の生きる時間分野は定期的に増加されます。 分野が最大の状態であらかじめセットされたaを超えているなら、項目は捨てられます。 リストの上のすべての項目が捨てられるなら、ネットの数を含む全体のエントリーは捨てられますが。
When a gateway sends an EGP Update message to a neighbor, it must
invert the data base in order by gateway address, rather than net
number. As part of this process the routing table is scanned and
the gateway with minimum distance selected for each net number.
The resulting list is sorted by gateway address and partitioned on
the basis of internal/external system number.
ゲートウェイがEGP Updateメッセージを隣人に送るとき、それはネットの数よりむしろゲートウェイアドレスで整然としているデータベースを逆にしなければなりません。 この過程の一部として、経路指定テーブルはスキャンされていて、最小の距離があるゲートウェイはそれぞれのネットの数のために選択されています。 結果として起こるリストは、ゲートウェイアドレスによって分類されて、内部の、または、外部のシステム番号に基づいて仕切られます。
3.2. Routing Functions
3.2. 経路選択機能
A gateway encountering a datagram (service unit) searches the
routing table for matching destination net number and then selects
the gateway on that list with minimum distance. As the result of
the value assignments above, it should be clear that routes at a
higher level will never be chosen if routes at a lower level
exist. It should also be clear that route selection within a
system cannot affect route selection outside that system, except
through the intervention of the intra-confederation routing
algorithm. If a simple min-system-hop algorithm is used for the
confederation EGP, the IGP of each system can influence it only to
the extent of reachability.
データグラム(サービスユニット)に遭遇するゲートウェイは、合っている目的地ネットの番号のために経路指定テーブルを捜して、次に、そのリストで最小の距離でゲートウェイを選択します。 値の課題の結果として、上では、下のレベルにおけるルートが存在していると、より高いレベルにおけるルートが決して選ばれないのが、明確であるはずです。 また、システムの中のルート選択がそのシステムの外でルート選択に影響できないのも、明確であるはずです、イントラ同盟者ルーティング・アルゴリズムの介入を除いて。 簡単なシステムが飛び越す分アルゴリズムが同盟者EGPに使用されるなら、それぞれのシステムのIGPは可到達性の範囲だけにそれに影響を及ぼすことができます。
3.3. Compatibility Issues
3.3. 互換性の問題
The proposed interpretation is backwards-compatibile with known
EGP implementations which do not interpret the distance field and
with several known EGP implementations that take private liberties
with this field. Perhaps the simplest way to evolve the present
system is to collect the existing implementations that do not
interpet the distance field at all as a single confederation with
the present core system and routing restrictions. All distances
provided by this confederation would be assumed equal to 192,
which would provide at least a rudimentary capability for routing
within the universe of confederations.
提案された解釈は距離分野を解釈しない知られているEGP実現とこの分野がある個人的な無作法を取るいくつかの知られているEGP実現がある遅れているcompatibileです。 現行制度を発展する恐らく最も簡単な方法は独身の同盟者として現在のコア・システムとルーティング制限で全く距離分野をinterpetでないのにする既存の実現を集めることです。 この同盟者によって提供されたすべての距離が192と等しいと思われるでしょう。(192は同盟者の宇宙の中のルーティングに少なくとも初歩的な能力を提供するでしょう)。
One or more existing or proposed systems in which the distance
field has a uniform interpretation throughout the system can be
organized as autonomous confederations. This might include the
Butterfly gateways now now being deployed, as well as clones
elsewhere. These systems provide the capability to select routes
into the system based on the distance fields for the different
gateways. It is anticipated that the distance fields for the
Butterfly system can be set to at least 128 if the routing
自動同盟者として1か距離分野がシステム中に同一解釈を持っているさらに既存の、または、提案されたシステムは組織化できます。 これは、現在、現在クローンと同様にほかの場所で配備されながら、Butterflyゲートウェイを含むかもしれません。 これらのシステムは異なったゲートウェイのために距離分野に基づくシステムにルートを選択する能力を提供します。 Butterflyシステムのための距離分野を少なくとも128に設定できると予期される、ルーティング
Mills [Page 9]
工場[9ページ]
RFC 975 February 1986 Autonomous Confederations
RFC975 1986年2月自動同盟者
information comes from another Butterfly system and to at least
192 if from a non-Butterfly system presumed outside the
confederation.
同盟者の外で非Butterflyシステムから推定されるなら、情報は別のButterflyシステムと少なくとも192に来ます。
New systems using an implmentation model such as suggested above
can select routes into a confederation based on the distance
field. For this to work properly, however, it is necessary that
all systems and confederations adopt a consistent interpretation
of distance values exceeding 192.
上に示されるようにimplmentationモデルを使用する新しいシステムは距離分野に基づく同盟者にルートを選択できます。 しかしながら、これが適切に働くように、すべてのシステムと同盟者が192を超えている距離値の一貫した解釈を採用するのが必要です。
4. Summary and Conclusions
4. 概要と結論
Taken at face value, this document represents a proposal for an interpretation of the distance field of the EGP Update message, which has previously been assigned no architected interpretation, but has been often used informally. The proposal amounts to ordering the autonomous systems in a hierarchy of systems and confederations, together with an interpretation of the distance field as a three-level metric. The result is to create a corresponding three-level routing community, one prefering routes inside a system, a second preferring routes inside a confederation and the third with no preference.
額面通りに取って、このドキュメントは、architected解釈が全く以前に割り当てられていないEGP Updateメッセージの距離分野の解釈のための提案を表しますが、しばしば非公式に使用されました。 提案は、距離分野の解釈と共に3レベルとしてシステムと同盟者の階層構造で自律システムを注文するのにメートル法で達します。 結果が3レベルの対応するルーティング共同体を創設することであり、1つのpreferingがシステム、2番目の中で好みなしで同盟者の中でルートを好んで、3番目を発送します。
While the proposed three-level hierarchy can readily be extended to any number of levels, this would create strain on the distance field, which is limited to eight bits in the current EGP model.
容易に提案された3レベルの階層構造をいろいろなレベルに広げることができる間、これは距離フィールドに緊張を引き起こすでしょう。(それは、現在のEGPモデルで8ビットに制限されます)。
The concept of distance can easily be generalized to "administrative distance" as suggested by John Nagle and others.
ジョン・ネーグルと他のものによって提案されるように容易に「管理距離」に距離概念を広めることができます。
5. References
5. 参照
[1] Rosen, E., Exterior Gateway Protocol (EGP), DARPA Network
Working Group Report RFC-827, Bolt Beranek and Newman, September
1982.
[1] ローゼンとE.と外のゲートウェイプロトコル(EGP)とDARPAネットワークワーキンググループレポートRFC-827とボルトBeranekとニューマン、1982年9月。
[2] Seamonson, L.J., and E.C., Rosen. "STUB" Exterior Gateway
Protocol, DARPA Network Working Group Report RFC-888, BBN
Communications, January 1984.
[2]Seamonson、L.J.、およびE.C.、ローゼン。 「スタッブ」外のゲートウェイプロトコル、DARPAネットワークワーキンググループレポートRFC-888、BBNコミュニケーション、1984年1月。
[3] Mills, D.L., Exterior Gateway Protocol Formal Specification,
DARPA Network Working Group Report RFC-904, M/A-COM Linkabit,
April 1984.
[3] 工場、D.L.、外のゲートウェイプロトコル形式仕様、DARPAネットワーク作業部会は、RFC-904、M/が1COM Linkabitであると報告して、4月は1984です。
Mills [Page 10]
工場[10ページ]
一覧
スポンサーリンク
