RFC1126 日本語訳
1126 Goals and functional requirements for inter-autonomous systemrouting. M. Little. October 1989. (Format: TXT=62725 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Little
Request for Comments: 1126 SAIC
October 1989
ほとんどコメントを求めるワーキンググループM.要求をネットワークでつながないでください: 1126 SAIC1989年10月
Goals and Functional Requirements for
Inter-Autonomous System Routing
相互自律システムルート設定のための目標と機能条件書
Status of this Memo
このMemoの状態
This document describes the functional requirements for a routing protocol to be used between autonomous systems. This document is intended as a necessary precursor to the design of a new inter- autonomous system routing protocol and specifies requirements for the Internet applicable for use with the current DoD IP, the ISO IP, and future Internet Protocols. It is intended that these requirements will form the basis for the future development of a new inter- autonomous systems routing architecture and protocol. This document is being circulated to the IETF and Internet community for comment. Comments should be sent to: "open-rout-editor@bbn.com". This memo does not specify a standard. Distribution of this memo is unlimited.
このドキュメントはルーティング・プロトコルが自律システムの間で使用されるという機能条件書について説明します。このドキュメントは、必要な先駆として新しい相互自律システムルーティング・プロトコルのデザインに意図して、現在のDoD IP、ISO IPとの使用に、適切なインターネット、および将来のインターネットプロトコルに要件を指定します。 これらの要件が新しい相互自律システムルーティング構造とプロトコルの今後の開発の基礎を形成することを意図します。 このドキュメントはコメントのためにIETFとインターネットコミュニティに循環しています。 以下のことのためにコメントを送るべきです。 " open-rout-editor@bbn.com "。 このメモは規格を指定しません。 このメモの分配は無制限です。
1. Introduction
1. 序論
The development of an inter-autonomous systems routing protocol proceeds from those goals and functions seen as both desirable and obtainable for the Internet environment. This document describes these goals and functional requirements. The goals and functional requirements addressed by this document are intended to provide a context within which an inter-autonomous system routing architecture can be developed which will meet both current and future Internet routing needs. The goals presented indicate properties and general capabilities desired of the Internet routing environment and what the inter-autonomous system routing architecture is to accomplish as a whole.
相互自律システムルーティング・プロトコルの開発はともに望ましくインターネット環境には入手可能であるとみなされたそれらの目標と機能から進んでいます。 このドキュメントはこれらの目標と機能条件書について説明します。 このドキュメントによって記述された目標と機能条件書が満たされる相互自律システムルーティング構造を開発できる現在のものと同様に将来のインターネット・ルーティングが必要とする文脈を提供することを意図します。 提示された目標は全体で達成するインターネット・ルーティング環境と相互自律システムルーティング構造が何であるかということであることで必要な特性と一般的な能力を示します。
The goals are followed by functional requirements, which address either detailed objectives or specific functionality to be achieved by the architecture and resulting protocol(s). These functional requirements are enumerated for clarity and grouped so as to map directly to areas of architectural consideration. This is followed by a listing and description of general objectives, such as robustness, which are applicable in a broad sense. Specific functions which are not reasonably attainable or best left to future efforts are identified as non-requirements.
機能条件書は目標のあとに続いています。(機能条件書は、構造と結果として起こるプロトコルによって達成されるために詳細な目的か特定の機能性のどちらかを記述します)。 これらの機能条件書は、直接建築することの領域に考慮を写像するために明快ために列挙されて、分類されます。 丈夫さなどの一般的な広い意味で適切な目的のリストと記述はこれを支えています。 今後の努力への合理的に達成できるか最も良い左でない具体的な機能は非要件として特定されます。
The intent of this document is to provide both the goals and functional requirements in a concise fashion. Supporting arguments,
このドキュメントの意図は簡潔なファッションによる目標と機能条件書の両方を提供することです。 議論を支持します。
Little [Page 1] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[1ページ]RFC1126相互自律システム
tradeoff considerations and the like have been purposefully omitted in support of this. An appendix has been included which addresses this omission to a limited extent and the reader is directed there for a more detailed discussion of the issues involved.
見返り問題と同様のものは故意にこれを支持して省略されました。 付録は含まれています、そして、(限られた程度でこの省略を記述します)読者はかかわった問題の、より詳細な議論のためにそこで指示されます。
The goals and functional requirements contained in this document are the result of work done by the members of the Open Routing Working Group. It is our intention that these goals and requirements reflect not only those foreseen in the Internet community but are also similar to those encountered in environments proposed by ANSI, ECMA and ISO. It is expected that there will be some interaction and relationship between this work and the product of these groups.
本書では含まれた目標と機能条件書はオープンルート設定作業部会のメンバーによって行われた仕事の結果です。 それはこれらの目標と要件もインターネットコミュニティで見通されたものだけを反映しませんが、また、ANSI、ECMA、およびISOによって提案された環境で遭遇するものと同様であるという私たちの意志です。 これらのグループのこの仕事と製品との何らかの相互作用と関係があると予想されます。
2. Overall Goals
2. 全体的な目的
In order to derive a set functional requirements there must be one or more principals or overall goals for the routing environment to satisfy. These high level goals provide the basis for each of the functional requirements we have derived and will guide the design philosophy for achieving an inter-autonomous system routing solution. The overall goals we are utilizing are described in the following sections.
セットを引き出して、そこの機能条件書は、満たすルーティング環境のための1人以上の校長か全体的な目的でなければなりません。 これらの高い平らな目標は相互自律システムルーティング解決を実現する私たちが派生して、設計理念を誘導するつもりであるそれぞれに関する機能条件書の基礎を提供します。 私たちが利用している全体的な目的は以下のセクションで説明されます。
2.1 Route to Destination
目的地への2.1ルート
The routing architecture will provide for the routing of datagrams from a single source to one or more destinations in a timely manner. The larger goal is to provide datagram delivery to an identifiable destination, one which is not necessarily immediately reachable by the source. In particular, routing is to address the needs of a single source requiring datagram delivery to one or more destinations. The concepts of multi-homed hosts and multicasting routing services are encompassed by this goal. Datagram delivery is to be provided to all interconnected systems when not otherwise constrained by autonomous considerations.
ルーティング構造は単独のソースから1つ以上の目的地まで直ちにデータグラムのルーティングに備えるでしょう。 より大きい目標は身元保証可能な目的地(必ずすぐにソースで届いていないもの)にデータグラム配信を提供することです。 ルーティングは特に、1つ以上の目的地にデータグラム配信を必要とする単独のソースの必要性を記述することです。 概念、マルチ、家へ帰り、ホストとマルチキャスティングルーティングサービスはこの目標によって成就されます。 データグラム配信は別の方法で自治の問題で抑制しないとすべての相互接続システムに供給することです。
2.2 Routing is Assured
2.2 ルート設定はAssuredです。
Routing services are to be provided with assurance, where the inability to provide a service is communicated under best effort to the requester within an acceptable level of error. This assurance is not to be misconstrued to mean guaranteed datagram delivery nor does it imply error notification for every lost datagram. Instead, attempts to utilize network routing services when such service cannot be provided will result in requester notification within a reasonable period given persistent attempts.
ルート設定サービスは自信を持って提供することです、サービスを提供できないことがリクエスタへの合格水準の誤りの中のベストエフォート型の下で伝えられるところで。 この保証が保証されたデータグラム配信を意味するために誤解されないことであり、それはあらゆる無くなっているデータグラムのためのエラー通知を含意しません。 代わりに、粘り強い試みを考えて、そのようなサービスを提供できないときネットワークルーティングサービスを利用する試みは相当期間以内にリクエスタ通知をもたらすでしょう。
Little [Page 2] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[2ページ]RFC1126相互自律システム
2.3 Large System
2.3 大規模システム
The design of the architecture, and the protocols within this architecture, should accommodate a large number of routing entities. The exact order of magnitude is a relative guess and the best designs would provide for a practical level of unbounded growth. Nevertheless, the routing architecture is expected to accommodate the growth of the Internet environment for the next 10 years.
構造のデザイン、およびこの構造の中のプロトコルは多くのルーティング実体を収容するべきです。 正確な桁は相対的な推測です、そして、最も良いデザインは実務レベルの限りない成長に備えるでしょう。 それにもかかわらず、ルーティング構造が次の10年間インターネット環境の成長に対応すると予想されます。
2.4 Autonomous Operation
2.4 自動操作
The routing architecture is to allow for stable operation when significant portions of the internetworking environment are controlled by disjoint entities. The future Internet environment is envisioned as consisting of a large number of internetworking facilities owned and operated by a variety of funding sources and administrative concerns. Although cooperation between these facilities is necessary to provide interconnectivity, it is viewed that both the degree and type of cooperation will vary widely. Additionally, each of these internetworking facilities desires to operate as independently as possible from the concerns and activities of other facilities individually and the interconnection environment as a whole. Those resources used by (and available for) routing are to be allowed autonomous control by those administrative entities which own or operate them. Specifically, each controlling administration should be allowed to establish and maintain policies regarding the use of a given routing resource.
ルーティング構造は安定稼働を考慮するために、インターネットワーキング環境の重要な部分がいつまでに制御されているかが実体をばらばらにならせるということです。 将来のインターネット環境はさまざまな資金源と管理関心によって所有されて、操作された多くのインターネットワーキング施設から成ると思い描かれます。 これらの施設の間の協力が相互接続性を提供するのに必要ですが、それは見られます。度とタイプの協力の両方がばらつきが大きいでしょう。 さらに、そして、それぞれ他の施設の関心と活動からできるだけ独自に個別に作動するこれらのインターネットワーキング施設願望と全体でインタコネクト環境について。 それらのリソース、中古、そして、(利用可能)、掘って、自治はそれらを所有しているか、または操作するそれらの管理実体によって許容されることになっていてください。 明確に、与えられたルーティングリソースの使用に関する方針を確立して、それぞれ管理を制御するのは維持できるべきです。
2.5 Distributed System
2.5 分散システム
The routing environment developed should not depend upon a data repository or topological entity which is either centralized or ubiquitous. The growth pattern of the Internet, coupled with the need for autonomous operation, dictates an independence from the topological and administrative centralization of both data and control flows. Past experience with a centralized topology has shown that it is both impractical for the needs of the community and restrictive of administrative freedoms. A distributed routing environment should not be restrictive of either redundancy or diversity. Any new routing environment must allow for arbitrary interconnection between internetworks.
環境が開発したルーティングは、どれが集結されているか、または遍在しているかにデータ倉庫か位相的な実体によるべきではありません。 自動操作の必要性に結びつけられたインターネットの成長パターンは両方のデータの位相的で管理の中央集権化から独立を決めます、そして、コントロールは流れます。 集結されたトポロジーの過去の経験は、管理自由の共同体と限定語の必要性には、それがともに非実用的であることを示しました。分散ルーティング環境は冗長か多様性のどちらかで制限しているべきではありません。 どんな新しいルーティング環境もインターネットワークの間の任意のインタコネクトを考慮しなければなりません。
2.6 Provide A Credible Environment
2.6は確かな環境を提供します。
The routing environment and services should be based upon mechanisms and information that exhibit both integrity and security. The routing mechanisms should operate in a sound and reliable fashion while the routing information base should provide credible data upon
ルーティング環境とサービスは保全とセキュリティの両方を示すメカニズムと情報に基づくべきです。 ルーティングメカニズムはベースが確かなデータを提供するはずであるルーティング情報である間、音と信頼できるファッションで動作するはずです。
Little [Page 3] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[3ページ]RFC1126相互自律システム
which to base routing decisions. The environment can be unreliable to the extent that the resulting effect on routing services is negligible. The architecture and protocol designs should be such that the routing environment is reasonably secure from unwanted modification or influence.
どれ、ルーティング決定を基礎づけるために。 環境はルーティングサービスへの結果として起こる効果が取るにたらないという範囲に頼り無い場合があります。 構造とプロトコルデザインがそのようなものであるべきであるので、ルーティング環境は求められていない変更か影響から合理的に安全です。
2.7 Be A Managed Entity
2.7 管理された実体になってください。
Provide a manger insight into the operation of the inter-autonomous system routing environment to support resource management, problem solving, and fault isolation. Allow for management control of the routing system and collect useful information for the internetwork management environment. Datagram events as well as the content and distribution characteristics of relevant databases are of particular importance.
相互自律システムルーティング環境の操作に関する飼葉桶洞察を提供して、資源管理、問題解決、および欠点孤立を支持してください。 ルーティングシステムのマネジメント・コントロールを考慮してください、そして、インターネットワーク経営環境のための役に立つ情報を集めてください。 関連データベースの内容と分配の特性と同様にデータグラムイベントは特別に重要です。
2.8 Minimize Required Resources
2.8は必要なリソースを最小にします。
Any feasible design should restrain the demand for resources required to provide inter-autonomous systems routing. Of particular interest are those resources required for data storage, transmission, and processing. The design must be practical in terms of today's technology. Specifically, do not assume significant upgrades to the existing level of technology in use today for data communication systems.
どんな可能なデザインも相互自律システムルーティングを提供するのに必要であるリソースの要求を抑制するべきです。 特別の関心はデータ保存、トランスミッション、および処理に必要であるそれらのリソースです。 デザインは今日の技術で実用的であるに違いありません。 明確に、今日、データ通信システムのために既存のレベルの技術への重要なアップグレードが使用中であると仮定しないでください。
3. Functional Requirements
3. 機能条件書
The functional requirements we have identified have been derived from the overall goals and describe the critical features expected of inter-autonomous system routing. To an extent, these functions are vague in terms of detail. We do not, for instance, specify the quantity or types for quality-of-service parameters. This is purposeful, as the functional requirements specified here are intended to define the features required of the inter-autonomous system routing environment rather than the exact nature of this environment. The functional requirements identified have been loosely grouped according to areas of architectural impact.
私たちが特定した機能条件書は、全体的な目的から得られて、相互自律システムルーティングに予想されたきわどい特徴について説明します。 これらの機能は詳細で程度まで、あいまいです。 例えば、私たちはサービスの質パラメタに量かタイプを指定しません。 これは故意です、ここで指定された機能条件書がこの環境の正確な本質よりむしろ相互自律システムルーティング環境について必要である特徴を定義することを意図するとき。 建築衝撃の領域に従って、特定された機能条件書は緩く分類されました。
3.1 Route Synthesis Requirements
3.1 ルート統合要件
Route synthesis is that functional area concerned with both route selection and path determination (identification of a sequence of intermediate systems) from a source to a destination. The functional requirements identified here provide for path determination which is adaptive to topology changes, responsive to administrative policy, cognizant of quality-of-service concerns, and sensitive to an interconnected environment of autonomously managed systems.
ルート統合は機能的な領域がソースから目的地までの(中間システムの系列の識別)がルート選択と経路決断の両方に関係があったということです。 ここで特定された機能条件書はトポロジー変化に適応型の、そして、施政方針に敏感で、サービスの質関心で認識力があって、自主的に管理されたシステムのインタコネクトされた環境に敏感な経路決断に備えます。
Little [Page 4] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[4ページ]RFC1126相互自律システム
a) Route around failures dynamically
a) 失敗の周りでダイナミックに発送します。
Route synthesis will provide a best effort attempt to detect
failures in those routing resources which are currently being
utilized. Upon detection of a failed resource, route synthesis
will provide a best effort to utilize other available routing
resources in an attempt to provide the necessary routing
service.
ルート統合は現在利用されているそれらのルーティングリソースに失敗を検出するベストエフォート型試みを提供するでしょう。 失敗したリソースの検出のときに、ルート統合は必要なルーティングサービスを提供する試みで他の利用可能なルーティングリソースを利用するためにはベストエフォート型のaを提供するでしょう。
b) Provide loop free paths
b) 自由な経路を輪に供給してください。
The path provided for a datagram, from source to destination,
will be free of circuits or loops most of the time. At those
times a circuit or loop exists, it occurs with both negligible
probability and duration.
経路は、たいていソースから目的地までデータグラムに備えるか、サーキットから自由であるか、または輪にされます。 サーキットか輪が存在しているというそれらの時に、それは取るにたらない確率と持続時間の両方で起こります。
c) Know when a path or destination is unavailable
c) 経路か目的地がいつ入手できないかを知ってください。
Route synthesis will be capable of determining when a path
cannot be constructed to reach a known destination.
Additionally, route synthesis will be capable of determining
when a given destination cannot be determined because the
requested destination is unknown (or this knowledge is
unavailable).
ルート統合は、いつ知られている目的地に達するように経路を構成できないかを決定できるでしょう。 さらに、ルート統合は、要求された目的地が未知であるので(この知識は入手できません)与えられた目的地がいつ決定できないかを決定できるでしょう。
d) Provide paths sensitive to administrative policies
d) 施政方針に敏感な経路を提供してください。
Route synthesis will accommodate the resource utilization
policies of those administrative entities which manage the
resources identified by the resulting path. However, it is
inconceivable to accommodate all policies which can be defined
by a managing administrative entity. Specifically, policies
dependent upon volatile events of great celerity or those which
are non-deterministic in nature cannot be accommodated.
ルート統合は結果として起こる経路によって特定されたリソースを管理するそれらの管理実体のリソース利用方針に対応するでしょう。 しかしながら、管理の管理実体で定義できるすべての方針に対応するのは思いもよりません。 明確に、すばらしい迅速の揮発性の出来事に依存する方針か現実に非決定論的なものに対応できません。
e) Provide paths sensitive to user policies
e) ユーザ方針に敏感な経路を提供してください。
Paths produced by route synthesis must be sensitive to policies
expressed by the user. These user policies are expressed in
terms relevant to known characteristics of the topology. The
path achieved will meet the requirements stated by the user
policy.
ルート統合で生産された経路はユーザによって言い表された方針に敏感であるに違いありません。 これらのユーザ方針はトポロジーの知られている特性に関連している用語で言い表されます。 達成された経路はユーザ方針で述べられた必要条件を満たすでしょう。
f) Provide paths which characterize user quality-of-service
requirements
f) ユーザサービスの質要件を特徴付ける経路を提供してください。
The characteristics of the path provided should match those
indicated by the quality-of-service requested. When
提供された経路の特性は要求されたサービスの質によって示されたものに合うべきです。 いつ
Little [Page 5] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[5ページ]RFC1126相互自律システム
appropriate, utilize only those resources which can support the
desired quality-of-service (e.g., bandwidth).
適切であることで、必要なサービスの質(例えば、帯域幅)を支持できるそれらのリソースだけを利用してください。
g) Provide autonomy between inter- and intra-autonomous system
route synthesis
g) そして、自治を提供する、相互、イントラ自律システムルート統合
The inter- and intra-autonomous system routing environments
should operate independent of one another. The architecture
and design should be such that route synthesis of either
routing environment does not depend upon information from the
other for successful functioning. Specifically, the inter-
autonomous system route synthesis design should minimize the
constraints on the intra-autonomous system route synthesis
decisions when transiting (or delivering to) the autonomous
system.
そして、相互、イントラ自律システムルーティング環境はお互いの如何にかかわらず作動するべきです。 構造とデザインがそのようなものであるべきであるので、掘っている環境のルート統合はうまくいっている機能のためにもう片方からの情報によりません。 または、イントラ自律システムルート統合決定のときに通過するとき、明確に、相互自律システムルート統合デザインが規制を最小にするべきである、(配送する、)、自律システム。
3.2 Forwarding Requirements
3.2 推進要件
The following requirements specifically address the functionality of the datagram forwarding process. The forwarding process transfers datagrams to intermediate or final destinations based upon datagram characteristics, environmental characteristics, and route synthesis decisions.
以下の要件は明確にデータグラム推進の過程の機能性を記述します。 推進の過程はデータグラムの特性、環境特性、およびルート統合決定に基づく中間的であるか最終的な目的地にデータグラムを移します。
a) Decouple inter- and intra-autonomous system forwarding
decisions
a) そして、衝撃を吸収、相互、イントラ自律システム推進決定
The requirement is to provide a degree of independence between
the inter-autonomous system forwarding decision and the intra-
autonomous system forwarding decision within the forwarding
process. Though the forwarding decisions are to be independent
of each other, the inter-autonomous system delivery process may
necessarily be dependent upon intra-autonomous system route
synthesis and forwarding.
要件は推進の過程の中で相互自律システム推進決定とイントラ自律システム推進決定の間に1段階の独立を提供することです。 推進決定が互いから独立していることですが、相互自律システム配送過程は必ずイントラ自律システムルート統合と推進に依存しているかもしれません。
b) Do not forward datagrams deemed administratively inappropriate
b) 行政上不適当であると考えられたデータグラムを進めないでください。
Forward datagrams according to the route synthesis decision if
it does not conflict with known policy. Policy sensitive route
synthesis will prevent normally routed datagrams from utilizing
inappropriate resources. However, a datagram routed abnormally
due to unknown events or actions can always occur and the only
way to prohibit unwanted traffic from entering or leaving an
autonomous system is to provide policy enforcement within the
forwarding function.
知られている方針と衝突しないなら、ルート統合決定に応じて、データグラムを進めてください。 方針の敏感なルート統合は、通常、発送されたデータグラムが不適当なリソースを利用するのを防ぐでしょう。 しかしながら、未知の出来事か動きのため異常に発送されたデータグラムはいつも現れることができます、そして、自律システムを入るか、または残すのから求められていない交通を禁じる唯一の方法は推進機能の中で方針実施を提供することです。
Little [Page 6] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[6ページ]RFC1126相互自律システム
c) Do not forward datagrams to failed resources
c) 失敗したリソースにデータグラムを送らないでください。
A datagram is not to be forwarded to a resource known to be
unavailable, notably an intermediate system such as a gateway.
This implies some ability to detect and react to resource
failures.
入手できないのが知られているリソースにデータグラムを送ってはいけません、著しくゲートウェイなどの中間システム。 これはリソース失敗に検出して、反応する何らかの能力を含意します。
d) Forward datagram according to its characteristics
d) 特性に従った前進のデータグラム
The datagram forwarding function is to be sensitive to the
characteristics of the datagram in order to execute the
appropriate route synthesis decision. Characteristics to
consider are the destination, quality-of-service, precedence,
datagram (or user) policy, and security. Note that some
characteristics, precedence for example, affect the forwarding
service provided whereas others affect the path chosen.
データグラム推進機能は適切なルート統合決定を実行するためにデータグラムの特性に敏感であることです。 考える特性は、目的地と、サービスの質と、先行と、データグラム(または、ユーザ)方針と、セキュリティです。 いくつかの特性(例えば、先行)が推進サービスに影響するというメモは提供されましたが、他のものは選ばれた経路に影響します。
3.3 Information Requirements
3.3 情報要件
This functional area addresses the general information requirements of the routing environment. This encompasses both the nature and disbursal of routing information. The characteristics of the routing information and its disbursal are given by the following functional requirements.
この機能的な領域はルーティング環境の一般情報要件を記述します。 これは自然とルーティング情報のdisbursalの両方を取り囲みます。 以下の機能条件書はルーティング情報とそのdisbursalの特性を与えます。
a) Provide a distributed and descriptive information base
a) 分配されて描写的である情報ベースを供給してください。
The information base must not depend upon either centralization
or exact replication. The content of the information base must
be sufficient to support all provided routing functionality,
specifically that of route synthesis and forwarding.
Information of particular importance includes resource
characteristics and resource utilization policies.
情報ベースは中央集権化か正確な模写のどちらかによってはいけません。 情報ベースの内容は、機能性、明確にルート統合と推進のものを発送しながら提供されたすべてを支持するために十分でなければなりません。 特別に重要な情報はリソースの特性とリソース利用方針を含んでいます。
b) Determine resource availability
b) リソースの有用性を決定してください。
Provide a means of determining the availability of any utilized
resource in a timely manner. The timeliness of this
determination is dependent upon the routing service(s) to be
supported.
直ちにどんな利用されたリソースの有用性も決定する手段を提供してください。 この決断のタイムリーさであるのは支持されるべきルーティングサービスに依存しています。
c) Restrain transmission utilization
c) トランスミッション利用を抑制してください。
The dynamics of routing information flow should be such that a
significant portion of transmission resources are not consumed.
Routing information flow should adjust to the demands of the
environment, the capacities of the distribution facilities
utilized, and the desires of the resource manager.
消費されて、ルーティング情報流動の力学はトランスミッションリソースの重要な部分がないそのようなものであるべきです。 ルート設定情報流動は環境の要求、施設が利用した分配の能力、および資源管理プログラムの願望に適応するべきです。
Little [Page 7] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[7ページ]RFC1126相互自律システム
d) Allow limited information exchange
d) 限られた情報交換を許容してください。
Information distribution is to be sensitive to administrative
policies. An administrative policy may affect the content or
completeness of the information distributed. Additionally,
administrative policy may determine the extent of information
distributed.
情報流通は施政方針に敏感であることです。 施政方針は分配された情報の内容か完全性に影響するかもしれません。 さらに、施政方針は、情報の範囲が分配したことを決定するかもしれません。
3.4 Environmental Requirements
3.4 環境要件
The following items identify those requirements directly related to the nature of the environment within which routing is to occur.
以下の項目は直接ルーティングが起こることになっている環境の本質に関連するそれらの要件を特定します。
a) Support a packet-switching environment
a) パケット交換環境を支持してください。
The routing environment should be capable of supporting
datagram transfer within a packet-switched oriented networking
environment.
ルーティング環境はパケットで切り換えられた指向のネットワーク環境の中でデータグラム転送を支持できるべきです。
b) Accommodate a connection-less oriented user transport service
b) コネクションレスな指向のユーザ輸送サービスを収容してください。
The routing environment should be designed such that it
accommodates the model for connection-less oriented user
transport service.
ルーティング環境は、コネクションレスな指向のユーザ輸送サービスのためのモデルに対応するように、設計されるべきです。
c) Accommodate 10K autonomous systems and 100K networks
c) 10Kの自律システムと100Kのネットワークに対応してください。
This requirement identifies the scale of the internetwork
environment we view as appearing in the future. A routing
design which does not accommodate this order of magnitude is
viewed as being inappropriate.
この要件は私たちが将来現れると見なすインターネットワーク環境のスケールを特定します。 この桁を収容しないルーティングデザインは不適当であるとして見なされます。
d) Allow for arbitrary interconnection of autonomous systems
d) 自律システムの任意のインタコネクトを考慮してください。
The routing environment should accommodate interconnectivity
between autonomous systems which may occur in an arbitrary
manner. It is recognized that a practical solution is likely
to favor a given structure of interconnectivity for reasons of
efficiency. However, a design which does not allow for and
utilize interconnectivity of an arbitrary nature would not be
considered a feasible design.
ルーティング環境は任意の方法で起こるかもしれない自律システムの間に相互接続性を収容するべきです。 実際的な解決が効率の理由で相互接続性の与えられた構造を支持しそうであると認められます。 しかしながら、任意の自然の相互接続性を考慮して、利用しないデザインは可能なデザインであると考えられないでしょう。
3.5 General Objectives
3.5 一般目的
The following are overall objectives to be achieved by the inter- autonomous routing architecture and its protocols.
↓これは相互自治のルーティング構造とそのプロトコルによって達成されるべき総合的な目的です。
a) Provide routing services in a timely manner
a) 直ちにルーティングサービスを提供してください。
Little [Page 8] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[8ページ]RFC1126相互自律システム
Those routing services provided, encapsulated by the
requirements stated herein, are to be provided in a timely
manner. The time scale for this provision must be reasonable
to support those services provided by the internetwork
environment as a whole.
ここに述べられた要件によって要約されて、提供されたそれらのルーティングサービスは直ちに提供することです。 この支給のためのタイムスケールは全体でインターネットワーク環境によって提供されたそれらのサービスを支持するのが妥当であるに違いありません。
b) Minimize constraints on systems with limited resources
b) システムの上で限りある資源で規制を最小にしてください。
Allow autonomous systems, or gateways, of limited resources to
participate in the inter-autonomous system routing
architecture. This limited participation is not necessarily
without cost, either in terms of responsiveness, path
optimization, or other factor(s).
限りある資源の自律システム、またはゲートウェイを相互自律システムルーティング構造に参加させてください。 反応性、経路最適化、または他の要素に関してこの限られた参加は必ず費用なしでありません。
c) Minimize impact of dissimilarities between autonomous systems
c) 自律システムの間の相違点の影響を最小にしてください。
Attempt to achieve a design in which the dissimilarities
between autonomous systems do not impinge upon the routing
services provided to any autonomous system.
自律システムの間の相違点がどんな自律システムにも提供されたルーティングサービスに影響を与えないデザインを達成するのを試みてください。
d) Accommodate the addressing schemes and protocol mechanisms of
the autonomous systems
d) 自律システムのアドレシング計画とプロトコルメカニズムに対応してください。
The routing environment should accommodate the addressing
schemes and protocol mechanisms of autonomous systems, where
these schemes and mechanisms may differ among autonomous
systems.
ルーティング環境は自律システムのアドレシング計画とプロトコルメカニズムに対応するべきです。そこでは、これらの計画とメカニズムが自律システムの中で異なるかもしれません。
e) Must be implementable by network vendors
e) ネットワークによる実行可能が業者であったならそうしなければなりません。
This is to say that the algorithms and complexities of the
design must be such that they can be understood outside of the
research community and implementable by people other than the
designers themselves. Any feasible design must be capable of
being put into practice.
これは、デザインのアルゴリズムと複雑さが研究団体の外でそれらを理解できるようにものであるに違いないと言って、デザイナー以外の人々自身に実行可能されることになっています。 どんな可能なデザインも実行に移すことができなければなりません。
4. Non-Goals
4. 非目標
In view of the conflicting nature of many of the stated goals and the careful considerations and tradeoffs necessary to achieve a successful design, it is important to also identify those goals or functions which we are not attempting to achieve. The following items are not considered to be reasonable goals or functional requirements at this time and are best left to future efforts. These are non-goals, or non-requirements, within the context of the goals and requirements previously stated by this document as well as our interpretation of what can be practically achieved.
うまくいっているデザインを達成するのに必要な述べられた目標、慎重な問題、および見返りの多くの闘争本質から見て、また、それらの目標か私たちが獲得するのを試みていない機能を特定するのは重要です。 以下の商品をこのとき妥当な目標か機能条件書であることは考えられないで、今後の努力に残すのは最も良いです。 以前に実際に達成できることに関する私たちの解釈と同様にこのドキュメントによって述べられた目標と要件の文脈の中で、これらは、非目標、または非要件です。
Little [Page 9] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[9ページ]RFC1126相互自律システム
a) Ubiquity
a) 偏在
It is not a goal to design a routing environment in which any
participating autonomous system can obtain a routing service to
any other participating autonomous system in a ubiquitous
fashion. Within a policy sensitive routing environment, the
cooperation of intermediate resources will be necessary and
cannot be guaranteed to all participants. The concept of
ubiquitous connectivity will not be a valid one.
それはどんな参加自律システムも遍在しているファッションでいかなる他の参加自律システムに対するルーティングサービスも得ることができるルーティング環境を設計する目標ではありません。 方針の敏感なルーティング環境の中では、中間的リソースの協力は、必要であり、すべての関係者に保証できません。 遍在している接続性の概念は有効なものにならないでしょう。
b) Congestion control
b) 輻輳制御
The ability for inter-autonomous system routing to perform
congestion control is a non-requirement. Additional study is
necessary to determine what mechanisms are most appropriate and
if congestion control is best realized within the inter-AS
and/or intra-AS environments, and if both, what the dynamics of
the interactions between the two are.
相互自律システムルーティングが輻輳制御を実行する能力は非要件です。 追加研究が、どんなメカニズムが最も適切であるか、そして、輻輳制御が相互AS、そして/または、イントラ-AS環境、両方であるなら実現されたベスト、2つの間の相互作用の力学が何であるかということであるかどうか決定するのに必要です。
c) Load splitting
c) 負荷の分かれること
The functional capability to distribute the flow of datagrams,
from a source to a destination, across two or more distinct
paths through route synthesis and/or forwarding is a non-
requirement.
ルート統合、そして/または、推進で2つ以上の異なった経路の向こう側にデータグラムのソースから目的地までの流れを分配する機能的な能力は非要件です。
d) Maximizing the utilization of resources
d) リソースの利用を最大にします。
There is no goal or requirement for the inter-autonomous system
routing environment to be designed such that it attempts to
maximize the utilization of available resources.
ノー・ゴールか相互自律システムルーティング環境が利用可能資源の利用を最大にするのを試みるように設計されているという要件があります。
e) Schedule to deadline service
e) 締め切りのサービスへのスケジュール
The ability to support a schedule to deadline routing service
is a non-requirement for the inter-autonomous routing
environment at this point in time.
この時点で締め切りのルーティングサービスにスケジュールを支持する能力は相互自治のルーティング環境のための非要件です。
f) Non-interference policies of resource utilization
f) リソース利用の不干渉方針
The ability to support routing policies based upon the concept
of non-interference is a not a requirement. An example of such
a policy is one where an autonomous system allows the
utilization of excess bandwidth by external users as long as
this does not interfere with local usage of the link.
不干渉の概念に基づく方針を発送するのを支持する能力は要件ではなく、aです。 そのような方針に関する例はこれがリンクのローカルの使用法を妨げない限り、自律システムが社外利用者による余分な帯域幅の利用を許すものです。
Little [Page 10] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[10ページ]RFC1126相互自律システム
5. Considerations
5. 問題
Although neither a specific goal nor a functional requirement, consideration must be given to the transition which will occur from the current operational routing environment to a new routing environment. A coordinated effort among all participants of the Internet would be impractical considering the magnitude of such an undertaking. Particularly, the issues of transitional coexistence, as opposed to phased upgrading between disjoint systems, should be addressed as a means to minimize the disruption of service. Careful consideration should also be given to any required changes to hosts. It is very unlikely that all hosts could be changed, given historical precedence, their diversity and their large numbers.
どちらも明確な目標か機能条件書ですが、現在の操作上のルーティング環境から新しいルーティング環境まで起こる変遷に対して考慮を払わなければなりません。 そのような仕事の大きさを考える場合、インターネットのすべての関係者の中の連携努力は非実用的でしょう。 特に過渡的な共存の問題、段階的と対照的に、aが、サービスの分裂を最小にすることを意味するとき、間にアップグレードするのは、システムをばらばらにならせて、記述されるべきです。 また、ホストへのどんな必要な変化にも熟慮を与えるべきです。 歴史的な先行、彼らの多様性、および彼らの大きい番号を考えて、すべてのホストを変えることができたのは非常にありそうもないです。
Appendix - Issues in Inter-Autonomous Systems Routing
付録--相互自律システムルート設定における問題
A.0 Acknowledgement
A.0承認
This appendix is an edited version of the now defunct document entitled "Requirements for Inter-Autonomous Systems Routing", written by Ross Callon in conjunction with the members of the Open Routing Working Group.
この付録はオープンルート設定作業部会のメンバーに関連してロスCallonによって書かれた「相互自律システムルート設定のための要件」と題する現在死んでいるドキュメントの編集されたバージョンです。
A.1 Introduction
A.1序論
The information and discussion contained here historically precedes that of the main document body and was a major influence on its content. It is included here as a matter of reference and to provide insight into some of the many issues involved in inter-autonomous systems routing.
ここに含まれた情報と議論は、主な文書本体のものに歴史的に先行して、内容への主要な影響でした。 それは参照の問題としてここに含まれていました、そして、多くのいくつかに関する洞察を提供するために、問題は相互自律システムにルーティングにかかわりました。
The following definitions are utilized:
以下の定義は利用されています:
Boundary Gateway
境界ゲートウェイ
A boundary gateway is any autonomous system gateway which
has a network interface directly reachable from another
autonomous system. As a member of an autonomous system, a
boundary gateway participates in the Interior Gateway
Protocol and other protocols used for routing (and other
purposes) between other gateways of this same autonomous
system and between those networks directly reachable by this
autonomous system. A boundary gateway may also
participate in an Inter-Autonomous System Routing Protocol.
As a participant in the inter-autonomous system routing
protocol, a boundary gateway interacts with other boundary
gateways in other autonomous systems, either directly or
indirectly, in support of the operation of the
境界ゲートウェイはネットワーク・インターフェースを別の自律システムから直接届くようにするあらゆる自律システムゲートウェイです。 自律システムのメンバーとして、境界ゲートウェイはこの同じ自律システムの他のゲートウェイと、そして、この自律システムで直接届いているそれらのネットワークの間のルーティング(そして、他の目的)に使用されるInteriorゲートウェイプロトコルと他のプロトコルに参加します。 また、境界ゲートウェイはInter自治のSystemルート設定プロトコルに参加するかもしれません。 相互自律システムルーティング・プロトコルの関係者として、境界ゲートウェイは他の自律システムか直接か間接的に操作を支持して他の境界ゲートウェイと対話します。
Little [Page 11] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[11ページ]RFC1126相互自律システム
Inter-Autonomous System Routing Protocol.
相互自律システムルーティング・プロトコル。
Interior Gateway
内部のゲートウェイ
An interior gateway is any autonomous system gateway which
is not a boundary gateway. As such, an interior gateway
does not have any network interfaces which are directly
reachable by any other autonomous system. An interior
gateway is part of an autonomous system and, as such,
takes part in the Interior Gateway Protocol and other
protocols used in that autonomous system. However, an
interior gateway does not directly exchange routing
information with gateways in other autonomous systems via
the Inter-Autonomous System Routing Protocol.
内部のゲートウェイは境界ゲートウェイでないあらゆる自律システムゲートウェイです。 そういうものとして、内部のゲートウェイには、少しのいかなる他の自律システムでも直接届いているネットワーク・インターフェースもありません。 内部のゲートウェイは、自律システムの一部であり、そういうものとしてその自律システムで使用されるInteriorゲートウェイプロトコルと他のプロトコルに参加します。 しかしながら、内部のゲートウェイはInter自治のSystemルート設定プロトコルで他の自律システムのゲートウェイと直接ルーティング情報を交換しません。
The following acronyms are used:
以下の頭文字語は使用されています:
AS -- Autonomous System
--、自律システム
This document uses the current definition of "Autonomous
System": a collection of cooperating gateways running a
common interior routing protocol. This implies that networks
and hosts may be reachable through one or more Autonomous
Systems.
このドキュメントは「自律システム」の現在の定義を使用します: 一般的な内部のルーティング・プロトコルを走らせる協力ゲートウェイの収集。 これは、ネットワークとホストに1Autonomous Systemsを通して届くかもしれないのを含意します。
NOTE: The current notion of "Autonomous System" implicitly
assumes that each gateway will belong to exactly one AS.
Extensions to allow gateways which belong to no AS's
and/or gateways which belong to multiple AS's, are beyond
the scope of this discussion. However, we do not preclude
the possibility of considering such extensions in the
future.
以下に注意してください。 「自律システム」の現在の概念は、各ゲートウェイがちょうど1ASに属すとそれとなく仮定します。 ASのものがないのに属すゲートウェイ、そして/または、ASの複数のものに属すゲートウェイを許容する拡大はこの議論の範囲を超えたそうです。 しかしながら、私たちは将来そのような拡大を考える可能性を排除しません。
IARP -- Inter-Autonomous System Routing Protocol
IARP--相互自律システムルーティング・プロトコル
This is the protocol used between boundary gateways for
the purpose of routing between autonomous systems.
これは自律システムの間のルーティングの目的に境界ゲートウェイの間で使用されるプロトコルです。
IGP -- Interior Gateway Protocol
IGP--内部のゲートウェイプロトコル
This is the protocol used within an autonomous system for
routing within that autonomous system.
これはその自律システムの中のルーティングに自律システムの中で使用されたプロトコルです。
A.2 Architectural Issues
A.2構造的な問題
The architecture of an inter-autonomous system routing environment is mutually dependent with the notion of an Autonomous System. In general, the architecture should maximize independence of the
相互自律システムルーティング環境の構造はAutonomous Systemの概念について互いに依存しています。 一般に、構造は独立を最大にするべきです。
Little [Page 12] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[12ページ]RFC1126相互自律システム
internals of an AS from the internals of other AS's, as well as from the inter-autonomous system routing protocols (IARP). This independence should allow technological and administrative differences among AS's as well as protection against propagation of misbehavior. The following issues address ways to achieve interoperation and protection, and to meet certain performance criteria. We also put forth a set of minimal constraints to be imposed among Autonomous Systems, and between inter- and intra-AS functions.
他のASのインターナルと、相互自律システムルーティング・プロトコルからのAS(IARP)のインターナル。 この独立は不正行為の伝播に対する保護と同様にASのところに技術的で管理の違いを許容するべきです。 以下の問題はinteroperationと保護を達成して、あるパフォーマンス基準を満たす方法を記述します。 そして、また、私たちがAutonomous Systemsの中と間に課されるという1セットの最小量の規制を差し出す、相互、イントラ-ASは機能します。
A.2.1 IGP Behavior
A.2.1 IGPの振舞い
The IARP should be capable of tolerating an Autonomous System in which its IGP is unable to route packets, provides incorrect information, and exhibits unstable behavior. Interfacing to such an ill-behaved AS should not produce global instabilities within the IARP and the IARP should localize any effects. On the other hand, the IGP should provide a routing environment where the information and connectivity provided to the IARP from the IGP does not exhibit rapid and continual changes. An Autonomous System therefore should appear as a relatively stable environment.
IARPはIGPがパケットを発送できないで、不正確な情報を提供して、不安定な振舞いを示すAutonomous Systemを許容できるべきです。 そのような無作法なASに連結するのはIARPの中で世界的な不安定を生産するべきではありません、そして、IARPはどんな効果も局部にとどめるはずです。 他方では、IGPは情報と接続性がIARPに供給したIGPが示さないルーティング環境に急速で絶え間ない変化を供給するはずです。 したがって、Autonomous Systemは比較的安定した環境として現れるはずです。
A.2.2 Independence of Autonomous Systems
自律システムからのA.2.2独立
The IARP should not constrain any AS to require the use any one specific IGP. This applies both to IGPs and potentially to any other internal protocols. The architecture should also allow intra-AS routing and organizational structures to be hidden from inter-AS use. An Autonomous System should not be required to use any one specific type of linkage between boundary gateways within the AS. However, there are some minimal constraints that gateways and the associated interior routing protocol within an AS must meet in order to be able to route Inter-AS traffic, as discussed in Section A.2.6.
IARPは、どんなASも使用を必要とするのを抑制するはずがありません。どんな特定のIGP。 これは潜在的にいかなる他の内部のプロトコルにもIGPsへの両方を適用します。 また、構造で、イントラ-ASルーティングと組織体制を相互AS使用から隠すべきです。 ASの中で境界ゲートウェイの間のどんな特定のタイプのリンケージも使用するためにAutonomous Systemを必要とするべきではありません。 しかしながら、ゲートウェイとASの中の関連内部のルーティング・プロトコルがInter-AS交通を発送できるように触れなければならないといういくつかの最小量の規制があります、セクションA.2.6で議論するように。
A.2.3 General Topology
A.2.3の一般トポロジー
The routing architecture should provide significant flexibility regarding the interconnection of AS's. The specification of IARP should impose no inherent restriction on either interconnection configuration or information passing among autonomous systems. There may be administrative and policy limitations on the interconnection of AS's, and on the extent to which routing information and data traffic may be passed between AS's. However, there should be no inherent restrictions imposed by limitations in the design of the routing architecture. The architecture should allow arbitrary topological interconnection of Autonomous Systems. Propagation of routing information should not be restricted by the specification of the IARP. For example, the restrictions imposed by the "core model"
ルーティング構造はASのインタコネクトに関して重要な柔軟性を提供するべきです。 IARPの仕様は自律システムの中で終わるインタコネクト構成か情報のどちらかにどんな固有の制限も課すべきではありません。ASのインタコネクトの上と、そして、ASのものがルーティング情報とデータ通信量で渡されるかもしれない範囲の上に管理と方針制限があるかもしれません。 しかしながら、ルーティング構造のデザインにおける制限で課されたどんな固有の制限もあるべきではありません。 構造はAutonomous Systemsの任意の位相的なインタコネクトを許すべきです。IARPの仕様はルーティング情報の伝播を制限するべきではありません。 例えば、制限は「コアモデル」ででしゃばりました。
Little [Page 13] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[13ページ]RFC1126相互自律システム
used by EGP are not acceptable.
使用されて、EGPは許容できません。
A.2.4 Routing Firewalls
A.2.4ルート設定ファイアウォール
We expect AS's to have a certain amount of insulation from other AS's. This protection should apply to both the adequacy and stability of routes produced by the routing scheme, and also to the amount of overhead traffic and other costs necessary to run the routing scheme. There are several forms which these "routing firewalls" may take:
私たちは、ASのものにはASの他のものからのある量の断熱材があると予想します。 この保護はルーティング計画によって生産された妥当性とルートの安定性の両方と、そして、ルーティング計画を走らせるのに必要なオーバーヘッド・トラヒックと他のコストの量にも適用されるべきです。 これらの「ルーティングファイアウォール」が取るかもしれない数個の形があります:
- An AS must be able to successfully route its own internal
traffic in the face of arbitrary failures of other IGPs and the
IARP. In other words, the AS should be able to effectively
shutout the rest of the world.
- ASは他のIGPsとIARPの任意の失敗に直面して首尾よくそれ自身の国内取引を発送できなければなりません。 言い換えれば、ASは事実上締め出しにできるべきです。他の国々。
- The IARP should be able to operate correctly in the face of IGP
failures. In this case, correct operation is defined as
recognizing that an AS has failed, and routing around it if
possible (traffic to or from that AS may of course fail).
- IARPはIGPの故障に直面して正しく作動するはずであることができます。 この場合、正しい操作はASが失敗したと認めて、できれば、それの周りで掘ると定義されます(ASかそのASからの交通はもちろん失敗するかもしれません)。
- In addition, problems in Inter-AS Routing should, as much as
possible, be limited in the extent of their effect.
- さらに、Inter-ASルート設定における問題の彼らの効果の程度はできるだけ限られているべきです。
Routing firewalls may be explicit, or may be inherent in the design of the algorithms. We expect that both explicit and inherent firewalls will be utilized. Examples of firewalls include:
ルート設定ファイアウォールは、明白であるかもしれないか、またはアルゴリズムの設計固有であるかもしれません。私たちは、明白なものと同様に固有のファイアウォールが利用されると予想します。 ファイアウォールに関する例は:
- Separating Intra- and Inter-AS Routing to some extent
isolates each of these from problems with the other. Clearly
defined interfaces between different modules/protocols provides
some degree of protection.
- IntraとInter-ASルート設定を切り離すと、それぞれのこれらはもう片方に関する問題からある程度隔離されます。 異なったモジュール/プロトコルの間の明確に定義されたインタフェースは保護をいくらかの提供します。
- Access control restrictions may provide some degree of
firewalls. For example, some AS's may be non-transit (won't
forward transit traffic). Failures within such AS's may be
prevented from affecting traffic not associated with that AS.
- アクセス管理制限はいくらかのファイアウォールを提供するかもしれません。 例えば、ASの何らかのものが非トランジットであるかもしれません(トランジット交通を進めないでしょう)。 ASのそのようなところの中の失敗はそのASに関連づけられなかった交通に影響するのが防がれるかもしれません。
- Protocol design can help. For example, with link state routing
you can require that both ends must report a link before is may
be regarded as up, thereby eliminating the possibility of a
single node causing fictitious links.
- プロトコルデザインは助けることができます。 例えば、両端が以前リンクを報告しなければならないのによる上がって、その結果、排泄していると見なされて、ただ一つのノードが架空で引き起こす可能性がリンクされるということであるかもしれないというあなたが必要とすることができるリンク州のルーティングによる、ことです。
- Finally, explicit firewalls may be employed using explicit
configuration information.
- 最終的に、明白なファイアウォールは、明白な設定情報を使用することで使われるかもしれません。
Little [Page 14] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[14ページ]RFC1126相互自律システム
A.2.5 Boundary Gateways
A.2.5境界ゲートウェイ
Boundary gateways will exchange Inter-AS Routing information with other boundary gateways using the IARP. Each AS which is to take part in Inter-AS Routing will have one or more boundary gateways, of which one or more of these boundary gateways exchanges information with peer boundary gateways in other AS's.
境界ゲートウェイは、IARPを使用することで他の境界ゲートウェイとInter-ASルート設定情報を交換するでしょう。 Inter-ASルート設定に参加することになっている各ASがASの他のところにこれらの境界ゲートウェイのどの1つ以上が同輩境界ゲートウェイで情報交換するかに関する1境界門以上を持つでしょう。
Information related to Inter-AS Routing may be passed between connected boundary gateways in different AS's. Specific designated boundary gateways will therefore be required to understand the IARP. The external link between the boundary gateways may be accomplished by any kind of connectivity that can be modeled as a direct link between two gateways -- a LAN, an ARPANET, a satellite link, a dedicated line, and so on.
Information related to Inter-AS Routing may be passed between connected boundary gateways in different AS's. したがって、特定の指定された境界ゲートウェイはIARPを理解しなければならないでしょう。 境界ゲートウェイの間の外部のリンクは2門の間の直リンクとしてモデル化できるどんな種類の接続性によっても達成されるかもしれません--LAN、アルパネット、衛星中継、専用線など。
A.2.6 Minimal Constraints on the Autonomous System
自律システムにおけるA.2.6の最小量の規制
The architectural issues discussed here for inter-AS routing imply certain minimal functional constraints that an AS must satisfy in order to take part in the Inter-AS Routing scheme. These minimal requirements are described in greater detail in this section. This list of functional constraints is not necessarily complete.
相互ASルーティングのためにここで議論した構造的な問題はASがInter-ASルート設定計画に参加するために満足させなければならないというある最小量の関数制約条件を含意します。 これらの最小量の要件はこのセクションで詳細によりすばらしい説明されます。 関数制約条件のこのリストは必ず完全であるというわけではありません。
A.2.6.1 Internal Links between Boundary Gateways
境界ゲートウェイの間のA.2.6.1の内部のリンク
In those cases where an AS may act as a transit AS (i.e., may pass traffic for which neither the source nor the destination is in that AS), the gateways internal to that AS will need to know which boundary gateway is to serve as the exit gateway from that AS. There are several ways in which this may be accomplished:
ASがトランジットとしてAS(すなわち、ソースも目的地もそのASにない交通を通り過ぎるかもしれない)、それへの内部のゲートウェイを機能させるかもしれないASがどの境界ゲートウェイが出口ゲートウェイとしてそのASから機能することになっているかを知るために必要とするそれらの場合で。 これが達成されるかもしれないいくつかの方法があります:
1. Boundary gateways are directly connected
1. 境界ゲートウェイは直接接続されます。
2. "Tunneling" (i) using source routing (ii) using encapsulation
2. (i) カプセル化を使用することでソースルーティング(ii)を使用することで「トンネル」です。
3. Interior gateways participate (i) limited participation (ii)
fully general participation
3. 内部のゲートウェイが関与する、(i)が参加(ii)を完全に制限した、一般的な参加
With solution (1), the boundary gateways in an AS are directly connected. This eliminates the need for other gateways in the AS to have any knowledge of Inter-AS Routing. Transit traffic is passed directly among the boundary gateways of the AS.
解決策(1)と、ASの境界ゲートウェイは直接接続されます。 これはASの他のゲートウェイにはInter-ASルート設定に関するどんな知識もある必要性を排除します。 トランジット交通はASの境界ゲートウェイの直接中を流れます。
With solution (2), transit traffic may traverse interior gateways, but these interior gateways are protected from any need to have knowledge about Inter-AS routes by means such as source routing or encapsulation. The boundary gateway by which the packet enters an AS
解決策(2)で、トランジット交通は内部のゲートウェイを横断するかもしれませんが、これらの内部のゲートウェイはInter-ASルートの周りでソースルーティングかカプセル化などの手段で心得があるどんな必要性からも保護されます。 パケットがASに入る境界ゲートウェイから
Little [Page 15] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[15ページ]RFC1126相互自律システム
determines the boundary gateway which will serve as the exit gateway. This may require that the entrance boundary gateway add a source route to the packet, or encapsulate the packet in another level of IP or gateway-to-gateway header. This allows boundary gateways to forward data traffic using the appropriate tunnelling technique.
出口ゲートウェイとして機能する境界ゲートウェイを決定します。 これは、入り口の境界ゲートウェイがパケットに送信元経路を加えるか、または別のレベルのIPかゲートウェイからゲートウェイへのヘッダーでパケットをカプセルに入れるのを必要とするかもしれません。 これで、境界ゲートウェイは、適切なトンネルのテクニックを使用することでデータ通信量を進めることができます。
Finally, with solution (3), the interior gateways have some knowledge of Inter-AS Routing. At a minimum, the interior gateways would need to know the identity of each boundary gateway, the address(es) that can be reached by that gateway, and the Inter-AS metric associated with the route to that address(es). If the IARP allows for separate routing for multiple TOS classes, then the information that the interior gateways need to know includes a separate Inter-AS metric for each TOS class. The Inter-AS metrics are necessary to allow gateways to choose among multiple possible exit boundary gateways. In general, it is not necessary for the Inter-AS metrics to have any relationship with the metric used within an AS for interior routing. The interior gateways do not need to know how to interpret the exterior metrics, except to know that each metric is to be interpreted as an unsigned integer and a lesser value is preferable to a greater value. It would be possible, but not necessary, for the interior gateways to have full knowledge of the IARP.
最終的に、内部のゲートウェイには、解決策(3)によって、Inter-ASルート設定に関する何らかの知識があります。 最小限では、内部のゲートウェイは、それぞれの境界ゲートウェイのアイデンティティを知る必要があって、そのゲートウェイ、およびInter-ASがメートル法で達することができるアドレス(es)はそのアドレス(es)へのルートと交際しました。 IARPが複数のTOSのクラスに関して別々のルーティングを考慮するなら、内部のゲートウェイが、知る必要があるという情報はそれぞれのTOSのクラスにおける、メートル法の別々のInter-ASを含んでいます。 Inter-AS測定基準が、ゲートウェイが複数の可能な出口境界ゲートウェイの中で選ぶのを許容するのに必要です。 一般に、Inter-AS測定基準には内部のルーティングにASの中で使用されるメートル法とのどんな関係もあるのは必要ではありません。 内部のゲートウェイは外の測定基準を解釈する方法を知る必要はありません、それぞれメートル法であることが、符号のない整数として解釈されることであり、より大きい値より少ない値が望ましいのを知るのを除いて。 可能ですが、IARPに関する完全な知識を持つのは、内部のゲートウェイに必要でないでしょう。
It is not necessary for the Inter-AS Routing architecture to specify which of these solutions are to be used for any particular AS. Rather, it is possible for individual AS's to choose which scheme or combination of schemes to use. Independence of the IARP from the internal operation of each AS implies that this decision be left up to the internal protocols used in each AS. The IARP must be able to operate as if the boundary gateways were directly connected.
Inter-ASルート設定構造が、これらの解決策のどれが何か特定のASに使用されるかことであるかと指定するのは必要ではありません。 むしろ、個々のASのものが、計画のどの計画か組み合わせを使用したらよいかを選ぶのは、可能です。 それぞれのASの内部の操作からのIARPからの独立は、この決定が各ASで使用される内部のプロトコルに任せられるのを含意します。 まるで境界ゲートウェイが直接接続されるかのようにIARPは作動できなければなりません。
A.2.6.2 Forwarding of Data from the AS
データのA.2.6.2推進
The scheme used for forwarding transit traffic across an AS also has implications for the forwarding of traffic which originates within an AS, but whose destination is reachable only from other AS's. If either of solutions (1) or (2) in Section A.2.6.1 is followed, then it will be sufficient for an interior gateway to forward such traffic to any boundary gateway. Greater efficiency may optionally be achieved in some cases by providing interior gateways with additional information which will allow them to choose the "best" boundary gateway in some sense. If solution (3) is followed, then the information passed to interior gateways to allow them to forward transit traffic will also be sufficient to forward traffic originating within that AS.
また、推進トランジット交通にASの向こう側に使用される計画は由来しますが、目的地がASの中でASの他のものだけから届いている交通の推進のための意味を持っています。 セクションA.2.6.1の解決策(1)か(2)のどちらかが続かれているなら、内部のゲートウェイがどんな境界ゲートウェイにもそのような交通を送るのは、十分です。 いくつかの場合、大効率は、彼らが何らかの意味における「最も良い」境界ゲートウェイを選ぶことができる追加情報を内部のゲートウェイに提供することによって、任意に達成されるかもしれません。 また、解決策(3)が従われているなら、トランジット交通を進めるのを許容するために内部のゲートウェイに通過された情報も、そのASの中で由来する交通を進めるために十分です。
Little [Page 16] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[16ページ]RFC1126相互自律システム
A.2.6.3 Forwarding of Data to a Destination in the AS
中の目的地へのデータのA.2.6.3推進
If a packet whose destination is reachable from an AS arrives at that AS, then it is desired that the interior routing protocol used in that AS be able to successfully deliver the packet without reliance on Inter-AS Routing. This does not preclude that the Inter-AS Routing protocol will deal with partitioned AS's.
目的地がASから届いているパケットがそのASに到着するなら、そのASで使用される内部のルーティング・プロトコルがInter-ASルート設定への信用なしでパケットを首尾よく届けることができることが望まれています。 これはそれを排除しません。Inter-ASルート設定プロトコルは仕切られたASのものに対処するでしょう。
An AS may have access control, security, and policy restrictions that restrict which data packets may enter or leave the AS. However, for any data packet which is allowed access to the AS, the AS is expected to deliver the packet to its destination without further restrictions between parts of the AS. In this sense, the internal structure of the AS should not be visible to the IARP.
ASには、パケットがASを入れるか、または残すかもしれないどのデータを制限するアクセス管理、セキュリティ、および方針制限があるかもしれません。 しかしながら、ASへのアクセスが許されているどんなデータ・パケットに関しても、ASがASの部分の間でさらなる制限なしでパケットを送付先に届けると予想されます。 この意味で、ASの内部の構造はIARPに目に見えるべきではありません。
A.3 Policy Issues
A.3政策問題
The interconnection of multiple heterogeneous networks and multiple heterogeneous autonomous systems owned and operated by multiple administrations into a single combined internet is a very complex task. It is expected that the administrations associated with such an internet will wish to impose a variety of constraints on the operation of the internet. Specifically, externally imposed routing constraints may include a variety of transit access control, administrative policy, and security constraints.
ただ一つの結合したインターネットへの複数の政権によって所有されて、運用された複数の異機種ネットワークと複数の異種の自律システムのインタコネクトは非常に複雑なタスクです。 そのようなインターネットに関連している政権がさまざまな規制をインターネットの操作に課したくなると予想されます。 明確に、外部的に課されたルーティング規制はさまざまなトランジットアクセス管理、施政方針、およびセキュリティ規制を含むかもしれません。
Transit access control refers to those access control restrictions which an AS may impose to restrict which traffic the AS is willing to forward. There are a large number of access control restrictions which one could envision being used. For example, some AS's may wish to operate only as "non-transit" AS's, that is, they will only forward data traffic which either originates or terminates within that AS. Other AS's may restrict transit traffic to datagrams which originate within a specified set of source hosts. Restrictions may require that datagrams be associated with specific applications (such as electronic mail traffic only), or that datagrams be associated with specific classes of users.
トランジットアクセス管理はASが進めても構われないASが思っているどの交通を制限するかために課すかもしれないそれらのアクセス管理制限を示します。 1つが思い描くことができた使用される多くのアクセス管理制限があります。 例えば、ASの何らかのものが単に「非トランジット」ASのものとして作動したがっているかもしれません、すなわち、彼らはそのASの中で由来するか、または終わるデータ通信量を進めるだけでしょう。 ASの他のものはトランジット交通を指定されたセットの送信元ホストの中で由来するデータグラムに制限するかもしれません。 制限は、データグラムが特定のアプリケーション(電子メール交通だけなどの)に関連しているか、またはデータグラムが特定のクラスのユーザに関連しているのを必要とするかもしれません。
Policy restrictions may allow either the source of datagrams, or the organization that is paying for transmission of a datagram, to limit which AS's the datagrams may transit. For example, an organization may wish to specify that certain traffic originating within their AS should not transit any AS administered by its main competitor.
方針制限はデータグラムのトランスミッションの代価を払っているデータグラムの源か組織のどちらかを許すかもしれなくて、ASのどのものを制限するかために、データグラムはトランジットがそうするかもしれません。 例えば、組織はどんなASも主な競合相手で管理したトランジットではなく、それらのASの中で由来するのがそうするべきであるそのある一定の交通を指定したがっているかもしれません。
Security restrictions on traffic relates to the official security classification level of traffic. As an example, an AS may specify that all classified traffic is not allowed to leave its AS.
交通の安全保障制限は公式のセキュリティ分類レベルの交通に関連します。 例として、ASは、すべての分類された交通がASを残すことができないと指定するかもしれません。
Little [Page 17] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[17ページ]RFC1126相互自律システム
The main problem with producing a routing scheme which is sensitive to transit access control, administrative policy, and security constraints is the associated potential for exponential growth of routes. For example, suppose that there are 20 packets arriving at a particular gateway, each for the same destination, but subject to a different combination of access control, policy, and security constraints. It is possible that all 20 packets would need to follow different routes to the destination.
トランジットアクセス管理、施政方針、およびセキュリティ規制に敏感なルーティング計画を作成することに関する主な問題はルートの急激な増加の関連可能性です。 例えば、特定のゲートウェイに到着する20のパケットがあると仮定してください、それぞれ同じ目的地、アクセス管理の異なった組み合わせへの対象だけ、方針、およびセキュリティ規制のために。 すべての20のパケットが、異なったルートに目的地に従う必要があるのは、可能です。
This explosive growth of routes leads to the question: "Is it practically feasible to deal with complete general external routing constraints?" One approach would allow only a smaller subset of constraints, chosen to provide some useful level of control while allowing minimal impact on the routing protocol. Further work is needed to determine the feasibility of this approach.
ルートのこの爆発的成長は質問につながります: 「完全な一般的な外部のルーティング規制に対処するのは実際に可能ですか?」 1つのアプローチがルーティング・プロトコルへの最小量の影響を許容している間の何らかの役に立つ管理水準を提供するために選ばれた規制の、より小さい部分集合だけを許容するでしょう。 さらなる仕事が、このアプローチに関する実現の可能性を決定するのに必要です。
There is another problem with dealing with transit access control, policy, and security restrictions in a fully general way. Specifically, it is not clear just what the total set of possible restrictions should be. Efforts to study this issue are currently underway, but are not expected to produce definitive results within a short to medium time frame. It is therefore not practical to wait for this effort to be finished before defining the next generation of Inter-AS Routing.
トランジットアクセス管理に対処することに関する別の問題、方針、および安全保障制限が完全に一般的な方法であります。 明確に、可能な制限の全体集合がちょうど何であるべきであるかが明確ではありません。 この問題を研究するための努力は、現在、進行中ですが、ショートの中で中型の時間枠に決定的な結果を生まないと予想されます。 したがって、Inter-ASルート設定の次世代を定義する前に終わっているためのこの努力を待つのは実用的ではありません。
A.4 Service Features
A.4サービス機能
The following paragraphs discuss issues concerning the services an Inter-AS Routing Protocol may provide. This is not a complete list of service issues but does address many of those services which are of concern to a significant portion of the community.
以下のパラグラフはInter-ASルート設定プロトコルが提供するかもしれないサービスに関して問題について議論します。 これは、サービス問題に関する全リストではありませんが、共同体の重要な部分に重要なそれらのサービスの多くを扱います。
A.4.1 Cost on Toll Networks
トールダイヤル網のA.4.1費用
Consideration must be given to the use of routing protocols with toll (i.e., charge) networks. Although uncommon in the Internet at the moment, they will become more common in the future, and thought needs to be given to allowing their inclusion in an efficient and effective manner.
料金(すなわち、充電)ネットワークによるルーティング・プロトコルの使用に対して考慮を払わなければなりません。 現在、インターネットで珍しいです、将来より一般的になるでしょう、そして、考えは効率的で効果的な方法での彼らの包含を許容するのに与えられている必要がありますが。
There are two areas in which concerns of cost intrude. First, provision must be made to include in the routing information distributed throughout the system the information that certain links cost money, so that traffic patterns may account for the cost. Second, the actual operation of the algorithm, in terms of the messages that must be exchanged to operate the algorithm, must recognize that fact that on certain links, the exchange may have an associated cost which must be taken into account. These areas often
費用の関心に立ち入る2つの領域があります。 まず最初に、ルーティングにシステム中で分配されて、リンクが金がかかっているのでそのトラフィックが型に基づいて作るのをそんなに確信している情報が費用を説明するかもしれないという情報を含んでいるのを設備をしなければなりません。 2(アルゴリズムを操作するために交換しなければならないメッセージに関するアルゴリズムの実際の運営)番目はあるリンクの上では、交換が考慮に入れなければならない関連費用を持っているかもしれないというその事実を認識しなければなりません。 これらの領域、しばしば
Little [Page 18] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[18ページ]RFC1126相互自律システム
involve policy questions on the part of the user. It is a requirement of the algorithm that facilities be available to allow different groups to answer these questions in different ways. The first area is related to type-of-service routing, and is discussed in Section A.4.2. The second area is discussed below.
ユーザ側の方針質問にかかわってください。 それは施設が異なったグループが異なった方法でこれらの質問に答えるのを許容するために利用可能であるというアルゴリズムの要件です。 最初の領域について、サービスのタイプルーティングに関連して、セクションA.4.2で議論します。 以下で2番目の領域について議論します。
Previous attempts at providing these sorts of controls were incomplete because they were not thought through fully; a new effort must avoid these pitfalls. For instance, even though the Hello rate in EGP may be adjusted, turning the rate down too low (to control the costs) could cause the route to be dropped from databases through timeout.
それらが突き抜けると完全に考えられたというわけではないので、これらの種類のコントロールを提供することへの前の試みは不完全でした。 新しい取り組みはこれらの落とし穴を避けなければなりません。 例えば、EGPのHelloレートは調整されるかもしれませんが、あまりに低いこと(コストを制御する)にレートを拒絶するのに、データベースからタイムアウトでルートを下げることができるでしょう。
In a large internet, changes will be occurring constantly; a simplistic mechanism might mean that a site which is only connected by toll networks has to either accept having an old picture of the network, or spend more to keep a more current picture of things. However, that is not necessarily the case if incomplete knowledge and cache-based techniques are used more. For instance, if a site connected only by toll links keeps an incomplete or less up-to-date map of the situation, an agreement with a neighbor which does not labor under these restrictions might allow it to get up-to-date information only when needed.
大きいインターネットでは、変化は絶えず起こるでしょう。 安易なメカニズムは、トールダイヤル網によってつなげられるだけであるサイトがネットワークの古い画像を持ちながら受け入れなければならないか、またはものの、より現在の画像を保つためにさらに費やされなければならないことを意味するかもしれません。 しかしながら、不完全な知識とキャッシュベースのテクニックがさらに使用されるなら、それは必ずそうであるというわけではありません。 例えば、料金リンクだけによってつなげられたサイトが状況の不完全であるかそれほど最新でない地図を保管するなら、隣人とのこれらの制限で働かない協定で、必要である場合にだけ、それは最新情報を得ることができるかもしれません。
A.4.2 Type-of-Service Routing
A.4.2サービスのタイプルート設定
The need for type-of-service (TOS) has been increasing as networks become more heterogeneous in physical channel components, high-level applications, and administrative management. For instance, some recently installed fiber cables provide abundant communication bandwidths, while old narrow-band channels will still be with us for a long time period. Electronic mail traffic tolerates delivery delays and low throughput. New image transmissions are coming up; these require high bandwidths but are not effected by a few bit errors. Furthermore, some networks may soon install accounting functions to charge users, while others may still provide free services.
ネットワークが物理的なチャンネル成分、ハイレベルのアプリケーション、および行政運営において、より異種になるのに従って、サービスのタイプ(TOS)の必要性は大きくなっています。 例えば、ケーブルが古い狭周波数帯が精神を集中する間の豊富なコミュニケーション帯域幅を供給するいくつかの最近インストールされたファイバーが長い間、期間にまだ私たちと共になっているでしょう。 電子メールトラフィックは配送遅れと少ないスループットを許容します。 新しい映像電送は来ています。 これらは、高帯域を必要としますが、いくつかの噛み付いている誤りで作用しません。 その上、いくつかのネットワークがすぐ、ユーザを請求するために会計機能をインストールするかもしれませんが、他のものはまだ無料奉仕を提供しているかもしれません。
Considering the long life span of a new routing architecture, it is mandatory that it be built with mechanisms to provide TOS routing. Unfortunately, we have had very little experience with TOS routing, even with a single network. No TOS routing system has ever been field-tested on a large-scale basis.
新しいルーティングアーキテクチャの長寿の長さを考える場合、ルーティングをTOSに供給するのはそれがメカニズムで建てられるのが義務的です。 残念ながら、私たちには、TOSルーティングと、ただ一つのネットワークさえの経験がほとんどありません。 TOSルーティングシステムは全く今までに、大規模ベースで実地試験されたことがありません。
We foresee the need for TOS routing and recognize the possible complexities and difficulties in design and implementation. We also consider that new applications coming along may require novel services that are unforeseeable today. We feel a practical approach
私たちは、TOSルーティングの必要性について見通して、設計と実装における可能な複雑さと困難を認めます。 また、私たちは、やって来る新しいアプリケーションが今日「非-予見でき」な目新しいサービスを必要とするかもしれないと考えます。 私たちは実践的なアプローチを感じます。
Little [Page 19] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[19ページ]RFC1126相互自律システム
is to provide a small set of TOS routing functions as a first step while the design of the architecture should be such that new classes of TOS can be easily added later and incrementally deployed. The Inter-AS Routing Architecture should allow both globally and locally defined TOS classes.
アーキテクチャのデザインが容易にTOSの新しいクラスを加えることができるようにものであるべきですが、第一歩が後で、そして増加して展開したので、小さいTOS経路選択機能を提供することになっています。 ルート設定Architectureがグローバルに局所的に許容するはずであるInter-ASはTOSのクラスを定義しました。
We intend to address TOS routing based on the following metrics:
私たちは、TOSが以下の測定基準に基づくルーティングであると扱うつもりです:
- Delay
- 遅れ
- Throughput
- スループット
- Cost
- 費用
Delay and throughput are the main network performance concerns. Considering that some networks may soon start charging users for the transmission services provided, the cost should also be added as a factor in route selection.
遅れとスループットは主なネットワーク性能関心です。 いくつかのネットワークが、すぐトランスミッションサービスのためにユーザを請求するのを出発するかもしれないと考えるのを提供されました、また、費用はルート選択の要素として加えられるべきです。
Reliability is not included in the above list. Different applications with different reliability requirements will differ in terms of what Transport Protocol they use. However, IP offers only a "moderate" level of reliability, suitable to applications such as voice, or possibly even less than that required by voice. The level of reliability offered by IP will not differ substantially based on the application. Thus the requested level of reliability will not affect Inter-AS Routing.
信頼性は上記のリストに含まれていません。 異なった信頼度要求事項がある異なったアプリケーションはそれらが使用するすべてのTransportプロトコルで異なるでしょう。 しかしながら、IPは「中道主義者」のレベルの信頼性だけを提供します、声などのアプリケーションに適しているか、またはそれことによると以下さえ声が必要です。 IPによって提供された信頼性のレベルはアプリケーションに基づいて実質的に異ならないでしょう。 したがって、要求されたレベルの信頼性はInter-ASルート設定に影響しないでしょう。
Delay and throughput will be measured from the physical characteristics of communication channels, without considering instantaneous load. This is necessary in order to provide stable routes, and to minimize the overhead caused by the Inter-AS Routing scheme.
瞬時に起こっている負荷を考えないで、遅れとスループットは通信チャネルの物理的な特性から測定されるでしょう。 これが、安定したルートを提供して、Inter-ASルート設定体系によって引き起こされたオーバーヘッドを最小にするのに必要です。
A number of TOS service classes may be defined according to these metrics. Each class will present defined requirements for each of the TOS metrics. For example, one class may require low delay, require only low throughput, and require low cost.
これらの測定基準に従って、多くのTOSサービスのクラスが定義されるかもしれません。 各クラスはそれぞれに関するTOS測定基準のための定義された要件を提示するでしょう。 例えば、1つのクラスが、低い遅れを必要として、少ないスループットだけを必要として、低価格を必要とするかもしれません。
A.4.3 Multipath Routing
A.4.3多重通路ルート設定
There are two types of multipath routing which are useful for Inter- AS Routing: (1) there may be multiple gateways between any two neighboring AS's; (2) there may be multiple AS-to-AS paths between any pair of source and destination AS's. Both forms of multipath are useful in order to allow for loadsplitting. Provision for multipath routing in the IARP is desirable, but not an absolute requirement.
そうする多重通路ルーティングの2つのタイプがInter- ASルート設定の役に立った状態であります: (1) ASのものを近所付き合いさせるどんな2の間にはも、複数のゲートウェイがあるかもしれません。 (2) どんな組のソースとASの目的地ところの間にはも、ASからASへの複数の経路があるかもしれません。 多重通路の両方のフォームは、loadsplittingすると考慮するために役に立ちます。 IARPでの多重通路ルーティングへの支給が望ましいのですが、絶対条件は望ましくはありません。
Little [Page 20] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[20ページ]RFC1126相互自律システム
A.5 Performance Issues
A.5パフォーマンス問題
The following paragraphs discuss issues related to the performance of an Inter-AS Routing Protocol. This discussion addresses size as well as efficiency considerations.
以下のパラグラフはInter-ASルート設定プロトコルの性能に関連する問題について議論します。 この議論は効率問題と同様にサイズを扱います。
A.5.1 Adaptive Routing
A.5.1最適経路指定
It is necessary that the Inter-AS Routing scheme respond in a timely fashion to major network problems, such as the failure of specific network resources. In this sense, Inter-AS Routing needs to use adaptive routing mechanisms similar to those commonly used within individual networks and AS's. It is important that the adaptive routing mechanism chosen for Inter-AS Routing achieve rapid convergence following internet topological changes, with little or none of the serious convergence problems (such as "counting to infinity") that have been experienced in some existing dynamic routing protocols.
Inter-ASルート設定体系が直ちに重大なネットワーク問題に応じるのが必要です、特定のネットワーク資源の失敗などのように。 この意味で、Inter-ASルート設定は、個々のネットワークとASのところの中で一般的に使用されたものと同様の最適経路指定メカニズムを使用する必要があります。 インターネットの位相的な変化に続いて、Inter-ASルート設定に選ばれた最適経路指定メカニズムが急速な集合を実現するのは、重要です、いくつかの既存のダイナミックルーティングプロトコルで経験された重大な集合問題(「無限勘定」などであることなどの)の少しかいずれでも、そうしません。
The Inter-AS Routing scheme must provide stability of routes. It is totally unacceptable for routes to vary on a frequent basis. This requirement is not meant to limit the ability of the routing algorithm to react rapidly to major topological changes, such as the loss of connectivity between two AS's. The need for adaptive routing does not imply any desire for load-based routing.
Inter-ASルート設定体系はルートの安定性を提供しなければなりません。 ルートが頻繁ベースにおいて異なるのは、完全に容認できません。 この要件はルーティング・アルゴリズムが急速に主要な位相的な変化に反応する能力を制限することになっていません、ASの2ところの間の接続性の損失などのように。 最適経路指定の必要性は負荷ベースのルーティングに関する少しの願望も含意しません。
A.5.2 Large Internets
A.5.2の大きいインターネット
One key question in terms of the targets is the maximum size of the Internet this algorithm is supposed to support. To some degree, this is tied to the timeline for which this protocol is expected to be active. However, it is necessary to have some size targets. Techniques that work at one order of size may be impractical in a system ten or twenty times larger.
目標に関する1つの肝心かなめの問題がこのアルゴリズムがサポートするべきであるインターネットの最大サイズです。 ある程度、これはこのプロトコルがアクティブであると予想されるスケジュールに結ばれます。 しかしながら、いくつかのサイズ目標を持つのが必要です。 サイズの1つの注文で利くテクニックは、システムtenで非実用的であるか、または20倍より大きいかもしれません。
Over the past five years there has been an approximate doubling of the Internet each year. In January 1988, there were more than 330 operational networks and more than 700 network assigned numbers. Exact figures for the future growth rate of the Internet are difficult to predict accurately. However, if this doubling trend continues, we would reach 10,000 nets sometime near January 1993.
過去5年間、それぞれの年はインターネットの大体の倍増です。 1988年1月に、330以上の操作上のネットワークと700以上のネットワーク規定番号がありました。 インターネットの将来の成長率のための正確な図形は正確に予測するのが難しいです。 しかしながら、この倍増傾向が続くなら、私たちは1993年1月頃のいつか、1万のネットに達するでしょう。
Taking a projection purely on the number of networks (the top level routing entity) may be overly conservative since the introduction and wide use of subnets has absorbed some growth, but will not continue to be able to do so. In addition, there are plans being discussed that will continue or accelerate the current rate of growth. Nonetheless, the number of networks is very important because
ネットワーク(最高平らなルーティング実体)の数で純粋に映像を取るのは、サブネットの序論と広い使用が何らかの成長を吸収したのでひどく保守的であるかもしれませんが、ずっとそうすることができないでしょう。 さらに、現在の成長率を続けているか、または加速する議論するプランがあります。 それにもかかわらず、ネットワークの数は非常に重要です。
Little [Page 21] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[21ページ]RFC1126相互自律システム
networks constitute the "top level entities" in the current addressing structure.
ネットワークは現在のアドレシング構造で「最高平らな実体」を構成します。
The implications of the size parameter are fairly serious. The current system has only one level of addressing above subnets. While it is possible to adjust certain parameters (for example, the unsolicited or unnecessary retransmission rate) to produce a larger but less robust system, other parameters (for example, the rate of change in the system) cannot be so adjusted. This will provide eventual limits on the size of a system that can be dealt with in a flat address space.
サイズ・パラメータの含意はかなり重大です。 現在のシステムには、サブネットを超えて1つのレベルのアドレシングしかありません。 より大きい、しかし、それほど強健でないシステムを作成するように、あるパラメタ(例えば、求められていないか不要な「再-トランスミッション」レート)を調整するのが可能である間、他のパラメタ(例えば、システムの増減率)を非常に調整できません。 これはフラットアドレス空間で対処できるシステムのサイズにおける最後の限界を提供するでしょう。
The exact size that necessitates moving from the current single- level system to a multi-level system is not clear. Among the parameters which affect it are the assumed minimum speed of links in the system (faster links can allocate more bandwidth to routing traffic before it becomes obtrusive), speed and memory capacity of routing nodes (needed to store and process routing data), rate at which topology changes, etc. The maximum size which can be handled in a single layer is generally thought to be somewhere on the order of 10 thousand objects. The IARP must be designed to deal with internets bigger than this.
現在のただ一つの平らなシステムからマルチレベルシステムまで移行するのを必要とする実寸は明確ではありません。 それに影響するパラメタの中に、ルーティングノード(ルーティングデータを保存して、処理するのが必要である)のシステム(おしつけがましくなる前により速いリンクは、より多くの帯域幅をルーティングトラフィックに割り当てることができる)、速度、および記憶容量における、リンクの想定された最小の速度、トポロジーが変化する速度などがあります。 一般に、単一層の中で扱うことができる最大サイズが10の注文のときに1,000が反対するところにあると考えられます。 これより大きくインターネットに対処するようにIARPを設計しなければなりません。
A.5.3 Addressing Implications
含意を扱うA.5.3
Given the current rate of growth of the Internet, we can expect that the current addressing structure will become unworkable early within the lifetime of the new IARP. It is therefore essential that any new IARP be able to use a new addressing format which allows for addressing hierarchies beyond the network level. Any new IARP should allow for graceful migration from the current routing protocols, and should also allow for graceful migration from a routing scheme based on the current addressing, to a scheme based on a new multi-level addressing format such as that described by OSI 8473.
インターネットの現在の成長率を考えて、私たちは、現在のアドレシング構造が新しいIARPの生涯中に早く「非-実行可能」になると予想できます。 したがって、どんな新しいIARPもネットワークレベルを超えて階層構造を扱うと考慮する新しいアドレス指定形式を使用できるのは、不可欠です。 どんな新しいIARPも現在のルーティング・プロトコルから優雅な移行を考慮するべきであり、また、現在のアドレシングに基づくルーティング体系から優雅な移行を考慮するはずです、OSI8473によって説明されたそれなどの新しいマルチレベルアドレス指定形式に基づく体系に。
A.5.4 Memory, CPU, and Bandwidth Costs
A.5.4メモリ、CPU、および帯域幅コスト
Routing costs can be measured in terms of the memory needed to store routing information, the CPU costs of calculating routes and forwarding packets, and the bandwidth costs of exchanging routing information and of forwarding packets. These significant factors should provide the basis for comparison between competing proposals in IARP design.
ルーティング情報を保存するのに必要であるメモリ、計算のルートと推進パケットのCPUコスト、およびルーティング情報を交換して、パケットを進める帯域幅コストでルート設定コストを測定できます。 これらの特筆すべき要因はIARPデザインで競争することの間の比較の基準に提案を提供するべきです。
Little [Page 22] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[22ページ]RFC1126相互自律システム
The routing architecture will be driven by the expected size of the Internet, the expected memory capacity of the gateways, capacity of the Inter-AS links, and the computing speed of the gateways. Given our experience with the current Internet, it is clearly necessary for the scheme to function adequately even if the Internet grows more quickly than we predict and its capacity grows more slowly. Memory, CPU, and bandwidth costs should be in line with what is economically practical at any point in time given the size of the Internet at that time.
ルーティングアーキテクチャはインターネットの予想されたサイズ、ゲートウェイの予想された記憶容量、Inter-ASリンクの容量、およびゲートウェイのコンピューティング速度によって動かされるでしょう。 現在のインターネットの私たちの経験を考えて、インターネットが私たちが予測するより急速に発展し、容量が、よりゆっくり成長しても、体系が適切に機能するのが明確に必要です。 その時インターネットのサイズを与える場合時間内に任意な点で経済的に実用的なことに沿ってメモリ、CPU、および帯域幅コストがあるべきです。
A.6 Other Issues
A.6他の問題
The following are issues of a general nature and includes discussion of items which have been considered to be best left for future efforts.
以下は、将来の取り組みのために左に一般的な自然の問題であり、最も良いと考えられた項目の議論を含んでいます。
A.6.1 Implementation
A.6.1実装
The specification of IARP should allow interoperation among multi- vendor implementations. This requires that multiple vendors be able to implement the same protocol, and that equipment from multiple vendors be able to interoperate successfully.
IARPの仕様はマルチベンダー実装の中にinteroperationを許容するべきです。 これは、複数のベンダーが同じプロトコルを実装することができて、複数のベンダーからの設備が首尾よく共同利用できるのを必要とします。
There are potential practical difficulties of realizing multi-vendor interoperation. Any such difficulty should not be inherent to the protocol specifications. Towards this end, we should produce a protocol specification that is precise and unambiguous. This implies that the specification should include a detailed specification using Pseudo-Code or a Formal Description Technique.
マルチベンダinteroperationがわかるという潜在的実用的な困難があります。 そのようなどんな困難もプロトコル仕様に固有であるべきではありません。 この終わりに向かって、私たちは正確で明白なプロトコル仕様を作り出すべきです。 これは、仕様がPseudo-コードかFormal記述Techniqueを使用することで仕様詳細を含むべきであるのを含意します。
A.6.2 Configuration
A.6.2構成
It is expected that any IARP will require a certain amount of configuration information to be maintained by gateways. However, in practice it is often difficult to maintain configuration information in a fully correct and up-to-date form. Problems in configuration have been known to cause significant problems in existing operational networks and internets. The design of an Inter-AS Routing architecture must therefore simplify the maintenance of configuration information, consistent with other requirements. Simplification of configuration information may require minimizing the amount of configuration information, and using automated or semi-automated configuration mechanisms.
どんなIARPも、ある量の設定情報がゲートウェイによって維持されるのを必要とすると予想されます。 しかしながら、実際には、完全に正しくて最新のフォームで設定情報を維持するのはしばしば難しいです。 構成における問題が操作上のネットワークとインターネットを存在することにおける重大な問題に引き起こすのが知られています。 したがって、Inter-ASルート設定アーキテクチャのデザインは他の要件と一致した設定情報のメインテナンスを簡素化しなければなりません。 設定情報の簡素化は、量を最小にするのを設定情報と、自動化されたか半自動化している構成メカニズムを使用するのを要求するかもしれません。
A.6.3 Migration
A.6.3移行
In any event, whether the address format changes or not, a viable transition plan which allows for interoperability must be arranged.
とにかく、アドレス形式変化であるか否かに関係なく、相互運用性を考慮する実行可能な変遷プランを調整しなければなりません。
Little [Page 23] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[23ページ]RFC1126相互自律システム
In a system of this magnitude, which is in operational use, a coordinated change is not possible. Where possible, changes should not affect the hosts, since deploying such a change is probably several orders of magnitude more difficult than changing only the gateways, due to the larger number of host implementations as well as hosts. There are two important questions that need to be addressed: (1) migration from the existing EGP to a new IARP; (2) migration from the current DD IP to future protocols (including the ISO IP, and other future protocols).
この大きさのシステムでは、連携変化は可能ではありません。(操作上、大きさは使用中です)。 可能であるところでは、変化がホストに影響するはずがありません、そのような変化を配布するのがたぶんゲートウェイだけを変えるより数桁難しいので、ホストと同様に多くのホスト導入のため。 扱われる必要がある2つの重要な質問があります: (1) 既存のEGPから新しいIARPまでの移行。 (2) 現在のDD IPから将来のプロトコル(ISO IP、および他の将来のプロトコルを含んでいる)までの移行。
A.6.4 Load-Based Routing
A.6.4の負荷ベースのルート設定
Some existing networks are able to route packets based on current load in the network. For example, one approach to congestion involves adjusting the routes in real time to send as much traffic as possible on lightly loaded network links.
いくつかの既存のネットワークがネットワークで現在の負荷に基づくパケットを発送できます。 例えば、混雑への1つのアプローチが、リアルタイムで軽く積み込まれたネットワークリンクでできるだけ多くのトラフィックを送るようにルートを調整することを伴います。
This sort of load-based routing is a relatively delicate procedure which is prone to instability. It is particularly difficult to achieve stability in multi-vendor environments, in large internets, and in environments characterized by a large variation in network characteristics. For these reasons, we believe that it would be a mistake to attempt to achieve effective load-based routing in an Inter-AS Routing scheme.
この種類の負荷ベースのルーティングは不安定性の傾向がある比較的デリケートな手順です。 マルチベンダ環境、大きいインターネット、およびネットワークの特性の大きい変化によって特徴付けられた環境における安定性を達成するのは特に難しいです。 これらの理由で、私たちは、Inter-ASルート設定計画における効果的な負荷ベースのルーティングを達成するのを試みるのが、誤りであると信じています。
A.6.5 Non-Interference Policies
A.6.5不干渉方針
There are policies which are in effect, or desired to be in effect, which are based upon the concept of non-interference. These policies state that the utilization of a given resource is permissible by one party as long as that utilization does not disrupt the current or future utilization of another party. These policies are often of the kind "you may use the excess capacity of my link" without guaranteeing any capacity will be available. The expectation is to be able to utilize the link as needed, perhaps to the exclusion of the other party. The problem with supporting such a policy is the need to be cognizant of highly dynamic state information and the implicit requirement to adapt to these changes. Rapid, persistent, and non-deterministic state changes would lead to routing oscillations and looping. We do not believe it is feasible to support policies based on these considerations in a large internetworking environment based on the current design of IP.
有効であり、有効であることが望まれていて、不干渉の概念に基づいている方針があります。 これらの方針は、その利用が別のパーティーの現在の、または、今後の利用を中断しない限り、与えられたリソースの利用が1回のパーティーを許されさせていると述べます。 これらの方針はどんな容量も有効になるのを保証するのなしでしばしば親切な「あなたは私のリンクの過剰生産能力を使用できる」そうです。 期待は恐らく相手を除外して必要に応じてリンクを利用することであることができます。 そのような方針を支持することに関する問題は非常にダイナミックな州の情報とこれらの変化に順応するという暗黙の要件において認識力がある必要性です。 急速で、しつこくて、非決定論的な州の変化はルーティング振動とループに通じるでしょう。 私たちは、IPの現在のデザインに基づく大きいインターネットワーキング環境でこれらの問題に基づく方針を支持するのが可能であると信じていません。
Security Considerations
セキュリティ問題
Security issues are not addressed in this memo.
安全保障問題はこのメモに記述されません。
Little [Page 24] RFC 1126 Inter-Autonomous System Routing October 1989
1989年10月に掘られる小さい[24ページ]RFC1126相互自律システム
Author's Address
作者のアドレス
Mike Little Science Applications International Corporation (SAIC) 8619 Westwood Center Drive Vienna, Virginia 22182
8619年のマイク小さい科学応用インターナショナル・コーポレーション(SAIC)ウエストウッドのセンターDriveウィーン、ヴァージニア 22182
Phone: 703-734-9000
以下に電話をしてください。 703-734-9000
EMail: little@SAIC.COM
メール: little@SAIC.COM
Little [Page 25]
リトル[25ページ]
一覧
スポンサーリンク
