[要約] 要約：RFC 5773は、インタードメインルーティングの要件と歴史の分析を提供しています。 目的：インタードメインルーティングの進化と課題を理解し、将来の改善に向けた指針を提供することです。
Internet Research Task Force (IRTF) E. Davies
Request for Comments: 5773 Folly Consulting
Category: Historic A. Doria
ISSN: 2070-1721 LTU
February 2010
Analysis of Inter-Domain Routing Requirements and History
ドメイン間のルーティング要件と履歴の分析
Abstract
概要
This document analyzes the state of the Internet domain-based routing system, concentrating on Inter-Domain Routing (IDR) and also considering the relationship between inter-domain and intra-domain routing. The analysis is carried out with respect to RFC 1126 and other IDR requirements and design efforts looking at the routing system as it appeared to be in 2001 with editorial additions reflecting developments up to 2006. It is the companion document to "A Set of Possible Requirements for a Future Routing Architecture" (RFC 5772), which is a discussion of requirements for the future routing architecture, addressing systems developments and future routing protocols. This document summarizes discussions held several years ago by members of the IRTF Routing Research Group (IRTF RRG) and other interested parties. The document is published with the support of the IRTF RRG as a record of the work completed at that time, but with the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the date of publication.
このドキュメントは、インターネットドメインベースのルーティングシステムの状態を分析し、ドメイン間ルーティング（IDR）に集中し、ドメイン間とドメイン内のルーティングの関係を考慮しています。分析は、RFC 1126およびその他のIDRの要件と、2006年までの開発を反映した編集上の追加であると思われるルーティングシステムを検討するその他のIDR要件と設計の取り組みに関して実行されます。将来のルーティングアーキテクチャのために」（RFC 5772）は、将来のルーティングアーキテクチャ、システム開発、将来のルーティングプロトコルへの要件について説明しています。このドキュメントは、数年前にIRTFルーティングリサーチグループ（IRTF RRG）およびその他の利害関係者のメンバーによって開催された議論をまとめたものです。このドキュメントは、IRTF RRGのサポートを当時完了した作業の記録として公開されていますが、出版日における研究グループの最新の技術的理解または技術的コンセンサスを必ずしも表しているわけではないという理解があります。。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for the historical record.
このドキュメントは、インターネット標準の追跡仕様ではありません。歴史的記録のために公開されています。
This document defines a Historic Document for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the individual opinion(s) of one or more members of the Routing Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティ向けの歴史的なドキュメントを定義しています。このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）のルーティング研究グループの1人以上のメンバーの個々の意見を表しています。IRSGによって公開されたことが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5773.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5773で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Provenance of This Document .....................................4
2. Introduction ....................................................5
2.1. Background .................................................7
3. Historical Perspective ..........................................7
3.1. The Legacy of RFC 1126 .....................................7
3.1.1. General Requirements ................................8
3.1.2. "Functional Requirements" ..........................13
3.1.3. "Non-Goals" ........................................21
3.2. ISO OSI IDRP, BGP, and the Development of Policy Routing ..25
3.3. Nimrod Requirements .......................................30
3.4. PNNI ......................................................32
4. Recent Research Work ...........................................33
4.1. Developments in Internet Connectivity .....................33
4.2. DARPA NewArch Project .....................................34
4.2.1. Defending the End-to-End Principle .................35
5. Existing Problems of BGP and the Current Inter-/Intra-Domain
Architecture ...................................................35
5.1. BGP and Auto-Aggregation ..................................36
5.2. Convergence and Recovery Issues ...........................36
5.3. Non-Locality of Effects of Instability and
Misconfiguration ..........................................37
5.4. Multi-Homing Issues .......................................37
5.5. AS Number Exhaustion ......................................38
5.6. Partitioned ASs ...........................................39
5.7. Load Sharing ..............................................40
5.8. Hold-Down Issues ..........................................40
5.9. Interaction between Inter-Domain Routing and
Intra-Domain Routing ......................................40
5.10. Policy Issues ............................................42
5.11. Security Issues ..........................................42
5.12. Support of MPLS and VPNS .................................43
5.13. IPv4/IPv6 Ships in the Night .............................43
5.14. Existing Tools to Support Effective Deployment of
Inter-Domain Routing .....................................44
5.14.1. Routing Policy Specification Language RPSL
(RFC 2622 and RFC 2650) and RIPE NCC Database
(RIPE 157) ........................................44
6. Security Considerations ........................................45
7. Acknowledgments ................................................45
8. Informative References .........................................46
In 2001, the IRTF Routing Research Group (IRTF RRG) chairs, Abha Ahuja and Sean Doran, decided to establish a sub-group to look at requirements for inter-domain routing (IDR). A group of well-known routing experts was assembled to develop requirements for a new routing architecture. Their mandate was to approach the problem starting from a blank slate. This group was free to take any approach, including a revolutionary approach, in developing requirements for solving the problems they saw in inter-domain routing. Their eventual approach documented requirements for a complete future routing and addressing architecture rather than just the requirements for IDR.
2001年、IRTFルーティングリサーチグループ（IRTF RRG）の椅子であるAbha AhujaとSean Doranは、ドメイン間ルーティング（IDR）の要件を検討するサブグループを確立することを決定しました。有名なルーティング専門家のグループが組み立てられ、新しいルーティングアーキテクチャの要件を開発しました。彼らの任務は、空白のスレートから始まる問題にアプローチすることでした。このグループは、革新的なアプローチを含む、ドメイン間ルーティングで見た問題を解決するための要件を開発する際に、あらゆるアプローチを自由に取ることができました。彼らの最終的なアプローチは、IDRの要件だけでなく、完全な将来のルーティングとアドレス指定アーキテクチャの要件を文書化しました。
Simultaneously, an independent effort was started in Sweden with a similar goal. A team, calling itself Babylon, with participation from vendors, service providers, and academia, assembled to understand the history of inter-domain routing, to research the problems seen by the service providers, and to develop a proposal of requirements for a follow-on to the current routing architecture. This group's approach required an evolutionary approach starting from current routing architecture and practice. In other words, the group limited itself to developing an evolutionary strategy and consequently assumed that the architecture would probably remain domain-based. The Babylon group was later folded into the IRTF RRG as Sub-Group B to distinguish it from the original RRG Sub-Group A.
同時に、スウェーデンでも同様の目標で独立した努力が開始されました。ベンダー、サービスプロバイダー、および学界からの参加を含むバビロンと呼ばれるチームは、ドメイン間ルーティングの歴史を理解し、サービスプロバイダーが見た問題を調査し、フォローの要件の提案を作成するために集まりました。現在のルーティングアーキテクチャに。このグループのアプローチには、現在のルーティングアーキテクチャと実践から始まる進化的アプローチが必要でした。言い換えれば、グループは進化戦略の開発に限定され、その結果、アーキテクチャがおそらくドメインベースのままであると仮定しました。バビロングループは、後にサブグループとしてIRTF RRGに折りたたまれ、元のRRGサブグループAと区別されます。
This document, which was a part of Sub-Group B's output, provides a snapshot of the state of Inter-Domain Routing (IDR) at the time of original writing (2001) with some minor updates to take into account developments since that date, bringing it up to date in 2006. The development of the new requirements set was then motivated by an analysis of the problems that IDR has been encountering in the recent past. This document is intended as a counterpart to the Routing Requirements document ("A Set of Possible Requirements for a Future Routing Architecture"), which documents the requirements for future routing systems as captured separately by the IRTF RRG Sub-Groups A and B [RFC5772].
サブグループBの出力の一部であるこのドキュメントは、オリジナルライティング（2001）の時点でドメイン間ルーティングの状態（IDR）のスナップショットを提供し、その日以来開発を考慮に入れるためのいくつかのマイナーアップデートを提供します。2006年に最新の状態になりました。その後、新しい要件セットの開発は、最近のIDRが遭遇した問題の分析によって動機付けられました。このドキュメントは、ルーティング要件ドキュメント（「将来のルーティングアーキテクチャのための一連の要件」）に対応することを目的としています。]。
The IRTF RRG supported publication of this document as a historical record of the work completed on the understanding that it does not necessarily represent either the latest technical understanding or the technical consensus of the research group at the time of publication. The document has had substantial review by members of the Babylon team, members of the IRTF RRG, and others over the years.
IRTF RRGは、この文書の出版物が、出版時の研究グループの最新の技術的理解または技術的コンセンサスを必ずしも表すとは限らないという理解について完成した作品の歴史的記録としてサポートしました。この文書は、Babylonチームのメンバー、IRTF RRGのメンバー、その他の長年にわたってかなりのレビューを行ってきました。
For the greater part of its existence, the Internet has used a domain-oriented routing system whereby the routers and other nodes making up the infrastructure are partitioned into a set of administrative domains, primarily along ownership lines. Individual routing domains (also known as Autonomous Systems (ASs)), which maybe a subset of an administrative domain, are made up of a finite, connected set of nodes (at least in normal operation). Each routing domain is subject to a coherent set of routing and other policies managed by a single administrative authority. The domains are interlinked to form the greater Internet, producing a very large network: in practice, we have to treat this network as if it were infinite in extent as there is no central knowledge about the whole network of domains. An early presentation of the concept of routing domains can be found in Paul Francis' OSI routing architecture paper from 1987 [Tsuchiya87] (Paul Francis was formerly known as Paul Tsuchiya).
その存在の大部分について、インターネットはドメイン指向のルーティングシステムを使用しており、それにより、インフラストラクチャを構成するルーターや他のノードが主に所有権に沿って、管理ドメインのセットに分割されます。おそらく、管理ドメインのサブセットである個々のルーティングドメイン（自律システム（ASS）とも呼ばれます）は、有限の接続されたノードのセットで構成されています（少なくとも通常の動作では）。各ルーティングドメインは、単一の管理当局によって管理されるルーティングの一貫したセットおよびその他のポリシーの対象となります。ドメインは相互にリンクされて、より大きなインターネットを形成し、非常に大きなネットワークを生成します。実際には、ドメインのネットワーク全体に関する中心的な知識がないため、このネットワークを無限に扱う必要があります。ルーティングドメインの概念の初期のプレゼンテーションは、1987年のポールフランシスのOSIルーティングアーキテクチャペーパー[Tsuchiya87]にあります（ポールフランシスは以前はポールツキヤとして知られていました）。
The domain concept and domain-oriented routing has become so fundamental to Internet-routing thinking that it is generally taken as an axiom these days and not even defined again (cf., [NewArch03]). The issues discussed in the present document notwithstanding, it has proved to be a robust and successful architectural concept that brings with it the possibility of using different routing mechanisms and protocols within the domains (intra-domain) and between the domains (inter-domain). This is an attractive division, because intra-domain protocols can exploit the well-known finite scope of the domain and the mutual trust engendered by shared ownership to give a high degree of control to the domain administrators, whereas inter-domain routing lives in an essentially infinite region featuring a climate of distrust built on a multitude of competitive commercial agreements and driven by less-than-fully-public policies from each component domain. Of course, like any other assumption that has been around for a very long time, the domain concept should be reevaluated to make sure that it is still helping!
ドメインの概念とドメイン指向のルーティングは、最近では一般的に公理と見なされており、再び定義されていないインターネットルーティングの考えの基本的なものになっています（[Newarch03]）。現在の文書で説明した問題にもかかわらず、ドメイン内（ドメイン内）およびドメイン間（ドメイン間）内で異なるルーティングメカニズムとプロトコルを使用する可能性をもたらす堅牢で成功したアーキテクチャの概念であることが証明されています。。ドメイン内プロトコルは、ドメインのよく知られている有限範囲と共有所有権によって生み出される相互信頼を活用してドメイン管理者に高度な制御を与えるのに対し、ドメイン間ルーティングの生活を提供することができるため、これは魅力的な部門です。多数の競争力のある商業協定に基づいて構築された不信感の環境を特徴とする本質的に無限の地域は、各コンポーネントドメインからの公開されていない政策によって推進されています。もちろん、非常に長い間存在してきた他の仮定と同様に、ドメインの概念を再評価して、それがまだ役立っていることを確認する必要があります！
It is generally accepted that there are major shortcomings in the inter-domain routing of the Internet today and that these may result in severe routing problems within an unspecified period of time. Remedying these shortcomings will require extensive research to tie down the exact failure modes that lead to these shortcomings and identify the best techniques to remedy the situation. Comparatively, intra-domain routing works satisfactorily, and issues with intra-domain routing are mainly associated with the interface between intra- and inter-domain routing.
一般的に、今日のインターネットのドメイン間ルーティングに大きな欠点があり、これらが不特定の期間内に深刻なルーティングの問題をもたらす可能性があることが認められています。これらの欠点を是正するには、これらの欠点につながる正確な障害モードを結び付け、状況を改善するための最良のテクニックを特定するための広範な研究が必要です。それに比べて、ドメイン内ルーティングは十分に機能し、ドメイン内ルーティングの問題は、主にドメイン間ルーティングとインター間ルーティングの間のインターフェースに関連付けられています。
Reviewer's Note: Even in 2001, there was a wide difference of opinion across the community regarding the shortcomings of inter-domain routing. In the years between writing and publication, further analysis, changes in operational practice, alterations to the demands made on inter-domain routing, modifications made to BGP and a recognition of the difficulty of finding a replacement may have altered the views of some members of the community.
レビュアーのメモ：2001年でさえ、ドメイン間ルーティングの欠点に関して、コミュニティ全体で幅広い意見の違いがありました。執筆と出版の間に、さらなる分析、運用慣行の変化、ドメイン間ルーティングの要求の変更、BGPに加えられた修正、および交換を見つけることの難しさの認識が、一部のメンバーの見解が変わった可能性があります。地域社会・共同体。
Changes in the nature and quality of the services that users want from the Internet are difficult to provide within the current framework, as they impose requirements never foreseen by the original architects of the Internet routing system.
ユーザーがインターネットから望むサービスの性質と品質の変化は、インターネットルーティングシステムの元のアーキテクトが決して予測していない要件を課すため、現在のフレームワーク内で提供するのが困難です。
The kind of radical changes that have to be accommodated are epitomized by the advent of IPv6 and the application of IP mechanisms to private commercial networks that offer specific service guarantees beyond the best-effort services of the public Internet. Major changes to the inter-domain routing system are inevitable to provide an efficient underpinning for the radically changed and increasingly commercially-based networks that rely on the IP protocol suite.
収容しなければならない根本的な変化の種類は、IPv6の出現と、パブリックインターネットのベストエフォートサービスを超えて特定のサービス保証を提供するプライベート商業ネットワークへのIPメカニズムの適用により象徴されています。ドメイン間ルーティングシステムの主要な変更は、IPプロトコルスイートに依存する根本的に変更され、ますます商業的にベースのネットワークに効率的な基盤を提供するために避けられません。
Current practice stresses the need to separate the concerns of the control plane and the forwarding plane in a router: this document will follow this practice, but we still use the term "routing" as a global portmanteau to cover all aspects of the system.
現在の練習は、コントロールプレーンと転送面の懸念をルーターで分離する必要性を強調しています。このドキュメントはこの慣行に従いますが、「ルーティング」という用語をグローバルポートマントーとして使用して、システムのすべての側面をカバーしています。
This document provides a historical perspective on the current state of inter-domain routing and its relationship to intra-domain routing in Section 3 by revisiting the previous IETF requirements document intended to steer the development of a future routing system. These requirements, which informed the design of the Border Gateway Protocol (BGP) in 1989, are contained in RFC 1126 -- "Goals and Functional Requirements for Inter-Autonomous System Routing" [RFC1126].
このドキュメントは、将来のルーティングシステムの開発を操縦することを目的とした以前のIETF要件ドキュメントを再検討することにより、セクション3のドメイン間ルーティングの現在の状態とドメイン内ルーティングとの関係に関する歴史的な視点を提供します。1989年にBorder Gateway Protocol（BGP）の設計を通知したこれらの要件は、RFC 1126に含まれています。
Section 3 also looks at some other work on requirements for domain-based routing that was carried out before and after RFC 1126 was published. This work fleshes out the historical perspective and provides some additional insights into alternative approaches that may be instructive when building a new set of requirements.
セクション3では、RFC 1126が公開された前後に実行されたドメインベースのルーティングの要件に関する他の作業も検討しています。この作品は、歴史的な視点を具体化し、新しい一連の要件を構築する際に有益な代替アプローチに関するいくつかの追加の洞察を提供します。
The motivation for change and the inspiration for some of the requirements for new routing architectures derive from the problems attributable to the current domain-based routing system that are being experienced in the Internet today. These will be discussed in Section 5.
変化の動機と、新しいルーティングアーキテクチャの要件のいくつかのインスピレーションは、今日のインターネットで経験されている現在のドメインベースのルーティングシステムに起因する問題に由来しています。これらについては、セクション5で説明します。
Today's Internet uses an addressing and routing structure that has developed in an ad hoc, more or less upwards-compatible fashion. The structure has progressed from supporting a non-commercial Internet with a single administrative domain to a solution that is able to control today's multi-domain, federated Internet, carrying traffic between the networks of commercial, governmental, and not-for-profit participants. This is not achieved without a great deal of 24/7 vigilance and operational activity by network operators: Internet routing often appears to be running close to the limits of stability. As well as directing traffic to its intended endpoint, inter-domain routing mechanisms are expected to implement a host of domain-specific routing policies for competing, communicating domains. The result is not ideal, particularly as regards inter-domain routing mechanisms, but it does a pretty fair job at its primary goal of providing any-to-any connectivity to many millions of computers.
今日のインターネットは、多かれ少なかれ上向きに互換性のあるファッションで開発されたアドレス指定とルーティングの構造を使用しています。この構造は、単一の管理ドメインを備えた非営利インターネットをサポートすることから、今日のマルチドメイン、フェデレーションインターネットを制御できるソリューションに進み、商業、政府、非営利の参加者のネットワーク間のトラフィックを運ぶことができます。これは、ネットワークオペレーターによる24時間年中無休の警戒と運用活動が大幅に達成されずに達成されることはありません。インターネットルーティングは、安定性の限界近くで実行されているように見えることがよくあります。意図されたエンドポイントにトラフィックを向けるだけでなく、ドメイン間ルーティングメカニズムは、競合するドメインの通信のためのドメイン固有のルーティングポリシーのホストを実装することが期待されています。結果は理想的ではありません。特にドメイン間のルーティングメカニズムに関しては、何百万ものコンピューターに何百万ものコンピューターに接続することを提供するという主要な目標でかなり公平な仕事をしています。
Based on a large body of anecdotal evidence, but also on a growing body of experimental evidence [Labovitz02] and analytic work on the stability of BGP under certain policy specifications [Griffin99], the main Internet inter-domain routing protocol, BGP version 4 (BGP-4), appears to have a number of problems. These problems are discussed in more detail in Section 5. Additionally, the hierarchical nature of the inter-domain routing problem appears to be changing as the connectivity between domains becomes increasingly meshed [RFC3221], which alters some of the scaling and structuring assumptions on which BGP-4 is built. Patches and fix-ups may relieve some of these problems, but others may require a new architecture and new protocols.
逸話的な証拠の大きな本体に基づいているだけでなく、特定のポリシー仕様[Griffin99]、BGPバージョン4（BGPバージョン4（Griffin99]に基づくBGPの安定性に関する実験的証拠の増加」と分析作業にも基づいています（Griffin99]（Griffin99]BGP-4）、多くの問題があるようです。これらの問題については、セクション5で詳細に説明します。さらに、ドメイン間の接続性がますますメッシュ化されるにつれて、ドメイン間ルーティングの問題の階層的性質は変化しているように見えます[RFC3221]。BGP-4が構築されています。パッチと修正はこれらの問題のいくつかを緩和するかもしれませんが、他のものは新しいアーキテクチャや新しいプロトコルを必要とする場合があります。
RFC 1126 [RFC1126] outlined a set of requirements that were intended to guide the development of BGP.
RFC 1126 [RFC1126]は、BGPの開発を導くことを目的とした一連の要件を概説しました。
Editors' Note: When this document was reviewed by Yakov Rekhter, one of the designers of BGP, his view was that "While some people expected a set of requirements outlined in RFC 1126 to guide the development of BGP, in reality the development of BGP happened completely independently of RFC 1126. In other words, from the point of view of the development of BGP, RFC 1126 turned out to be totally irrelevant". On the other hand, it appears that BGP, as currently implemented, has met a large proportion of these requirements, especially for unicast traffic.
編集者注：BGPのデザイナーの1人であるYakov Rekhterによってこのドキュメントがレビューされたとき、彼の見解は「RFC 1126で概説された一連の要件がBGPの開発を導くために、実際にはBGPの開発を導くことを期待していました。言い換えれば、BGPの開発の観点から、RFC 1126はまったく無関係であることが判明しました」。一方、現在実装されているBGPは、特にユニキャストトラフィックについて、これらの要件の大部分を満たしているようです。
While the network is demonstrably different from what it was in 1989, having:
ネットワークは1989年のものとは明らかに異なりますが、
o moved from single to multiple administrative control,
o シングルから複数の管理制御に移動し、
o increased in size by several orders of magnitude, and
o サイズが数桁増加し、
o migrated from a fairly tree-like connectivity graph to a meshier style
o かなりの木のような接続グラフからメッシャースタイルに移行しました
many of the same requirements remain. As a first step in setting requirements for the future, we need to understand the requirements that were originally set for the current protocols. In charting a future architecture, we must first be sure to do no harm. This means a future domain-based routing system has to support, as its base requirement, the level of function that is available today.
同じ要件の多くが残っています。将来の要件を設定するための最初のステップとして、現在のプロトコルにも当初設定されていた要件を理解する必要があります。将来のアーキテクチャのチャートにおいて、まず害を及ぼさないでください。これは、将来のドメインベースのルーティングシステムが、その基本要件として、今日利用可能な機能のレベルをサポートする必要があることを意味します。
The following sections each relate to a requirement, or non-requirement listed in RFC 1126. In fact, the section names are direct quotes from the document. The discussion of these requirements covers the following areas:
次のセクションは、それぞれ要件、またはRFC 1126にリストされている非追跡に関連しています。実際、セクション名はドキュメントからの直接引用です。これらの要件の議論は、次の領域をカバーしています。
Explanation: Optional interpretation for today's audience of the original intent of the requirement.
説明：要件の元の意図の今日の聴衆のためのオプションの解釈。
Relevance: Is the requirement of RFC 1126 still relevant, and to what degree? Should it be understood differently in today's environment?
関連性：RFC 1126の要件は依然として関連していますか？今日の環境では違って理解されるべきですか？
Current practice: How well is the requirement met by current protocols and practice?
現在の練習：現在のプロトコルと実践によって要件はどの程度満たされていますか？
Timely routing to all reachable destinations, including multi-homing and multicast.
マルチホミングやマルチキャストを含むすべての到達可能な目的地へのタイムリーなルーティング。
Relevance: Valid, but requirements for multi-homing need further discussion and elucidation. The requirement should include multiple-source multicast routing.
関連性：有効ですが、マルチホーミングの要件にはさらなる議論と解明が必要です。要件には、マルチソースマルチキャストルーティングを含める必要があります。
Current practice: Multi-homing is not efficient, and the proposed inter-domain multicast protocol Border Gateway Multicast Protocol (BGMP) [RFC3913] is an add-on to BGP following many of the same strategies but not integrated into the BGP framework.
現在の練習：マルチホミングは効率的ではなく、提案されているドメイン間マルチキャストプロトコルボーダーゲートウェイマルチキャストプロトコル（BGMP）[RFC3913]は、同じ戦略の多くに従ってBGPへのアドオンですが、BGPフレームワークに統合されていません。
Editors' Note: Multicast routing has moved on again since this was originally written. By 2006, BGMP had been effectively superseded. Multicast routing now uses Multi-protocol BGP [RFC4760], the Multicast Source Discovery Protocol (MSDP) [RFC3618], and Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC2362], [RFC4601], especially the Source Specific Multicast (SSM) subset.
編集者注：これが最初に書かれて以来、マルチキャストルーティングが再び進みました。2006年までに、BGMPは効果的に置き換えられました。マルチキャストルーティングは、マルチプロトコルBGP [RFC4760]、マルチキャストソースディスカバリープロトコル（MSDP）[RFC3618]、およびプロトコル独立マルチキャスト - スパルスモード（PIM-SM）[RFC2362]、[RFC4601]、[RFC2362]、[RFC2362]、[RFC2362]、[RFC2362]を使用するようになりました。SSM）サブセット。
This requires that a user be notified within a reasonable time period after persistent attempts, about inability to provide a service.
これには、サービスを提供できないことについて、持続的な試みの後、合理的な期間内にユーザーに通知する必要があります。
Relevance: Valid.
関連性：有効です。
Current practice: There are ICMP messages for this; but, in many cases, they are not used, either because of fears about creating message storms or uncertainty about whether the end system can do anything useful with the resulting information. IPv6 implementations may be able to make better use of the information as they may have alternative addresses that could be used to exploit an alternative routing.
現在の練習：これにはICMPメッセージがあります。しかし、多くの場合、メッセージの嵐を作成することに対する恐怖や、結果の情報で最終システムが有用なことを行うことができるかどうかについての不確実性のために、それらは使用されません。IPv6の実装は、代替ルーティングを悪用するために使用できる代替アドレスがある可能性があるため、情報をより適切に使用できる場合があります。
The architecture was designed to accommodate the growth of the Internet.
アーキテクチャは、インターネットの成長に対応するように設計されています。
Relevance: Valid. Properties of Internet topology might be an issue for future scalability (topology varies from very sparse to quite dense at present). Instead of setting out to accommodate growth in a specific time period, indefinite growth should be accommodated. On the other hand, such growth has to be accommodated without making the protocols too expensive -- trade-offs may be necessary.
関連性：有効です。インターネットトポロジの特性は、将来のスケーラビリティの問題である可能性があります（トポロジーは、非常にまばらなものから非常に密なものまでさまざまです）。特定の期間に成長に対応するために出発する代わりに、無期限の成長に対応する必要があります。一方、そのような成長は、プロトコルを高価にすることなく対応する必要があります。トレードオフが必要になる場合があります。
Current practice: Scalability of the current protocols will not be sufficient under the current rate of growth. There are problems with BGP convergence for large dense topologies, problems with the slow speed of routing information propagation between routers in transit domains through the intra-domain protocol, for example, when a failure requires traffic to be redirected to an alternative exit point from the domain (see Section 5.9), limited support for hierarchy, etc.
現在の実践：現在の成長率では、現在のプロトコルのスケーラビリティは十分ではありません。大規模な密なトポロジーのBGP収束には問題があります。輸送ドメインのルーター間のルーティング情報伝播の遅い速度の問題は、ドメイン内プロトコルを介して輸送ドメイン間のルーター間の問題です。ドメイン（セクション5.9を参照）、階層の限られたサポートなど。
This requirement encapsulates the need for administrative domains ("Autonomous Systems" - AS) to be able to operate autonomously as regards setting routing policy:
この要件は、ルーティングポリシーの設定に関して自律的に動作できるようにするための管理ドメイン（「自律システム」 - AS）の必要性をカプセル化します。
Relevance: Valid. There may need to be additional requirements for adjusting policy decisions to the global functionality and for avoiding contradictory policies. This would decrease the possibility of unstable routing behavior.
関連性：有効です。ポリシーの決定をグローバルな機能に調整し、矛盾するポリシーを回避するために、追加の要件が必要になる場合があります。これにより、不安定なルーティング動作の可能性が低下します。
There is a need for handling various degrees of trust in autonomous operations, ranging from no trust (e.g., between separate ISPs) to very high trust where the domains have a common goal of optimizing their mutual policies.
自律的な運用に対するさまざまな程度の信頼を処理する必要があります。これは、ドメインが相互ポリシーを最適化するという共通の目標を持っている非常に高い信頼に至るまで、信頼なし（例えば、個別のISPの間）に至るまでです。
Policies for intra-domain operations should, in some cases, be revealed, using suitable abstractions.
ドメイン内操作のポリシーは、場合によっては、適切な抽象化を使用して明らかにする必要があります。
Current practice: Policy management is in the control of network managers, as required, but there is little support for handling policies at an abstract level for a domain.
現在の実践：ポリシー管理は、必要に応じてネットワークマネージャーの制御にありますが、ドメインの抽象レベルでポリシーを処理するサポートはほとんどありません。
Cooperating administrative entities decide about the extent of cooperation independently. This can lead to inconsistent, and potentially incompatible routing policies being applied in notionally cooperating domains. As discussed in Sections 5.2, 5.3, and 5.10, lack of coordination combined with global range of effects of BGP policies results in occasional disruption of Internet routing over an area far wider than the domains that are not cooperating effectively.
協力する管理事業体は、協力の程度を独立して決定します。これは、概念的に協力するドメインに適用される一貫性のない、潜在的に互換性のないルーティングポリシーにつながる可能性があります。セクション5.2、5.3、および5.10で説明したように、調整の欠如は、BGPポリシーのグローバルな影響範囲の影響を組み合わせて、効果的に協力していないドメインよりもはるかに広い地域でのインターネットルーティングが時折破壊されます。
The routing environment is a distributed system. The distributed routing environment supports redundancy and diversity of nodes and links. Both the controlling rule sets, which implement the routing policies, and the places where operational control is applied, through decisions on path selection, are distributed (primarily in the routers).
ルーティング環境は分散システムです。分散ルーティング環境は、ノードとリンクの冗長性と多様性をサポートします。ルーティングポリシーを実装する制御ルールセットと、パス選択の決定を通じて運用制御が適用される場所は、（主にルーターに）分散されます。
Relevance: Valid. RFC 1126 is very clear that we should not be using centralized solutions, but maybe we need a discussion on trade-offs between common knowledge and distribution (i.e., to allow for uniform policy routing, e.g., Global System for Mobile Communications (GSM) systems are in a sense centralized, but with hierarchies).
関連性：有効です。RFC 1126は、集中化されたソリューションを使用すべきではないことを非常に明確にしていますが、一般的な知識と配布のトレードオフに関する議論が必要である可能性があります（つまり、均一なポリシールーティング、例えばモバイルコミュニケーションのグローバルシステム（GSM）システムを可能にするためにある意味で集中化されていますが、階層があります）。
Current practice: Routing is very distributed, but lacking the ability to consider optimization over several hops or domains.
現在の練習：ルーティングは非常に分散されていますが、いくつかのホップまたはドメインにわたって最適化を考慮する能力がありません。
Editors' Note: Also, coordinating the implementation of a set of routing policies across a large domain with many routers running BGP is difficult. The policies have to be turned into BGP rules and applied individually to each router, giving opportunities for mismatch and error.
編集者注：また、BGPを実行している多くのルーターを使用して、大規模なドメインで一連のルーティングポリシーの実装を調整することは困難です。ポリシーをBGPルールに変え、各ルーターに個別に適用する必要があり、不一致とエラーの機会が与えられます。
The routing environment and services should be based upon mechanisms and information that exhibit both integrity and security. That is, the routers should always be working with credible data derived through the reliable operation of protocols. Security from unwanted modification and influence is required.
ルーティング環境とサービスは、完全性とセキュリティの両方を示すメカニズムと情報に基づいている必要があります。つまり、ルーターは常に、プロトコルの信頼できる動作を通じて導出された信頼できるデータを使用して動作する必要があります。不要な変更と影響からのセキュリティが必要です。
Relevance: Valid.
関連性：有効です。
Current practice: BGP provides a limited mechanism for authentication and security of peering sessions, but this does not guarantee the authenticity or validity of the routing information that is exchanged.
There are certainly security problems with the current practice. The Routing Protocol Security Requirements (rpsec) working group has been struggling to agree on a set of requirements for BGP security since early 2002.
確かに現在のプラクティスにはセキュリティの問題があります。ルーティングプロトコルセキュリティ要件（RPSEC）ワーキンググループは、2002年初頭からBGPセキュリティの一連の要件に同意することに苦労しています。
Editors' Note: Proposals for authenticating BGP routing information using certificates were under development by the Secure Inter-Domain Routing (sidr) working group from 2006 through 2008.
This requires that the routing system provides adequate information on the state of the network to allow resource, problem, and fault management to be carried out effectively and expeditiously. The system must also provide controls that allow managers to use this information to make informed decisions and use it to control the operation of the routing system.
これには、ルーティングシステムがネットワークの状態に関する適切な情報を提供して、リソース、問題、障害管理を効果的かつ迅速に実行できるようにする必要があります。また、システムは、管理者がこの情報を使用して情報に基づいた決定を下し、ルーティングシステムの動作を制御するために使用できるようにするコントロールを提供する必要があります。
Relevance: The requirement is reasonable, but we might need to be more specific on what information should be available, e.g., to prevent routing oscillations.
関連性：要件は合理的ですが、ルーティング振動を防ぐために、どの情報を利用できるかについて、より具体的にする必要がある場合があります。
Current practice: All policies are determined locally, where they may appear reasonable but there is limited global coordination through the routing policy databases operated by the Internet registries (AfriNIC, APNIC, ARIN, LACNIC, RIPE, etc.).
現在の慣行：すべてのポリシーはローカルで決定されており、そこでは合理的に見えるかもしれませんが、インターネットレジストリ（Afrinic、Apnic、Arin、Lacnic、Ripeなど）が運営するルーティングポリシーデータベースを通じてグローバルな調整が限られています。
Operators are not required to register their policies; even when policies are registered, it is difficult to check that the actual policies in use in other domains match the declared policies. Therefore, a manager cannot guarantee to design and implement policies that will interoperate with those of other domains to provide stable routing.
オペレーターはポリシーを登録する必要はありません。ポリシーが登録されている場合でも、他のドメインで使用されている実際のポリシーが宣言されたポリシーと一致することを確認することは困難です。したがって、マネージャーは、他のドメインのポリシーと相互運用して安定したルーティングを提供するポリシーを設計および実装することを保証することはできません。
Editors' Note: Operators report that management of BGP-based routing remains a function that needs highly-skilled operators and continual attention.
編集者の注：オペレーターは、BGPベースのルーティングの管理は、高度なスキルのオペレーターと継続的な注意を必要とする関数のままであると報告しています。
Relevance: Valid. However, the paragraph states that assumptions on significant upgrades shouldn't be made. Although this is reasonable, a new architecture should perhaps be prepared to use upgrades when they occur.
関連性：有効です。ただし、段落では、重要なアップグレードに関する仮定は行われないでください。これは合理的ですが、新しいアーキテクチャは、おそらくアップグレードが発生したときに使用する準備をする必要があります。
Current practice: Most bandwidth is consumed by the exchange of the Network Layer Reachability Information (NLRI). Usage of processing cycles ("Central Processor Usage" - CPU) depends on the stability of the Internet. Both phenomena have a local nature, so there are not scaling problems with bandwidth and CPU usage. Instability of routing increases the consumption of resources in any case. The number of networks in the Internet dominates memory requirements -- this is a scaling problem.
現在の練習：ほとんどの帯域幅は、ネットワーク層の到達可能性情報（NLRI）の交換によって消費されます。処理サイクルの使用（ "Central Processor Usage" -CPU）は、インターネットの安定性に依存します。両方の現象には地元の性質があるため、帯域幅とCPUの使用に関する問題はありません。ルーティングの不安定性は、いずれにせよ、リソースの消費を増加させます。インターネット内のネットワークの数は、メモリ要件を支配します。これはスケーリングの問題です。
Relevance: Valid. Should perhaps be stronger. Only providing a best-effort attempt may not be enough if real-time services are to be provided for. Detection of failures may need to be faster than 100 ms to avoid being noticed by end-users.
関連性：有効です。おそらく強くなるはずです。リアルタイムサービスを提供する場合にのみ、最良の試みを提供するだけでは不十分な場合があります。エンドユーザーが気づかないように、障害の検出は100ミリ秒より速くなる必要がある場合があります。
Current practice: Latency of fail-over is too high; sometimes minutes or longer.
現在の練習：フェールオーバーの遅延が高すぎます。時には数分以上。
Relevance: Valid. Loops should occur only with negligible probability and duration.
関連性：有効です。ループは、無視できる確率と期間でのみ発生する必要があります。
Current practice: Both link-state intra-domain routing and BGP inter-domain routing (if correctly configured) are forwarding-loop-free after having converged. However, convergence time for BGP can be very long, and poorly designed routing policies may result in a number of BGP speakers engaging in a cyclic pattern of advertisements and withdrawals that never converges to a stable result [RFC3345]. Part of the reason for long convergence times is the non-locality of the effects of changes in BGP advertisements (see Section 5.3). Modifying the inter-domain routing protocol to make the effects of changes less global, and convergence a more local condition, might improve performance, assuming a suitable modification could be developed.
現在の練習：リンク状態内のドメイン内ルーティングとBGPインタードメインルーティング（正しく構成されている場合）は、収束後に転送されない転送です。ただし、BGPの収束時間は非常に長くなる可能性があり、設計が不十分なルーティングポリシーにより、安定した結果に収束しない広告と引き出しの周期的なパターンに従事する多くのBGPスピーカーが生じる可能性があります[RFC3345]。長い収束時間の理由の一部は、BGP広告の変化の影響の非自発性です（セクション5.3を参照）。ドメイン間ルーティングプロトコルを変更して、変化の影響をグローバルにし、収束をよりローカルな状態にすると、適切な変更が開発される可能性があると仮定して、パフォーマンスが改善される可能性があります。
Relevance: Valid to some extent, but there is a trade-off between aggregation and immediate knowledge of reachability. It requires that routing tables contain enough information to determine that the destination is unknown or a path cannot be constructed to reach it.
関連性：ある程度有効ですが、集約と到達可能性に関する即時の知識の間にはトレードオフがあります。ルーティングテーブルには、宛先が不明であるか、パスを構築して到達することができないと判断するのに十分な情報が含まれている必要があります。
Current practice: Knowledge about lost reachability propagates slowly through the networks due to slow convergence for route withdrawals.
現在の実践：失われた到達可能性に関する知識は、ルートの引き出しのための収束が遅いため、ネットワークを介してゆっくりと伝播します。
Relevance: Valid. Policy control of routing has become increasingly important as the Internet has turned into a business.
関連性：有効です。インターネットがビジネスに変わったため、ルーティングの政策管理はますます重要になっています。
Current practice: Supported to some extent. Policies can only be applied locally in an AS and not globally. Policy information supplied has a very small probability of affecting policies in other ASs. Furthermore, only static policies are supported; between static policies and policies dependent upon volatile events of great celerity, there should exist events of which routing should be aware. Lastly, there is no support for policies other than route-properties (such as AS-origin, AS-path, destination prefix, Multi-Exit Discriminator-values (MED-values), etc).
現在の実践：ある程度サポートされています。ポリシーは、グローバルではなく、ASでのみローカルに適用できます。提供される政策情報は、他のロバのポリシーに影響を与える可能性が非常に少ない。さらに、静的ポリシーのみがサポートされています。偉大なセレリティの揮発性イベントに依存する静的ポリシーとポリシーの間で、ルーティングが注意すべきイベントが存在するはずです。最後に、ルートプロパティ（As-Origin、As-Path、Destination Prefix、Multi-Exhit Disfrinator-Values（Med-Values）など）以外のポリシーはサポートされていません。
Editors' Note: Subsequent to the original issue of this document, mechanisms that acknowledge the business relationships of operators have been developed such as the NOPEER community attribute [RFC3765]. However, the level of usage of this attribute is apparently not very great.
編集者注：このドキュメントの元の問題に続いて、オペレーターのビジネス関係を認めるメカニズムは、Noper Community属性[RFC3765]などの開発されています。ただし、この属性の使用レベルは明らかにあまり大きくありません。
Relevance: Valid to some extent, as they may conflict with the policies of the network administrator. It is likely that this requirement will be met by means of different bit-transport services offered by an operator, but at the cost of adequate provisioning, authentication, and policing when utilizing the service.
関連性：ネットワーク管理者のポリシーと競合する可能性があるため、ある程度有効です。この要件は、オペレーターが提供するさまざまなビットトランスポートサービスによって満たされる可能性がありますが、サービスを利用する際には、適切なプロビジョニング、認証、およびポリシングを犠牲にします。
Current practice: Not supported in normal routing. Can be accomplished to some extent with loose source routing, resulting in inefficient forwarding in the routers. The various attempts to introduce Quality of Service (QoS -- e.g., Integrated Services and Differentiated Services (Diffserv)) can also be seen as means to support this requirement, but they have met with limited success in terms of providing alternate routes as opposed to providing improved service on the standard route.
現在の練習：通常のルーティングではサポートされていません。ゆるいソースルーティングである程度達成することができ、ルーターで非効率的な転送をもたらすことができます。サービス品質を導入するためのさまざまな試み（QOS-統合サービスや差別化されたサービス（diffserv）もこの要件をサポートする手段と見なすことができますが、代理ではなく代替ルートを提供するという点で限られた成功を収めています。標準ルートで改善されたサービスを提供します。
Editors' Note: From the standpoint of a later time, it would probably be more appropriate to say "total failure" rather than "limited success".
編集者の注：後の時代の観点から、「限られた成功」ではなく「完全な失敗」と言う方がおそらくより適切でしょう。
Relevance: Valid to some extent, as they may conflict with the policies of the operator. It is likely that this requirement will be met by means of different bit-transport services offered by an operator, but at the cost of adequate provisioning, authentication, and policing when utilizing the service. It has become clear that offering to provide a particular QoS to any arbitrary destination from a particular source is generally impossible: QoS, except in very "soft" forms such as overall long-term average packet delay, is generally associated with connection-oriented routing.
関連性：オペレーターのポリシーと矛盾する可能性があるため、ある程度有効です。この要件は、オペレーターが提供するさまざまなビットトランスポートサービスによって満たされる可能性がありますが、サービスを利用する際には、適切なプロビジョニング、認証、およびポリシングを犠牲にします。特定のソースからあらゆる任意の目的地に特定のQoSを提供するための提供は一般に不可能であることが明らかになりました。QoSは、全体的な長期平均パケット遅延などの非常に「ソフト」フォームを除き、一般に接続指向のルーティングに関連付けられています。。
Current practice: Creating routes with specified QoS is not generally possible at present.
現在の練習：現在、指定されたQoSを使用してルートを作成することは一般に不可能です。
Relevance: Inter- and intra-domain routing should stay independent, but one should notice that this, to some extent, contradicts the previous three requirements. There is a trade-off between abstraction and optimality.
関連性：ドメイン内およびドメイン内のルーティングは独立したままである必要がありますが、これはある程度、以前の3つの要件と矛盾することに気付くはずです。抽象化と最適性の間にはトレードオフがあります。
Current practice: Inter-domain routing is performed independently of intra-domain routing. Intra-domain routing is however, especially in transit domains, very interrelated with inter-domain routing.
現在の練習：ドメイン間ルーティングは、ドメイン内ルーティングとは無関係に実行されます。ただし、ドメイン内ルーティングは、特に輸送ドメインでは、ドメイン間ルーティングと非常に関連しています。
Relevance: Valid.
関連性：有効です。
Current practice: As explained in Section 3.1.2.1.7, intra-domain forwarding in transit domains is dependent on inter-domain forwarding decisions.
現在の慣行：セクション3.1.2.1.7で説明されているように、輸送ドメインのドメイン内転送は、ドメイン間転送の決定に依存しています。
Relevance: Valid, and increasingly important in the context of enforcing policies correctly expressed through routing advertisements but flouted by rogue peers that send traffic for which a route has not been advertised. On the other hand, packets that have been misrouted due to transient routing problems perhaps should be forwarded to reach the destination, although along an unexpected path.
関連性：ルーティング広告を通じて正しく表現されているが、ルートが宣伝されていないトラフィックを送信する不正な仲間によってflされたポリシーを正しく表現するというコンテキストでは、有効であり、ますます重要になっています。一方、一時的なルーティングの問題のために誤って扱われたパケットは、予想外の経路に沿っていますが、おそらく目的地に到達するために転送する必要があります。
Current practice: At stub domains (i.e., domains that do not provide any transit service for any other domains but that connect directly to one or more transit domains), there is packet filtering, e.g., to catch source address spoofing on outgoing traffic or to filter out unwanted incoming traffic. Filtering can in particular reject traffic (such as unauthorized transit traffic) that has been sent to a domain even when it has not advertised a route for such traffic on a given interface. The growing class of "middleboxes" (midboxes, e.g., Network Address Translators -- NATs) is quite likely to apply administrative rules that will prevent the forwarding of packets. Note that security policies may deliberately hide administrative denials. In the backbone, intentional packet dropping based on policies is not common.
現在の練習：スタブドメイン（つまり、他のドメインにトランジットサービスを提供しないが、1つ以上のトランジットドメインに直接接続するドメイン）で、パケットフィルタリングがあります。不要な着信トラフィックを除外します。フィルタリングは、特に、特定のインターフェイス上のそのようなトラフィックのルートを宣伝していない場合でもドメインに送信されたトラフィック（不正なトランジットトラフィックなど）を拒否できます。「ミドルボックス」のクラスの成長（ミッドボックス、たとえば、ネットワークアドレス翻訳者-NAT）は、パケットの転送を妨げる管理ルールを適用する可能性が非常に高くなります。セキュリティポリシーは、意図的に管理上の拒否を非表示にする可能性があることに注意してください。バックボーンでは、ポリシーに基づいた意図的なパケットドロップは一般的ではありません。
Relevance: Unclear, although it is clearly desirable to minimize the waste of forwarding resources by discarding datagrams that cannot be delivered at the earliest opportunity. There is a trade-off between scalability and keeping track of unreachable resources. The requirement effectively imposes a requirement on adjacent nodes to monitor for failures and take steps to cause rerouting at the earliest opportunity, if a failure is detected. However, packets that are already in-flight or queued on a failed link cannot generally be rescued.
関連性：不明ですが、最も早い機会で提供できないデータグラムを破棄することにより、リソースの転送の無駄を最小限に抑えることが明らかに望ましいものです。スケーラビリティと到達不能なリソースを追跡することとの間にはトレードオフがあります。この要件は、故障を監視するために隣接するノードに要件を効果的に課し、障害が検出された場合、最も早い機会に再ルーティングを引き起こすための措置を講じます。ただし、リンクに障害のあるリンクで既に照明中またはキューに留められているパケットは、一般的に救助することはできません。
Current practice: Routing protocols use both internal adjacency management sub-protocols (e.g., "hello" protocols) and information from equipment and lower-layer link watchdogs to keep track of failures in routers and connecting links. Failures will eventually result in the routing protocol reconfiguring the routing to avoid (if possible) a failed resource, but this is generally very slow (30s or more). In the meantime, datagrams may well be forwarded to failed resources. In general terms, end hosts and some non-router middleboxes do not participate in these notifications, and failures of such boxes will not affect the routing system.
現在の練習：ルーティングプロトコルは、内部隣接管理サブプロトコル（「Hello」プロトコルなど）と機器と低層リンクウォッチドッグからの情報の両方を使用して、ルーターの障害とリンクの接続を追跡します。障害は最終的にルーティングプロトコルがルーティングを再構成して（可能であれば）失敗したリソースを回避するようになりますが、これは一般的に非常に遅い（30S以上）。それまでの間、データグラムは失敗したリソースに転送される可能性があります。一般的に、エンドホストと一部の非ルーターのミドルボックスはこれらの通知に参加しておらず、そのようなボックスの障害はルーティングシステムに影響しません。
Relevance: Valid. This is necessary in enabling differentiation in the network, based on QoS, precedence, policy or security.
関連性：有効です。これは、QoS、優先順位、ポリシー、またはセキュリティに基づいて、ネットワークの差別化を可能にするために必要です。
Current practice: Ingress and egress filtering can be done based on policy. Some networks discriminate on the basis of requested QoS.
現在の練習：イングレスと出口のフィルタリングは、ポリシーに基づいて実行できます。一部のネットワークは、要求されたQoSに基づいて差別します。
Relevance: Valid. However, an alternative arrangement of information bases, possibly with an element of centralization for the domain (as mentioned in Section 3.1.1.5) might offer some advantages through the ability to optimize across the domain and respond more quickly to changes and failures.
関連性：有効です。ただし、おそらくドメインの集中化要素（セクション3.1.1.5に記載されているように）を備えた情報ベースの代替配置は、ドメイン全体で最適化し、変化と障害に対してより迅速に応答する能力を通じていくつかの利点を提供する可能性があります。
Current practice: The information base is distributed, but it is unclear whether it supports all necessary routing functionality.
現在の練習：情報ベースは分散されていますが、必要なすべてのルーティング機能をサポートするかどうかは不明です。
Relevance: Valid. It should be possible to determine the availability and levels of availability of any resource (such as bandwidth) needed to carry out routing. This prevents needing to discover unavailability through failure. Resource location and discovery is arguably a separate concern that could be addressed outside the core routing requirements.
関連性：有効です。ルーティングを実行するために必要なリソース（帯域幅など）の可用性と可用性レベルを決定することが可能です。これにより、障害による利用不能を発見する必要があります。リソースの場所と発見は、間違いなく、コアルーティング要件の外で対処できる別の懸念です。
Current practice: Resource availability is predominantly handled outside of the routing system.
現在の練習：リソースの可用性は、主にルーティングシステムの外で処理されます。
Relevance: Valid. However, certain requirements in the control plane, such as fast detection of faults may be worth consumption of more resources. Similarly, simplicity of implementation may make it cheaper to "back haul" traffic to central locations to minimize the cost of routing if bandwidth is cheaper than processing.
関連性：有効です。ただし、障害の迅速な検出など、制御プレーンの特定の要件は、より多くのリソースを消費する価値があります。同様に、実装の単純さにより、帯域幅が処理よりも安い場合、ルーティングのコストを最小限に抑えるために、中央の場所へのトラフィックを「バック運搬」するよりも安くなる可能性があります。
Current practice: BGP messages probably do not ordinarily consume excessive resources, but might during erroneous conditions. In the data plane, the nearly universal adoption of shortest-path protocols could be considered to result in minimization of transmission utilization.
現在の練習：BGPメッセージはおそらく通常、過度のリソースを消費するのではなく、誤った条件の間はそうかもしれません。データプレーンでは、最も短いパスプロトコルのほぼ普遍的な採用は、伝送利用の最小化をもたらすと考える可能性があります。
Relevance: Valid. But perhaps routing could be improved if certain information (especially policies) could be available either globally or at least for a wider-defined locality.
関連性：有効です。しかし、特定の情報（特にポリシー）がグローバルに、または少なくともより広い定義の地域のいずれかで利用可能になる可能性がある場合、ルーティングを改善する可能性があります。
Editors' Note: Limited information exchange would be potentially compatible with a more local form of convergence than BGP tries to achieve today. Limited information exchange is potentially incompatible with global convergence.
編集者注：限られた情報交換は、BGPが今日達成しようとするよりも、よりローカルな形式の収束と互換性がある可能性があります。限られた情報交換は、グローバルな収束と潜在的に互換性がありません。
Current practice: Policies are used to determine which reachability information is exported, but neighbors receiving the information are not generally aware of the policies that resulted in this export.
現在の慣行：ポリシーは、どの到達可能性情報がエクスポートされるかを決定するために使用されますが、情報を受け取る近隣の人は一般に、このエクスポートをもたらしたポリシーを認識していません。
Relevance: Valid, but routing system should, perhaps, not be limited to this exclusively.
関連性：有効ですが、ルーティングシステムは、おそらくこれだけに限定されるべきではありません。
Current practice: Supported.
現在の練習：サポートされています。
Relevance: Valid, but routing system should, perhaps, not be limited to this exclusively.
関連性：有効ですが、ルーティングシステムは、おそらくこれだけに限定されるべきではありません。
Current practice: Accommodated.
現在の練習：収容されています。
Relevance: No longer valid. Needs to be increased -- potentially indefinitely. It is extremely difficult to foresee the future size expansion of the Internet, so the Utopian solution would be to achieve an Internet whose architecture is scale invariant. Regrettably, this may not be achievable without introducing undesirable complexity and a suitable trade-off between complexity and scalability is likely to be necessary.
関連性：もはや有効ではありません。潜在的に無期限に増やす必要があります。インターネットの将来のサイズの拡張を予測することは非常に困難です。そのため、ユートピアのソリューションは、アーキテクチャが不変のスケールであるインターネットを達成することです。残念ながら、これは望ましくない複雑さを導入せずに達成できない可能性があり、複雑さとスケーラビリティの間の適切なトレードオフが必要である可能性が高いです。
Current Practice: Supported, but perhaps reaching its limit. Since the original version of this document was written in 2001, the number of ASs advertised has grown from around 8000 to 20000, and almost 35000 AS numbers have been allocated by the regional registries [Huston05]. If this growth continues, the original 16-bit AS space in BGP-4 will be exhausted in less than 5 years. Planning for an extended AS space is now an urgent requirement.
現在の練習：サポートされていますが、おそらくその限界に達します。このドキュメントの元のバージョンが2001年に書かれて以来、宣伝されているASの数は約8000から20000に増加し、数が地域登録によって割り当てられたため、ほぼ35000が増加しました[Huston05]。この成長が続くと、BGP-4のスペースとしての元の16ビットは、5年以内に使い果たされます。スペースとして拡張された計画は、緊急の要件になりました。
Editors' Note: At the time of publication, 32- bit AS numbers have been introduced and are being deployed.
編集者注：出版時には、数字が導入され、展開されている32ビットが展開されています。
Relevance: Valid. However, perhaps not all interconnections should be accessible globally.
関連性：有効です。ただし、おそらくすべての相互接続がグローバルにアクセスできるわけではありません。
Current practice: BGP-4 allows for arbitrary interconnections.
現在の練習：BGP-4は、任意の相互接続を許可します。
Relevance: Valid, as stated before. It might be acceptable for a more complex service to take longer to deliver, but it still has to meet the application's requirements -- routing has to be at the service of the end-to-end principle.
関連性：前に述べたように有効です。より複雑なサービスが配信に時間がかかることは許容されるかもしれませんが、それでもアプリケーションの要件を満たす必要があります。ルーティングはエンドツーエンドの原則のサービスでなければなりません。
Editors' Note: Delays in setting up connections due to network functions such as NAT boxes are becoming increasingly problematic. The routing system should try to keep any routing delay to a minimum.
編集者の注：NATボックスなどのネットワーク機能による接続の設定の遅延は、ますます問題になっています。ルーティングシステムは、ルーティングの遅延を最小限に抑えようとする必要があります。
Current practice: More or less, with the exception of convergence and fault robustness.
現在の実践：収束と障害の堅牢性を除き、多かれ少なかれ。
Relevance: Valid.
関連性：有効です。
Current practice: Systems with limited resources are typically stub domains that advertise very little information.
現在の実践：リソースが限られているシステムは、通常、情報をほとんど宣伝するスタブドメインです。
Relevance: Important. This requirement is critical to a future architecture. In a domain-based routing environment where the internal properties of domains may differ radically, it will be important to be sure that these dissimilarities are minimized at the borders.
関連性：重要。この要件は、将来のアーキテクチャにとって重要です。ドメインの内部特性が根本的に異なる可能性のあるドメインベースのルーティング環境では、これらの類似性が境界で最小化されることを確認することが重要です。
Current: practice: For the most part, this capability is not really required in today's networks since the intra-domain attributes are broadly similar across domains.
現在：実践：ほとんどの場合、ドメイン内属性はドメイン間で広く類似しているため、この機能は今日のネットワークでは実際には必要ありません。
Relevance: Important, probably more so than when RFC 1126 was originally developed because of the potential deployment of IPv6, wider usage of MPLS, and the increasing usage of VPNs.
関連性：重要なことは、おそらくIPv6の潜在的な展開、MPLのより広い使用、およびVPNの使用の増加により、RFC 1126が元々開発されたときよりも重要です。
Current practice: Only one global addressing scheme is supported in most autonomous systems, but the availability of IPv6 services is steadily increasing. Some global backbones support IPv6 routing and forwarding.
現在の実践：ほとんどの自律システムでサポートされているグローバルアドレス指定スキームは1つだけですが、IPv6サービスの可用性は着実に増加しています。一部のグローバルバックボーンは、IPv6ルーティングと転送をサポートしています。
Relevance: Valid, but note that what can be implemented today is different from what was possible when RFC 1126 was written: a future domain-based routing architecture should not be unreasonably constrained by past limitations.
関連性：有効ですが、今日実装できるものは、RFC 1126が書かれたときに可能なこととは異なることに注意してください。将来のドメインベースのルーティングアーキテクチャは、過去の制限によって不当に制約されるべきではありません。
Current practice: BGP was implemented and meets a large proportion of the original requirements.
現在の慣行：BGPが実装され、元の要件の大部分を満たしています。
RFC 1126 also included a section discussing non-goals. This section discusses the extent to which these are still non-goals. It also considers whether the fact that they were non-goals adversely affects today's IDR system.
RFC 1126には、非ゴールを議論するセクションも含まれています。このセクションでは、これらがまだ非神格である程度について説明します。また、それらが非ゴールであるという事実が今日のIDRシステムに悪影響を与えるかどうかを考慮します。
The authors of RFC 1126 were explicitly saying that IP and its inter-domain routing system need not be deployed in every AS, and a participant should not necessarily expect to be able to reach a given AS, possibly because of routing policies. In a sense, this "non-goal" has effectively been achieved by the Internet and IP protocols. This requirement reflects a different worldview where there was serious competition for network protocols, which is really no longer the case. Ubiquitous deployment of inter-domain routing in particular has been achieved and must not be undone by any proposed future domain-based routing architecture. On the other hand:
RFC 1126の著者は、IPとそのドメイン間ルーティングシステムをすべてに展開する必要はないと明示的に述べていました。参加者は、おそらくルーティングポリシーのために、必ずしも与えられたASに到達できると予想すべきではありません。ある意味では、この「非ゴール」は、インターネットおよびIPプロトコルによって効果的に達成されました。この要件は、ネットワークプロトコルの深刻な競争があった別の世界観を反映していますが、これは実際にはそうではありません。特にドメイン間ルーティングのユビキタスな展開が達成されており、提案された将来のドメインベースのルーティングアーキテクチャによって取り消されてはなりません。一方で：
o ubiquitous connectivity cannot be reached in a policy-sensitive environment and should not be an aim.
o 政策に敏感な環境では、ユビキタスな接続に到達することはできず、目的であってはなりません。
Editors' Note: It has been pointed out that this statement could be interpreted as being contrary to the Internet mission of providing universal connectivity. The fact that limits to connectivity will be added as operational requirements in a policy-sensitive environment should not imply that a future domain-based routing architecture contains intrinsic limits on connectivity.
編集者の注：この声明は、普遍的な接続を提供するというインターネットミッションに反していると解釈できると指摘されています。政策に敏感な環境での運用要件として接続への制限が追加されるという事実は、将来のドメインベースのルーティングアーキテクチャに接続に固有の制限が含まれていることを意味するものではありません。
o it must not be required that the same routing mechanisms are used throughout, provided that they can interoperate appropriately.
o 適切に相互運用できる限り、同じルーティングメカニズムが全体を通して使用されることは必須ではありません。
o the information needed to control routing in a part of the network should not necessarily be ubiquitously available, and it must be possible for an operator to hide commercially sensitive information that is not needed outside a domain.
o ネットワークの一部でのルーティングを制御するために必要な情報は、必ずしも遍在的に利用可能であるべきではありません。また、オペレーターがドメインの外部では必要ない商業的に機密情報を隠すことができる必要があります。
o the introduction of IPv6 reintroduces an element of diversity into the world of network protocols, but the similarities of IPv4 and IPv6 as regards routing and forwarding make this event less likely to drive an immediate diversification in routing systems. The potential for further growth in the size of the network enabled by IPv6 is very likely to require changes in the future: whether this results in the replacement of one de facto ubiquitous system with another remains to be seen but cannot be a requirement -- it will have to interoperate with BGP during the transition.
o IPv6の導入は、ネットワークプロトコルの世界に多様性の要素を再導入しますが、ルーティングと転送に関するIPv4とIPv6の類似性により、このイベントはルーティングシステムの即時の多様化を促進する可能性が低くなります。IPv6によって有効になったネットワークのサイズがさらに成長する可能性は、将来の変更を必要とする可能性が非常に高いです。これにより、1つの事実上のユビキタスシステムが別のものを置き換えることになるかどうかはまだわかりませんが、要件ではありません - 移行中にBGPと相互運用する必要があります。
Relevance: De facto essential for a future domain-based routing architecture, but what is required is ubiquity of the routing system rather than ubiquity of connectivity and it must be capable of a gradual takeover through interoperation with the existing system.
関連性：将来のドメインベースのルーティングアーキテクチャには事実上不可欠ですが、必要なのは、接続の遍在性ではなく、ルーティングシステムの遍在性であり、既存のシステムとの相互運用を通じて徐々に買収できる必要があります。
Current practice: De facto ubiquity achieved.
現在の実践：事実上の遍在性が達成されました。
Relevance: It is not clear if this non-goal was to be applied to routing or forwarding. It is definitely a non-goal to adapt the choice of route when there is transient congestion. However, to add support for congestion avoidance (e.g., Explicit Congestion Notification (ECN) and ICMP messages) in the forwarding process would be a useful addition. There is also extensive work going on in traffic engineering that should result in congestion avoidance through routing as well as in forwarding.
関連性：この非ゴールがルーティングまたは転送に適用されるかどうかは明らかではありません。一時的な混雑がある場合、ルートの選択を適応させることは間違いなくゴールではありません。ただし、転送プロセスに混雑回避（例えば、明示的な混雑通知（ECN）およびICMPメッセージ）のサポートを追加することは、有用な追加になります。また、トラフィックエンジニアリングでは、ルーティングを通じて混雑回避と転送につながるはずの広範な作業も行われています。
Current practice: Some ICMP messages (e.g., source quench) exist to deal with congestion control, but these are not generally used as they either make the problem worse or there is no mechanism to reflect the message into the application that is providing the source.
現在の練習：一部のICMPメッセージ（例：ソースクエンチ）は、混雑制御に対処するために存在しますが、これらは一般に問題を悪化させるか、ソースを提供しているアプリケーションにメッセージを反映するメカニズムがないため、使用されません。
Relevance: This should neither be a non-goal nor an explicit goal. It might be desirable in some cases and should be considered as an optional architectural feature.
関連性：これは、非ゴールでも明示的な目標でもありません。場合によっては望ましい場合があり、オプションのアーキテクチャ機能と見なす必要があります。
Current practice: Can be implemented by exporting different prefixes on different links, but this requires manual configuration and does not consider actual load.
現在の練習：さまざまなリンクで異なるプレフィックスをエクスポートすることで実装できますが、これには手動構成が必要であり、実際の負荷を考慮しません。
Editors' Note: This configuration is carried out extensively as of 2006 and has been a significant factor in routing table bloat. If this need is a real operational requirement, as it seems to be for multi-homed or otherwise richly connected sites, it will be necessary to reclassify this as a real and important goal.
編集者注：この構成は、2006年の時点で広範囲に実行され、テーブルの膨満をルーティングする重要な要因です。このニーズが実際の運用上の要件である場合、マルチホームまたは豊富な接続されたサイトのように思われる場合、これを実際の重要な目標として再分類する必要があります。
Relevance: Valid. Cost-efficiency should be striven for; we note that maximizing resource utilization does not always lead to the greatest cost-efficiency.
関連性：有効です。費用効率を築く必要があります。リソースの利用を最大化すると、常に最大の費用効率につながるとは限りません。
Current practice: Not currently part of the system, though often a "hacked in" feature done with manual configuration.
現在の練習：現在、システムの一部ではありませんが、多くの場合、手動構成で行われた「ハッキング」機能です。
This non-goal was put in place to ensure that the IDR did not have to meet real-time deadline goals such as might apply to Constant Bit Rate (CBR) real-time services in ATM.
この非ゴールは、IDRがATMの一定のビットレート（CBR）リアルタイムサービスに適用されるなどのリアルタイム締め切り目標を満たす必要がないことを保証するために導入されました。
Relevance: The hard form of deadline services is still a non-goal for the future domain-based routing architecture, but overall delay bounds are much more of the essence than was the case when RFC 1126 was written.
関連性：締め切りサービスのハードフォームは、将来のドメインベースのルーティングアーキテクチャにとって依然としてノンゴールですが、RFC 1126が書かれた場合よりも、全体的な遅延境界線ははるかに重要です。
Current practice: Service providers are now offering overall probabilistic delay bounds on traffic contracts. To implement these contracts, there is a requirement for a rather looser form of delay sensitive routing.
現在の慣行：サービスプロバイダーは現在、交通契約で全体的な確率的遅延境界を提供しています。これらの契約を実装するには、遅延に敏感なルーティングのかなり緩い形式の要件があります。
The requirement in RFC 1126 is somewhat opaque, but appears to imply that what we would today call QoS routing is a non-goal and that routing would not seek to control the elastic characteristics of Internet traffic whereby a TCP connection can seek to utilize all the spare bandwidth on a route, possibly to the detriment of other connections sharing the route or crossing it.
RFC 1126の要件はやや不透明ですが、今日私たちがQoSルーティングと呼ぶものは非ゴールであり、ルーティングはTCP接続がすべてのものを利用しようとするインターネットトラフィックの弾性特性を制御しようとしないことを暗示しているようです。ルートの帯域幅は、ルートを共有または交差させる他の接続の不利益になります。
Relevance: Open Issue. It is not clear whether dynamic QoS routing can or should be implemented. Such a system would seek to control the admission and routing of traffic depending on current or recent resource utilization. This would be particularly problematic where traffic crosses an ownership boundary because of the need for potentially commercially sensitive information to be made available outside the ownership boundary.
関連性：OPEN ISSUE。動的なQoSルーティングを実装できるのか、実装すべきかは明らかではありません。このようなシステムは、現在または最近のリソースの使用率に応じて、トラフィックの入場とルーティングを制御しようとします。これは、所有権の境界以外で利用可能になる可能性のある商業的に機密情報が必要になるため、トラフィックが所有権の境界を越えている場合に特に問題があります。
Current practice: Routing does not consider dynamic resource availability. Forwarding can support service differentiation.
現在の練習：ルーティングでは、動的なリソースの可用性を考慮しません。転送はサービスの差別化をサポートできます。
During the decade before the widespread success of the World Wide Web, ISO was developing the communications architecture and protocol suite Open Systems Interconnection (OSI). For a considerable part of this time, OSI was seen as a possible competitor for and even a replacement for the IP suite as this basis for the Internet. The technical developments of the two protocols were quite heavily interrelated with each providing ideas and even components that were adapted into the other suite.
World Wide Webの広範な成功の1年前に、ISOはCommunication Architecture and Protocol Suite Open Systems Interconnection（OSI）を開発していました。この時間のかなりの部分で、OSIはインターネットのこの基礎としてIPスイートの可能性のある競合他社と見なされていました。2つのプロトコルの技術的な開発は、それぞれのアイデアを提供する各アイデアや、他のスイートに適合したコンポーネントと非常に大きく相互に関連していました。
During the early stages of the development of OSI, the IP suite was still mainly in use on the ARPANET and the relatively small scale first phase NSFNET. This was effectively a single administrative domain with a simple tree-structured network in a three-level hierarchy connected to a single logical exchange point (the NSFNET backbone). In the second half of the 1980s, the NSFNET was starting on the growth and transformation that would lead to today's Internet. It was becoming clear that the backbone routing protocol, the Exterior Gateway Protocol (EGP) [RFC0904], was not going to cope even with the limited expansion being planned. EGP is an "all informed" protocol that needed to know the identities of all gateways, and this was no longer reasonable. With the increasing complexity of the NSFNET and the linkage of the NSFNET network to other networks, there was a desire for policy-based routing that would allow administrators to manage the flow of packets between networks. The first version of the Border Gateway Protocol (BGP-1) [RFC1105] was developed as a replacement for EGP with policy capabilities -- a stopgap EGP version 3 had been created as an interim measure while BGP was developed. BGP was designed to work on a hierarchically structured network, such as the original NSFNET, but could also work on networks that were at least partially non-hierarchical where there were links between ASs at the same level in the hierarchy (we would now call these "peering arrangements") although the protocol made a distinction between different kinds of links (links are classified as upwards, downwards, or sideways). ASs themselves were a "fix" for the complexity that developed in the three-tier structure of the NSFNET.
OSIの開発の初期段階では、IPスイートは主にARPANETおよび比較的小規模な第1フェーズNSFNETで使用されていました。これは事実上、単一の論理交換ポイント（NSFNETバックボーン）に接続された3レベルの階層に単純なツリー構造ネットワークを備えた単一の管理ドメインでした。1980年代後半、NSFNETは、今日のインターネットにつながる成長と変換から始まりました。バックボーンルーティングプロトコルであるExterior Gateway Protocol（EGP）[RFC0904]が、限られた拡張が計画されていても対処しないことが明らかになっています。EGPは、すべてのゲートウェイのアイデンティティを知るために必要な「すべての情報に基づいた」プロトコルであり、これはもはや合理的ではありませんでした。NSFNETの複雑さの増加とNSFNETネットワークの他のネットワークへのリンケージにより、管理者がネットワーク間のパケットのフローを管理できるようにするポリシーベースのルーティングを望んでいました。Border Gateway Protocol（BGP-1）[RFC1105]の最初のバージョンは、ポリシー機能を備えたEGPの代替として開発されました。BGPが開発されている間、StopGap EGPバージョン3が暫定測定として作成されました。BGPは、元のNSFNETなどの階層構造ネットワークで動作するように設計されていますが、階層の同じレベルのASS間にリンクがある場合、少なくとも部分的に非歴史的なネットワークでも動作する可能性があります（これらを呼び出します。「ピアリングアレンジメント」）が、プロトコルは異なる種類のリンクを区別しました（リンクは上向き、下向き、または横に分類されます）。お尻自体は、NSFNETの3層構造で発生した複雑さの「修正」でした。
Meanwhile, the OSI architects, led by Lyman Chapin, were developing a much more general architecture for large-scale networks. They had recognized that no one node, especially an end-system (host), could or should attempt to remember routes from "here" to "anywhere" -- this sounds obvious today, but was not so obvious 20 years ago. They were also considering hierarchical networks with independently administered domains -- a model already well entrenched in the public-switched telephone network. This led to a vision of a network with multiple independent administrative domains with an arbitrary interconnection graph and a hierarchy of routing functionality. This architecture was fairly well established by 1987 [Tsuchiya87]. The architecture initially envisaged a three-level routing functionality hierarchy in which each layer had significantly different characteristics:
一方、ライマンチャピン率いるOSI建築家は、大規模なネットワーク向けのはるかに一般的なアーキテクチャを開発していました。彼らは、誰も、特に最終システム（ホスト）が「ここ」から「どこでも」までのルートを覚えようとすることができない、または試みることができないことを認識していました。また、独立して管理されたドメインを持つ階層ネットワークを検討していました。これは、公開された電話ネットワークにすでに十分に定着しているモデルです。これにより、任意の相互接続グラフとルーティング機能の階層を備えた複数の独立した管理ドメインを持つネットワークのビジョンが生じました。このアーキテクチャは、1987年までにかなり確立されました[Tsuchiya87]。アーキテクチャは、当初、各レイヤーが有意に異なる特性を持っている3レベルのルーティング機能階層を想定していました。
1. *End-system to intermediate system (IS) routing (host to router)*, in which the principal functions are discovery and redirection.
1. *エンドシステムから中間システム（IS）ルーティング（ルーターのホスト）*。主な機能は発見とリダイレクトです。
2. *Intra-domain IS-IS routing (router to router)*, in which "best" routes between end-systems in a single administrative domain are computed and used. A single algorithm and routing protocol would be used throughout any one domain.
2. *ドメイン内ISルーティング（ルーターからルーターへのルーター）*。単一の管理ドメインのエンドシステム間の「最良の」ルートが計算され、使用されます。1つのドメイン全体で単一のアルゴリズムとルーティングプロトコルが使用されます。
3. *Inter-domain IS-IS routing (router to router)*, in which routes between routing domains within administrative domains are computed (routing is considered separately between administrative domains and routing domains).
3. *ドメイン間ISルーティング（ルーターからルーターへのルーター）*。そこでは、管理ドメイン内のルーティングドメイン間のルートが計算されます（ルーティングは、管理ドメインとルーティングドメイン間で個別に考慮されます）。
Level 3 of this hierarchy was still somewhat fuzzy. Tsuchiya says:
この階層のレベル3は、まだ多少曖昧でした。津波は言う：
The last two components, Inter-Domain and Inter-Administration routing, are less clear-cut. It is not obvious what should be standardized with respect to these two components of routing. For example, for Inter-Domain routing, what can be expected from the Domains? By asking Domains to provide some kind of external behavior, we limit their autonomy. If we expect nothing of their external behavior, then routing functionality will be minimal.
最後の2つのコンポーネント、ドメイン間および管理間ルーティングは、あまり明確ではありません。ルーティングのこれら2つのコンポーネントに関して、何が標準化されるべきかは明らかではありません。たとえば、ドメイン間ルーティングの場合、ドメインに何が期待できますか？ドメインに何らかの外部行動を提供するように依頼することにより、それらの自律性を制限します。外部の動作を何も期待していない場合、ルーティング機能は最小限に抑えられます。
Across administrations, it is not known how much trust there will be. In fact, the definition of trust itself can only be determined by the two or more administrations involved.
政権全体で、どれだけ信頼できるかは不明です。実際、信頼自体の定義は、関係する2つ以上の管理者によってのみ決定できます。
Fundamentally, the problem with Inter-Domain and Inter-Administration routing is that autonomy and mistrust are both antithetical to routing. Accomplishing either will involve a number of tradeoffs which will require more knowledge about the environments within which they will operate.
基本的に、ドメイン間および管理間のルーティングの問題は、自律性と不信が両方ともルーティングに反対であるということです。どちらかを達成するには、多くのトレードオフが含まれ、それらが動作する環境に関するより多くの知識を必要とします。
Further refinement of the model occurred over the next couple of years and a more fully formed view is given by Huitema and Dabbous in 1989 [Huitema90]. By this stage, work on the original IS-IS link-state protocol, originated by the Digital Equipment Corporation (DEC), was fairly advanced and was close to becoming a Draft International Standard. IS-IS is of course a major component of intra-domain routing today and inspired the development of the Open Shortest Path First (OSPF) family. However, Huitema and Dabbous were not able to give any indication of protocol work for Level 3. There are hints of possible use of centralized route servers.
モデルのさらなる改良が今後数年間で発生し、1989年にHuitemaとDabbousによってより完全に形成されたビューが与えられます[Huitema90]。この段階では、Digital Equipment Corporation（DEC）が発信する元のIS-ISリンク状態プロトコルの作業はかなり進歩し、国際標準のドラフトに近づいていました。もちろん、IS-ISは今日のドメイン内ルーティングの主要なコンポーネントであり、最初のオープンパス（OSPF）ファミリーの開発に影響を与えました。ただし、HuitemaとDabbousは、レベル3のプロトコル作業の兆候を示すことができませんでした。集中ルートサーバーの使用の可能性があります。
In the meantime, the NSFNET consortium and the IETF had been struggling with the rapid growth of the NSFNET. It had been clear since fairly early on that EGP was not suitable for handling the expanding network and the race was on to find a replacement. There had been some intent to include a metric in EGP to facilitate routing decisions, but no agreement could be reached on how to define the metric. The lack of trust was seen as one of the main reasons that EGP could not establish a globally acceptable routing metric: again this seems to be a clearly futile aim from this distance in time! Consequently, EGP became effectively a rudimentary path-vector protocol that linked gateways with Autonomous Systems. It was totally reliant on the tree-structured network to avoid routing loops, and the all-informed nature of EGP meant that update packets became very large. BGP version 1 [RFC1105] was standardized in 1989, but it had been in development for some time before this and had already seen action in production networks prior to standardization. BGP was the first real path-vector routing protocol and was intended to relieve some of the scaling problems as well as providing policy-based routing. Routes were described as paths along a "vector" of ASs without any associated cost metric. This way of describing routes was explicitly intended to allow detection of routing loops. It was assumed that the intra-domain routing system was loop-free with the implication that the total routing system would be loop-free if there were no loops in the AS path. Note that there were no theoretical underpinnings for this work, and it traded freedom from routing loops for guaranteed convergence.
それまでの間、NSFNETコンソーシアムとIETFはNSFNETの急速な成長に苦労していました。EGPが拡大するネットワークの処理に適しておらず、レースが代替品を見つけるためにレースが進行していたことがかなり早い段階で明らかでした。ルーティングの決定を容易にするためにEGPにメトリックを含める意図がありましたが、メトリックを定義する方法について一致することはできませんでした。信頼の欠如は、EGPがグローバルに受け入れられるルーティングメトリックを確立できなかった主な理由の1つと見なされていました。これも、この距離からの明らかに無駄な目的のようです！その結果、EGPは事実上、ゲートウェイを自律システムとリンクした初歩的なパスベクトルプロトコルになりました。ルーティングループを避けるためにツリー構造のネットワークに完全に依存しており、EGPのすべてに基づいた性質により、更新パケットが非常に大きくなることがわかりました。BGPバージョン1 [RFC1105]は1989年に標準化されましたが、これより前にしばらく開発中であり、標準化の前に生産ネットワークでのアクションをすでに見ていました。BGPは、最初の実際のパスベクトルルーティングプロトコルであり、スケーリングの問題の一部を緩和し、ポリシーベースのルーティングを提供することを目的としていました。ルートは、関連するコストメトリックのないASSの「ベクトル」に沿ったパスとして説明されていました。ルートを説明するこの方法は、ルーティングループの検出を許可することを明示的に意図していました。ASパスにループがない場合、総ルーティングシステムがループフリーであるという意味で、ドメイン内ルーティングシステムがループフリーであると想定されていました。この作業の理論的基盤はなく、保証された収束のためにループループからの自由を交換したことに注意してください。
Also, the NSFNET was a government-funded research and education network. Commercial companies that were partners in some of the projects were using the NSFNET for their research activities, but it was becoming clear that these companies also needed networks for commercial traffic. NSFNET had put in place "acceptable use" policies that were intended to limit the use of the network. However, there was little or no technology to support the legal framework.
また、NSFNETは政府が資金提供する研究および教育ネットワークでした。一部のプロジェクトのパートナーであった商業会社は、研究活動にNSFNETを使用していましたが、これらの企業も商業交通のためにネットワークを必要としていることが明らかになっています。NSFNETは、ネットワークの使用を制限することを目的とした「許容可能な使用」ポリシーを導入していました。ただし、法的枠組みをサポートする技術はほとんどまたはまったくありませんでした。
Practical experience, IETF IAB discussion (centered in the Internet Architecture Task Force) and the OSI theoretical work were by now coming to the same conclusions:
実務経験、IETF IABディスカッション（インターネットアーキテクチャタスクフォースを中心とした）、OSIの理論的作業は、今では同じ結論に達していました。
o Networks were going to be composed out of multiple administrative domains (the federated network),
o ネットワークは、複数の管理ドメイン（フェデレーションネットワーク）から作曲される予定でした。
o The connections between these domains would be an arbitrary graph and certainly not a tree,
o これらのドメイン間の接続は任意のグラフであり、確かに木ではありません。
o The administrative domains would wish to establish distinctive, independent routing policies through the graph of Autonomous Systems, and
o 管理ドメインは、自律システムのグラフを介して独特の独立したルーティングポリシーを確立したいと考えています。
o Administrative domains would have a degree of distrust of each other that would mean that policies would remain opaque.
o 管理ドメインには、お互いに不信感があり、ポリシーが不透明のままであることを意味します。
These views were reflected by Susan Hares' (working for Merit Networks at that time) contribution to the Internet Architecture (INARC) workshop in 1989, summarized in the report of the workshop [INARC89]:
これらの見解は、1989年のインターネットアーキテクチャ（INARC）ワークショップへのスーザンハーズ（当時のメリットネットワークで働いている）に反映されており、ワークショップ[INARC89]のレポートにまとめられています。
The rich interconnectivity within the Internet causes routing problems today. However, the presenter believes the problem is not the high degree of interconnection, but the routing protocols and models upon which these protocols are based. Rich interconnectivity can provide redundancy which can help packets moving even through periods of outages. Our model of interdomain routing needs to change. The model of autonomous confederations and autonomous systems [RFC0975] no longer fits the reality of many regional networks. The ISO models of administrative domain and routing domains better fit the current Internet's routing structure.
インターネット内の豊富な相互接続性は、今日ルーティングの問題を引き起こします。ただし、発表者は、問題は高度な相互接続ではなく、これらのプロトコルが基づいているルーティングプロトコルとモデルであると考えています。豊富な相互接続性は、停止期間を経てもパケットが移動するのに役立つ冗長性を提供できます。ドメイン間ルーティングのモデルは変更する必要があります。自律的なコンフェデレーションと自律システム[RFC0975]のモデルは、もはや多くの地域ネットワークの現実に適合しません。管理ドメインとルーティングドメインのISOモデルは、現在のインターネットのルーティング構造によりよく適合します。
With the first NSFNET backbone, NSF assumed that the Internet would be used as a production network for research traffic. We cannot stop these networks for a month and install all new routing protocols. The Internet will need to evolve its changes to networking protocols while still continuing to serve its users. This reality colors how plans are made to change routing protocols.
最初のNSFNETバックボーンにより、NSFは、インターネットが研究トラフィックのための生産ネットワークとして使用されると想定していました。これらのネットワークを1か月間停止し、すべての新しいルーティングプロトコルをインストールすることはできません。インターネットは、ユーザーにサービスを提供し続けながら、ネットワーキングプロトコルへの変更を進化させる必要があります。この現実は、ルーティングプロトコルを変更する計画がどのように作られているかを彩ります。
It is also interesting to note that the difficulties of organizing a transition were recognized at this stage and have not been seriously explored or resolved since.
また、移行を組織することの難しさがこの段階で認識されており、それ以来真剣に探求または解決されていないことに注意することも興味深いことです。
Policies would primarily be interested in controlling which traffic should be allowed to transit a domain (to satisfy commercial constraints or acceptable use policies), thereby controlling which traffic uses the resources of the domain. The solution adopted by both the IETF and OSI was a form of distance vector hop-by-hop routing with explicit policy terms. The reasoning for this choice can be found in Breslau and Estrin's 1990 paper [Breslau90] (implicitly -- because some other alternatives are given such as a link state with policy suggestion, which, with hindsight, would have even greater problems than BGP on a global scale network). Traditional distance-vector protocols exchanged routing information in the form of a destination and a metric. The new protocols explicitly associated policy expressions with the route by including either a list of the source ASs that are permitted to use the route described in the routing update, and/or a list of all ASs traversed along the advertised route.
ポリシーは主に、どのトラフィックをドメインを通過できるか（商業的制約または許容可能な使用ポリシーを満たすために）制御することに関心があり、それにより、どのトラフィックがドメインのリソースを使用するかを制御します。IETFとOSIの両方で採用されたソリューションは、明示的なポリシー条件を備えた距離ベクトルホップバイホップルーティングの一形態でした。この選択の理由は、BreslauとEstrinの1990年の論文[Breslau90]に記載されています（暗黙的に - 政策提案を含むリンク状態など、他のいくつかの選択肢が与えられているため、後知恵では、BGPよりもさらに大きな問題を抱えています。グローバルスケールネットワーク）。従来の距離ベクトルプロトコルは、宛先とメトリックの形でルーティング情報を交換しました。新しいプロトコルは、ルーティングアップデートで説明されているルートを使用することが許可されているソースASSのリスト、および/または広告されたルートに沿って移動されたすべてのASSのリストを含めることにより、ルートと明示的にポリシー式を明示的に関連付けました。
Parallel protocol developments were already in progress by the time this paper was published: BGP version 2 [RFC1163] in the IETF and the Inter-Domain Routing Protocol (IDRP) [ISO10747], which would be the Level 3 routing protocol for the OSI architecture. IDRP was developed under the aegis of the ANSI XS3.3 working group led by Lyman Chapin and Charles Kunzinger. The two protocols were very similar in basic design, but IDRP has some extra features, some of which have been incorporated into later versions of BGP; others may yet be so, and still others may be seen to be inappropriate. Breslau and Estrin summarize the design of IDRP as follows:
並列プロトコルの開発は、このペーパーが発行されるまでにすでに進行中でした：IETFおよびドメイン間ルーティングプロトコル（IDRP）[ISO10747]のBGPバージョン2 [RFC1163]は、OSIアーキテクチャのレベル3ルーティングプロトコルになります。。IDRPは、Lyman ChapinとCharles Kunzingerが率いるANSI XS3.3ワーキンググループの支援の下で開発されました。2つのプロトコルは基本設計が非常に似ていましたが、IDRPにはいくつかの追加機能があり、その一部はBGPの後のバージョンに組み込まれています。他の人はまだそうであるかもしれませんし、他の人は不適切であると見られるかもしれません。Breslauとエストリンは、次のようにIDRPの設計を要約します。
IDRP attempts to solve the looping and convergence problems inherent in distance vector routing by including full AD (Administrative Domain -- essentially the equivalent of what are now called ASs) path information in routing updates. Each routing update includes the set of ADs that must be traversed in order to reach the specified destination. In this way, routes that contain AD loops can be avoided.
IDRPは、フルAD（管理ドメイン - 基本的に現在ASSと呼ばれるものに相当する）をルーティングの更新に含めることにより、距離ベクトルルーティングに固有のループおよび収束の問題を解決しようとします。各ルーティングアップデートには、指定された宛先に到達するために通過する必要がある広告のセットが含まれています。このようにして、広告ループを含むルートは回避できます。
IDRP updates also contain additional information relevant to policy constraints. For instance, these updates can specify what other ADs are allowed to receive the information described in the update. In this way, IDRP is able to express source specific policies. The IDRP protocol also provides the structure for the addition of other types of policy related information in routing updates. For example, User Class Identifiers (UCI) could also be included as policy attributes in routing updates.
IDRPの更新には、ポリシーの制約に関連する追加情報も含まれています。たとえば、これらの更新は、更新に記載されている情報を受信できる他の広告を指定することができます。このようにして、IDRPはソース特定のポリシーを表現できます。IDRPプロトコルは、ルーティングの更新に他のタイプのポリシー関連情報を追加するための構造も提供します。たとえば、ユーザークラス識別子（UCI）は、ルーティングの更新にポリシー属性として含めることもできます。
Using the policy route attributes IDRP provides the framework for expressing more fine grained policy in routing decisions. However, because it uses hop-by-hop distance vector routing, it only allows a single route to each destination per-QOS to be advertised. As the policy attributes associated with routes become more fine grained, advertised routes will be applicable to fewer sources. This implies a need for multiple routes to be advertised for each destination in order to increase the probability that sources have acceptable routes available to them. This effectively replicates the routing table per forwarding entity for each QoS, UCI, source combination that might appear in a packet. Consequently, we claim that this approach does not scale well as policies become more fine grained, i.e., source or UCI specific policies.
ポリシールート属性を使用すると、IDRPは、ルーティングの決定においてより細かい粒子のポリシーを表現するためのフレームワークを提供します。ただし、ホップバイホップ距離ベクトルルーティングを使用するため、各宛先ごとのルートが宣伝されることのみが可能です。ルートに関連付けられたポリシー属性がより細かくなるため、広告されたルートはより少ないソースに適用されます。これは、ソースが利用可能なルートが許容できるルートを持っている確率を高めるために、各宛先の複数のルートを宣伝する必要があることを意味します。これにより、各QoS、UCI、パケットに表示される可能性のあるソースの組み合わせの転送エンティティごとにルーティングテーブルが効果的に複製されます。その結果、ポリシーがより細かく、つまりソースまたはUCI固有のポリシーがより細かくなるにつれて、このアプローチはうまく拡大しないと主張します。
Over the next three or four years, successive versions of BGP (BGP-2 [RFC1163], BGP-3 [RFC1267], and BGP-4 [RFC1771]) were deployed to cope with the growing and by now commercialized Internet. From BGP-2 onwards, BGP made no assumptions about an overall structure of interconnections allowing it to cope with today's dense web of interconnections between ASs. BGP version 4 was developed to handle the change from classful to classless addressing. For most of this time, IDRP was being developed in parallel, and both protocols were implemented in the Merit gatedaemon routing protocol suite. During this time, there was a movement within the IETF that saw BGP as a stopgap measure to be used until the more sophisticated IDRP could be adapted to run over IP instead of the OSI connectionless protocol Connectionless Network Protocol (CLNP). However, unlike its intra-domain counterpart IS-IS, which has stood the test of time, and indeed proved to be more flexible than OSPF, IDRP was ultimately not adopted by the market. By the time the NSFNET backbone was decommissioned in 1995, BGP-4 was the inter-domain routing protocol of choice and OSI's star was already beginning to wane. IDRP is now little remembered.
次の3、4年にわたって、BGP（BGP-2 [RFC1163]、BGP-3 [RFC1267]、およびBGP-4 [RFC1771]）の連続バージョンが展開され、現在の商業化されたインターネットに対処するために展開されました。BGP-2以降、BGPは相互接続の全体的な構造について仮定しませんでした。BGPバージョン4は、クラスフルからクラスレスアドレスまでの変更を処理するために開発されました。ほとんどの間、IDRPは並行して開発されており、両方のプロトコルがメリットゲートエモンルーティングプロトコルスイートに実装されました。この間、IETF内には、より洗練されたIDRPがOSI Connectionless Protocol Connectionless Network Protocol（CLNP）の代わりにIPを実行するように適応できるようになるまで、BGPを使用するストップガップ測定と見なす動きがありました。しかし、時の試練に耐え、実際にOSPFよりも柔軟性があることが証明されたドメイン内のカウンターパートISとは異なり、IDRPは最終的に市場で採用されませんでした。NSFNETバックボーンが1995年に廃止された頃には、BGP-4は選択のドメイン間ルーティングプロトコルであり、OSIのスターはすでに衰え始めていました。IDRPは今ではほとんど覚えていません。
A more complete account of the capabilities of IDRP can be found in Chapter 14 of David Piscitello and Lyman Chapin's book "Open Systems Networking: TCP/IP and OSI", which is now readable on the Internet [Chapin94].
IDRPの機能のより完全な説明は、David PiscitelloとLyman Chapinの著書「Open Systems Networking：TCP/IP and OSI」の第14章に記載されています。
IDRP also contained quite extensive means for securing routing exchanges, much of it based on X.509 certificates for each router and public-/private-key encryption of routing updates.
IDRPには、ルーティング交換を保護するための非常に広範な手段も含まれていました。その多くは、各ルーターのX.509証明書とルーティングアップデートのパブリック/プライベートキー暗号化に基づいています。
Some of the capabilities of IDRP that might yet appear in a future version of BGP include the ability to manage routes with explicit QoS classes and the concept of domain confederations (somewhat different from the confederation mechanism in today's BGP) as an extra level in the hierarchy of routing.
BGPの将来バージョンにまだ登場する可能性のあるIDRPの機能には、明示的なQoSクラスを持つルートを管理する機能と、ドメインコンフェデレーションの概念（今日のBGPの連合メカニズムとは多少異なる）が階層の追加レベルとして含まれています。ルーティングの。
Nimrod as expressed by Noel Chiappa in his early document, "A New IP Routing and Addressing Architecture" [Chiappa91] and later in the NIMROD working group documents [RFC1753] and [RFC1992] established a number of requirements that need to be considered by any new routing architecture. The Nimrod requirements took RFC 1126 as a starting point and went further.
Noel Chiappaが初期の文書で表現したNimrodは、「新しいIPルーティングとアドレス指定アーキテクチャ」[Chiappa91]で、Nimrodワーキンググループドキュメント[RFC1753]および[RFC1992]で、検討する必要がある多くの要件を確立しました。新しいルーティングアーキテクチャ。NIMROD要件は、RFC 1126を出発点として取り上げ、さらに進みました。
The three goals of Nimrod, quoted from [RFC1992], were as follows:
[RFC1992]から引用されたニムロッドの3つの目標は次のとおりでした。
1. To support a dynamic internetwork of _arbitrary size_ (our emphasis) by providing mechanisms to control the amount of routing information that must be known throughout an internetwork.
1. _arbitrary size _（私たちの強調）の動的なインターネットワークをサポートするには、インターネットワーク全体で知られている必要があるルーティング情報の量を制御するメカニズムを提供します。
2. To provide service-specific routing in the presence of multiple constraints imposed by service providers and users.
2. サービスプロバイダーとユーザーによって課される複数の制約が存在する場合、サービス固有のルーティングを提供する。
3. To admit incremental deployment throughout an internetwork.
3. インターネットワーク全体の増分展開を認める。
It is certain that these goals should be considered requirements for any new domain-based routing architecture.
これらの目標は、新しいドメインベースのルーティングアーキテクチャの要件を考慮する必要があることは確かです。
o As discussed in other sections of this document, the rate of growth of the amount of information needed to maintain the routing system is such that the system may not be able to scale up as the Internet expands as foreseen. And yet, as the services and constraints upon those services grow, there is a need for more information to be maintained by the routing system. One of the key terms in the first requirements is "control". While increasing amounts of information need to be known and maintained in the Internet, the amounts and kinds of information that are distributed can be controlled. This goal should be reflected in the requirements for the future domain-based architecture.
o このドキュメントの他のセクションで説明したように、ルーティングシステムを維持するために必要な情報量の成長率は、インターネットが予見されるように拡大するにつれてシステムがスケールアップできないようなものです。それでも、これらのサービスに対するサービスと制約が成長するにつれて、ルーティングシステムによってより多くの情報を維持する必要があります。最初の要件の重要な用語の1つは「制御」です。情報量を増やす必要がありますが、インターネットで既知と維持する必要がありますが、配布される情報の量と種類を制御できます。この目標は、将来のドメインベースのアーキテクチャの要件に反映される必要があります。
o If anything, the demand for specific services in the Internet has grown since 1996 when the Nimrod architecture was published. Additionally, the kinds of constraints that service providers need to impose upon their networks and that services need to impose upon the routing have also increased. Any changes made to the network in the last half-decade have not significantly improved this situation.
o どちらかといえば、インターネットでの特定のサービスの需要は、Nimrodアーキテクチャが公開された1996年以来増加しています。さらに、サービスプロバイダーがネットワークに課す必要がある種類の制約と、ルーティングに課す必要があるサービスも増加しています。過去半年にネットワークに加えられた変更は、この状況を大幅に改善していません。
o The ability to incrementally deploy any new routing architecture within the Internet is still an absolute necessity. It is impossible to imagine that a new routing architecture could supplant the current architecture on a flag day.
o インターネット内で新しいルーティングアーキテクチャを段階的に展開する機能は、依然として絶対的な必要性です。新しいルーティングアーキテクチャが旗の日に現在のアーキテクチャに取って代わることができると想像することは不可能です。
At one point in time, Nimrod, with its addressing and routing architectures, was seen as a candidate for IPng. History shows that it was not accepted as the IPng, having been ruled out of the selection process by the IESG in 1994 on the grounds that it was "too much of a research effort" [RFC1752], although input for the requirements of IPng was explicitly solicited from Chiappa [RFC1753]. Instead, IPv6 has been put forth as the IPng. Without entering a discussion of the relative merits of IPv6 versus Nimrod, it is apparent that IPv6, while it may solve many problems, does not solve the critical routing problems in the Internet today. In fact, in some sense, it exacerbates them by adding a requirement for support of two Internet protocols and their respective addressing methods. In many ways, the addition of IPv6 to the mix of methods in today's Internet only points to the fact that the goals, as set forth by the Nimrod team, remain as necessary goals.
ある時点で、Nimrodは、そのアドレス指定とルーティングアーキテクチャを備えた、IPNGの候補者と見なされていました。歴史は、IPNGとして受け入れられていないことを示しており、1994年にIESGによって「研究努力が多すぎる」[RFC1752]であるという理由でIESGによって選択プロセスから除外されましたが、IPNGの要件の入力はChiappa [RFC1753]から明示的に求められています。代わりに、IPv6はIPNGとして提示されています。IPv6とNimrodの相対的なメリットについて議論することなく、IPv6は多くの問題を解決するかもしれませんが、今日のインターネットの重要なルーティングの問題を解決しないことは明らかです。実際、ある意味では、2つのインターネットプロトコルとそれぞれのアドレス指定方法のサポートの要件を追加することにより、それらを悪化させます。多くの点で、今日のインターネットにメソッドを組み合わせたIPv6を追加することは、NIMRODチームが規定している目標が必要な目標として残っているという事実を示しています。
There is another sense in which the study of Nimrod and its architecture may be important to deriving a future domain-based routing architecture. Nimrod can be said to have two derivatives:
Nimrodとそのアーキテクチャの研究が、将来のドメインベースのルーティングアーキテクチャを導き出すために重要である可能性がある別の意味があります。Nimrodには2つの誘導体があると言えます。
o Multi-Protocol Label Switching (MPLS), in that it took the notion of forwarding along well-known paths.
o よく知られているパスに沿って転送するという概念をとったという点で、マルチプロトコルラベルスイッチング（MPLS）。
o Private Network-Node Interface (PNNI), in that it took the notion of abstracting topological information and using that information to create connections for traffic.
o プライベートネットワークノードインターフェイス（PNNI）は、トポロジー情報を抽象化し、その情報を使用してトラフィックの接続を作成するという概念をとったという点で。
It is important to note, that whilst MPLS and PNNI borrowed ideas from Nimrod, neither of them can be said to be an implementation of this architecture.
MPLとPNNIはNimrodからアイデアを借りた一方で、どちらもこのアーキテクチャの実装とは言えないことに注意することが重要です。
The Private Network-Node Interface (PNNI) routing protocol was developed under the ATM Forum's auspices as a hierarchical route determination protocol for ATM, a connection-oriented architecture. It is reputed to have developed several of its methods from a study of the Nimrod architecture. What can be gained from an analysis of what did and did not succeed in PNNI?
プライベートネットワークノードインターフェイス（PNNI）ルーティングプロトコルは、ATMフォーラムの後援の下で、接続指向のアーキテクチャであるATMの階層ルート決定プロトコルとして開発されました。ニムロッド建築の研究からいくつかの方法を開発したと言われています。PNNIで何をしたか、成功しなかったことの分析から何を得ることができますか？
The PNNI protocol includes the assumption that all peer groups are willing to cooperate, and that the entire network is under the same top administration. Are there limitations that stem from this "world node" presupposition? As discussed in [RFC3221], the Internet is no longer a clean hierarchy, and there is a lot of resistance to having any sort of "ultimate authority" controlling or even brokering communication.
PNNIプロトコルには、すべてのピアグループが協力する意思があり、ネットワーク全体が同じ最高の管理下にあるという仮定が含まれています。この「ワールドノード」の前提に起因する制限はありますか？[RFC3221]で説明したように、インターネットはもはやクリーンな階層ではなく、コミュニケーションを制御または仲介する「究極の権限」を課すことに多くの抵抗があります。
PNNI is the first deployed example of a routing protocol that uses abstract map exchange (as opposed to distance-vector or link-state mechanisms) for inter-domain routing information exchange. One consequence of this is that domains need not all use the same mechanism for map creation. What were the results of this abstraction and source-based route calculation mechanism? Since the authors of this document do not have experience running a PNNI network, the comments above are from a theoretical perspective. Further research on these issues based on operational experience is required.
PNNIは、ドメイン間ルーティング情報交換に抽象的なマップ交換（距離ベクトルまたはリンク状態メカニズムとは対照的に）を使用するルーティングプロトコルの最初の展開例です。これの1つの結果は、ドメインがすべてがマップ作成に同じメカニズムを使用する必要はないということです。この抽象化とソースベースのルート計算メカニズムの結果は何でしたか？このドキュメントの著者はPNNIネットワークを実行した経験がないため、上記のコメントは理論的な観点からのものです。運用経験に基づいたこれらの問題に関するさらなる研究が必要です。
The work commissioned from Geoff Huston by the Internet Architecture Board [RFC3221] draws a number of conclusions from the analysis of BGP routing tables and routing registry databases:
インターネットアーキテクチャボード[RFC3221]によってGeoff Hustonから委託された作業は、BGPルーティングテーブルとルーティングレジストリデータベースの分析から多くの結論を導き出します。
o The connectivity between provider ASs is becoming more like a dense mesh than the tree structure that was commonly assumed to be commonplace a couple of years ago. This has been driven by the increasing amounts charged for peering and transit traffic by global service providers. Local direct peering and Internet exchanges are becoming steadily more common as the cost of local fibre connections drops.
o プロバイダーのお尻間の接続性は、数年前に一般的に一般的であると想定されていたツリー構造よりも密なメッシュのようになっています。これは、グローバルなサービスプロバイダーによる覗き見と交通トラフィックに対して請求される量の増加によって推進されています。ローカルの直接ピアリングとインターネットの交換は、ローカルファイバー接続のコストが低下するにつれて、着実に一般的になりつつあります。
o End-user sites are increasingly resorting to multi-homing onto two or more service providers as a way of improving resiliency. This has a knock-on effect of spectacularly fast depletion of the available pool of AS numbers as end-user sites require public AS numbers to become multi-homed and corresponding increase in the number of prefixes advertised in BGP.
o エンドユーザーサイトは、レジリエンシーを改善する方法として、2つ以上のサービスプロバイダーにマルチホミングに頼っています。これには、エンドユーザーサイトとしてのAS数字の利用可能なプールが壮大に急速に枯渇するというノックオン効果があります。
o Multi-homed sites are using advertisement of longer prefixes in BGP as a means of traffic engineering to load spread across their multiple external connections with further impact on the size of the BGP tables.
o マルチホームのサイトは、BGPテーブルのサイズにさらに影響を与え、複数の外部接続に広がるトラフィックエンジニアリングの手段として、BGPの長いプレフィックスの広告を使用しています。
o Operational practices are not uniform, and in some cases lack of knowledge or training is leading to instability and/or excessive advertisement of routes by incorrectly configured BGP speakers.
o 運用慣行は均一ではなく、場合によっては、知識やトレーニングの不足が、誤って構成されたBGPスピーカーによるルートの不安定性および/または過度の広告につながります。
o All these factors are quickly negating the advantages in limiting the expansion of BGP routing tables that were gained by the introduction of Classless Inter-Domain Routing (CIDR) and consequent prefix aggregation in BGP. It is also now impossible for IPv6 to realize the worldview in which the default-free zone would be limited to perhaps 10,000 prefixes.
o これらすべての要因は、クラスレスインタードメインルーティング（CIDR）の導入と、BGPでの結果の接頭辞集約によって得られたBGPルーティングテーブルの拡張を制限する上での利点をすぐに無効にしています。また、IPv6がデフォルトのフリーゾーンがおそらく10,000のプレフィックスに制限される世界観を実現することは不可能になりました。
o The typical "width" of the Internet in AS hops is now around five, and much less in many cases.
o ホップとしてのインターネットの典型的な「幅」は現在5件前後であり、多くの場合ははるかに少ないです。
These conclusions have a considerable impact on the requirements for the future domain-based routing architecture:
これらの結論は、将来のドメインベースのルーティングアーキテクチャの要件に大きな影響を与えます。
o Topological hierarchy (e.g., mandating a tree-structured connectivity) cannot be relied upon to deliver scalability of a large Internet routing system.
o トポロジー階層（たとえば、樹木構造の接続性を義務付ける）は、大規模なインターネットルーティングシステムのスケーラビリティを提供するために依存することはできません。
o Aggregation cannot be relied upon to constrain the size of routing tables for an all-informed routing system.
o 集約は、すべてに基づいたルーティングシステムのルーティングテーブルのサイズを制限することに依存することはできません。
DARPA funded a project to think about a new architecture for future generation Internet, called NewArch (see http://www.isi.edu/newarch/). Work started in the first half of 2000 and the main project finished in 2003 [NewArch03].
DARPAは、NewArchと呼ばれる将来の世代インターネットの新しいアーキテクチャについて考えるプロジェクトに資金を提供しました（http://www.isi.edu/newarch/を参照）。作業は2000年前半に始まり、メインプロジェクトは2003年に終了しました[Newarch03]。
The main development is to conclude that as the Internet becomes mainstream infrastructure, fewer and fewer of the requirements are truly global but may apply with different force or not at all in certain parts of the network. This (it is claimed) makes the compilation of a single, ordered list of requirements deeply problematic. Instead, we may have to produce multiple requirement sets with support for differing requirement importance at different times and in different places. This "meta-requirement" significantly impacts architectural design.
主な開発は、インターネットが主流のインフラストラクチャになるにつれて、ネットワークの特定の部分では、実際にグローバルなものが少なくなりますが、異なる力でまったく適用される可能性があると結論付けることです。これは（主張されています）要件の単一の順序付けられたリストの編集を深く問題にします。代わりに、さまざまな時期や異なる場所での重要性の重要性が異なることをサポートして、複数の要件セットを作成する必要がある場合があります。この「メタ要請」は、建築設計に大きな影響を与えます。
Potential new technical requirements identified so far include:
これまでに特定された潜在的な新しい技術的要件は次のとおりです。
o Commercial environment concerns such as richer inter-provider policy controls and support for a variety of payment models
o より豊富なプロバイダー間のポリシーの管理とさまざまな支払いモデルのサポートなどの商業環境の懸念
o Trustworthiness
o 信頼性
o Ubiquitous mobility
o ユビキタスモビリティ
o Policy driven self-organization ("deep auto-configuration")
o ポリシー主導の自己組織化（「ディープオートコンフィグレーザー」）
o Extreme short-timescale resource variability
o 極端な短縮リソースのばらつき
o Capacity allocation mechanisms
o 容量割り当てメカニズム
o Speed, propagation delay, and delay/bandwidth product issues
o 速度、伝播遅延、および遅延/帯域幅製品の問題
Non-technical or political "requirements" include:
非技術的または政治的な「要件」には次のものが含まれます。
o Legal and Policy drivers such as
o 次のような法的およびポリシードライバー
* Privacy and free/anonymous speech
* プライバシーと無料/匿名のスピーチ
* Intellectual property concerns
* 知的財産の懸念
* Encryption export controls
* 暗号化エクスポートコントロール
* Law enforcement surveillance regulations
* 法執行機関の監視規制
* Charging and taxation issues
* 請求と課税の問題
o Reconciling national variations and consistent operation in a worldwide infrastructure
o 世界的なインフラストラクチャにおける国家のバリエーションと一貫した操作の調整
The conclusions of the work are now summarized in the final report [NewArch03].
作業の結論は、最終報告書[Newarch03]にまとめられています。
One of the participants in DARPA NewArch work (Dave Clark) with one of his associates has also published a very interesting paper analyzing the impact of some of the new requirements identified in NewArch (see Section 4.2) on the end-to-end principle that has guided the development of the Internet to date [Clark00]. Their primary conclusion is that the loss of trust between the users at the ends of end-to-end has the most fundamental effect on the Internet. This is clear in the context of the routing system, where operators are unwilling to reveal the inner workings of their networks for commercial reasons. Similarly, trusted third parties and their avatars (mainly midboxes of one sort or another) have a major impact on the end-to-end principles and the routing mechanisms that went with them. Overall, the end-to-end principles should be defended so far as is possible -- some changes are already too deeply embedded to make it possible to go back to full trust and openness -- at least partly as a means of staving off the day when the network will ossify into an unchangeable form and function (much as the telephone network has done). The hope is that by that time, a new Internet will appear to offer a context for unfettered innovation.
DARPA Newark Work（Dave Clark）の参加者の1人は、仲間の1人と一緒に、Newarchで特定された新しい要件の一部（セクション4.2を参照）のいくつかの影響を分析した非常に興味深い論文を発表しました。インターネットの開発をこれまでに導きました[Clark00]。彼らの主な結論は、エンドツーエンドの端でのユーザー間の信頼の喪失が、インターネットに最も基本的な効果をもたらすということです。これは、ルーティングシステムのコンテキストでは明らかであり、オペレーターは商業上の理由でネットワークの内部の仕組みを明らかにしようとしません。同様に、信頼できるサードパーティとそのアバター（主に何らかの種類のミッドボックス）は、エンドツーエンドの原則とそれらに伴うルーティングメカニズムに大きな影響を及ぼします。全体として、可能な限りエンドツーエンドの原則を防御する必要があります - いくつかの変更は、完全に信頼と開放性に戻ることを可能にするにはすでに深く埋め込まれすぎています - 少なくとも部分的には、それを取り除く手段としては、ネットワークが不変の形と機能に骨化する日（電話ネットワークが行ったように）。希望は、その時までに、新しいインターネットが自由なイノベーションのコンテキストを提供するように見えることです。
Although most of the people who have to work with BGP today believe it to be a useful, working protocol, discussions have brought to light a number of areas where BGP or the relationship between BGP and the intra-domain routing protocols in use today could be improved. BGP-4 has been and continues to be extended since it was originally introduced in [RFC1771] and the protocol as deployed has been documented in [RFC4271]. This section is, to a large extent, a wish list for the future domain-based routing architecture based on those areas where BGP is seen to be lacking, rather than simply a list of problems with BGP. The shortcomings of today's inter-domain routing system have also been extensively surveyed in "Architectural Requirements for Inter-Domain Routing in the Internet" [RFC3221], particularly with respect to its stability and the problems produced by explosions in the size of the Internet.
今日BGPと協力しなければならない人のほとんどは、それが有用で有効なプロトコルであると信じていますが、議論はBGPまたはBGPと今日使用されているドメイン内ルーティングプロトコルとの関係がある多くの領域を明らかにしましたが、改善。BGP-4は、元々[RFC1771]で導入されて以来、拡張され続けており、展開されたプロトコルは[RFC4271]で記録されています。このセクションは、BGPの問題のリストではなく、BGPが不足していると見られている領域に基づいた将来のドメインベースのルーティングアーキテクチャのウィッシュリストです。今日のドメイン間ルーティングシステムの欠点は、特にその安定性とインターネットのサイズの爆発によって生じる問題に関して、「インターネット内のドメイン間ルーティングのアーキテクチャ要件」[RFC3221]で広範囲に調査されています。
The initial stability followed by linear growth rates of the number of routing objects (prefixes) that was achieved by the introduction of CIDR around 1994, has now been once again been replaced by near-exponential growth of number of routing objects. The granularity of many of the objects advertised in the default-free zone is very small (prefix length of 22 or longer): this granularity appears to be a by-product of attempts to perform precision traffic engineering related to increasing levels of multi-homing. At present, there is no mechanism in BGP that would allow an AS to aggregate such prefixes without advance knowledge of their existence, even if it was possible to deduce automatically that they could be aggregated. Achieving satisfactory auto-aggregation would also significantly reduce the non-locality problems associated with instability in peripheral ASs.
1994年頃にCIDRの導入によって達成されたルーティングオブジェクトの数（接頭辞）の線形成長率が続く初期の安定性に続いて、ルーティングオブジェクトの数のほぼ極端な成長に再び置き換えられました。デフォルトのないゾーンで宣伝されている多くのオブジェクトの粒度は非常に小さい（22以上のプレフィックスの長さ）：この粒度は、マルチホミングのレベルの増加に関連する精密トラフィックエンジニアリングを実行しようとする試みの副産物であるように見えます。現在、BGPには、存在を事前に知ることなくそのような接頭辞を集約できるようにするメカニズムはありません。満足のいく自動凝集を達成することで、末梢Assの不安定性に関連する非局所性の問題も大幅に減少します。
On the other hand, it may be that alterations to the connectivity of the net as described in [RFC3221] and Section 2.5.1 may limit the usefulness of auto-aggregation.
一方、[RFC3221]およびセクション2.5.1で説明されているように、ネットの接続性の変更は、自動凝集の有用性を制限する可能性がある可能性があります。
BGP today is a stable protocol under most circumstances, but this has been achieved at the expense of making the convergence time of the inter-domain routing system very slow under some conditions. This has a detrimental effect on the recovery of the network from failures.
今日のBGPは、ほとんどの状況では安定したプロトコルですが、これは、一部の条件下でドメイン間ルーティングシステムの収束時間を非常に遅くすることを犠牲にして達成されています。これは、障害からのネットワークの回復に有害な影響を及ぼします。
The timers that control the behavior of BGP are typically set to values in the region of several tens of seconds to a few minutes, which constrains the responsiveness of BGP to failure conditions.
BGPの動作を制御するタイマーは、通常、数十秒から数分の領域の値に設定されており、BGPの障害条件に対する応答性を制約します。
In the early days of deployment of BGP, poor network stability and router software problems lead to storms of withdrawals closely followed by re-advertisements of many prefixes. To control the load on routing software imposed by these "route flaps", route-flap damping was introduced into BGP. Most operators have now implemented a degree of route-flap damping in their deployments of BGP. This restricts the number of times that the routing tables will be rebuilt, even if a route is going up and down very frequently.
BGPの展開の初期には、ネットワークの安定性が低く、ルーターソフトウェアの問題は、多くの接頭辞の再承認に続いて引きこもりの嵐につながります。これらの「ルートフラップ」によって課されるルーティングソフトウェアの負荷を制御するために、ルートフラップダンピングがBGPに導入されました。現在、ほとんどのオペレーターは、BGPの展開にある程度のルートフラップダンピングを実装しています。これにより、ルートが非常に頻繁に上下している場合でも、ルーティングテーブルが再構築される回数が制限されます。
Unfortunately, route-flap damping responds to multiple flaps by increasing the route suppression time exponentially, which can result in some parts of the Internet being unreachable for hours at a time.
残念ながら、ルートフラップダンピングは、ルート抑制時間を指数関数的に増加させることにより、複数のフラップに応答します。これにより、インターネットの一部が一度に数時間到達できなくなる可能性があります。
There is evidence ([RFC3221] and measurements by some of the Sub-Group B members [Jiang02]) that in today's network, route flap is disproportionately associated with the fine-grained prefixes (length 22 or longer) associated with traffic engineering at the periphery of the network. Auto-aggregation, as previously discussed, would tend to mask such instability and prevent it being propagated across the whole network. Another question that needs to be studied is the continuing need for an architecture that requires global convergence. Some of our studies (unpublished) show that, in some localities at least, the network never actually reaches stability; i.e., it never really globally converges. Can a global, and beyond, network be designed with the requirement of global convergence?
今日のネットワークでは、ルートフラップがトラフィックエンジニアリングに関連する細粒のプレフィックス（長さ22以上）に不均衡に関連しているという証拠（[RFC3221]とサブグループメンバーの一部による測定値）があります。ネットワークの周辺。前述のように、自動凝集は、そのような不安定性を隠し、ネットワーク全体で伝播するのを防ぐ傾向があります。研究する必要があるもう1つの質問は、グローバルな収束を必要とするアーキテクチャの継続的な必要性です。私たちの研究の一部（未発表）は、少なくとも一部の地域では、ネットワークが実際に安定性に達することはないことを示しています。つまり、それは実際にはグローバルに収束することはありません。グローバルな、そしてそれ以降のネットワークは、グローバルな収束の要件で設計できますか？
There have been a number of instances, some of which are well documented, of a mistake in BGP configuration in a single peripheral AS propagating across the whole Internet and resulting in misrouting of most of the traffic in the Internet.
多くのインスタンスがあり、その一部は十分に文書化されており、単一の周辺機器でのBGP構成の間違いがインターネット全体で伝播し、インターネット内のほとんどのトラフィックを誤って誤解することになりました。
Similarly, a single route flap in a single peripheral AS can require route table recalculation across the entire Internet.
同様に、単一のルートフラップは、インターネット全体でルートテーブルの再計算を必要とするため、単一の周辺機器にフラップします。
This non-locality of effects is highly undesirable, and it would be a considerable improvement if such effects were naturally limited to a small area of the network around the problem. This is another argument for an architecture that does not require global convergence.
この非自発性効果は非常に望ましくありません。そのような効果が、問題の周りのネットワークの小さな領域に自然に制限されていれば、かなりの改善になります。これは、グローバルな収束を必要としないアーキテクチャの別の議論です。
As discussed previously, the increasing use of multi-homing as a robustness technique by peripheral networks requires that multiple routes have to be advertised for such domains. These routes must not be aggregated close in to the multi-homed domain as this would defeat the traffic engineering implied by multi-homing and currently cannot be aggregated further away from the multi-homed domain due to the lack of auto-aggregation capabilities. Consequentially, the default-free zone routing table is growing exponentially, as it was before CIDR.
前述のように、周辺ネットワークによる堅牢性のテクニックとしてのマルチホーミングの使用の増加には、そのようなドメインに対して複数のルートを宣伝する必要があります。これらのルートは、マルチホミングによって暗示されるトラフィックエンジニアリングを打ち負かすため、自動凝集機能がないためマルチホームドメインからさらに離れて集約することはできないため、マルチホームドメインに近づけて集約してはなりません。その結果、デフォルトのフリーゾーンルーティングテーブルは、CIDRの前と同様に指数関数的に成長しています。
The longest prefix match routing technique introduced by CIDR, and implemented in BGP-4, when combined with provider address allocation is an obstacle to effective multi-homing if load sharing across the multiple links is required. If an AS has been allocated, its addresses from an upstream provider, the upstream provider can aggregate those addresses with those of other customers and need only advertise a single prefix for a range of customers. But, if the customer AS is also connected to another provider, the second provider is not able to aggregate the customer addresses because they are not taken from his allocation, and will therefore have to announce a more specific route to the customer AS. The longest match rule will then direct all traffic through the second provider, which is not as required.
CIDRによって導入され、BGP-4で実装された最長のプレフィックスマッチルーティングテクニックは、プロバイダーアドレスの割り当てと組み合わせると、複数のリンク全体で負荷共有が必要な場合に効果的なマルチホミングの障害です。上流のプロバイダーからのアドレスが割り当てられている場合、上流のプロバイダーはこれらのアドレスを他の顧客のアドレスと集約することができ、さまざまな顧客に1つのプレフィックスのみを宣伝する必要があります。しかし、顧客が別のプロバイダーにも接続されている場合、2番目のプロバイダーは、割り当てから取られていないため、顧客アドレスを集約することができず、したがって、顧客へのより具体的なルートを発表する必要があります。最長の一致ルールは、2番目のプロバイダーを介してすべてのトラフィックを向けますが、これは必要ありません。
Example:
例：
\ /
AS1 AS2
\ /
AS3
Figure 1: Address Aggregation
図1：アドレス集約
In Figure 1, AS3 has received its addresses from AS1, which means AS1 can aggregate. But if AS3 wants its traffic to be seen equally both ways, AS3 is forced to announce both the aggregate and the more specific route to AS2.
図1では、AS3はAS1からアドレスを受け取りました。これは、AS1が集約できることを意味します。しかし、AS3がトラフィックを等しく両方の方法で見ることを望んでいる場合、AS3は集合体とAS2へのより具体的なルートの両方を発表することを余儀なくされます。
This problem has induced many ASs to apply for their own address allocation even though they could have been allocated from an upstream provider further exacerbating the default-free zone route table size explosion. This problem also interferes with the desire of many providers in the default-free zone to route only prefixes that are equal to or shorter than 20 or 19 bits.
この問題により、デフォルトのフリーゾーンルートテーブルサイズの爆発をさらに悪化させる上流のプロバイダーから割り当てられた可能性があるにもかかわらず、多くのASSが独自のアドレス割り当てを適用するように誘導されました。また、この問題は、デフォルトのないゾーン内の多くのプロバイダーが20または19ビットまたは19ビットと等しいまたは短いプレフィックスのみをルーティングするという要望を妨げます。
Note that some problems that are referred to as multi-homing issues are not, and should not be, solvable through the routing system (e.g., where a TCP load distributor is needed), and multi-homing is not a panacea for the general problem of robustness in a routing system [Berkowitz01].
マルチホームの問題と呼ばれるいくつかの問題は、ルーティングシステム（たとえば、TCP負荷ディストリビューターが必要な場合）を通じて解決できないことであり、そうすべきではないことに注意してください。ルーティングシステムの堅牢性[Berkowitz01]。
Editors' Note: A more recent analysis of multi-homing can be found in [RFC4116].
編集者注：マルチホミングの最近の分析は、[RFC4116]に記載されています。
The domain identifier or AS number is a 16-bit number. When this paper was originally written in 2001, allocation of AS numbers was increasing 51% a year [RFC3221] and exhaustion by 2005 was predicted.
ドメイン識別子またはAS番号は16ビット番号です。この論文が2001年に最初に書かれたとき、AS数の割り当ては年間51％増加し[RFC3221]、2005年までに疲労が予測されました。
According to some recent work again by Huston [Huston05], the rate of increase dropped off after the business downturn, but as of July 2005, well over half the available AS numbers (39000 out of 64510) had been allocated by IANA and around 20000 were visible in the global BGP routing tables. A year later, these figures had grown to 42000 (April 2006) and 23000 (August 2006), respectively, and the rate of allocation is currently about 3500 per year. Depending on the curve-fitting model used to predict when exhaustion will occur, the pool will run out somewhere between 2010 and 2013. There appear to be other factors at work in this rate of increase beyond an increase in the number of ISPs in business, although there is a fair degree of correlation between these numbers. AS numbers are now used for a number of purposes beyond that of identifying large routing domains: multi-homed sites acquire an AS number in order to express routing preferences to their various providers and AS numbers are used part of the addressing mechanism for MPLS/BGP-based virtual private networks (VPNs) [RFC4364]. The IETF has had a proposal under development for over four years to increase the available range of AS numbers to 32 bits [RFC4893]. Much of the slowness in development is due to the deployment challenge during transition. Because of the difficulties of transition, deployment needs to start well in advance of actual exhaustion so that the network as a whole is ready for the new capability when it is needed. This implies that standardization needs to be complete and implementations available at least well in advance of expected exhaustion so that deployment of upgrades that can handle the longer AS numbers, should be starting around 2008, to give a reasonable expectation that the change has been rolled out across a large fraction of the Internet by the time exhaustion occurs.
Huston [Huston05]による最近のいくつかの研究によると、ビジネスの低迷後に増加率は低下しましたが、2005年7月の時点で、利用可能な数の半分以上（64510のうち39000）がIANAおよび20000年頃に割り当てられていました。グローバルBGPルーティングテーブルに表示されていました。1年後、これらの数値はそれぞれ42000（2006年4月）と23000（2006年8月）に成長し、配分率は現在年間約3500です。疲労がいつ発生するかを予測するために使用される曲線フィッティングモデルに応じて、プールは2010年から2013年の間にどこかで尽きます。これらの数値の間にはかなりの相関がありますが。現在、大規模なルーティングドメインを識別することを超えて多くの目的に数値が使用されているため：マルチホームサイトは、さまざまなプロバイダーにルーティング設定を表現するためにAS番号を取得し、数字がMPLS/BGPのアドレス指定メカニズムの一部を使用します。 - ベースの仮想プライベートネットワーク（VPNS）[RFC4364]。IETFは、AS数の利用可能な範囲を32ビットに増やすために、4年以上にわたって開発中の提案がありました[RFC4893]。開発中の遅さの多くは、移行中の展開の課題によるものです。移行が困難なため、展開は実際の疲労のかなり前に開始する必要があり、ネットワーク全体が必要なときに新しい機能に対応する準備ができているようにする必要があります。これは、標準化が完全に、少なくとも予想される疲労のかなり前に利用可能な実装を必要とする必要があることを意味します。そのため、数字として長く処理できるアップグレードの展開は2008年頃に開始する必要があります。疲労が発生するまでにインターネットの大部分を超えて。
Editors' Note: The Regional Internet Registries (RIRs) are planning to move to assignment of the longer AS numbers by default on 1 January 2009, but there are concerns that significant numbers of routers will not have been upgraded by then.
編集者の注：地域のインターネットレジストリ（RIRS）は、2009年1月1日にデフォルトで数として長いものを割り当てることを計画していますが、それまでにかなりの数のルーターがアップグレードされなかったという懸念があります。
Tricks with discontinuous ASs are used by operators, for example, to implement anycast. Discontinuous ASs may also come into being by chance if a multi-homed domain becomes partitioned as a result of a fault and part of the domain can access the Internet through each connection. It may be desirable to make support for this kind of situation more transparent than it is at present.
不連続なお尻のトリックは、たとえばAnycastを実装するためにオペレーターによって使用されます。不連続なお尻は、障害の結果としてマルチホームのドメインが分割され、ドメインの一部が各接続を介してインターネットにアクセスできる場合、偶然になる可能性があります。この種の状況へのサポートを現在よりも透明にすることが望ましいかもしれません。
Load splitting or sharing was not a goal of the original designers of BGP and it is now a problem for today's network designers and managers. Trying to fool BGP into load sharing between several links is a constantly recurring exercise for most operators today.
負荷分割または共有は、BGPの元のデザイナーの目標ではなく、現在のネットワークデザイナーとマネージャーにとって問題になりました。BGPをいくつかのリンク間で負荷共有に惑わそうとすることは、今日のほとんどのオペレーターにとって絶えず繰り返される運動です。
As with the interval between "hello" messages in OSPF, the typical size and defined granularity (seconds to tens of seconds) of the "keepalive" time negotiated at start-up for each BGP connection constrains the responsiveness of BGP to link failures.
OSPFの「hello」メッセージ間の間隔と同様に、各BGP接続の起動時に交渉された「キープライブ」時間の典型的なサイズと定義された粒度（秒数秒から数秒）は、BGPの障害の応答性を制約します。
The recommended values and the available lower limit for this timer were set to limit the overhead caused by keepalive messages when link bandwidths were typically much lower than today. Analysis and experiment ([Alaettinoglu00], [Sandiick00] and [RFC4204]) indicate that faster links could sustain a much higher rate of keepalive messages without significantly impacting normal data traffic. This would improve responsiveness to link and node failures but with a corresponding increase in the risk of instability, if the error characteristics of the link are not taken properly into account when setting the keepalive interval.
このタイマーで推奨される値と利用可能な下限は、リンク帯域幅が通常今日よりもはるかに低い場合、キープライブメッセージによって引き起こされるオーバーヘッドを制限するように設定されました。分析と実験（[alaettinoglu00]、[sandiick00]、および[rfc4204]）は、より速いリンクが通常のデータトラフィックに大きく影響することなく、はるかに高いレートのキープライブメッセージを維持できることを示しています。これにより、リンク障害とノードの障害に対する応答性が向上しますが、リンクのエラー特性がキープライブ間隔を設定する際に適切に考慮されない場合、不安定性のリスクがそれに対応して増加します。
Editors' Note: A "fast" liveness protocol has been specified in [Katz10].
編集者注：[katz10]で「高速」livening livensionプロトコルが指定されています。
An additional problem with the hold-down mechanism in BGP is the amount of information that has to be exchanged to re-establish the database of route advertisements on each side of the link when it is re-established after a failure. Currently any failure, however brief forces a full exchange that could perhaps be constrained by retaining some state across limited time failures and using revision control, transaction and replication techniques to resynchronize the databases. Various techniques have been implemented to try to reduce this problem, but they have not yet been standardized.
BGPのホールドダウンメカニズムの追加の問題は、障害後に再確立されたときに、リンクの両側のルート広告のデータベースを再確立するために交換する必要がある情報の量です。ただし、現在の障害は、限られた時間の障害に一部の状態を維持し、改訂制御、トランザクション、およびレプリケーション技術を使用してデータベースを再同期させることにより、おそらく完全な交換を強制します。この問題を軽減しようとするためにさまざまな手法が実装されていますが、それらはまだ標準化されていません。
Today, many operators' backbone routers run both I-BGP and an intra-domain protocol to maintain the routes that reach between the borders of the domain. Exporting routes from BGP into the intra-domain protocol in use and bringing them back up to BGP is not recommended [RFC2791], but it is still necessary for all backbone routers to run both protocols. BGP is used to find the egress point and intra- domain protocol to find the path (next-hop router) to the egress point across the domain. This is not only a management problem but may also create other problems:
今日、多くのオペレーターのバックボーンルーターは、I-BGPとドメイン内プロトコルの両方を実行して、ドメインの境界の間に到達するルートを維持しています。BGPから使用中のドメイン内プロトコルへのルートをエクスポートし、BGPに戻すことは推奨されません[RFC2791]が、すべてのバックボーンルーターが両方のプロトコルを実行するためにはまだ必要です。BGPは、出口ポイントとイントラドメインプロトコルを見つけて、ドメインを横切る出口ポイントへのパス（ネクストホップルーター）を見つけるために使用されます。これは管理上の問題であるだけでなく、他の問題を引き起こす可能性もあります。
o BGP is a path-vector protocol (i.e., a protocol that uses distance metrics possibly overridden by policy metrics), whereas most intra-domain protocols are link-state protocols. As such, BGP is not optimized for convergence speed although distance-vector algorithms generally require less processing power. Incidentally, more efficient distance-vector algorithms are available such as [Xu97].
o BGPはパスベクトルプロトコル（つまり、ポリシーメトリックによって上書きされる可能性のある距離メトリックを使用するプロトコル）ですが、ほとんどのドメインプロトコルはリンク状態のプロトコルです。そのため、距離ベクトルアルゴリズムは通常、処理能力が少ないものの、BGPは収束速度に最適化されていません。ちなみに、[Xu97]など、より効率的な距離ベクトルアルゴリズムが利用可能です。
o The metrics used in BGP and the intra-domain protocol are rarely comparable or combinable. Whilst there are arguments that the optimizations inside a domain may be different from those for end-to-end paths, there are occasions, such as calculating the "topologically nearest" server when computable or combinable metrics would be of assistance.
o BGPおよびドメイン内プロトコルで使用されるメトリックは、比較可能または組み合わせることはめったにありません。ドメイン内の最適化はエンドツーエンドのパスの最適化とは異なる可能性があるという議論がありますが、計算可能または組み合わせ可能なメトリックが支援するときに「トポロジカルに最も近い」サーバーを計算するなどの場合があります。
o The policies that can be implemented using BGP are designed for control of traffic exchange between operators, not for controlling paths within a domain. Policies for BGP are most conveniently expressed in Routing Policy Support Language (RPSL) [RFC2622] and this could be extended if thought desirable to include additional policy information.
o BGPを使用して実装できるポリシーは、ドメイン内のパスを制御するためではなく、オペレーター間のトラフィック交換を制御するために設計されています。BGPのポリシーは、ルーティングポリシーサポート言語（RPSL）[RFC2622]で最も便利に表現されており、これは追加のポリシー情報を含めることが望ましい場合は拡張できます。
o If the NEXT HOP destination for a set of BGP routes becomes inaccessible because of intra-domain protocol problems, the routes using the vanished next hop have to be invalidated at the next available UPDATE. Subsequently, if the next-hop route reappears, this would normally lead to the BGP speaker requesting a full table from its neighbor(s). Current implementations may attempt to circumvent the effects of intra-domain protocol route flap by caching the invalid routes for a period in case the next hop is restored through the "graceful restart" mechanism.
o ドメイン内プロトコルの問題のためにBGPルートのセットの次のホップ宛先がアクセスできない場合、消滅した次のホップを使用するルートは、次の利用可能な更新で無効にする必要があります。その後、next-Hopルートが再び現れると、これは通常、BGPスピーカーが隣人から完全なテーブルを要求することにつながります。現在の実装は、「優雅な再起動」メカニズムを介して次のホップが復元された場合に備えて、無効なルートを一定期間キャッシュすることにより、ドメイン内プロトコルルートフラップの影響を回避しようとする場合があります。
Editors' Note: This was standardized as [RFC4724].
編集者注：これは[RFC4724]として標準化されました。
o Synchronization between intra-domain and inter-domain routing information is a problem as long as we use different protocols for intra-domain and inter-domain routing, which will most probably be the case even in the future because of the differing requirements in the two situations. Some sort of synchronization between those two protocols would be useful. In the RFC "IS-IS Transient Blackhole Avoidance" [RFC3277], the intra-domain protocol side of the story is covered (there is an equivalent discussion for OSPF).
o ドメイン内とドメイン間のルーティング情報間の同期は、ドメイン内およびドメイン間ルーティングに異なるプロトコルを使用している限り問題です。状況。これら2つのプロトコル間の何らかの同期が役立ちます。RFC「IS-IS一時的なブラックホール回避」[RFC3277]では、ストーリーのドメイン内プロトコル側の側面がカバーされています（OSPFには同等の議論があります）。
o Synchronizing in BGP means waiting for the intra-domain protocol to know about the same networks as the inter-domain protocol, which can take a significant period of time and slows down the convergence of BGP by adding the intra-domain protocol convergence time into each cycle. In general, operators no longer attempt full synchronization in order to avoid this problem (in general, redistributing the entire BGP routing feed into the local intra-domain protocol is unnecessary and undesirable but where a domain has multiple exits to peers and other non-customer networks, changes in BGP routing that affect the exit taken by traffic require corresponding re-routing in the intra-domain routing).
o BGPの同期とは、ドメイン内プロトコルがドメイン間プロトコルと同じネットワークについて知るのを待つことを意味します。サイクル。一般に、オペレーターはこの問題を回避するために完全に同期しなくなりました（一般に、BGPルーティングフィード全体をローカルドメイン内プロトコルに再配布することは不要で望ましくありませんが、ドメインにはピアや他の非カスタマーに複数の出口がある場合ネットワーク、トラフィックが取る出口に影響するBGPルーティングの変更には、ドメイン内ルーティングで対応する再ルーティングが必要です）。
There are several classes of issues with current BGP policy:
現在のBGPポリシーにはいくつかのクラスの問題があります。
o Policy is installed in an ad hoc manner in each autonomous system. There isn't a method for ensuring that the policy installed in one router is coherent with policies installed in other routers.
o ポリシーは、各自律システムにアドホックな方法でインストールされます。1つのルーターにインストールされているポリシーが、他のルーターにインストールされたポリシーと一貫性があることを保証する方法はありません。
o As described in Griffin [Griffin99] and in McPherson [RFC3345], it is possible to create policies for ASs, and instantiate them in routers, that will cause BGP to fail to converge in certain types of topology
o Griffin [Griffin99]およびMcPherson [RFC3345]で説明されているように、ASSのポリシーを作成し、ルーターにインスタンス化することが可能です。
o There is no available network model for describing policy in a coherent manner.
o ポリシーを一貫した方法で説明するための利用可能なネットワークモデルはありません。
Policy management is extremely complex and mostly done without the aid of any automated procedures. The extreme complexity means that a highly-qualified specialist is required for policy management of border routers. The training of these specialists is quite lengthy and needs to involve long periods of hands-on experience. There is, therefore, a shortage of qualified staff for installing and maintaining the routing policies. Because of the overall complexity of BGP, policy management tends to be only a relatively small topic within a complete BGP training course and specialized policy management training courses are not generally available.
ポリシー管理は非常に複雑であり、ほとんど自動化された手順を使用せずに行われます。極端な複雑さは、ボーダールーターの政策管理に高度に資格のある専門家が必要であることを意味します。これらの専門家のトレーニングは非常に長く、長期間の実践的な経験を伴う必要があります。したがって、ルーティングポリシーをインストールおよび維持するための資格のあるスタッフが不足しています。BGPの全体的な複雑さのため、政策管理は完全なBGPトレーニングコース内で比較的小さなトピックに過ぎない傾向があり、一般的に専門的な政策管理トレーニングコースは利用できません。
While many of the issues with BGP security have been traced either to implementation issues or to operational issues, BGP is vulnerable to Distributed Denial of Service (DDoS) attacks. Additionally, routers can be used as unwitting forwarders in DDoS attacks on other systems.
BGPセキュリティに関する問題の多くは、実装の問題または運用上の問題のいずれかに追跡されていますが、BGPは分散型サービス拒否（DDO）攻撃に対して脆弱です。さらに、ルーターは、他のシステムでのDDOS攻撃の無意識のフォワーダーとして使用できます。
Though DDoS attacks can be fought in a variety of ways, mostly using filtering methods, it takes constant vigilance. There is nothing in the current architecture or in the protocols that serves to protect the forwarders from these attacks.
DDOS攻撃はさまざまな方法で戦うことができますが、主にフィルタリング方法を使用して、一定の警戒が必要です。現在のアーキテクチャやプロトコルには、これらの攻撃からフォワーダーを保護するのに役立つものは何もありません。
Editors' Note: Since the original document was written, the issue of inter-domain routing security has been studied in much greater depth. The rpsec working group has gone into the security issues in great detail [RFC4593] and readers should refer to that work to understand the security issues.
編集者注：元のドキュメントが書かれているため、ドメイン間ルーティングセキュリティの問題は、はるかに深く研究されています。RPSECのワーキンググループは、セキュリティの問題に非常に詳細に進み[RFC4593]、読者はセキュリティの問題を理解するためにその作業を参照する必要があります。
Recently, BGP has been modified to function as a signaling protocol for MPLS and for VPNs [RFC4364]. Some people see this overloading of the BGP protocol as a boon whilst others see it as a problem. While it was certainly convenient as a vehicle for vendors to deliver extra functionality to their products, it has exacerbated some of the performance and complexity issues of BGP. Two important problems are that, the additional state that must be retained and refreshed to support VPN (Virtual Private Network) tunnels and that BGP does not provide end-to-end notification making it difficult to confirm that all necessary state has been installed or updated.
最近、BGPはMPLSおよびVPNSのシグナル伝達プロトコルとして機能するように変更されました[RFC4364]。一部の人々は、BGPプロトコルのこの過負荷を恩恵と見ていますが、他の人はそれを問題と見なしています。ベンダーが製品に追加の機能を提供する手段として確かに便利でしたが、BGPのパフォーマンスと複雑さの問題のいくつかを悪化させています。2つの重要な問題は、VPN（仮想プライベートネットワーク）トンネルをサポートするために保持およびリフレッシュする必要がある追加の状態であり、BGPがエンドツーエンドの通知を提供しないため、必要なすべての状態がインストールまたは更新されていることを確認することが困難であることです。。
It is an open question whether VPN signaling protocols should remain separate from the route determination protocols.
VPNシグナル伝達プロトコルがルート決定プロトコルとは分離されたままであるかどうかは未解決の問題です。
The fact that service providers need to maintain two completely separate networks, one for IPv4 and one for IPv6, has been a real hindrance to the introduction of IPv6. When IPv6 does get widely deployed, it will do so without causing the disappearance of IPv4. This means that unless something is done, service providers would need to maintain the two networks in perpetuity (at least on the foreshortened timescale which the Internet world uses).
サービスプロバイダーが2つの完全に個別のネットワークを維持する必要があるという事実は、IPv4用とIPv6用の2つのネットワークを維持する必要があります。IPv6の導入の真の障害でした。IPv6が広く展開されると、IPv4の消失を引き起こすことなくそうします。これは、何かが行われない限り、サービスプロバイダーは2つのネットワークを永続的に維持する必要があることを意味します（少なくともインターネットの世界が使用する予定されたタイムスケールで）。
It is possible to use a single set of BGP speakers with multi-protocol extensions [RFC4760] to exchange information about both IPv4 and IPv6 routes between domains, but the use of TCP as the transport protocol for the information exchange results in an asymmetry when choosing to use one of TCP over IPv4 or TCP over IPv6. Successful information exchange confirms one of IPv4 or IPv6 reachability between the speakers but not the other, making it possible that reachability is being advertised for a protocol for which it is not present.
Multi-Protocol Extensions [RFC4760]を使用したBGPスピーカーの単一セットを使用して、ドメイン間のIPv4とIPv6ルートの両方に関する情報を交換することができますが、情報交換のトランスポートプロトコルとしてのTCPの使用は、選択する際の非対称性になります。IPv4を介してTCPまたはIPv6を介してTCPを使用するには。情報交換は、スピーカー間のIPv4またはIPv6の到達可能性のいずれかを確認しますが、他のスピーカー間では到達可能性ではなく、存在しないプロトコルに対して到達可能性が宣伝されている可能性があります。
Also, current implementations do not allow a route to be advertised for both IPv4 and IPv6 in the same UPDATE message, because it is not possible to explicitly link the reachability information for an address family to the corresponding next-hop information. This could be improved, but currently results in independent UPDATEs being exchanged for each address family.
また、現在の実装では、同じ更新メッセージでIPv4とIPv6の両方に対してルートを宣伝することはできません。これは、住所ファミリのReachability情報を対応するNext-Hop情報に明示的にリンクすることはできないためです。これは改善される可能性がありますが、現在、各住所ファミリと独立した更新が交換されています。
The tools available to network operators to assist in configuring and maintaining effective inter-domain routing in line with their defined policies are limited, and almost entirely passive.
ネットワークオペレーターが利用できるツールは、定義されたポリシーに沿って効果的なドメイン間ルーティングの構成と維持を支援することが限られており、ほぼ完全に受動的です。
o There are no tools to facilitate the planning of the routing of a domain (either intra- or inter-domain); there are a limited number of display tools that will visualize the routing once it has been configured.
o ドメインのルーティングの計画を容易にするツールはありません（ドメイン内または領域間）。ルーティングが構成されたら視覚化するディスプレイツールは限られています。
o There are no tools to assist in converting business policy specifications into the Routing Policy Specification Language (RPSL) language (see Section 5.14.1); there are limited tools to convert the RPSL into BGP commands and to check, post-facto, that the proposed policies are consistent with the policies in adjacent domains (always provided that these have been revealed and accurately documented).
o ビジネスポリシーの仕様をルーティングポリシー仕様言語（RPSL）言語に変換するのを支援するツールはありません（セクション5.14.1を参照）。RPSLをBGPコマンドに変換し、提案されたポリシーが隣接するドメインのポリシーと一致していることを確認するための限られたツールがあります（常にこれらが明らかにされ、正確に文書化されていることを条件としています）。
o There are no tools to monitor BGP route changes in real-time and warn the operator about policy inconsistencies and/or instabilities.
o BGPルートの変更をリアルタイムで監視し、ポリシーの矛盾や不安定性についてオペレーターに警告するツールはありません。
The following section summarizes the tools that are available to assist with the use of RPSL. Note they are all batch mode tools used off-line from a real network. These tools will provide checks for skilled inter-domain routing configurers but limited assistance for the novice.
次のセクションでは、RPSLの使用を支援するために利用できるツールをまとめたものです。これらはすべて、実際のネットワークからオフラインで使用されるバッチモードツールであることに注意してください。これらのツールは、熟練したドメイン間ルーティング構成のチェックを提供しますが、初心者の支援は限られています。
Routing Policy Specification Language (RPSL) [RFC2622] enables a network operator to describe routes, routers, and Autonomous Systems (ASs) that are connected to the local AS.
ルーティングポリシー仕様言語（RPSL）[RFC2622]により、ネットワークオペレーターはローカルASに接続されているルート、ルーター、および自律システム（ASS）を記述できます。
Using the RPSL language (see [RFC2650]) a distributed database is created to describe routing policies in the Internet as described by each AS independently. The database can be used to check the consistency of routing policies stored in the database.
RPSL言語（[RFC2650]を参照）を使用して、それぞれが独立して説明しているように、インターネット内のルーティングポリシーを記述するために分散データベースが作成されます。データベースを使用して、データベースに保存されているルーティングポリシーの一貫性を確認できます。
Tools exist [IRRToolSet] that can use the database to (among other things):
データベースを（とりわけ）に使用できるツールが存在します。
o Flag when two neighboring network operators specify conflicting or inconsistent routing information exchanges with each other and also detect global inconsistencies where possible;
o フラグ2つの隣接するネットワークオペレーターが、相反するまたは一貫性のないルーティング情報交換を互いに指定し、可能な場合はグローバルな矛盾を検出した場合。
o Extract all AS-paths between two networks that are allowed by routing policy from the routing policy database; display the connectivity a given network has according to current policies.
o ルーティングポリシーデータベースからルーティングポリシーによって許可される2つのネットワーク間ですべてのパスを抽出します。特定のネットワークに現在のポリシーに従って接続を表示します。
The database queries enable a partial-static solution to the convergence problem. They analyze routing policies of a very limited part of Internet and verify that they do not contain conflicts that could lead to protocol divergence. The static analysis of convergence of the entire system has exponential time complexity, so approximation algorithms would have to be used.
データベースクエリは、収束問題に対する部分的な静的ソリューションを有効にします。インターネットの非常に限られた部分のルーティングポリシーを分析し、プロトコルの発散につながる可能性のある競合が含まれていないことを確認します。システム全体の収束の静的分析には、指数関数的な時間の複雑さがあるため、近似アルゴリズムを使用する必要があります。
The toolset also allows router configurations to be generated from RPSL specifications.
ツールセットでは、RPSL仕様からルーター構成を生成することもできます。
Editors' Note: The "Internet Routing Registry Toolset" was originally developed by the University of Southern California's Information Sciences Institute (ISI) between 1997 and 2001 as the "Routing Arbiter ToolSet" (RAToolSet) project. The toolset is no longer developed by ISI but is used worldwide, so after a period of improvement by RIPE NCC, it has now been transferred to the Internet Systems Consortium (ISC) for ongoing maintenance as a public resource.
編集者注：「インターネットルーティングレジストリツールセット」は、1997年から2001年の間に南カリフォルニア大学情報科学研究所（ISI）によって「ルーティングアービターツールセット」（Ratoolset）プロジェクトとして開発されました。ツールセットはISIによって開発されなくなりましたが、世界中で使用されているため、Ripe NCCによる改善期間の後、公共リソースとして継続的なメンテナンスのためにインターネットシステムコンソーシアム（ISC）に転送されました。
As this is an informational document on the history of requirements in IDR and on the problems facing the current Internet IDR architecture, it does not as such create any security problems. On the other hand, some of the problems with today's Internet routing architecture do create security problems, and these have been discussed in the text above.
これは、IDRの要件の履歴と現在のインターネットIDRアーキテクチャが直面している問題に関する情報文書であるため、セキュリティの問題を作成するものではありません。一方、今日のインターネットルーティングアーキテクチャの問題のいくつかは、セキュリティの問題を引き起こし、これらは上記のテキストで説明されています。
The document is derived from work originally produced by Babylon. Babylon was a loose association of individuals from academia, service providers, and vendors whose goal was to discuss issues in Internet routing with the intention of finding solutions for those problems.
このドキュメントは、元々バビロンが製造した作業から派生しています。バビロンは、アカデミア、サービスプロバイダー、およびベンダーの個人とのゆるい関係でした。そのベンダーは、これらの問題の解決策を見つけることを目的として、インターネットルーティングの問題を議論することを目標としていました。
The individual members who contributed materially to this document are: Anders Bergsten, Howard Berkowitz, Malin Carlzon, Lenka Carr Motyckova, Elwyn Davies, Avri Doria, Pierre Fransson, Yong Jiang, Dmitri Krioukov, Tove Madsen, Olle Pers, and Olov Schelen.
この文書に実質的に貢献した個々のメンバーは、アンダース・ベルクステン、ハワード・バーコウィッツ、マリン・カールゾン、レンカ・カー・モティコヴァ、エルウィン・デイビス、アヴリ・ドリア、ピエール・フランソン、ヨン・ジアン、ドミトリ・クリコフ、オル・マドセン、オロ・シェルンです。
Thanks also go to the members of Babylon and others who did substantial reviews of this material. Specifically, we would like to acknowledge the helpful comments and suggestions of the following individuals: Loa Andersson, Tomas Ahlstrom, Erik Aman, Thomas Eriksson, Niklas Borg, Nigel Bragg, Thomas Chmara, Krister Edlund, Owe Grafford, Susan Hares, Torbjorn Lundberg, David McGrew, Jasminko Mulahusic, Florian-Daniel Otel, Bernhard Stockman, Tom Worster, and Roberto Zamparo.
また、この資料のかなりのレビューを行ってくれたバビロンと他の人たちにも感謝します。具体的には、Loa Andersson、Tomas Ahlstrom、Erik Aman、Thomas Eriksson、Niklas Borg、Nigel Bragg、Thomas Chmara、Krister Edlund、Owe Grafford、Susan Hares、Torbjorn Lundberg。デビッド・マクグリュー、ジャスミンコ・ムラフジック、フロリアン・ダニエル・オテル、ベルンハルト・ストックマン、トム・ワースター、ロベルト・ザンパロ。
In addition, the authors are indebted to the folks who wrote all the references we have consulted in putting this paper together. This includes not only the references explicitly listed below, but also those who contributed to the mailing lists we have been participating in for years.
さらに、著者は、この論文をまとめる際に私たちが相談したすべての参照を書いた人々に感謝しています。これには、以下に明示的にリストされている参考文献だけでなく、私たちが何年も参加してきたメーリングリストに貢献した参考文献も含まれます。
The editors thank Lixia Zhang, as IRSG document shepherd, for her help and her perseverance, without which this document would never have been published.
編集者は、IRSGがShepherdを文書化したLixia Zhangに、彼女の助けと彼女の忍耐に感謝します。
Finally, it is the editors who are responsible for any lack of clarity, any errors, glaring omissions or misunderstandings.
最後に、明確さの欠如、エラー、明白な省略、または誤解を担当するのは編集者です。
[Alaettinoglu00] Alaettinoglu, C., Jacobson, V., and H. Yu, "Towards Milli-Second IGP Convergence", Work in Progress, November 2000.
[Alaettinoglu00] Alaettinoglu、C.、Jacobson、V。、およびH. Yu、「Milli-cond Igp Convergenceに向けて」、2000年11月、進行中の作業。
[Berkowitz01] Berkowitz, H. and D. Krioukov, "To Be Multihomed: Requirements and Definitions", Work in Progress, July 2001.
[Berkowitz01] Berkowitz、H。およびD. Krioukov、「Multihomed：要件と定義」、2001年7月、進行中の作業。
[Breslau90] Breslau, L. and D. Estrin, "An Architecture for Network-Layer Routing in OSI", Proceedings of the ACM symposium on Communications architectures & protocols , 1990.
[Breslau90] Breslau、L。およびD. Estrin、「OSIのネットワーク層ルーティングのアーキテクチャ」、Communications Architectures＆Protocols、1990に関するACMシンポジウムの議事録。
[Chapin94] Piscitello, D. and A. Chapin, "Open Systems Networking: TCP/IP & OSI", Addison-Wesley Copyright assigned to authors, 1994, <http://www.interisle.net/OSN/OSN.html>.
[Chapin94] Piscitello、D。およびA. Chapin、「Open Systems Networking：TCP/IP＆OSI」、Addison-Wesley著作権著作権、1994年、<http://www.interisle.net/osn/osn.html>。
[Chiappa91] Chiappa, J., "A New IP Routing and Addressing Architecture", Work in Progress, 1991.
[Chiappa91] Chiappa、J。、「新しいIPルーティングとアドレス指定アーキテクチャ」、Work in Progress、1991。
[Clark00] Clark, D. and M. Blumenthal, "Rethinking the design of the Internet: The end to end arguments vs. the brave new world", August 2000, <http://dspace.mit.edu/handle/1721.1/1519>.
[Clark00] Clark、D。およびM. Blumenthal、「インターネットのデザインを再考する：エンドツーエンドの議論vs. The Brave New World」、<http://dspace.mit.edu/handle/1721.1.1/1519>。
[Griffin99] Griffin, T. and G. Wilfong, "An Analysis of BGP Convergence Properties", Association for Computing Machinery Proceedings of SIGCOMM '99, 1999.
[Griffin99] Griffin、T。およびG. Wilfong、「BGP収束特性の分析」、Sigcomm '99、1999のコンピューティング機械の議事録協会。
[Huitema90] Huitema, C. and W. Dabbous, "Routeing protocols development in the OSI architecture", Proceedings of ISCIS V Turkey, 1990.
[Huitema90] Huitema、C。およびW. dabbous、「OSI建築におけるプロトコルのルーティング開発」、ISCIS v Turkeyの議事録、1990年。
[Huston05] Huston, G., "Exploring Autonomous System Numbers", The ISP Column , August 2005, <http://www.potaroo.net/ispcol/2005-08/as.html>.
[Huston05] Huston、G。、「自律システム番号の探索」、ISP列、2005年8月、<http://www.potaroo.net/ispcol/2005-08/as.html>。
[INARC89] Mills, D., Ed. and M. Davis, Ed., "Internet Architecture Workshop: Future of the Internet System Architecture and TCP/IP Protocols - Report", Internet Architecture Task Force INARC, 1990, <http://www.eecis.udel.edu/~mills/ database/papers/inarc.pdf>.
[INARC89] Mills、D.、ed。and M. Davis、ed。、「インターネットアーキテクチャワークショップ：インターネットシステムアーキテクチャとTCP/IPプロトコルの未来 - レポート」、インターネットアーキテクチャタスクフォースINARC、1990、<http://www.eecis.udel.edu/~Mills/Database/Papers/inarc.pdf>。
[IRRToolSet] Internet Systems Consortium, "Internet Routing Registry Toolset Project", IRR Tool Set Website, 2006, <http://www.isc.org/index.pl?/sw/IRRToolSet/>.
[Irrtoolset]インターネットシステムコンソーシアム、「インターネットルーティングレジストリツールセットプロジェクト」、IRRツールセットWebサイト、2006、<http://www.isc.org/index.pl?/sw/irrtoolset/>。
[ISO10747] ISO/IEC, "Protocol for Exchange of Inter-Domain Routeing Information among Intermediate Systems to support Forwarding of ISO 8473 PDUs", International Standard 10747 , 1993.
[ISO10747] ISO/IEC、「ISO 8473 PDUの転送をサポートするための中間システム間の情報交換情報の交換のためのプロトコル」、International Standard 10747、1993。
[Jiang02] Jiang, Y., Doria, A., Olsson, D., and F. Pettersson, "Inter-domain Routing Stability Measurement", 2002, <http://psg.com/~avri/papers/paper-yong-hpsr2002-final.pdf>.
[Jiang02] Jiang、Y.、Doria、A.、Olsson、D。、およびF. Pettersson、「ドメイン間ルーティング安定性測定」、2002年、<http://psg.com/~avri/papers/paper--Yong-HPSR2002-Final.pdf>。
[Katz10] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, January 2010.
[Katz10] Katz、D。およびD. Ward、「双方向転送検出」、2010年1月の作業。
[Labovitz02] Labovitz, C., Ahuja, A., Farnam, J., and A. Bose, "Experimental Measurement of Delayed Convergence", NANOG , 2002.
[Labovitz02] Labovitz、C.、Ahuja、A.、Farnam、J。、およびA. Bose、「遅延収束の実験測定」、Nanog、2002。
[NewArch03] Clark, D., Sollins, K., Wroclawski, J., Katabi, D., Kulik, J., Yang, X., Braden, R., Faber, T., Falk, A., Pingali, V., Handley, M., and N. Chiappa, "New Arch: Future Generation Internet Architecture", December 2003, <http://www.isi.edu/newarch/iDOCS/final.finalreport.pdf>.
[Newarch03] Clark、D.、Sollins、K.、Wroclawski、J.、Katabi、D.、Kulik、J.、Yang、X.、Braden、R.、Faber、T.、Falk、A.、Pingali、PingaliV.、Handley、M。、およびN. Chiappa、「New Arch：Future Generation Internet Architecture」、2003年12月、<http://www.isi.edu/newarch/idocs/final.finalreport.pdf>。
[RFC0904] Mills, D., "Exterior Gateway Protocol formal specification", RFC 904, April 1984.
[RFC0904] Mills、D。、「Exterior Gateway Protocol Formal Specification」、RFC 904、1984年4月。
[RFC0975] Mills, D., "Autonomous confederations", RFC 975, February 1986.
[RFC0975]ミルズ、D。、「自律的なコンフェデレーション」、RFC 975、1986年2月。
[RFC1105] Lougheed, K. and J. Rekhter, "Border Gateway Protocol (BGP)", RFC 1105, June 1989.
[RFC1105] Lougheed、K。およびJ. Rekhter、「Border Gateway Protocol（BGP）」、RFC 1105、1989年6月。
[RFC1126] Little, M., "Goals and functional requirements for inter-autonomous system routing", RFC 1126, October 1989.
[RFC1126] Little、M。、「自律システム間ルーティングの目標と機能的要件」、RFC 1126、1989年10月。
[RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1163, June 1990.
[RFC1163] Lougheed、K。およびY. Rekhter、「Border Gateway Protocol（BGP）」、RFC 1163、1990年6月。
[RFC1267] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol 3 (BGP-3)", RFC 1267, October 1991.
[RFC1267] Lougheed、K。およびY. Rekhter、「Border Gateway Protocol 3（BGP-3）」、RFC 1267、1991年10月。
[RFC1752] Bradner, S. and A. Mankin, "The Recommendation for the IP Next Generation Protocol", RFC 1752, January 1995.
[RFC1752] Bradner、S。およびA. Mankin、「IP Next Generation Protocolの推奨」、RFC 1752、1995年1月。
[RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture", RFC 1753, December 1994.
[RFC1753] Chiappa、J。、「Nimrodルーティングとアドレス指定アーキテクチャのIPNG技術要件」、RFC 1753、1994年12月。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y。およびT. Li、「A Border Gateway Protocol 4（BGP-4）」、RFC 1771、1995年3月。
[RFC1992] Castineyra, I., Chiappa, N., and M. Steenstrup, "The Nimrod Routing Architecture", RFC 1992, August 1996.
[RFC1992] Castineyra、I.、Chiappa、N。、およびM. Steenstrup、「Nimrod Routing Architecture」、RFC 1992、1996年8月。
[RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., and V. Jacobson, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[RFC2362] Estrin、D.、Farinacci、D.、Helmy、A.、Thaler、D.、Deering、S.、Handley、M。、およびV. Jacobson、「Protocol Independent Multicast-Sparse Mode（PIM-SM）：プロトコル仕様」、RFC 2362、1998年6月。
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, "Routing Policy Specification Language (RPSL)", RFC 2622, June 1999.
[RFC2622] Alaettinoglu、C.、Villamizar、C.、Gerich、E.、Kessens、D.、Meyer、D.、Bates、T.、Karrenberg、D。、およびM. Terpstra、「ルーティングポリシー仕様言語（RPSL））」、RFC 2622、1999年6月。
[RFC2650] Meyer, D., Schmitz, J., Orange, C., Prior, M., and C. Alaettinoglu, "Using RPSL in Practice", RFC 2650, August 1999.
[RFC2650] Meyer、D.、Schmitz、J.、Orange、C.、Prior、M。、およびC. Alaettinoglu、「RPSLを実際に使用」、RFC 2650、1999年8月。
[RFC2791] Yu, J., "Scalable Routing Design Principles", RFC 2791, July 2000.
[RFC2791] Yu、J。、「スケーラブルなルーティング設計原則」、RFC 2791、2000年7月。
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[RFC3221] Huston、G。、「インターネット内のドメイン間ルーティングに関する解説」、RFC 3221、2001年12月。
[RFC3277] McPherson, D., "Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance", RFC 3277, April 2002.
[RFC3277] McPherson、D。、「中間システムから中間システム（IS-IS）過渡的なブラックホール回避」、RFC 3277、2002年4月。
[RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, August 2002.
[RFC3345] McPherson、D.、Gill、V.、Walton、D。、およびA. Retana、「Border Gateway Protocol（BGP）永続的なルート振動条件」、RFC 3345、2002年8月。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618] Fenner、B。およびD. Meyer、「マルチキャストソースディスカバリープロトコル（MSDP）」、RFC 3618、2003年10月。
[RFC3765] Huston, G., "NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control", RFC 3765, April 2004.
[RFC3765] Huston、G。、「ボーダーゲートウェイプロトコル（BGP）ルートスコープ制御のためのNoper Community」、RFC 3765、2004年4月。
[RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): Protocol Specification", RFC 3913, September 2004.
[RFC3913] Thaler、D。、「Border Gateway Multicast Protocol（BGMP）：プロトコル仕様」、RFC 3913、2004年9月。
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. Gill, "IPv4 Multihoming Practices and Limitations", RFC 4116, July 2005.
[RFC4116] Eabley、J.、Lindqvist、K.、Davies、E.、Black、B。、およびV. Gill、「IPv4マルチホームの実践と制限」、RFC 4116、2005年7月。
[RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204] Lang、J。、「Link Management Protocol（LMP）」、RFC 4204、2005年10月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想ネットワーク（VPNS）」、RFC 4364、2006年2月。
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[RFC4593] Barbir、A.、Murphy、S。、およびY. Yang、「ルーティングプロトコルに対する一般的な脅威」、RFC 4593、2006年10月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H.、およびI. Kouvelas、「プロトコル独立マルチキャスト - スパースモード（PIM -SM）：プロトコル仕様（改訂）」、RFC 4601、2006年8月。
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, January 2007.
[RFC4724] Sangli、S.、Chen、E.、Fernando、R.、Scudder、J。、およびY. Rekhter、「BGPの優雅な再起動メカニズム」、RFC 4724、2007年1月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760] Bates、T.、Chandra、R.、Katz、D。、およびY. Rekhter、「BGP-4のマルチプロトコル拡張」、RFC 4760、2007年1月。
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS Number Space", RFC 4893, May 2007.
[RFC4893] Vohra、Q。およびE. Chen、「Number Spaceとしての4オクテットのBGPサポート」、RFC 4893、2007年5月。
[RFC5772] Doria, A., Davies, E., and F. Kastenholz, "A Set of Possible Requirements for a Future Routing Architecture", RFC 5772, February 2010.
[RFC5772] Doria、A.、Davies、E。、およびF. Kastenholz、「将来のルーティングアーキテクチャの可能な要件のセット」、RFC 5772、2010年2月。
[Sandiick00] Sandick, H., Squire, M., Cain, B., Duncan, I., and B. Haberman, "Fast LIveness Protocol (FLIP)", Work in Progress, February 2000.
[Sandiick00] Sandick、H.、Squire、M.、Cain、B.、Duncan、I.、およびB. Haberman、「Fast Livension Protocol（Flip）」、Work in Progress、2000年2月。
[Tsuchiya87] Tsuchiya, P., "An Architecture for Network-Layer Routing in OSI", Proceedings of the ACM workshop on Frontiers in computer communications technology , 1987.
[Tsuchiya87] Tsuchiya、P。、「OSIのネットワーク層ルーティングのためのアーキテクチャ」、コンピューター通信技術のフロンティアに関するACMワークショップの議事録、1987年。
[Xu97] Xu, Z., Dai, S., and J. Garcia-Luna-Aceves, "A More Efficient Distance Vector Routing Algorithm", Proc IEEE MILCOM 97, Monterey, California, Nov 1997, <http:// www.cse.ucsc.edu/research/ccrg/publications/ zhengyu.milcom97.pdf>.
[Xu97] Xu、Z.、Dai、S。、およびJ. Garcia-Luna-aceves、「より効率的な距離ベクトルルーティングアルゴリズム」、Proc Ieee Milcom 97、カリフォルニア州モントレー、1997年11月、<http：// wwwwww.cse.ucsc.edu/research/ccrg/publications/zhengyu.milcom97.pdf>。
Authors' Addresses
著者のアドレス
Elwyn B. Davies Folly Consulting Soham, Cambs UK
Elwyn B. Davies Folly Consulting Soham、Cambs UK
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Avri Doria LTU Lulea, 971 87 Sweden
Avri Doria Ltu Lulea、971 87スウェーデン
Phone: +1 401 663 5024
EMail: avri@acm.org