[要約] 要約：RFC 5772は、将来のルーティングアーキテクチャに関する要件の一連の可能性を提供しています。 目的：このRFCの目的は、将来のルーティングアーキテクチャの設計において考慮すべき要件を明確にすることです。
Internet Research Task Force (IRTF) A. Doria
Request for Comments: 5772 LTU
Category: Historic E. Davies
ISSN: 2070-1721 Folly Consulting
F. Kastenholz
BBN Technologies
February 2010
A Set of Possible Requirements for a Future Routing Architecture
将来のルーティングアーキテクチャのための一連の要件
Abstract
概要
The requirements for routing architectures described in this document were produced by two sub-groups under the IRTF Routing Research Group (RRG) in 2001, with some editorial updates up to 2006. The two sub-groups worked independently, and the resulting requirements represent two separate views of the problem and of what is required to fix the problem. This document may usefully serve as part of the recommended reading for anyone who works on routing architecture designs for the Internet in the future.
このドキュメントで説明されているルーティングアーキテクチャの要件は、2001年にIRTFルーティングリサーチグループ（RRG）に基づいて2つのサブグループによって作成され、2006年までの編集上の更新がいくつかあります。問題と問題を修正するために必要なものの個別の見解。このドキュメントは、将来的にインターネットのルーティングアーキテクチャデザインに取り組んでいる人のために、推奨読書の一部として有用に機能する場合があります。
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.
このドキュメントは、IRTF RRGのサポートを当時完了した作業の記録として公開されていますが、出版日における研究グループの最新の技術的理解または技術的コンセンサスを必ずしも表しているわけではないという理解があります。。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for the historical record.
このドキュメントは、インターネット標準の追跡仕様ではありません。歴史的記録のために公開されています。
This document defines a Historic Document for the Internet community. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the individual opinion(s) of one or more members of the Routing Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティ向けの歴史的なドキュメントを定義しています。このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）のルーティング研究グループの1人以上のメンバーの個々の意見を表しています。IRSGによって公開されたことが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5772.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5772で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Background ......................................................4
2. Results from Group A ............................................5
2.1. Group A - Requirements for a Next Generation Routing and
Addressing Architecture ....................................5
2.1.1. Architecture ........................................6
2.1.2. Separable Components ................................6
2.1.3. Scalable ............................................7
2.1.4. Lots of Interconnectivity ..........................10
2.1.5. Random Structure ...................................10
2.1.6. Multi-Homing .......................................11
2.1.7. Multi-Path .........................................11
2.1.8. Convergence ........................................12
2.1.9. Routing System Security ............................14
2.1.10. End Host Security .................................16
2.1.11. Rich Policy .......................................16
2.1.12. Incremental Deployment ............................19
2.1.13. Mobility ..........................................19
2.1.14. Address Portability ...............................20
2.1.15. Multi-Protocol ....................................20
2.1.16. Abstraction .......................................20
2.1.17. Simplicity ........................................21
2.1.18. Robustness ........................................21
2.1.19. Media Independence ................................22
2.1.20. Stand-Alone .......................................22
2.1.21. Safety of Configuration ...........................23
2.1.22. Renumbering .......................................23
2.1.23. Multi-Prefix ......................................23
2.1.24. Cooperative Anarchy ...............................23
2.1.25. Network-Layer Protocols and Forwarding Model ......23
2.1.26. Routing Algorithm .................................23
2.1.27. Positive Benefit ..................................24
2.1.28. Administrative Entities and the IGP/EGP Split .....24
2.2. Non-Requirements ..........................................25
2.2.1. Forwarding Table Optimization ......................25
2.2.2. Traffic Engineering ................................25
2.2.3. Multicast ..........................................25
2.2.4. Quality of Service (QoS) ...........................26
2.2.5. IP Prefix Aggregation ..............................26
2.2.6. Perfect Safety .....................................26
2.2.7. Dynamic Load Balancing .............................27
2.2.8. Renumbering of Hosts and Routers ...................27
2.2.9. Host Mobility ......................................27
2.2.10. Backward Compatibility ............................27
3. Requirements from Group B ......................................27
3.1. Group B - Future Domain Routing Requirements ..............28
3.2. Underlying Principles .....................................28
3.2.1. Inter-Domain and Intra-Domain ......................29
3.2.2. Influences on a Changing Network ...................29
3.2.3. High-Level Goals ...................................31
3.3. High-Level User Requirements ..............................35
3.3.1. Organizational Users ...............................35
3.3.2. Individual Users ...................................37
3.4. Mandated Constraints ......................................38
3.4.1. The Federated Environment ..........................39
3.4.2. Working with Different Sorts of Networks ...........39
3.4.3. Delivering Resilient Service .......................39
3.4.4. When Will the New Solution Be Required? ............40
3.5. Assumptions ...............................................40
3.6. Functional Requirements ...................................42
3.6.1. Topology ...........................................43
3.6.2. Distribution .......................................44
3.6.3. Addressing .........................................48
3.6.4. Statistics Support .................................50
3.6.5. Management Requirements ............................50
3.6.6. Provability ........................................51
3.6.7. Traffic Engineering ................................52
3.6.8. Support for Middleboxes ............................54
3.7. Performance Requirements ..................................54
3.8. Backward Compatibility (Cutover) and Maintainability ......55
3.9. Security Requirements .....................................56
3.10. Debatable Issues .........................................57
3.10.1. Network Modeling ..................................58
3.10.2. System Modeling ...................................58
3.10.3. One, Two, or Many Protocols .......................59
3.10.4. Class of Protocol .................................59
3.10.5. Map Abstraction ...................................59
3.10.6. Clear Identification for All Entities .............60
3.10.7. Robustness and Redundancy .........................60
3.10.8. Hierarchy .........................................60
3.10.9. Control Theory ....................................61
3.10.10. Byzantium ........................................61
3.10.11. VPN Support ......................................61
3.10.12. End-to-End Reliability ...........................62
3.10.13. End-to-End Transparency ..........................62
4. Security Considerations ........................................62
5. IANA Considerations ............................................63
6. Acknowledgments ................................................63
7. Informative References .........................................65
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.
2001年、IRTFルーティングリサーチグループ（IRTF RRG）の椅子であるAbha AhujaとSean Doranは、ドメイン間ルーティング（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 remit required an evolutionary approach starting from current routing architecture and practice. In other words, the group limited itself to developing an evolutionary strategy. The Babylon group was later folded into the IRTF RRG as Sub-Group B to distinguish it from the original RRG Sub-Group A.
同時に、スウェーデンでも同様の目標で独立した努力が開始されました。ベンダー、サービスプロバイダー、および学界からの参加と呼ばれるチームは、ドメイン間のルーティングの歴史を理解し、サービスプロバイダーが見た問題を調査し、フォローオンの要件の提案を作成するために組み立てられました。現在のルーティングアーキテクチャに。このグループの送金には、現在のルーティングアーキテクチャと実践から始まる進化的アプローチが必要でした。言い換えれば、グループは進化戦略の開発に限定されています。バビロングループは、後にサブグループとしてIRTF RRGに折りたたまれ、元のRRGサブグループAと区別されます。
One of the questions that arose while the groups were working in isolation was whether there would be many similarities between their sets of requirements. That is, would the requirements that grew from a blank sheet of paper resemble those that started with the evolutionary approach? As can be seen from reading the two sets of requirements, there were many areas of fundamental agreement but some areas of disagreement.
グループが単独で働いている間に発生した質問の1つは、彼らの一連の要件の間に多くの類似点があるかどうかでした。つまり、空白の紙から成長した要件は、進化的アプローチから始まったものに似ているでしょうか？2つの要件セットを読むことでわかるように、基本的な合意の多くの領域がありましたが、不一致のいくつかの分野がありました。
There were suggestions within the RRG that the two teams should work together to create a single set of requirements. Since these requirements are only guidelines to future work, however, some felt that doing so would risk losing content without gaining any particular advantage. It is not as if any group, for example, the IRTF RRG or the IETF Routing Area, was expected to use these requirements as written and to create an architecture that met these requirements. Rather, the requirements were in practice strong recommendations for a way to proceed in creating a new routing architecture. In the end, the decision was made to include the results of both efforts, side by side, in one document.
RRG内では、2つのチームが協力して単一の要件を作成する必要があるという提案がありました。ただし、これらの要件は将来の作業のガイドラインにすぎないため、特定の利点を獲得せずにコンテンツを失うリスクがあると感じる人もいます。たとえば、IRTF RRGまたはIETFルーティング領域など、どのグループも、これらの要件を書かれたものとして使用し、これらの要件を満たすアーキテクチャを作成すると予想されていません。むしろ、要件は、新しいルーティングアーキテクチャの作成を進める方法に関する強力な推奨事項でした。最終的に、1つの文書に、両方の努力の結果を並べて含めることが決定されました。
This document contains the two requirement sets produced by the teams. The text has received only editorial modifications; the requirements themselves have been left unaltered. Whenever the editors felt that conditions had changed in the few years since the text was written, an editors' note has been added to the text.
このドキュメントには、チームが作成した2つの要件セットが含まれています。テキストは編集の変更のみを受けています。要件自体は変更されていません。編集者は、テキストが書かれてから数年で条件が変化したと感じたときはいつでも、編集者のメモがテキストに追加されました。
In reading this document, it is important to keep in mind that all of these requirements are suggestions, which are laid out to assist those interested in developing new routing architectures. It is also important to remember that, while the people working on these suggestions have done their best to make intelligent suggestions, there are no guarantees. So a reader of this document should not treat what it says as absolute, nor treat every suggestion as necessary. No architecture is expected to fulfill every "requirement". Hopefully, though, future architectures will consider what is offered in this document.
このドキュメントを読むには、これらの要件はすべて提案であり、新しいルーティングアーキテクチャの開発に関心のある人々を支援するためにレイアウトされていることを留意することが重要です。また、これらの提案に取り組んでいる人々がインテリジェントな提案をするために最善を尽くしているが、保証はないことを覚えておくことも重要です。したがって、このドキュメントの読者は、それが絶対的なものとして言っていることを扱ったり、必要に応じてすべての提案を扱ったりするべきではありません。すべての「要件」を満たすアーキテクチャは予想されていません。ただし、将来のアーキテクチャがこのドキュメントで提供されているものを検討することを願っています。
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 two teams, other members of the IRTF RRG, and additional experts over the years.
IRTF RRGは、この文書の出版物が、出版時の研究グループの最新の技術的理解または技術的コンセンサスを必ずしも表すとは限らないという理解について完成した作品の歴史的記録としてサポートしました。この文書は、2つのチームのメンバー、IRTF RRGの他のメンバー、および長年にわたって追加の専門家によってかなりのレビューを行ってきました。
Finally, this document does not make any claims that it is possible to have a practical solution that meets all the listed requirements.
最後に、このドキュメントでは、リストされているすべての要件を満たす実用的なソリューションを持つことが可能であるという主張はありません。
This section presents the results of the work done by Sub-Group A of the IRTF RRG during 2001-2002. The work originally appeared under the title: "Requirements For a Next Generation Routing and Addressing Architecture" and was edited by Frank Kastenholz.
このセクションでは、2001年から2002年にかけてIRTF RRGのサブグループAで行われた作業の結果を示します。この作品はもともとタイトル「次世代ルーティングとアドレス指定アーキテクチャの要件」というタイトルの下に登場し、フランクカステンホルツによって編集されました。
The requirements presented in this section are not presented in any particular order.
このセクションで示されている要件は、特定の順序で提示されません。
The new routing and addressing protocols, data structures, and algorithms need to be developed from a clear, well thought-out, and documented architecture.
新しいルーティングおよびアドレス指定プロトコル、データ構造、およびアルゴリズムは、明確でよく考え抜かれた、文書化されたアーキテクチャから開発する必要があります。
The new routing and addressing system must have an architectural specification that describes all of the routing and addressing elements, their interactions, what functions the system performs, and how it goes about performing them. The architectural specification does not go into issues such as protocol and data structure design.
新しいルーティングおよびアドレス指定システムには、すべてのルーティングおよびアドレス指定要素、それらの相互作用、システムが実行する機能、およびそれらの実行方法を説明するアーキテクチャ仕様が必要です。アーキテクチャの仕様は、プロトコルやデータ構造の設計などの問題にはなりません。
The architecture should be agnostic with regard to specific algorithms and protocols.
アーキテクチャは、特定のアルゴリズムとプロトコルに関して不可知論者でなければなりません。
Doing architecture before doing detailed protocol design is good engineering practice. This allows the architecture to be reviewed and commented upon, with changes made as necessary, when it is still easy to do so. Also, by producing an architecture, the eventual users of the protocols (the operations community) will have a better understanding of how the designers of the protocols meant them to be used.
詳細なプロトコル設計を行う前にアーキテクチャを行うことは、優れたエンジニアリングの実践です。これにより、アーキテクチャをレビューしてコメントすることができます。これは、必要に応じて変更された場合でも、まだ簡単に行えます。また、アーキテクチャを作成することにより、プロトコル（オペレーションコミュニティ）の最終的なユーザーは、プロトコルの設計者がどのように使用するかをよりよく理解することができます。
The architecture must place different functions into separate components.
アーキテクチャは、異なる機能を個別のコンポーネントに配置する必要があります。
Separating functions, capabilities, and so forth into individual components and making each component "stand alone" is generally considered by system architects to be "A Good Thing". It allows individual elements of the system to be designed and tuned to do their jobs "very well". It also allows for piecemeal replacement and upgrading of elements as new technologies and algorithms become available.
機能、機能などを個々のコンポーネントに分離し、各コンポーネントを「スタンドアロン」にすることは、一般にシステムアーキテクトによって「良いこと」と見なされます。これにより、システムの個々の要素を設計および調整して、仕事を「非常によく」行うことができます。また、新しいテクノロジーとアルゴリズムが利用可能になるにつれて、断片的な交換と要素のアップグレードが可能になります。
The architecture must have the ability to replace or upgrade existing components and to add new ones, without disrupting the remaining parts of the system. Operators must be able to roll out these changes and additions incrementally (i.e., no "flag days"). These abilities are needed to allow the architecture to evolve as the Internet changes.
アーキテクチャには、システムの残りの部分を破壊することなく、既存のコンポーネントを交換またはアップグレードし、新しいコンポーネントを追加する機能が必要です。オペレーターは、これらの変更を繰り返して繰り返すことができなければなりません（つまり、「フラグの日」はありません）。これらの能力は、インターネットが変化するにつれてアーキテクチャが進化できるようにするために必要です。
The architecture specification shall define each of these components, their jobs, and their interactions.
アーキテクチャの仕様は、これらのコンポーネント、その仕事、およびそれらの相互作用を定義するものとします。
Some thoughts to consider along these lines are:
これらの線に沿って考慮すべきいくつかの考えは次のとおりです。
o Making topology and addressing separate subsystems. This may allow highly optimized topology management and discovery without constraining the addressing structure or physical topology in unacceptable ways.
o トポロジを作成し、個別のサブシステムに対処します。これにより、アドレス指定構造や物理的トポロジーを容認できない方法で制約することなく、高度に最適化されたトポロジ管理と発見が可能になる場合があります。
o Separate "fault detection and healing" from basic topology. From Mike O'Dell:
o 基本的なトポロジーから「障害検出と治癒」を分離します。マイク・オデルから：
Historically the same machinery is used for both. While attractive for many reasons, the availability of exogenous topology information (i.e., the intended topology) should, it seems, make some tasks easier than the general case of starting with zero knowledge. It certainly helps with recovery in the case of constraint satisfaction. In fact, the intended topology is a powerful way to state certain kinds of policy. [ODell01]
歴史的に同じ機械が両方に使用されています。多くの理由で魅力的ですが、外因性のトポロジー情報（つまり、意図されたトポロジー）の可用性は、知識がゼロから始まる一般的なケースよりもいくつかのタスクを簡単にする必要があります。制約満足度の場合の回復に確かに役立ちます。実際、意図されたトポロジーは、特定の種類のポリシーを述べる強力な方法です。[odell01]
o Making policy definition and application a separate subsystem, layered over the others.
o ポリシーの定義とアプリケーションを別のサブシステムにして、他のサブシステムを重ねます。
The architecture should also separate topology, routing, and addressing from the application that uses those components. This implies that applications such as policy definition, forwarding, and circuit and tunnel management are separate subsystems layered on top of the basic topology, routing, and addressing systems.
アーキテクチャは、これらのコンポーネントを使用するアプリケーションからトポロジ、ルーティング、およびアドレス指定を分離する必要があります。これは、ポリシーの定義、転送、回路およびトンネル管理などのアプリケーションが、基本的なトポロジ、ルーティング、アドレス指定システムの上に階層化された別々のサブシステムであることを意味します。
Scaling is the primary problem facing the routing and addressing architecture today. This problem must be solved and it must be solved for the long term.
スケーリングは、今日のルーティングとアドレス指定のアーキテクチャに直面している主な問題です。この問題は解決する必要があり、長期的に解決する必要があります。
The architecture must support a large and complex network. Ideally, it will serve our needs for the next 20 years. Unfortunately:
アーキテクチャは、大規模で複雑なネットワークをサポートする必要があります。理想的には、今後20年間のニーズに応えます。不幸にも：
1. we do not know how big the Internet will grow over that time, and
1. その間、インターネットがどれほど大きくなるかはわかりません。
2. the architecture developed from these requirements may change the fundamental structure of the Internet and therefore its growth patterns. This change makes it difficult to predict future growth patterns of the Internet.
2. これらの要件から開発されたアーキテクチャは、インターネットの基本構造、したがってその成長パターンを変更する可能性があります。この変更により、インターネットの将来の成長パターンを予測することが困難になります。
As a result, we can't quantify the requirement in any meaningful way. Using today's architectural elements as a mechanism for describing things, we believe that the network could grow to: 1. tens of thousands of ASs
その結果、意味のある方法で要件を定量化することはできません。今日の建築要素を物事を説明するメカニズムとして使用して、ネットワークは次のように成長できると考えています。
Editors' Note: As of 2005, this level had already been reached.
編集者注：2005年の時点で、このレベルはすでに到達していました。
2. tens to hundreds of millions of prefixes, during the lifetime of this architecture.
2. このアーキテクチャの生涯の間に、数十億から数億の接頭辞。
These sizes are given as a "flavor" for how we expect the Internet to grow. We fully believe that any new architecture may eliminate some current architectural elements and introduce new ones.
これらのサイズは、インターネットが成長することを期待するための「フレーバー」として与えられています。新しいアーキテクチャは、現在のアーキテクチャ要素を排除し、新しい要素を紹介する可能性があると完全に信じています。
A new routing and addressing architecture designed for a specific network size would be inappropriate. First, the cost of routing calculations is based only in part on the number of ASs or prefixes in the network. The number and locations of the links in the network are also significant factors. Second, past predictions of Internet growth and topology patterns have proven to be wildly inaccurate, so developing an architecture to a specific size goal would at best be shortsighted.
特定のネットワークサイズ用に設計された新しいルーティングとアドレス指定アーキテクチャは不適切です。まず、ルーティング計算のコストは、ネットワーク内のASSまたはプレフィックスの数に一部のみ基づいています。ネットワーク内のリンクの数と場所も重要な要素です。第二に、インターネットの成長とトポロジパターンの過去の予測は非常に不正確であることが証明されているため、特定のサイズの目標にアーキテクチャを開発することは、せいぜい近視眼的です。
Editors' Note: At the time of these meetings, the BGP statistics kept at sites such as www.routeviews.org either did not exist or had been running for only a few months. After 5 years of recording public Internet data trends in AS growth, routing table growth can be observed (past) with some short-term prediction. As each year of data collection continues, the ability to observe and predict trends improves. This architecture work pointed out the need for such statistics to improve future routing designs.
編集者注：これらの会議の時点で、www.routeviews.orgなどのサイトに保管されていたBGP統計は、存在しなかったか、数か月しか走っていませんでした。AS成長の公開インターネットデータの傾向を5年間記録した後、短期的な予測でルーティングテーブルの成長を観察できます（過去）。データ収集の毎年が続くにつれて、傾向を観察および予測する能力が向上します。このアーキテクチャ作業は、将来のルーティング設計を改善するためのこのような統計の必要性を指摘しました。
Therefore, we will not make the scaling requirement based on a specific network size. Instead, the new routing and addressing architecture should have the ability to constrain the increase in load (CPU, memory space and bandwidth, and network bandwidth) on ANY SINGLE ROUTER to be less than these specific functions:
したがって、特定のネットワークサイズに基づいてスケーリング要件を作成しません。代わりに、新しいルーティングとアドレス指定アーキテクチャには、単一のルーターの負荷（CPU、メモリスペース、帯域幅、およびネットワーク帯域幅）の増加を制限する機能が必要です。
1. The computational power and memory sizes required to execute the routing protocol software and to contain the tables must grow more slowly than hardware capabilities described by Moore's Law, doubling every 18 months. Other observations indicate that memory sizes double every 2 years or so.
1. ルーティングプロトコルソフトウェアを実行し、テーブルを封じ込めるために必要な計算能力とメモリサイズは、18か月ごとに2倍になるムーアの法律で記述されたハードウェア機能よりもゆっくりと成長する必要があります。他の観察結果は、メモリサイズが2年ごとに2倍になることを示しています。
2. Network bandwidth and latency are some key constraints on how fast routing protocol updates can be disseminated (and therefore how fast the routing system can adapt to changes). Raw network bandwidth seems to quadruple every 3 years or so. However, it seems that there are some serious physics problems in going faster than 40 Gbit/s (OC768); we should not expect raw network link speed to grow much beyond OC768. On the other hand, for economic reasons, large swathes of the core of the Internet will still operate at lower speeds, possibly as slow as DS3.
2. ネットワーク帯域幅とレイテンシは、ルーティングプロトコルの更新が普及する速さ（したがって、ルーティングシステムが変更に適応できる速さ）に関するいくつかの重要な制約です。Raw Networkの帯域幅は、3年ごとに4倍になっているようです。ただし、40 Gbit/sよりも速く進むには、いくつかの深刻な物理学の問題があるようです（OC768）。Rawネットワークリンク速度がOC768をはるかに超えて成長することを期待すべきではありません。一方、経済的な理由から、インターネットの中核の大きな範囲は、おそらくDS3と同じくらい遅い速度で動作します。
Editors' Note: Technology is running ahead of imagination and higher speeds are already common.
編集者の注：テクノロジーは想像力よりも先に実行されており、高速はすでに一般的です。
Furthermore, in some sections of the Internet, even lower speed links are found. Corporate access links are often T1, or slower. Low-speed radio links exist. Intra-domain links may be T1 or fractional-T1 (or slower).
さらに、インターネットの一部のセクションでは、さらに低速リンクが見つかります。企業のアクセスリンクは、多くの場合T1または遅いです。低速無線リンクが存在します。ドメイン内リンクは、T1または分数-T1（または遅い）である場合があります。
Therefore, the architecture must not make assumptions about the bandwidth available.
したがって、アーキテクチャは、利用可能な帯域幅について仮定してはなりません。
3. The speeds of high-speed RAMs (Static RAMs (SRAMs), used for caches and the like) are growing, though slowly. Because of their use in caches and other very specific applications, these RAMs tend to be small, a few megabits, and the size of these RAMs is not increasing very rapidly.
3. キャッシュなどに使用される高速ラム（静的ラム（SRAM））の速度はゆっくりと成長しています。キャッシュやその他の非常に特定の用途での使用により、これらのラムは小さく、いくつかのメガビットがあり、これらのラムのサイズはあまり急速に増加していません。
On the other hand, the speed of "large" memories (Dynamic RAMs (DRAMs)) is increasing even slower than that for the high-speed RAMs. This is because the development of these RAMs is driven by the PC market, where size is very important, and low speed can be made up for by better caches.
一方、「大きな」記憶（ダイナミックラム（DRAMS））の速度は、高速ラムの速度よりもさらに遅くなっています。これは、これらのRAMの開発がPC市場によって駆動され、サイズが非常に重要であり、低速がより良いキャッシュで構成されるためです。
Memory access rates should not be expected to increase significantly.
メモリアクセスレートは大幅に増加するとは予想されていません。
Editors' Note: Various techniques have significantly increased memory bandwidth. 800 MHz is now possible, compared with less than 100 MHz in the year 2000. This does not, however, contradict the next paragraph, but rather just extends the timescales somewhat.
編集者注：さまざまな手法により、メモリ帯域幅が大幅に増加しています。2000年の100 MHz未満と比較して、800 MHzが可能になりました。ただし、これは次の段落と矛盾するわけではなく、タイムスケールを多少延長するだけです。
The growth in resources available to any one router will eventually slow down. It may even stop. Even so, the network will continue to grow. The routing and addressing architecture must continue to scale in even this extreme condition. We cannot continue to add more computing power to routers forever. Other strategies must be available. Some possible strategies are hierarchy, abstraction, and aggregation of topology information.
1つのルーターが利用できるリソースの成長は、最終的に遅くなります。停止することさえあります。それでも、ネットワークは成長し続けます。ルーティングとアドレス指定アーキテクチャは、この極端な状態でさえも拡大し続ける必要があります。ルーターに永遠にコンピューティングパワーを追加し続けることはできません。他の戦略を利用できる必要があります。いくつかの可能な戦略は、トポロジー情報の階層、抽象化、および集約です。
The new routing and addressing architecture must be able to cope with a high degree of interconnectivity in the Internet. That is, there are large numbers of alternate paths and routes among the various elements. Mechanisms are required to prevent this interconnectivity (and continued growth in interconnectivity) from causing tables, compute time, and routing protocol traffic to grow without bound. The "cost" to the routing system of an increase in complexity must be limited in scope; sections of the network that do not see, or do not care about, the complexity ought not pay the cost of that complexity.
新しいルーティングとアドレス指定アーキテクチャは、インターネットでの高度な相互接続性に対処できる必要があります。つまり、さまざまな要素の間には、多数の代替パスとルートがあります。この相互接続性（および相互接続性の継続的な成長）がテーブル、計算時間、およびルーティングプロトコルトラフィックが拘束されずに成長するのを防ぐためにメカニズムが必要です。複雑さの増加のルーティングシステムへの「コスト」は、範囲が制限されている必要があります。複雑さを見ない、または気にしないネットワークのセクションは、その複雑さのコストを支払うべきではありません。
Over the past several years, the Internet has seen an increase in interconnectivity. Individual end sites (companies, customers, etc.), ISPs, exchange points, and so on, all are connecting to more "other things". Companies multi-home to multiple ISPs, ISPs peer with more ISPs, and so on. These connections are made for many reasons, such as getting more bandwidth, increased reliability and availability, policy, and so on. However, this increased interconnectivity has a price. It leads to more scaling problems as it increases the number of AS paths in the networks.
過去数年にわたって、インターネットは相互接続性の増加を見てきました。個々のエンドサイト（企業、顧客など）、ISP、交換ポイントなど、すべてがより多くの「他のもの」に接続しています。企業は複数のISPから複数のISP、より多くのISPを備えたISPのピアなどです。これらの接続は、帯域幅の増加、信頼性と可用性の向上、ポリシーなど、多くの理由で作成されています。ただし、この相互接続性の増加には価格があります。ネットワーク内のASパスの数を増やすにつれて、よりスケーリングの問題につながります。
Any new architecture must assume that the Internet will become a denser mesh. It must not assume, nor can it dictate, certain patterns or limits on how various elements of the network interconnect.
新しいアーキテクチャは、インターネットがより密度の高いメッシュになると想定する必要があります。ネットワークのさまざまな要素がどのように相互接続されているかについて、特定のパターンまたは制限を想定したり、指示したりすることはできません。
Another facet of this requirement is that there may be multiple valid, loop-free paths available to a destination. See Section 2.1.7 for a further discussion.
この要件のもう1つの側面は、宛先が利用できる複数の有効でループフリーのパスがある可能性があることです。詳細については、セクション2.1.7を参照してください。
We wryly note that one of the original design goals of IP was to support a large, heavily interconnected network, which would be highly survivable (such as in the face of a nuclear war).
IPの元の設計目標の1つは、非常に生存可能な大規模な相互接続されたネットワークをサポートすることであったことに注意してください（核戦争に直面するなど）。
The routing and addressing architecture must not place any constraints on or make assumptions about the topology or connectedness of the elements comprising the Internet. The routing and addressing architecture must not presume any particular network structure. The network does not have a "nice" structure. In the past, we used to believe that there was this nice "backbone/tier-1/ tier-2/end-site" sort of hierarchy. This is not so. Therefore, any new architecture must not presume any such structure.
ルーティングおよびアドレス指定アーキテクチャは、インターネットを構成する要素のトポロジーまたは接続性について制約を課したり、仮定したりしてはなりません。ルーティングおよびアドレス指定アーキテクチャは、特定のネットワーク構造を推定してはなりません。ネットワークには「素敵な」構造はありません。過去には、この素敵な「バックボーン/ティア1/ティア2/エンドサイト」の階層があると信じていました。これはそうではありません。したがって、新しいアーキテクチャはそのような構造を推定してはなりません。
Some have proposed that a geographic addressing scheme be used, requiring exchange points to be situated within each geographic "region". There are many reasons why we believe this to be a bad approach, but those arguments are irrelevant. The main issue is that the routing architecture should not presume a specific network structure.
地理的アドレス指定スキームを使用することを提案している人もいれば、各地理的「地域」内に交換ポイントを配置することを要求することを提案しています。これが悪いアプローチであると信じている多くの理由がありますが、それらの議論は無関係です。主な問題は、ルーティングアーキテクチャが特定のネットワーク構造を推定すべきではないことです。
The architecture must provide multi-homing for all elements of the Internet. That is, multi-homing of hosts, subnetworks, end-sites, "low-level" ISPs, and backbones (i.e., lots of redundant interconnections) must be supported. Among the reasons to multi-home are reliability, load sharing, and performance tuning.
アーキテクチャは、インターネットのすべての要素にマルチホミングを提供する必要があります。つまり、ホスト、サブネットワーク、エンドサイト、「低レベル」ISP、およびバックボーン（つまり、冗長な相互接続の多く）をマルチホミングする必要があります。マルチホームの理由には、信頼性、負荷共有、パフォーマンスの調整があります。
The term "multi-homing" may be interpreted in its broadest sense -- one "place" has multiple connections or links to another "place".
「マルチホミング」という用語は、最も広い意味で解釈される場合があります。1つの「場所」には、別の「場所」への複数の接続またはリンクがあります。
The architecture must not limit the number of alternate paths to a multi-homed site.
アーキテクチャは、マルチホームのサイトへの代替パスの数を制限してはなりません。
When multi-homing is used, it must be possible to use one, some (more than one but less than all), or all of the available paths to the multi-homed site. The multi-homed site must have the ability to declare which path(s) are used and under what conditions (for example, one path may be declared "primary" and the other "backup" and to be used only when the primary fails).
マルチホーミングを使用する場合、1つ、一部（複数以上ではないが、すべて）、またはマルチホームサイトへの利用可能なすべてのパスを使用することが可能でなければなりません。マルチホームのサイトには、どのパスが使用されているかを宣言し、どの条件下で宣言する機能が必要です（たとえば、1つのパスは「プライマリ」と宣言され、もう1つのパスは「バックアップ」を宣言し、プライマリが失敗した場合にのみ使用することができます）。
A current problem in the Internet is that multi-homing leads to undue increases in the size of the BGP routing tables. The new architecture must support multi-homing without undue routing table growth.
インターネットでの現在の問題は、マルチホームがBGPルーティングテーブルのサイズが過度に増加することにつながることです。新しいアーキテクチャは、過度のルーティングテーブルの成長なしにマルチホームをサポートする必要があります。
As a corollary to multi-homing, the architecture must allow for multiple paths from a source to a destination to be active at the same time. These paths need not have the same attributes. Policies are to be used to disseminate the attributes and to classify traffic for the different paths.
マルチホミングの結果として、アーキテクチャは、ソースから目的地までの複数のパスを同時にアクティブにすることを許可する必要があります。これらのパスには同じ属性を持つ必要はありません。ポリシーは、属性を広め、さまざまなパスのトラフィックを分類するために使用されます。
There must be a rich "language" for specifying the rules for classifying the traffic and assigning classes of traffic to different paths (or prohibiting it from certain paths). The rules should allow traffic to be classified based upon, at least, the following: o IPv6 FlowIDs,
トラフィックを分類し、トラフィックのクラスを異なるパスに割り当てる（または特定のパスから禁止する）ためのルールを指定するには、豊富な「言語」が必要です。ルールは、少なくとも次のことに基づいてトラフィックを分類できるようにする必要があります。OIPv6flowids、
o Diffserv Code Point (DSCP) values,
o Diffservコードポイント（DSCP）値、
o source and/or destination prefixes, or
o ソースおよび/または宛先のプレフィックス、または
o random selections at some probability.
o ある程度の確率でのランダム選択。
A mechanism is needed that allows operators to plan and manage the traffic load on the various paths. To start, this mechanism can be semi-automatic or even manual. Eventually, it ought to become fully automatic.
オペレーターがさまざまなパスのトラフィック負荷を計画および管理できるようにするメカニズムが必要です。開始するために、このメカニズムは半自動またはマニュアルでさえあります。最終的には、完全に自動になるはずです。
When multi-path forwarding is used, options must be available to preserve packet ordering where appropriate (such as for individual TCP connections).
マルチパス転送を使用する場合、必要に応じてパケットの順序を保持するためにオプションを利用できる必要があります（個々のTCP接続など）。
Please refer to Section 2.2.7 for a discussion of dynamic load-balancing and management over multiple paths.
複数のパスでの動的な負荷分散と管理の議論については、セクション2.2.7を参照してください。
The speed of convergence (also called the "stabilization time") is the time it takes for a router's routing processes to reach a new, stable, "solution" (i.e., forwarding information base) after a change someplace in the network. In effect, what happens is that the output of the routing calculations stabilizes -- the Nth iteration of the software produces the same results as the N-1th iteration.
収束の速度（「安定化時間」とも呼ばれます）は、ルーターのルーティングプロセスがネットワーク内の変更後に新しい「ソリューション」（すなわち、転送情報ベース）に到達するのにかかる時間です。実際には、ルーティング計算の出力が安定することです。ソフトウェアのNth Iterationは、N-1イテレーションと同じ結果を生成します。
The speed of convergence is generally considered to be a function of the number of subnetworks in the network and the amount of connections between those networks. As either number grows, the time it takes to converge increases.
収束の速度は一般に、ネットワーク内のサブネットワークの数とそれらのネットワーク間の接続の量の関数であると考えられています。いずれかの数が増えると、収束にかかる時間が増えます。
In addition, a change can "ripple" back and forth through the system. One change can go through the system, causing some other router to change its advertised connectivity, causing a new change to ripple through. These oscillations can take a while to work their way out of the network. It is also possible that these ripples never die out. In this situation, the routing and addressing system is unstable; it never converges.
さらに、変更はシステムを介して「リップル」します。1つの変更がシステムを通過する可能性があり、他のいくつかのルーターが宣伝された接続性を変更し、リップルを通過させる新しい変更を引き起こします。これらの振動には、ネットワークから抜け出すのに時間がかかる場合があります。また、これらの波紋が決して死ぬことはない可能性もあります。この状況では、ルーティングおよびアドレス指定システムは不安定です。収束することはありません。
Finally, it is more than likely that the routers comprising the Internet never converge simply because the Internet is so large and complex. Assume it takes S seconds for the routers to stabilize on a solution for any one change to the network. Also, assume that changes occur, on average, every C seconds. Because of the size and complexity of the Internet, C is now less than S. Therefore, if a change, C1, occurs at time T, the routing system would stabilize at time T+S, but a new change, C2, will occur at time T+C, which is before T+S. The system will start processing the new change before it's done with the old.
最後に、インターネットが非常に大きく複雑であるという理由だけで、インターネットを構成するルーターが決して収束しない可能性があります。ルーターがネットワークへの1つの変更のソリューションを安定させるのに1秒かかると仮定します。また、変化が平均してC秒ごとに発生すると仮定します。インターネットのサイズと複雑さのため、Cは現在Sより少ないため、C1が時間tでC1が発生した場合、ルーティングシステムは時間tで安定しますが、新しい変更、C2は時間に発生します。T Cの前にあるT Cは、システムが古いもので行われる前に新しい変更の処理を開始します。
This is not to say that all routers are constantly processing changes. The effects of changes are like ripples in a pond. They spread outward from where they occur. Some routers will be processing just C1, others C2, others both C1 and C2, and others neither.
これは、すべてのルーターが常に処理されているということではありません。変化の影響は、池の波紋のようなものです。彼らは彼らが発生する場所から外側に広がりました。一部のルーターはC1、C2、他のルーターはC1とC2の両方を処理し、他のルーターはどちらも処理します。
We have two separate scopes over which we can set requirements with respect to convergence:
収束に関して要件を設定できる2つの個別のスコープがあります。
1. Single Change: In this requirement, a single change of any type (link addition or deletion, router failure or restart, etc.) is introduced into a stabilized system. No additional changes are introduced. The system must re-stabilize within some measure of bounded time. This requirement is a fairly abstract one as it would be impossible to test in a real network. Definition of the time constraints remains an open research issue.
1. 単一の変更：この要件では、あらゆるタイプの単一の変更（リンクの追加または削除、ルーターの障害または再起動など）が安定化されたシステムに導入されます。追加の変更は導入されていません。システムは、ある程度の境界時間内で再設定する必要があります。この要件は、実際のネットワークでテストすることは不可能であるため、かなり抽象的なものです。時間制約の定義は、未解決の研究問題のままです。
2. System-Wide: Defining a single target for maximum convergence time for the real Internet is absurd. As we mentioned earlier, the Internet is large enough and diverse enough so that it is quite likely that new changes are introduced somewhere before the system fully digests old ones.
2. システム全体：実際のインターネットの最大収束時間に単一のターゲットを定義することはばかげています。前述したように、インターネットは十分に大きく多様であるため、システムが古いものを完全に消化する前に、新しい変更がどこかに新しい変更が導入される可能性が非常に高いです。
So, the first requirement here is that there must be mechanisms to limit the scope of any one change's visibility and effects. The number of routers that have to perform calculations in response to a change is kept small, as is the settling time.
したがって、ここでの最初の要件は、1つの変更の可視性と効果の範囲を制限するメカニズムが必要であることです。変化に応じて計算を実行しなければならないルーターの数は、沈降時間と同様に小さくなります。
The second requirement is based on the following assumptions:
2番目の要件は、次の仮定に基づいています。
- the scope of a change's visibility and impact can be limited. That is, routers within that scope know of the change and recalculate their tables based on the change. Routers outside of the scope don't see it at all.
- 変化の可視性と影響の範囲は制限される可能性があります。つまり、その範囲内のルーターは変更を知っており、変更に基づいてテーブルを再計算します。スコープの外側のルーターはまったく表示されません。
- Within any scope, S, network changes are constantly occurring and the average inter-change interval is Tc seconds.
- 任意の範囲内で、s、ネットワークの変更が常に発生しており、平均変化間隔はTC秒です。
- There are Rs routers within scope S.
- スコープSにはRSルーターがあります。
- A subset of the destinations known to the routers in S, Ds, are impacted by a given change.
- S、DSのルーターに知られている宛先のサブセットは、特定の変更の影響を受けます。
- We can state that for Z% of the changes, within Y% of Tc seconds after a change, C, X% of the Rs routers have their routes to Ds settled to a useful answer (useful meaning that packets can get to Ds, though perhaps not by the optimal path -- this allows some "hunting" for the optimal solution).
- 変化のz％の場合、変化後のtc秒のy％以内で、c、rsルーターのx％がDSへのルートを有用な答えに落ち着かせることを述べることができます（ただし、パケットはDSに到達できるという意味です。おそらく最適なパスではありません - これにより、最適なソリューションのために「狩り」が可能になります）。
X, Y, and Z are yet to be defined. Their definition remains a research issue.
x、y、zはまだ定義されていません。彼らの定義は研究問題のままです。
This requirement implies that the scopes can be kept relatively small in order to minimize Rs and maximize Tc.
この要件は、RSを最小限に抑えてTCを最大化するために、スコープを比較的小さく保つことができることを意味します。
The growth rate of the convergence time must not be related to the growth rate of the Internet as a whole. This implies that the convergence time either:
収束時間の成長率は、インターネット全体の成長率に関連してはなりません。これは、収束時間のいずれかを意味します。
1. not be a function of basic network elements (such as prefixes and links/paths), and/or
1. 基本的なネットワーク要素（プレフィックスやリンク/パスなど）の関数ではない、および/または
2. that the Internet be continuously divisible into chunks that limit the scope and effect of a change, thereby limiting the number of routers, prefixes, links, and so on, involved in the new calculations.
2. インターネットが変化の範囲と効果を制限するチャンクに継続的に分裂し、それにより、新しい計算に関与するルーター、プレフィックス、リンクなどの数を制限します。
The security of the Internet's routing system is paramount. If the routing system is compromised or attacked, the entire Internet can fail. This is unacceptable. Any new architecture must be secure.
インターネットのルーティングシステムのセキュリティが最重要です。ルーティングシステムが侵害または攻撃されている場合、インターネット全体が失敗する可能性があります。これは受け入れがたい。新しいアーキテクチャは安全でなければなりません。
Architectures by themselves are not secure. It is the implementation of an architecture, its protocols, algorithms, and data structures that are secure. These requirements apply primarily to the implementation. The architecture must provide the elements that the implementation needs to meet these security requirements. Also, the architecture must not prevent these security requirements from being met.
それ自体によるアーキテクチャは安全ではありません。安全なのは、アーキテクチャ、そのプロトコル、アルゴリズム、およびデータ構造の実装です。これらの要件は、主に実装に適用されます。アーキテクチャは、実装がこれらのセキュリティ要件を満たすために必要な要素を提供する必要があります。また、アーキテクチャは、これらのセキュリティ要件が満たされないようにしてはなりません。
Security means different things to different people. In order for this requirement to be useful, we must define what we mean by security. We do this by identifying the attackers and threats we wish to protect against. They are: Masquerading The system, including its protocols, must be secure against intruders adopting the identity of other known, trusted elements of the routing system and then using that position of trust for carrying out other attacks. Protocols must use cryptographically strong authentication.
セキュリティとは、さまざまな人々にとって異なることを意味します。この要件が有用であるためには、セキュリティが意味することを定義する必要があります。私たちは、私たちが保護したい攻撃者と脅威を特定することによってこれを行います。それらは次のとおりです。そのプロトコルを含むシステムを装備することは、ルーティングシステムの他の既知の信頼できる要素のアイデンティティを採用し、他の攻撃を実行するためにその信頼の位置を使用する侵入者に対して安全でなければなりません。プロトコルは、暗号的に強力な認証を使用する必要があります。
Denial-of-Service (DoS) Attacks The architecture and protocols should be secure against DoS attacks directed at the routers.
サービス拒否（DOS）攻撃アーキテクチャを攻撃し、プロトコルはルーターに向けられたDOS攻撃に対して安全である必要があります。
The new architecture and protocols should provide as much information as it can to allow administrators to track down sources of DoS and Distributed DOS (DDoS) attacks.
新しいアーキテクチャとプロトコルは、管理者がDOSおよび分散DOS（DDOS）攻撃のソースを追跡できるようにできる限り多くの情報を提供する必要があります。
No Bad Data Any new architecture and protocols must provide protection against the introduction of bad, erroneous, or misleading data by attackers. Of particular importance, an attacker must not be able to redirect traffic flows, with the intent of:
悪いデータ新しいアーキテクチャとプロトコルは、攻撃者による悪い、誤った、または誤解を招くデータの導入に対する保護を提供する必要があります。特に重要なことに、攻撃者は次の意図を持ってトラフィックフローをリダイレクトできない必要があります。
o directing legitimate traffic away from a target, causing a denial-of-service attack by preventing legitimate data from reaching its destination,
o 合法的なトラフィックをターゲットから遠ざけるように指示し、正当なデータが目的地に到達するのを防ぐことにより、サービス拒否攻撃を引き起こし、
o directing additional traffic (going to other destinations that are "innocent bystanders") to a target, causing the target to be overloaded, or
o 追加のトラフィック（「無実の傍観者」である他の目的地に行く）をターゲットに指示し、ターゲットを過負荷にします。
o directing traffic addressed to the target to a place where the attacker can copy, snoop, alter, or otherwise affect the traffic.
o 攻撃者がトラフィックにコピー、スヌープ、変更、またはその他の影響を与えることができる場所にターゲットに宛てたトラフィックを誘導します。
Topology Hiding Any new architecture and protocols must provide mechanisms to allow network owners to hide the details of their internal topologies, while maintaining the desired levels of service connectivity and reachability.
新しいアーキテクチャとプロトコルを隠すトポロジは、ネットワーク所有者が内部トポロジの詳細を隠すことができるメカニズムを提供する必要があります。
Privacy By "privacy" we mean privacy of the routing protocol exchanges between routers.
「プライバシー」によるプライバシーは、ルーター間のルーティングプロトコル交換のプライバシーを意味します。
When the routers are on point-to-point links, with routers at each end, there may not be any need to encrypt the routing protocol traffic as the possibility of a third party intercepting the traffic is limited, though not impossible. We do believe, however, that it is important to have the ability to protect routing protocol traffic in two cases:
ルーターが両端にルーターを使用してポイントツーポイントリンクにある場合、サードパーティがトラフィックを傍受する可能性が制限されている可能性があるため、ルーティングプロトコルトラフィックを暗号化する必要はない場合があります。ただし、2つのケースでルーティングプロトコルトラフィックを保護する能力を持つことが重要であると考えています。
1. When the routers are on a shared network, it is possible that there are hosts on the network that have been compromised. These hosts could surreptitiously monitor the protocol traffic.
1. ルーターが共有ネットワーク上にある場合、ネットワーク上に侵害されたホストがある可能性があります。これらのホストは、プロトコルトラフィックをひそかに監視する可能性があります。
2. When two routers are exchanging information "at a distance" (over intervening routers and, possibly, across administrative domain boundaries). In this case, the security of the intervening routers, links, and so on, cannot be assured. Thus, the ability to encrypt this traffic is important.
2. 2つのルーターが「距離で」情報を交換している場合（介在するルーターの上に、そしておそらく管理ドメインの境界を越えて）。この場合、介在するルーター、リンクなどのセキュリティは保証できません。したがって、このトラフィックを暗号化する能力は重要です。
Therefore, we believe that the option to encrypt routing protocol traffic is required.
したがって、ルーティングプロトコルトラフィックを暗号化するオプションが必要であると考えています。
Data Consistency A router should be able to detect and recover from any data that is received from other routers that is inconsistent. That is, it must not be possible for data from multiple routers, none of which is malicious, to "break" another router.
データの一貫性ルーターは、一貫性のない他のルーターから受信されたデータを検出して回復できる必要があります。つまり、複数のルーターからのデータが悪意のあるものではなく、別のルーターを「壊す」ことは不可能です。
Where security mechanisms are provided, they must use methods that are considered to be cryptographically secure (e.g., using cryptographically strong encryption and signatures -- no cleartext passwords!).
セキュリティメカニズムが提供される場合、暗号化された安全であると見なされる方法を使用する必要があります（例えば、暗号化的に強い暗号化と署名を使用します - クリアテキストパスワードはありません！）。
Use of security features should not be optional (except as required above). This may be "social engineering" on our part, but we believe it to be necessary. If a security feature is optional, the implementation of the feature must default to the "secure" setting.
セキュリティ機能の使用はオプションではありません（上記の場合を除く）。これは私たちの「ソーシャルエンジニアリング」かもしれませんが、私たちはそれが必要であると信じています。セキュリティ機能がオプションの場合、機能の実装は「セキュア」設定にデフォルトする必要があります。
The architecture must not prevent individual host-to-host communications sessions from being secured (i.e., it cannot interfere with things like IPsec).
アーキテクチャは、個々のホスト間通信セッションが保護されないようにしてはなりません（つまり、IPSECのようなものに干渉することはできません）。
Before setting out policy requirements, we need to define the term. Like "security", "policy" means different things to different people. For our purposes, "policy" is the set of administrative influences that alter the path determination and next-hop selection procedures of the routing software.
ポリシー要件を設定する前に、用語を定義する必要があります。「セキュリティ」のように、「ポリシー」とは異なる人々にとって異なることを意味します。私たちの目的のために、「ポリシー」は、ルーティングソフトウェアのパス決定と次のホップ選択手順を変更する管理上の影響のセットです。
The main motivators for influencing path and next-hop selection seem to be transit rules, business decisions, and load management.
パスに影響を与え、次のホップの選択に影響を与える主な動機は、輸送規則、ビジネス上の決定、負荷管理のようです。
The new architecture must support rich policy mechanisms. Furthermore, the policy definition and dissemination mechanisms should be separated from the network topology and connectivity dissemination mechanisms. Policy provides input to and controls the generation of the forwarding table and the abstraction, filtering, aggregation, and dissemination of topology information.
新しいアーキテクチャは、豊富な政策メカニズムをサポートする必要があります。さらに、ポリシーの定義と普及メカニズムは、ネットワークトポロジと接続性普及メカニズムから分離する必要があります。ポリシーは、転送テーブルの生成と、トポロジー情報の抽象化、フィルタリング、集約、および普及を提供し、制御します。
Note that if the architecture is properly divided into subsystems, then at a later time, new policy subsystems that include new features and capabilities could be developed and installed as needed.
アーキテクチャがサブシステムに適切に分割されている場合、後で、必要に応じて新しい機能と機能を含む新しいポリシーサブシステムを開発およびインストールできることに注意してください。
We divide the general area of policy into two sub-categories: routing information and traffic control. Routing Information Policies control what routing information is disseminated or accepted, how it is disseminated, and how routers determine paths and next-hops from the received information. Traffic Control Policies determine how traffic is classified and assigned to routes.
ポリシーの一般的な領域を2つのサブカテゴリに分けます：ルーティング情報とトラフィックコントロール。ルーティング情報ポリシーは、どのルーティング情報が普及または受け入れられているか、それがどのように普及されているか、およびルーターが受信した情報からパスとネクストホップをどのように決定するかを制御します。トラフィック管理ポリシーは、トラフィックの分類方法とルートに割り当てられる方法を決定します。
There must be mechanisms to allow network administrators, operators, and designers to control receipt and dissemination of routing information. These controls include, but are not limited to:
ネットワーク管理者、オペレーター、設計者がルーティング情報の領収書と普及を制御できるようにするメカニズムが必要です。これらのコントロールには、以下が含まれますが、これらに限定されません。
- Selecting to which other routers routing information will be transmitted.
- 他のルーターのルーティング情報が送信されるかを選択します。
- Specifying the "granularity" and type of transmitted information. The length of IPv4 prefixes is an example of granularity.
- 「粒度」と送信された情報の種類を指定します。IPv4プレフィックスの長さは、粒度の例です。
- Selection and filtering of topology and service information that is transmitted. This gives different "views" of internal structure and topology to different peers.
- 送信されるトポロジとサービス情報の選択とフィルタリング。これにより、さまざまなピアに内部構造とトポロジのさまざまな「見解」が得られます。
- Selecting the level of security and authenticity for transmitted information.
- 送信された情報のセキュリティと信頼性のレベルを選択します。
- Being able to cause the level of detail that is visible for some portion of the network to reduce the farther you get from that part of the network.
- ネットワークの一部がネットワークのその部分からより遠くまで削減するために、ネットワークの一部が見える詳細レベルを引き起こすことができます。
- Selecting from whom routing information will be accepted. This control should be "provisional" in the sense of "accept routes from "foo" only if there are no others available".
- 誰からルーティング情報が受け入れられるかを選択します。このコントロールは、「他のものが利用できない場合にのみ、「foo」からルートを受け入れる」という意味で「暫定的」でなければなりません。
- Accepting or rejecting routing information based on the path the information traveled (using the current system as an example, this would be filtering routes based on an AS appearing anywhere in the AS path). This control should be "use only if there are no other paths available".
- パスに基づいてルーティング情報を受け入れるか拒否した情報が移動しました（現在のシステムを例として使用して、これはASパスのどこにでも表示されるASに基づいてルートをフィルタリングします）。この制御は、「利用可能な他のパスがない場合にのみ使用する」必要があります。
- Selecting the desired level of granularity for received routing information (this would include, but is not limited to, things similar in nature to the prefix-length filters widely used in the current routing and addressing system).
- 受信したルーティング情報に対して望ましいレベルの粒度を選択する（これには、現在のルーティングおよびアドレス指定システムで広く使用されているプレフィックス長フィルターに類似したものが含まれますが、これらに限定されません）。
- Selecting the level of security and authenticity of received information in order for that information to be accepted.
- その情報を受け入れるために、受信した情報のセキュリティと信頼性のレベルを選択します。
- Determining the treatment of received routing information based on attributes supplied with the information.
- 情報が付属している属性に基づいて、受信したルーティング情報の処理を決定する。
- Applying attributes to routing information that is to be transmitted and then determining treatment of information (e.g., sending it "here" but not "there") based on those tags.
- 送信されるルーティング情報に属性を適用し、それらのタグに基づいて情報の処理（たとえば、「ここ」ではなく「ここ」ではなく送信する）を決定します。
- Selection and filtering of topology and service information that is received.
- 受け取ったトポロジとサービス情報の選択とフィルタリング。
The architecture should provide mechanisms that allow network operators to manage and control the flow of traffic. The traffic controls should include, but are not limited to:
アーキテクチャは、ネットワークオペレーターがトラフィックの流れを管理および制御できるようにするメカニズムを提供する必要があります。トラフィックコントロールには含まれる必要がありますが、以下に限定されません。
- The ability to detect and eliminate congestion points in the network (by redirecting traffic around those points).
- ネットワーク内の混雑ポイントを検出および排除する機能（これらのポイントの周りのトラフィックをリダイレクトすることにより）。
- The ability to develop multiple paths through the network with different attributes and then assign traffic to those paths based on some discriminators within the packets (discriminators include, but are not limited to, IP addresses or prefixes, IPv6 flow ID, DSCP values, and MPLS labels).
- 異なる属性を持つネットワークを介して複数のパスを開発し、パケット内の一部の判別器に基づいてそれらのパスにトラフィックを割り当てる機能（判別器には、IPアドレスまたはプレフィックス、IPv6フローID、DSCP値、およびMPLSが含まれますが、これらに限定されませんラベル）。
- The ability to find and use multiple, equivalent paths through the network (i.e., they would have the "same" attributes) and allocate traffic across the paths.
- ネットワークを介して複数の同等のパスを見つけて使用する機能（つまり、「同じ」属性があり、パス全体にトラフィックを割り当てることができます。
- The ability to accept or refuse traffic based on some traffic classification (providing, in effect, transit policies).
- 一部のトラフィック分類（実際には、輸送ポリシーを提供する）に基づいてトラフィックを受け入れるか拒否する能力。
Traffic classification must at least include the source and destination IP addresses (prefixes) and the DSCP value. Other fields may be supported, such as:
トラフィック分類には、少なくともソースおよび宛先IPアドレス（プレフィックス）とDSCP値を含める必要があります。次のような他のフィールドがサポートされる場合があります。
* Protocol and port-based functions,
* プロトコルとポートベースの機能、
* DSCP/QoS (Quality of Service) tuple (such as ports),
* DSCP/QOS（サービス品質）タプル（ポートなど）、
* Per-host operations (i.e., /32 s for IPv4 and /128 s for IPv6), and
* ホストごとの操作（つまり、IPv4の場合は /32秒、IPv6の場合 /128秒）、および
* Traffic matrices (e.g., traffic from prefix X and to prefix Y).
* トラフィックマトリックス（たとえば、プレフィックスXからプレフィックスYへのトラフィック）。
The reality of the Internet is that there can be no Internet-wide cutover from one architecture and protocol to another. This means that any new architecture and protocol must be incrementally deployable; ISPs must be able to set up small sections of the new architecture, check it out, and then slowly grow the sections. Eventually, these sections will "touch" and "squeeze out" the old architecture.
インターネットの現実は、あるアーキテクチャやプロトコルから別のアーキテクチャまでインターネット全体のカットオーバーがないことです。これは、新しいアーキテクチャとプロトコルが段階的に展開できることを意味します。ISPは、新しいアーキテクチャの小さなセクションをセットアップし、チェックアウトしてから、セクションをゆっくりと成長させることができなければなりません。最終的に、これらのセクションは古いアーキテクチャを「触れ」、「絞り出す」ことになります。
The protocols that implement the architecture must be able to interoperate at "production levels" with currently existing routing protocols. Furthermore, the protocol specifications must define how the interoperability is done.
アーキテクチャを実装するプロトコルは、現在既存のルーティングプロトコルと「生産レベル」で相互運用できる必要があります。さらに、プロトコル仕様は、相互運用性がどのように行われるかを定義する必要があります。
We also believe that sections of the Internet will never convert over to the new architecture. Thus, it is important that the new architecture and its protocols be able to interoperate with "old architecture" regions of the network indefinitely.
また、インターネットのセクションが新しいアーキテクチャに変換されることは決してないと考えています。したがって、新しいアーキテクチャとそのプロトコルが、ネットワークの「古いアーキテクチャ」領域と無期限に相互運用できることが重要です。
The architecture's addressing system must not force existing address allocations to be redone: no renumbering!
アーキテクチャのアドレス指定システムは、既存のアドレスの割り当てを強制してはなりません。
There are two kinds of mobility: host mobility and network mobility. Host mobility is when an individual host moves from where it was to where it is. Network mobility is when an entire network (or subnetwork) moves.
モビリティには、ホストのモビリティとネットワークモビリティの2種類があります。ホストのモビリティとは、個々のホストが場所からそれがどこにあるかに移動するときです。ネットワークモビリティとは、ネットワーク全体（またはサブネットワーク）が移動する場合です。
The architecture must support network-level mobility. Please refer to Section 2.2.9 for a discussion of host mobility.
アーキテクチャは、ネットワークレベルのモビリティをサポートする必要があります。ホストのモビリティの議論については、セクション2.2.9を参照してください。
Editors' Note: Since the time of this work, the Network Mobility (NEMO) extensions to Mobile-IP [RFC3963] to accommodate mobile networks have been developed.
編集者注：この作業の時代以来、モバイルネットワークに対応するためのモバイルIP [RFC3963]へのネットワークモビリティ（NEMO）拡張が開発されました。
One of the big "hot items" in the current Internet political climate is portability of IP addresses (both v4 and v6). The short explanation is that people do not like to renumber when changing connection point or provider and do not trust automated renumbering tools.
現在のインターネットの政治情勢の大きな「ホットアイテム」の1つは、IPアドレスの携帯性です（V4とV6の両方）。簡単な説明は、人々が接続ポイントやプロバイダーを変更するときに買い戻しを好まないことであり、自動化された変更ツールを信頼していないということです。
The architecture must provide complete address portability.
アーキテクチャは、完全なアドレス移植性を提供する必要があります。
The Internet is expected to be "multi-protocol" for at least the next several years. IPv4 and IPv6 will co-exist in many different ways during a transition period. The architecture must be able to handle both IPv4 and IPv6 addresses. Furthermore, protocols that supplant IPv4 and IPv6 may be developed and deployed during the lifetime of the architecture. The architecture must be flexible and extensible enough to handle new protocols as they arise.
インターネットは、少なくとも今後数年間は「マルチプロトコル」になると予想されています。IPv4とIPv6は、移行期間中にさまざまな方法で共存します。アーキテクチャは、IPv4アドレスとIPv6アドレスの両方を処理できる必要があります。さらに、IPv4とIPv6に取って代わるプロトコルは、アーキテクチャの寿命の間に開発および展開される場合があります。アーキテクチャは、新しいプロトコルが発生するにつれて柔軟で拡張可能である必要があります。
Furthermore, the architecture must not assume any given relationships between a topological element's IPv4 address and its IPv6 address. The architecture must not assume that all topological elements have IPv4 addresses/prefixes, nor can it assume that they have IPv6 addresses/prefixes.
さらに、アーキテクチャは、トポロジ要素のIPv4アドレスとそのIPv6アドレスとの間に与えられた関係を想定してはなりません。アーキテクチャは、すべてのトポロジ要素がIPv4アドレス/プレフィックスを持っていると仮定してはならず、IPv6アドレス/プレフィックスがあると仮定することもできません。
The architecture should allow different paths to the same destination to be used for different protocols, even if all paths can carry all protocols.
アーキテクチャは、すべてのパスがすべてのプロトコルを運ぶことができる場合でも、同じ宛先への異なるパスを異なるプロトコルに使用できるようにする必要があります。
In addition to the addressing technology, the architecture need not be restricted to only packet-based multiplexing/demultiplexing technology (such as IP); support for other multiplexing/ demultiplexing technologies may be added.
アドレス指定技術に加えて、アーキテクチャは、パケットベースの多重化/非崩壊テクノロジー（IPなど）のみに制限する必要はありません。他の多重化/非崩壊技術のサポートが追加される場合があります。
The architecture must provide mechanisms for network designers and operators to:
アーキテクチャは、ネットワーク設計者とオペレーターに次のメカニズムを提供する必要があります。
o Group elements together for administrative control purposes,
o 管理制御目的でグループ要素を一緒にする、
o Hide the internal structure and topology of those groupings for administrative and security reasons,
o 管理およびセキュリティの理由のために、これらのグループの内部構造とトポロジを非表示にします。
o Limit the amount of topology information that is exported from the groupings in order to control the load placed on external routers,
o 外部ルーターに配置された負荷を制御するために、グループからエクスポートされるトポロジ情報の量を制限します。
o Define rules for traffic transiting or terminating in the grouping.
o グループ内の交通または終了の交通量のルールを定義します。
The architecture must allow the current Autonomous System structure to be mapped into any new abstraction schemes.
アーキテクチャは、現在の自律システム構造を新しい抽象化スキームにマッピングできるようにする必要があります。
Mapping mechanisms, algorithms, and techniques must be specified.
マッピングメカニズム、アルゴリズム、および手法を指定する必要があります。
The architecture must be simple enough so that someone who is extremely knowledgeable in routing and who is skilled at creating straightforward and simple explanations can explain all the important concepts in less than an hour.
アーキテクチャは、ルーティングに非常に知識が豊富で、簡単で簡単な説明を作成することに熟練している人が、すべての重要な概念を1時間以内に説明できるように、十分にシンプルでなければなりません。
This criterion has been chosen since developing an objective measure of complexity for an architecture can be very difficult and is out of scope for this document.
この基準は、アーキテクチャの複雑さの客観的な尺度を開発することが非常に難しく、このドキュメントの範囲外であるため、選択されています。
The requirement is that the routing architecture be kept as simple as possible. This requires careful evaluation of possible features and functions with a merciless weeding out of those that "might be nice" but are not necessary.
要件は、ルーティングアーキテクチャを可能な限りシンプルに保つことです。これには、「いいかもしれないが必要ではないかもしれないが必要ないものから容赦ない除草を伴う、可能な機能と機能を慎重に評価する必要があります。
By keeping the architecture simple, the protocols and software used to implement the architecture are simpler. This simplicity in turn leads to:
アーキテクチャをシンプルに保つことにより、アーキテクチャの実装に使用されるプロトコルとソフトウェアがより簡単になります。このシンプルさは次のことにつながります。
1. Faster implementation of the protocols. If there are fewer bells and whistles, then there are fewer things that need to be implemented.
1. プロトコルのより速い実装。鐘とホイッスルが少ない場合、実装する必要があるものが少なくなります。
2. More reliable implementations. With fewer components, there is less code, reducing bug counts, and fewer interactions between components that could lead to unforeseen and incorrect behavior.
2. より信頼性の高い実装。コンポーネントが少ないと、コードが少なくなり、バグ数が減少し、コンポーネント間の相互作用が少ないため、予期せぬ動作と誤った動作につながる可能性があります。
The architecture, and the protocols implementing it, should be robust. Robustness comes in many different flavors. Some considerations with regard to robustness include (but are not limited to):
アーキテクチャとそれを実装するプロトコルは、堅牢でなければなりません。堅牢性には多くの異なるフレーバーがあります。堅牢性に関するいくつかの考慮事項には、（ただし、これらに限定されない）が含まれます。
o Continued correct operation in the face of:
o に直面して正しい操作を続けます：
* Defective (even malicious) trusted routers.
* 欠陥のある（悪意のある）信頼できるルーター。
* Network failures. Whenever possible, valid alternate paths are to be found and used.
* ネットワークの障害。可能な場合はいつでも、有効な代替パスが見つかり、使用されます。
o Failures must be localized. That is, the architecture must limit the "spread" of any adverse effects of a misconfiguration or failure. Badness must not spread.
o 障害はローカライズする必要があります。つまり、アーキテクチャは、誤解または失敗の悪影響の「広がり」を制限する必要があります。悪さは広まってはなりません。
Of course, the general robustness principle of being liberal in what's accepted and conservative in what's sent must also be applied.
もちろん、受け入れられているものでリベラルであるという一般的な堅牢性の原則も、送信されたものに保守的である必要があります。
Original Editor's Note: Some of the contributors to this section have argued that robustness is an aspect of security. I have exercised editor's discretion by making it a separate section. The reason for this is that to too many people "security" means "protection from break-ins" and "authenticating and encrypting data". This requirement goes beyond those views.
オリジナルの編集者注：このセクションへの貢献者の一部は、堅牢性はセキュリティの側面であると主張しています。編集者の裁量を別のセクションにすることにより、編集者の裁量を行使しました。この理由は、「セキュリティ」が多すぎると、「侵入からの保護」および「データの認証と暗号化」を意味するためです。この要件は、これらの見解を超えています。
While it is an article of faith that IP operates over a wide variety of media (such as Ethernet, X.25, ATM, and so on), IP routing must take an agnostic view toward any "routing" or "topology" services that are offered by the medium over which IP is operating. That is, the new architecture must not be designed to integrate with any media-specific topology management or routing scheme.
IPが多種多様なメディア（イーサネット、X.25、ATMなど）で動作するのは信仰の記事ですが、IPルーティングは、「ルーティング」または「トポロジ」サービスに対して不可知論的ビューを取得する必要があります。IPが動作している媒体によって提供されます。つまり、新しいアーキテクチャは、メディア固有のトポロジ管理またはルーティングスキームと統合するように設計されてはなりません。
The routing architecture must assume, and must work over, the simplest possible media.
ルーティングアーキテクチャは、可能な限り単純なメディアを想定し、作業する必要があります。
The routing and addressing architecture can certainly make use of lower-layer information and services, when and where available, and to the extent that IP routing wishes.
ルーティングおよびアドレス指定アーキテクチャは、いつ、どこで利用可能な場合、およびIPルーティングが希望する範囲で、低層情報とサービスを確実に利用できます。
The routing architecture and protocols must not rely on other components of the Internet (such as DNS) for their correct operation. Routing is the fundamental process by which data "finds its way around the Internet" and most, if not all, of those other components rely on routing to properly forward their data. Thus, routing cannot rely on any Internet systems, services, or capabilities that in turn rely on routing. If it did, a dependency loop would result.
ルーティングアーキテクチャとプロトコルは、正しい操作のためにインターネットの他のコンポーネント（DNSなど）に依存してはなりません。ルーティングは、データが「インターネットの周りを見つける」基本的なプロセスであり、ほとんどではないにしても、他のコンポーネントのほとんどは、データを適切に転送するためにルーティングに依存しています。したがって、ルーティングは、インターネットシステム、サービス、または機能に依存することはできません。もしそうなら、依存関係ループが生じます。
The architecture, protocols, and standard implementation defaults must be such that a router installed "out of the box" with no configuration, etc., by the operators will not cause "bad things" to happen to the rest of the routing system (e.g., no dial-up customers advertising routes to 18/8!).
アーキテクチャ、プロトコル、および標準の実装のデフォルトは、オペレーターによって「構成なしで「ボックスから外れて」インストールされたルーターが、残りのルーティングシステムに「悪いこと」が発生するようにするようにする必要があります（例：、ダイヤルアップの顧客は18/8までのルートを広告しません！）。
The routing system must allow topological entities to be renumbered.
ルーティングシステムは、トポロジートンティティを変更することを許可する必要があります。
The architecture must allow topological entities to have multiple prefixes (or the equivalent under the new architecture).
このアーキテクチャにより、トポロジエンティティは複数のプレフィックス（または新しいアーキテクチャの下で同等のもの）を持たせる必要があります。
As RFC 1726[RFC1726] states:
RFC 1726 [RFC1726]が次のように述べています。
A major contributor to the Internet's success is the fact that there is no single, centralized, point of control or promulgator of policy for the entire network. This allows individual constituents of the network to tailor their own networks, environments, and policies to suit their own needs. The individual constituents must cooperate only to the degree necessary to ensure that they interoperate.
インターネットの成功への主要な貢献者は、ネットワーク全体に単一の集中化された制御ポイントまたはポリシーの公布者が存在しないという事実です。これにより、ネットワークの個々の構成要素は、独自のニーズに合わせて独自のネットワーク、環境、ポリシーを調整できます。個々の構成員は、相互操作を確認するために必要な程度にのみ協力しなければなりません。
This decentralization, called "cooperative anarchy", is still a key feature of the Internet today. The new routing architecture must retain this feature. There can be no centralized point of control or promulgator of policy for the entire Internet.
「協同組合の無秩序」と呼ばれるこの分散化は、今日でもインターネットの重要な機能です。新しいルーティングアーキテクチャは、この機能を保持する必要があります。インターネット全体のコントロールの集中ポイントやポリシーのプロマッター装置はあり得ません。
For the purposes of backward compatibility, any new routing and addressing architecture and protocols must work with IPv4 and IPv6 using the traditional "hop-by-hop" forwarding and packet-based multiplex/demultiplex models. However, the architecture need not be restricted to these models. Additional forwarding and multiplex/ demultiplex models may be added.
後方互換性の目的のために、新しいルーティングおよびアドレス指定アーキテクチャおよびプロトコルは、従来の「ホップバイホップ」転送とパケットベースのマルチプレックス/デマルトレックスモデルを使用してIPv4およびIPv6と連携する必要があります。ただし、アーキテクチャをこれらのモデルに制限する必要はありません。追加の転送と多重/ Demultiplexモデルが追加される場合があります。
The architecture should not require a particular routing algorithm family. That is to say, the architecture should be agnostic about link-state, distance-vector, or path-vector routing algorithms.
アーキテクチャには、特定のルーティングアルゴリズムファミリを必要としないでください。つまり、アーキテクチャは、リンク状態、距離ベクトル、またはパスベクトルルーティングアルゴリズムに関する不可知論者である必要があります。
Finally, the architecture must show benefits in terms of increased stability, decreased operational costs, and increased functionality and lifetime, over the current schemes. This benefit must remain even after the inevitable costs of developing and debugging the new protocols, enduring the inevitable instabilities as things get shaken out, and so on.
最後に、アーキテクチャは、現在のスキームにわたって、安定性の向上、運用コストの削減、機能性と寿命の増加という点で利益を示さなければなりません。この利益は、新しいプロトコルの開発とデバッグの避けられないコストの後でも、物事が揺れるにつれて避けられない不安定性に耐えなければなりません。
We explicitly recognize that the Internet consists of resources under control of multiple administrative entities. Each entity must be able to manage its own portion of the Internet as it sees fit. Moreover, the constraints that can be imposed on routing and addressing on the portion of the Internet under the control of one administration may not be feasibly extended to cover multiple administrations. Therefore, we recognize a natural and inevitable split between routing and addressing that is under a single administrative control and routing and addressing that involves multiple administrative entities. Moreover, while there may be multiple administrative authorities, the administrative authority boundaries may be complex and overlapping, rather than being a strict hierarchy.
インターネットは、複数の管理エンティティを管理するリソースで構成されていることを明示的に認識しています。各エンティティは、適切と思われるインターネットの独自の部分を管理できる必要があります。さらに、1つの管理の管理下にあるインターネットの一部でのルーティングとアドレス指定に課せられる制約は、複数の管理をカバーするために確実に拡張できない場合があります。したがって、複数の管理エンティティが関与する単一の管理制御とルーティングとアドレス指定の下にあるルーティングとアドレス指定の間の自然で避けられない分裂を認識します。さらに、複数の行政当局が存在する可能性がありますが、管理当局の境界は厳格な階層ではなく、複雑で重複する場合があります。
Furthermore, there may be multiple levels of administration, each with its own level of policy and control. For example, a large network might have "continental-level" administrations covering its European and Asian operations, respectively. There would also be that network's "inter-continental" administration covering the Europe-to-Asia links. Finally, there would be the "Internet" level in the administrative structure (analogous to the "exterior" concept in the current routing architecture).
さらに、それぞれが独自のレベルの政策と制御を備えた複数のレベルの投与があるかもしれません。たとえば、大規模なネットワークには、それぞれヨーロッパとアジアの事業を対象とした「大陸レベル」の管理がある可能性があります。また、ヨーロッパからアジアへのリンクをカバーするネットワークの「大陸間」政権があります。最後に、管理構造には「インターネット」レベルがあります（現在のルーティングアーキテクチャの「外部」の概念に類似）。
Thus, we believe that the administrative structure of the Internet must be extensible to many levels (more than the two provided by the current IGP/EGP split). The interior/exterior property is not absolute. The interior/exterior property of any point in the network is relative; a point on the network is interior with respect to some points on the network and exterior with respect to others.
したがって、インターネットの管理構造は、多くのレベル（現在のIGP/EGP分割によって提供される2つ以上）に拡張可能でなければならないと考えています。内部/外部プロパティは絶対的ではありません。ネットワーク内の任意のポイントの内部/外部プロパティは相対的です。ネットワーク上のポイントは、ネットワーク上のいくつかのポイントと他のポイントに関する内部です。
Administrative entities may not trust each other; some may be almost actively hostile toward each other. The architecture must accommodate these models. Furthermore, the architecture must not require any particular level of trust among administrative entities.
管理エンティティはお互いを信頼していない場合があります。一部はお互いに対してほとんど積極的に敵対的であるかもしれません。アーキテクチャはこれらのモデルに対応する必要があります。さらに、アーキテクチャは、管理エンティティ間で特定のレベルの信頼を必要としてはなりません。
The following are not required or are non-goals. This should not be taken to mean that these issues must not be addressed by a new architecture. Rather, addressing these issues or not is purely an optional matter for the architects.
以下は不要であるか、非神格です。これは、これらの問題が新しいアーキテクチャによって対処されてはならないことを意味するものではありません。むしろ、これらの問題に対処するかどうかは、建築家にとって純粋にオプションの問題です。
We believe that it is not necessary for the architecture to minimize the size of the forwarding tables (FIBs). Current memory sizes, speeds, and prices, along with processor and Application-specific Integrated Circuit (ASIC) capabilities allow forwarding tables to be very large, O(E6), and allow fast (100 M lookups/second) tables to be built with little difficulty.
アーキテクチャが転送テーブル（FIB）のサイズを最小限に抑える必要はないと考えています。現在のメモリサイズ、速度、および価格、プロセッサおよびアプリケーション固有の統合回路（ASIC）機能により、テーブルを非常に大きくすることができ、o（e6）を転送し、高速（100 mルックアップ/秒）テーブルをで構築できるようにします。少し難しい。
"Traffic engineering" is one of those terms that has become terribly overloaded. If one asks N people what traffic engineering is, one would get something like N! disjoint answers. Therefore, we elect not to require "traffic engineering", per se. Instead, we have endeavored to determine what the ultimate intent is when operators "traffic engineer" their networks and then make those capabilities an inherent part of the system.
「トラフィックエンジニアリング」は、非常に過負荷になった用語の1つです。交通工学とは何かをnに尋ねると、nのようなものを手に入れるでしょう！嫌いな答え。したがって、「交通工学」自体を要求しないことを選択します。代わりに、オペレーターがネットワークを「トラフィックエンジニア」にし、それらの機能をシステムの固有の部分にするとき、最終的な意図が何であるかを判断するよう努めました。
The new architecture is not designed explicitly to be an inter-domain multicast routing architecture. However, given the notable lack of a viable, robust, and widely deployed inter-domain multicast routing architecture, the architecture should not hinder the development and deployment of inter-domain multicast routing without an adverse effect on meeting the other requirements.
新しいアーキテクチャは、ドメイン間マルチキャストルーティングアーキテクチャとして明示的に設計されていません。ただし、実行可能で堅牢で広く展開されているドメイン間マルチキャストルーティングアーキテクチャの顕著な欠如を考えると、アーキテクチャは、他の要件を満たすことに悪影響を与えることなく、ドメイン間マルチキャストルーティングの開発と展開を妨げるものではありません。
We do note however that one respected network sage [Clark91] has said (roughly):
ただし、尊敬されているネットワークセージ[Clark91]が（大まかに）言ったことに注意してください。
When you see a bunch of engineers standing around congratulating themselves for solving some particularly ugly problem in networking, go up to them, whisper "multicast", jump back, and watch the fun begin...
ネットワーキングで特にugい問題を解決してくれたことを祝福しているエンジニアがたくさんいるのを見たら、彼らに上がり、「マルチキャスト」をささやき、ジャンプして、楽しみを見てください...
The architecture concerns itself primarily with disseminating network topology information so that routers may select paths to destinations and build appropriate forwarding tables. Quality of Service (QoS) is not a part of this function and we make no requirements with respect to QoS.
アーキテクチャは、主にネットワークトポロジ情報を広めることに関係しているため、ルーターが目的地へのパスを選択し、適切な転送テーブルを構築することができます。サービス品質（QOS）はこの関数の一部ではなく、QoSに関して要件はありません。
However, QoS is an area of great and evolving interest. It is reasonable to expect that in the not too distant future, sophisticated QoS facilities will be deployed in the Internet. Any new architecture and protocols should be developed with an eye toward these future evolutions. Extensibility mechanisms, allowing future QoS routing and signaling protocols to "piggy-back" on top of the basic routing system are desired.
ただし、QoSは非常に進化する関心の分野です。それほど遠くない将来、洗練されたQoS施設がインターネットに展開されることを期待するのは合理的です。新しいアーキテクチャとプロトコルは、これらの将来の進化に目を向けて開発する必要があります。拡張可能性メカニズムは、将来のQoSルーティングとシグナリングプロトコルを基本的なルーティングシステムの上に「ピギーバック」にすることが望まれます。
We do require the ability to assign attributes to entities and then do path generation and selection based on those attributes. Some may call this QoS.
エンティティに属性を割り当て、それらの属性に基づいてパス生成と選択を行う機能が必要です。このQosと呼ぶ人もいます。
There is no specific requirement that CIDR-style (Classless Inter-Domain Routing) IP prefix aggregation be done by the new architecture. Address allocation policies, societal pressure, and the random growth and structure of the Internet have all conspired to make prefix aggregation extraordinarily difficult, if not impossible. This means that large numbers of prefixes will be sloshing about in the routing system and that forwarding tables will grow quite big. This is a cost that we believe must be borne.
CIDRスタイル（クラスレスドメイン間ルーティング）IPプレフィックス集約が新しいアーキテクチャによって行われるという特定の要件はありません。アドレス配分ポリシー、社会的圧力、およびインターネットのランダムな成長と構造はすべて、不可能ではないにしても、プレフィックス集約を非常に困難にすることを共謀しています。これは、ルーティングシステムで多数の接頭辞がスロッシングし、転送テーブルが非常に大きくなることを意味します。これは、私たちが負担しなければならないと思われるコストです。
Nothing in this non-requirement should be interpreted as saying that prefix aggregation is explicitly prohibited. CIDR-style IP prefix aggregation might be used as a mechanism to meet other requirements, such as scaling.
この非追跡の何も、プレフィックスの集約が明示的に禁止されていると言っていると解釈されるべきではありません。CIDRスタイルのIPプレフィックス集約は、スケーリングなどの他の要件を満たすメカニズムとして使用される場合があります。
Making the system impossible to misconfigure is, we believe, not required. The checking, constraints, and controls necessary to achieve this could, we believe, prevent operators from performing necessary tasks in the face of unforeseen circumstances.
システムを不可能にすることは、必要ではないと考えています。これを達成するために必要なチェック、制約、およびコントロールは、予期せぬ状況に直面してオペレーターが必要なタスクを実行できないようにする可能性があると考えています。
However, safety is always a "good thing", and any results from research in this area should certainly be taken into consideration and, where practical, incorporated into the new routing architecture.
ただし、安全性は常に「良いこと」であり、この分野での研究の結果は確かに考慮され、実用的な場合は新しいルーティングアーキテクチャに組み込まれるべきです。
History has shown that using the routing system to perform highly dynamic load balancing among multiple more-or-less-equal paths usually ends up causing all kinds of instability, etc., in the network. Thus, we do not require such a capability.
歴史は、ルーティングシステムを使用して、複数のより等しくないパス間で非常に動的な負荷分散を実行することを示しています。通常、ネットワーク内のあらゆる種類の不安定性などを引き起こすことが示されています。したがって、そのような能力は必要ありません。
However, this is an area that is ripe for additional research, and some believe that the capability will be necessary in the future. Thus, the architecture and protocols should be "malleable" enough to allow development and deployment of dynamic load-balancing capabilities, should we ever figure out how to do it.
ただし、これは追加の研究に熟した分野であり、将来的には機能が必要になると考えている人もいます。したがって、アーキテクチャとプロトコルは、動的な負荷バランス機能の開発と展開を可能にするのに十分な「順応性」でなければなりません。
We believe that the routing system is not required to "do renumbering" of hosts and routers. That's an IP issue.
ルーティングシステムは、ホストとルーターの「変更」を行うために必要ではないと考えています。それはIPの問題です。
Of course, the routing and addressing architecture must be able to deal with renumbering when it happens.
もちろん、ルーティングとアドレス指定のアーキテクチャは、それが起こったときに買い戻しに対処できる必要があります。
In the Internet architecture, host mobility is handled on a per-host basis by a dedicated, Mobile-IP protocol [RFC3344]. Traffic destined for a mobile-host is explicitly forwarded by dedicated relay agents. Mobile-IP [RFC3344] adequately solves the host-mobility problem and we do not see a need for any additional requirements in this area. Of course, the new architecture must not impede or conflict with Mobile-IP.
インターネットアーキテクチャでは、ホストのモビリティは、専用のモバイルIPプロトコル[RFC3344]によってホストごとに処理されます。モバイルホスト用のトラフィックは、専用のリレーエージェントによって明示的に転送されます。Mobile-IP [RFC3344]は、ホストモビリティの問題を適切に解決し、この分野での追加要件が必要であるとは考えていません。もちろん、新しいアーキテクチャはモバイルIPを妨害したり矛盾したりしてはなりません。
For the purposes of development of the architecture, we assume that there is a "clean slate". Unless specified in Section 2.1, there are no explicit requirements that elements, concepts, or mechanisms of the current routing architecture be carried forward into the new one.
アーキテクチャの開発の目的のために、「きれいなスレート」があると仮定します。セクション2.1で指定されていない限り、現在のルーティングアーキテクチャの要素、概念、またはメカニズムを新しいものに繰り越す明示的な要件はありません。
The following is the result of the work done by Sub-Group B of the IRTF RRG in 2001-2002. It was originally released under the title: "Future Domain Routing Requirements" and was edited by Avri Doria and Elwyn Davies.
以下は、2001年から2002年にIRTF RRGのサブグループBによって行われた作業の結果です。もともとタイトル「Future Domain Routing Recomations」というタイトルでリリースされ、Avri DoriaとElwyn Daviesによって編集されました。
It is generally accepted that there are major shortcomings in the inter-domain routing of the Internet today and that these may result in meltdown 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.
一般に、今日のインターネット間のドメイン間ルーティングに大きな欠点があり、これらが不特定の期間内にメルトダウンをもたらす可能性があることが認められています。これらの欠点を是正するには、これらの欠点につながる正確な障害モードを結び付け、状況を改善するための最良のテクニックを特定するための広範な研究が必要です。
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プロトコルスイートに依存する根本的に変更され、ますます商業的にベースのネットワークに効率的な基盤を提供するために避けられません。
Although inter-domain routing is seen as the major source of problems, the interactions with intra-domain routing, and the constraints that confining changes to the inter-domain arena would impose, mean that we should consider the whole area of routing as an integrated system. This is done for two reasons:
ドメイン間ルーティングは問題の主要な原因と見なされていますが、ドメイン内ルーティングとの相互作用、およびドメイン間アリーナに閉じ込められる変更が課す制約は、ルーティングの領域全体を統合されたものと見なす必要があることを意味します。システム。これは2つの理由で行われます。
- Requirements should not presuppose the solution. A continued commitment to the current definitions and split between inter-domain and intra-domain routing would constitute such a presupposition. Therefore, this part of the document uses the name Future Domain Routing (FDR).
- 要件はソリューションを前提とするべきではありません。現在の定義への継続的なコミットメントとドメイン間ルーティングとドメイン内ルーティングの間で分割されると、そのような前提が構成されます。したがって、ドキュメントのこの部分では、Futureドメインルーティングという名前（FDR）を使用します。
- It is necessary to understand the degree to which inter-domain and intra-domain routing are related within today's routing architecture.
- 今日のルーティングアーキテクチャ内でドメイン間およびドメイン内ルーティングがどの程度関連しているかを理解する必要があります。
We are aware that using the term "domain routing" is already fraught with danger because of possible misinterpretation due to prior usage. The meaning of "domain routing" will be developed implicitly throughout the document, but a little advance explicit definition of the word "domain" is required, as well as some explanation on the scope of "routing".
「ドメインルーティング」という用語を使用することは、以前の使用による誤解の可能性があるため、すでに危険に満ちていることを認識しています。「ドメインルーティング」の意味はドキュメント全体で暗黙的に開発されますが、「ドメイン」という単語の明示的な定義と、「ルーティング」の範囲に関するいくつかの説明が必要です。
This document uses "domain" in a very broad sense, to mean any collection of systems or domains that come under a common authority that determines the attributes defining, and the policies controlling, that collection. The use of "domain" in this manner is very similar to the concept of region that was put forth by John Wroclawski in his Metanet model [Wroclawski95]. The idea includes the notion that certain attributes will characterize the behavior of the systems within a domain and that there will be borders between domains. The idea of domain presented here does not presuppose that two domains will have the same behavior. Nor does it presuppose anything about the hierarchical nature of domains. Finally, it does not place restrictions on the nature of the attributes that might be used to determine membership in a domain. Since today's routing domains are an example of the concept of domains in this document, there has been no attempt to create a new term.
このドキュメントでは、非常に広い意味で「ドメイン」を使用して、その収集を定義する属性と制御するポリシーを決定する共通の権限の下にあるシステムまたはドメインのコレクションを意味します。この方法での「ドメイン」の使用は、彼のメタネットモデル[wroclawski95]でジョン・ロクロウスキーによって発表された地域の概念に非常に似ています。このアイデアには、特定の属性がドメイン内のシステムの動作を特徴付け、ドメイン間に境界があるという概念が含まれています。ここで提示されたドメインのアイデアは、2つのドメインが同じ動作をすることを前提としていません。また、ドメインの階層的な性質については何も前提としていません。最後に、ドメイン内のメンバーシップを決定するために使用される可能性のある属性の性質に制限はありません。今日のルーティングドメインは、このドキュメントのドメインの概念の例であるため、新しい用語を作成する試みはありませんでした。
Current practice in routing-system design 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. Specifically, however, "routing" will be used to mean the process of discovering, interpreting, and distributing information about the logical and topological structure of the network.
ルーティングシステム設計の現在の練習は、ルーター内のコントロールプレーンと転送面の懸念を分離する必要性を強調しています。このドキュメントはこのプラクティスに従いますが、システムのあらゆる側面をカバーするために、「ルーティング」という用語をグローバルポートマントーとして使用しています。ただし、具体的には、「ルーティング」を使用して、ネットワークの論理的およびトポロジ構造に関する情報を発見、解釈、および配布するプロセスを意味します。
Throughout this section, the terms "intra-domain" and "inter-domain" will be used. These should be understood as relative terms. In all cases of domains, there will be a set of network systems that are within that domain; routing between these systems will be termed "intra-domain". In some cases there will be routing between domains, which will be termed "inter-domain". It is possible that the routing exchange between two network systems can be viewed as intra-domain from one perspective and as inter-domain from another perspective.
このセクション全体で、「ドメイン内」と「ドメイン間」という用語が使用されます。これらは相対的な用語として理解する必要があります。ドメインのすべての場合において、そのドメイン内にあるネットワークシステムのセットがあります。これらのシステム間のルーティングは、「ドメイン内」と呼ばれます。場合によっては、ドメイン間にルーティングが行われ、「ドメイン間」と呼ばれます。2つのネットワークシステム間のルーティング交換は、ある観点からドメイン内および別の観点からドメイン間と見なすことができる可能性があります。
The development of the Internet is likely to be driven by a number of changes that will affect the organization and the usage of the network, including:
インターネットの開発は、組織とネットワークの使用に影響を与える多くの変更によって推進される可能性があります。
- Ongoing evolution of the commercial relationships between (connectivity) service providers, leading to changes in the way in which peering between providers is organized and the way in which transit traffic is routed.
- （接続性）サービスプロバイダー間の商業的関係の継続的な進化は、プロバイダー間のピアリングが編成され、輸送トラフィックがルーティングされる方法の変化につながります。
- Requirements for traffic engineering within and between domains including coping with multiple paths between domains.
- ドメイン間の複数のパスへの対処を含むドメイン内およびドメイン間の交通工学の要件。
- Addition of a second IP addressing technique, in the form of IPv6.
- IPv6の形で、2番目のIPアドレス指定手法の追加。
- The use of VPNs and private address space with IPv4 and IPv6.
- IPv4とIPv6を使用したVPNとプライベートアドレススペースの使用。
- Evolution of the end-to-end principle to deal with the expanded role of the Internet, as discussed in [Blumenthal01]: this paper discusses the possibility that the range of new requirements, especially the social and techno-political ones that are being placed on the future, may compromise the Internet's original design principles. This might cause the Internet to lose some of its key features, in particular, its ability to support new and unanticipated applications. This discussion is linked to the rise of new stakeholders in the Internet, especially ISPs; new government interests; the changing motivations of the ever growing user base; and the tension between the demand for trustworthy overall operation and the inability to trust the behavior of individual users.
- [blumenthal01]で説明したように、インターネットの拡大された役割に対処するためのエンドツーエンドの原則の進化：この論文では、新しい要件、特に配置されている社会的およびテクノ政治的な要件の範囲が可能性について説明します。将来、インターネットの元の設計原則を妥協する可能性があります。これにより、インターネットはその主要な機能のいくつかを失う可能性があります。特に、予期しないアプリケーションをサポートする能力があります。この議論は、インターネット、特にISPでの新しい利害関係者の台頭に関連しています。新政府の利益;増え続けるユーザーベースの変化する動機。そして、信頼できる全体的な運用の需要と個々のユーザーの行動を信頼できないこととの間の緊張。
- Incorporation of alternative forwarding techniques such as the explicit routing (pipes) supplied by the MPLS [RFC3031] and GMPLS [RFC3471] environments.
- MPLS [RFC3031]やGMPLS [RFC3471]環境によって提供される明示的ルーティング（PIPE）などの代替転送手法の組み込み。
- Integration of additional constraints into route determination from interactions with other layers (e.g., Shared Risk Link Groups [InferenceSRLG]). This includes the concern that redundant routes should not fate-share, e.g., because they physically run in the same trench.
- 他のレイヤーとの相互作用からのルート決定への追加の制約の統合（例：共有リスクリンクグループ[推論）。これには、冗長なルートが運命をシェアするべきではないという懸念が含まれます。たとえば、それらは同じtrenchで物理的に走るからです。
- Support for alternative and multiple routing techniques that are better suited to delivering types of content organized in ways other than into IP-addressed packets.
- IPアドレスパケット以外の方法で整理された種類のコンテンツを配信するのに適した代替および複数のルーティング技術のサポート。
Philosophically, the Internet has the mission of transferring information from one place to another. Conceptually, this information is rarely organized into conveniently sized, IP-addressed packets, and the FDR needs to consider how the information (content) to be carried is identified, named, and addressed. Routing techniques can then be adapted to handle the expected types of content.
哲学的には、インターネットには、ある場所から別の場所に情報を転送するという使命があります。概念的には、この情報が便利なサイズのIPアドレスパケットに編成されることはめったにありません。FDRは、運ばれる情報（コンテンツ）がどのように識別、名前が付けられ、対処されるかを検討する必要があります。ルーティングテクニックは、予想されるタイプのコンテンツを処理するように適合させることができます。
This section attempts to answer two questions:
このセクションでは、2つの質問に答えようとします。
- What are we trying to achieve in a new architecture?
- 新しいアーキテクチャで何を達成しようとしていますか？
- Why should the Internet community care?
- なぜインターネットコミュニティはケアする必要がありますか？
There is a third question that needs to be answered as well, but that has seldom been explicitly discussed:
回答する必要がある3番目の質問もありますが、明示的に議論されることはめったにありません。
- How will we know when we have succeeded?
- 成功したときにどのようにわかりますか？
Many of today's routing problems are caused by a routing system that is not well matched to the organization and policies that it is trying to support. Our goal is to develop a routing architecture where even a domain organization that is not envisioned today can be served by a routing architecture that matches its requirements. We will know when this goal is achieved when the desired policies, rules, and organization can be mapped into the routing system in a natural, consistent, and easily understood way.
今日のルーティングの問題の多くは、サポートしようとしている組織とポリシーによく一致していないルーティングシステムによって引き起こされます。私たちの目標は、今日想定されていないドメイン組織でさえ、要件に合ったルーティングアーキテクチャが提供できるルーティングアーキテクチャを開発することです。この目標は、目的のポリシー、ルール、および組織が、自然で一貫した、簡単に理解された方法でルーティングシステムにマッピングできるときにいつ達成されるかを知ります。
Today's routing protocols only support a single data forwarding service that is typically used to deliver a best-effort service in the public Internet. On the other hand, Diffserv for example, can construct a number of different bit transport services within the network. Using some of the per-domain behaviors (PDB)s that have been discussed in the IETF, it is possible to construct services such as Virtual Wire [DiffservVW] and Assured Rate [DiffservAR].
今日のルーティングプロトコルは、一般的にパブリックインターネットで最高のエフォルトサービスを提供するために使用される単一のデータ転送サービスのみをサポートしています。一方、たとえば、DiffServは、ネットワーク内でさまざまなビット輸送サービスを構築できます。IETFで議論されているドメインごとの動作（PDB）の一部を使用して、仮想ワイヤ[diffservvw]や保証レート[diffservar]などのサービスを構築することができます。
Providers today offer rudimentary promises about traffic handling in the network, for example, delay and long-term packet loss guarantees. As time goes on, this becomes even more relevant. Communicating the service characteristics of paths in routing protocols will be necessary in the near future, and it will be necessary to be able to route packets according to their service requirements.
今日のプロバイダーは、たとえば遅延や長期のパケット損失保証など、ネットワークでの交通処理について初歩的な約束を提供しています。時間が経つにつれて、これはさらに関連性が高まります。ルーティングプロトコルにおけるパスのサービス特性を通信することは、近い将来に必要であり、サービスの要件に従ってパケットをルーティングできる必要があります。
Thus, a goal of this architecture is to allow adequate information about path service characteristics to be passed between domains and consequently, to allow the delivery of bit transport services other than the best-effort datagram connectivity service that is the current common denominator.
したがって、このアーキテクチャの目標は、パスサービスの特性に関する適切な情報をドメイン間で渡し、その結果、現在の一般的な分母であるBest-Eftort Datagram Connectivityサービス以外のビット輸送サービスの提供を許可することです。
Any proposed FDR system should scale beyond the size and performance we can foresee for the next ten years. The previous IDR proposal as implemented by BGP, has, with some massaging, held up for over ten years. In that time the Internet has grown far beyond the predictions that were implied by the original requirements.
提案されているFDRシステムは、今後10年間、予測できるサイズとパフォーマンスを超えてスケーリングする必要があります。BGPが実施した以前のIDR提案は、ある程度のマッサージで10年以上保持されています。その間、インターネットは、元の要件によって暗示された予測をはるかに超えて成長してきました。
Unfortunately, we will only know if we have succeeded in this goal if the FDR system survives beyond its design lifetime without serious massaging. Failure will be much easier to spot!
残念ながら、FDRシステムが深刻なマッサージなしに設計寿命を超えて生き残っている場合、この目標に成功したかどうかのみがわかります。失敗ははるかに簡単になります！
With the advent of circuit-based technologies (e.g., MPLS [RFC3031] and GMPLS [RFC3471]) managed by IP routers there are forwarding mechanisms other than the datagram service that need to be supported by the routing architecture.
IPルーターによって管理される回路ベースのテクノロジー（例：MPLS [RFC3031]およびGMPLS [RFC3471]）の出現により、ルーティングアーキテクチャでサポートする必要があるデータグラムサービス以外の転送メカニズムがあります。
An explicit goal of this architecture is to add support for forwarding mechanisms other then the current hop-by-hop datagram forwarding service driven by globally unique IP addresses.
このアーキテクチャの明示的な目標は、グローバルに一意のIPアドレスによって駆動される現在のホップバイホップデータグラム転送サービス以外の転送メカニズムのサポートを追加することです。
It is envisioned that an organization can support multiple services within a single network. These services can, for example, be of different quality, of different connectivity type, or of different protocols (e.g., IPv4 and IPv6). For all these services, there may be common domain topology, even though the policies controlling the routing of information might differ from service to service. Thus, a goal with this architecture is to support separation between creation of a domain (or organization) topology map and service creation.
組織は、単一のネットワーク内で複数のサービスをサポートできることが想定されています。これらのサービスは、たとえば、異なる品質、異なる接続タイプ、または異なるプロトコル（例：IPv4やIPv6）のものである可能性があります。これらすべてのサービスでは、情報のルーティングを制御するポリシーがサービスごとに異なる場合がありますが、共通のドメイントポロジがある場合があります。したがって、このアーキテクチャの目標は、ドメイン（または組織）トポロジマップとサービス作成の作成間の分離をサポートすることです。
The architecture of a router is composed of two main separable parts: control and forwarding. These components, while inter-dependent, perform functions that are largely independent of each other. Control (routing, signaling, and management) is typically done in software while forwarding typically is done with specialized ASICs or network processors.
ルーターのアーキテクチャは、制御と転送という2つの主要な分離可能な部分で構成されています。これらのコンポーネントは、相互に依存しますが、互いに大きく独立した関数を実行します。コントロール（ルーティング、シグナル、管理、および管理）は通常、ソフトウェアで行われ、通常は専門的なASICまたはネットワークプロセッサで転送されます。
The nature of an IP-based network today is that control and data protocols share the same network and forwarding regime. This may not always be the case in future networks, and we should be careful to avoid building in this sharing as an assumption in the FDR.
今日のIPベースのネットワークの性質は、コントロールとデータプロトコルが同じネットワークと転送体制を共有することです。これは、将来のネットワークでは必ずしもそうであるとは限らないため、FDRの仮定としてこの共有の構築を避けるように注意する必要があります。
A goal of this architecture is to support full separation of control and forwarding, and to consider what additional concerns might be properly considered separately (e.g., adjacency management).
このアーキテクチャの目標は、制御と転送の完全な分離をサポートし、追加の懸念が別々に適切に考慮される可能性があることを検討することです（隣接管理など）。
A number of routing paradigms have been used or researched, in addition to the conventional shortest-path-by-hop-count paradigm that is the current mainstay of the Internet. In particular, differences in underlying transport networks may mean that other kinds of routing are more relevant, and the perceived need for traffic engineering will certainly alter the routing chosen in various domains.
インターネットの現在の主力である従来の最短パスバイホップカウントパラダイムに加えて、多くのルーティングパラダイムが使用または調査されています。特に、基礎となる輸送ネットワークの違いは、他の種類のルーティングがより関連性があることを意味する場合があり、トラフィックエンジニアリングの知覚された必要性は、さまざまなドメインで選択されたルーティングを確実に変えるでしょう。
Explicitly, one of these routing paradigms should be the current routing paradigm, so that the new paradigms will inter-operate in a backward-compatible way with today's system. This will facilitate a migration strategy that avoids flag days.
明示的に、これらのルーティングパラダイムの1つは現在のルーティングパラダイムである必要があります。そのため、新しいパラダイムは今日のシステムとの後方互換性のある方法で操作します。これにより、旗の日を回避する移行戦略が容易になります。
Currently, existence of a route to a destination effectively implies that anybody who can get a packet onto the network is entitled to use that route. While there are limitations to this generalization, this is a clear invitation to denial-of-service attacks. A goal of the FDR system should be to allow traffic to be specifically linked to whole or partial routes so that a destination or link resources can be protected from unauthorized use.
現在、目的地へのルートの存在は、事実上、ネットワークにパケットを取得できる人がそのルートを使用する権利があることを意味します。この一般化には制限がありますが、これはサービス拒否攻撃への明確な招待です。FDRシステムの目標は、宛先またはリンクリソースを不正使用から保護できるように、トラフィックを全体または部分的なルートに特にリンクできるようにすることです。
Editors' Note: When sections like this one and the previous ones on quality differentiation were written, the idea of separating traffic for security or quality was considered an unqualified advantage. Today, however, in the midst of active discussions on Network Neutrality, it is clear that such issues have a crucial policy component that also needs to be understood. These, and other similar issues, are open to further research.
編集者の注：このようなセクションと品質差別化に関する以前のセクションが書かれたとき、セキュリティまたは品質のためにトラフィックを分離するという考えは、資格のない利点と見なされました。しかし、今日、ネットワークの中立性に関する積極的な議論の最中に、そのような問題にも理解する必要がある重要なポリシーコンポーネントがあることは明らかです。これらおよびその他の同様の問題は、さらなる研究に対して開かれています。
It has been shown both analytically, by Griffin, et al. (see [Griffin99]), and practically (see [RFC3345]) that BGP will not converge stably or is only meta-stable (i.e., will not re-converge in the face of a single failure) when certain types of policy constraint are applied to categories of network topology. The addition of policy to the basic distance-vector algorithm invalidates the proofs of convergence that could be applied to a policy-free implementation.
Griffin et al。によって分析的に示されています。（[griffin99]を参照）、およびBGPは安定して収束しないか、メタ安定ではない（つまり、単一の障害に直面して再評価しない）、特定のタイプのポリシーの制約がある場合、ネットワークトポロジのカテゴリに適用されます。基本的な距離ベクトルアルゴリズムにポリシーを追加すると、ポリシーのない実装に適用できる収束の証明が無効になります。
It has also been argued that global convergence may no longer be a necessary goal and that local convergence may be all that is required.
また、グローバルな収束はもはや必要な目標ではなく、ローカル収束が必要である可能性があると主張されています。
A goal of the FDR should be to achieve provable convergence of the protocols used that may involve constraining the topologies and domains subject to convergence. This will also require vetting the policies imposed to ensure that they are compatible across domain boundaries and result in a consistent policy set.
FDRの目標は、収束の対象となるトポロジーとドメインの制約を伴う可能性のある使用されるプロトコルの証明可能な収束を達成することです。また、これには、ドメインの境界を越えて互換性があり、一貫したポリシーセットになるように課されるポリシーを審査する必要があります。
Editors' Note: This requirement is very optimistic in that it implies that it is possible to get operators to cooperate even it is seen by them to be against their business practices. Though perhaps Utopian, this is a good goal.
編集者の注：この要件は、ビジネス慣行に反対することが見られるとしても、オペレーターに協力することが可能であることを意味するという点で、非常に楽観的です。おそらくユートピア人ですが、これは良い目標です。
From time to time in the history of the Internet, there have been occurrences where misconfigured routers have destroyed global connectivity.
インターネットの歴史の中で時々、誤ったルーターがグローバルな接続性を破壊したという発生がありました。
A goal of the FDR is to be more robust to configuration errors and failures. This should probably involve ensuring that the effects of misconfiguration and failure can be confined to some suitable locality of the failure or misconfiguration.
FDRの目標は、構成エラーと障害により堅牢になることです。これには、おそらく、誤解と失敗の影響が、失敗または誤解の適切な地域に限定されることを保証する必要があります。
The policy work ([rap-charter02], [snmpconf-charter02], and [policy-charter02]) that has been done at IETF provides an architecture that standardizes and simplifies management of QoS. This kind of simplicity is needed in a Future Domain Routing architecture and its protocols.
IETFで行われたポリシー作業（[RAP-Charter02]、[SnmpConf-Charter02]、および[Policy-Charter02]）は、QoSの管理を標準化および簡素化するアーキテクチャを提供します。この種のシンプルさは、将来のドメインルーティングアーキテクチャとそのプロトコルで必要です。
A goal of this architecture is to make configuration and management of inter-domain routing as simple as possible.
このアーキテクチャの目標は、ドメイン間ルーティングの構成と管理を可能な限り簡単にすることです。
Editors' Note: Snmpconf and rap are the hopes of the past. Today, configuration and policy hope is focused on netconf [netconf-charter].
編集者注：SNMPCONFとRAPは過去の希望です。今日、構成とポリシーの希望は、NetConf [NetConf-Charter]に焦点を当てています。
RFC 1126 outlined a set of requirements that were used to guide the development of BGP. While the network has changed in the years since 1989, many of the same requirements remain. A future domain routing solution has to support, as its base requirement, the level of function that is available today. A detailed discussion of RFC 1126 and its requirements can be found in [RFC5773]. Those requirements, while specifically spelled out in that document, are subsumed by the requirements in this document.
RFC 1126は、BGPの開発を導くために使用された一連の要件を概説しました。1989年以来、ネットワークは数年で変化していますが、同じ要件の多くが残っています。将来のドメインルーティングソリューションは、基本要件として、今日利用可能な機能のレベルをサポートする必要があります。RFC 1126とその要件の詳細な議論は、[RFC5773]に記載されています。これらの要件は、そのドキュメントで具体的に説明されていますが、このドキュメントの要件に包まれています。
This section considers the requirements imposed by the target audience of the FDR both in terms of organizations that might own networks that would use FDR, and the human users who will have to interact with the FDR.
このセクションでは、FDRを使用するネットワークを所有する可能性のある組織と、FDRと対話しなければならない人間ユーザーの両方の観点から、FDRのターゲットオーディエンスが課した要件を検討します。
The organizations that own networks connected to the Internet have become much more diverse since RFC 1126 [RFC1126] was published. In particular, major parts of the network are now owned by commercial service provider organizations in the business of making profits from carrying data traffic.
インターネットに接続されているネットワークを所有する組織は、RFC 1126 [RFC1126]が公開されて以来、はるかに多様化されています。特に、ネットワークの主要部分は、現在、データトラフィックを運ぶことで利益を上げるビジネスの商業サービスプロバイダー組織によって所有されています。
The routing system must take into account the commercial service provider's need for secrecy and security, as well as allowing them to organize their business as flexibly as possible.
ルーティングシステムは、商業サービスプロバイダーが秘密とセキュリティの必要性を考慮し、可能な限り柔軟にビジネスを組織できるようにする必要があります。
Service providers will often wish to conceal the details of the network from other connected networks. So far as is possible, the routing system should not require the service providers to expose more details of the topology and capability of their networks than is strictly necessary.
サービスプロバイダーは、多くの場合、他の接続されたネットワークからネットワークの詳細を隠したいと考えています。可能な限り、ルーティングシステムは、サービスプロバイダーが、厳密に必要であるよりも、ネットワークのトポロジと能力の詳細を公開することを要求するべきではありません。
Many service providers will offer contracts to their customers in the form of Service Level Agreements (SLAs). The routing system must allow the providers to support these SLAs through traffic engineering and load balancing as well as multi-homing, providing the degree of resilience and robustness that is needed.
多くのサービスプロバイダーは、サービスレベル契約（SLA）の形で顧客に契約を提供します。ルーティングシステムは、プロバイダーが交通工学と負荷分散、マルチホミングを通じてこれらのSLAをサポートし、必要な回復力と堅牢性を提供する必要があります。
Service providers can be categorized as:
サービスプロバイダーは、次のように分類できます。
- Global Service Providers (GSPs) whose networks have a global reach. GSPs may, and usually will, wish to constrain traffic between their customers to run entirely on their networks. GSPs will interchange traffic at multiple peering points with other GSPs, and they will need extensive policy-based controls to control the interchange of traffic. Peering may be through the use of dedicated private lines between the partners or, increasingly, through Internet Exchange Points.
- ネットワークがグローバルなリーチを持っているグローバルサービスプロバイダー（GSP）。GSPは、顧客間のトラフィックを制約して、ネットワークで完全に実行する場合があります。GSPは、他のGSPと複数のピアリングポイントでトラフィックを交換し、トラフィックの交換を制御するために広範なポリシーベースの制御が必要になります。ピアリングは、パートナー間の専用のプライベートラインを使用すること、またはますますインターネット交換ポイントを通じて使用される場合があります。
- National, or regional, Service Providers (NSPs) that are similar to GSPs but typically cover one country. NSPs may operate as a federation that provides similar reach to a GSP and may wish to be able to steer traffic preferentially to other federation members to achieve global reach.
- GSPに似ているが、通常1つの国をカバーする国、または地域のサービスプロバイダー（NSP）。NSPは、GSPに同様のリーチを提供する連邦として動作する場合があり、グローバルなリーチを達成するために他のフェデレーションメンバーにトラフィックを優先的に導くことができる場合があります。
- Local Internet Service Providers (ISPs) operate regionally. They will typically purchase transit capacity from NSPs or GSPs to provide global connectivity, but they may also peer with neighboring, and sometimes distant, ISPs.
- ローカルインターネットサービスプロバイダー（ISP）は地域で動作します。彼らは通常、NSPまたはGSPから輸送容量を購入してグローバルな接続を提供しますが、隣接する、時には遠いISPと覗き込むこともあります。
The routing system should be sufficiently flexible to accommodate the continually changing business relationships of the providers and the various levels of trustworthiness that they apply to customers and partners.
ルーティングシステムは、プロバイダーの継続的に変化するビジネス関係と、顧客やパートナーに適用するさまざまなレベルの信頼性に対応するのに十分な柔軟性が必要です。
Service providers will need to be involved in accounting for Internet usage and monitoring the traffic. They may be involved in government action to tax the usage of the Internet, enforce social mores and intellectual property rules, or apply surveillance to the traffic to detect or prevent crime.
サービスプロバイダーは、インターネットの使用とトラフィックの監視の会計に関与する必要があります。彼らは、インターネットの使用に課税したり、社会的慣習と知的財産規則を施行したり、犯罪を検出または防止するためのトラフィックに監視を適用するための政府の行動に関与している可能性があります。
The leaves of the network domain graph are in many cases networks supporting a single enterprise. Such networks cover an enormous range of complexity. Some multi-national companies own networks that rival the complexity and reach of a GSP, whereas many fall into the Small Office-Home Office (SOHO) category. The routing system should allow simple and robust configuration and operation for the SOHO category, while effectively supporting the larger enterprise.
ネットワークドメイングラフの葉は、多くの場合、単一のエンタープライズをサポートするネットワークです。このようなネットワークは、膨大な範囲の複雑さをカバーしています。一部の多国籍企業は、GSPの複雑さと範囲に匹敵するネットワークを所有していますが、多くは小さなオフィスホームオフィス（SOHO）カテゴリに分類されています。ルーティングシステムは、SOHOカテゴリのシンプルで堅牢な構成と操作を可能にしながら、大規模な企業を効果的にサポートする必要があります。
Enterprises are particularly likely to lack the capability to configure and manage a complex routing system, and every effort should be made to provide simple configuration and operation for such networks.
企業は、複雑なルーティングシステムを構成および管理する機能が特に不足している可能性が高く、そのようなネットワークに簡単な構成と操作を提供するためにあらゆる努力を払う必要があります。
Enterprises will also need to be able to change their service provider with ease. While this is predominantly a naming and addressing issue, the routing system must be able to support seamless changeover; for example, if the changeover requires a change of address prefix, the routing system must be able to cope with a period when both sets of addresses are in use.
また、企業はサービスプロバイダーを簡単に変更できる必要があります。これは主に命名と対処の問題ですが、ルーティングシステムはシームレスな切り替えをサポートできる必要があります。たとえば、切り替えにアドレスプレフィックスの変更が必要な場合、ルーティングシステムは、両方のアドレスセットが使用されている期間に対処できる必要があります。
Enterprises will wish to be able to multi-home to one or more providers as one possible means of enhancing the resilience of their network.
企業は、ネットワークの回復力を高めるための1つの可能な手段として、1つ以上のプロバイダーにマルチホームできるようにすることを望んでいます。
Enterprises will also frequently need to control the trust that they place both in workers and external connections through firewalls and similar mid-boxes placed at their external connections.
Increasingly domestic, i.e., non-business home, networks are likely to be 'always on' and will resemble SOHO enterprises networks with no special requirements on the routing system.
ますます国内、つまり、非ビジネスホームであるネットワークは「常にオン」になる可能性が高く、ルーティングシステムに特別な要件がないSoho Enterprisesネットワークに似ています。
The routing system must also continue to support dial-up users.
ルーティングシステムは、ダイヤルアップユーザーも引き続きサポートする必要があります。
Peering of service providers, academic networks, and larger enterprises is happening increasingly at specific Internet Exchange Points where many networks are linked together in a relatively small physical area. The resources of the exchange may be owned by a trusted third party or owned jointly by the connecting networks. The routing systems should support such exchange points without requiring the exchange point to either operate as a superior entity with every connected network logically inferior to it or by requiring the exchange point to be a member of one (or all) connected networks. The connecting networks have to delegate a certain amount of trust to the exchange point operator.
Content providers are at one level a special class of enterprise, but the desire to deliver content efficiently means that a content provider may provide multiple replicated origin servers or caches across a network. These may also be provided by a separate content delivery service. The routing system should facilitate delivering content from the most efficient location.
コンテンツプロバイダーは1つのレベルで特別なクラスのエンタープライズですが、コンテンツを効率的に提供したいという要望は、コンテンツプロバイダーがネットワーク全体で複数の複製されたオリジンサーバーまたはキャッシュを提供できることを意味します。これらは、個別のコンテンツ配信サービスによっても提供される場合があります。ルーティングシステムは、最も効率的な場所からコンテンツの配信を容易にする必要があります。
This section covers the most important human users of the FDR and their expected interactions with the system.
このセクションでは、FDRの最も重要な人間ユーザーと、システムとの予想される相互作用について説明します。
The routing system must continue to deliver the current global connectivity service (i.e., any unique address to any other unique address, subject to policy constraints) that has always been the basic aim of the Internet.
ルーティングシステムは、常にインターネットの基本的な目的であった現在のグローバル接続サービス（つまり、ポリシーの制約の対象となる他の一意のアドレスへの一意のアドレス）を引き続き提供する必要があります。
End user applications should be able to request, or have requested on their behalf by agents and policy mechanisms, end-to-end communication services with QoS characteristics different from the best-effort service that is the foundation of today's Internet. It should be possible to request both a single service channel and a bundle of service channels delivered as a single entity.
エンドユーザーアプリケーションは、今日のインターネットの基礎であるベストエフォルトサービスとは異なるQOS特性を持つエンドツーエンドのコミュニケーションサービスを使用して、エージェントとポリシーメカニズムによって要求されるか、リクエストすることができるはずです。単一のサービスチャネルと単一のエンティティとして配信されるサービスチャネルのバンドルの両方を要求することができるはずです。
The routing system should allow network planners to plan and implement a network that can be proved to be stable and will meet their traffic engineering requirements.
ルーティングシステムにより、ネットワークプランナーは、安定していることが証明され、トラフィックエンジニアリングの要件を満たすことができるネットワークを計画および実装できるようにする必要があります。
The routing system should, so far as is possible, be simple to configure, operate and troubleshoot, behave in a predictable and stable fashion, and deliver appropriate statistics and events to allow the network to be managed and upgraded in an efficient and timely fashion.
ルーティングシステムは、可能な限り、簡単に構成、操作、トラブルシューティング、予測可能で安定した方法で動作し、適切な統計とイベントを提供して、ネットワークを効率的かつタイムリーな方法で管理およびアップグレードできるようにする必要があります。
The routing system must support mobile end users. It is clear that mobility is becoming a predominant mode for network access.
ルーティングシステムは、モバイルエンドユーザーをサポートする必要があります。モビリティがネットワークアクセスの主要なモードになっていることは明らかです。
While many of the requirements to which the protocol must respond are technical, some aren't. These mandated constraints are those that are determined by conditions of the world around us. Understanding these requirements requires an analysis of the world in which these systems will be deployed. The constraints include those that are determined by:
プロトコルが応答しなければならない要件の多くは技術的ですが、一部はそうではありません。これらの義務付けられた制約は、私たちの周りの世界の条件によって決定される制約です。これらの要件を理解するには、これらのシステムが展開される世界の分析が必要です。制約には、以下によって決定される制約が含まれます。
- environmental factors,
- 環境要因、
- geography,
- 地理、
- political boundaries and considerations, and
- 政治的境界と考慮事項、そして
- technological factors such as the prevalence of different levels of technology in the developed world compared to those in the developing or undeveloped world.
- 発達中または未開発の世界のものと比較して、先進国のさまざまなレベルの技術の有病率などの技術的要因。
The graph of the Internet network, with routers and other control boxes as the nodes and communication links as the edges, is today partitioned administratively into a large number of disjoint domains.
ルーターとその他のコントロールボックスをノードとエッジとしてリンクするインターネットネットワークのグラフは、今日、管理的に多数のばらばらのドメインに分割されています。
A common administration may have responsibility for one or more domains that may or may not be adjacent in the graph.
一般的な管理は、グラフに隣接する場合と隣接していない場合がある1つ以上のドメインに対して責任を負う場合があります。
Commercial and policy constraints affecting the routing system will typically be exercised at the boundaries of these domains where traffic is exchanged between the domains.
ルーティングシステムに影響を与える商業およびポリシーの制約は、通常、ドメイン間でトラフィックが交換されるこれらのドメインの境界で行使されます。
The perceived need for commercial confidentiality will seek to minimize the control information transferred across these boundaries, leading to requirements for aggregated information, abstracted maps of connectivity exported from domains, and mistrust of supplied information.
商業的機密性の認識された必要性は、これらの境界を越えて転送される制御情報を最小限に抑えようとするため、集約された情報の要件、ドメインからエクスポートされる接続のマップの抽象化されたマップ、および提供された情報の不信感につながります。
The perceived desire for anonymity may require the use of zero-knowledge security protocols to allow users to access resources without exposing their identity.
匿名に対する知覚された欲求は、ユーザーがアイデンティティを公開せずにリソースにアクセスできるようにするために、ゼロ知識セキュリティプロトコルを使用する必要がある場合があります。
The requirements should provide the ability for groups of peering domains to be treated as a complex domain. These complex domains could have a common administrative policy.
要件は、ピアリングドメインのグループが複雑なドメインとして扱われる能力を提供する必要があります。これらの複雑なドメインには、共通の管理ポリシーがある可能性があります。
The diverse Layer 2 networks, over which the Layer 3 routing system is implemented, have typically been operated totally independently from the Layer 3 network and often with their own routing mechanisms. Consideration needs to be given to the desirable degree and nature of interchange of information between the layers. In particular, the need for guaranteed robustness through diverse routing layers implies knowledge of the underlying networks.
レイヤー3ルーティングシステムが実装されている多様なレイヤー2ネットワークは、通常、レイヤー3ネットワークから完全に独立して動作し、しばしば独自のルーティングメカニズムを備えています。レイヤー間の情報の交換の望ましい程度と性質に考慮する必要があります。特に、多様なルーティングレイヤーを介して保証された堅牢性の必要性は、基礎となるネットワークの知識を意味します。
Mobile access networks may also impose extra requirements on Layer 3 routing.
モバイルアクセスネットワークは、レイヤー3ルーティングに追加の要件を課すこともあります。
The routing system operates at Layer 3 in the network. To achieve robustness and resilience at this layer requires that, where multiple diverse routes are employed as part of delivering the resilience, the routing system at Layer 3 needs to be assured that the Layer 2 and lower routes are really diverse. The "diamond problem" is the simplest form of this problem -- a Layer 3 provider attempting to provide diversity buys Layer 2 services from two separate providers who in turn buy Layer 1 services from the same provider:
ルーティングシステムは、ネットワークのレイヤー3で動作します。このレイヤーで堅牢性と回復力を実現するには、レジリエンスを提供する一部として複数の多様なルートが使用される場合、レイヤー3のルーティングシステムは、レイヤー2以下のルートが本当に多様であることを保証する必要があります。「ダイヤモンドの問題」は、この問題の最も単純な形式です。レイヤー3プロバイダーは、ダイバーシティを提供しようとする2つの別々のプロバイダーからレイヤー2サービスを購入します。
Layer 3 service
/ \
/ \
Layer 2 Layer 2
Provider A Provider B
\ /
\ /
Layer 1 Provider
Now, when the backhoe cuts the trench, the Layer 3 provider has no resilience unless he had taken special steps to verify that the trench wasn't common. The routing system should facilitate avoidance of this kind of trap.
さて、バックホーがtrenchを切ると、レイヤー3プロバイダーは、トレンチが一般的ではないことを確認するために特別な措置を講じていない限り、回復力がありません。ルーティングシステムは、この種のトラップの回避を容易にする必要があります。
Some work is going on to understand the sort of problems that stem from this requirement, such as the work on Shared Risk Link Groups [InferenceSRLG]. Unfortunately, the full generality of the problem requires diversity be maintained over time between an arbitrarily large set of mutually distrustful providers. For some cases, it may be sufficient for diversity to be checked at provisioning or route instantiation time, but this remains a hard problem requiring research work.
共有リスクリンクグループ[推論Rllg]の作業など、この要件に起因する種類の問題を理解するために、一部の作業が進行中です。残念ながら、問題の完全な一般性には、相互に不信のあるプロバイダーの任意に大きなセットの間で、時間の経過とともに多様性を維持する必要があります。場合によっては、プロビジョニングまたはルートインスタンスタイムで多様性をチェックするだけで十分かもしれませんが、これは研究作業を必要とする難しい問題のままです。
There is a full range of opinion on this subject. An informal survey indicates that the range varies from 2 to 6 years. And while there are those, possibly outliers, who think there is no need for a new routing architecture as well as those who think a new architecture was needed years ago, the median seems to lie at around 4 years. As in all projections of the future, this is not provable at this time.
この主題については、あらゆる意見があります。非公式の調査では、範囲が2〜6年まで変化することが示されています。そして、おそらく外れ値は、新しいルーティングアーキテクチャを必要としないと考えているものと、何年も前に新しいアーキテクチャが必要だったと思う人がいますが、中央値は約4年間にあるようです。将来のすべての予測のように、これは現時点では証明されていません。
Editors' Note: The paragraph above was written in 2002, yet could be written without change in 2006. As with many technical predictions and schedules, the horizon has remained fixed through this interval.
編集者注：上記の段落は2002年に書かれていましたが、2006年には変更なしで書かれています。多くの技術的な予測やスケジュールと同様に、地平線はこの間隔を通して固定されたままです。
In projecting the requirements for the Future Domain Routing, a number of assumptions have been made. The requirements set out should be consistent with these assumptions, but there are doubtless a number of other assumptions that are not explicitly articulated here: 1. The number of hosts today is somewhere in the area of 100 million. With dial-in, NATs, and the universal deployment of IPv6, this is likely to become up to 500 million users (see [CIDR]). In a number of years, with wireless accesses and different appliances attaching to the Internet, we are likely to see a couple of billion (10^9) "users" on the Internet. The number of globally addressable hosts is very much dependent on how common NATs will be in the future.
将来のドメインルーティングの要件を予測する際に、多くの仮定が行われました。設定されている要件は、これらの仮定と一致する必要がありますが、ここで明示的に明確に表現されていない他の多くの仮定が間違いなくあります。1。今日のホストの数は1億の地域のどこかにあります。ダイヤルイン、NAT、およびIPv6のユニバーサル展開により、これは最大5億ユーザーになる可能性があります（[CIDR]を参照）。何年もの間、ワイヤレスアクセスとさまざまなアプライアンスがインターネットに接続されているため、インターネット上で数十億（10^9）の「ユーザー」が表示される可能性があります。グローバルにアドレス指定可能なホストの数は、将来のNATがどのように一般的になるかに大きく依存しています。
2. NATs, firewalls, and other middle-boxes exist, and we cannot assume that they will cease being a presence in the networks.
2. NAT、ファイアウォール、その他の中間ボックスが存在し、ネットワークでの存在感を止めるとは思いません。
3. The number of operators in the Internet will probably not grow very much, as there is a likelihood that operators will tend to merge. However, as Internet-connectivity expands to new countries, new operators will emerge and then merge again.
3. インターネット内のオペレーターの数は、おそらくあまり成長しないでしょう。なぜなら、オペレーターが合併する傾向がある可能性があるからです。ただし、インターネット接続性が新しい国に拡大すると、新しいオペレーターが出現し、再び融合します。
4. At the beginning of 2002, there are around 12000 registered ASs. With current use of ASs (e.g., multi-homing) the number of ASs could be expected to grow to 25000 in about 10 years [Broido02]. This is down from a previously reported growth rate of 51% per year [RFC3221]. Future growth rates are difficult to predict.
4. 2002年の初めには、約12000件の登録されたお尻があります。現在のASS（たとえば、マルチホミング）を使用すると、約10年でASSの数が25000に成長すると予想されます[Broido02]。これは、以前に報告された年間51％の成長率から減少しています[RFC3221]。将来の成長率を予測することは困難です。
Editors' Note: In the routing report table of August 2006, the total number of ASs present in the Internet Routing Table was 23000. In 4 years, this is substantial progress on the prediction of 25000 ASs. Also, there are significantly more ASs registered than are visibly active, i.e., in excess of 42000 in mid-2006. It is possible, however, that many are being used internally.
編集者注：2006年8月のルーティングレポート表では、インターネットルーティングテーブルに存在するASSの総数は23000でした。4年後、これは25000 ASSの予測の大きな進歩です。また、2006年半ばには、目に見えてアクティブ、つまり42000を超えるASSが登録されているよりも大幅に多くのASSがあります。ただし、多くの人が内部で使用されている可能性があります。
5. In contrast to the number of operators, the number of domains is likely to grow significantly. Today, each operator has different domains within an AS, but this also shows in SLAs and policies internal to the operator. Making this globally visible would create a number of domains; 10-100 times the number of ASs, i.e., between 100,000 and 1,000,000.
5. オペレーターの数とは対照的に、ドメインの数は大幅に増加する可能性があります。今日、各オペレーターはAS内に異なるドメインを持っていますが、これはオペレーターの内部のSLAとポリシーにも表示されます。これをグローバルに見えると、多くのドメインが作成されます。10〜100倍のASの数、つまり100,000〜1,000,000の間。
6. With more and more capacity at the edge of the network, the IP network will expand. Today, there are operators with several thousands of routers, but this is likely to be increased. Some domains will probably contain tens of thousands of routers.
6. ネットワークの端にますます多くの容量があるため、IPネットワークが拡大します。今日、数千のルーターを備えたオペレーターがいますが、これは増加する可能性があります。一部のドメインには、おそらく数万のルーターが含まれます。
7. The speed of connections in the (fixed) access will technically be (almost) unconstrained. However, the cost for the links will not be negligible so that the apparent speed will be effectively bounded. Within a number of years, some will have multi-gigabit speed in the access.
7. （固定）アクセスの接続の速度は、技術的には（ほぼ）制約されません。ただし、リンクのコストは無視できないため、見かけの速度が効果的に境界線になります。何年も以内に、アクセスにマルチギガビット速度がある人もいます。
8. At the same time, the bandwidth of wireless access still has a strict upper-bound. Within the foreseeable future each user will have only a tiny amount of resources available compared to fixed accesses (10 kbps to 2 Mbps for a Universal Mobile Telecommunications System (UMTS) with only a few achieving the higher figure as the bandwidth is shared between the active users in a cell and only small cells can actually reach this speed, but 11 Mbps or more for wireless LAN connections). There may also be requirements for effective use of bandwidth as low as 2.4 Kbps or lower, in some applications.
8. 同時に、ワイヤレスアクセスの帯域幅はまだ厳格な上部にあります。近い将来、各ユーザーは、固定アクセス（ユニバーサルモバイルテレコミュニケーションシステム（UMTS）の固定アクセス（10 kbpsから2 Mbps）と比較して利用可能なリソースをご利用いただけます。セル内のユーザーと小さなセルのみが実際にこの速度に達することができますが、ワイヤレスLAN接続の場合は11 Mbps以上です）。一部のアプリケーションでは、2.4 kbps以下の低い帯域幅を効果的に使用するための要件も存在する場合があります。
9. Assumptions 7 and 8 taken together suggest a minimum span of bandwidth between 2.4 kbps to 10 Gbps.
9. 1つの仮定7と8が一緒になっていることは、2.4 kbpsから10 gbpsの間の帯域幅の最小スパンを示唆しています。
10. The speed in the backbone has grown rapidly, and there is no evidence that the growth will stop in the coming years. Terabit-speed is likely to be the minimum backbone speed in a couple of years. The range of bandwidths that need to be represented will require consideration on how to represent the values in the protocols.
10. バックボーンの速度は急速に成長しており、今後数年間で成長が止まるという証拠はありません。Terabit-Speedは、数年で最小のバックボーン速度になる可能性があります。表現する必要がある帯域幅の範囲は、プロトコル内の値を表す方法を考慮する必要があります。
11. There have been discussions as to whether Moore's Law will continue to hold for processor speed. If Moore's Law does not hold, then communication circuits might play a more important role in the future. Also, optical routing is based on circuit technology, which is the main reason for taking "circuits" into account when designing an FDR.
11. ムーアの法律がプロセッサの速度のために引き続き保持されるかどうかについて議論がありました。ムーアの法律が保持されない場合、通信回路は将来より重要な役割を果たす可能性があります。また、光学ルーティングは回路技術に基づいています。これは、FDRを設計する際に「回路」を考慮に入れる主な理由です。
12. However, the datagram model still remains the fundamental model for the Internet.
12. ただし、データグラムモデルは依然としてインターネットの基本モデルのままです。
13. The number of peering points in the network is likely to grow, as multi-homing becomes important. Also, traffic will become more locally distributed, which will drive the demand for local peering.
13. マルチホーミングが重要になるにつれて、ネットワーク内のピアリングポイントの数が増加する可能性があります。また、トラフィックはよりローカルに分散され、地元の覗き見の需要を促進します。
Editors' Note: On the other hand, peer-to-peer networking may shift the balance in demand for local peering.
編集者の注：一方、ピアツーピアネットワーキングは、地元のピアリングの需要のバランスを変える可能性があります。
14. The FDR will achieve the same degree of ubiquity as the current Internet and IP routing.
14. FDRは、現在のインターネットおよびIPルーティングと同じ程度の普及を達成します。
This section includes a detailed discussion of new requirements for a Future Domain Routing architecture. The nth requirement carries the label "R(n)". As discussed in Section 3.2.3.12, a new architecture must build upon the requirements of the past routing framework and must not reduce the functionality of the network. A discussion and analysis of the RFC 1126 requirements can be found in [RFC5773].
このセクションには、将来のドメインルーティングアーキテクチャの新しい要件に関する詳細な説明が含まれています。n番目の要件には、ラベル「r（n）」が含まれています。セクション3.2.3.12で説明したように、新しいアーキテクチャは、過去のルーティングフレームワークの要件に基づいて構築する必要があり、ネットワークの機能を低下させてはなりません。RFC 1126要件の議論と分析は、[RFC5773]に記載されています。
R(1) Routers must be able to acquire and hold sufficient information on the underlying topology of the domain to allow the establishment of routes on that topology.
R（1）ルーターは、ドメインの基礎となるトポロジに関する十分な情報を取得して保持して、そのトポロジにルートを確立できるようにする必要があります。
R(2) Routers must have the ability to control the establishment of routes on the underlying topology.
R（2）ルーターには、基礎となるトポロジのルートの確立を制御する能力が必要です。
R(3) Routers must be able, where appropriate, to control Sub-IP mechanisms to support the establishment of routes.
R（3）ルーターは、必要に応じて、ルートの確立をサポートするためにサブIPメカニズムを制御することができなければなりません。
The OSI Inter-Domain Routing Protocol (IDRP) [ISO10747] allowed a collection of topologically related domains to be replaced by an aggregate domain object, in a similar way to the Nimrod [Chiappa02] domain hierarchies. This allowed a route to be more compactly represented by a single collection instead of a sequence of individual domains.
OSIインタードメインルーティングプロトコル（IDRP）[ISO10747]により、トポロジカルに関連するドメインのコレクションを、Nimrod [Chiappa02]ドメイン階層と同様の方法で、集計ドメインオブジェクトに置き換えることができました。これにより、個々のドメインのシーケンスではなく、単一のコレクションでルートをよりコンパクトに表現することができました。
R(4) Routers must, where appropriate, be able to construct abstractions of the topology that represent an aggregation of the topological features of some area of the topology.
R（4）ルーターは、必要に応じて、トポロジーの一部の領域のトポロジー特徴の集約を表すトポロジーの抽象化を構築できなければなりません。
The same topology information needs to provide the more flexible spectrum of path selection methods that we might expect to find in a future Internet, including distributed techniques such as hop-by-hop, shortest path, local optimization constraint-based, class of service, source address routing, and destination address routing, as well as the centralized, global optimization constraint-based "traffic engineering" type. Allowing different path selection techniques will produce a much more predictable and comprehensible result than the "clever tricks" that are currently needed to achieve the same results. Traffic engineering functions need to be combined.
同じトポロジー情報は、ホップバイホップ、最短パス、ローカル最適化制約ベース、サービスのクラスなどの分散技術を含む、将来のインターネットで見つかる可能性のあるより柔軟なパス選択方法を提供する必要があります。ソースアドレスルーティング、および宛先アドレスルーティング、および集中化されたグローバルな最適化制約ベースの「トラフィックエンジニアリング」タイプ。異なるパス選択技術を許可すると、同じ結果を達成するために現在必要な「巧妙なトリック」よりもはるかに予測可能で理解できる結果が得られます。交通工学機能を組み合わせる必要があります。
R(5) Routers must be capable of supporting a small number of different path selection algorithms.
R（5）ルーターは、少数の異なるパス選択アルゴリズムをサポートできる必要があります。
R(6) The controlling network may be logically separate from the controlled network.
R（6）制御ネットワークは、制御されたネットワークから論理的に分離される場合があります。
The two functional "planes" may physically reside in the same nodes and share the same links, but this is not the only possibility, and other options may sometimes be necessary. An example is a pure circuit switch (that cannot see individual IP packets) combined with an external controller. Another example may be multiple links between two routers, where all the links are used for data forwarding but only one is used for carrying the routing session.
2つの機能的な「平面」は物理的に同じノードに存在し、同じリンクを共有する場合がありますが、これが唯一の可能性ではなく、他のオプションが必要になる場合があります。例は、外部コントローラーと組み合わせた純粋な回路スイッチ（個々のIPパケットが表示されない）です。別の例は、2つのルーター間の複数のリンクである場合があります。ここでは、すべてのリンクがデータ転送に使用されますが、ルーティングセッションを運ぶために使用されるのは1つだけです。
R(7) Relevant changes in the state of the network, including modifications to the topology and changes in the values of dynamic capabilities, must be distributed to every entity in the network that needs them, in a reliable and trusted way, at the earliest appropriate time after the changes have occurred.
R（7）トポロジの変更や動的能力の値の変化を含む、ネットワークの状態の関連する変更は、信頼できる信頼できる方法で、最も早く、それらを必要とするネットワーク内のすべてのエンティティに分散する必要があります。変更が発生した後の適切な時間。
R(8) Information must not be distributed outside areas where it is needed, or believed to be needed, for the operation of the routing system.
R（8）ルーティングシステムの操作には、情報が必要である、または必要であると考えられている領域の外に情報を配布してはなりません。
R(9) Information must be distributed in such a way that it minimizes the load on the network, consistent with the required response time of the network to changes.
R（9）情報は、ネットワークの負荷を最小限に抑えるように配布する必要があり、ネットワークの必要な応答時間と一致して変更されます。
R(10) The router must be able to acquire and store additional static and dynamic information that relates to the capabilities of the topology and its component nodes and links and that can subsequently be used by path selection methods.
R（10）ルーターは、トポロジとそのコンポーネントノードとリンクの機能に関連する追加の静的および動的情報を取得および保存できる必要があり、その後パス選択方法で使用できます。
The inter-domain routing system must be able to advertise more kinds of information than just connectivity and domain paths.
ドメイン間ルーティングシステムは、接続パスやドメインパスよりも多くの情報を宣伝できる必要があります。
R(11) The routing system must support service specifications, e.g., the Service Level Specifications (SLSs) developed by the Differentiated Services working group [RFC3260].
R（11）ルーティングシステムは、分化したサービスワーキンググループ[RFC3260]によって開発されたサービスレベル仕様（SLS）などのサービス仕様をサポートする必要があります。
Careful attention should be paid to ensuring that the distribution of additional information with path advertisements remains scalable as domains and the Internet get larger, more numerous, and more diversified.
ドメインとインターネットがより大きく、より多く、より多様化するにつれて、パス広告を使用した追加情報の配布がスケーラブルなままであることを保証するために慎重に注意する必要があります。
R(12) The distribution mechanism used for distributing network state information must be scalable with respect to the expected size of domains and the volume and rate of change of dynamic state that can be expected.
R（12）ネットワーク状態情報の配布に使用される分布メカニズムは、予想されるドメインのサイズと、予想される動的状態の変化の量と速度に関してスケーラブルでなければなりません。
The combination of R(9) and R(12) may result in a compromise between the responsiveness of the network to change and the overhead of distributing change notifications. Attempts to respond to very rapid changes may damage the stability of the routing system.
r（9）とr（12）の組み合わせにより、変更するネットワークの応答性と、変化通知の分布のオーバーヘッドとの間に妥協が発生する可能性があります。非常に急速な変化に対応しようとすると、ルーティングシステムの安定性が損なわれる可能性があります。
Possible examples of additional capability information that might be carried include:
運ばれる可能性のある追加の機能情報の可能な例は次のとおりです。
- QoS information
- QoS情報
To allow an ISP to sell predictable end-to-end QoS service to any destination, the routing system should have information about the end-to-end QoS. This means that:
ISPが予測可能なエンドツーエンドのQoSサービスを任意の宛先に販売できるようにするには、ルーティングシステムにエンドツーエンドQosに関する情報が必要です。この意味は：
R(13) The routing system must be able to support different paths for different services.
R（13）ルーティングシステムは、さまざまなサービスのさまざまなパスをサポートできる必要があります。
R(14) The routing system must be able to forward traffic on the path appropriate for the service selected for the traffic, either according to an explicit marking in each packet (e.g., MPLS labels, Diffserv Per-Hop Behaviors (PHBs) or DSCP values) or implicitly (e.g., the physical or logical port on which the traffic arrives).
R（14）ルーティングシステムは、各パケットの明示的なマーク（MPLSラベル、Diffserv Per Hop動作（PHB）またはDSCP）に従って、トラフィックに選択されたサービスに適したパス上のトラフィックを転送できる必要があります。値）または暗黙的に（たとえば、トラフィックが到着する物理的または論理的なポート）。
R(15) The routing system should also be able to carry information about the expected (or actually, promised) characteristics of the entire path and the price for the service.
R（15）ルーティングシステムは、パス全体の予想される（または実際に約束された）特性とサービスの価格に関する情報を伝えることもできる必要があります。
(If such information is exchanged at all between network operators today, it is through bilateral management interfaces, and not through the routing protocols.)
（そのような情報が今日のネットワークオペレーター間でまったく交換されている場合、それはルーティングプロトコルを使用するのではなく、二国間管理インターフェイスを介したものです。）
This would allow for the operator to optimize the choice of path based on a price/performance trade-off.
これにより、オペレーターは価格/パフォーマンスのトレードオフに基づいてパスの選択を最適化することができます。
In addition to providing dynamic QoS information, the system should be able to use static class-of-service information.
動的なQoS情報の提供に加えて、システムは静的なクラスオブサービス情報を使用できる必要があります。
- Security information
- セキュリティ情報
Security characteristics of other domains referred to by advertisements can allow the routing entity to make routing decisions based on political concerns. The information itself is assumed to be secure so that it can be trusted.
広告で言及されている他のドメインのセキュリティ特性により、ルーティングエンティティは政治的懸念に基づいてルーティングの決定を下すことができます。情報自体は、信頼できるように安全であると想定されています。
- Usage and cost information
- 使用およびコスト情報
Usage and cost information can be used for billing and traffic engineering. In order to support cost-based routing policies for customers (i.e., peer ISPs), information such as "traffic on this link or path costs XXX per Gigabyte" needs to be advertised, so that the customer can choose a more or a less expensive route.
使用およびコスト情報は、請求および交通工学に使用できます。顧客のコストベースのルーティングポリシー（つまり、ピアISP）をサポートするには、「このリンクやパスのトラフィックコストxxx xxx xxx」などの情報を宣伝する必要があります。ルート。
- Monitored performance
- 監視されたパフォーマンス
Performance information such as delay and drop frequency can be carried. (This may only be suitable inside a domain because of trust considerations.) This should support at least the kind of delay-bound contractual terms that are currently being offered by service providers. Note that these values refer to the outcome of carrying bits on the path, whereas the QoS information refers to the proposed behavior that results in this outcome.
遅延頻度やドロップ周波数などのパフォーマンス情報を運ぶことができます。（これは、信頼の考慮事項のためにドメイン内でのみ適切な場合があります。）これは、少なくともサービスプロバイダーが現在提供されている遅延拘束契約条件の種類をサポートする必要があります。これらの値は、パスにビットを運ぶ結果を指しますが、QoS情報はこの結果をもたらす提案された行動を指します。
- Multicast information
- マルチキャスト情報
R(16) The routing system must provide information needed to create multicast distribution trees. This information must be provided for one-to-many distribution trees and should be provided for many-to-many distribution trees.
R（16）ルーティングシステムは、マルチキャスト配布ツリーを作成するために必要な情報を提供する必要があります。この情報は、1対多くの配布ツリー用に提供され、多くの多い分布ツリーに提供する必要があります。
The actual construction of distribution trees is not necessarily done by the routing system.
配布ツリーの実際の構築は、必ずしもルーティングシステムによって行われるわけではありません。
R(17) The new network architecture must be stable without needing global convergence, i.e., convergence is a local property.
R（17）新しいネットワークアーキテクチャは、グローバルな収束を必要とせずに安定している必要があります。つまり、収束はローカルプロパティです。
The degree to which this is possible and the definition of "local" remain research topics. Restricting the requirement for convergence to localities will have an effect on all of the other requirements in this section.
これが可能な程度と「ローカル」の定義は研究トピックのままです。地域への収束の要件を制限することは、このセクションの他のすべての要件に影響を与えます。
R(18) The distribution and the rate of distribution of changes must not affect the stability of the routing information. For example, commencing redistribution of a change before the previous one has settled must not cause instability.
R（18）変化の分布と分布速度は、ルーティング情報の安定性に影響してはなりません。たとえば、前の変化が解決する前に変化を再分配することを開始することは、不安定性を引き起こしてはなりません。
R(19) The routing system must minimize oscillations in route advertisements.
R（19）ルーティングシステムは、ルート広告の振動を最小限に抑える必要があります。
In line with the separation of routing and forwarding concerns:
ルーティングと転送の懸念の分離に沿って：
R(20) The distribution of routing information must be, so far as is possible, loop-free.
R（20）ルーティング情報の分布は、可能な限りループフリーでなければなりません。
R(21) The forwarding information created from this routing information must seek to minimize persistent loops in the data-forwarding paths.
r（21）このルーティング情報から作成された転送情報は、データフォワードパスでの永続的なループを最小限に抑えることを求める必要があります。
It is accepted that transient loops may occur during convergence of the protocol and that there are trade-offs between loop avoidance and global scalability.
プロトコルの収束中に過渡ループが発生する可能性があり、ループ回避とグローバルなスケーラビリティの間にトレードオフがあることが認められています。
R(22) The routing system must provide means for detecting failures of node equipment or communication links.
R（22）ルーティングシステムは、ノード機器または通信リンクの障害を検出する手段を提供する必要があります。
R(23) The routing system should be able to coordinate failure indications from Layer 3 mechanisms, from nodal mechanisms built into the routing system, and from lower-layer mechanisms that propagate up to Layer 3 in order to determine the root cause of the failure. This will allow the routing system to react correctly to the failure by activating appropriate mitigation and repair mechanisms if required, while ensuring that it does not react if lower-layer repair mechanisms are able to repair or mitigate the fault.
R（23）ルーティングシステムは、レイヤー3メカニズム、ルーティングシステムに組み込まれた結節メカニズム、および障害の根本原因を決定するためにレイヤー3まで伝播する低層メカニズムからの故障の表示を調整できる必要があります。。これにより、必要に応じて適切な緩和および修復メカニズムをアクティブにすることにより、ルーティングシステムが障害に正しく反応することができ、低層修復メカニズムが障害を修復または軽減できる場合に反応しないようにします。
Most Layer 3 routing protocols have utilized keepalives or "hello" protocols as a means of detecting failures at Layer 3. The keepalive mechanisms are often complemented by analog mechanisms (e.g., laser-light detection) and hardware mechanisms (e.g., hardware/software watchdogs) that are built into routing nodes and communication links. Great care must be taken to make the best possible use of the various failure repair methods available while ensuring that only one repair mechanism at a time is allowed to repair any given fault.
ほとんどのレイヤー3ルーティングプロトコルは、レイヤー3で障害を検出する手段としてキープライブまたは「ハロー」プロトコルを利用しています。キープライブメカニズムは、しばしばアナログメカニズム（例えば、レーザー光検出）とハードウェアメカニズム（例えば、ハードウェア/ソフトウェアの監視機関）によって補完されます。）ルーティングノードと通信リンクに組み込まれています。一度に1つの修復メカニズムのみが特定の障害を修復できるようにしながら、利用可能なさまざまな障害修復方法を最大限に活用するために、細心の注意を払わなければなりません。
Interactions between, for example, fast reroute mechanisms at Layer 3 and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/ SDH) repair at Layer 1 are highly undesirable and are likely to cause problems in the network.
たとえば、レイヤー3での高速な再ルートメカニズムと、レイヤー1での同期光ネットワーク/同期デジタル階層（SONET/ SDH）修復との相互作用は非常に望ましくなく、ネットワークに問題を引き起こす可能性があります。
R(24) Where a network topology and routing system contains multiple fault repair mechanisms, the responses of these systems to a detected failure should be coordinated so that the fault is repaired by the most appropriate means, and no extra repairs are initiated.
R（24）ネットワークトポロジとルーティングシステムに複数の障害修復メカニズムが含まれている場合、これらのシステムの検出された障害に対する応答を調整して、障害が最も適切な手段によって修復され、追加の修理が開始されないようにする必要があります。
R(25) Where specialized packet exchange mechanisms (e.g., Layer 3 keepalive or "hello" protocol mechanisms) are used to detect failures, the routing system must allow the configuration of the rate of transmission of these keepalives. This must include the capability to turn them off altogether for links that are deliberately broken when no real user or control traffic is present (e.g., ISDN links).
R（25）特殊なパケット交換メカニズム（例えば、レイヤー3キープライブまたは「ハロー」プロトコルメカニズム）が障害を検出するために使用される場合、ルーティングシステムはこれらのキープライブの伝送速度の構成を可能にする必要があります。これには、実際のユーザーまたはコントロールトラフィックが存在しない場合に意図的に壊れているリンクに対して、それらを完全にオフにする機能を含める必要があります（例：ISDNリンク）。
This will allow the operator to compromise between the speed of failure detection and the proportion of link bandwidth dedicated to failure detection.
これにより、演算子は障害検出速度と障害検出専用のリンク帯域幅の割合の間の妥協が可能になります。
R(26) The routing system must support a mix of different kinds of addresses.
R（26）ルーティングシステムは、さまざまな種類のアドレスの組み合わせをサポートする必要があります。
This mix will include at least IPv4 and IPv6 addresses, and preferably various types of non-IP addresses, too. For instance, networks like SDH/SONET and Wavelength Division Multiplexing (WDM) may prefer to use non-IP addresses. It may also be necessary to support multiple sets of "private" (e.g., RFC 1918) addresses when dealing with multiple customer VPNs.
このミックスには、少なくともIPv4およびIPv6アドレス、およびできればさまざまなタイプの非IPアドレスも含まれます。たとえば、SDH/SONETや波長分割多重化（WDM）などのネットワークは、非IPアドレスを使用することを好む場合があります。また、複数の顧客VPNを扱う際に、複数の「プライベート」（例：RFC 1918）のアドレスをサポートする必要がある場合があります。
R(27) The routing system should support the use of a single topology representation to generate routing and forwarding tables for multiple address families on the same network.
R（27）ルーティングシステムは、同じネットワーク上の複数のアドレスファミリのルーティングテーブルと転送テーブルを生成するために、単一のトポロジ表現の使用をサポートする必要があります。
This capability would minimize the protocol overhead when exchanging routes.
この機能は、ルートを交換するときにプロトコルオーバーヘッドを最小限に抑えます。
R(28) If a domain is subject to address reassignment that would cause forwarding interruption, then the routing system should support readdressing (e.g., when a new prefix is given to an old network, and the change is known in advance) by maintaining routing during the changeover period [RFC2071] [RFC2072].
R（28）ドメインが転送の中断を引き起こす再割り当てに対処する場合、ルーティングシステムは再処理をサポートする必要があります（例えば、古いネットワークに新しいプレフィックスが与えられ、変更が事前に知られている場合）。切り替え期間[RFC2071] [RFC2072]。
R(29) The routing system must support multicast addressing, both within a domain and across multiple domains.
R（29）ルーティングシステムは、ドメイン内および複数のドメインの両方で、マルチキャストアドレス指定をサポートする必要があります。
R(30) The routing system should support anycast addressing within a domain. The routing system may support anycast addressing across domains.
R（30）ルーティングシステムは、ドメイン内のアドレス指定をサポートする必要があります。ルーティングシステムは、ドメイン全体のアドレス指定をサポートする場合があります。
An open question is whether it is possible or useful to support anycast addressing between cooperating domains.
未解決の質問は、協力ドメイン間のアドレス指定をサポートすることが可能かどうかです。
R(31) The routing system must support scoping of unicast addresses, and it should support scoping of multicast and anycast address types.
R（31）ルーティングシステムは、ユニキャストアドレスのスコーピングをサポートする必要があり、マルチキャストおよびAnycastアドレスタイプのスコーピングをサポートする必要があります。
The unicast address scoping that is being designed for IPv6 does not seem to cause any special problems for routing. IPv6 inter-domain routing handles only IPv6 global addresses, while intra-domain routing also needs to be aware of the scope of private addresses.
IPv6向けに設計されているユニキャストアドレススコーピングは、ルーティングに特別な問題を引き起こしていないようです。IPv6インタードメインルーティングは、IPv6グローバルアドレスのみを処理しますが、ドメイン内ルーティングもプライベートアドレスの範囲を認識する必要があります。
Editors' Note: the original reference was to site-local addresses, but these have been deprecated by the IETF. Link-local addresses are never routed at all.
編集者注：元の参照はサイトローカルアドレスへのものでしたが、これらはIETFによって非推奨されています。Link-Localアドレスはまったくルーティングされることはありません。
More study may be needed to identify the requirements and solutions for scoping in a more general sense and for scoping of multicast and anycast addresses.
より一般的な意味でのスコーピングの要件とソリューションを特定し、マルチキャストおよびAnycastアドレスのスコープの要件とソリューションを特定するには、さらに研究が必要になる場合があります。
R(32) The routing system must support system mobility. The term "system" includes anything from an end system to an entire domain.
R（32）ルーティングシステムは、システムのモビリティをサポートする必要があります。「システム」という用語には、エンドシステムからドメイン全体へのあらゆるものが含まれます。
We observe that the existing solutions based on renumbering and/or tunneling are designed to work with the current routing, so they do not add any new requirements to future routing. But the requirement is general, and future solutions may not be restricted to the ones we have today.
変更やトンネリングに基づいた既存のソリューションは、現在のルーティングで動作するように設計されているため、将来のルーティングに新しい要件を追加しないことがわかります。しかし、要件は一般的であり、将来のソリューションは今日のソリューションに限定されない可能性があります。
R(33) Both the routing and forwarding parts of the routing system must maintain statistical information about the performance of their functions.
R（33）ルーティングシステムのルーティング部分と転送部分の両方は、機能のパフォーマンスに関する統計情報を維持する必要があります。
While the tools of management are outside the scope of routing, the mechanisms to support the routing architecture and protocols are within scope.
管理のツールはルーティングの範囲外ですが、ルーティングアーキテクチャとプロトコルをサポートするメカニズムは範囲内です。
R(34) Mechanisms to support Operational, Administrative, and Management control of the routing architecture and protocols must be designed into the original fabric of the architecture.
R（34）ルーティングアーキテクチャとプロトコルの運用、管理、および管理制御をサポートするメカニズムは、アーキテクチャの元のファブリックに設計する必要があります。
The basic aims of this specification are:
- to require less manual configuration than today, and
-
- to satisfy the requirements for both easy handling and maximum control. That is:
- 簡単な取り扱いと最大の制御の両方の要件を満たすため。あれは：
- All the information should be available,
-
- but should not be visible except for when necessary.
- ただし、必要な場合を除いて、表示されるべきではありません。
- Policies themselves should be advertised and not only the result of policy, and
- ポリシー自体は宣伝され、ポリシーの結果だけでなく、
- policy-conflict resolution must be provided.
- ポリシーの紛争解決を提供する必要があります。
R(35) The routing system must provide management of the system by means of policies. For example, policies that can be expressed in terms of the business and services implemented on the network and reflect the operation of the network in terms of the services affected.
R（35）ルーティングシステムは、ポリシーによってシステムの管理を提供する必要があります。たとえば、ネットワーク上に実装されたビジネスとサービスの観点から表現し、影響を受けるサービスの観点からネットワークの運用を反映できるポリシー。
Editors' Note: This requirement is optimistic in that it implies that it is possible to get operators to cooperate even if it is seen by them to be against their business practices.
編集者注：この要件は、ビジネス慣行に反対していると見なされていても、オペレーターに協力することが可能であることを意味するという点で、楽観的です。
R(36) The distribution of policies must be amenable to scoping to protect proprietary policies that are not relevant beyond the local set of domains.
R（36）ポリシーの分布は、ドメインのローカルセットを超えて関連性がない独自のポリシーを保護するために、スコーピングに適している必要があります。
A major problem in today's networks is the need to perform initial configuration on routers from a local interface before a remote management system can take over. It is not clear that this imposes any requirements on the routing architecture beyond what is needed for a ZeroConf host.
今日のネットワークの大きな問題は、リモート管理システムが引き継ぐ前に、ローカルインターフェイスからルーターで初期構成を実行する必要があることです。これにより、ルーティングアーキテクチャに要件がゼロコンフホストに必要なものを超えて課されることは明らかではありません。
Similarly, maintenance and upgrade of routers can cause major disruptions to the network routing because the routing system and management of routers is not organized to minimize such disruption. Some improvements have been made, such as graceful restart mechanisms in protocols, but more needs to be done.
同様に、ルーターのメンテナンスとアップグレードは、ルーターのルーティングシステムと管理がこのような混乱を最小限に抑えるために編成されていないため、ネットワークルーティングに大きな混乱を引き起こす可能性があります。プロトコルの優雅な再起動メカニズムなど、いくつかの改善が行われましたが、さらに多くの改善を行う必要があります。
R(37) The routing system and routers should provide mechanisms that minimize the disruption to the network caused by maintenance and upgrades of software and hardware. This requirement recognizes that some of the capabilities needed are outside the scope of the routing architecture (e.g., minimum impact software upgrade).
R（37）ルーティングシステムとルーターは、ソフトウェアとハードウェアのメンテナンスとアップグレードによって引き起こされるネットワークの破壊を最小限に抑えるメカニズムを提供する必要があります。この要件は、必要な機能の一部がルーティングアーキテクチャの範囲外であることを認識しています（たとえば、最小影響ソフトウェアのアップグレードなど）。
R(38) The routing system and its component protocols must be demonstrated to be locally convergent under the permitted range of parameter settings and policy options that the operator(s) can select.
R（38）ルーティングシステムとそのコンポーネントプロトコルは、オペレーターが選択できるパラメーター設定とポリシーオプションの許可された範囲の下で局所的に収束することを実証する必要があります。
There are various methods for demonstration and proof that include, but are not limited to: mathematical proof, heuristic, and pattern recognition. No requirement is made on the method used for demonstrating local convergence properties.
デモンストレーションと証明には、数学的証明、ヒューリスティック、およびパターン認識を含むがこれらに限定されないさまざまな方法があります。ローカル収束特性を実証するために使用される方法については要件はありません。
R(39) Routing protocols employed by the routing system and the overall routing system should be resistant to bad routing policy decisions made by operators.
R（39）ルーティングシステムとルーティングシステム全体で採用されているルーティングプロトコルは、オペレーターが行った悪いルーティングポリシー決定に耐性がなければなりません。
Tools are needed to check compatibility of routing policies. While these tools are not part of the routing architecture, the mechanisms to support such tools are.
ルーティングポリシーの互換性を確認するには、ツールが必要です。これらのツールはルーティングアーキテクチャの一部ではありませんが、そのようなツールをサポートするメカニズムはそうです。
Routing policies are compatible if their interaction does not cause instability. A domain or group of domains in a system is defined as being convergent, either locally or globally, if and only if, after an exchange of routing information, routing tables reach a stable state that does not change until the routing policies or the topology changes again.
ルーティングポリシーは、相互作用が不安定性を引き起こさない場合、互換性があります。システム内のドメインのドメインまたはグループは、ルーティング情報の交換後、ルーティングテーブルがルーティングポリシーまたはトポロジが変更されるまで変更されない安定した状態に到達した場合にのみ、ローカルまたはグローバルに収束すると定義されます。また。
To achieve the above-mentioned goals:
上記の目標を達成するには：
R(40) The routing system must provide a mechanism to publish and communicate policies so that operational coordination and fault isolation are possible.
R（40）ルーティングシステムは、運用の調整と障害分離が可能になるように、ポリシーを公開および伝達するメカニズムを提供する必要があります。
Tools are required that verify the stability characteristics of the routing system in specified parts of the Internet. The tools should be efficient (fast) and have a broad scope of operation (check large portions of Internet). While these tools are not part of the architecture, developing them is in the interest of the architecture and should be defined as a Routing Research Group activity while research on the architecture is in progress.
インターネットの指定された部分のルーティングシステムの安定性特性を確認するツールが必要です。ツールは効率的（高速）であり、幅広い動作範囲を持っている必要があります（インターネットの大部分を確認してください）。これらのツールはアーキテクチャの一部ではありませんが、それらを開発することはアーキテクチャの利益になり、アーキテクチャに関する研究が進行中である間、ルーティング研究グループの活動として定義する必要があります。
Tools analyzing routing policies can be applied statically or (preferably) dynamically. A dynamic solution requires tools that can be used for run time checking for oscillations that arise from policy conflicts. Research is needed to find an efficient solution to the dynamic checking of oscillations.
ルーティングポリシーを分析するツールは、静的または（できれば）動的に適用できます。動的なソリューションには、ポリシーの競合から生じる振動の実行時間チェックに使用できるツールが必要です。振動の動的なチェックに対する効率的な解決策を見つけるには、研究が必要です。
The ability to do traffic engineering and to get the feedback from the network to enable traffic engineering should be included in the future domain architecture. Though traffic engineering has many definitions, it is, at base, another alternative or extension for the path selection mechanisms of the routing system. No fundamental changes to the requirements are needed, but the iterative processes involved in traffic engineering may require some additional capabilities and state in the network.
トラフィックエンジニアリングを行い、ネットワークからフィードバックを取得してトラフィックエンジニアリングを有効にする機能は、将来のドメインアーキテクチャに含める必要があります。トラフィックエンジニアリングには多くの定義がありますが、ベースでは、ルーティングシステムのパス選択メカニズムの別の代替または拡張です。要件の根本的な変更は必要ありませんが、交通工学に関与する反復プロセスには、ネットワーク内の追加の機能と状態が必要になる場合があります。
Traffic engineering typically involves a combination of off-line network planning and administrative control functions in which the expected and measured traffic flows are examined, resulting in changes to static configurations and policies in the routing system.
トラフィックエンジニアリングには、通常、オフラインのネットワーク計画と管理制御機能の組み合わせが含まれ、予想されるトラフィックフローが調べられ、ルーティングシステムの静的構成とポリシーが変更されます。
During operations, these configurations control the actual flow of traffic and affect the dynamic path selection mechanisms; the results are measured and fed back into further rounds of network planning.
操作中、これらの構成はトラフィックの実際の流れを制御し、動的なパス選択メカニズムに影響します。結果は測定され、ネットワーク計画のさらなるラウンドに供給されます。
At present, there is an almost total lack of effective traffic engineering tools, whether in real time for network control or off-line for network planning. The routing system should encourage the provision of such tools.
現在、ネットワーク制御のためのリアルタイムであろうと、ネットワーク計画のオフラインであろうと、効果的なトラフィックエンジニアリングツールがほぼ完全に不足しています。ルーティングシステムは、そのようなツールの提供を促進する必要があります。
R(41) The routing system must generate statistical and accounting information in such a way that traffic engineering and network planning tools can be used in both real-time and off-line planning and management.
R（41）ルーティングシステムは、トラフィックエンジニアリングおよびネットワーク計画ツールをリアルタイムおよびオフラインの両方の計画と管理の両方で使用できるように、統計情報と会計情報を生成する必要があります。
R(42) The routing system must support the controlled distribution over multiple links or paths of traffic toward the same destination. This applies to domains with two or more connections to the same neighbor domain, and to domains with connections to more than one neighbor domain. The paths need not have the same metric.
R（42）ルーティングシステムは、同じ宛先へのトラフィックの複数のリンクまたはパス上の制御された分布をサポートする必要があります。これは、同じ近隣ドメインに2つ以上の接続を持つドメインと、複数の隣接ドメインへの接続を持つドメインに適用されます。パスには同じメトリックを持つ必要はありません。
R(43) The routing system must support forwarding over multiple parallel paths when available. This support should extend to cases where the offered traffic is known to exceed the available capacity of a single link, and to the cases where load is to be shared over paths for cost or resiliency reasons.
R（43）ルーティングシステムは、利用可能な場合は複数の並列パス上の転送をサポートする必要があります。このサポートは、提供されたトラフィックが単一のリンクの利用可能な容量を超えることが知られている場合、およびコストまたは回復力の理由で負荷をパスで共有する場合に拡張する必要があります。
R(44) Where traffic is forwarded over multiple parallel paths, the routing system must, so far as is possible, avoid the reordering of packets in individual micro-flows.
R（44）複数の並列パスにトラフィックが転送される場合、ルーティングシステムは、可能な限り、個々のマイクロフローでのパケットの並べ替えを避けなければなりません。
R(45) The routing system must have mechanisms to allow the traffic to be reallocated back onto a single path when multiple paths are not needed.
R（45）ルーティングシステムには、複数のパスが不要な場合にトラフィックを単一のパスに再配置できるようにするメカニズムが必要です。
R(46) The routing system must support peer-level connectivity as well as hierarchical connections between domains.
R（46）ルーティングシステムは、ドメイン間の階層接続と同様に、ピアレベルの接続性をサポートする必要があります。
The network is becoming increasingly complex, with private peering arrangements set up between providers at every level of the hierarchy of service providers and even by certain large enterprises, in the form of dedicated extranets.
ネットワークはますます複雑になりつつあり、専用のエクストラネットの形で、サービスプロバイダーの階層のあらゆるレベルのプロバイダー間で、さらには特定の大企業によるプライベートピアリングアレンジメントが設定されています。
R(47) The routing system must facilitate traffic engineering of peer routes so that traffic can be readily constrained to travel as the network operators desire, allowing optimal use of the available connectivity.
R（47）ルーティングシステムは、ネットワークオペレーターが希望するときにトラフィックを移動するためにトラフィックを容易に制約し、利用可能な接続を最適に使用できるように、ピアルートの交通工学を促進する必要があります。
One of our assumptions is that NATs and other middle-boxes such as firewalls, web proxies, and address family translators (e.g., IPv4 to IPv6) are here to stay.
私たちの仮定の1つは、NATやファイアウォール、Webプロキシ、アドレスファミリ翻訳者（IPv4からIPv6など）などの他の中間ボックスがここに留まることです。
R(48) The routing system should work in conjunction with middle-boxes, e.g., NAT, to aid in bi-directional connectivity without compromising the additional opacity and privacy that the middle-boxes offer.
R（48）ルーティングシステムは、ミドルボックスが提供する追加の不透明度とプライバシーを損なうことなく、双方向の接続性を支援するために、中間ボックス、たとえばNATと組み合わせて動作する必要があります。
This problem is closely analogous to the abstraction problem, which is already under discussion for the interchange of routing information between domains.
この問題は、ドメイン間のルーティング情報の交換についてすでに議論されている抽象化の問題と密接に類似しています。
Over the past several years, the performance of the routing system has frequently been discussed. The requirements that derive from those discussions are listed below. The specific values for these performance requirements are left for further discussion.
過去数年にわたって、ルーティングシステムのパフォーマンスが頻繁に議論されてきました。これらの議論に由来する要件を以下に示します。これらのパフォーマンス要件の特定の値は、さらなる議論のために残されています。
R(49) The routing system must support domains of at least N systems. A system is taken to mean either an individual router or a domain.
R（49）ルーティングシステムは、少なくともNシステムのドメインをサポートする必要があります。システムは、個々のルーターまたはドメインのいずれかを意味するように使用されます。
R(50) Local convergence should occur within T units of time.
R（50）時間の時間単位内で局所的な収束が発生するはずです。
R(51) The routing system must be measurably reliable. The measure of reliability remains a research question.
R（51）ルーティングシステムは、測定可能に信頼性が高い必要があります。信頼性の尺度は、研究の問題のままです。
R(52) The routing system must be locally stable to a measured degree. The degree of measurability remains a research issue.
R（52）ルーティングシステムは、測定された程度まで局所的に安定している必要があります。測定可能性の程度は研究問題のままです。
R(53) The routing system must be globally stable to a measured degree. The degree of measurability remains a research issue.
R（53）ルーティングシステムは、測定された程度までグローバルに安定している必要があります。測定可能性の程度は研究問題のままです。
R(54) The routing system should scale to an indefinitely large number of domains.
R（54）ルーティングシステムは、無期限に多数のドメインにスケーリングする必要があります。
There has been very little data or statistical evidence for many of the performance claims made in the past. In recent years, several efforts have been initiated to gather data and do the analyses required to make scientific assessments of performance issues and requirements. In order to complete this section of the requirements analysis, the data and analyses from these studies needs to be gathered and collated into this document. This work has been started but has yet to be completed.
過去に行われた多くのパフォーマンスの主張について、データや統計的証拠はほとんどありませんでした。近年、データを収集し、パフォーマンスの問題と要件の科学的評価を行うために必要な分析を行うためのいくつかの努力が開始されています。要件分析のこのセクションを完了するには、これらの研究のデータと分析を収集してこのドキュメントに照合する必要があります。この作業は開始されましたが、まだ完了していません。
Editors' Note: This work was never completed due to corporate reorganizations.
編集者の注：この作業は、企業の再編成のために完了することはありませんでした。
This area poses a dilemma. On one hand, it is an absolute requirement that:
この領域はジレンマをもたらします。一方では、それは絶対的な要件です。
R(55) The introduction of the routing system must not require any flag days.
R（55）ルーティングシステムの導入には、フラグの日を必要としないでください。
R(56) The network currently in place must continue to run at least as well as it does now while the new network is being installed around it.
R（56）現在配置されているネットワークは、新しいネットワークがその周りにインストールされている間、少なくとも現在も実行し続ける必要があります。
However, at the same time, it is also an requirement that:
ただし、同時に、それは次の要件でもあります。
R(57) The new architecture must not be limited by the restrictions that plague today's network.
R（57）新しいアーキテクチャは、今日のネットワークを悩ませる制限によって制限されてはなりません。
It has to be admitted that R(57) is not a well-defined requirement, because we have not fully articulated what the restrictions might be. Some of these restrictions can be derived by reading the discussions for the positive requirements above. It would be a useful exercise to explicitly list all the restrictions and irritations with which we wish to do away. Further, it would be useful to determine if these restrictions can currently be removed at a reasonable cost or whether we are actually condemned to live with them.
R（57）は、制限が何であるかを完全に明確にしていないため、明確に定義された要件ではないことを認めなければなりません。これらの制限のいくつかは、上記の肯定的な要件について議論を読むことで導き出すことができます。私たちがやりたいと思うすべての制限と刺激を明示的にリストするのは有用な演習です。さらに、これらの制限が現在合理的なコストで削除できるかどうか、または実際にそれらと一緒に暮らすことを非難されているかどうかを判断することは有用です。
Those restrictions cannot be allowed to become permanent baggage on the new architecture. If they do, the effort to create a new system will come to naught. It may, however, be necessary to live with some of them temporarily for practical reasons while providing an architecture that will eventually allow them to be removed. The last three requirements have significance not only for the transition strategy but also for the architecture itself. They imply that it must be possible for an internet such as today's BGP-controlled network, or one of its ASs, to exist as a domain within the new FDR.
これらの制限は、新しいアーキテクチャの恒久的な荷物になることを許可することはできません。もしそうなら、新しいシステムを作成する努力は無意味になります。ただし、最終的には削除できるようにするアーキテクチャを提供しながら、実際的な理由で一時的にそれらのいくつかと一緒に暮らす必要があるかもしれません。最後の3つの要件は、移行戦略だけでなく、アーキテクチャ自体にとっても重要です。彼らは、今日のBGP制御ネットワーク、またはその尻の1つなどのインターネットが新しいFDR内のドメインとして存在することが可能であることを意味します。
As previously discussed, one of the major changes that has overtaken the Internet since its inception is the erosion of trust between end users making use of the net, between those users and the suppliers of services, and between the multiplicity of providers. Hence, security, in all its aspects, will be much more important in the FDR.
前述のように、設立以来インターネットを追い越した主要な変更の1つは、ネットを利用しているエンドユーザー、それらのユーザーとサービスのサプライヤー間、および多数のプロバイダー間の間の信頼の侵食です。したがって、セキュリティは、そのすべての面で、FDRではるかに重要になります。
It must be possible to secure the routing communication.
ルーティング通信を保護することは可能である必要があります。
R(58) The communicating entities must be able to identify who sent and who received the information (authentication).
R（58）通信エンティティは、誰が送信され、誰が情報を受け取ったか（認証）を特定できる必要があります。
R(59) The communicating entities must be able to verify that the information has not been changed on the way (integrity).
R（59）通信エンティティは、情報が途中で変更されていないことを確認できる必要があります（整合性）。
Security is more important in inter-domain routing where the operator has no control over the other domains, than in intra-domain routing where all the links and the nodes are under the administration of the operator and can be expected to share a trust relationship. This property of intra-domain trust, however, should not be taken for granted:
セキュリティは、すべてのリンクとノードがオペレーターの管理下にあり、信頼関係を共有することが期待できるドメイン内ルーティングよりも、オペレーターが他のドメインを制御できないドメイン間ルーティングでより重要です。ただし、ドメイン内トラストのこの財産は、当然のことと見なされるべきではありません。
R(60) Routing communications must be secured by default, but an operator must have the option to relax this requirement within a domain where analysis indicates that other means (such as physical security) provide an acceptable alternative.
R（60）ルーティング通信はデフォルトで保護する必要がありますが、オペレーターは、分析が他の手段（物理的セキュリティなど）が許容可能な代替手段を提供することを示すドメイン内でこの要件を緩和するオプションを持っている必要があります。
R(61) The routing communication mechanism must be robust against denial-of-service attacks.
R（61）ルーティング通信メカニズムは、サービス拒否攻撃に対して堅牢でなければなりません。
R(62) It should be possible to verify that the originator of the information was authorized to generate the information.
R（62）情報の発信者が情報を生成することが許可されたことを確認することができるはずです。
Further considerations that may impose further requirements include:
さらなる要件を課す可能性のあるさらなる考慮事項は次のとおりです。
- whether no one else but the intended recipient is able to access (privacy) or understand (confidentiality) the information,
- 意図された受信者以外の誰もアクセス（プライバシー）にアクセスできないか、情報を理解することができないかどうか、
- whether it is possible to verify that all the information has been received and that the two parties agree on what was sent (validation and non-repudiation),
- すべての情報が受信されたこと、および2つの当事者が送信されたもの（検証と非控除）に同意することを確認することが可能かどうか、
- whether there is a need to separate security of routing from security of forwarding, and
- ルーティングのセキュリティを転送のセキュリティから分離する必要があるかどうか、および
- whether traffic flow security is needed (i.e., whether there is value in concealing who can connect to whom, and what volumes of data are exchanged).
- トラフィックフローセキュリティが必要かどうか（つまり、誰が誰に接続できるかを隠すことに価値があるかどうか、そしてどのような量のデータが交換されるか）。
Securing the BGP session, as done today, only secures the exchange of messages from the peering domain, not the content of the information. In other words, we can confirm that the information we got is what our neighbor really sent us, but we do not know whether or not this information (that originated in some remote domain) is true.
BGPセッションを保護することは、今日行われているように、情報の内容ではなく、ピアリングドメインからのメッセージの交換のみを保護します。言い換えれば、私たちが得た情報が私たちの隣人が本当に私たちに送ったものであることを確認できますが、この情報（いくつかのリモートドメインに由来する）が真実かどうかはわかりません。
A decision has to be made on whether to rely on chains of trust (we trust our peers who trust their peers who..), or whether we also need authentication and integrity of the information end-to-end. This information includes both routes and addresses. There has been interest in having digital signatures on originated routes as well as countersignatures by address authorities to confirm that the originator has authority to advertise the prefix. Even understanding who can confirm the authority is non-trivial, as it might be the provider who delegated the prefix (with a whole chain of authority back to ICANN) or it may be an address registry. Where a prefix delegated by a provider is being advertised through another provider as in multi-homing, both may have to be involved to confirm that the prefix may be advertised through the provider who doesn't have any interest in the prefix!
信頼のチェーンに依存するかどうか（私たちは自分の仲間を信頼する仲間を信頼します..）、または情報のエンドツーエンドの情報の認証と整合性も必要かどうかについて決定する必要があります。この情報には、ルートとアドレスの両方が含まれます。オリジネーターがプレフィックスを宣伝する権限を持っていることを確認するために、住所局による逆説と同様に、起源のルートと逆説にデジタル署名を持つことに興味がありました。権限を確認できるのは誰であるかを理解しても、プレフィックスを委任したプロバイダーである可能性があるため、権限全体をICANNに戻した場合、またはアドレスレジストリである可能性があるためです。プロバイダーによって委任されたプレフィックスが別のプロバイダーを通じて宣伝されている場合、マルチホミングのように、プレフィックスがプレフィックスに関心のないプロバイダーを通じて宣伝されることを確認するために両方を巻き込む必要がある場合があります。
R(63) The routing system must cooperate with the security policies of middle-boxes whenever possible.
R（63）ルーティングシステムは、可能な限りミドルボックスのセキュリティポリシーと協力する必要があります。
This is likely to involve further requirements for abstraction of information. For example, a firewall that is seeking to minimize interchange of information that could lead to a security breach. The effect of such changes on the end-to-end principle should be carefully considered as discussed in [Blumenthal01].
これには、情報の抽象化のためのさらなる要件が含まれる可能性があります。たとえば、セキュリティ侵害につながる可能性のある情報の交換を最小限に抑えようとしているファイアウォール。[Blumenthal01]で説明するように、エンドツーエンドの原則に対するそのような変化の影響は慎重に考慮する必要があります。
R(64) The routing system must be capable of complying with local legal requirements for interception of communication.
R（64）ルーティングシステムは、コミュニケーションの傍受に関する現地の法的要件を遵守できる必要があります。
This section covers issues that need to be considered and resolved in deciding on a Future Domain Routing architecture. While they can't be described as requirements, they do affect the types of solution that are acceptable. The discussions included below are very open-ended.
このセクションでは、将来のドメインルーティングアーキテクチャを決定する際に考慮し、解決する必要がある問題について説明します。それらは要件として説明することはできませんが、許容できるソリューションの種類に影響します。以下に含まれる議論は非常にオープンエンドです。
The mathematical model that underlies today's routing system uses a graph representation of the network. Hosts, routers, and other processing boxes are represented by nodes and communications links by arcs. This is a topological model in that routing does not need to directly model the physical length of the links or the position of the nodes; the model can be transformed to provide a convenient picture of the network by adjusting the lengths of the arcs and the layout of the nodes. The connectivity is preserved and routing is unaffected by this transformation.
今日のルーティングシステムの根底にある数学モデルは、ネットワークのグラフ表現を使用しています。ホスト、ルーター、およびその他の処理ボックスは、ノードとアークによる通信リンクで表されます。これは、ルーティングがリンクの物理的長さまたはノードの位置を直接モデル化する必要がないという点でトポロジモデルです。モデルを変換して、アークの長さとノードのレイアウトを調整することにより、ネットワークの便利な画像を提供できます。接続性は保存され、ルーティングはこの変換の影響を受けません。
The routing algorithms in traditional routing protocols utilize a small number of results from graph theory. It is only recently that additional results have been employed to support constraint-based routing for traffic engineering.
従来のルーティングプロトコルのルーティングアルゴリズムは、グラフ理論から少数の結果を利用しています。トラフィックエンジニアリングの制約ベースのルーティングをサポートするために、追加の結果が採用されたことはごく最近です。
The naturalness of this network model and the "fit" of the graph theoretical methods may have tended to blind us to alternative representations and inhibited us from seeking alternative strands of theoretical thinking that might provide improved results.
このネットワークモデルの自然性とグラフの理論的方法の「適合性」は、私たちを代替表現に盲目にする傾向があり、改善された結果をもたらす可能性のある理論的思考の代替鎖を求めることを阻害する可能性があります。
We should not allow this habitual behavior to stop us from looking for alternative representations and algorithms; topological revolutions are possible and allowed, at least in theory.
この習慣的な行動が、私たちが代替表現やアルゴリズムを探すのを止めることを許可すべきではありません。少なくとも理論的には、トポロジー革命が可能であり、許可されています。
The assumption that object modeling of a system is an essential first step to creating a new system is still novel in this context. Frequently, the object modeling effort becomes an end in itself and does not lead to system creation. But there is a balance, and a lot that can be discovered in an ongoing effort to model a system such as the Future Domain Routing system. It is recommended that this process be included in the requirements. It should not, however, be a gating event to all other work.
システムのオブジェクトモデリングが新しいシステムを作成するための不可欠な最初のステップであるという仮定は、このコンテキストではまだ斬新です。多くの場合、オブジェクトモデリングの取り組みはそれ自体が目的となり、システムの作成につながりません。しかし、バランスがあり、将来のドメインルーティングシステムなどのシステムをモデル化するための継続的な努力で発見できる多くのことがあります。このプロセスを要件に含めることをお勧めします。ただし、他のすべての作業にとってはゲーティングイベントではありません。
Some of the most important realizations will occur during the process of determining the following:
最も重要な実現のいくつかは、以下を決定する過程で発生します。
- Object classification
- オブジェクト分類
- Relationships and containment
- 関係と封じ込め
- Roles and Rules
- 役割とルール
There has been a lot of discussion of whether the FDR protocol solution should consist of one (probably new) protocol, two (intra-and inter-domain) protocols, or many protocols. While it might be best to have one protocol that handles all situations, this seems improbable. On the other hand, maintaining the "strict" division evident in the network today between the IGP and EGP may be too restrictive an approach. Given this, and the fact that there are already many routing protocols in use, the only possible answer seems to be that the architecture should support many protocols. It remains an open issue, one for the solution, to determine if a new protocol needs to be designed in order to support the highest goals of this architecture. The expectation is that a new protocol will be needed.
FDRプロトコルソリューションは、1つの（おそらく新しい）プロトコル、2つの（領域内および領域間）プロトコル、または多くのプロトコルで構成されるべきかどうかについて多くの議論がありました。すべての状況を処理するプロトコルを1つ持っていることが最善かもしれませんが、これはありそうもないようです。一方、IGPとEGPの間で今日のネットワークで明らかな「厳格な」部門を維持することは、あまりにも制限的なアプローチである可能性があります。これを考えると、すでに多くのルーティングプロトコルが使用されているという事実を考えると、唯一の答えは、アーキテクチャが多くのプロトコルをサポートする必要があるということです。このアーキテクチャの最高の目標をサポートするために、新しいプロトコルを設計する必要があるかどうかを判断するために、解決策のための未解決の問題のままです。期待されるのは、新しいプロトコルが必要になることです。
If a new protocol is required to support the FDR architecture, the question remains open as to what kind of protocol this ought to be. It is our expectation that a map distribution protocol will be required to augment the current path-vector protocol and shortest path first protocols.
FDRアーキテクチャをサポートするために新しいプロトコルが必要な場合、これがどのようなプロトコルがあるべきかについて疑問は開かれたままです。現在のパスベクトルプロトコルと最短のパス最初のプロトコルを強化するには、マップ配布プロトコルが必要になることが期待されます。
Assuming that a map distribution protocol, as defined in [RFC1992] is required, what are the requirements on this protocol? If every detail is advertised throughout the Internet, there will be a lot of information. Scalable solutions require abstraction.
[RFC1992]で定義されているマップ分布プロトコルが必要であると仮定すると、このプロトコルの要件は何ですか？すべての詳細がインターネット全体で宣伝されている場合、多くの情報があります。スケーラブルなソリューションには抽象化が必要です。
- If we summarize too much, some information will be lost on the way.
- 要約しすぎると、いくつかの情報が途中で失われます。
- If we summarize too little, then more information than required is available, contributing to scaling limitations.
- 要約が少なすぎると、必要以上の情報が利用可能であり、スケーリングの制限に貢献します。
- One can allow more summarization, if there also is a mechanism to query for more details within policy limits.
- ポリシーの制限内で詳細を照会するメカニズムもある場合は、さらに要約を許可できます。
- The basic requirement is not that the information shall be advertised, but rather that the information shall be available to those who need it. We should not presuppose a solution where advertising is the only possible mechanism.
- 基本的な要件は、情報が宣伝されることではなく、情報がそれを必要とする人が利用できることです。広告が唯一の可能なメカニズムであるソリューションを前提とするべきではありません。
As in all other fields, the words used to refer to concepts and to describe operations about routing are important. Rather than describe concepts using terms that are inaccurate or rarely used in the real world of networking, it is necessary to make an effort to use the correct words. Many networking terms are used casually, and the result is a partial or incorrect understanding of the underlying concept. Entities such as nodes, interfaces, subnetworks, tunnels, and the grouping concepts such as ASs, domains, areas, and regions, need to be clearly identified and defined to avoid confusion.
他のすべての分野と同様に、概念を参照し、ルーティングに関する操作を説明するために使用される単語は重要です。ネットワーキングの現実の世界で不正確またはめったに使用されない用語を使用して概念を記述するのではなく、正しい単語を使用する努力をする必要があります。多くのネットワーキング用語がさりげなく使用されており、結果は基礎となる概念の部分的または誤った理解です。ノード、インターフェイス、サブネットワーク、トンネル、およびASS、ドメイン、エリア、領域などのグループ化の概念などのエンティティは、混乱を避けるために明確に識別および定義する必要があります。
There is also a need to separate identifiers (what or who) from locators (where) from routes (how to reach).
また、識別子（何または誰が）からロケーター（WHERE）からルート（到達方法）から分離する必要があります。
Editors' Note: Work was undertaken in the shim6 working group of the IETF on this sort of separation. This work needs to be taken into account in any new routing architecture.
編集者注：この種の分離について、IETFのSHIM6ワーキンググループで作業が行われました。この作業は、新しいルーティングアーキテクチャで考慮する必要があります。
The routing association between two domains should survive even if some individual connection between two routers goes down.
2つのドメイン間のルーティング関連は、2つのルーター間の個別の接続がダウンしても生き残る必要があります。
The "session" should operate between logical "routing entities" on each domain side, and not necessarily be bound to individual routers or addresses. Such a logical entity can be physically distributed over multiple network elements. Or, it can reside in a single router, which would default to the current situation.
「セッション」は、各ドメイン側の論理的な「ルーティングエンティティ」間で動作し、必ずしも個々のルーターまたはアドレスにバインドされるわけではありません。このような論理的エンティティは、複数のネットワーク要素に物理的に分散できます。または、単一のルーターに存在する可能性があり、デフォルトで現在の状況になります。
A more flexible hierarchy with more levels and recursive groupings in both upward and downward directions allows more structured routing. The consequence is that no single level will get too big for routers to handle.
より多くのレベルと上向き方向と下向きの両方の方向の両方で再帰的なグループを備えたより柔軟な階層により、より構造化されたルーティングが可能になります。その結果、ルーターが処理するには1つのレベルが大きくなりすぎないことがあります。
On the other hand, it appears that the real-world Internet is becoming less hierarchical, so that it will be increasingly difficult to use hierarchy to control scaling.
一方、実際のインターネットは階層的ではなくなっているため、階層を使用してスケーリングを制御することがますます困難になるようです。
Note that groupings can look different depending on which aspect we use to define them. A Diffserv area, an MPLS domain, a trusted domain, a QoS area, a multicast domain, etc., do not always coincide; nor are they strict hierarchical subsets of each other. The basic distinction at each level is "this grouping versus everything outside".
グループ化は、それらを定義するために使用する側面によって異なるように見えることに注意してください。DiffServエリア、MPLSドメイン、信頼できるドメイン、QoSエリア、マルチキャストドメインなどは、常に一致するとは限りません。また、それらは互いに厳格な階層的なサブセットでもありません。各レベルでの基本的な区別は、「このグループと外部のすべて」です。
Is it possible to apply a control theory framework to analyze the stability of the control system of the whole network domain, with regard to, e.g., convergence speed and the frequency response, and then use the results from that analysis to set the timers and other protocol parameters?
コントロール理論フレームワークを適用して、収束速度と周波数応答に関して、ネットワークドメイン全体の制御システムの安定性を分析し、その分析の結果を使用してタイマーやその他を設定することができますか？プロトコルパラメーター？
Control theory could also play a part in QoS routing, by modifying current link-state protocols with link costs dependent on load and feedback. Control theory is often used to increase the stability of dynamic systems.
コントロール理論は、負荷とフィードバックに依存するリンクコストで現在のリンク状態プロトコルを変更することにより、QoSルーティングに役割を果たすこともできます。制御理論は、多くの場合、動的システムの安定性を高めるために使用されます。
It might be possible to construct a new, totally dynamic routing protocol solely on a control theoretic basis, as opposed to the current protocols that are based in graph theory and static in nature.
グラフ理論に基づいており、本質的に静的な現在のプロトコルとは対照的に、制御理論的ベースでのみ、新しい完全に動的なルーティングプロトコルを構築することが可能かもしれません。
Is solving the Byzantine Generals problem a requirement? This is the problem of reaching a consensus among distributed units if some of them give misleading answers. The current intra-domain routing system is, at one level, totally intolerant of misleading information. However, the effect of different sorts of misleading or incorrect information has vastly varying results, from total collapse to purely local disconnection of a single domain. This sort of behavior is not very desirable.
ビザンチン将軍の問題を解決することは要件ですか？これは、一部が誤解を招く答えを出した場合、分散ユニットの間でコンセンサスに達する問題です。現在のドメイン内ルーティングシステムは、あるレベルで、誤解を招く情報に完全に不寛容です。ただし、さまざまな種類の誤解を招くまたは誤った情報の効果は、総崩壊から純粋に局所的な切断まで、非常に変化した結果を持っています。この種の動作はあまり望ましくありません。
There are, possibly, other network robustness issues that must be researched and resolved.
おそらく、研究および解決しなければならない他のネットワークの堅牢性の問題があります。
Today, BGP is also used for VPNs, for example, as described in RFC 4364 [RFC4364].
今日、BGPは、たとえばRFC 4364 [RFC4364]で説明されているように、VPNにも使用されています。
Internet routing and VPN routing have different purposes and most often exchange different information between different devices. Most Internet routers do not need to know VPN-specific information. The concepts should be clearly separated.
インターネットルーティングとVPNルーティングには異なる目的があり、ほとんどの場合、異なるデバイス間で異なる情報を交換します。ほとんどのインターネットルーターは、VPN固有の情報を知る必要はありません。概念は明確に分離する必要があります。
But when it comes to the mechanisms, VPN routing can share the same protocol as ordinary Internet routing; it can use a separate instance of the same protocol or it can use a different protocol. All variants are possible and have their own merits. These requirements are silent on this issue.
しかし、メカニズムに関しては、VPNルーティングは通常のインターネットルーティングと同じプロトコルを共有できます。同じプロトコルの個別のインスタンスを使用するか、異なるプロトコルを使用できます。すべてのバリアントが可能であり、独自のメリットがあります。これらの要件は、この問題について沈黙しています。
The existing Internet architecture neither requires nor provides end-to-end reliability of control information dissemination. There is, however, already a requirement for end-to-end reliability of control information distribution, i.e., the ends of the VPN established need to have an acknowledgment of the success in setting up the VPN. While it is not necessarily the function of a routing architecture to provide end-to-end reliability for this kind of purpose, we must be clear that end-to-end reliability becomes a requirement if the network has to support such reliable control signaling. There may be other requirements that derive from requiring the FDR to support reliable control signaling.
既存のインターネットアーキテクチャは、制御情報の普及のエンドツーエンドの信頼性を必要とせず、提供しません。ただし、制御情報分布のエンドツーエンドの信頼性の要件がすでにあります。つまり、VPNの設定における成功を認識する必要があるVPNの終わりが確立されています。この種の目的のためにエンドツーエンドの信頼性を提供することは必ずしもルーティングアーキテクチャの機能ではありませんが、ネットワークがそのような信頼できる制御シグナリングをサポートする必要がある場合、エンドツーエンドの信頼性が要件になることを明確にする必要があります。信頼できる制御信号をサポートするためにFDRが要求することから派生する他の要件があるかもしれません。
The introduction of private addressing schemes, Network Address Translators, and firewalls has significantly reduced the end-to-end transparency of the network. In many cases, the network is also no longer symmetric, so that communication between two addresses is possible if the communication session originates from one end but not from the other. This impedes the deployment of new peer-to-peer services and some "push" services where the server in a client-server arrangement originates the communication session. Whether a new routing system either can or should seek to restore this transparency is an open issue.
プライベートアドレス指定スキーム、ネットワークアドレス翻訳者、およびファイアウォールの導入により、ネットワークのエンドツーエンドの透明性が大幅に低下しました。多くの場合、ネットワークも対称ではなくなっているため、通信セッションが一方の端から発生し、もう一方のアドレスからではなく、2つのアドレス間の通信が可能になります。これにより、新しいピアツーピアサービスの展開と、クライアントサーバーアレンジメントのサーバーが通信セッションを開始する「プッシュ」サービスの展開が妨げられます。新しいルーティングシステムがこの透明性を復元しようとするかどうかを模索するかどうかは、未解決の問題です。
A related issue is the extent to which end-user applications should seek to control the routing of communications to the rest of the network.
関連する問題は、エンドユーザーアプリケーションがネットワークの残りの部分への通信のルーティングを制御しようとする程度です。
We address security issues in the individual requirements. We do require that the architecture and protocols developed against this set of requirements be "secure". Discussion of specific security issues can be found in the following sections:
個々の要件のセキュリティ問題に対処します。この一連の要件に対して開発されたアーキテクチャとプロトコルが「安全」であることが必要です。特定のセキュリティ問題の議論は、次のセクションにあります。
o Group A: Routing System Security - Section 2.1.9
o グループA：ルーティングシステムセキュリティ - セクション2.1.9
o Group A: End Host Security - Section 2.1.10
o グループA：エンドホストセキュリティ - セクション2.1.10
o Group A: Routing Information Policies - Section 2.1.11.1
o グループA：ルーティング情報ポリシー - セクション2.1.11.1
o Group A: Abstraction - Section 2.1.16
o グループA：抽象化 - セクション2.1.16
o Group A: Robustness - Section 2.1.18 o Group B: Protection against Denial-of-Service and Other Security Attacks - Section 3.2.3.8
o グループA：堅牢性 - セクション2.1.18 OグループB：サービス拒否およびその他のセキュリティ攻撃に対する保護-3.2.3.8セクション
o Group B: Commercial Service Providers - Section 3.3.1.1
o グループB：商業サービスプロバイダー - セクション3.3.1.1
o Group B: The Federated Environment - Section 3.4.1
o グループB：フェデレーション環境 - セクション3.4.1
o Group B: Path Advertisement - Section 3.6.2.2
o グループB：パス広告 - セクション3.6.2.2
o Group B: Security Requirements - Section 3.9
o グループB：セキュリティ要件 - セクション3.9
This document is a set of requirements from which a new routing and addressing architecture may be developed. From that architecture, a new protocol, or set of protocols, may be developed.
このドキュメントは、新しいルーティングとアドレス指定アーキテクチャを開発できる一連の要件です。そのアーキテクチャから、新しいプロトコル、または一連のプロトコルが開発される場合があります。
While this note poses no new tasks for IANA, the architecture and protocols developed from this document probably will have issues to be dealt with by IANA.
このメモはIANAの新しいタスクを提起しませんが、このドキュメントから開発されたアーキテクチャとプロトコルには、おそらくIANAが対処すべき問題があります。
This document is the combined effort of two groups in the IRTF. Group A, which was formed by the IRTF Routing Research chairs, and Group B, which was self-formed and later was folded into the IRTF Routing Research Group. Each group has it own set of acknowledgments.
このドキュメントは、IRTFの2つのグループの組み合わせの取り組みです。IRTFルーティングリサーチチェアによって形成されたグループAとグループBは、自己形成され、後にIRTFルーティングリサーチグループに折りたたまれました。各グループには、独自の謝辞セットがあります。
Group A Acknowledgments
グループA謝辞
This originated in the IRTF Routing Research Group's sub-group on Inter-domain routing requirements. The members of the group were:
これは、IRTFルーティングリサーチグループのドメイン間ルーティング要件に関するサブグループのサブグループに由来しています。グループのメンバーは次のとおりです。
Abha Ahuja Danny McPherson
J. Noel Chiappa David Meyer
Sean Doran Mike O'Dell
JJ Garcia-Luna-Aceves Andrew Partan
Susan Hares Radia Perlman
Geoff Huston Yakov Rehkter
Frank Kastenholz John Scudder
Dave Katz Curtis Villamizar
Tony Li Dave Ward
We also appreciate the comments and review received from Ran Atkinson, Howard Berkowitz, Randy Bush, Avri Doria, Jeffery Haas, Dmitri Krioukov, Russ White, and Alex Zinin. Special thanks to Yakov Rehkter for contributing text and to Noel Chiappa.
また、Ran Atkinson、Howard Berkowitz、Randy Bush、Avri Doria、Jeffery Haas、Dmitri Krioukov、Russ White、Alex Zininから受け取ったコメントとレビューにも感謝しています。Yakov Rehkterに貢献してくれたこととNoel Chiappaに感謝します。
Group B Acknowledgments
グループBの謝辞
The document is derived from work originally produced by Babylon. Babylon was a loose association of individuals from academia, service providers, and vendors whose goal was to discuss issues in Internet routing with the intention of finding solutions for those problems.
このドキュメントは、元々バビロンが製造した作業から派生しています。バビロンは、アカデミア、サービスプロバイダー、およびベンダーの個人とのゆるい関係でした。そのベンダーは、これらの問題の解決策を見つけることを目的として、インターネットルーティングの問題を議論することを目標としていました。
The individual members who contributed materially to this document are: Anders Bergsten, Howard Berkowitz, Malin Carlzon, Lenka Carr Motyckova, Elwyn Davies, Avri Doria, Pierre Fransson, Yong Jiang, Dmitri Krioukov, Tove Madsen, Olle Pers, and Olov Schelen.
この文書に実質的に貢献した個々のメンバーは、アンダース・ベルクステン、ハワード・バーコウィッツ、マリン・カールゾン、レンカ・カー・モティコヴァ、エルウィン・デイビス、アヴリ・ドリア、ピエール・フランソン、ヨン・ジアン、ドミトリ・クリコフ、オル・マドセン、オロ・シェルンです。
Thanks also go to the members of Babylon and others who did substantial reviews of this material. Specifically, we would like to acknowledge the helpful comments and suggestions of the following individuals: Loa Andersson, Tomas Ahlstrom, Erik Aman, Thomas Eriksson, Niklas Borg, Nigel Bragg, Thomas Chmara, Krister Edlund, Owe Grafford, Torbjorn Lundberg, Jeremy Mineweaser, Jasminko Mulahusic, Florian-Daniel Otel, Bernhard Stockman, Tom Worster, and Roberto Zamparo.
また、この資料のかなりのレビューを行ってくれたバビロンと他の人たちにも感謝します。具体的には、Loa Andersson、Tomas Ahlstrom、Erik Aman、Thomas Eriksson、Niklas Borg、Nigel Bragg、Thomas Chmara、Krister Edlund、Owe Grafford、Torbjorn Lundberg、Jerem Mineweaser、Jerem Mineweaser、Jasminko Mulahusic、Florian-Daniel Otel、Bernhard Stockman、Tom Worster、Roberto 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がShepherdを文書化したLixia Zhangに、彼女の助けと彼女の忍耐に感謝します。
Finally, it is the editors who are responsible for any lack of clarity, any errors, glaring omissions or misunderstandings.
最後に、明確さの欠如、エラー、明白な省略、または誤解を担当するのは編集者です。
[Blumenthal01] Blumenthal, M. and D. Clark, "Rethinking the design of the Internet: The end to end arguments vs. the brave new world", May 2001, <http://dspace.mit.edu/handle/1721.1/1519>.
[Blumenthal01] Blumenthal、M。およびD. Clark、「インターネットのデザインを再考する：エンドツーエンドの議論vs. The Brave New World」、2001年5月、<http://dspace.mit.edu/handle/1721.11/1519>。
[Broido02] Broido, A., Nemeth, E., Claffy, K., and C. Elves, "Internet Expansion, Refinement and Churn", February 2002.
[Broido02] Broido、A.、Nemeth、E.、Claffy、K。、およびC. Elves、「インターネットの拡大、改良、解約」、2002年2月。
[CIDR] Telcordia Technologies, "CIDR Report", <http://www.cidr-report.org/>.
[CIDR] Telcordia Technologies、「CIDR Report」、<http://www.cidr-report.org/>。
[Chiappa02] Chiappa, N., "A New IP Routing and Addressing Architecture", July 1991, <http://ana-3.lcs.mit.edu/~jnc/nimrod/overview.txt>.
[Chiappa02] Chiappa、N。、「新しいIPルーティングとアドレス指定アーキテクチャ」、1991年7月、<http://ana-3.lcs.mit.edu/~jnc/nimrod/overview.txt>。
[Clark91] Clark, D., "Quote reportedly from IETF Plenary discussion", 1991.
[Clark91] Clark、D。、「IETF Plerenary Discussionからの引用」、1991年。
[DiffservAR] Seddigh, N., Nandy, B., and J. Heinanen, "An Assured Rate Per-Domain Behaviour for Differentiated Services", Work in Progress, July 2001.
[Diffservar] Seddigh、N.、Nandy、B。、およびJ. Heinanen、「差別化されたサービスのドメインごとの保証率」、2001年7月の作業。
[DiffservVW] Jacobson, V., Nichols, K., and K. Poduri, "The 'Virtual Wire' Per-Domain Behavior", Work in Progress, July 2000.
[diffservvw] Jacobson、V.、Nichols、K。、およびK. Poduri、「ドメインごとの「仮想ワイヤ」の動作」、2000年7月の進行中。
[Griffin99] Griffin, T. and G. Wilfong, "An Analysis of BGP Convergence Properties", SIGCOMM 1999.
[Griffin99] Griffin、T。およびG. Wilfong、「BGP収束特性の分析」、Sigcomm 1999。
[ISO10747] ISO/IEC, "Protocol for Exchange of Inter-Domain Routeing Information among Intermediate Systems to Support Forwarding of ISO 8473 PDUs", International Standard 10747 ISO/IEC JTC 1, Switzerland, 1993.
[ISO10747] ISO/IEC、「ISO 8473 PDUSの転送をサポートするための中間システム間の情報交換情報の交換のためのプロトコル」、国際標準10747 ISO/IEC JTC 1、スイス、1993年。
[InferenceSRLG] Papadimitriou, D., Poppe, F., J. Jones, J., S. Venkatachalam, S., S. Dharanikota, S., Jain, R., Hartani, R., and D. Griffith, "Inference of Shared Risk Link Groups", Work in Progress, November 2001.
[推論Rlg] Papadimitriou、D.、Poppe、F.、J。Jones、J.、S。Venkatachalam、S.、S。Dharanikota、S.、Jain、R.、Hartani、R.、およびD. Griffith、共有リスクリンクグループの推論」、2001年11月、進行中の作業。
[ODell01] O'Dell, M., "Private Communication", 2001.
[Odell01] O'Dell、M。、「プライベートコミュニケーション」、2001年。
[RFC1126] Little, M., "Goals and functional requirements for inter-autonomous system routing", RFC 1126, October 1989.
[RFC1126] Little、M。、「自律システム間ルーティングの目標と機能的要件」、RFC 1126、1989年10月。
[RFC1726] Partridge, C. and F. Kastenholz, "Technical Criteria for Choosing IP The Next Generation (IPng)", RFC 1726, Dec 1994.
[RFC1726] Partridge、C。およびF. Kastenholz、「IPを選択するための技術基準（IPNG）」、RFC 1726、1994年12月。
[RFC1992] Castineyra, I., Chiappa, N., and M. Steenstrup, "The Nimrod Routing Architecture", RFC 1992, August 1996.
[RFC1992] Castineyra、I.、Chiappa、N。、およびM. Steenstrup、「Nimrod Routing Architecture」、RFC 1992、1996年8月。
[RFC2071] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC 2071, January 1997.
[RFC2071] Ferguson、P。およびH. Berkowitz、「ネットワークの名前を変更する概要：なぜ私はそれが欲しいのか、とにかくそれは何ですか？」、RFC 2071、1997年1月。
[RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
[RFC2072] Berkowitz、H。、「ルーターのレニンバーガイド」、RFC 2072、1997年1月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[RFC3221] Huston、G。、「インターネット内のドメイン間ルーティングに関する解説」、RFC 3221、2001年12月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260] Grossman、D。、「Diffservの新しい用語と説明」、RFC 3260、2002年4月。
[RFC3344] Perkins, C., "IP Mobility Support.", RFC 3344, August 2002.
[RFC3344] Perkins、C。、「IP Mobility Support」、RFC 3344、2002年8月。
[RFC3345] McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, August 2002.
[RFC3345] McPherson、D.、Gill、V.、Walton、D。、およびA. Retana、「Border Gateway Protocol（BGP）永続的なルート振動条件」、RFC 3345、2002年8月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger、L。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナル伝達機能説明」、RFC 3471、2003年1月。
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
[RFC3963] Devarapalli、V.、Wakikawa、R.、Petrescu、A。、およびP. Thubert、「ネットワークモビリティ（NEMO）基本的なサポートプロトコル」、RFC 3963、2005年1月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想ネットワーク（VPNS）」、RFC 4364、2006年2月。
[RFC5773] Davies, E. and A. Doria, "Analysis of Inter-Domain Routing Requirements and History", RFC 5773, February 2010.
[RFC5773] Davies、E。およびA. Doria、「ドメイン間のルーティング要件と履歴の分析」、RFC 5773、2010年2月。
[Wroclawski95] Wroclowski, J., "The Metanet White Paper - Workshop on Research Directions for the Next Generation Internet", 1995.
[wroclawski95] wroclowski、J。、「メタネットホワイトペーパー - 次世代インターネットの研究方向に関するワークショップ」、1995年。
[netconf-charter] Internet Engineering Task Force, "IETF Network Configuration working group", 2005, <http://www.ietf.org/html.charters/netconf-charter.html>.
[NetConf-Charter]インターネットエンジニアリングタスクフォース、「IETFネットワーク構成ワーキンググループ」、2005、<http://www.ietf.org/html.charters/netconf-charter.html>。
[policy-charter02] Internet Engineering Task Force, "IETF Policy working group", 2002, <http://www.ietf.org/html.charters/OLD/ policy-charter.html>.
[Policy-Charter02]インターネットエンジニアリングタスクフォース、「IETFポリシーワーキンググループ」、2002、<http://www.ietf.org/html.charters/old/ policy-charter.html>。
[rap-charter02] Internet Engineering Task Force, "IETF Resource Allocation Protocol working group", 2002, <http://www.ietf.org/html.charters/OLD/rap-charter.html>.
[RAP-Charter02]インターネットエンジニアリングタスクフォース、「IETFリソース割り当てプロトコルワーキンググループ」、2002、<http://www.ietf.org/html.charters/old/rap-charter.html>。
[snmpconf-charter02] Internet Engineering Task Force, "IETF Configuration management with SNMP working group", 2002, <http:// www.ietf.org/html.charters/OLD/snmpconf-charter.html>.
[SNMPCONF-CHARTER02]インターネットエンジニアリングタスクフォース、「SNMPワーキンググループによるIETF構成管理」、2002年、<http：// www.ietf.org/html.charters/old/snmpconf-charter.html>。
Authors' Addresses
著者のアドレス
Avri Doria LTU Lulea 971 87 Sweden
Avri Doria Ltu Lulea 971 87 Sweden
Phone: +46 73 277 1788
EMail: avri@ltu.se
Elwyn B. Davies Folly Consulting Soham, Cambs UK
Elwyn B. Davies Folly Consulting Soham、Cambs UK
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Frank Kastenholz BBN Technologies 10 Moulton St. Cambridge, MA 02183 USA
フランク・カステンホルツBBNテクノロジーズ10モールトンセントケンブリッジ、マサチューセッツ州02183 USA
Phone: +1 617 873 8047
EMail: frank@bbn.com