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）に集中し、また、ドメイン間およびドメイン内ルーティングとの関係を考慮すると、インターネットドメインベースのルーティングシステムの状態を分析します。編集上の追加はそれは仲間ドキュメントである2006年までの動向を反映して、2001年にあるように見えたとして分析をルーティングシステムを見ているRFC 1126およびその他の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.
この文書は、インターネットコミュニティのための歴史的な文書を定義します。この文書はインターネットResearch Task Force（IRTF）の製品です。 IRTFはインターネット関連の研究開発活動の成果を公表しています。これらの結果は、展開に適していない可能性があります。このRFCはインターネットResearch Task Force（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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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）椅子、アブハアフジャとショーン・ドーランは、ドメイン間ルーティング（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.
同時に、独立した努力は、同様の目的で、スウェーデンで開始されました。 、ドメイン間ルーティングの歴史を理解するために、サービスプロバイダから見た問題を検索するには、とフォローのための要件の提案を開発するために組み立てベンダー、サービスプロバイダー、および学界からの参加を得て、自らバビロンを呼び出すチーム、現在のルーティングアーキテクチャの上。このグループのアプローチは、現在のルーティングアーキテクチャと実践から始まる進化のアプローチが必要。換言すれば、グループは、進化戦略の開発に自分自身を制限し、その結果、アーキテクチャは、おそらくドメインベースのままであると仮定する。バビロン基は、後に元のRRGサブグループAからそれを区別するためにサブグループBとしてIRTF RRGに折り畳まれました
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は、最近の過去に遭遇された問題の分析によって動機づけられた設定新しい要件の開発を、それを育てます。このドキュメントはIRTFのRRGサブグループAおよびB [RFC5772によって別々に捕捉され、将来のルーティングシステムの要件を文書ルーティング要件文書（「将来のルーティングアーキテクチャの可能な要件のセット」）に対応ように意図されています]。
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は、それが必ずしも公開時点での最新の技術の理解や研究グループの技術的なコンセンサスのいずれかを表すものではないことを理解した上で完了した作業の歴史的な記録として、本書の出版をサポート。文書には、年間のバビロンチームのメンバー、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).
その存在の大部分のために、インターネットは、ルータとインフラストラクチャを構成する他のノードが、主所有線に沿って、管理ドメインのセットに分割されるドメイン指向ルーティングシステムを使用してきました。多分管理ドメインのサブセットが、ノードの有限の、接続されたセット（少なくとも通常動作時）から構成されている（また、自律システム（のAS）として知られている）個々のルーティングドメイン。各ルーティングドメインは、単一の管理権限によって管理ルーティングや他の政策の一貫性セットの対象となります。ドメインは、非常に大規模なネットワークを生成する、より大きなインターネットを形成するように連結されています。実際には、我々は、ドメインのネットワーク全体についての中心的な知識がないので、それは程度が無限であるかのように、このネットワークを治療することがあります。ルーティングドメインの概念の初期のプレゼンテーションが1987 [Tsuchiya87]からポール・フランシスOSIルーティングアーキテクチャ論文に見出すことができる（ポール・フランシスが以前ポール土屋として知られていました）。
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のドメイン内ルーティングとの関係で歴史的な視点を提供します。 「目標と間自律システムルーティングの機能要件」[RFC1126] - 1989年にボーダーゲートウェイプロトコル（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の後に出版されたドメインベースのルーティングのための要件のいくつかの他の作品を見ます。この作品は、歴史的な視点をfleshesと要件の新しいセットを構築する際に有益であり、代替的なアプローチにいくつかの追加の洞察を提供します。
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/7警戒大量の運用活動なしには達成されない：インターネットルーティングは、多くの場合、安定性の限界に近い動作しているように見えます。ならびにその意図エンドポイントにトラフィックを向けるように、ドメイン間ルーティングメカニズムは、ドメインを通信する、競合のためにドメイン固有のルーティングポリシーのホストを実現することが期待されます。その結果は、ドメイン間ルーティングメカニズムについて、特にとして、理想的ではないが、それは、コンピュータの何百万人に任意の-to-anyの接続性を提供するという第一の目標でかなり公正仕事をしていません。
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.
事例証拠の大きな体上でだけでなく、実験的証拠[Labovitz02]と特定のポリシーの仕様の下でBGPの安定性に対する分析作業【Griffin99]の成長体に基づいて、メインインターネットドメイン間ルーティングプロトコル、BGPバージョン4（ 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のデザイナーの一人で見直された、彼の見解だった「という一部の人は現実には、BGPの開発をBGPの発展を導くために、RFC 1126で概説した要件のセットを期待しながらBGPの発展の観点から、つまり、完全に独立してRFC 1126の起こった、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 meshierスタイルにかなりツリー状の接続グラフから移行
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.
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.
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.
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.
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.
現在の練習：BGPはピアリングセッションの認証およびセキュリティのための限られたメカニズムを提供しますが、これが交換された経路情報の信憑性や妥当性を保証するものではありません。
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.
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.
編集者注：証明書を使用してBGPルーティング情報を認証するための提案は2006年から2008年までセキュアドメイン間ルーティング（SIDR）ワーキンググループによって開発されました。
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）の交換によって消費されます。処理サイクル（「中央プロセッサ使用率」 - 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の収束時間が非常に長くすることができ、かつ設計が不十分なルーティングポリシーは、安定した結果、[RFC3345]に収束することはありません広告や引き出しの周期パターンに従事BGPスピーカの数になることがあります。長い収束時間の理由の一部は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内の政策に影響を与えるのは非常に小さい確率を持っています。さらに、唯一の静的なポリシーがサポートされています。静的ポリシーと偉大セレリティの揮発性のイベントに依存政策の間で、ルーティングが知っておくべきのイベントが存在する必要があります。最後に、ルートの特性以外の政策はサポートされていません（例えばAS-原点として、ASパス、宛先プレフィックス、マルチ終了弁別値（MED-値）、など）。
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.
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：Quality of Service - 例えば、統合サービスと差別化サービス（Diffservの））を導入する様々な試みも、この要件をサポートするための手段として見ることができますが、とは対照的に、代替ルートを提供するという点で限定された成功していません標準ルート上の改善サービスを提供します。
Editors' Note: From the standpoint of a later
time, it would probably be more appropriate to
say "total failure" rather than "limited
success".
3.1.2.1.6. "Provide paths which characterize user quality-of-service requirements"
3.1.2.1.6。 「利用者のサービス品質要件を特徴づけるのパスを提供します」
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でルートを作成するには、現在では一般に不可能です。
3.1.2.1.7. "Provide autonomy between inter- and intra-autonomous system route synthesis"
3.1.2.1.7。 「インターイントラ自律システムルート合成間の自律性を提供します」
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.
現在の実践：ドメイン間ルーティングは、独立してドメイン内ルーティングの行われます。ドメイン内ルーティングは、特に輸送ドメインで、しかしドメイン間ルーティングと非常に相互にあります。
3.1.2.2.1. "Decouple inter- and intra-autonomous system forwarding decisions"
3.1.2.2.1。 「インターイントラ自律システム転送決定をデカップル」
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で説明したように、トランジットのドメインのドメイン内の転送は、ドメイン間転送の判断に依存しています。
3.1.2.2.2. "Do not forward datagrams deemed administratively inappropriate"
3.1.2.2.2。 「前方管理上不適切と判断データグラムはいけません」
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.
関連性：有効な、そして正しくルーティング広告を通して表現が、ルートがアドバタイズされていないためにトラフィックを送信する不正なピアによってfloutedポリシーを適用する文脈においてますます重要。一方、おそらく過渡ルーティングの問題に誤ってルーティングされたパケットは、予想外の経路に沿っているが、宛先に到達するために転送されるべきです。
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
現在の練習：スタブドメイン（他のドメインの任意のトランジットサービスを提供するが、それは、1つまたは複数のトランジットドメインに直接接続していないつまり、ドメイン）で、パケットフィルタリングがあり、例えば、送信トラフィック上またはになりすまし送信元アドレスをキャッチします不要な着信トラフィックをフィルタリング。フィルタリングは、特に、それが所定のインターフェイス上でこのようなトラフィックのルートをアドバタイズしていなくてもドメインに送信されてきた（例えば、不正なトランジットトラフィックなど）トラフィックを拒否することができます。 「ミドルボックス」の成長しているクラス（midboxes、例えば、ネットワークアドレス
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.
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.
現在のプラクティス：ルーティングプロトコルは、ルータおよび接続リンクの障害を追跡するために、内部隣接管理サブプロトコル（例えば、「こんにちは」プロトコル）と機器と下位層リンクウォッチドッグからの情報の両方を使用します。失敗は、最終的に回避するために、ルーティングを再構成するルーティングプロトコル（可能な場合）失敗したリソースになり、これは一般的に（30秒以上）が非常に遅いです。一方で、データグラムはよく失敗したリソースに転送することができます。一般的な用語、エンドホストとこれらの通知に参加しないいくつかの非ルーターのミドルボックス、および、このようなボックスの故障ではルーティングシステムには影響しません。
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.
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.
現在のプラクティス：サポートされています。
3.1.2.4.2. "Accommodate a connection-less oriented user transport service"
3.1.2.4.2。 「コネクションレス指向のユーザーを収容する輸送サービス」
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 AS番号は、地域レジストリ[Huston05]によって割り当てられています。この成長が続く場合は、BGP-4のスペースAS元の16ビットは、5年未満で排出されます。スペースなどの拡張の計画は今急務です。
Editors' Note: At the time of publication, 32-
bit AS numbers have been introduced and are
being deployed.
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.
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.
現在の練習：リソースの限られたシステムは、典型的には非常に少ない情報を広告スタブドメインです。
3.1.2.5.3. "Minimize impact of dissimilarities between autonomous systems"
3.1.2.5.3。 「自律システム間の相違の影響を最小限に抑えます」
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.
現在：実践：ドメイン内の属性は、ドメイン間で広く類似しているため、ほとんどの場合、この機能は本当に今日のネットワークで必要とされていません。
3.1.2.5.4. "Accommodate the addressing schemes and protocol mechanisms of the autonomous systems"
3.1.2.5.4。 「自律システムのアドレッシングスキームおよびプロトコルメカニズムを収容します」
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.
関連性：重要な、おそらくより多くのようにRFC 1126は、もともとためのIPv6の潜在的な展開、MPLSのより広い使用法、およびVPNの増加使い方を開発したときよりも。
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.
現在の実践：唯一のグローバルアドレス指定方式は、ほとんどの自律システムでサポートされていますが、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で展開される必要がないことを言っていたし、参加者は必ずしもおそらくルーティングポリシーを、指定した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.
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は、固定ビットレート（CBR）に適用される場合がありますなどのATMでリアルタイムサービスを、リアルタイムの締め切り目標を達成するために持っていなかったことを確認するための場所に置かれました。
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.
関連性：オープン発行。動的な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.
ワールド・ワイド・ウェブの広範な成功の前に十年の間に、ISOは、通信アーキテクチャとプロトコルスイート開放型システム間相互接続（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と比較的小規模な第一段階NSFNETに主に使用されてまだありました。これは、効果的に単一の論理交換ポイントに接続された3つのレベルの階層における単純木構造ネットワーク（NSFNETバックボーン）を有する単一の管理ドメインでした。 1980年代の後半には、NSFNETは、今日のインターネットにつながる成長と変革に始めていました。これは、ルーティングプロトコルのバックボーンは、エクステリアゲートウェイプロトコル（EGP）[RFC0904]は、さえ限られた展開が計画されているに対処するつもりではなかったことが明らかになってきました。 EGPは、すべてのゲートウェイのアイデンティティを知るために必要な「すべての通知」プロトコルであり、これはもはや合理的ではなかったです。 NSFNETの複雑化や他のネットワークへのNSFNETネットワークのリンクと、管理者は、ネットワーク間のパケットの流れを管理することを可能にするポリシーベースのルーティングに対する要望がありました。 BGPを開発しながら、EGPバージョン3は暫定措置として作成されたつなぎ - ボーダーゲートウェイプロトコル（BGP-1）[RFC1105]の最初のバージョンは、ポリシー機能を備えたEGPの代替として開発されました。 BGPは、このような元NSFNETなどの階層構造のネットワーク、上で動作するように設計されましたが、また、我々は今、これらを呼び出します（階層内の同じレベルのAS間のリンクがあった場所に少なくとも部分的に非階層たネットワークで仕事ができますプロトコルは、リンクの異なる種類を区別したが）、「構成をピアリング」（リンク）のような上向き、下向き、または横向きに分類されます。自身が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の建築家は、大規模ネットワークのためのより多くの一般的なアーキテクチャを開発していました。これは、今日明らかに聞こえるが、20年前にそれほど明らかではなかった - 彼らは誰のノード、特にエンドシステム（ホスト）、または「どこでも」に「ここ」からのルートを覚えしようとするべきではない可能性があることを認識していました。すでによく公衆交換電話網に定着モデル - 彼らはまた、独立して管理ドメインを持つ階層的なネットワークを検討していました。これは、任意の相互接続グラフと機能ルーティングの階層構造を有する複数の独立した管理ドメインを持つネットワークのビジョンにつながりました。このアーキテクチャは、かなりよく[Tsuchiya87] 1987年に設立されました。アーキテクチャは、最初に、各層が著しく異なる特性を有している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. *イントラドメインは、ある単一の管理ドメイン内のエンドシステムとの間の「最良の」ルートが計算され、使用されている（ルータにルータ）*を、ルーティング。単一のアルゴリズムとルーティングプロトコルは、いずれかのドメイン全体で使用されるであろう。
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. *インタードメインは、ある管理ドメイン内ルーティングドメイン間ルートが計算される（ルータにルータ）*、（ルーティングは管理ドメインとルーティングドメインとの間に別々に考えられている）ルーティング。
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.
最後の二つの成分、ドメイン間と間の管理ルーティングは、それほど明確です。ルーティングのこれら二つの成分に関して標準化すべきか明らかではありません。たとえば、ドメイン間ルーティングのために、何がドメインから期待することができますか？外部の行動のいくつかの種類を提供するために、ドメインを尋ねることによって、我々は彼らの自律性を制限します。我々は彼らの外部の行動の何を期待していない場合は、ルーティング機能が最小限になります。
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
モデルのさらなる改良は、今後数年間にわたり発生し、より完全に形成されたビューは、[Huitema90] 1989年のHuitemaとDabbousで与えられます。この段階では、ディジタル・イクイップメント・コーポレーション（DEC）によって発信元の作業はIS-ISリンクステートプロトコルは、かなり高度だったとドラフトになりつつに近かったです
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.
国際標準。 IS-ISはもちろん、ドメイン内ルーティングの主要なコンポーネント今日で、OSPF（Open Shortest Path First）の家族の発展に影響を与えました。しかし、の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が世界的に許容可能なルーティングメトリックを確立することができなかった主な理由の一つと見られていた。もう一度、この時間にこの距離から明確に無益な目的のようです！したがって、EGPを効果的に自律システムとゲートウェイを連結基本的なパスベクトルプロトコルとなりました。ルーティングループを避けるために、ツリー構造のネットワークに完全に依存した、とEGPのすべて-知らさ性質は、その更新パケットが非常に大きくなったもので。 BGPバージョン1 [RFC1105]は1989年に標準化されたが、それはこの前にいくつかの時間のために開発していたし、すでに標準化前の生産ネットワークでアクションを見ていました。 BGPは、第一の実パスベクトルルーティングプロトコルであり、スケーリングの問題の一部を軽減するだけでなく、ポリシーベースのルーティングを提供することを意図しました。ルートは、関連するコストメトリックなしのASの「ベクター」に沿ってパスとして説明しました。経路を説明する。この方法は、明示的ルーティングループの検出を可能にするように意図されていました。これは、ドメイン内ルーティングシステムはループフリー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は、インターネットは、研究トラフィックの生産ネットワークとして使用されることを想定しました。私たちは月のこれらのネットワークを停止し、すべての新しいルーティングプロトコルをインストールすることはできません。インターネットはまだそのユーザーにサービスを提供し続けながら、ネットワークプロトコルへの変更を進化する必要があります。計画が作られていますどのようにこの現実の色は、ルーティングプロトコル変更します。
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の両方によって採用されたソリューションは、明示的なポリシー条件付き距離ベクトルホップバイホップルーティングの形でした。この選択のための推理はブレスラウとEstrinの1990紙[Breslau90]（暗黙のうちに見つけることができます - いくつかの他の選択肢は後知恵で、上のBGPよりもさらに大きな問題を抱えているだろう、政策提案、とのリンク状態など与えられているので、地球規模のネットワーク）。伝統的な距離ベクトルプロトコルは、宛先とメトリックの形式でルーティング情報を交換しました。新しいプロトコルは、明示的ルーティングアップデートに記載の経路を使用することが許可されたソースのASのリスト、及び/又は広告経路に沿って横断すべてのASのリストのいずれかを含むことによって、ルートにポリシー表現に関連します。
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はライマンチャピンとチャールズKunzinger率いるANSI XS3.3ワーキンググループの庇護の下で開発されました。 2つのプロトコルは、基本的な設計が非常に類似していたが、IDRPはBGPのそれ以降のバージョンに組み込まれているそのうちのいくつかは、いくつかの余分な機能を持っています。他の人はまだそうであってもよく、まだ他の人が不適切と見られるかもしれません。次のようにブレスラウとEstrinは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（現在のASと呼ばれるものの本質的に同等の管理ドメイン）を含むことによって、距離ベクトルルーティングに固有のループと収束問題を解決しようとします。各ルーティング更新は、指定された宛先に到達するために横断しなければならないの広告セットを含みます。このように、ADループが含まれているルートを回避することができます。
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各宛先への単一の経路を可能にします。ルートに関連付けられたポリシー属性をきめ、より細かいようになると、アドバタイズされたルートは少ないソースに適用されます。これは、ソースがそれらに利用可能な許容されるルートを持っている確率を高めるために、各宛先に対してアドバタイズされる複数の経路の必要性を暗示します。これは、効果的にパケットに表示される場合があります各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は、AS間の相互接続の今日の密なウェブにも対応できるようにする相互接続の全体的な構造についての仮定を行いません。 BGPバージョン4は、アドレス指定の階級のためにクラスフルからの変更を処理するために開発されました。この時間のほとんどは、IDRPが並列に開発された、両方のプロトコルはメリットgatedaemonルーティングプロトコルスイートで実施されました。この時間の間に、より洗練されたIDRPは、IPの代わりに、OSIコネクションレスプロトコルコネクションレスネットワークプロトコル（CLNP）上で実行するように適合させることができるまで、その場しのぎの対策としてBGPを見たIETF内での移動を使用することがありました。しかし、そのドメイン内の対応とは異なり、時間の試練に耐え、そして実際にOSPFよりも柔軟であることが証明された、-ISは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].
今、インターネット[Chapin94]で読み取り可能である、：IDRPの機能のより完全なアカウントは、デビッドPiscitelloとライマンチャピンの著書「TCP / IPと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.
彼の初期の文書でクリスマスChiappaによって表現ニムロッドとして、「新しいIPルーティングおよびアドレッシングアーキテクチャ」[Chiappa91]以降NIMRODワーキンググループ文書で[RFC1753]と[RFC1992]はいずれかによって考慮される必要がある要件の数を設立しました新しいルーティングアーキテクチャ。ニムロデの要件は、出発点として1126 RFCを取り、さらに行きました。
The three goals of Nimrod, quoted from [RFC1992], were as follows:
次のように[RFC1992]からの引用ニムロデの三つの目標は、ありました：
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.サービスプロバイダおよびユーザによって課される複数の制約の存在下で、サービス固有のルーティングを提供します。
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、インターネットにおける特定のサービスに対する需要は、ニムロッドアーキテクチャが発表された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.
ある時点で、ニムロデは、そのアドレッシングおよびルーティングアーキテクチャと、IPngのための候補と見られていました。歴史はIPngのの要件のための入力があったが、それは、それは[RFC1752]「研究努力のあまり」だったことを理由に、1994年にIESGによる選択プロセスから除外された、のIPngとして受け入れられなかったことを示しています明示的にChiappa [RFC1753]から募集。代わりに、IPv6はIPngのよう掲げてきました。ニムロッド対のIPv6の優劣の議論に入ることなく、多くの問題を解決することがありながら、IPv6は、今日のインターネット上で重要なルーティングの問題を解決していないことは明らかです。実際には、ある意味では、それは2つのインターネットプロトコルとそれぞれのアドレス指定の方法をサポートするための要件を追加することによって、それらを悪化させます。いろいろな意味で、今日のインターネットでのメソッドのミックスにIPv6の追加はニムロッドチームによって記載された目標は、必要に応じて目標を残っているという事実を指します。
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:
ニムロッドとそのアーキテクチャの研究は、将来のドメインベースのルーティングアーキテクチャを導出することが重要であるここで別の意味があります。ニムロデは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.
MPLSおよびPNNIはニムロッドからアイデアを借りながら、それらのいずれも、このアーキテクチャの実装であると言うことができることに、注意することが重要です。
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?
PNNIは、ドメイン間ルーティング情報交換のための抽象マップ交換（又はリンクステート機構ベクトルの距離ではなく）使用するルーティングプロトコルの最初の展開例です。このことの1つの結果は、ドメインは、すべてのマップを作成するために同じメカニズムを使用する必要はないということです。この抽象化とソースベースのルート計算メカニズムの結果はどうでしたか？
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ネットワークを実行している経験を持っていないので、上記のコメントは、理論的な視点からです。運用経験に基づいて、これらの問題についてさらなる研究が必要とされます。
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]でジェフ・ヒューストンからの委託作業は、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プロバイダのAS間の接続は、より一般的に数年前に一般的であると仮定されたツリー構造より密なメッシュ状になってきています。これは、グローバルサービスプロバイダーによってピアリングとトランジットトラフィックのための充電量を増加させて駆動されています。ローカル直接ピアリングやインターネットの交流は、ローカルファイバ接続のコストが低下すると、着実に、より一般的になってきています。
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エンドユーザーのサイトがますます弾力性を改善する方法として、二つ以上のサービスプロバイダへのマルチホーミングに頼るされています。数字はマルチホームとなり、BGPでアドバタイズされるプレフィクス数の増加に対応するため、エンドユーザーのサイトがパブリック必要としてこれはノックオン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すべてのこれらの要因は、迅速BGPにおけるクラスレスドメイン間ルーティング（CIDR）を導入することにより得られたBGPルーティングテーブルの拡張とその結果としての接頭凝集を制限する利点を否定しています。 IPv6は、デフォルトフリーゾーンはおそらく万プレフィックスに限定されるであろうに世界観を実現することは、今も不可能です。
o The typical "width" of the Internet in AS hops is now around five, and much less in many cases.
O ASホップにおけるインターネットの典型的な「幅」とは現在約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年の前半に始まり、メインプロジェクトは、[NewArch03] 2003年に終わりました。
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 NewArch作業（デイブ・クラーク）の参加者の一つでもNewArchで特定し、新たな要件の一部の影響を分析することは非常に興味深い論文を発表したエンド・ツー・エンド原理その上で（4.2節を参照してください） [Clark00]これまでに、インターネットの発展を導いてきました。彼らの主な結論は、エンドツーエンドの端部でのユーザー間の信頼の喪失は、インターネット上で最も基本的な効果を有することです。これは、オペレータが商業的な理由のために彼らのネットワークの内部の仕組みを明らかにするために不本意であるルーティングシステムの文脈で明らかです。同様に、第三者を信頼し、彼らのアバター（一種又は他の主midboxes）は、エンド・ツー・エンドの原則およびそれらと一緒に行ったルーティングメカニズムに大きな影響を与えます。全体的に、エンド・ツー・エンドの原則は、これまで可能であると擁護しなければならない - いくつかの変更は、すでにあまりにも深く背完全な信頼性とオープン性に行くことを可能にするために組み込まれている - 少なくとも部分的にオフstavingの手段として、ネットワークは不変の形と機能（電話網など多くが行っている）に骨化します一日。希望は、その時点で、新しいインターネットは自由な技術革新のためのコンテキストを提供するために表示されるということです。
5. Existing Problems of BGP and the Current Inter-/Intra-Domain Architecture
5.既存のBGPの問題点と現在のインター/イントラドメインアーキテクチャ
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
今日BGPで動作するように持っている人のほとんどが、それは便利、作業プロトコルであると信じるが、議論はBGPまたは使用中のBGPおよびドメイン内ルーティングプロトコル間の関係今日は可能性領域の数を光に持ってきました改善されました。 BGP-4はされて、それが元々[RFC1771]に導入し、展開などのプロトコルは、[RFC4271]に記載されているので、拡張され続けています。このセクションでは、かなりの程度まで、願いです
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での問題のリスト。今日のドメイン間ルーティングシステムの欠点も広く、特にその安定性に関して、インターネットの大きさに爆発によって生成さの問題で、「インターネットにおけるドメイン間ルーティングのための建築要件」[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以上のプレフィックス長）非常に小さい：この粒度は、副生成物のマルチホーミングの増加レベルに関連精密トラフィックエンジニアリングを実行しようとする試みのように見えます。現時点では、彼らが集約することができることを自動的に推定することが可能であっても、ASは、その存在の事前の知識がなくても、このようなプレフィックスを集約できるようになるBGPでのメカニズムはありません。満足自動集約を達成することも大幅周辺のASでの不安定性に関連した非局所性の問題を低減するであろう。
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?
証拠（[RFC3221]とサブグループBのメンバー[Jiang02]の一部による測定）、今日のネットワークでルートフラップが不釣り合いでトラフィックエンジニアリングに関連したきめ細かなプレフィックス（長さ22以上）に関連付けられていることがありますネットワークの周辺。自己凝集は、前述したように、そのような不安定性をマスクし、それがネットワーク全体に伝播されるのを防ぐ傾向があります。研究する必要がありますもう一つの問題は、グローバルな収束を必要とするアーキテクチャが引き続き必要です。我々の研究（未発表）の一部は、少なくともいくつかの地域では、ネットワークが実際に安定性に到達したことがない、ことを示しています。すなわち、それは決して本当に世界的に収束します。グローバル、以降、ネットワークは、世界的なコンバージェンスの要件で設計することができますか？
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.
全体のインターネットを介して伝播し、インターネットのトラフィックのほとんどのmisroutingその結果として単一の周辺でBGP設定に間違いが十分に文書化されているそのうちのいくつかのインスタンスの数、ありました。
Similarly, a single route flap in a single peripheral AS can require route table recalculation across the entire Internet.
同様に、単一の末梢ASで単一ルートフラップは、全インターネット上のルートテーブルの再計算を必要とすることができます。
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に実装され、プロバイダのアドレス割り当てと組み合わせた場合に有効なマルチホーミングの障害です。 ASは、上流プロバイダから、そのアドレスが割り当てられている場合には、上流プロバイダは、他の顧客のものとそれらのアドレスを集約し、お客様のみの範囲のための単一のプレフィックスを通知することができます必要があります。顧客としては、また別のプロバイダに接続している場合、彼らは彼の割り当てから取られていないので、AS顧客へのより特定のルートを発表する必要がありますので、しかし、第二プロバイダは、顧客の住所を集約することができません。最長一致ルールは、必要ありませんように、第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.
この問題は、彼らがさらにデフォルト・フリーゾーンのルートテーブルサイズの爆発を悪化させ、上流プロバイダから割り当てられている可能性もかかわらず、自分のアドレス割り当てを申請する多くのお尻を誘導しました。また、この問題は20または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.
ヒューストン[Huston05]で再びいくつかの最近の研究によると、増加率は、事業の低迷の後に脱落したが、2005年7月のように、数字（64510のうち39000）ASも半分以上利用可能ではIANAによって割り当てられ、周りの20000されていましたグローバルBGPルーティングテーブルに見えました。一年後、これらの数字は、それぞれ、42000（2006年4月）および23000（2006年8月）に成長していた、と配分の割合は、現在、年間約3500です。枯渇が発生する時期を予測するために使用さ曲線フィッティングモデルに応じて、プールは、2010年と2013年の間のどこかに尽きます、ビジネスでのISPの数の増加を超えて増加のこのレートでは、職場で、他の要因があるように見えますこれらの数値の間の相関の公正度がありますが。数字は、現在大規模なルーティングドメインを同定することを超えて多くの目的のために使用されるようなマルチホームサイトは、それらの様々なプロバイダにルーティング選好を表現するためにAS番号を取得し、番号がMPLS / BGPのためのアドレッシング機構の一部を使用されるようベースの仮想プライベートネットワーク（VPN）[RFC4364]。 IETFは、32ビット[RFC4893]にAS番号の利用可能範囲を拡大するために4年以上にわたって開発中の提案がありました。開発の遅さの多くは、移行時の配備挑戦によるものです。そのための移行の困難のため、展開はそれが必要とされる時に、ネットワーク全体としては、新機能の準備ができているように、実際の枯渇の前にも開始する必要があります。これは、長いAS番号を扱うことができるアップグレードの展開は、変更がロールアウトされたことの合理的な期待を与えるために、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.
編集者注：地域インターネットレジストリ（RIRは）2009年1月1日に、デフォルトでAS番号長いの割り当てに移動することを計画しているが、ルータのかなりの数は、それまでにアップグレードされていないだろうという懸念があります。
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.
不連続のASとのトリックは、エニーキャストを実装するために、例えば、オペレータによって使用されています。各接続を介してインターネットにアクセスすることができ、マルチホームドメインは、ドメインの障害と一部の結果としてパーティション分割された場合、不連続のASはまた、偶然にされて入って来るかもしれません。現在であるよりも、より透明性の高いこのような状況のための支援を行うことが望ましいことがあります。
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におけるメッセージ「ハロー」間の間隔と同様に、各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]で指定されています。
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.
BGPおよびドメイン内のプロトコルで使用されるメトリックoをまれに匹敵または組み合わせ可能です。ドメイン内の最適化は、エンドツーエンドのパスのものと異なっていてもよい引数が存在する一方で、そのような計算又は組合せメトリックは助けになるであろう「トポロジー的に最も近い」サーバを計算するような機会があります。
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.
BGPルートのセットのための次のホップ先が原因ドメイン内プロトコルの問題のアクセス不能になった場合はO、消え次のホップを使用してルートは、次の利用可能な更新で無効化されなければなりません。ネクストホップルートが再表示された場合、その後、これは通常、その隣（S）からの完全なテーブルを要求する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).
BGPに同期することは、かなりの時間を取ることができ、ドメイン間のプロトコル、同じネットワークについて知っているドメイン内のプロトコルを待っていることとにドメイン内のプロトコルのコンバージェンス時間を追加することによって、BGPの収束を遅くO各サイクル。一般的には、事業者は、もはや（一般的には、ローカルドメイン内のプロトコルに全体の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
グリフィン[Griffin99]にし、マクファーソン[RFC3345]で説明したように、O、トポロジーの特定の種類に収束に失敗するBGPの原因となりますよう、尻のポリシーを作成し、ルータでそれらをインスタンス化することが可能です
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は、分散型サービス拒否（DDoS攻撃）攻撃に対して脆弱です。また、ルータは、他のシステム上の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およびVPNのシグナリングプロトコル[RFC4364]として機能するように改変されています。他の人が問題としてそれを見ながら、一部の人々が恩恵としてBGPプロトコルのこのオーバーロードを参照してください。それが彼らの製品に追加機能を提供するベンダーのための車両として確かに便利でしたが、それはBGPの性能と複雑さの問題のいくつかを悪化させています。二つの重要な問題は、ことを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のための1つを、維持する必要があるという事実は、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.
選択するとき、それをドメイン間でIPv4とIPv6の両方の経路についての情報を交換するために[RFC4760]マルチプロトコル拡張子を持つBGPスピーカの単一のセットを使用することが可能であるが、非対称の情報交換の結果のためのトランスポートプロトコルとしてTCPを使用しますIPv6の上でIPv4またはTCP上で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.
明示的に対応する次ホップの情報にアドレスファミリの到達可能性情報をリンクすることができないため、また、現在の実装では、経路が同じUPDATEメッセージ中でIPv4とIPv6の両方のためにアドバタイズすることができません。これは改善したが、現在は独立した更新が各アドレスファミリのために交換され、その結果できました。
5.14. Existing Tools to Support Effective Deployment of Inter-Domain Routing
5.14. ドメイン間ルーティングの効果的な展開をサポートする既存のツール
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を参照）。 BGPコマンドと提案された政策は、隣接するドメイン内のポリシー（常にこれらは明らかにされていることを提供し、正確に文書化）と一致していることを、事後、チェックするためにRPSLを変換するために限られたツールがあります。
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の使用を支援するために利用可能なツールをまとめたもの。彼らは現実のネットワークからオフラインで使用されるすべてのバッチモードツールであることに注意してください。これらのツールは、熟練したドメイン間ルーティングconfigurersなく、初心者のための限られた援助のための小切手を提供します。
5.14.1. Routing Policy Specification Language RPSL ( and 2650) and RIPE NCC Database (RIPE 157)
5.14.1. ルーティングポリシー仕様言語RPSL（および2650）とRIPE NCCデータベース（RIPE 157）
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.
ローカルASに接続されているルーティングポリシー仕様言語（RPSL）[RFC2622]の経路、ルータ、および自律システムを説明するために、ネットワークオペレータを可能にする（のAS）。
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):
ツールは、[IRRToolSet]（とりわけ）にデータベースを使用することができる存在します。
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フラグ。
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つのネットワーク間のすべてのAS-パスを抽出し、与えられたネットワークは、現在のポリシーに応じた接続を表示します。
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.
編集者注： 『インターネットルーティングレジストリツールセットは、』当初、 『ルーティングアービタツールセット』（RAToolSet）プロジェクトとして1997年から2001年の間に南カリフォルニアの情報科学研究所（ISI）の大学によって開発されました。ツールセットは、もはや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.
このドキュメントに著しく貢献した個々のメンバーは以下のとおりです。アンダースバーグステン、ハワード・バーコウィッツ、マリンCarlzon、レンカ・カーMotyckova、エルウィン・デイヴィス、Avriドリア、ピエールFransson、龍江、ドミトリKrioukov、トーベ・マドセン、オルレペールス、および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.
おかげでも、この物質の実質的なレビューをしたバビロンのメンバーや他の人に行きます。具体的には、以下の個人の有益なコメントや提案承認したいと思います：ロア・アンダーソン、トーマスアールストロム、エリック・アマン、トーマス・エリクソン、ニクラス・ボルグ、ナイジェル・ブラッグ、トーマスChmara、クリスターEdlund、Graffordを借りて、スーザンノウサギ、Torbjornランドバーグが、デビッドマグリュー、Jasminko Mulahusic、フロリアン・ダニエルオテル、ベルンハルト・ストックマン、トムWorster、そしてロベルトZamparo。
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のドキュメント羊飼いとして、Lixiaチャンに感謝します。
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.
"ミリ秒IGPコンバージェンスに向けて" [Alaettinoglu00] Alaettinoglu、C.、ヤコブソン、V.、およびH.ユー、進歩、2000年11月に作業。
[Berkowitz01] Berkowitz, H. and D. Krioukov, "To Be Multihomed: Requirements and Definitions", Work in Progress, July 2001.
、進捗状況、2001年7月の作業：[Berkowitz01]バーコウィッツ、H.およびD. Krioukovは、 "要件定義およびマルチホームであることを"。
[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]ブレスラウ、L.とD. Estrin、「OSIにおけるネットワーク層ルーティングのアーキテクチャ」、コミュニケーションのアーキテクチャ＆プロトコル上のACMのシンポジウムの議事録、1990年。
[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.チャピン、 "オープンシステムネットワーク：TCP / IP＆OSI"、著者に割り当てられたアディソン・ウェズリー著作権、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ルーティングおよびアドレス指定アーキテクチャ"、進歩、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]クラーク、D.とM.ブルーメンソール、「インターネットのデザイン再考：勇敢な新しい世界対引数を端から端まで」、2000年8月、<http://dspace.mit.edu/handle/1721.1 / 1519>。
[Griffin99] Griffin, T. and G. Wilfong, "An Analysis of BGP Convergence Properties", Association for Computing Machinery Proceedings of SIGCOMM '99, 1999.
[Griffin99]グリフィン、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トルコ、1990年の議事。
[Huston05] Huston, G., "Exploring Autonomous System Numbers", The ISP Column , August 2005, <http://www.potaroo.net/ispcol/2005-08/as.html>.
[Huston05]ヒューストン、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]ミルズ、D.、エド。そして、M.デイヴィス、エド、「インターネットアーキテクチャワークショップ：インターネットシステムアーキテクチャおよびTCP / IPプロトコルの未来 - 報告書」。、インターネットアーキテクチャタスクフォースINARC、1990年、<http://www.eecis.udel.edu/~工場/データベース/論文/ 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ツールセットのウェブサイト、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は、国際標準10747、1993の「中間システムの中でドメイン間のRouteing情報交換のためのプロトコルは、ISO 8473台のPDUの転送をサポートします」。
[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]江、Y.、ドリア、A.、オルソン、D.、およびF. Petterssonの、 "ドメイン間ルーティング安定性の測定"、2002、<http://psg.com/~avri/papers/paper-容hpsr2002-final.pdf>。
[Katz10] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, January 2010.
[Katz10]カッツ、D.とD.ウォード、 "双方向フォワーディング検出"、進歩、2010年1月の作業。
[Labovitz02] Labovitz, C., Ahuja, A., Farnam, J., and A. Bose, "Experimental Measurement of Delayed Convergence", NANOG , 2002.
【Labovitz02] Labovitz、C.、アフジャ、A.、ファーナム、J.、およびA.ボーズ、 "遅延コンバージェンスの実験的測定"、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]クラーク、D.、Sollins、K.、Wroclawski、J.、Katabi、D.、クーリック、J.、ヤン、X.、ブレーデン、R.、ファーバー、T.、フォーク、A.、Pingali、 V.、ハンドリー、M.、およびN. Chiappa、 "新アーチ：次世代インターネットアーキテクチャ"、2003年12月、<http://www.isi.edu/newarch/iDOCS/final.finalreport.pdf>。
[RFC0904] Mills, D., "Exterior Gateway Protocol formal specification", RFC 904, April 1984.
[RFC0904]ミルズ、D.、 "エクステリアゲートウェイプロトコル形式仕様"、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]ロッキード、K.およびJ. Rekhter、 "ボーダーゲートウェイプロトコル（BGP）"、RFC 1105、1989年6月。
[RFC1126] Little, M., "Goals and functional requirements for inter-autonomous system routing", RFC 1126, October 1989.
[RFC1126]リトル、M.、「目標と相互自律システムルーティングのための機能要件」、RFC 1126、1989年10月。
[RFC1163] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol (BGP)", RFC 1163, June 1990.
[RFC1163]ロッキード、K.、およびY. Rekhter、 "ボーダーゲートウェイプロトコル（BGP）"、RFC 1163、1990年6月。
[RFC1267] Lougheed, K. and Y. Rekhter, "Border Gateway Protocol 3 (BGP-3)", RFC 1267, October 1991.
[RFC1267]ロッキード、K.、およびY. Rekhter、 "ボーダーゲートウェイプロトコル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]ブラドナー、S.およびA.マンキン、 "IP次世代プロトコルのための勧告"、RFC 1752、1995年1月。
[RFC1753] Chiappa, J., "IPng Technical Requirements Of the Nimrod Routing and Addressing Architecture", RFC 1753, December 1994.
[RFC1753] Chiappa、J.、RFC 1753、1994年12月 "ニムロッドルーティングとアドレッシングアーキテクチャのIPngの技術的要件"。
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル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、 "ニムロッドルーティングアーキテクチャ"、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.、ファリナッチ、D.、Helmy、A.、ターラー、D.、デアリング、S.、ハンドレー、M.、およびV. Jacobsonの、「プロトコル独立マルチキャスト - スパースモード（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.、マイヤー、D.、ベイツ、T.、Karrenberg、D.、およびM.テルプストラ、「ルーティングポリシー仕様言語（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]マイヤー、D.、シュミッツ、J.、オレンジ、C.、前、M.、およびC. Alaettinoglu、 "実践において使用RPSL"、RFC 2650、1999年8月。
[RFC2791] Yu, J., "Scalable Routing Design Principles", RFC 2791, July 2000.
[RFC2791]ゆう、J.、 "スケーラブルなルーティング設計原理"、RFC 2791、2000年7月。
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[RFC3221]ヒューストン、G.、 "インターネットにおけるドメイン間ルーティングの解説"、RFC 3221、2001年12月。
[RFC3277] McPherson, D., "Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance", RFC 3277, April 2002.
[RFC3277]マクファーソン、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]マクファーソン、D.、ギル、V.、ウォルトン、D.、およびA. Retana、 "ボーダーゲートウェイプロトコル（BGP）永続的なルート発振条件"、RFC 3345、2002年8月。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618]フェナー、B.とD.マイヤー、 "は、Multicast Source Discovery Protocol（MSDP）"、RFC 3618、2003年10月。
[RFC3765] Huston, G., "NOPEER Community for Border Gateway Protocol (BGP) Route Scope Control", RFC 3765, April 2004.
[RFC3765]ヒューストン、G.、 "NOPEERコミュニティボーダーのためのゲートウェイプロトコル（BGP）ルートスコープコントロール"、RFC 3765、2004年4月。
[RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): Protocol Specification", RFC 3913, September 2004.
[RFC3913]ターラー、D.、 "ボーダーゲートウェイマルチキャストプロトコル（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] Abley、J.、Lindqvist、K.、デイビス、E.、ブラック、B.、およびV.ギル、 "IPv4のマルチホーミングプラクティスと制限"、RFC 4116、2005年7月。
[RFC4204] Lang, J., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204]ラング、J.、 "リンク管理プロトコル（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.、李、T.、およびS.野兎、 "ボーダーゲートウェイプロトコル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]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、RFC 4364、2006年2月。
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[RFC4593] Barbir、A.、マーフィー、S.、およびY.ヤン、 "ルーティングプロトコルへの一般的な脅威"、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]フェナー、B.、ハンドリー、M.、ホルブルック、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]サングリ、S.、チェン、E.、フェルナンド、R.、スカダー、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]ベイツ、T.、チャンドラ、R.、カッツ、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.チェン、 "ナンバースペースAS 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]ドリア、A.、デイヴィス、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.、スクワイア、M.、カイン、B.、ダンカン、I.、およびB.ハーバーマン、 "高速ライブネス・プロトコル（FLIP）"、進歩、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]土屋、P.、「OSIにおけるネットワーク層ルーティングのアーキテクチャ」、コンピュータ通信技術、1987年にフロンティアACMワークショップの議事録。
[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]徐、Z.、大、S.、およびJ.ガルシア - ルナ - ACEVES、 "より効率的な距離ベクトルルーティングアルゴリズム"、PROC IEEE MILCOM 97、モントレー、カリフォルニア州、1997年11月、<のhttp：// WWW .cse.ucsc.edu /研究/ ccrg /出版/ zhengyu.milcom97.pdf>。
Authors' Addresses
著者のアドレス
Elwyn B. Davies Folly Consulting Soham, Cambs UK
エルウィンB.デイヴィスフォリーコンサルティングソーハム、Cambsの英国
Phone: +44 7889 488 335 EMail: elwynd@dial.pipex.com
電話：+44 7889 488 335 Eメール：elwynd@dial.pipex.com
Avri Doria LTU Lulea, 971 87 Sweden
AvriドリアLTUルーレオ、971 87スウェーデン
Phone: +1 401 663 5024 EMail: avri@acm.org
電話：+1 401 663 5024 Eメール：avri@acm.org