RFC1093 日本語訳
1093 NSFNET routing architecture. H.W. Braun. February 1989. (Format: TXT=20629 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group H.W. Braun
Request for Comments: 1093 Merit
February 1989
コメントを求めるワーキンググループH.W.ブラウン要求をネットワークでつないでください: 1093は1989年2月に値します。
The NSFNET Routing Architecture
NSFNETルート設定アーキテクチャ
Status of this Memo
このMemoの状態
This document describes the routing architecture for the NSFNET centered around the new NSFNET Backbone, with specific emphasis on the interface between the backbone and its attached networks. Distribution of this memo is unlimited.
このドキュメントは新しいNSFNET Backboneが中心に置かれたNSFNETのためにバックボーンとその付属ネットワークとのインタフェースへの特定の強調でルーティングアーキテクチャについて説明します。 このメモの分配は無制限です。
Introduction
序論
This document describes the routing architecture for the NSFNET centered around the new NSFNET Backbone, with specific emphasis on the interface between the backbone and its attached networks. It reflects and augments thoughts described in [1], discussions during the Internet Engineering Task Force meeting at the San Diego Supercomputing Center in March 1988, discussions on mailing lists, especially on a backbone/regional network working group mailing list, and a final discussion held at the IBM T.J. Watson Research Center in Yorktown, NY, on the 21st of March 1988. The Yorktown meeting was attended by Hans-Werner Braun (Merit), Scott Brim (Cornell University), Mark Fedor (NYSERNet), Jeff Honig (Cornell University), and Jacob Rekhter (IBM). Thanks also to: Milo Medin (NASA), John Moy (Proteon) and Greg Satz (Cisco) for discussing this document by email and/or phone.
このドキュメントは新しいNSFNET Backboneが中心に置かれたNSFNETのためにバックボーンとその付属ネットワークとのインタフェースへの特定の強調でルーティングアーキテクチャについて説明します。 それは、[1]で説明された考えを、反映して、増大させます、1988年3月のサンディエゴのSupercomputingセンターのインターネット・エンジニアリング・タスク・フォースのミーティングの間の議論、メーリングリストについての議論、特にバックボーン/地域ネットワークワーキンググループメーリングリスト、およびヨークタウン(ニューヨーク)でIBM T.J.ワトソン研究所で行われる最終的な議論に関して、1988年3月21日に。 ヨークタウンのミーティングはハンス-ヴェルナーBraun(長所)、スコットBrim(コーネル大学)、マーク・ヒョードル(NYSERNet)、ジェフ・ホニッグ(コーネル大学)、およびヤコブRekhter(IBM)によって出席されました。 また、以下のことのためにありがとうございます。 メール、そして/または、電話でこのドキュメントについて議論するためのミロ・メディン(NASA)、ジョンMoy(Proteon)、およびグレッグSatz(シスコ)。
Understanding of [1] is highly recommended prior to reading this document.
このドキュメントを読む前に、[1]の理解は非常にお勧めです。
1. Routing Overview
1. ルート設定概要
The new NSFNET backbone forms the core of the overall NSFNET, which connects to regional networks (or regional backbones) as well as to peer networks (other backbones like the NASA Science Network or the ARPANET). The NSFNET core uses a SPF based internal routing protocol, adapted from the IS-IS protocol submitted by ANSI for standardization to the ISO. The ANSI IS-IS protocol is based upon work done at Digital Equipment Corporation. Its adaptation to the Internet environment requires additional definitions, most notably to the addressing structure, which will be described in a later document. This adaptation was largely done by Jacob Rekhter of IBM Research in Yorktown, NY. The RCP/PSP routing architecture was largely implemented by Rick Boivie and his colleagues at IBM TCS in
新しいNSFNETバックボーンは総合的なNSFNETのコアを形成します。(NSFNETは同輩ネットワーク(NASA Science Networkやアルパネットのような他のバックボーン)に関してまた、地域ネットワーク(または、地方のバックボーン)に接続します)。 NSFNETコアはSPFのベースの内部のルーティング・プロトコルを使用します、適合している、-、プロトコルが標準化のためにANSIによってISOに提出されました。 ANSI IS存在、プロトコルはDECで行われた仕事に基づいています。 インターネット環境への適合はアドレシング構造に追加定義を最も著しく必要とします。(それは、後のドキュメントで説明されるでしょう)。 この適合がヨークタウン(ニューヨーク)でIBM ResearchのヤコブRekhterによって主に行われました。 アーキテクチャがIBM TCSのリックによるBoivieと彼の同僚に主に実装されたRCP/PSPルーティング
Braun [Page 1] RFC 1093 NSFNET Routing Architecture February 1989
アーキテクチャ1989年2月に掘るブラウン[1ページ]RFC1093NSFNET
Milford, CT. The adaptation of EGP to the NSS routing code and the new requirements was done jointly by Jeff Honig (who spent about a week to work on this at IBM Research) and Jacob Rekhter. Jeff is integrating the changes done for the new EGP requirements into the "gated" distributions.
ミルフォード(コネチカット)。 NSSルーティングコードと新しい要件へのEGPの適合がジェフ・ホニッグ(IBM Researchでこれに働くためにおよそ1週間を費やした)とヤコブRekhterによって共同で行われました。 ジェフは新しいEGP要件のために「外出を禁止された」配に行われた変化を統合しています。
The IGP derives routing tables from Internet address information. This information is flooded throughout the NSFNET core, and the individual NSS nodes create or update their routing information after running the SPF algorithm over the flooded information. A detailed description of the NSFNET backbone IGP will be documented in a future document.
IGPが経路指定テーブルにインターネットアドレス情報に由来しています。 この情報がNSFNETコア中で水につかっていて、水につかっている情報の上にSPFアルゴリズムを実行した後に、個々のNSSノードは、それらのルーティング情報を作成するか、またはアップデートします。 NSFNETバックボーンIGPの詳述は将来のドキュメントに記録されるでしょう。
The routing interface between the NSFNET core and regional backbones as well as peer networks utilizes the Exterior Gateway Protocol (EGP). The EGP/IGP consistency and integrity at the interface points is ensured by filtering mechanisms according to individual nodal routing policy data bases [1]. EGP is selected as the routing interface of choice between the NSFNET backbone and its regional attachments due to its widespread implementation as well its ability to utilize autonomous system designators and to allow for effective firewalls between systems. In the longer run the hope is to replace the EGP interface with a new inter Autonomous System protocol. Such a new protocol should also allow to move the filtering of network numbers or Autonomous Network number groups to the regional gateways in order for the regional gateways to decide as to what routing information they wish to receive.
同輩ネットワークと同様にNSFNETコアと地方のバックボーンとのルーティングインタフェースはExteriorゲートウェイプロトコル(EGP)を利用します。 インタフェースポイントでのEGP/IGPの一貫性と保全は、個々のこぶのようなルーティング方針データベース[1]に従ってメカニズムをフィルターにかけることによって、確実にされます。 広範囲の実装によるNSFNETバックボーンとその地方の付属の選択のルーティングインタフェースが自律システム指示子を利用して、システムの間に. より長い走行における望みを有効なファイアウォールに許容する性能がEGPインタフェースを新しい間のAutonomous Systemによく取り替えることであるので議定書を作るとき、EGPは選択されます。 地方のゲートウェイが、それらがどんなルーティング情報に関して受信したがっているかを決めるように、また新しいプロトコルでネットワーク・ナンバーかAutonomous Network番号のフィルタリングを動かすべきであるそのようなものは地方のゲートウェイに分類されます。
A general model is to ensure consistent routing information between peer networks. This means that, e.g., the NSFNET core will have the same sets of Internet network numbers in its routing tables as are present in the ARPANET core. However, the redistribution of this routing information is tightly controlled and based on Autonomous System numbers. For example, ARPANET routes with the ARPANET Autonomous System number will not be redistributed into regional or other peer networks. If an NSFNET internal path exists to such a network known to the ARPANET it may be redistributed into regional networks, subject to further policy verification. Generally it may be necessary to have different trust models for peer and subordinate networks, while giving a greater level of trust to peer networks.
一般的なモデルは同輩ネットワークの間の一貫したルーティング情報を保証することになっています。 これはそれを意味します、例えば、NSFNETコアが存在しているようにアルパネットコアに経路指定テーブルに同じセットのインターネットネットワーク・ナンバーを持つでしょう。 しかしながら、このルーティング情報の再分配は、しっかり制御されて、Autonomous System番号に基づいています。 例えば、アルパネットAutonomous System番号があるアルパネットルートは地方の、または、他の同輩ネットワークに再配付されないでしょう。 NSFNETの内部の経路がアルパネットに知られているそのようなネットワークに存在しているなら、さらなる方針検証を条件としてそれを地域ネットワークに再配付するかもしれません。 一般に、同輩のための異なった信頼モデルと下位のネットワークを持つのが、より大きいレベルの信頼を同輩ネットワークに与える間、必要であるかもしれません。
The described use of EGP, which is further elaborated on in [1] requires bidirectional translation of network information between the IGP in use and EGP.
EGPの説明された使用であり、どれが[1]にさらに詳しく説明されるかが使用中のIGPとEGPの間のネットワーク情報の双方向の翻訳を必要とします。
2. Conclusions reached during the discussions
2. 議論の間に達した結論
The following conclusions were reached during the meeting and in
以下の結論にミーティングとコネの間、達しました。
Braun [Page 2] RFC 1093 NSFNET Routing Architecture February 1989
アーキテクチャ1989年2月に掘るブラウン[2ページ]RFC1093NSFNET
subsequent discussions:
その後の議論:
No DDN-only routes (ARPANET/MILNET) shall be announced into the
regional backbones. This is a specific case of the ability to
suppress information from specific Autonomous Systems, as
described later.
DDNだけルート(アルパネット/MILNET)を全く地方のバックボーンに発表しないものとします。 これは後で説明されるように特定のAutonomous Systemsからの情報を抑圧する能力の特定のそうです。
Regional backbones are required to use an unique Autonomous System
number. Announcements from non-sanctioned autonomous systems,
relative to a particular site, will not be believed and will
instead trigger an alarm to the Network Operations Center.
地方のバックボーンが、ユニークなAutonomous System番号を使用するのに必要です。 非認可された自律システムからの発表は、特定のサイトに比例して信じられないで、代わりにネットワーク運営センターにアラームの引き金となるでしょう。
Regional backbone attachments must not require routes to local
subnets. This means that the locally attached network needs to
use a flat space, without subnet bits, at least from the NSS point
of view. The reason for this is that the EGP information
exchanged between the regional gateway and the NSS cannot include
subnet information. Therefore the NSS has no knowledge of remote
subnets. The safest way to get around this limitation is to use a
non-subnetted network (like a separate Class-C network) at the
interface between a regional backbone and the NSFNET backbone.
The other way is to use Proxy-ARP while having just the NSS think
that the network is not subnetted. In the latter case care must be
taken so that the E-PSP uses the proper local IP broadcast
address.
地方のバックボーン付属は地方のサブネットにルートを必要としてはいけません。 これは、局所的に添付のネットワークが、平坦なスペースを使用する必要を意味します、サブネットビットなしで、少なくともNSS観点から。 この理由は地方のゲートウェイとNSSの間で交換されたEGP情報がサブネット情報を含むことができないということです。 したがって、NSSには、リモートサブネットに関する知識が全くありません。 この制限を逃れる最も安全な方法は地方のバックボーンとNSFNETバックボーンとのインタフェースで非サブネット化したネットワーク(別々のClass-Cネットワークのような)を使用することです。 もう片方の道はまさしくNSSにネットワークが「副-網で覆」われないと思わせる間、Proxy-ARPを使用することです。 後者では、ケース注意を払わなければならないので、E-PSPは適切なローカルアイピー放送演説を使用します。
Routing information received by the NSS from regional gateways
will be verified on both network number and autonomous system
number.
NSSによって地方のゲートウェイから受け取られたルート設定情報はネットワーク・ナンバーと自律システム番号の両方で確かめられるでしょう。
Metric reconstitution is done on a per-network basis. The NSS
will construct the fixed metric it will use for a given network
number from its internal data base. Network metrics given to the
NSS via EGP will be ignored. The metrics used are a result of an
ordered list of preferred paths as supplied by the regional
backbones and the attached campuses. This metric is of relevance
only to the NSFNET core itself. The mechanisms are further
explained in [1].
1ネットワークあたり1個のベースでメートル法の再構成をします。 NSSはメートル法で修理を組み立てるでしょう。それは内部のデータベースからの与えられたネットワーク・ナンバーに使用されるでしょう。 EGPを通してNSSに与えられたネットワーク測定基準は無視されるでしょう。 使用される測定基準は地方のバックボーンと付属キャンパスから供給するように都合のよい経路の規則正しいリストの結果です。 これほどメートル法であることは、関連性のそうです。NSFNETコア自体だけに。 メカニズムは[1]でさらに説明されます。
Global metric reconstitution by Autonomous System numbers is
necessary in specific cases, such as peer networks. An example is
that ARPANET routes will be reconstituted to a global metric, as
determined by the NSS.
Autonomous System番号に従ったグローバルなメートル法の再構成が同輩ネットワークなどの特定の場合で必要です。 例はNSSによって決定されるようにアルパネットルートがaグローバルにメートル法であることで再編成されるということです。
EGP announcements into regional networks will use a fixed metric.
The metric used shall be "128." The 128-metric is somewhat
arbitrarily chosen to be high enough so that a regional backbone
will get a metric high enough from the NSFNET Core AS to allow a
地域ネットワークへのEGP発表はメートル法で修理されたaを使用するでしょう。 使用されるメートル法は「128」でしょう。 aが地方のバックボーンでメートル法にaを許容するNSFNET Core ASから十分高い状態でなって、128メートル法は、十分高くなるようにいくらか任意に選ばれています。
Braun [Page 3] RFC 1093 NSFNET Routing Architecture February 1989
アーキテクチャ1989年2月に掘るブラウン[3ページ]RFC1093NSFNET
comparison against other (most likely internal) routes. "128" is
also consistent with [2].
他の(たぶん内部)のルートに対する比較。 また、「128」も[2]と一致しています。
Peer network routes (e.g., ARPANET routes) are propagated through
the NSS structure.
同輩ネットワークルート(例えば、アルパネットルート)はNSS構造を通して伝播されます。
No DEFAULT routing information is distributed within the NSFNET
backbone, as the NSFNET core has the combined routing knowledge of
the attached regional and peer networks.
DEFAULTルーティング情報は全くNSFNETバックボーンの中で分配されません、NSFNETコアに地方と同輩の付属ネットワークに関する結合したルーティング知識があるとき。
We do not expect the requirement for damping of routing update
frequencies, at least initially. The frequency of net up/down
changes combined with the available bandwidth and CPU capacity do
not let the frequency of SPF floodings appear as being a major
problem. Simple metric changes as heard by a NSS via EGP will not
trigger updates.
私たちは少なくとも初めは、ルーティングアップデート頻度の湿気のための要件を予想しません。 利用可能な帯域幅とCPU容量に結合された/下に変化へのネットの頻度は大した問題であるとしてSPF氾濫の頻度を現れさせません。 EGPを通してNSSによって聞かれる簡単なメートル法の変化はアップデートの引き金とならないでしょう。
An allowed list of Source Autonomous System information will be
used to convert from the IGP to EGP, on a Destination Autonomous
System number basis, to allow for specific exclusion of definable
remote Autonomous System information.
Source Autonomous System情報の許容リストは、定義可能なリモートAutonomous System情報の特定の除外を考慮するのにDestination Autonomous System数のベースでIGPからEGPまで転向者に使用されるでしょう。
EGP must only announce networks for which the preferred path is
via the IGP. This means in particular that the EGP peer will
never announce via EGP what it learned via EGP on the same
interface, not even if the information was received from a third
EGP peer. This will avoid the back-distribution of information
learned via that same interface. The EGP peers of regional
gateways must only announce information belonging to their own
Autonomous System.
EGPはIGPを通して都合のよい経路があるネットワークを発表するだけでよいです。 これは、EGP同輩がEGPを通してそれが同じインタフェースのEGPを通して学んだことを決して、発表しないことを特に意味します、情報が3番目のEGP同輩から受け取られなかったとしても。 これはその同じインタフェースを通して学習された逆情報の流通を避けるでしょう。 地方のゲートウェイのEGP同輩はそれら自身のAutonomous Systemに属す情報を発表するだけでよいです。
EGP will be used in interior mode only.
EGPは内部のモードだけで使用されるでしょう。
The regional backbones are responsible for generating DEFAULT
routing information at their option. One possibility is to
generate an IGP default on a peer base as long as the NSS EGP
connection is working. The EGP information will not include a
special indication for DEFAULT.
彼らの選択のときにDEFAULTルーティングが情報であると生成するのに地方のバックボーンは原因となります。 1つの可能性はNSS EGP接続が働いている限り、同輩ベースの上でIGPデフォルトを生成することです。 EGP情報はDEFAULTに、特別な指示を含まないでしょう。
It is highly desirable to have direct peer-peer connections, to
ease the implementation of a consistent routing data base.
ダイレクト同輩同輩接続があるのは、一貫したルーティングデータベースの実装を緩和するために非常に望ましいです。
A single Autonomous System number may not be used with two E-PSPs
at the same time as long as the two E-PSP's belong to the same
NSS. Otherwise the same Autonomous System number can be used from
multiple points of attachment to the backbone and therefore can
talk to more than one E-PSP. However, this may result in
suboptimal routing unless multiple announcements are properly
2PSPのE-ものが同じNSSに属して、ただ一つのAutonomous System番号は長いことと同時に2E-PSPsと共に使用されないかもしれません。 そうでなければ、同じAutonomous System番号は、バックボーンへの複数のポイントの付属によって使用できて、したがって、1E-PSPと話すことができます。 しかしながら、複数の発表が適切にもたらさない場合、これは準最適のルーティングをもたらすかもしれません。
Braun [Page 4] RFC 1093 NSFNET Routing Architecture February 1989
アーキテクチャ1989年2月に掘るブラウン[4ページ]RFC1093NSFNET
engineered according to [1].
[1]によると、設計されます。
The administrator of the regional networks should be warned that
improper routing implementations within the region may create
suboptimal regional routing by using this restriction if no care
is taken in that:
地域ネットワークの管理者は領域の中の不適当なルーティング実装がそれで心配しないならこの制限を使用することによって準最適の地方のルーティングを作成するかもしれないのに注意されるべきです:
Only networks belonging to their own Autonomous System get
preferred over NSFNET backbone paths; this may extend to a
larger virtual Autonomous System if backdoor paths are
effectively implemented.
それら自身のAutonomous Systemに属すネットワークだけがNSFNETバックボーン経路より好まれます。 裏口の経路が事実上実装されるなら、これは、より大きい仮想のAutonomous Systemに達するかもしれません。
IGP implementations should not echo back routing information
heard via the same path.
エコーバックが同じ経路を通して聞かれた情報を発送して、IGP実装はそうするべきではありません。
If two regional networks decide to implement a backdoor
connection between themselves, then the backdoor must have a
firewall in so that information about their own Autonomous
System cannot flow in from the other Autonomous System. That
is, a regional network must not allow information about
networks that are interior to its Autonomous System to enter
via exterior routes. Likewise, if a regional network is
connected to the NSFNET via two NSS connections, the NSS cannot
send back information about the Autonomous System into the
Autonomous System where it originated. The end effect is that
partitions within an Autonomous System will not be healed by
using the NSS system. In addition, if three or more regionals
connect to each other via multiple back-door paths, it is
imperative that all back-door paths have firewalls that ensure
that the above restrictions are imposed. These actions are
necessary to prevent routing loops that involve the NSS system.
Furthermore routing information should only be accepted from
another regional backbone via backdoor paths for networks which
are positively desired to be reached via this same backdoor
path.
2つの地域ネットワークであるなら、自分たちの間の裏口の接続を実装すると決めてください、それら自身のAutonomous Systemの情報がもう片方のAutonomous Systemから流れることができないための裏口にはファイアウォールがなければならないその時。 外のルートですなわち、地域ネットワークはAutonomous Systemに内部であることのネットワークの情報を入らせてはいけません。 同様に、地域ネットワークが2つのNSS接続でNSFNETに接続されるなら、NSSはそれが起因したAutonomous SystemにAutonomous Systemの情報を返送できません。 終端効果はAutonomous Systemの中のパーティションがNSSシステムを使用することによって癒されないということです。 さらに、3つ以上の地方版が複数の裏口経路を通して互いに接するなら、オール・バックドア経路には上の制限が課されるのを確実にするファイアウォールがあるのは、必須です。 これらの動作が、NSSシステムにかかわる輪を発送するのを防ぐのに必要です。 その上、この同じ裏口の経路を通して達することが明確に望まれているネットワークのための裏口の経路を通して別の地方のバックボーンからルーティング情報を受け入れるだけであるべきです。
3. EGP requirements for attached gateways
3. 付属ゲートウェイのためのEGP要件
The following EGP requirements are necessary for attached gateways; they may require changes in existing vendor products:
以下のEGP要件が付属ゲートウェイに必要です。 彼らは既存のメーカー製品の中に釣り銭がいるかもしれません:
IGP to EGP routing exchanges need to be bidirectional. This
feature should be selectable by the gateway administrator, and by
default be configured OFF.
EGPルーティング交換へのIGPは、双方向である必要があります。 この特徴は、ゲートウェイ管理者が選択可能であり、デフォルトで構成されたOFFであるべきです。
The metric used when translating from EGP to IGP should be
configurable.
EGPからIGPまで翻訳するとき使用されるメートル法は構成可能であるべきです。
Braun [Page 5] RFC 1093 NSFNET Routing Architecture February 1989
アーキテクチャ1989年2月に掘るブラウン[5ページ]RFC1093NSFNET
It must be possible for IGP information to override EGP
information, so that the internal paths are preferred over
external paths. Overriding EGP information on an absolute basis,
where an external path would never be used as long as there is an
internal one, is acceptable.
IGP情報がEGP情報に優越するのは、可能であるに違いありません、内部の経路が外部の経路より好まれるように。 絶対ベースのEGP情報に優越するのは許容できます。(そこでは、内部のものがある限り、外部の経路が決して使用されません)。
The ability to do route filtering in the regional gateways on a
per net basis is highly desirable to allow the regional gateways
to do a further selection as to what routes they would want to
redistribute into their network.
それらがどんなルートを自己のネットワークに再配付したがっているだろうかに関して地方のゲートウェイがさらなる選択をするのを許容するのにおいてネットの基礎あたりのaで地方のゲートウェイでフィルタリングを発送する能力は非常に望ましいです。
The existence of an EGP connection should optionally lead to the
generation of a DEFAULT announcement for propagation via the IGP.
The DEFAULT metric should be independently configurable.
EGP接続の存在はIGPを通して任意に伝播のためのDEFAULT発表の世代につながるべきです。 DEFAULTメートル法であることは、独自にそうであるべきです。構成可能。
EGP routes with a metric of "128" should be acceptable. In most
cases the regional backbone should ignore the EGP metric.
「128」におけるメートル法のaがあるEGPルートは許容できるべきです。 多くの場合、地方のバックボーンはメートル法であることでEGPを無視するべきです。
The regional gateways must only announce networks known to their
own Autonomous System. At the very least they must not
redistribute routing information via EGP for routes previously
learned via EGP.
地方のゲートウェイはそれら自身のAutonomous Systemにおいて知られているネットワークを発表するだけでよいです。 少なくとも、彼らは以前にEGPを通して学習されたルートへのEGPを通してルーティング情報を再配付してはいけません。
It would be beneficial if the regional IGPs would tag routes as
being EGP derived.
地方のIGPsがEGPが引き出した存在としてルートにタグ付けをするなら、有益でしょう。
If the EGP peer (e.g., a NSS) terminates the EGP exchange the
previously learned routes should expire in a timely fashion.
EGP同輩(例えば、NSS)がEGP交換を終えるなら、以前に学術的なルートは直ちに期限が切れるはずです。
4. References
4. 参照
[1] Rekhter, J., "EGP and Policy Based Routing in the New NSFNET
Backbone", T.J. Watson Research Center, IBM Corporation, March
1988. Also as RFC 1092, February 1989.
[1] Rekhter、J.、「EGPと方針は新しいNSFNETバックボーンにおけるルート設定を基礎づけました」、T.J.ワトソン研究所、IBM社、1988年3月。 RFC1092、1989年2月としても。
[2] Mills, D., "Autonomous Confederations", RFC 975, M/A-COM
Linkabit, February 1986.
[2]工場、D.、RFC975、M1COM Linkabitの/1986年2月の「自動同盟者。」
[3] Mills, D., "Exterior Gateway Formal Specification", RFC 904,
M/A-COM Linkabit, April 1984.
[3] 工場、D.、「外のゲートウェイ形式仕様」、RFC904、M1COM Linkabitの/1984年4月。
[4] "Exterior Gateway Protocol, Version 3, Revisions and Extensions,"
Working Notes of the IETF WG on EGP, Marianne L. Gardner and
Mike Karels, February 1988.
[4] EGPとマリアンエ・L.ガードナーとマイクKarels、1988年2月にIETF WGの注意を扱う「外のゲートウェイプロトコル、バージョン3、改正、および拡大。」
[5] "Management and Operation of the NSFNET Backbone Network,"
proposal to the National Science Foundation, Merit Computer
Network, August 1987.
[5] 「NSFNET背骨ネットワークの管理と操作」、国立科学財団への提案、MeritコンピュータNetwork、8月1987日
Braun [Page 6] RFC 1093 NSFNET Routing Architecture February 1989
構造1989年2月に掘るブラウン[6ページ]RFC1093NSFNET
5. Appendix
5. 付録
The following are extensions implemented for the "gated" EGP implementation, as designed by Jeff Honig of the Cornell University Theory Center. These extensions are still in the design stage and may be changed over time. They are included here as an implementation example.
↓これは「外出を禁止された」EGP実現のために実行された拡大です、コーネル大学Theoryセンターのジェフ・ホニッグによって設計されているように。 これらの拡大はまだ設計段階にあって、時間がたつにつれて、変えるかもしれません。 それらは実現の例としてここに含まれています。
Changes to egpneighbor clause:
egpneighbor節への変化:
egpneighbor <address> metricin <metric>
egpmetricout <egpmetric>
ASin <as>
ASout <as>
nogendefault
acceptdefault
defaultout <egpmetric>
validate
>nogendefault acceptdefault defaultout<egpmetric>としての>ASout<としてのメートル法の>のegpmetricout<egpmetric>ASin<が有効にするegpneighbor<アドレス>metricin<。
metricin <metric>
metricinの<のメートル法の>。
If specified, the metric of all nets received from this
neighbor are set to <metric>.
指定されるなら、この隣人から受け取られたすべてのネットのメートル法は<のメートル法の>に設定されます。
egpmetricout <egpmetric>
egpmetricout<egpmetric>。
If specified, the metric of all nets sent to this neighbor,
except default, are set to <egpmetric>.
指定されるなら、デフォルトを除いて、この隣人に送られたすべてのネットのメートル法は<egpmetric>に設定されます。
ASin <as>
>としてのASin<。
If specified, EGP packets received from this neighbor must
specify this AS number of an EGP error packet is generated.
The AS number is only checked at neighbor acquisition time.
この隣人から受け取られた指定されたEGPパケットが指定しなければならないなら、EGP誤りパケットのこのAS番号は発生します。 AS番号は隣人獲得時間にチェックされるだけです。
ASout <as>
>としてのASout<。
If specified, this AS number is used on all EGP packets sent
to thiqs neighbor
指定されるなら、このAS番号はthiqs隣人に送られたすべてのEGPパケットの上で使用されます。
nogendefault
nogendefault
If specified, this neighbor is not considered when
generating a gateway default.
ゲートウェイデフォルトを発生させるとき、指定されるなら、この隣人は考えられません。
acceptdefault
acceptdefault
If specified, the default will be accepted from this
指定すると、これからデフォルトを受け入れるでしょう。
Braun [Page 7] RFC 1093 NSFNET Routing Architecture February 1989
構造1989年2月に掘るブラウン[7ページ]RFC1093NSFNET
neighbor, otherwise it will be explicitly ignored.
隣人、さもなければ、それは明らかに無視されるでしょう。
defaultout <egpmetric>
defaultout<egpmetric>。
If specified, the internally generated default is send to
this neighbor in EGP updates. Default learned from other
gateways is not propogated.
指定されるなら、内部的に発生したデフォルトはEGPアップデートでこの隣人に発信することです。 他のゲートウェイから学習されたデフォルトは伝播されません。
validate
有効にします。
If specifed, all nets learned from this EGP neighbor must
have a corresponding 'validAS' clause or they will be
ignored.
specifedされるなら、このEGP隣人から学習されたすべてのネットが対応する'validAS'節を持たなければならない、さもなければ、彼らは無視されるでしょう。
Addition of a validAS clause:
validAS節の添加:
validAS <net> AS <as> metric <metric>
>のメートル法の<メートル法の>としてのvalidASの<のネットの>AS<。
This clause specifies which AS a network may be learned from and
what internal metric to use when the net is learned. The
specifies the 'validate' option. Note that more than one may be
learned from more than one AS.
この節は、ネットワークがどのASから学習されるかもしれないか、そして、ネットであるときに、使用するためにはメートル法のどんなインターナルが学習されるかを指定します。 '有効にする'オプションを指定します。 より多くの1ASから学習されるかもしれないことに注意してください。
Addition of sendAS and donotsendAS clauses:
sendASとdonotsendAS節の添加:
These clauses control the announcement of exterior (currently only
EGP) routes. Normally, exterior routes are not considered for
announcement. When the 'sendAS' or 'donotsendAS' clauses are
used, the announce/donotannounce, egpnetsreachable and other
restrictions still apply. The 'sendAS' and 'donotsendAS' clauses
are mutually exclusive by autonomous system.
これらの節は外(現在のEGPだけ)のルートの発表を制御します。 通常、外のルートは発表のために考えられません。 'sendAS'か'donotsendAS'節が使用されているとき、発表する、/donotannounceであって、egpnetsreachableであって他の制限がまだ適用されていると発表してください。 'sendAS'と'donotsendAS'節は自律システムで互いに排他的です。
sendAS <as0> ASlist <as1> <as2> ...
sendAS<as0>ASlist<as1><as2>…
This clause specifies that only nets learned from as1, as2, ...
may be propogated to as0.
この節は、ネットだけがas1、as2から学んだと指定して、…はas0に伝播されるかもしれません。
donotsendAS <as0> ASlist <as1> <as2> ...
donotsendAS<as0>ASlist<as1><as2>…
This clause specifies that nets learned from as1, as2, ... may
not be propogated to <as0>, all other nets are propogated.
この節は、as1から学習されたネット、as2、…が<as0>に伝播されないかもしれなくて、他のすべてのネットが伝播されると指定します。
An example of a "/etc/gated.conf" file could include the following:
"/etc/gated.conf"ファイルに関する例は以下を含むかもしれません:
# RIP supplier # autonomousystem (regional AS)
# RIP供給者#autonomousystem(地方)です。
Braun [Page 8] RFC 1093 NSFNET Routing Architecture February 1989
構造1989年2月に掘るブラウン[8ページ]RFC1093NSFNET
# egpneighbor (NSS address) ASin (NSS AS) nogendefault metricin (metric) # sendAS (NSS AS) ASlist (regional AS) #
# egpneighbor(NSSアドレス)ASin(NSS AS)のnogendefault metricinの(メートル法)の#sendAS(NSS AS)ASlist(地方のAS)#
Where:
どこ:
Regional AS Is the AS number of the regional network
NSS address Is the IP address of the local NSS
NSS AS Is the AS number the NSFNET backbone
Metric Is the gated internal (time delay) metric that
EGP learned routes should have. This is the
metric used on output after conversion to a RIP
metric. Some values are:
ASが付番するIPが記述する地方のNSS NSS AS Is ASの地域ネットワークNSSアドレスIsの地方のAS Isは外出を禁止された内部(時間遅れ)のメートル法のEGPそんなに学術的なルートが持っているはずであるNSFNET背骨Metric Isに付番します。 これは変換の後に出力のときにRIPにメートル法で使用されたメートル法です。 いくつかの値は以下の通りです。
HELLO RIP
100 1
148 2
219 3
325 4
481 5
こんにちは、裂け目100の1、148、2、219、3、325、4、481、5
Author's Address:
作者のアドレス:
Hans-Werner Braun University of Michigan Computing Center 1075 Beal Avenue Ann Arbor, MI 48109
ハンス-ヴェルナー・ブラウンミシガン計算機センタ大学1075ビール・Avenueアナーバー、MI 48109
Phone: (313) 763-4897
以下に電話をしてください。 (313) 763-4897
Email: HWB@MCR.UMICH.EDU
メール: HWB@MCR.UMICH.EDU
Braun [Page 9]
ブラウン[9ページ]
一覧
スポンサーリンク
