RFC1787 日本語訳

Network Working Group                                         Y. Rekhter
Request for Comments: 1787        T.J. Watson Research Center, IBM Corp.
Category: Informational                                       April 1995

Rekhterがコメントのために要求するワーキンググループY.をネットワークでつないでください: 1787 T.J.ワトソン研究所、IBM社のカテゴリ: 情報の1995年4月

                  Routing in a Multi-provider Internet

マルチプロバイダーインターネットのルート設定

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Abstract

要約

   This document was prepared by the author on behalf of the Internet
   Architecture Board (IAB). It is offered by the IAB to stimulate
   discussion.

このドキュメントはインターネット・アーキテクチャ委員会(IAB)を代表して作者によって準備されました。 それは、議論を刺激するためにIABによって提供されます。

   Over the past few years the Internet has undergone significant
   changes.  Among them is the emergence of multiple Network Service
   Providers, where resources that provide Internet-wide IP connectivity
   (routers, links) are controlled by different organizations.  This
   document presents some of the issues related to network layer routing
   in a multi-provider Internet, and specifically to the unicast
   routing.

過去数年間にわたって、インターネットは著しい変化を受けています。 それらの中に、複数のNetwork Service Providersの出現があります。((そこでは、異なった組織によって制御されます)インターネット全体のIPの接続性(ルータ、リンク)を提供するリソース)。 このドキュメントはマルチプロバイダーインターネットと、特にユニキャストルーティングにネットワーク層ルーティングに関連する問題のいくつかを提示します。

1. Network Service Providers vs Network Service Subscribers

1. ネットワーク・サービスプロバイダー対ネットワーク・サービス加入者

   Within the current routing paradigm the service offered by a provider
   at the network layer (IP) is the set of destinations (hosts) that can
   be reached through the provider. Once a subscriber establishes direct
   connectivity to a provider, the subscriber can in principle reach all
   the destinations reachable through the provider. Since the value of
   the Internet-wide connectivity service offered by a provider
   increases with the number of destinations reachable through the
   provider, providers are motivated to interconnect with each other.

中では、サービスがネットワーク層(IP)におけるプロバイダーで提供した現在のルーティングパラダイムがプロバイダーを通して達することができる目的地(ホスト)のセットです。 加入者がいったんダイレクト接続性をプロバイダーに確立すると、加入者は原則としてプロバイダーを通して届いているすべての目的地に着くことができます。 プロバイダーを通して届いている目的地の数に従ってプロバイダーによって提供されたインターネット全体の接続性サービスの価値が増加するので、プロバイダーは互いと共に内部連絡するために動機づけられています。

   In principle a provider need not offer the same service (in terms of
   the set of destinations) to all of its subscribers -- for some of the
   subscribers the provider may restrict the services to a subset of the
   destinations reachable through the provider. In fact, for certain
   types of subscribers constrained connectivity could be seen as part
   of the service offered by a provider.

原則として、プロバイダーは同じサービスを加入者のすべてに提供する必要はありません(目的地のセットに関して)--何人かの加入者に関して、プロバイダーはプロバイダーを通して届いている目的地の部分集合に対するサービスを制限するかもしれません。 事実上、あるタイプの加入者に関して、制約つき接続性をプロバイダーによって提供されたサービスの一部と考えることができました。

   In a multi-provider environment individual providers may be driven by
   diverse and sometimes even conflicting goals and objectives. Some of
   the providers exist to provide connectivity to only a specific group

マルチプロバイダーでは、環境の個々のプロバイダーはさまざまの、そして、時々同等の闘争目標と目的によって動かされるかもしれません。 プロバイダーのいくつかが、特定のグループだけに接続性を提供するために存在しています。

Rekhter                                                         [Page 1]

RFC 1787          Routing in a multi-provider Internet        April 1995

マルチプロバイダーインターネット1995年4月のRekhter[1ページ]RFC1787ルート設定

   of Network Service Subscribers. Other providers place no constraints
   on the subscribers that can subscribe to them, as long as the
   subscribers pay the fee charged by the providers. Some of the
   providers place certain constraints on the reselling of the
   connectivity services by organizations (e.g., other providers)
   attached to the providers. Some of the providers may be operated by
   companies that are subject to specific regulations (e.g.,  regulated
   monopoly), while other providers are completely unregulated.  The
   scope of geographical coverage among providers varies from a small
   region (e.g., county, town) to a country-wide, international, or even
   intercontinental.

ネットワークでは、加入者にサービスを提供してください。 他のプロバイダーは彼らに加入できる加入者に規制を全く置きません、加入者がプロバイダーによって請求された料金を支払う限り。 プロバイダーのいくつかがプロバイダーに付けられた組織(例えば、他のプロバイダー)による接続性サービスの転売であることに、ある規制を置きます。 プロバイダーのいくつかが特定の規則(例えば、規制された独占)を受けることがある会社によって運用されるかもしれません、他のプロバイダーは完全に調節されるというわけではありませんが。 プロバイダーの中の地域的範囲の範囲は国際的であるか、大陸間な小さいaに全国的な領域(例えば、カウンティー、町)とさえ異なります。

   There is no centralized control over all the providers in the
   Internet.  The providers do not always coordinate their efforts with
   each other, and quite often are in competition with each other.

インターネットのすべてのプロバイダーの上に集中制御が全くありません。 プロバイダーは、互いと共に彼らの努力をいつも調整するというわけではなくて、互いと共にかなりしばしば競争しています。

   Despite all the diversity among the providers, the Internet-wide IP
   connectivity is realized via Internet-wide distributed routing, which
   involves multiple providers, and thus implies certain degree of
   cooperation and coordination. Therefore, there is a need to balance
   the providers' goals and objectives against the public interest of
   Internet-wide connectivity and subscribers' choices. Further work is
   needed to understand how to reach the balance.

プロバイダーの中のすべての多様性にもかかわらず、インターネット全体のIPの接続性は、インターネット全体の分配されたルーティングで実現されて、その結果、ある度の協力とコーディネートを含意します。(ルーティングは複数のプロバイダーを伴います)。 したがって、接続性と加入者のインターネット全体の選択の公益に対してプロバイダーの目標と目的のバランスをとる必要があります。 さらなる仕事が、バランスに達する方法を理解するのに必要です。

2. Routing Requirements

2. ルート設定要件

   Conceptually routing requirements can be classified into the
   following three categories: source preferences, destination
   preferences, and constraints on transit traffic. Source preferences
   allow an originator of a packet to exert control over the path to a
   destination.  Destination preferences allow a destination to exert
   control over the path from a source to the destination. Constraints
   on transit traffic allow a provider to control the traffic that can
   traverse through the resources (routers, links) controlled by the
   provider.

概念的に、ルーティング要件を以下の3つのカテゴリに分類できます: ソース好み、目的地好み、およびトランジット交通の規制。 ソース好みで、パケットの生成元は経路のコントロールを目的地に及ぼすことができます。 目的地好みで、目的地はソースから目的地まで経路のコントロールを及ぼすことができます。 トランジット交通の規制で、プロバイダーはそれがプロバイダーによって制御されたリソース(ルータ、リンク)を通して横断できる交通を制御できます。

   From a conceptual point of view the requirements over the degree of
   control for source and destination preferences may vary from being
   able to just provide connectivity (regardless of the path), to being
   able to select immediate providers, to more complex scenarios, where
   at the other extreme a subscriber may want to have complete control
   over the path selection.

概念的な観点と、ソースと目的地好みのための統制度の上要件はただ、接続性(経路にかかわらず)を提供できるので、異なるかもしれません、即座のプロバイダーを選択できるのに、より複雑なシナリオに。そこでは、それとは正反対に加入者が経路選択の完全なコントロールが欲しいかもしれません。

   From a conceptual point of view the requirements over the degree of
   control for transit traffic may vary from control based only on the
   direct physical connectivity (controlling the set of organizations
   directly connected to the provider), to being able to restrict
   traffic to a particular set of sources or destinations, or a

トランジット交通への統制度の上要件がダイレクト物理的な接続性(直接プロバイダーに接続された組織のセットを制御する)だけに基づくコントロールから交通を特定のセットのソース、目的地、またはaに制限できるのに変えるかもしれない概念的な観点から

Rekhter                                                         [Page 2]

RFC 1787          Routing in a multi-provider Internet        April 1995

マルチプロバイダーインターネット1995年4月のRekhter[2ページ]RFC1787ルート設定

   combination of particular sources and destinations, or even take into
   account the paths to/from these sources and/or destinations.

特定のソースと目的地か、これらからの/への経路が出典を明示するアカウントへの撮影、そして/または、目的地さえの組み合わせ。

   In view of a potentially wide variety of routing requirements, we
   need to get a better understanding on the relative practical
   importance of various routing requirements. In practice organizations
   usually don't formulate their routing requirements in a vacuum. For
   example, since the primary role of a provider is to provide services
   to a set of subscribers, the provider usually formulates its routing
   requirements based on the set of the routing requirements of the
   subscribers the provider is expected to serve.

潜在的に広いバラエティーのルーティング要件から見て、私たちは、様々なルーティング要件の相対的な実用的な重要性で分かりながら回復する必要があります。 実際には、通常、組織は真空でそれらのルーティング要件を定式化しません。 例えば、プロバイダーの第一の役割が1セットの加入者に対するサービスを提供することであるので、通常、プロバイダーは取り扱うプロバイダーが予想される加入者のルーティング要件のセットに基づくルーティング要件を定式化します。

   Support for various routing requirements should take into account the
   overhead and the scope of the overhead associated with those
   requirements. A situation where an organization can unilaterally
   impose routing information overhead on other organization (e.g., by
   requiring the other organization to maintain an additional routing
   information) should be viewed as undesirable. The cost of supporting
   a particular routing requirement should not be borne by organizations
   that do not benefit from supporting that requirement. Ideally the
   routing system should allow to shift the overhead associated with a
   particular routing requirement towards the entity that instigates the
   requirement (for example, there is a need to carefully balance the
   overhead associated with maintaining a state needed for multi-hop
   header compression vs carrying explicit forwarding information on a
   per packet basis).  Organizations with simple routing requirements
   shouldn't bear the same routing information overhead as organizations
   with complex routing requirements.

様々なルーティング要件のサポートはそれらの要件に関連しているオーバーヘッドのオーバーヘッドと範囲を考慮に入れるべきです。 組織が一方的に他の組織(例えば、もう片方の組織が追加ルーティング情報を保守するのを必要とするのによる)にルーティング情報オーバーヘッドを課すことができる状況は同じくらい望ましくない状態で見られるべきです。 その要件を支持するのから利益を得ない組織は特定のルーティング要件を支持する費用を負担するべきではありません。 理想的に、ルーティングシステムは要件を扇動する実体に向かった特定のルーティング要件に関連しているオーバーヘッドをシフトに許容するはずです(例えば、パケット基礎あたりのaの明白な推進情報を運ぶことに対して慎重に状態を維持するとマルチホップヘッダー圧縮に必要である関連しているオーバーヘッドのバランスをとる必要があります)。 簡単なルーティング要件がある組織は複雑なルーティング要件がある組織と同じルーティング情報オーバーヘッドを負担するべきではありません。

   A situation where the overhead associated with supporting a
   particular routing requirement has to be carried by every entity
   (e.g., router, host) within an organization that would like to impose
   the requirement could be viewed as undesirable. An organization
   should be able to instantiate its routing requirements in a more or
   less central fashion, for example by utilizing just some of the
   routers.

あらゆる実体(例えば、ルータ、ホスト)によって特定のルーティング要件を支持すると関連しているオーバーヘッドが要件を課したがっている組織の中で運ばれなければならない状況は同じくらい望ましくない状態で見られるかもしれません。 組織は多少主要なファッションによるルーティング要件を例示できるべきです、例えば、ルータのほんのいくつかを利用することによって。

   Even if the scope of the routing information overhead is purely
   local, there is a need to perform a careful analysis of the tradeoff
   between the potential benefits and the cost associated with
   supporting various routing requirements.

ルーティング情報オーバーヘッドの範囲が純粋に地方であっても、様々なルーティング要件を支持すると関連している潜在的利益と費用の間には、見返りの慎重な分析を実行する必要があります。

3. Encapsulation

3. カプセル化

   The technique of encapsulation allows for the creation of a "virtual"
   IP overlay over an existing IP infrastructure. This has certain
   implications for the Internet routing system.

カプセル化のテクニックは既存のIPインフラストラクチャに関して「仮想」のIPオーバレイの創造を考慮します。 これには、インターネット・ルーティングシステムのためのある意味があります。

Rekhter                                                         [Page 3]

RFC 1787          Routing in a multi-provider Internet        April 1995

マルチプロバイダーインターネット1995年4月のRekhter[3ページ]RFC1787ルート設定

   In the presence of encapsulation, a provider may no longer be able to
   constrain its transit traffic to a particular set of ultimate sources
   and/or destinations, as a packet may be encapsulated by some router
   along the path, with the original source and/or destination addresses
   being "hidden" (via encapsulation) at the Network layer. Likewise,
   encapsulation may affect source and destination preferences, as a
   source (or a destination) may either (a) be unaware of the
   encapsulation, or (b) have little or no control over the encapsulated
   segment of a path.

カプセル化があるとき、プロバイダーはもう特定のセットの究極の源、そして/または、目的地へのトランジット交通を抑制できないかもしれません、パケットが経路に沿った何らかのルータによってカプセルに入れられるとき、一次資料、そして/または、送付先アドレスがNetwork層に「隠されている」状態で(カプセル化で)。 (a) ソース(または、目的地)がそうするかもしれないようにカプセル化に同様に、カプセル化がソースと目的地好みに影響するかもしれないのを気づかないか、または(b) 経路の要約のセグメントをまず管理してください。

   Further work is needed to understand the implications of the overlay
   capabilities created via encapsulation on the semantics of routing
   requirements, as well as the interaction among the routing
   requirements by the entities that form the overlay and the entities
   that form the underlying infrastructure.

さらなる仕事が、ルーティング要件の意味論、およびルーティング要件の中の相互作用でオーバレイを形成する実体と基本的なインフラストラクチャを形成する実体でカプセル化で作成されたオーバレイ能力の含意を理解するのに必要です。

4. Price Structure and its Impact on Routing

4. 価格Structureとルート設定でのそのImpact

   Routing among providers, as well as between providers and subscribers
   may be influenced by the price structure employed by the providers,
   as well as the usage pattern of the subscribers. A provider can view
   routing as a mechanism that allows the provider to exert control over
   who can use the provider's services. A subscriber can view routing as
   a mechanism that allows the subscriber to exert control over the
   price it pays for the Internet connectivity.

プロバイダーの中で掘って、プロバイダーと加入者の間でプロバイダーによって使われた価格構造によって影響を及ぼされるかもしれません、加入者の用法模範と同様に。 プロバイダーはプロバイダーがだれがプロバイダーのサービスを利用できるかのコントロールを及ぼすことができるメカニズムであるとルーティングをみなすことができます。 加入者は加入者がそれが支払うインターネットの接続性の価格のコントロールを及ぼすことができるメカニズムであるとルーティングをみなすことができます。

   The need to exert control has to be carefully balanced against the
   cost of the routing mechanisms needed to provide such control. In a
   competitive market one could question the viability of a mechanism
   whose incremental cost would be greater than the saving recovered by
   the mechanism -- competitive pressure or alternate mechanisms are
   likely to push providers and subscribers towards choosing the
   cheapest mechanism.

コントロールを及ぼす必要性は慎重にそのようなコントロールを提供するのが必要であるルーティングメカニズムの費用に対してバランスをとらなければなりません。 競争の激しい市場で、1つは増分費用が節約がメカニズムで回復したより大きいメカニズムの生存力に質問するかもしれません--最も安いメカニズムを選ぶことに向かって競争の激しい圧力か交互のメカニズムがプロバイダーと加入者を押しそうです。

5. Scalability

5. スケーラビリティ

   One of the key requirements imposed on the Internet routing is its
   ability to scale. In addition to conventional metrics for scalability
   (e.g., memory, CPU, bandwidth), we need to take into account
   scalability with respect to the human resources required to operate
   the system. The need for deployment of CIDR already showed that a
   routing scheme that scales linearly with respect to the number of
   connected networks, or even to the number of connected organizations
   is unacceptable today, and is likely to be unacceptable in the long
   term. It is not clear whether routing that scales linearly with the
   number of providers is going to be acceptable in the long term.

インターネット・ルーティングに課された主要な要件の1つは比例するその性能です。 スケーラビリティ(例えば、メモリ、CPU、帯域幅)のための従来の測定基準に加えて、私たちは、システムを操作するのに必要である人的資源に関してアカウントスケーラビリティを連れていく必要があります。 CIDRの展開の必要性はスケールが接続ネットワークの数か、接続組織の数にさえ直線的であるルーティング計画が今日、容認できなく、長期で容認できない傾向があることを既に示しました。 長期で許容できるのはスケールがプロバイダーの数で直線的であるルーティングが行くかどうか明確ではありません。

Rekhter                                                         [Page 4]

RFC 1787          Routing in a multi-provider Internet        April 1995

マルチプロバイダーインターネット1995年4月のRekhter[4ページ]RFC1787ルート設定

   Scaling implies that the Internet routing system needs to have
   powerful mechanisms to provide routing information
   aggregation/abstraction.

スケーリングは、インターネット・ルーティングシステムがルーティング情報集合/抽象化を提供するために強力なメカニズムを必要とするのを含意します。

   In the absence of Internet-wide coordination and in the presence of
   competition among the providers, the aggregation/abstraction
   mechanisms should minimize preconditions as well as limit the amount
   of required inter-provider coordination. Ideally the routing system
   should allow a provider to control the amount of its local resources
   needed to deal with the routing overhead based on considerations that
   are purely local to the provider.

インターネット全体のコーディネートがないときプロバイダーの中の競争があるとき、集合/抽象化メカニズムは、前提条件を最小にして、必要な相互プロバイダーコーディネートの量を制限するはずです。 理想的に、ルーティングシステムで、プロバイダーは純粋にプロバイダーにローカルであることの問題に基づくルーティングオーバーヘッドに対処するのに必要であるローカル資源の量を制御できるべきです。

   One of the side effects of the routing information
   aggregation/abstraction is that some of the routing information is
   going to be lost. This may impact route optimality and even the
   ability to find an existing route. The need for routing information
   aggregation/abstraction also implies certain homogeneity of the
   information to be aggregated/abstracted. This needs to be counter-
   balanced against the potential diversity of routing requirements.

ルーティング情報集合/抽象化の副作用の1つはルーティング情報のいくつかが無くなるということです。 これはルートの最適と既存のルートを見つける能力にさえ影響を与えるかもしれません。 また、ルーティング情報集合/抽象化の必要性は、集められるか、または抜き取られるために情報のある同質を含意します。 これは、ルーティング要件の潜在的多様性に対してバランスをとるカウンタである必要があります。

   As a way to deal with the routing information loss due to
   aggregation/abstraction, we need to explore mechanisms that allow
   routing that is based on the on-demand acquisition of subsets of
   unaggregated information.

集合/抽象化によるルーティング情報の損失に対処する方法として、私たちは、「非-集合」情報の部分集合の要求次第の習得に基づいているルーティングを許すメカニズムを探る必要があります。

   The overhead associated with supporting specific routing requirements
   has a direct impact on the overall scalability of the Internet
   routing system. We need to get a better understanding of how various
   routing requirements impact scalability. When the impact is
   significant, and the requirements have practical importance we need
   to develop mechanisms that allow the impact to be reduced.

特定のルーティング要件を支持すると関連しているオーバーヘッドはインターネット・ルーティングシステムの総合的なスケーラビリティに直接的な衝撃を持っています。 私たちは、様々なルーティング要件がどうスケーラビリティに影響を与えるかに関する、より良い理解を得る必要があります。 影響が重要であり、要件に私たちが衝撃が減少するメカニズムを開発するために必要とする実用的な重要性があるとき。

6. Hierarchical Routing

6. 階層型ルーティング

   Classless Inter-Domain Routing (CIDR) (RFC1518, RFC1519) that is used
   today for scalable Internet-wide routing is based on the technique of
   hierarchical routing. Essential to this technique is the assumption
   that Network layer addresses assigned to individual entities (e.g.,
   hosts, routers) reflect the position of these entities within the
   network topology -- addresses are said to be "topologically
   significant". With CIDR addresses assigned to most of the individual
   sites are expected to reflect providers the sites are connected to --
   CIDR uses "provider-based" addresses.

今日スケーラブルなインターネット全体のルーティングに使用される階級のないInter-ドメインルート設定(CIDR)(RFC1518、RFC1519)は階層型ルーティングのテクニックに基づいています。 不可欠である、このテクニックには、個々の実体(例えば、ホスト、ルータ)に割り当てられたNetwork層のアドレスがネットワーク形態の中でこれらの実体の位置を反映するという仮定があります--アドレスが言われているのを「位相的である、重要である、」 CIDRと共に、個々のサイトの大部分に割り当てられたアドレスがサイトがつなげられるプロバイダーを反映すると予想されます--CIDRは「プロバイダーベース」のアドレスを使用します。

   One of the fundamental consequences of using hierarchical routing is
   that in order to preserve topological significance of network
   addresses, changes in the network topology may need to be accompanied
   by the corresponding changes in the addresses. Presence of multiple

階層型ルーティングを使用する基本的な結果の1つはネットワーク形態における変化が、ネットワーク・アドレスの位相的な意味を保存するのにアドレスにおける対応する変化によって伴われる必要があるかもしれないということです。 倍数の存在

Rekhter                                                         [Page 5]

RFC 1787          Routing in a multi-provider Internet        April 1995

マルチプロバイダーインターネット1995年4月のRekhter[5ページ]RFC1787ルート設定

   providers serving the same geographical area implies that a
   subscriber should be able to switch from one provider to another.
   Since such a switch implies changes in the Internet topology, it
   follows that to retain topological significance of the (provider-
   based) addresses within the subscriber, the subscriber has to change
   the addresses of all of its entities -- the process known as
   "renumbering". There are already tools to facilitate this process --
   Dynamic Host Configuration Protocol (DHCP).  However, DHCP is not yet
   widely deployed. Further work is needed to improve these tools, get
   them widely deployed, and to integrate them with Domain Name System
   (DNS).

同じ地理的な領域に役立つプロバイダーは、加入者が1つのプロバイダーから別のものに切り替わることができるべきであるのを含意します。 そのようなスイッチがインターネットトポロジーの変化を含意するので、それは、加入者の中で(基づくプロバイダー)アドレスの位相的な意味を保有するために、加入者は実体のすべてのアドレスを変えなければなりません--「番号を付け替える」として知られている過程に続きます。 既に、この過程を容易にするツールがあります--Dynamic Host Configuration Protocol(DHCP)。 しかしながら、DHCPはまだ広く配備されていません。 さらなる仕事がこれらのツールを改良するのに必要であり、それらを広く配備させて、ドメインネームシステム(DNS)がある統合しているそれらに。

   Multi-level hierarchical routing allows for recapturing additional
   routing information (routing entropy) due to the mismatch between
   addresses and topology at a particular level in the routing hierarchy
   at some higher level in the hierarchy (e.g., at an exchange point
   among providers).  This enables the routing system to contain the
   scope of entities impacted by the mismatch. Containing the scope of
   entities could be an important factor to facilitate graceful
   renumbering.  Further work is needed to develop appropriate
   deployment strategies to put these capabilities in place.

マルチレベル階層型ルーティングは、アドレスとトポロジーの間のミスマッチのため、階層構造(例えば、プロバイダーの中の交換ポイントの)で追加ルーティング情報(ルーティングエントロピー)を特定のレベルで何らかのより高いレベルにおけるルーティング階層構造で取り戻すと考慮します。 これは、ルーティングシステムがミスマッチによって影響を与えられた実体の範囲を含むのを可能にします。 実体の範囲を含むのは、優雅な番号を付け替えることを容易にするためには重要な要素であるかもしれません。 さらなる仕事が、これらの能力を適所に置くために適切な展開戦略を開発するのに必要です。

   It is important to emphasize that the requirement to maintain
   topologically significant addresses doesn't need to be applied
   indiscriminately to all the organizations connected to the Internet
   -- hierarchical routing requires that most, but not all addresses be
   topologically significant.  For a large organization it could be
   sufficient if the set of destinations within the organization can be
   represented within the Internet routing system as a small number of
   address prefixes, even if these address prefixes are independent of
   the providers that the organization uses to connect to the Internet
   ("provider-independent" addresses). The volume of routing information
   that a large organization would inject into the Internet routing
   system would be comparable to the (aggregated) routing information
   associated with a large number of small organizations.

重要なアドレスを位相的に維持するという要件によって無差別にインターネットに接続されたすべての組織に適用される必要はないと強調するのは重要です--階層型ルーティングは、すべてのアドレスではなく、大部分が位相的にそうであることを必要とします。重要。 大きな組織では、少ない数のアドレス接頭語としてインターネット・ルーティングシステムの中に組織の中の目的地のセットを表すことができるなら、十分であるかもしれません、これらのアドレス接頭語が組織がインターネット(「プロバイダーから独立している」アドレス)に接続するのに使用するプロバイダーから独立していても。 大きな組織がインターネット・ルーティングシステムを注ぐだろうというルーティング情報のボリュームは多くの小さい組織に関連している(集められます)ルーティング情報に匹敵しているでしょう。

   Existence of multiple providers allows a subscriber to be
   simultaneously connected to more than one provider (multi-homed
   subscribers). CIDR offers several alternatives for handling such
   cases. We need to gain more operational experience as well as better
   understand tradeoffs associated with the proposed alternatives.

加入者が同時に複数のプロバイダーの存在で1つ以上のプロバイダーに接続する、(マルチ、家へ帰り、加入者) CIDRは、そのような場合を扱うためにいくつかの選択肢を提供します。 私たちは、より操作上の経験をして、提案された代替手段に関連している見返りをより理解する必要があります。

   An alternative to CIDR address assignment is to assign addresses
   based purely on the geographical location. However, address
   assignment that reflects geographical location of an entity implies
   that either (a) the Internet topology needs to be made sufficiently
   congruent to the geography, or (b) addresses aren't going to be
   topologically significant. In the former case we need to understand

CIDRアドレス課題への代替手段は純粋に地理的な位置に基づくアドレスを割り当てることです。 しかしながら、実体の地理的な位置を反映するアドレス課題は、位相的にであるなるように(a) インターネットトポロジーが、地理学に十分一致しているのに作られている必要があるか、または(b) アドレスが続いていないのを含意します。重要。 私たちが分かるために必要とする前の場合で

Rekhter                                                         [Page 6]

RFC 1787          Routing in a multi-provider Internet        April 1995

マルチプロバイダーインターネット1995年4月のRekhter[6ページ]RFC1787ルート設定

   the driving forces that would make the topology congruent to the
   geography. In the latter case techniques other than hierarchical
   routing need to be developed.

トポロジーを地理学に一致するようにする原動力。 後者では、階層型ルーティング以外のケースのテクニックは、開発される必要があります。

7. Routing Information Sharing

7. 経路情報共有

   While ensuring Internet-wide coordination may be more and more
   difficult, as the Internet continues to grow, stability and
   consistency of the Internet-wide routing could significantly benefit
   if the information about routing requirements of various
   organizations could be shared across organizational boundaries. Such
   information could be used in a wide variety of situations ranging
   from troubleshooting to detecting and eliminating conflicting routing
   requirements. The scale of the Internet implies that the information
   should be distributed. Work is currently underway to establish
   depositories of this information (Routing Registries), as well as to
   develop tools that analyze, as well as utilize this information.

インターネットが、成長し続けているのでインターネット全体のコーディネートが確実にますます難しいかもしれなくなるようにしている間、組織境界の向こう側に様々な組織のルーティング要件の情報を共有できるなら、インターネット全体のルーティングの安定性と一貫性はかなり利益を得るかもしれないでしょうに。 要件を発送しながら闘争を検出して、排除するのに障害調査するので及ぶさまざまな状況でそのような情報を使用できました。 インターネットのスケールは、情報が分配されるべきであるのを含意します。 仕事は、現在、この情報(ルート設定Registries)の貯蔵所を証明して、この情報を分析して、利用するツールを開発するために進行中です。

8. Summary

8. 概要

   In this section we enumerate some of the issues that the IAB thinks
   should be brought to the attention of the Internet community.

このセクションでは、私たちはもたらされるべきであるIABがインターネットコミュニティの注意と思う問題のいくつかを列挙します。

   The following two tasks require the most immediate attention:

以下の2つのタスクが最も即座の注意を必要とします:

      - further work is needed to develop technologies that facilitate
        renumbering

- さらなる仕事が、番号を付け替えるのを容易にする技術を開発するのに必要です。

      - further work is needed to investigate feasibility of routing
        information aggregation above the direct (immediate) provider
        level

- さらなる仕事が、ダイレクトな(即座の)プロバイダーレベルを超えてルーティング情報集合に関する実現の可能性を調査するのに必要です。

   The following tasks are viewed as medium term:

以下のタスクは中期として見なされます:

      - further work is needed to get a better understanding on the
        relative practical importance of various routing requirements

- さらなる仕事が、様々なルーティング要件の相対的な実用的な重要性で分かりながら回復するのに必要です。

      - further work is needed to understand of how various routing
        requirements impact scalability of the routing system

- さらなる仕事が、様々なルーティング要件がどうルーティングシステムのスケーラビリティに影響を与えるかを理解するのに必要です。

      - further work is needed to investigate alternatives to
        hierarchical routing

- さらなる仕事が、階層型ルーティングへの代替手段を調査するのに必要です。

   Finally, the following tasks are viewed as long term:

最終的に、以下のタスクは長期として見なされます:

      - further work is needed to understand and utilize the benefits of
        routing information sharing

- さらなる仕事が、ルーティング情報共有の利益を理解して、利用するのに必要です。

Rekhter                                                         [Page 7]

RFC 1787          Routing in a multi-provider Internet        April 1995

マルチプロバイダーインターネット1995年4月のRekhter[7ページ]RFC1787ルート設定

      - further work is needed to understand the implications of virtual
        overlays created via encapsulation

- さらなる仕事が、カプセル化で作成された仮想のオーバレイの含意を理解するのに必要です。

      - further work is needed to understand how different price
        structures influence routing requirements

- さらなる仕事が、異なった価格構造がどのようにルーティング要件に影響を及ぼすかを理解するのに必要です。

      - further work is needed to understand how to balance the
        providers' goals and objectives against the public interest of
        Internet-wide connectivity and subscribers' choices.

- さらなる仕事が、接続性と加入者のインターネット全体の選択の公益に対してプロバイダーの目標と目的のバランスをとる方法を理解するのに必要です。

9. Conclusions

9. 結論

   This document presents some of the issues related to routing in a
   multi-provider Internet. There are no doubt routing-related areas
   that are not covered in this document. For instance, such areas as
   multicast routing, or routing in the presence of mobile hosts, or
   routing in the presence of a large shared media (e.g., ATM) aren't
   discussed here. Further work is needed to understand the implications
   of a multi-provider Internet on these areas.

このドキュメントはマルチプロバイダーインターネットにルーティングに関連する問題のいくつかを提示します。 本書ではカバーされていない間違いなくルーティング関連の領域があります。 例えば、ここでマルチキャストルーティング、モバイルホストの面前でルーティング、または大きい共有されたメディアがあるときルーティング(例えば、ATM)のような領域について議論しません。 さらなる仕事が、これらの領域のマルチプロバイダーインターネットの含意を理解するのに必要です。

   The impact of multi-provider Internet goes well beyond just routing,
   and percolates into such areas as network management,
   troubleshooting, and others. Further work is needed to assess the
   implications of multi-provider environment on these areas, as well as
   to understand the interaction among all these areas from a system-
   wide perspective.

マルチプロバイダーインターネットの影響は、まさしくルーティングを超えてうまく行って、ネットワークマネージメント、トラブルシューティング、および他のもののような領域にこされます。 さらなる仕事が、これらの領域のマルチプロバイダー環境の含意を評価して、これらのすべての領域の中でシステムの広い見解から相互作用を理解するのに必要です。

10. Acknowledgments

10. 承認

   Many thanks to all the IAB members, and especially to Brian
   Carpenter, Robert Elz, Christian Huitema, Paul Mockapetris, and Lixia
   Zhang for their contributions to this document.

このドキュメントへの彼らの貢献のために特にすべてのIABメンバーと、そして、ブライアンCarpenterと、ロバートElzと、クリスチャンのHuitemaと、ポールMockapetrisと、Lixiaチャンをありがとうございます。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Editor's Address

エディタのアドレス

   Yakov Rekhter
   T.J. Watson Research Center IBM Corporation
   P.O. Box 704, Office H3-D40
   Yorktown Heights, NY 10598

ニューヨーク ヤコフRekhter T.J.ワトソン研究所IBM社の私書箱704、オフィスH3-D40ヨークタウンの高さ、10598

   Phone:  +1 914 784 7361
   EMail:  yakov@watson.ibm.com

以下に電話をしてください。 +1 7361年の914 784メール: yakov@watson.ibm.com

Rekhter                                                         [Page 8]

Rekhter[8ページ]