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.
この文書に記載されアーキテクチャをルーティングするための要件は2006年まで、いくつかの編集更新と、2001年IRTFルーティング研究グループ（RRG）下の2つのサブグループによって生成された2つのサブグループは、独立して働いて、得られた要件は、二つを表します問題の問題を修正するために必要とされるものの別の景色。この文書は、有効将来的には、インターネットのためのアーキテクチャ設計をルーティングする上で動作し、誰のための推奨読書の一部として機能することができます。
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.
この文書は、インターネットコミュニティのための歴史的な文書を定義します。この文書はインターネットResearch Task Force（IRTF）の製品です。 IRTFはインターネット関連の研究開発活動の成果を公表しています。これらの結果は、展開に適していない可能性があります。このRFCはインターネットResearch Task Force（IRTF）のルーティング研究グループの1つまたは複数のメンバーの個々の意見（複数可）を表しています。 IRSGによって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5772.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. 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）椅子、アブハアフジャとショーン・ドーランは、ドメイン間ルーティング（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.
同時に、独立した努力は、同様の目的で、スウェーデンで開始されました。ベンダー、サービスプロバイダー、および学界からの参加を得て、自らバビロンを呼び出すチームは、ドメイン間ルーティングの歴史を理解するために、サービスプロバイダから見た問題を調査するために、そして後続のための要件の提案を開発するために組み立て現在のルーティングアーキテクチャへ。このグループの任務は、現在のルーティングアーキテクチャと実践から始まる進化のアプローチが必要。換言すれば、グループは、進化戦略の開発に自分自身を制限しました。バビロン基は、後に元のRRGサブグループAからそれを区別するためにサブグループBとしてIRTF RRGに折り畳まれました
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.
グループが孤立して作業している間に生じた問題の一つは、要件の彼らのセット間の多くの類似点があることになるかどうかということでした。白紙から育った要件は、進化的なアプローチを開始しているものに似ているということは、ありますか？要件の二組を読んでからわかるように、多くの基本的な合意の領域が、不一致のいくつかの領域がありました。
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.
2つのチームが要件の一つのセットを作成するために協力すべきであるRRG内の提案がありました。これらの要件は、将来の仕事への唯一のガイドラインですので、しかし、いくつかはそうすることが任意の特定の利点を得ることなく、コンテンツを失う危険だろうと感じました。任意のグループかのように、例えば、IRTF RRGまたはIETFルーティングエリアは、書かれたように、これらの要件を使用すると、これらの要件を満たしアーキテクチャを作成することが期待されたされていません。むしろ、要件は、新たなルーティングアーキテクチャを作成して進行する方法を実際の強い勧告していました。最後に、決定は、一つの文書の両方の努力、横並びの結果を含むように作製しました。
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は、それが必ずしも公開時点での最新の技術の理解や研究グループの技術的なコンセンサスのいずれかを表すものではないことを理解した上で完了した作業の歴史的な記録として、本書の出版をサポート。文書には、年間で、両チームのメンバーは、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で行われた仕事の結果を示します。仕事はもともとタイトルで登場：「次世代ルーティングのための要件とアドレッシングアーキテクチャ」とフランクKastenholzとによって編集されました。
2.1. Group A - Requirements for a Next Generation Routing and Addressing Architecture
2.1. グループ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.
アーキテクチャは、交換または既存のコンポーネントをアップグレードし、システムの残りの部分を中断することなく、新しいものを追加する能力を持っている必要があります。オペレータは増分これらの変更や追加（すなわち、NO「フラグの日」）をロールアウトすることができなければなりません。これらの能力は、アーキテクチャは、インターネットの変化に応じて進化できるようにするために必要とされています。
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]
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年間、私たちのニーズに応えるます。残念ながら：
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:
その結果、我々はいかなる意味のある方法で要件を定量化することはできません。物事を記述するための仕組みとして、今日の建築要素を使用して、我々はネットワークがに成長できると信じています：
Editors' Note: As of 2005, this level had already been
reached.
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.
特定のネットワークのサイズのために設計された新しいルーティングおよびアドレス指定アーキテクチャは不適切であろう。まず、ルーティング計算のコストは、ネットワーク内のASまたはプレフィックスの数のみに部分的に基づいています。数およびネットワーク内のリンクの位置も重要な要因です。第二に、インターネットの成長とトポロジーパターンの過去の予測が乱暴に不正確であることが証明されているので、特定のサイズのゴールがアーキテクチャを開発することがせいぜい近視眼的になります。
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.
編集者注：これらの会議の時には、BGPの統計情報は、www.routeviews.orgなどのサイトに保っも存在していなかったか、ほんの数ヶ月のために実行していました。 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. 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.ネットワーク帯域幅と遅延は、ルーティングプロトコルの更新は（ルーティングシステムは変化に適応することができますどのくらいの速のでと）普及することができますどのくらいの速にいくつかの重要な制約です。生のネットワーク帯域幅は、3年ごとかそこら4倍に思えます。しかし、いくつかの深刻な物理学の問題はより速く40ギガビット/秒（OC768）より予定であると思われます。私たちは生のネットワークのリンク速度が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.高速RAMの速度（キャッシュ等に用いられるスタティックRAM（SRAMは）、）、成長しています。そのため、キャッシュおよび他の非常に特定のアプリケーションでの使用のため、これらのRAMは、数メガビット小さくなる傾向にあり、これらのRAMのサイズが非常に急速に増加していません。
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.
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.
編集者注：種々の技術が大幅にメモリ帯域幅を増加しています。 800 MHzのは、2000年に100 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.
いずれかのルータに利用可能なリソースの成長は、最終的に遅くなります。それも、停止することがあります。そうであっても、ネットワークが成長していきます。ルーティングとアドレス体系も、この極端な条件を中に拡大し続けなければなりません。私たちは永遠にルータに多くのコンピューティングパワーを追加し続けることはできません。他の戦略が利用可能でなければなりません。いくつかの可能な戦略は、階層、抽象化、およびトポロジー情報の集合体です。
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とピアリング、と。これらの接続は、このようなようになって、より多くの帯域幅、増加信頼性と可用性、ポリシー、およびなど多くの理由のために作られています。しかし、この増加した相互接続は、価格を持っています。それはネットワークのパス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.
この要件の別の面は、先に利用可能な複数の有効な、ループのないパスが存在する可能性があることです。さらなる議論については、セクション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の本来の設計目標の一つは、（例えば、核戦争の顔のように）非常に存続可能となり、大規模で頻繁に相互接続されたネットワークをサポートするためだったことに注意してください。
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".
「マルチホーミング」という用語は最も広義に解釈することができる - 一つの「場所」とは、別の「場所」への複数の接続またはリンクがあります。
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つのパスは「主」と他の「バックアップ」と宣言することができると、主に障害が発生した場合にのみ使用されるように）どのパス（複数可）を宣言する能力を持っている必要があります。
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,
トラフィックを分類し、異なるパスへのトラフィックのクラスを割り当てる（または特定のパスからそれを禁止する）ための規則を指定するための豊富な「言語」がなければなりません。 、IPv6のFlowIDs○：ルールは、トラフィックの分類、に基づいて、少なくとも、以下のことができるようにする必要があります
o Diffserv Code Point (DSCP) values,
Diffservのコードポイント（DSCP）値は、O、
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.
（また、「安定時間」と呼ばれる）の収束の速さは、ルータのルーティングプロセスは、ネットワークの変化どこかの後に新たな、安定した、「溶液」（すなわち、転送情報ベース）に到達するのにかかる時間です。ソフトウェアのN番目の反復は、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つの変更のためのソリューションを安定させるために、それはS秒を要するものとします。また、変更が発生することを前提とし、平均して、すべてのC秒。なぜなら、インターネットのサイズと複雑さ、Cは現在変化、C1は、時間Tで発生した場合、Sはしたがって、ルーティングシステムは、時間T + Sで安定させるだろうが、新たな変化、C2は、発生する未満でありますT + S前の時刻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:
我々は、収束に対する要求事項を設定することができ、その上二つの別々のスコープを持っています：
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:
第二の要件は、以下の仮定に基づいています。
- 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.内ルピールータがあります。
- 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).
- 私たちは、変更後のTc秒のY％以内の変更、のZ％のため、Cは、ルピールータの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.
この要件は、スコープが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.
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 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:
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およびIPv6の/ 128秒間、すなわち、/ 32秒）、及び
* Traffic matrices (e.g., traffic from prefix X and to prefix Y).
*交通行列（Yを先頭に付加するなど、プレフィックスXからのトラフィックと）。
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.
編集者注：この作業の時以来、ネットワークモビリティ（NEMO）モバイルネットワークに対応するためのモバイルIP [RFC3963]の拡張機能が開発されています。
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.
現在のインターネット政治情勢に大きな「ホットアイテム」の一つは、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.
ルーティングで非常に知識が豊富で、簡単でシンプルな説明を作成するに熟練している誰かが時間未満のすべての重要な概念を説明することができるようにアーキテクチャが十分に単純である必要があります。
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.
インターネットの成功に大きく貢献は、ネットワーク全体の制御やポリシーのpromulgatorのない単一の集中、ポイントが存在しないという事実です。これは、ネットワークの個々の成分が自分のニーズに合わせて、独自のネットワーク、環境、およびポリシーをカスタマイズすることができます。個々の構成要素は、彼らが相互運用することを確実にするためにのみ必要な程度に協力しなければなりません。
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.
「協力的アナーキー」と呼ばれるこの分散化は、まだ今日のインターネットの重要な特徴です。新しいルーティングアーキテクチャでは、この機能を保持しなければなりません。インターネット全体の制御やポリシーのpromulgatorのない集中型のポイントがあってはいけません。
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で動作しなければならない/モデルを逆多重化。しかし、アーキテクチャは、これらのモデルに限定される必要はありません。追加の転送およびマルチプレックスは/逆多重化モデルを追加してもよいです。
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.
私たちは、明示的にインターネットが複数の管理エンティティの制御下のリソースで構成されていることを認識しています。各エンティティは、それが適当と考えるよう、インターネットの自身の部分を管理できなければなりません。また、ルーティングに課さ一回の投与の制御の下で、インターネットの一部に対処することができる制約が実行可能に複数回の投与をカバーするように拡張されなくてもよいです。したがって、我々は、ルーティングの間に自然と必然的な分割を認識して、それを対処することは、単一の管理制御およびルーティングの下にあり、対処することが、複数の管理エンティティを含んでいます。複数の管理当局が存在してもよいしながらまた、管理権限の境界ではなく、厳密な階層であるよりも、複雑で重複してもよいです。
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の人々を要求する場合は、1が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):
私たちは、1つの尊敬のネットワークセージは[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...
あなたがネットワークにいくつかの特に醜い問題を解決するために自分自身を祝福の周りに立ってエンジニアの束を見ると、彼らに上がる、ささやく「マルチキャスト」、バックジャンプ、そして楽しみが始まる見ます...
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]でホスト単位で処理されます。モバイルホスト宛てのトラフィックを明示的に専用のリレーエージェントによって転送されます。モバイル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が行った作業の結果です。もともとはタイトルの下でリリースされました：「未来ドメインルーティング要件」とAvriドリアとエルウィン・デイヴィスが編集しました。
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).
- 要件のソリューションを前提としてはなりません。ドメイン間およびドメイン内ルーティングの間の現在の定義と分割する継続的なコミットメントは、このような前提を構成するであろう。したがって、文書のこの部分は、名前フューチャードメインルーティング（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.
この文書では、そのコレクションを定義し、ポリシーが制御する属性を決定し、共通の権限の下に来るシステムまたはドメインの任意の集合を意味するように、非常に広い意味での「ドメイン」を使用しています。このように「ドメイン」の使用は、彼のMetanetモデル[Wroclawski95]ジョンWroclawskiによって示さ置かれた地域の概念に非常によく似ています。アイデアは、特定の属性は、ドメイン内のシステムの動作を特徴付けるし、ドメイン間の国境があるだろうという考えが含まれています。ここで紹介するドメインのアイデアは、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.
- VPNおよびIPv4とIPv6とのプライベートアドレス空間を使用します。
- 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]環境によって供給され、このような明示的なルーティング（パイプ）のような代替的な転送技術の取り込み。
- 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.
- 他の層（例えば、共有リスクリンクグループ[InferenceSRLG]）との相互作用からルート決意に追加の制約の組込み。それらは物理的に同一のトレンチ内に実行されるため、これは、例えば、冗長経路が運命シェアないことを懸念を含みます。
- 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.
したがって、このアーキテクチャの目的は、現在の共通分母であるベストエフォート型のデータグラム接続サービス以外のビット・トランスポート・サービスの配信を可能にするために、パスサービスの特性に関する十分な情報が結果的ドメインとの間を通過するようにすることです。
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.
回路ベースの技術の出現により（例えば、MPLS [RFC3031]とGMPLS [RFC3471]）は、ルーティングアーキテクチャによってサポートされる必要があるデータグラムサービス以外の転送メカニズムが存在するIPルータが管理します。
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).
このアーキテクチャの目標は、コントロールとフォワーディングの完全な分離をサポートするために、追加の懸念が適切に（例えば、隣接管理）個別に考慮されるかもしれないものを考えることです。
3.2.3.7. Different Routing Paradigms in Different Areas of the Same Network
3.2.3.7。同じネットワークの異なる領域に異なるルーティングパラダイム
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.
新しいパラダイムは、今日のシステムとの後方互換性のある方法で相互運用するように明示的に、これらのルーティングパラダイムの一つは、現在のルーティングパラダイムでなければなりません。これは、フラグの日を避け移行戦略を促進します。
3.2.3.8. Protection against Denial-of-Service and Other Security Attacks
3.2.3.8。サービス拒否およびその他のセキュリティ攻撃に対する保護
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.
これは、グリフィンらによって、解析の両方が示されています。ポリシーの制約の特定のタイプである場合（すなわち、単一の障害に直面して、収束再ない）BGPが安定収束のみ準安定でないこと（[RFC3345]を参照）、実用上（[Griffin99]を参照）、およびネットワークトポロジのカテゴリに適用されます。基本的な距離ベクトルアルゴリズムにポリシーを追加するには、ポリシー・フリーな実装に適用することができ、収束の証明を無効化します。
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]、および[ポリシー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とラップが過去の希望です。今日では、コンフィギュレーションおよびポリシーの希望は、NETCONF [NETCONF-チャーター]に焦点を当てています。
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
RFC 1126は、BGPの開発を導くために使用された要件のセットを概説しました。ネットワークは、1989年以来、年に変更されていますが、同じ要件の多くが残っています。将来のドメインのルーティングソリューションは、その基本要件、今日利用できる機能のレベルとして、サポートする必要があります。 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.
そしてその要件は[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.
ネットワーク・ドメイン・グラフの葉は、単一の企業をサポートする多くの場合、ネットワークです。このようなネットワークは複雑の巨大な範囲をカバーしています。いくつかの多国籍企業の複雑さに匹敵し、多くは、スモールオフィス・ホームオフィス（SOHO）カテゴリーに分類されるのに対して、GSPの到達独自のネットワーク。効果的に、より大きな企業をサポートしながら、ルーティングシステムは、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.
企業は自社のネットワークの回復力を向上させる一つの可能な手段として、一の以上のプロバイダにマルチホームにできるようにしたいでしょう。
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企業ネットワークのようになります。
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.
サービスプロバイダ、学術ネットワーク、および大企業のピアリングは、多くのネットワークが比較的小さい物理的領域で一緒にリンクされている特定のインターネットエクスチェンジでますます起こっています。為替のリソースは、信頼できる第三者が所有または接続するネットワークが共同で所有することができます。ルーティングシステムは、いずれかの論理的に劣る、または1つ（またはすべての）接続されたネットワークのメンバーである交換ポイントを要求することによって、すべての接続されたネットワークとの優れたエンティティとして動作するように交換ポイントを必要とすることなく、そのような交換ポイントをサポートすべきです。接続ネットワークは、交換点オペレータに信頼のある量を委任しなければなりません。
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のプロバイダは、順番に同じプロバイダからレイヤ1つのサービスを購入二つの別々のプロバイダからのレイヤ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.
バックホーは、トレンチをカットする際に今、レイヤ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.
いくつかの作品は、このような共有リスクリンクグループ[InferenceSRLG]の作業として、この要件から生じる問題、のようなものを理解するために起こっています。残念ながら、問題の完全な一般には多様性が、相互不信のプロバイダの任意の大規模なセットの間の時間にわたって維持することが必要です。いくつかのケースでは、多様性がプロビジョニングまたはルートインスタンス化時にチェックされることが十分であるかもしれないが、これは研究作業を必要とする困難な問題のまま。
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.ホストの数今日は億のエリアのどこかにあります。ダイヤルイン、NATの、およびIPv6の普遍的展開では、この500万人のユーザー（[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.
2002年の初めに4、12000の登録ASの周りがあります。 ASの現在の使用（例えば、マルチホーミング）とのASの数は、約10年[Broido02]で25000まで成長すると期待できます。これがダウンし、年間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.
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とオペレータに内部方針に示されています。これは世界的に見えるようにすることはドメインの数を作成します。 ASの10~100倍の数、すなわち、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）のための2 Mbpsに10 kbpsのを持っていますセル内のユーザーとわずかな細胞が実際にこの速度に達しますが、無線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.仮定7と一緒になって8は、10 Gbpsの2.4 kbpsの間の帯域幅の最小スパンを示唆しています。
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.バックボーンにおける速度は急速に成長してきた、そして成長は今後数年間で停止することを示す証拠はありません。テラビット速度は数年で最小のバックボーンの速度である可能性が高いです。表現する必要がある帯域幅の範囲は、プロトコルの値を表す方法についての検討が必要になります。
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
このセクションでは、将来ドメインルーティングアーキテクチャのための新しい要件の詳細な議論を含んでいます。 n番目の要件は、ラベル「R（N）」を運びます。セクション3.2.3.12、新しいアーキテクチャで説明したように
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].
過去のルーティングフレームワークの要件に構築しなければならないし、ネットワークの機能を低下させなければなりません。 RFCの議論および分析1126枚の要件は[RFC5773]に見出すことができます。
3.6.1.1. Routers Should Be Able to Learn and to Exploit the Domain Topology
3.6.1.1。ルータは、学習することができるはずとドメイントポロジを利用するために
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]は位相的に関連するドメインのコレクションはニムロッド[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）ルータは、適切な場合、トポロジの一部領域の地形的特徴の集合を表すトポロジーの抽象化を構築することができなければなりません。
3.6.1.2. The Same Topology Information Should Support Different Path Selection Ideas
3.6.1.2。同じトポロジ情報が異なるパス選択のアイデアをサポートする必要があります
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）ルータは異なる経路選択アルゴリズムの小さな数をサポートすることができなければなりません。
3.6.1.3. Separation of the Routing Information Topology from the Data Transport Topology
3.6.1.3。データ転送トポロジからルーティング情報トポロジの分離
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.
二つの機能「平面」は、物理的に同じノードに存在し、同じリンクを共有し、これは唯一の可能性ではなく、他のオプションが時々必要であるかもしれないことができます。例では、外部コントローラと組み合わされ、純粋な回線交換（すなわち、個々のIPパケットを見ることができない）です。別の例では、すべてのリンクがデータ転送に使用されるが、一つだけがルーティングセッションを搬送するために使用される2つのルータ間の複数のリンクであってもよいです。
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]によって開発されたサービスレベル仕様（SLSS）をサービス仕様をサポートしなければなりません。
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のホップ単位動作（の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コストを」ルート。
- 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で障害を検出する手段として、キープアライブまたは「ハロー」プロトコルを利用しています）ルーティングノードと通信リンクに組み込まれています。一度に一つだけの修復機構が任意の障害を修復することが許可されていることを保証しながら細心の注意は、さまざまな障害の修復方法の最善の使用が利用できるように注意する必要があります。
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).
特殊なパケット交換機構（例えば、レイヤ3キープアライブまたは「ハロー」プロトコルメカニズム）が障害を検出するために使用されるR（25）は、ルーティングシステムは、これらのキープアライブの伝送速度の設定を可能にしなければなりません。これが本当のユーザーまたは制御トラフィックが（例えば、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）ルーティングシステムは、ユニキャストアドレスのスコープをサポートする必要があり、それはマルチキャストおよびエニーキャストアドレスタイプのスコープをサポートしなければなりません。
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によって推奨されていません。リンクローカルアドレスは、すべてのルーティングされることはありません。
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.
より多くの研究では、より一般的な意味でスコープ用およびマルチキャストおよびエニーキャストアドレスのスコープのための要件とソリューションを識別するために必要な場合があります。
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.
今日のネットワークにおける主要な問題は、遠隔管理システムを引き継ぐことができる前に、ローカルインターフェイスからルータ上で初期設定を行う必要があります。のZeroconfホストのために必要とされるものを超えてルーティングアーキテクチャ上の任意の要件を課していることは明らかではありません。
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.
私たちの仮定の一つは、NATをして、ファイアウォール、Webプロキシ、およびアドレスファミリの翻訳者（IPv6へ例えば、IPv4）のようなその他のミドルボックスがここに滞在していることです。
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）ローカル収束時間のT単位内で起こるべきです。
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つの要件は、移行戦略のためだけでなく、アーキテクチャ自体のためだけではなく、意味を持っています。彼らは、新しいFDR内ドメインとして存在し、それは、このような今日のBGP-制御ネットワーク、またはそののASの一つとして、インターネットのために可能でなければならないことを意味します。
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.
前述したように、創業以来、インターネットを抜いて大きな変化の一つは、それらのユーザーやサービスのサプライヤーとの間で、ネットを利用したエンドユーザー間の信頼の浸食であり、プロバイダの多重度の間。そのため、セキュリティは、そのすべての面で、はるかに重要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),
- すべての情報を受信し、両当事者は、（検証および否認防止）送信されたものに同意することをされていることを確認することが可能であるかどうか、
- 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!
決定は、（私たちは誰仲間を信頼して私たちの仲間を信頼して...）信頼の連鎖に依存するかどうかで行わなければならず、または我々はまた、情報の認証と完全性を必要とするかどうかをエンド・ツー・エンド。この情報は、ルートとアドレスの両方を含んでいます。発信者がプレフィックスを通知する権限を持っていることを確認するために、アドレス当局によって発信ルートだけでなく、countersignaturesにデジタル署名を持つことに関心がありました。それは（バック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.
- また、ポリシーの制限内で詳細を照会するメカニズムがある場合は、1つは、より多くの集約を許可することができます。
- 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.
他のすべてのフィールドのように、単語が概念を参照して、重要なルーティングに関する動作を説明するために使用されます。不正確またはめったにネットワーキングの現実の世界で使用されていない用語を使用して概念を説明するのではなく、正しい単語を使用するための努力を行う必要があります。多くのネットワーキング用語が何気なく使用され、その結果は、基礎となる概念の部分的または不正な理解です。このようなノード、インターフェース、サブネットワーク、トンネル、およびそのようなのAS、ドメイン、領域、及び領域としてグループ化の概念などのエンティティは、明確に識別され、混乱を避けるために定義する必要があります。
There is also a need to separate identifiers (what or who) from locators (where) from routes (how to reach).
路線からロケータ（）（到達する方法）から識別子（何か）を分離する必要もあります。
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つのルータ間、いくつかの個々の接続がダウンしても生き残る必要があります。
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.
上下両方向における複数のレベルと再帰グループと、より柔軟な階層は、より構造化されたルーティングを可能にします。その結果は、単一のレベルは、ルータが処理するには大きくなりすぎないということです。
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.
要件ビザンチン将軍問題を解決されていますか？これは、それらのいくつかは、誤解を招くような答えを与える場合には、分散ユニット間で合意に達することが問題です。現在のドメイン内ルーティングシステムが誤解を招く情報の完全不耐性、1つのレベルで、です。しかし、誤解を招くまたは誤った情報の異なる種類の効果が大幅に総崩壊から単一ドメインの純粋にローカル断線に、結果を変えました。行動のこの種は非常に望ましいものではありません。
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].
RFC 4364 [RFC4364]に記載されているように今日では、BGPはまた、例えば、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グループA：頑健性 - セクション2.1.18
o Group B: Protection against Denial-of-Service and Other Security Attacks - Section 3.2.3.8
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での二つのグループの組み合わせの努力です。 IRTFのルーティング研究の椅子によって形成されたグループA、および自己形成された以降IRTFのルーティング研究グループに折り畳まれたグループB、。各グループは、その確認応答の独自のセットを持っています。
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.
我々はまた蘭アトキンソン、ハワード・バーコウィッツ、ランディブッシュ、Avriドリア、ジェフリーハース、ドミトリKrioukov、ラスホワイト、およびアレックスジニンから受け取ったコメントやレビューを感謝しています。テキストの貢献のためとクリスマスChiappaにヤコフRehkterに感謝します。
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.
このドキュメントに著しく貢献した個々のメンバーは以下のとおりです。アンダースバーグステン、ハワード・バーコウィッツ、マリンCarlzon、レンカ・カーMotyckova、エルウィン・デイヴィス、Avriドリア、ピエールFransson、龍江、ドミトリKrioukov、トーベ・マドセン、オルレペールス、およびOlov Schelen。
Thanks also go to the members of Babylon and others who did substantial reviews of this material. Specifically, we would like to acknowledge the helpful comments and suggestions of the following individuals: Loa Andersson, Tomas Ahlstrom, Erik Aman, Thomas Eriksson, Niklas Borg, Nigel Bragg, Thomas Chmara, Krister Edlund, Owe Grafford, Torbjorn Lundberg, Jeremy Mineweaser, Jasminko Mulahusic, Florian-Daniel Otel, Bernhard Stockman, Tom Worster, and Roberto Zamparo.
おかげでも、この物質の実質的なレビューをしたバビロンのメンバーや他の人に行きます。具体的には、以下の個人の有益なコメントや提案承認したいと思います：ロア・アンダーソン、トーマスアールストロム、エリック・アマン、トーマス・エリクソン、ニクラス・ボルグ、ナイジェル・ブラッグ、トーマスChmara、クリスターEdlund、Graffordを借りて、Torbjornランドバーグ、ジェレミーMineweaserを、 Jasminko Mulahusic、フロリアン・ダニエルオテル、ベルンハルト・ストックマン、トムWorster、そしてロベルトZamparo。
In addition, the authors are indebted to the folks who wrote all the references we have consulted in putting this paper together. This includes not only the references explicitly listed below, but also those who contributed to the mailing lists we have been participating in for years.
また、著者は、私たちは一緒にこの論文を置くことで相談しているすべての参照を書いた人たちにお世話になっています。これは、明示的に、下記の言及はなく、私たちは長年に参加しているメーリングリストに貢献した人たちだけでなく、。
The editors thank Lixia Zhang, as IRSG document shepherd, for her help and her perseverance, without which this document would never have been published.
編集者は、この文書が公開されていないだろうこれなしで彼女の助けと彼女の忍耐力、のために、IRSGのドキュメント羊飼いとして、Lixiaチャンに感謝します。
Finally, it is the editors who are responsible for any lack of clarity, any errors, glaring omissions or misunderstandings.
最後に、それは明快、すべてのエラー、明白な不作為または誤解の欠如を担当する編集者です。
[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]ブルーメンソール、M.とD.クラーク、「インターネットのデザイン再考：勇敢な新しい世界対引数を端から端まで」、2001年5月、<http://dspace.mit.edu/handle/1721.1 / 1519>。
[Broido02] Broido, A., Nemeth, E., Claffy, K., and C. Elves, "Internet Expansion, Refinement and Churn", February 2002.
[Broido02] Broido、A.、ネメス、E.、Claffy、K.、およびC.エルフ、 "インターネットの拡大、洗練と解約"、2002年2月。
[CIDR] Telcordia Technologies, "CIDR Report", <http://www.cidr-report.org/>.
[シドル] telakaradiya技術、 "レポートシドル"、<HTTP：ooosidarariportaarga>。
[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]クラーク、D.、1991年 "IETF総会の議論から伝え引用"。
[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]ジェーコブソン、V.、ニコルズ、K.、およびK. Poduri、 "ドメイン単位の行動 '仮想ワイヤ'"、進歩、2000年7月の作業。
[Griffin99] Griffin, T. and G. Wilfong, "An Analysis of BGP Convergence Properties", SIGCOMM 1999.
【Griffin99]グリフィン、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、国際標準10747 ISO / IEC JTC 1、スイス、1993年 "中間システムの中でドメイン間のRouteing情報の交換は、ISO 8473のPDUの転送をサポートするための議定書"。
[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.
【InferenceSRLG] Papadimitriou、D.、Poppe、F.、J.ジョーンズ、J.、S. Venkatachalam、S.、S. Dharanikota、S.、ジェイン、R.、Hartani、R.、およびD.グリフィス、 "共有リスクリンクグループ」、進歩、2001年11月の作業の推論。
[ODell01] O'Dell, M., "Private Communication", 2001.
[ODell01]オデル、M.、 "プライベート・コミュニケーション"、2001年。
[RFC1126] Little, M., "Goals and functional requirements for inter-autonomous system routing", RFC 1126, October 1989.
[RFC1126]リトル、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]ヤマウズラ、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、 "ニムロッドルーティングアーキテクチャ"、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]ファーガソン、P.とH.バーコウィッツ、「ネットワークのリナンバリングの概要：なぜ私はそれをしたいだろうし、それはとにかく何ですか？」、RFC 2071、1997年1月。
[RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
[RFC2072]バーコウィッツ、H.、 "ルータリナンバリングガイド"、RFC 2072、1997年1月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC3221] Huston, G., "Commentary on Inter-Domain Routing in the Internet", RFC 3221, December 2001.
[RFC3221]ヒューストン、G.、 "インターネットにおけるドメイン間ルーティングの解説"、RFC 3221、2001年12月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260]グロスマン、D.、 "Diffservのための新しい用語と明確化"、RFC 3260、2002年4月。
[RFC3344] Perkins, C., "IP Mobility Support.", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、 "IPモビリティのサポート。"、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]マクファーソン、D.、ギル、V.、ウォルトン、D.、およびA. Retana、 "ボーダーゲートウェイプロトコル（BGP）永続的なルート発振条件"、RFC 3345、2002年8月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、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.、ペトレスク、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]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、RFC 4364、2006年2月。
[RFC5773] Davies, E. and A. Doria, "Analysis of Inter-Domain Routing Requirements and History", RFC 5773, February 2010.
[RFC5773]デイヴィス、E.およびA.ドリア、「ドメイン間ルーティングの要件の分析と歴史」、RFC 5773、2010年2月。
[Wroclawski95] Wroclowski, J., "The Metanet White Paper - Workshop on Research Directions for the Next Generation Internet", 1995.
[Wroclawski95] Wroclowski、J.、「Metanetホワイトペーパー - 次世代インターネットのための研究の方向性に関するワークショップ」、1995年。
[netconf-charter] Internet Engineering Task Force, "IETF Network Configuration working group", 2005, <http://www.ietf.org/html.charters/netconf-charter.html>.
[NETCONF-チャーター]インターネットエンジニアリングタスクフォース、 "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>.
[ポリシーcharter02]インターネットエンジニアリングタスクフォース、 "IETF方針ワーキンググループ"、2002年、<http://www.ietf.org/html.charters/OLD/ポリシー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ドリアLTUルーレオ971 87スウェーデン
Phone: +46 73 277 1788 EMail: avri@ltu.se
電話：+46 73 277 1788 Eメール：avri@ltu.se
Elwyn B. Davies Folly Consulting Soham, Cambs UK
エルウィンB.デイヴィスフォリーコンサルティングソーハム、Cambsの英国
Phone: +44 7889 488 335 EMail: elwynd@dial.pipex.com
電話：+44 7889 488 335 Eメール：elwynd@dial.pipex.com
Frank Kastenholz BBN Technologies 10 Moulton St. Cambridge, MA 02183 USA
フランクKastenholzとBBNテクノロジーズ10モールトンセントケンブリッジ、MA 02183 USA
Phone: +1 617 873 8047 EMail: frank@bbn.com
電話：+1 617 873 8047 Eメール：frank@bbn.com