Network Working Group D. Meyer, Ed.
Request for Comments: 4984 L. Zhang, Ed.
Category: Informational K. Fall, Ed.
September 2007
Report from the IAB Workshop on Routing and Addressing
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
This document reports the outcome of the Routing and Addressing Workshop that was held by the Internet Architecture Board (IAB) on October 18-19, 2006, in Amsterdam, Netherlands. The primary goal of the workshop was to develop a shared understanding of the problems that the large backbone operators are facing regarding the scalability of today's Internet routing system. The key workshop findings include an analysis of the major factors that are driving routing table growth, constraints in router technology, and the limitations of today's Internet addressing architecture. It is hoped that these findings will serve as input to the IETF community and help identify next steps towards effective solutions.
この文書では、アムステルダム、オランダでは、ルーティングと10月18-19、2006年のインターネットアーキテクチャ委員会（IAB）で開催されたアドレッシングワークショップの成果を報告します。ワークショップの主な目的は、大規模な基幹事業者は、今日のインターネットルーティングシステムのスケーラビリティに関する直面している問題の共通の理解を開発することでした。キーワークショップの成果は、ルーティングテーブルの成長、ルータ技術の制約、および今日のインターネットアドレス体系の限界を運転している大きな要因の分析が含まれます。これらの知見は、IETFコミュニティへの入力として機能し、効果的なソリューションに向けた次のステップを識別するのに役立つことが期待されます。
Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and not of the IAB. Furthermore, note that work on issues related to this workshop report is continuing, and this document does not intend to reflect the increased understanding of issues nor to discuss the range of potential solutions that may be the outcome of this ongoing work.
このドキュメントは、ワークショップの議事録についての報告であることに注意してください。ビューと、このレポートに記載さ位置は、IABのワークショップ参加者のそれとではありません。さらに、このワークショップの報告書に関連した問題について、その作業は継続されることに注意してください、そして、このドキュメントは、問題の増加理解を反映するためにも、この進行中の作業の結果である可能性がある潜在的なソリューションの範囲を議論するつもりはありません。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Key Findings from the Workshop . . . . . . . . . . . . . . . . 4
2.1. Problem #1: The Scalability of the Routing System . . . . 4
2.1.1. Implications of DFZ RIB Growth . . . . . . . . . . . . 5
2.1.2. Implications of DFZ FIB Growth . . . . . . . . . . . . 6
2.2. Problem #2: The Overloading of IP Address Semantics . . . 6
2.3. Other Concerns . . . . . . . . . . . . . . . . . . . . . . 7
2.4. How Urgent Are These Problems? . . . . . . . . . . . . . . 8
3. Current Stresses on the Routing and Addressing System . . . . 8
3.1. Major Factors Driving Routing Table Growth . . . . . . . . 8
3.1.1. Avoiding Renumbering . . . . . . . . . . . . . . . . . 9
3.1.2. Multihoming . . . . . . . . . . . . . . . . . . . . . 10
3.1.3. Traffic Engineering . . . . . . . . . . . . . . . . . 10
3.2. IPv6 and Its Potential Impact on Routing Table Size . . . 11
4. Implications of Moore's Law on the Scaling Problem . . . . . . 11
4.1. Moore's Law . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. DRAM . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2. Off-chip SRAM . . . . . . . . . . . . . . . . . . . . 13
4.2. Forwarding Engines . . . . . . . . . . . . . . . . . . . . 13
4.3. Chip Costs . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Heat and Power . . . . . . . . . . . . . . . . . . . . . . 14
4.5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. What Is on the Horizon . . . . . . . . . . . . . . . . . . . . 15
5.1. Continual Growth . . . . . . . . . . . . . . . . . . . . . 15
5.2. Large Numbers of Mobile Networks . . . . . . . . . . . . . 16
5.3. Orders of Magnitude Increase in Mobile Edge Devices . . . 16
6. What Approaches Have Been Investigated . . . . . . . . . . . . 17
6.1. Lessons from MULTI6 . . . . . . . . . . . . . . . . . . . 17
6.2. SHIM6: Pros and Cons . . . . . . . . . . . . . . . . . . . 18
6.3. GSE/Indirection Solutions: Costs and Benefits . . . . . . 19
6.4. Future for Indirection . . . . . . . . . . . . . . . . . . 20
7. Problem Statements . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Problem #1: Routing Scalability . . . . . . . . . . . . . 21
7.2. Problem #2: The Overloading of IP Address Semantics . . . 22
7.2.1. Definition of Locator and Identifier . . . . . . . . . 22
7.2.2. Consequence of Locator and Identifier Overloading . . 23
7.2.3. Traffic Engineering and IP Address Semantics
Overload . . . . . . . . . . . . . . . . . . . . . . . 24
7.3. Additional Issues . . . . . . . . . . . . . . . . . . . . 24
7.3.1. Routing Convergence . . . . . . . . . . . . . . . . . 24
7.3.2. Misaligned Costs and Benefits . . . . . . . . . . . . 25
7.3.3. Other Concerns . . . . . . . . . . . . . . . . . . . . 25
7.4. Problem Recognition . . . . . . . . . . . . . . . . . . . 26
8. Criteria for Solution Development . . . . . . . . . . . . . . 26
8.1. Criteria on Scalability . . . . . . . . . . . . . . . . . 26
8.2. Criteria on Incentives and Economics . . . . . . . . . . . 27
8.3. Criteria on Timing . . . . . . . . . . . . . . . . . . . . 28
8.4. Consideration on Existing Systems . . . . . . . . . . . . 28
8.5. Consideration on Security . . . . . . . . . . . . . . . . 29
8.6. Other Criteria . . . . . . . . . . . . . . . . . . . . . . 29
8.7. Understanding the Tradeoff . . . . . . . . . . . . . . . . 29
9. Workshop Recommendations . . . . . . . . . . . . . . . . . . . 30
10. Security Considerations . . . . . . . . . . . . . . . . . . . 31
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
12. Informative References . . . . . . . . . . . . . . . . . . . . 31
Appendix A. Suggestions for Specific Steps . . . . . . . . . . . 35
Appendix B. Workshop Participants . . . . . . . . . . . . . . . . 35
Appendix C. Workshop Agenda . . . . . . . . . . . . . . . . . . . 36
Appendix D. Presentations . . . . . . . . . . . . . . . . . . . . 37
It is commonly recognized that today's Internet routing and addressing system is facing serious scaling problems. The ever-increasing user population, as well as multiple other factors including multi-homing, traffic engineering, and policy routing, have been driving the growth of the Default Free Zone (DFZ) routing table size at an increasing and potentially alarming rate [DFZ][BGT04]. While it has been long recognized that the existing routing architecture may have serious scalability problems, effective solutions have yet to be identified, developed, and deployed.
一般的に、今日のインターネットルーティングおよびアドレッシングシステムは深刻なスケーリングの問題に直面していることが認識されています。増え続けるユーザー数だけでなく、マルチホーミング、トラフィックエンジニアリング、およびポリシールーティングを含む複数の他の要因は、増加し、潜在的に驚くべき速さでデフォルトフリーゾーン（DFZ）ルーティングテーブルサイズの成長を牽引してきた[DFZ ] [BGT04]。長い間、既存のルーティングアーキテクチャは、深刻なスケーラビリティの問題を抱えていることが認識されてきたが、効果的な解決策は、まだ同定されていない開発、および展開します。
As a first step towards tackling these long-standing concerns, the IAB held a "Routing and Addressing Workshop" in Amsterdam, Netherlands on October 18-19, 2006. The main objectives of the workshop were to identify existing and potential factors that have major impacts on routing scalability, and to develop a concise problem statement that may serve as input to a set of follow-on activities. This document reports on the outcome from that workshop.
これらの長年の懸念に取り組む第一歩として、IABは、10月18-19でアムステルダム、オランダの「ルーティングとアドレッシングワークショップ」を開催し、ワークショップの2006年の主な目的は、主要持ち、既存および潜在的な因子を同定することでしたルーティングのスケーラビリティへの影響は、および後続活動のセットに入力としての役割を果たすことができる簡潔な問題文を開発します。この文書では、そのワークショップの成果について報告します。
The remainder of the document is organized as follows: Section 2 provides an executive summary of the workshop findings. Section 3 describes the sources of stress in the current global routing and addressing system. Section 4 discusses the relationship between Moore's law and our ability to build large routers. Section 5 describes a few foreseeable factors that may exacerbate the current problems outlined in Section 2. Section 6 describes previous work in this area. Section 7 describes the problem statements in more detail, and Section 8 discusses the criteria that constrain the solution space. Finally, Section 9 summarizes the recommendations made by the workshop participants.
次のように文書の残りの部分は構成されています。第2節では、ワークショップの成果のエグゼクティブ・サマリーを提供します。第3節では、現在のグローバルルーティングおよびアドレッシングシステムのストレスの原因を説明しています。第4節では、ムーアの法則と大規模なルータを構築する当社の能力との関係について説明します。セクション5は、2部6は、この分野で以前の研究を記載しているセクションで概説現在の問題を悪化させることができるいくつかの予見可能な要素を記述しています。第7節は、より詳細に問題文を記述し、第8章では、解空間を制約する判定基準について説明します。最後に、第9章では、ワークショップの参加者によって行われた提言をまとめました。
The workshop participant list is attached in Appendix B. The agenda can be found in Appendix C, and Appendix D provides pointers to the presentations from the workshop.
ワークショップの参加者リストは、議題が、付録Cに見出すことができる付録Bに取り付けられており、付録Dは、ワークショップからのプレゼンテーションへのポインタを提供されます。
Finally, note that this document is a report on the outcome of the workshop, not an official document of the IAB. Any opinions expressed are those of the workshop participants and not of the IAB.
最後に、この文書は、ワークショップの成果に関する報告書ではなく、IABの公式文書であることに注意してください。表現の任意の意見はIABのワークショップ参加者のそれとではありません。
This section provides a concise summary of the key findings from the workshop. While many other aspects of a routing and addressing system were discussed, the first two problems described in this section were deemed the most important ones by the workshop participants.
このセクションでは、ワークショップからの主要な調査結果の簡潔な概要を提供します。ルーティングおよびアドレス指定システムの他の多くの側面を論じたが、このセクションで説明した第1の二つの問題は、ワークショップ参加者が最も重要なものとみなされました。
The clear, highest-priority takeaway from the workshop is the need to devise a scalable routing and addressing system, one that is scalable in the face of multihoming, and that facilitates a wide spectrum of traffic engineering (TE) requirements. Several scalability problems of the current routing and addressing systems were discussed, most related to the size of the DFZ routing table (frequently referred to as the Routing Information Base, or RIB) and its implications. Those implications included (but were not limited to) the sizes of the DFZ RIB and FIB (the Forwarding Information Base), the cost of recomputing the FIB, concerns about the BGP convergence times in the presence of growing RIB and FIB sizes, and the costs and power (and hence heat dissipation) properties of the hardware needed to route traffic in the core of the Internet.
ワークショップから明らかな、最優先の持ち帰りは、スケーラブルなルーティングおよびアドレス方式、マルチホーミングの面でスケーラブルなものを考案する必要があり、それは、トラフィックエンジニアリング（TE）の要件の広いスペクトルを容易にします。現在のルーティングおよびアドレス指定システムのいくつかのスケーラビリティの問題は、DFZルーティングテーブルのサイズ（しばしばルーティング情報ベース、またはRIBと呼ぶ）およびその影響に最も関連する議論されました。これらの影響はDFZ RIBとFIB（転送情報ベース）の大きさ、FIBを再計算するコスト、成長RIBおよびFIBのサイズの存在下でのBGPコンバージェンス時間に対する懸念、および含まれる（これらに限定されませんでした）コストと消費電力（したがって、熱放散）インターネットのコアにトラフィックをルーティングするために必要なハードウェアの性質。
The shape of the growth curve of the DFZ RIB has been the topic of much research and discussion since the early days of the Internet [H03]. There have been various hypotheses regarding the sources of this growth. The workshop identified the following factors as the main driving forces behind the rapid growth of the DFZ RIB:
DFZ RIBの成長曲線の形状は、インターネットの黎明期以来、多くの研究や議論の話題[H03]となっています。この成長の源泉に関するさまざまな仮説がありました。ワークショップはDFZ RIBの急成長の背後にある主要な原動力として、以下の要因を特定しました。
o Multihoming,
マルチホーミングO、
o Traffic engineering,
Oトラフィックエンジニアリング、
o Non-aggregatable address allocations (a big portion of which is inherited from historical allocations), and
非集約アドレス割り当て（の大部分は、過去の割り当てから継承されている）O、及び
o Business events, such as mergers and acquisitions.
合併や買収などOのビジネスでのイベント、。
All of the above factors can lead to prefix de-aggregation and/or the injection of unaggregatable prefixes into the DFZ RIB. Prefix de-aggregation leads to an uncontrolled DFZ RIB growth because, absent some non-topologically based routing technology (for example, Routing On Flat Labels [ROFL] or any name-independent compact routing algorithm, e.g., [CNIR]), topological aggregation is the only known practical approach to control the growth of the DFZ RIB. The following section reviews the workshop discussion of the implications of the growth of the DFZ RIB.
上記の要因の全てはプレフィックス脱凝集および/またはDFZリブにunaggregatableプレフィックスの注入をもたらすことができます。 、いくつかの非位相幾何学ベースのルーティング技術を欠くため、プレフィクスド・集約が制御されていないDFZのRIBの成長につながる（例えば、ルーティングフラットラベル[ROFL]または任意の名前に依存しないコンパクトルーティングアルゴリズム、例えば、[CNIR]オン）、トポロジカル集約DFZ RIBの成長を制御するための唯一の知られている実用的なアプローチがあります。次のセクションでは、DFZ RIBの成長の意味のワークショップの議論をレビュー。
Presentations made at the workshop showed that the DFZ RIB has been growing at greater than linear rates for several years [DFZ]. While this has the obvious effects on the requirements for RIB and FIB memory sizes, the growth driven by prefix de-aggregation also exposes the core of the network to the dynamic nature of the edges, i.e., the de-aggregation leads to an increased number of BGP UPDATE messages injected into the DFZ (frequently referred to as "UPDATE churn"). Consequently, additional processing is required to maintain state for the longer prefixes and to update the FIB. Note that, although the size of the RIB is bounded by the given address space size and the number of reachable hosts (i.e., O(m*2^32) for IPv4, where <m> is the average number of peers each BGP router may have), the amount of protocol activity required to distribute dynamic topological changes is not. That is, the amount of BGP UPDATE churn that the network can experience is essentially unbounded. It was also noted that the UPDATE churn, as currently measured, is heavy-tailed [ATNAC2006]. That is, a relatively small number of Autonomous Systems (ASs) or prefixes are responsible for a disproportionately large fraction of the UPDATE churn that we observe today. Furthermore, much of the churn may turn out to be unnecessary information, possibly due to instability of edge ASs being injected into the global routing system [DynPrefix], or arbitrage of some bandwidth pricing model (see [GIH], for example, or the discussion of the behavior of AS 9121 in [BGP2005]).
ワークショップで行われたプレゼンテーションはDFZ RIBは数年[DFZ]のための線形速度よりも大きいで成長していることを示しました。これはRIBとFIBメモリサイズの要件に関する明白な効果を持っている、接頭脱凝集によって駆動成長もすなわち、エッジの動的な性質のためにネットワークのコアを露出させながら、デ・集約は数が増加につながりますDFZ（しばしば「UPDATEチャーン」という。）に注入BGPアップデートメッセージの。その結果、追加の処理は、より長いプレフィックスの状態を維持し、FIBを更新する必要があります。 RIBのサイズが与えられたアドレス空間のサイズと到達可能なホストの数<M>は、各BGPルータピアの平均数でのIPv4用（すなわち、O（M * 2 ^ 32）によって囲まれているが、なお）を有していてもよい、動的なトポロジの変更を配布するために必要なプロトコル・アクティビティの量ではありません。これは、ネットワークが体験できるのBGP UPDATEチャーンの量は、本質的に無制限である、です。それはまた、現在測定されたUPDATEチャーンは、ヘビーテイル[ATNAC2006]であることに留意しました。それは、自律システム（ASの）またはプレフィックスの数が比較的少ないが、我々が今日観察UPDATEチャーンの不釣り合いに大きな部分を担当している、です。また、解約の多くはエッジ尻の不安定性は、いくつかの帯域幅の価格決定モデルのグローバルルーティングシステム[DynPrefix]、又は裁定に注入される可能性に起因して、不要な情報であることが判明してもよい（例えば、[GIH]を参照、または[BGP2005]でAS 9121の行動についての議論）。
Finally, it was noted by the workshop participants that the UPDATE churn situation may be exacerbated by the current Regional Internet Registry (RIR) policy in which end sites are allocated Provider-Independent (PI) addresses. These addresses are not topologically aggregatable, and as such, bring the churn problem described above into the core routing system. Of course, as noted by several participants, the RIRs have no real choice in this matter, as many enterprises demand PI addresses that allow them to multihome without the "provider lock" that Provider-Allocated (PA) [PIPA] address space creates. Some enterprises also find the renumbering cost associated with PA address assignments unacceptable.
最後に、UPDATEチャーン状況がエンドサイトは、プロバイダに依存しない（PI）アドレスが割り当てられている現在の地域インターネットレジストリ（RIR）政策によって悪化することができることをワークショップ参加者によって指摘されました。これらのアドレスは位相的に集約されず、そのようなものとして、コアルーティングシステムに上記チャーンの問題をもたらします。いくつかの参加者が述べたように、多くの企業は彼らが「プロバイダロック」そのプロバイダ割り当て（PA）[PIPA]アドレス空間は作成せずにマルチホームを可能にするPIアドレスを要求するようもちろん、RIRは、この問題では本当の選択肢を持っていません。一部の企業はまた、容認できないPAアドレスの割り当てに関連したリナンバリングのコストを見つけます。
One surprising outcome of the workshop was the observation made by Tony Li about the relationship between "Moore's Law" [ML] and our ability to build cost-effective, high-performance routers (see Appendix D). "Moore's Law" is the empirical observation that the transistor density of integrated circuits, with respect to minimum component cost, doubles roughly every 24 months. A commonly held wisdom is that Moore's law would save the day by ensuring that technology will continue to scale at historical rates that surpass the growth rate of routing information handled by core router hardware. However, Li pointed out that Moore's Law does not apply to building high-end routers as far as the cost is concerned.
ワークショップの一つ驚くべき結果が「ムーアの法則」[ML]と費用対効果の高い、高性能ルータを構築する当社の能力との関係についてのトニー・リーによって行われた観察した（付録Dを参照してください）。 「ムーアの法則」が最小の部品コストに対する集積回路のトランジスタ密度は、毎24ヶ月おおよそ倍に経験的観察です。一般的に開催された知恵は、ムーアの法則は、技術がコアルータハードウェアで処理するルーティング情報の成長率を上回る歴史的な速度で拡大し続けることを確実にすることによって救うだろうということです。しかし、李はムーアの法則は限りコストを懸念しているハイエンドルータを構築するには適用されないことを指摘しました。
Moore's Law applies specifically to the high-volume portion of the semiconductor industry, while the low-volume, customized silicon used in core routing is well off Moore's Law's cost curve. In particular, off-chip SRAM is commonly used for storing FIB data, and the driver for low-latency, high-capacity SRAM used to be PC cache memory. However, recently cache memory has been migrating directly onto the processor die, and cell phones are now the primary driver for off-chip SRAM. Given cell phones require low-power, small-capacity parts that are not applicable to high-end routers, the SRAMs that are favored for router design are not volume parts and do not track with Moore's law.
コアルーティングに使用される低容量、カスタマイズされたシリコンがよくムーアの法則のコスト曲線オフ時ムーアの法則は、具体的には、半導体業界の大容量部分に適用されます。具体的には、オフチップSRAMは、一般的にFIBデータを記憶するために使用され、そして低レイテンシのためのドライバは、大容量のSRAMは、PCキャッシュメモリに使用されます。しかし、最近、キャッシュメモリは、プロセッサダイに直接移行しており、携帯電話は今オフチップSRAMのための主な要因です。与えられた携帯電話は、ハイエンドルータには適用されない低消費電力、小容量の部品を必要とし、ルータの設計のために好まれているSRAMは、ボリュームの部分ではなく、ムーアの法則を追跡しません。
One of the fundamental assumptions underlying the scalability of routing systems was eloquently stated by Yakov Rekhter (and is sometimes referred to as "Rekhter's Law"), namely:
ルーティングシステムのスケーラビリティの基礎となる基本的な前提の一つ、すなわち、雄弁ヤコフ・レックターによって規定された（時には「Rekhterの法則」と呼ばれます）。
"Addressing can follow topology or topology can follow
addressing. Choose one."
The same idea was expressed by Mike O'Dell's design of an alternate address architecture for ipv6 [GSE], where the address structure was designed specifically to enable "aggressive topological aggregation" to scale the routing system. Noel Chiappa has also written extensively on this topic (see, e.g., [EID]).
同じ考え方は、アドレス構造がルーティングシステムを拡張するために、「積極的なトポロジー集合」を可能にするために特別に設計されたIPv6の代替アドレスアーキテクチャのマイクオデルの設計[GSE]、で表しました。クリスマスChiappaはまた、（例えば、[EID]）このトピックについての広範囲に書かれています。
There is, however, a difficulty in creating (and maintaining) the kind of congruence envisioned by Rekhter's Law in today's Internet. The difficulty arises from the overloading of addressing with the semantics of both "who" (endpoint identifier, as used by transport layer) and "where" (locators for the routing system); some might also add that IP addresses are also overloaded with "how" [GIH]. In any
今日のインターネットでRekhterの法則によって想定される合同の種類を作成（および維持）での難しさは、しかし、があります。難易度は「」（トランスポート層で使用されるエンドポイント識別子）と「」（ルーティングシステムのためのロケータ）の両方の意味でアドレッシングの過負荷から生じます。いくつかはまた、IPアドレスはまた、「どのように」[GIH]で過負荷されていることを追加される場合があります。いずれにおいても
event, this kind of overloading is felt to have had deep implications for the scalability of the global routing system.
イベントは、オーバーロードのこの種は、グローバルルーティングシステムの拡張性のために深い意味を持っていると感じられます。
A refinement to Rekhter's Law, then, is that for the Internet routing system to scale, an IP address must be assigned in such a way that it is congruent with the Internet's topology. However, identifiers are typically assigned based upon organizational (not topological) structure and have stability as a desirable property, a "natural incongruence" arises. As a result, it is difficult (if not impossible) to make a single number space serve both purposes efficiently.
Rekhterの法則への改良は、その後、インターネットルーティングシステムが拡張するために、IPアドレスは、インターネットのトポロジーと合同であるように割り当てられなければならないということです。しかしながら、識別子は、通常、組織（トポロジーではない）構造に基づいており、望ましい特性としての安定性を有していて割り当てられている、「天然の不適合」が生じます。その結果、それは、単一の番号空間を作ることが難しい（不可能ではない）で効率的に両方の目的を果たします。
Following the logic of the previous paragraphs, workshop participants concluded that the so-called "locator/identifier overload" of the IP address semantics is one of the causes of the routing scalability problem as we see today. Thus, a "split" seems necessary to scale the routing system, although how to actually architect and implement such a split was not explored in detail.
前の段落のロジックに続いて、ワークショップの参加者は、我々が今日見るようにIPアドレスのセマンティクスのいわゆる「ロケータ/識別子の過負荷は、」ルーティングのスケーラビリティの問題の原因の一つであると結論づけました。したがって、「スプリット」は、実際に建築家とそのような分割を実現するために詳細に探求されなかった方が、ルーティングシステムを拡張するために必要と思われます。
In addition to the issues described in Section 2.1 and Section 2.2, the workshop participants also identified the following three pressing, but "second tier", issues.
2.1節と2.2節で説明した問題に加えて、ワークショップの参加者はまた、押し、次の3が、「第二層」、問題を特定しました。
The first one is a general concern with IPv6 deployment. It is commonly believed that the IPv4 address space has put an effective constraint on the IPv4 RIB growth. Once this constraint is lifted by the deployment of IPv6, and in the absence of a scalable routing strategy, the rapid DFZ RIB size growth problem today can potentially be exacerbated by IPv6's much larger address space. The only routing paradigm available today for IPv6 is a combination of Classless Inter-Domain Routing (CIDR) [RFC4632] and Provider-Independent (PI) address allocation strategies [PIPA] (and possibly SHIM6 [SHIM6] when that technology is developed and deployed). Thus, the opportunity exists to create a "swamp" (unaggregatable address space) that can be many orders of magnitude larger than what we faced with IPv4. In short, the advent of IPv6 and its larger address space further underscores both the concerns raised in Section 2.1, and the importance of resolving the architectural issue raised in Section 2.2.
最初の1は、IPv6の展開と一般的な関心事です。一般的にIPv4アドレス空間は、IPv4 RIBの成長に効果的な制約を入れていると考えられています。この制約がIPv6の展開で持ち上げ、かつスケーラブルなルーティング戦略の不在にされると、急速DFZ RIBサイズの成長の問題今日は、潜在的にIPv6の者のはるかに大きなアドレス空間によって悪化することができます。 IPv6のために利用可能な唯一のルーティングパラダイム今日はクラスレスドメイン間ルーティング（CIDR）[RFC4632]とプロバイダに依存しない（PI）アドレス割り当て戦略の組み合わせである[PIPA]（そしておそらくSHIM6は[SHIM6]その技術が開発されたときに展開）。このように、機会が我々がIPv4に直面しているものよりも大きな何桁もできる「沼」（unaggregatableアドレス空間）を作成するために存在します。要するに、IPv6とその大きなアドレス空間の出現は、さらに2.1節に懸念、および2.2節で提起されたアーキテクチャの問題を解決することの重要性の両方を強調しています。
The second issue is slow routing convergence. In particular, the concern was that growth in the number of routes that service providers must carry will cause routing convergence to become a significant problem.
第二の問題は、低速のルーティング収束です。特に、懸念は、サービスプロバイダーが運ばなければならないルートの数の増加が大きな問題となるために、収束をルーティングする原因になりますということでした。
The third issue is the misalignment of costs and benefits in today's routing system. While the IETF does not typically consider the "business model" impacts of various technology choices, many participants felt that perhaps the time has come to review that philosophy.
第三の問題は、今日のルーティングシステムにおける費用と便益の位置ずれです。 IETFは、典型的には、様々な技術の選択肢の「ビジネスモデル」への影響を考慮していないが、多くの参加者は、おそらく時間がその理念を見直すようになってきたことを感じました。
There was a fairly universal agreement among the workshop participants that the problems outlined in Section 2.1 and Section 2.2 need immediate attention. This need was not because the participants perceived a looming, well-defined "hit the wall" date, but rather because these are difficult problems that to date have resisted solution, are likely to get more unwieldy as IPv6 deployment proceeds, and the development and deployment of an effective solution will necessarily take at least a few years.
2.1節と2.2節で概説した問題は早急な対応が必要であることをワークショップ参加者の間でかなり普遍的合意がありました。参加者は迫り来る、明確に定義された「壁にぶつかる」日付を認知するので、この必要性はありませんでしたが、むしろこれらは、現在までに解決策に抵抗してきたことの困難な問題であるため、IPv6の展開が進むにつれて、より扱いにくい取得する可能性があり、開発と効果的なソリューションの展開は、必ずしも、少なくとも数年はかかるだろう。
The primary concern voiced by the workshop participants regarding the state of the current Internet routing system was the rapid growth of the DFZ RIB. The number of entries in 2005 ranged from about 150,000 entries to 175,000 entries [BGP2005]; this number has reached 200,000 as of October 2006 [CIDRRPT], and is projected to increase to 370,000 or more within 5 years [Fuller]. Some workshop participants projected that the DFZ could reach 2 million entries within 15 years, and there might be as many as 10 million multihomed sites by 2050.
現在のインターネットルーティングシステムの状態に関するワークショップ参加者による声の主な関心事は、DFZ RIBの急速な成長でした。 2005年のエントリの数は、約150,000エントリから175,000エントリ[BGP2005]の範囲でした。この数は2006年10月のようCIDRRPT]を200,000に達した、と5年[フラー]内37万以上にまで増加すると予測されます。いくつかのワークショップの参加者はDFZは、15年以内に200万エントリに達する可能性がある、と2050年までにできるだけ多く億10としてマルチホームのサイトがあるかもしれないと予想しました。
Another related concern was the number of prefixes changed, added, and withdrawn as a function of time (i.e., BGP UPDATE churn). This has a detrimental impact on routing convergence, since UPDATEs frequently necessitate a re-computation and download of the FIB. For example, a BGP router may observe up to 500,000 BGP updates in a single day [DynPrefix], with the peak arrival rates over 1000 updates per second. Such UPDATE churn problems are not limited to DFZ routes; indeed, the number of internal routes carried by large ISPs also threatens convergence times, given that such internal routes include more specifics, Virtual Private Network (VPN) routes, and other routes that do not appear in the DFZ [ATNAC2006].
別の関連する懸念は、プレフィクスの数は、変更を加え、時間の関数（すなわち、BGPアップデートチャーン）として回収しました。更新が頻繁にFIBの再計算およびダウンロードを必要とするので、これは、収束経路に有害な影響を有しています。例えば、BGPルータは、毎秒1000回のアップデートを超えるピーク到着率で、[DynPrefix]一日で50万BGPアップデートまで観察することができます。このような更新チャーンの問題はDFZルートに限定されるものではありません。実際、大のISPによって運ば内部ルートの数はまた、内部ルートは、より具体的、仮想プライベートネットワーク（VPN）経路、及びDFZ [ATNAC2006]に表示されない他の経路を含むことを考慮すると、コンバージェンス時間を脅かします。
The growth of the DFZ RIB results from the addition of more prefixes to the table. Although some of this growth is organic (i.e., results simply from growth of the Internet), a large portion of the growth results from de-aggregation of address prefixes (i.e., more specific prefixes). In this section, we discuss in more detail why this trend is accelerating and may be cause for concern.
DFZ RIBの成長は、テーブルに複数のプレフィックスの付加から生じます。この成長の一部は（すなわち、単にインターネットの成長に起因する）、有機であるが、アドレスプレフィックス（すなわち、より具体的な接頭辞）の脱凝集からの成長結果の大部分。この傾向は加速していると懸念の原因である可能性があり、なぜこのセクションでは、我々はより詳細に議論します。
An increasing fraction of the more-specific prefixes found in the DFZ are due to deliberate action on the part of operators [ATNAC2006]. Motivations to advertise these more-specifics include:
DFZに見られるより特異的プレフィクスの増加分率は、[ATNAC2006】オペレータの部分に意図的作用によるものです。これらのより-詳細を宣伝するための動機は、次のとおりです。
o Traffic Engineering, where load is balanced across multiple links through selective advertisement of more-specific routes on different links to adjust the amount of traffic received on each; and
O負荷がトラフィックの量を調整するために、異なるリンク上のより具体的なルートの選択広告を介して複数のリンクを介してバランスされたトラフィック・エンジニアリングは、それぞれで受信。そして
o Attempts to prevent prefix-hijacking by other operators who might advertise more-specifics to steer traffic toward them; there are several known instances of this behavior today [BHB06].
Oそれに向かってトラフィックを導くために、より-詳細を宣伝する可能性のある他の事業者がプレフィックスハイジャックを防ぐためにしようとします。この動作のいくつかの既知のインスタンスが[BHB06]今日があります。
The workshop participants noted that customers generally prefer to have PI address space. Doing so gives them additional agility in selecting ISPs and helps them avoid the need to renumber. Many end-systems use DHCP to assign addresses, so a cursory analysis might suggest renumbering might involve modification of a modest number of routers and servers (perhaps rather than end hosts) at a site that was forced to renumber.
ワークショップの参加者は、顧客は、一般的PIアドレス空間を持っていることを好むことを指摘しました。そうすることのISPを選択するには、それらに追加俊敏性を与え、それらを再番号付けする必要性を回避するのに役立ちます。多くのエンドシステムは、アドレスを割り当てるDHCPを使用するので、リナンバリングを示唆するかもしれないぞんざいな分析は、番号を付け直すことを余儀なくされたサイトでのささやかなルータやサーバの数（おそらくではなく、エンドホスト）の変更を伴う場合があります。
In reality, however, renumbering can be more cumbersome because IP addresses are often used for other purposes such as access control lists. They are also sometimes hard-coded into applications used in environments where failure of the DNS would be catastrophic (e.g., some remote monitoring applications). Although renumbering may be a mild inconvenience for some sites and guidelines have been developed for renumbering a network without a flag day [RFC4192], for others, the necessary changes are sufficiently difficult so as to make renumbering effectively impossible.
IPアドレスは、多くの場合、アクセス制御リストなど、他の目的のために使用されているので、現実には、しかし、リナンバリングはもっと面倒なことができます。それらはまた、時々DNSの障害（例えば、いくつかの遠隔監視アプリケーション）致命的であろう環境で使用されるアプリケーションにハードコードされています。リナンバリングフラグ日[RFC4192]せずにネットワークを再番号付けするために開発されているいくつかのサイトとガイドラインについては、軽度の不便かもしれないが、他人のために、必要な変更を効果的に不可能リナンバリングになるように十分に困難です。
For these reasons, PI address space is sought by a growing number of customers. Current RIR policy reflects this trend, and their policy is to allocate PI prefixes to all customers who claim a need. Routing PI prefixes requires additional entries in the DFZ routing and forwarding tables. At present, ISPs do not typically charge to route PI prefixes. Therefore, the "costs" of the additional prefixes, in terms of routing table entries and processing overhead, is born by the global routing system as a whole, rather than directly by the users of PI space. The workshop participants observed that no strong disincentive exists to discourage the increasing use of PI address space.
これらの理由から、PIアドレス空間は、顧客数の増加によって求められています。現在RIRポリシーは、この傾向を反映し、そのポリシーが必要性を主張するすべての顧客にPIプレフィックスを割り当てることです。 PIプレフィックスをルーティングすることはDFZルーティングおよび転送テーブルの追加エントリーが必要です。現時点では、ISPは、通常ルートPIプレフィックスに充電しないでください。そのため、追加の接頭辞の「コスト」は、ルーティングテーブルエントリと処理のオーバーヘッドの観点から、むしろ直接PI空間の利用者によるよりも、全体としてグローバルルーティングシステムによって生まれています。ワークショップの参加者には、強力な阻害要因は、PIアドレス空間の使用の増加を阻止するために存在しないことを観察しました。
Multihoming refers generically to the case in which a site is served by more than one ISP [RFC4116]. There are several reasons for the observed increase in multihoming, including the increased reliance on the Internet for mission- and business-critical applications and the general decrease in cost to obtain Internet connectivity. Multihoming provides backup routing -- Internet connection redundancy; in some circumstances, multihoming is mandatory due to contract or law. Multihoming can be accomplished using either PI or PA address space, and multihomed sites generally have their own AS numbers (although some do not; this generally occurs when such customers are statically routed).
マルチホーミングは、サイトが一つ以上のISP [RFC4116]によってサービスを提供される場合に一般的に指します。ミッションやビジネスクリティカルなアプリケーションのためのインターネット上の増加信頼とインターネット接続を取得するためにコストの一般的な減少を含むマルチホーミングで観察された増加、いくつかの理由があります。マルチホーミングは、バックアップルーティングを提供 - インターネット接続の冗長性を、いくつかの状況では、マルチホーミングは、契約または法律による義務です。マルチホーミングは、PIやPAアドレス空間のいずれかを使用して達成することができ、（一部にはないものの、こうした顧客は、静的ルーティングされたときに、これは一般的に発生する）マルチホームのサイトは、一般的にAS番号、独自のを持っています。
A multihomed site using PI address space has its prefixes present in the forwarding and routing tables of each of its providers. For PA space, each prefix allocated from one provider's address allocation will be aggregatable for that provider but not the others. If the addresses are allocated from a 'primary' ISP (i.e., one that the site uses for routing unless a failure occurs), then the additional routing table entries only appear during path failures to that primary ISP. A problem with multihoming arises when a customer's PA IP prefixes are advertised by AS(es) other than their 'primary' ISP's. Because of the longest-matching prefix forwarding rule, in this case, the customer's traffic will be directed through the non-primary AS(s). In response, the primary ISP is forced to de-aggregate the customer's prefix in order to keep the customer's traffic flowing through it instead of the non-primary AS(s).
PIアドレス空間を使用してマルチホームサイトは、そのプロバイダのそれぞれの転送およびルーティングテーブルに存在するその接頭辞を持っています。 PAスペースのために、1つのプロバイダのアドレス割り当てから割り当てられた各プレフィックスは、そのプロバイダではなく、他人のために集約されます。アドレスは「一次」ISPから割り当てられている場合（すなわち、障害が発生しない限りサイトがルーティングのために使用するもの）、追加のルーティングテーブルエントリは、その一次ISPへのパスの障害時に表示されます。顧客のPA IPプレフィックスは、彼らの「主要」ISPの以外のAS（ES）によってアドバタイズされている場合マルチホーミングとの問題が生じます。そのため最長一致プレフィックス転送ルールのため、この場合には、顧客のトラフィックは、非プライマリAS（複数可）を介して送られます。応答では、主要ISPは、非プライマリAS（複数可）の代わりに、それを流れる顧客のトラフィックを維持するために、非集約し、顧客のプレフィックスを余儀なくされます。
Traffic engineering (TE) is the act of arranging for certain Internet traffic to use or avoid certain network paths (that is, TE puts traffic where capacity exists, or where some set of parameters of the path is more favorable to the traffic being placed there). TE is performed by both ISPs and customer networks, for three primary reasons:
トラフィックエンジニアリング（TE）を使用するか（すなわち、特定のネットワークパスを避けるために特定のインターネットトラフィックのために配置する行為であり、TEは、容量が存在する、またはパスのパラメータのいくつかのセットがトラフィックに、より有利である場合が配置されているトラフィックを置きます）。 TEは、三つの主要な理由のために、ISPや顧客ネットワークの両方で実行されます。
o First, as mentioned above, to match traffic with network capacity, or to spread the traffic load across multiple links (frequently referred to as "load balancing").
上述したように、Oまず、ネットワーク容量とトラフィックに一致する、または（しばしば「負荷分散」と呼ぶ）は、複数のリンク間のトラフィック負荷を分散します。
o Second, to reduce costs by shifting traffic to lower cost paths or by balancing the incoming and outgoing traffic volume to maintain appropriate peering relations.
O第二に、低コストパスにトラフィックをずらしたり、適切なピアリング関係を維持するために、着信と発信のトラフィック量のバランスをとることによってコストを削減します。
o Finally, TE is sometimes deployed to enforce certain forms of policy (e.g., Canadian government traffic may not be permitted to transit through the United States).
O最後に、TEは、時々ポリシーの特定の形態を実施するために配備されている（例えば、カナダ政府のトラフィックは米国経由のトランジットに許可されない場合があります）。
Few tools exist for inter-domain traffic engineering today. Network operators usually achieve traffic engineering by "tweaking" the processing of routing protocols to achieve desired results. At the BGP level, if the address range requiring TE is a portion of a larger PA address aggregate, network operators implementing TE are forced to de-aggregate otherwise aggregatable prefixes in order to steer the traffic of the particular address range to specific paths.
いくつかのツールは、今日のドメイン間のトラフィックエンジニアリングのために存在します。ネットワークオペレータは通常、「微調整」とは、所望の結果を達成するために、ルーティングプロトコルの処理によって、トラフィックエンジニアリングを実現します。 BGPレベルでは、TEが大きくPAアドレス集合体の一部である必要アドレス範囲場合、TEを実現するネットワークオペレータは、脱凝集する、さもなければ集約プレフィックスを特定のパスに特定のアドレス範囲のトラフィックを操縦するために強制されます。
In today's highly competitive environment, providers require TE to maintain good performance and low cost in their networks. However, the current practice of TE deployment results in an increase of the DFZ RIB; although individual operators may have a certain gain from doing TE, it leads to an overall increased cost for the Internet routing infrastructure as a whole.
今日の競争の激しい環境では、プロバイダは、そのネットワークでの優れた性能と低コストを維持するために、TEを必要としています。しかし、DFZ RIBの増加でTEの展開結果の現在の練習。個々の事業者がTEをやってから一定のゲインを持つかもしれないが、それは全体としてインターネットルーティングインフラストラクチャの全体的なコスト増につながります。
Due to the increased IPv6 address size over IPv4, a full immediate transition to IPv6 is estimated to lead to the RIB and FIB sizes increasing by a factor of about four. The size of the routing table based on a more realistic assumption, that of parallel IPv4 and IPv6 routing for many years, is less clear. An increasing amount of allocated IPv6 address prefixes is in PI space. ARIN [ARIN] has relaxed its policy for allocation of such space and has been allocating /48 prefixes when customers request PI prefixes. Thus, the same pressures affecting IPv4 address allocations also affect IPv6 allocations.
IPv4から増加したIPv6アドレスのサイズに、IPv6への完全な即時の遷移は約4倍に増加しRIBおよびFIBのサイズにつながると推定されます。パラレルIPv4およびIPv6ルーティングの多くの年のためのより現実的な仮定に基づいて、ルーティングテーブルのサイズは、それほど明確ではありません。割り当てられたIPv6アドレスプレフィックスの増加量は、PI空間です。 ARIN [ARIN】このようなスペースの配分のための政策を緩和しており、顧客はPIプレフィックスを要求したとき/ 48プレフィックスを割り当てるされています。このように、IPv4のアドレスの割り当てに影響を与えると同じ圧力もIPv6割り振りに影響を与えます。
[Editor's note: The information in this section is gathered from presentations given at the workshop. The presentation slides can be retrieved from the pointer provided in Appendix D. It is worth noting that this information has generated quite a bit of discussion since the workshop, and as such requires further community input.]
[編集者注：このセクションの情報は、ワークショップで与えられたプレゼンテーションから収集されます。プレゼンテーションスライドは、この情報はワークショップ以降の議論のかなりの生成、そのようなものとして、さらにコミュニティ入力を必要としていることは注目に値する付録Dに設けられたポインタから取得することができます。】
The workshop heard from Tony Li about the relationship between Moore's law and the ability to build cost-effective, high-performance routers. The scalability of the current routing subsystem manifests itself in the forwarding table (FIB) and routing table (RIB) of the routers in the core of the Internet. The implementation choices for FIB storage are on-chip SRAM, off-chip SRAM, or DRAM. DRAM is commonly used in lower end devices. RIB storage is done via DRAM.
ワークショップでは、ムーアの法則と費用対効果の高い、高性能ルータを構築する能力との関係についてのトニー・リーから聞きました。現在のルーティング・サブシステムのスケーラビリティは、フォワーディングテーブル（FIB）とインターネットのコアのルータのルーティングテーブル（RIB）で現れます。 FIBストレージの実装の選択肢が、オンチップSRAM、オフチップSRAMまたはDRAMです。 DRAMは、一般的に、下端機器に使用されています。 RIBストレージは、DRAMを介して行われます。
[Editor's note: The exact implementation of a high-performance router's RIB and FIB memories is the subject of much debate; it is also possible that alternative designs may appear in the future.]
[編集者注：高性能ルータのRIBとFIB思い出の正確な実装は、多くの議論の主題です。別の設計は、将来的に表示されることも可能です。]
The scalability question then becomes whether these memory technologies can scale faster than the size of the full routing table. Intrinsic in this statement is the assumption that core routers will be continually and indefinitely upgraded on a periodic basis to keep up with the technology curve and that the costs of those upgrades will be passed along to the general Internet community.
スケーラビリティの問題は、これらのメモリ技術は、完全なルーティングテーブルのサイズよりも速く拡大できるかどうかになります。この文で固有のコア・ルータが継続的かつ無期限の技術曲線と、これらのアップグレードのコストは、一般的なインターネットコミュニティに渡されることに追いつくために、定期的にアップグレードされるという仮定があります。
In 1965, Gordon Moore projected that the density of transistors in integrated circuits could double every two years, with respect to minimum component cost. The period was subsequently adjusted to be between 18-24 months and this conjecture became known as Moore's Law [ML]. The semiconductor industry has been following this density trend for the last 40 or so years.
1965年、ゴードン・ムーアは、集積回路内のトランジスタの密度は最小部品コストに関して、隔年倍増できると予想しました。期間は、その後、18〜24ヶ月の間になるように調整し、この推測は、ムーアの法則[ML]として知られるようになりました。半導体業界は、過去40年かそこらのために、この密度のトレンドを追っています。
The commonly held wisdom is that Moore's law will save the day by ensuring that technology will continue to scale at the historical rate that will surpass the growth rate of routing information. However, it is vital to understand that Moore's law comes out of the high-volume portion of the semiconductor industry, where the costs of silicon are dominated by the actual fabrication costs. The customized silicon used in core routers is produced in far lower volume, typically in the 1,000-10,000 parts per year, whereas microprocessors are running in the tens of millions per year. This places the router silicon well off the cost curve, where the economies of scale are not directly inherited, and yield improvements are not directly inherited from the best current practices. Thus, router silicon benefits from the technological advances made in semiconductors, but does not follow Moore's law from a cost perspective.
一般的に開催された知恵は、ムーアの法則は、技術情報をルーティングの成長率を上回るだろう歴史的な速度で拡大し続けることを確実にすることによって救うということです。しかし、ムーアの法則は、シリコンのコストは、実際の製造コストによって支配されている半導体業界の高体積部分から出てくることを理解することが重要です。マイクロプロセッサは、年間数千万で実行されているのに対し、コア・ルータで使用されるカスタマイズされたシリコンは、典型的には年間1,000〜10,000部で、はるかに低い量で産生されます。これはうまく規模の経済が直接継承されていない費用曲線、オフルータのシリコンを配置し、歩留まりの改善は、直接現在のベストプラクティスから継承されていません。このように、技術の進歩からルータのシリコンの利点は、半導体で作られたが、コストの観点から、ムーアの法則に従っていません。
To date, this cost difference has not shown clearly. However, the growth in bandwidth of the Internet and the steady climb of the speed of individual links has forced router manufacturers to apply more sophisticated silicon technology continuously. There has been a new generation of router hardware that has grown at about 4x the bandwidth every three years, and increases in routing table size have been absorbed by the new generations of hardware. Now that router hardware is nearing the practical limits of per-lambda bandwidth, it is possible that upgrades solely for meeting the forwarding table scaling will become more visible.
現在までに、このコスト差が明確に示されていません。しかし、インターネットの帯域幅と個々のリンクの速度の着実な上昇の成長は継続し、より高度なシリコン技術を適用するために、ルータのメーカーを余儀なくされました。そこ三年ごとにおよそ4倍の帯域幅で成長しているルータのハードウェアの新世代となっている、およびルーティングテーブルサイズの増加は、ハードウェアの新世代に吸収されています。そのルータのハードウェアごとのラムダ帯域幅の実用的な限界に近づいている今、より見えるようになりますフォワーディングテーブルのスケーリングを満たすためだけにアップグレードすることが可能です。
In routers, DRAM is used for storing the RIB and, in lower-end routers, is also used for storing the FIB. Historically, DRAM capacity grows at about 4x every 3.3 years. This translates to 2.4x every 2 years, so DRAM capacity actually grows faster than Moore's law would suggest. DRAM speed, however, only grows about 10% per year, or 1.2x every 2 years [DRAM] [Molinero]. This is an issue because BGP convergence time is limited by DRAM access speeds. In processing a BGP update, a BGP speaker receives a path and must compare it to all of the other paths it has stored for the prefix. It then iterates over all of the prefixes in the update stream. This results in a memory access pattern that has proven to limit the effectiveness of processor caching. As a result, BGP convergence time degrades at the routing table growth rate, divided by the speed improvement rate of DRAM. In the long run, this is likely to become a significant issue.
ルータでは、DRAMは、RIBを記憶するために使用され、下端ルータに、FIBを格納するためにも使用されます。歴史的に、DRAMの容量を約4倍ごとに3.3年で成長します。これは、2年ごとに2.4倍に変換するので、DRAMの容量は、実際にはムーアの法則は示唆しているよりも速く成長します。 DRAMの速度は、しかし、唯一の年間約10％、または1.2倍、2年毎[DRAM] [Molineroに]を成長します。 BGPコンバージェンス時間はDRAMのアクセス速度によって制限されているので、これは問題です。 BGPアップデートを処理する際に、BGPスピーカは、パスを受信し、接頭辞のために保存している他のパスの全てと比較しなければなりません。その後、更新ストリーム内のプレフィックスのすべてを反復処理しました。これは、プロセッサのキャッシュの有効性を制限するために証明されているメモリ・アクセス・パターンをもたらします。結果として、BGPコンバージェンス時間は、DRAMの速度向上率で割ったルーティングテーブルの成長速度で分解する。長い目で見れば、これは大きな問題になる可能性があります。
Storing the FIB in off-chip SRAM is a popular design decision. For high-speed interfaces, this requires low-latency, high-capacity parts. The driver for this type of SRAM was formerly PC cache memory. However, this cache memory has recently been migrating directly onto the processor die, so that the volumes of cache memory have fallen off. Today, the primary driver for off-chip SRAM is cell phones, which require low-power, small-capacity parts that are not applicable to high-end router design. As a result, the SRAMs that are favored for router design are not volume parts. They have fallen off the cost curve and do not track with Moore's law.
オフチップSRAMにFIBを保存する人気のデザインの決定です。高速インタフェースの場合、これは、低遅延、高容量の部品が必要となります。 SRAMのこのタイプのドライバは、以前はPCのキャッシュメモリでした。キャッシュメモリの容量が落ちてきたように、しかし、このキャッシュメモリは、最近、プロセッサダイに直接移行されました。今日では、オフチップSRAMのための主な要因は、ハイエンドルータの設計に適用されない低消費電力、小容量の部品を必要とする携帯電話、です。その結果、ルータ設計のために好まれているSRAMは、ボリュームの部分ではありません。彼らは、費用曲線から落ちてきたとムーアの法則で追跡しません。
For many years, router companies have been building special-purpose silicon to provide high-speed packet-forwarding capabilities. This has been necessary because the architectural limitations of general purpose CPUs make them incapable of providing the high-bandwidth, low latency, low-jitter I/O interface for making high speed forwarding decisions.
何年もの間、ルータの企業は、高速パケット転送機能を提供するために、専用のシリコンを構築してきました。汎用CPUのアーキテクチャ上の制限は、高速転送決定を行うための高帯域幅、低遅延、低ジッタのI / Oインタフェースを提供する彼らが不可能にするため、これが必要でした。
As a result, the forwarding engines being built for high-end routers are some of the most sophisticated Application-specific Integrated Circuits (ASICs) being built, and are currently only one technological step behind general-purpose CPUs. This has been largely driven by the growth in bandwidth and has already pushed the technology well beyond the knee in the price/performance curve. Given that this level of technology is already a requirement to meet the performance goals, using on-chip SRAM is an interesting design alternative. If this choice is selected, then growth in the available FIB is tightly coupled to process technology improvements, which are driven by the general-purpose CPU market. While this growth rate should suffice, in general, the forwarding engine market is decidedly off the high-volume price curve, resulting in spiraling costs to support basic forwarding.
その結果、ハイエンドルータ用に構築されている転送エンジンは、構築される最も洗練された特定用途向け集積回路（ASIC）の一部であり、現在、汎用CPUの背後にある唯一の技術的なステップです。これは主に、帯域幅の成長によって駆動されており、すでによく価格/性能曲線で膝を超えて技術をプッシュしています。この技術のレベルはすでにパフォーマンス目標を達成するための要件であることを考えると、オンチップSRAMを使用すると、面白いデザインの選択肢です。この選択項目が選択されている場合は、利用可能FIBでの成長がしっかりと汎用CPU市場で駆動されている技術の向上を処理するために結合されています。この成長率は十分ですが、一般的には、フォワーディングエンジン市場は、基本的な転送をサポートするためのコストをらせん状になり、明らかに大量の価格曲線から外れています。
Moreover, if there is any change in Moore's law or decrease in the rate of processor technology evolution, the forwarding engine could quickly become the technological leader of silicon technology. This would rapidly result in forwarding technology becoming prohibitively expensive.
ムーアの法則やプロセッサ技術の進化の速度の低下に変更がある場合はまた、フォワーディングエンジンはすぐにシリコン技術の技術的リーダーになることができます。これは、急速に高価になってきて技術を転送することになります。
Each process technology step in chip development has come at increasing cost. The milestone of sending a completed chip design to a fabricator for manufacturing is known as 'tapeout', and is the point where the designer pays for the fixed overhead of putting the chip into production. The costs of taping out a chip have been rising about 1.5x every 2 years, driven by new process technology. The actual design and development costs have been rising similarly, because each new generation of technology increases the device count by roughly a factor of 2. This allows new features and chip architectures, which inevitably lead to an increase in complexity and labor costs. If new chip development was driven solely by the need to scale up memory, and if memory structures scaled, then we would expect labor costs to remain fixed. Unfortunately, memory structures typically do not seem to scale linearly. Individual memory controllers have a non-negligible cost, leading to the design for an internal on-chip interconnect of memories. The net result is that we can expect that chip development costs to continue to escalate roughly in line with the increases in tapeout costs, leading to an ongoing cost curve of about 1.5x every 2 years. Since each technology step roughly doubles memory, that implies that if demand grows faster than about (2x/1.5x) = 1.3x per year, then technology refresh will not be able to remain on a constant cost curve.
チップ開発の各プロセス技術のステップは、コストの増加になってきました。製造のために製作に完成したチップ設計を送信するマイルストーンは、「テープアウト」として知られており、設計者は製造中にチップを置くの固定オーバーヘッドを支払う点です。チップをテーピングの費用は、新しいプロセス技術を駆使した、2年ごとに1.5倍程度上昇しています。実際のデザインと開発費も同様に上昇してきた、技術のそれぞれの新しい世代が2のおよそ倍でデバイス数を増加させるのでこれは必然的に複雑さと人件費の増加につながる新機能とチップ・アーキテクチャを可能にします。新しいチップの開発がメモリをスケールアップする必要性によってのみ駆動された場合は、メモリー構造がスケーリング場合、そして、我々は人件費が固定されたままと期待します。残念ながら、メモリ構造は、一般的に直線的に拡張していないようです。個々のメモリ・コントローラは、メモリの内部オンチップ相互接続のための設計につながる、無視できないコストを持っています。最終結果は、我々はチップの開発コストを約1.5倍2年ごとの継続的な費用曲線につながる、テープアウトコストの増加に合わせておおよそエスカレートし続けることと期待できるということです。各技術のステップは、おおよそのメモリを倍増するので、それは需要が約速く成長している場合（2倍/ 1.5倍）= 1.3倍の年間、その後、技術のリフレッシュが一定の費用曲線に残ることができないことを意味します。
Transistors consume power both when idle ("leakage current") and when switching. The smaller and hotter the transistors, the larger the leakage current. The overall power consumption is not linear with the density increase. Thus, as the need for more powerful routers increases, cooling technology grows more taxed. At present, the existing air cooling system is starting to be a limiting factor for scaling high-performance routers.
トランジスタは、両方のアイドル時（「リーク電流」）の電力を消費して切り替えるとき。より大きな、より小さなトランジスタ高温漏れ電流。全体の消費電力は、密度の増加に伴って線形ではありません。このように、より強力なルータが増加の必要性として、冷却技術は、より多くの課税成長します。現時点では、既存の空気冷却システムは、高性能ルータをスケーリングするための制限因子であることが開始されます。
A key metric for system evaluation is now the unit of forwarding bandwidth per Watt-- [(Mb/s)/W]. About 60% of the power goes to the forwarding engine circuits, with the rest divided between the memories, route processors, and interconnect. Using parallelization to achieve higher bandwidths can aggravate the situation, due to increased power and cooling demands.
システム評価のための重要なメトリックは、現在Watt-- [（Mb /秒）/ W]当たりの転送帯域幅の単位です。電力の約60％はメモリ、ルートプロセッサ、および相互間で分割残りの部分と、転送エンジン回路へ進みます。高い帯域幅を達成するために並列化を使用することにより増加し、電力および冷却要求に、状況を悪化させることができます。
[Editor's note: Many in the community have commented that heat, power consumption, and the attendant heat dissipation, along with size limitations of fabrication processes for high speed parallel I/O interfaces, are the current limiting factors.]
[編集者注：コミュニティの多くは、高速パラレルI / Oインタフェースのための製造プロセスのサイズの制限と共に熱、消費電力、および付随する熱放散は、電流制限要因であることをコメントしています。]
Given the uncontrolled nature of its growth rate, there is some concern about the long-term prospects for the health and cost of the routing subsystem of the Internet. The ongoing growth will force periodic technology refreshes. However, the growth rate can possibly exceed the rate that can be supported at constant cost based on the development costs seen in the router industry. Since high-end routing is based on low-volume technology, the cost advantages that the bulk of the broader computing industry see, based on Moore's law, are not directly inherited. This leads to a sustainable growth rate of 1.3x/2yrs for the forwarding table and 1.2x/2yrs for the routing table. Given that the current baseline growth is at 1.3x/2yrs [CIDRRPT], with bursts that even exceed Moore's law, the trend is for the costs of technology refresh to continue to grow, indefinitely, even in constant dollars.
その成長率の制御不能な性質を考えると、インターネットのルーティングサブシステムの健全性とコストのための長期的な見通しについて、いくつかの懸念があります。継続的な成長は、定期的な技術の更新を強制します。しかし、成長率はおそらくルータ業界で見られる開発コストに基づいて一定のコストでサポートすることができますレートを超えることができます。ハイエンドのルーティングが低ボリューム技術に基づいているため、より広範なコンピューティング業界の大部分は、ムーアの法則に基づいて、参照コストの利点は、直接継承されません。これは、ルーティングテーブルの転送テーブルと1.2倍/ 2yrsのための1.3倍/ 2yrsの持続的な成長率につながります。現在のベースラインの成長もムーアの法則を超えてバーストして1.3倍/ 2yrs [CIDRRPT]、であることを考えると、トレンドにも一定のドルで、無制限に、成長し続けるための技術の更新のコストのためです。
Routing and addressing are two fundamental pieces of the Internet architecture, thus any changes to them will likely impact almost all of the "IP stack", from applications to packet forwarding. In resolving the routing scalability problems, as agreed upon by the workshop attendees, we should aim at a long-term solution. This requires a clear understanding of various trends in the foreseeable future: the growth in Internet user population, the applications, and the technology.
ルーティングとアドレッシングは、このようにそれらの変更の可能性が高いアプリケーションからのパケット転送に、ほぼすべての「IPスタック」の影響を与えるだろう、インターネットアーキテクチャの二つの基本的な部分です。ルーティングのスケーラビリティの問題を解決するには、ワークショップの参加者が合意したように、我々は長期的な解決策を目指す必要があります。インターネットユーザー人口の増加、アプリケーション、および技術：これは予見可能な将来において様々な動向を明確に理解する必要があります。
The backbone operators expect that the current Internet user population base will continue to expand, as measured by the traffic volume, the number of hosts connected to the Internet, the number of customer networks, and the number of regional providers.
バックボーン事業者は、現在のインターネットユーザー人口ベースは、トラフィック量によって測定されるように、インターネットに接続されたホストの数、顧客ネットワークの数、および地域プロバイダの数を拡大していくことを期待しています。
Boeing's Connexion service pioneered the deployment of commercial mobile networks that may change their attachment points to the Internet on a global scale. It is believed that such in-flight Internet connectivity would likely become commonplace in the not-too-distant future. When that happens, there can be multiple thousands of airplane networks in the air at any given time.
ボーイングのConnexionのサービスは、グローバル規模でのインターネットへの接続点を変更することができ、市販のモバイルネットワークの展開を開拓しました。このような飛行中のインターネット接続が可能性が高いそう遠くない将来に一般的になってしまうと考えられています。これが発生すると、任意の時点で、空気中の飛行機ネットワークの複数の何千ものが存在することができます。
Given that today's DFZ RIB already handles over 200,000 prefixes [CIDRRPT], several thousands of mobile networks, each represented by a single prefix announcement, may not necessarily raise serious routing scalability or stability concerns. However, there is an open question regarding whether this number can become substantially larger if other types of mobile networks, such as networks on trains or ships, come into play. If such mobile networks become commonplace, then their impact on the global routing system needs to be assessed.
今日のDFZのRIBはすでに20万人以上の接頭辞[CIDRRPT]、モバイルネットワークの数千、単一のプレフィックスの発表によって表される各を扱うことを考えると、必ずしも深刻なルーティング拡張性や安定性の問題を提起しないことがあります。しかし、そのような電車や船でのネットワークなどのモバイルネットワークの他のタイプは、遊びに来ている場合、この数は実質的に大きくなることができるかどうかについては未解決の問題があります。そのようなモバイルネットワークが一般的になっている場合、グローバルルーティングシステムへの影響を評価する必要があります。
Today's technology trend indicates that billions of hand-held gadgets may come online in the next several years. There were different opinions regarding whether this would, or would not, have a significant impact on global routing scalability. The current solutions for mobile hosts, namely Mobile IP (e.g., [RFC3775]), handle the mobility by one level of indirection through home agents; mobile hosts do not appear any different, from a routing perspective, than stationary hosts. If we follow the same approach, new mobile devices should not present challenges beyond the increase in the size of the host population.
今日の技術動向は、手持ちのガジェットの数十億は今後数年間でオンラインに来るかもしれないことを示しています。グローバルルーティング拡張性に大きな影響を持っている、これはでしょうか、いないかどうかについてはさまざまな意見がありました。モバイルホストのための現在の解決策、すなわち、モバイルIP（例えば、[RFC3775]）は、ホームエージェントを介して間接のレベルによって移動性を取り扱います。モバイルホストは、固定ホストよりも、ルーティングの観点から、任意異なって表示されません。私たちは、同じアプローチに従うならば、新しいモバイルデバイスがホスト人口の大きさの増加を超えて課題を提示するべきではありません。
The workshop participants recognized that the increase in the number of mobile devices can be significant, and that if a scalable routing system supporting generic identity-locator separation were developed and introduced, billions of mobile gadgets could be supported without bringing undue impact on global routing scalability and stability.
ワークショップの参加者は、モバイルデバイスの数の増加が大きくなる可能性があることを認識し、一般的なアイデンティティ・ロケータ分離をサポートするスケーラブルなルーティングシステムが開発され、導入された場合には、モバイルガジェットの数十億は、グローバルルーティングスケーラビリティに不当な影響をもたらすことなく、サポートすることができそして、安定性。
Further investigation is needed to gain a complete understanding of the implications on the global routing system of connecting many new mobile hand-held devices (including mobile sensor networks) to the Internet.
さらなる調査は、インターネットに（モバイルセンサネットワークを含む）多くの新しいモバイルハンドヘルドデバイスを接続するグローバルルーティングシステムに影響の完全な理解を得るために必要とされます。
Over the years, there have been many efforts designed to investigate scalable inter-domain routing for the Internet [IDR-REQS]. To benefit from the insights obtained from these past results, the workshop reviewed several major previous and ongoing IETF efforts:
長年にわたり、[IDR-REQS]インターネットのためのスケーラブルなドメイン間ルーティングを調査するために設計された多くの努力がなされてきました。これらの過去の結果から得られた知見を活用するには、ワークショップでは、いくつかの主要以前と現在進行中のIETF取り組みを検討しました：
1. The MULTI6 working group's exploration of the solution space and the lessons learned,
1. MULTI6ワーキンググループの解空間の探査及び教訓、
2. The solution to multihoming being developed by the SHIM6 Working Group, and its pros and cons,
2.マルチホーミングを解決するには、SHIM6ワーキンググループによって開発され、その長所と短所され、
3. The GSE proposal made by O'Dell in 1997, and its pros and cons, and
3. GSE 1997年にオデル提案により、その長所と短所、および
4. Map-and-Encap [RFC1955], a general indirection-based solution to scalable multihoming support.
4.地図-と-ENCAP [RFC1955]、スケーラブルなマルチホーミングサポートへの一般的な間接ベースのソリューション。
The MULTI6 working group was chartered to explore the solution space for scalable support of IPv6 multihoming. The numerous proposals collected by MULTI6 working group generally fell into one of two major categories: resolving the above-mentioned conflict by using provider-independent address assignments, or by assigning multiple address prefixes to multihomed sites, one for each of its providers, so that all the addresses can be topologically aggregatable.
MULTI6ワーキンググループは、IPv6マルチホーミングのスケーラブルな支援のための解空間を探索するためにチャーターされました。 MULTI6ワーキンググループによって収集された多数の提案は、一般に、2つの主要なカテゴリのいずれかに落ちた：なるように、または、マルチホームサイトへのプロバイダのそれぞれについて1つずつ、複数のアドレスプレフィックスを割り当てることによって、プロバイダ非依存アドレス割り当てを使用することにより、上記の競合を解決しますすべてのアドレスは位相的に集約することができます。
The first category includes proposals of (1) simply allocating provider-independent address space, which is effectively the current practice, and (2) assigning IP addresses based on customers' geographical locations. The first approach does not scale; the second approach represents a fundamental change to the Internet routing system and its economic model, and imposes undue constraints on ISPs. These proposals were found to be incomplete, as they offered no solutions to the new problems they introduced.
第一のカテゴリーは、（1）単純に効果的に現在の慣行であるプロバイダ独立アドレス空間を割り当て、及び（2）顧客の地理的位置に基づいてIPアドレスを割り当てるの提案を含みます。最初のアプローチはスケールしません。第2のアプローチは、インターネットルーティングシステムとその経済モデルへの根本的な変化を表し、やISPに過度の制約を課します。彼らは、彼らが導入された新しい問題への解決策を提供しないように、これらの提案は、不完全であることがわかりました。
The majority of the proposals fell into the second category-- assigning multiple address blocks per site. Because IP addresses have been used as identifiers by higher-level protocols and applications, these proposals face a fundamental design decision regarding which layer should be responsible for mapping the multiple locators (i.e., the multiple addresses received from ISPs) to an identifier. A related question involves which nodes are responsible for handling multiple addresses. One can implement a multi-address scheme at either each individual host or at edge routers of a site, or even both. Handling multiple addresses by edge routers provides the ability to control the traffic flow of the entire site. Conversely, handling multiple addresses by individual hosts offers each host the flexibility to choose different policies for selecting a provider; it also implies changes to all the hosts of a multihomed site.
提案の大半は、サイトごとに複数のアドレスブロックを割り当てる二category--に落ちました。 IPアドレスは、より高いレベルのプロトコルおよびアプリケーションによって識別子として使用されているため、これらの提案は、識別子に（すなわち、複数のアドレスのISPから受け取った）層が複数のロケータをマッピングする責任を負うべきに関する基本的な設計上の決定に直面します。関連する質問は、複数のアドレスを処理する責任があるどのノードが含まれます。一つは、いずれかの個々の各ホストで、またはサイト、あるいはその両方のエッジルータにマルチアドレススキームを実装することができます。エッジルータで複数のアドレスを処理するサイト全体のトラフィックフローを制御する機能を提供します。逆に、個々のホストで複数のアドレスを処理すると、各ホストにプロバイダを選択するための異なるポリシーを選択する柔軟性を提供しています。それはまた、マルチホームサイトのすべてのホストへの変更を意味します。
During the process of evaluating all the proposals, two major lessons were learned:
すべての提案を評価するプロセスの間に、二つの主要な教訓を学びました。
o Changing anything in the current practice is hard: for example, inserting an additional header into the protocol would impact IP fragmentation processing, and the current congestion control assumes that each TCP connection follows a single routing path. In addition, operators ask for the ability to perform traffic engineering on a per-site basis, and specification of site policy is often interdependent with the IP address structure.
例えば、プロトコルに追加ヘッダを挿入すると、IPフラグメンテーション処理に影響を与える、と現在の輻輳制御は、各TCP接続は単一のルーティング経路を辿ることを前提としています現在、実際には何も変更O型硬あります。また、事業者は、サイト単位でトラフィック・エンジニアリングを実行する能力について尋ねると、サイトポリシーの仕様は、多くの場合、IPアドレスの構造と相互依存しています。
o The IP address has been used as an identifier and has been codified into many Internet applications that manipulate IP addresses directly or include IP addresses within the application layer data stream. IP addresses have also been used as identifiers in configuring network policies. Changing the semantics of an IP address, for example, using only the last 64- bit as identifiers as proposed by GSE, would require changes to all such applications and network devices.
O IPアドレスが識別子として使用されており、アプリケーション層データストリーム内のIPアドレスを直接IPアドレスを操作したり含む多くのインターネットアプリケーションに体系化されています。 IPアドレスは、ネットワークポリシーを設定するには、識別子として使用されています。 GSEによって提案された識別子としてのみ、最後の64ビットを使用して、例えば、IPアドレスのセマンティクスを変更する、そのようなすべてのアプリケーションやネットワークデバイスへの変更が必要となります。
The SHIM6 working group took the second approach from the MULTI6 working group's investigation, i.e., supporting multihoming through the use of multiple addresses. SHIM6 adopted a host-based approach, where the host IP stack includes a "shim" that presents a stable "upper layer identifier" (ULID) to the upper layer protocols, but may rewrite the IP packets sent and received so that a currently working IP address is used in the transmitted packets. When needed, a SHIM6 header is also included in the packet itself, to signal to the remote stack.
SHIM6ワーキンググループは、複数のアドレスを使用してマルチホーミング支援、すなわちMULTI6ワーキンググループの調査から、第二のアプローチを取りました。 SHIM6ホストIPスタックが「シム」上位層プロトコルに安定した「上位層識別子」（ULID）を提示するが、現在の作業ように送信され、受信したIPパケットを書き換えることができることを含むホストベースのアプローチを採用しましたIPアドレスが送信されたパケットで使用されています。必要なとき、SHIM6ヘッダは、リモートスタックに知らせるために、パケット自体に含まれています。
With SHIM6, protocols above the IP layer use the ULID to identify endpoints (e.g., for TCP connections). The current design suggests choosing one of the locators as the ULID (borrowing a locator to be used as an identifier). This approach makes the implementation compatible with existing IPv6 upper layer protocol implementations and applications. Many of these applications have inherited the long time practice of using IP addresses as identifiers.
SHIM6と、IPレイヤ上のプロトコルは、（TCP接続のために、例えば）エンドポイントを識別するためにULIDを使用します。現在の設計は、（識別子として使用するロケータを借り）ULIDとしてロケータのいずれかを選択することを示唆しています。このアプローチは、既存のIPv6上位層プロトコルの実装およびアプリケーションと互換性のある実装を行います。これらのアプリケーションの多くは、識別子としてIPアドレスを使用して、長い時間の練習を継承しています。
SHIM6 is able to isolate upper layer protocols from multiple IP layer addresses. This enables a multihomed site to use provider-allocated prefixes, one from each of its multiple providers, to facilitate provider-based prefix aggregation. However, this gain comes with several significant costs. First, SHIM6 requires modifications to all host stack implementations to support the shim processing. Second, the shim layer must maintain the mapping between the identifier and the multiple locators returned from IPv6 AAAA name resolution, and must take the responsibility to try multiple locators if failures ever occur during the end-to-end communication. At this time, the host has little information to determine the order of locators it should use in reaching a multihomed destination, however, there is ongoing effort in addressing this issue.
SHIM6は、複数のIP層アドレスから上位層プロトコルを分離することができます。これは、プロバイダベースのプレフィックス集約を促進するために、プロバイダに割り当てられたプレフィックス、その複数のプロバイダのそれぞれからのいずれかを使用するマルチホームサイトを可能にします。しかし、このゲインは、いくつかの重要なコストが付属しています。まず、SHIM6はシム処理をサポートするために、すべてのホストスタックの実装を変更する必要があります。第二に、シム層は、識別子とIPv6 AAAAの名前解決から返された複数のロケータとの間のマッピングを維持しなければならない、と失敗が今までのエンド・ツー・エンドの通信中に発生した場合、複数のロケータを試して責任を取る必要があります。このとき、ホストはそれがマルチホーム宛先に到達して使用する必要がありますロケータの順序を決定するためにほとんど情報を持っている、しかし、この問題に対処するための継続的な努力があります。
Furthermore, as a host-based approach, SHIM6 provides little control to the service provider for effective traffic engineering. At the same time, it also imposes additional state information on the host regarding the multiple locators of the remote communication end. Such state information may not be a significant issue for individual user hosts, but can lead to larger resource demands on large application servers that handle hundreds of thousands of simultaneous TCP connections.
さらに、ホストベースのアプローチとして、SHIM6は、効果的なトラフィックエンジニアリングのためのサービスプロバイダにほとんど制御を提供します。同時に、それはまた、遠隔通信エンドの複数のロケータについてホストに追加の状態情報を課します。このような状態情報は、個々のユーザのホストにとって重要な問題ではないかもしれませんが、同時TCP接続の数十万人を扱う大規模なアプリケーションサーバー上の大きなリソース要求につながることができます。
Yet another major issue with the SHIM6 solution is the need for renumbering when a site changes providers. Although a multihomed site is assigned multiple address blocks, none of them can be treated as a persistent identifier for the site. When the site changes one of its providers, it must purge the address block of that provider from the entire site. The current practice of using the IP address as both an identifier and a locator has been strengthened by the use of IP addresses in access control lists present in various types of policy-enforcement devices (e.g., firewalls). If SHIM6's ULIDs are to be used for policy enforcement, a change of providers may necessitate the re-configuration of many such devices.
しかしSHIM6溶液でもう一つの大きな問題は、サイトがプロバイダを変更するリナンバリングの必要性があります。マルチホームのサイトは、複数のアドレスブロックを割り当てられているが、それらのどれもサイトの永続的な識別子として扱うことができません。サイトはそのプロバイダのいずれかを変更すると、それはサイト全体からそのプロバイダのアドレスブロックを消去する必要があります。識別子及びロケータの両方としてIPアドレスを使用して現在の実務は、ポリシー施行デバイスの様々なタイプ（例えば、ファイアウォール）内に存在するアクセス制御リスト内のIPアドレスを使用することによって強化されています。 SHIM6のULIDsは、ポリシー適用のために使用する場合は、プロバイダの変更が多く、そのようなデバイスの再構成が必要になる場合があります。
The use of indirection for scalable multihoming was discussed at the workshop, including the GSE [GSE] and indirection approaches, such as Map-and-Encap [RFC1955], in general. The GSE proposal changes the IPv6 address structure to bear the semantics of both an identifier and a locator. The first n bytes of the 16-byte IPv6 address are called the Routing Goop (RG), and are used by the routing system exclusively as a locator. The last 8 bytes of the IPv6 address specify an interface on an end-system. The middle (16 - n - 8) bytes are used to identify site local topology. The border routers of a site re-write the source RG of each outgoing packet to make the source address part of the source provider's address aggregation; they also re-write the destination RG of each incoming packet to hide the site's RG from all the internal routers and hosts. Although GSE designates the lower 8 bytes of the IPv6 address as identifiers, the extent to which GSE could be made compatible with increasingly-popular cryptographically-generated addresses (CGA) remains to be determined [dGSE].
スケーラブル・マルチホーミングのためのインダイレクションを使用することは一般的に、GSE [GSE]と、地図アンドENCAPなどの間接アプローチ、[RFC1955]を含む、ワークショップで議論されました。 GSEの提案は、識別子とロケータの両方の意味を負担するIPv6アドレスの構造を変更します。 16バイトのIPv6アドレスの最初のnバイトルーティングGOOP（RG）と呼ばれ、ロケータとしてのみルーティングシステムによって使用されます。 IPv6アドレスの最後の8つのバイトは、エンドシステムにインターフェイスを指定します。中間（16 - nが - 8）バイトは、サイトローカルトポロジを識別するために使用されます。サイトの境界ルータは、ソース・プロバイダのアドレス集約の送信元アドレス部を作るために、各送信パケットの送信元のRGを再書き込み。彼らはまた、すべての内部ルータとホストからサイトのRGを非表示にするには、各着信パケットの宛先RGを再書き込み。 GSEが識別子としてIPv6アドレスの下位8バイトを指定しているが、GSEがますます人気暗号-生成されたアドレス（CGA）と互換性行うことができる程度は[dGSE】決定されていません。
All identifier/locator split proposals require a mapping service that can return a set of locators corresponding to a given identifier. In addition, these proposals must also address the problem of detecting locator failures and redirecting data flows to remaining locators for a multihomed site. The Map-and-Encap proposal did not address these issues. GSE proposed to use DNS for providing the mapping service, but it did not offer an effective means for locator failure recovery. GSE also requires host stack modifications, as the upper layers and applications are only allowed to use the lower 8-bytes, rather than the entire, IPv6 address.
すべての識別子/ロケータ分離案は、与えられた識別子に対応するロケータのセットを返すことができるマッピングサービスを必要とします。また、これらの提案はまた、ロケータ障害を検出し、データをリダイレクトの問題に対処しなければならないマルチホームのサイトの残りのロケータに流れます。地図-と-ENCAPの提案は、これらの問題に対応していませんでした。 GSEは、マッピング・サービスを提供するためのDNSを使用することが提案されているが、それはロケータ障害回復のための有効な手段を提供していませんでした。上位層およびアプリケーションのみ、むしろ全体よりも、IPv6アドレスの下位8バイトを使用することが許可されているようにGSEはまた、ホスト・スタックの変更を必要とします。
As the saying goes, "There is no problem in computer science that cannot be solved by an extra level of indirection". The GSE proposal can be considered a specific instantiation of a class of indirection-based solutions to scalable multihoming. Map-and-Encap [RFC1955] represents a more general form of this indirection solution, which uses tunneling, instead of locator rewriting, to cross the DFZ and support provider-based prefix aggregation. This class of solutions avoids the provider and customer conflicts regarding PA and PI prefixes by putting each in a separate name space, so that ISPs can use topologically aggregatable addresses while customers can have their globally unique and provider-independent identifiers. Thus, it supports scalable multihoming, and requires no changes to the end systems when the encapsulation is performed by the border routers of a site. It also requires no changes to the current practice of both applications as well as backbone operations.
諺にように、「間接の余分なレベルでは解決できないコンピュータサイエンスの問題はありません」。 GSEの提案は、スケーラブルなマルチホーミングへの間接ベースのソリューションのクラスの特定のインスタンス化と見なすことができます。マップ・アンド・ENCAP [RFC1955] DFZを横断し、プロバイダベースプレフィックス集約をサポートするために、代わりにロケータ書き換えの、トンネリングを使用し、この間接溶液、より一般的な形態を表します。顧客がグローバルに一意とプロバイダ非依存の識別子を有することができるISPがトポロジー的に集約アドレスを使用できるように、ソリューションのこのクラスは、別の名前空間にそれぞれを置くことによってPA及びPIプレフィックスに関するプロバイダと顧客の競合を回避できます。したがって、それは、スケーラブルなマルチホーミングをサポートし、カプセル化は、サイトの境界ルータによって実行されたときにエンドシステムを変更する必要はありません。また、現在の両方のアプリケーションの練習だけでなく、基幹業務を変更する必要はありません。
However, all gains of an effective solution are accompanied with certain associated costs. As stated earlier in this section, a mapping service must be provided. This mapping service not only brings with it the associated complexity and cost, but it also adds another point of failure and could also be a potential target for malicious attacks. Any solution to routing scalability is necessarily a cost/benefit tradeoff. Given the high potential of its gains, this indirection approach deserves special attention in our search for scalable routing solutions.
しかし、効果的なソリューションのすべての利益は、特定の関連コストを伴うされています。このセクションですでに述べたように、マッピングサービスが提供されなければなりません。このマッピングサービスは、それに関連する複雑さとコストをもたらすだけでなく、故障の別のポイントを追加し、また悪意のある攻撃の潜在的なターゲットである可能性があります。スケーラビリティをルーティングする任意の溶液は、必ずしもコスト/利益のトレードオフです。その利益の高いポテンシャルを考えると、この間接的なアプローチは、スケーラブルなルーティングソリューションのためのGoogleの検索に特別な注意に値します。
The fundamental goal of this workshop was to develop a prioritized problem statement regarding routing and addressing problems facing us today, and the workshop spent a considerable amount of time on reaching that goal. This section provides a description of the prioritized problem statement, together with elaborations on both the rationale and open issues.
このワークショップの基本的な目標は、ルーティングに関する優先順位を付け、問題文を開発することでしたし、今日私たちが直面している問題に対処し、ワークショップでは、その目標を達成するにはかなりの時間を費やしました。このセクションでは、一緒に根拠と未解決の問題の両方に推敲して、優先順位をつけ、問題文の記述を提供します。
The workshop participants noted that there exist different classes of stakeholders in the Internet community who view today's global routing system from different angles, and assign different priorities to different aspects of the problem set. The prioritized problem statement in this section is the consensus of the participants in this workshop, representing primarily large network operators and a few router vendors. It is likely that a different group of participants would produce a different list, or with different priorities. For example, freedom to change providers without renumbering might make the top of the priority list assembled by a workshop of end users and enterprise network operators.
ワークショップの参加者は、異なる角度から、今日のグローバルルーティングシステムを表示し、問題セットの異なる側面に異なる優先順位を割り当てるインターネットコミュニティの利害関係者の異なるクラスが存在することを指摘しました。このセクションの優先順位の問題文は、主に大規模なネットワーク事業者といくつかのルータベンダーを表す、このワークショップの参加者のコンセンサスです。参加者の異なるグループが別のリストを生成する可能性が高い、または異なる優先順位です。例えば、リナンバリングなしでプロバイダを変更する自由は、エンドユーザーと企業のネットワークオペレータのワークショップで組み立て優先順位リストの一番上になるかもしれません。
The workshop participants believe that routing scalability is the most important problem facing the Internet today and must be solved, although the time frame in which these problems need solutions was not directly specified. The routing scalability problem includes the size of the DFZ RIB and FIB, the implications of the growth of the RIB and FIB on routing convergence times, and the cost, power (and hence, heat dissipation) and ASIC real estate requirements of core router hardware.
ワークショップの参加者は、スケーラビリティをルーティングすることは、今日のインターネットが直面している最も重要な問題であり、これらの問題が解決策を必要とする時間枠を直接指定されなかったが、解決しなければならないと考えています。ルーティングスケーラビリティの問題がDFZ RIBおよびFIBのサイズ、収束時間をルーティング上のRIBおよびFIBの成長の意味合い、およびコスト、消費電力（したがって、熱放散）とコアルータハードウェアのASIC不動産要件を含んでいます。
It is commonly believed that the IPv4 RIB growth has been constrained by the limited IPv4 address space. However, even under this constraint, the DFZ IPv4 RIB has been growing at what appears to be an accelerating rate [DFZ]. Given that the IPv6 routing architecture is the same as the IPv4 architecture (with substantially larger address space), if/when IPv6 becomes widely deployed, it is natural to predict that routing table growth for IPv6 will only exacerbate the situation.
一般的にはIPv4 RIBの成長が制限されたIPv4アドレス空間によって制約されてきたと考えられています。しかし、この制約の下で、DFZのIPv4 RIBは、加速率[DFZ]と思われるもので成長してきました。 IPv6が広く展開になると、唯一の状況を悪化させるであろうIPv6のそのルーティングテーブルの成長を予測することは自然であるIF / IPv6ルーティングアーキテクチャは、IPv4のアーキテクチャとして（実質的に大きなアドレス空間を持つ）同一であることを考えます。
The increasing deployment of Virtual Private Network/Virtual Routing and Forwarding (VPN/VRF) is considered another major factor driving the routing system growth. However, there are different views regarding whether this factor has, or does not have, a direct impact to the DFZ RIB. A common practice is to delegate specific routers to handle VPN connections, thus backbone routers do not necessarily hold state for individual VPNs. Nevertheless, VPNs do represent scalability challenges in network operations.
仮想プライベートネットワーク/仮想ルーティングおよびフォワーディング（VPN / VRF）の増加展開がルーティングシステムの成長を駆動する別の大きな要因と考えられています。しかし、この要因は、DFZのRIBへの直接的な影響を持っているか、いないかどうかについて異なる見解があります。一般的な方法は、このようバックボーンルータは必ずしも個々のVPNの状態を保持していない、VPN接続を処理するために、特定のルータを委任することです。それにもかかわらず、VPNは、ネットワーク運用におけるスケーラビリティの課題を表しています。
As we have reported in Section 3, multihoming, along with traffic engineering, appear to be the major factors driving the growth of the DFZ RIB. Below, we elaborate their impact on the DFZ RIB.
私たちは第3章で報告してきたように、マルチホーミングは、トラフィックエンジニアリングとともに、DFZ RIBの成長を駆動する主要な要因であるように思われます。以下に、我々はDFZ RIBへの影響を詳しく説明します。
Roughly speaking, the Internet comprises a large number of transit networks and a much larger number of customer networks containing hosts that are attached to the backbone. Viewing the Internet as a graph, transit networks have branches and customer networks with hosts hang at the edges as leaves.
大雑把に言えば、インターネットは、トランジットネットワークの数が多いと、バックボーンに接続されているホストを含む顧客のネットワークのはるかに大きい数を含みます。ホストが葉のようにエッジでハングアップしてグラフとしてインターネットを見ると、中継ネットワークは支店と顧客のネットワークを持っています。
As its name suggests, locators identify locations in the topology, and a network's or host's locator should be topologically constrained by its present position. Identifiers, in principle, should be network-topology independent. That is, even though a network or host may need to change its locator when it is moved to a different set of attachment points in the Internet, its identifier should remain constant.
その名前が示唆するように、ロケータは、トポロジ内の位置を識別し、ネットワークのまたはホストのロケータは、トポロジー的にその現在位置によって制約されるべきです。識別子は、原則的には、ネットワーク・トポロジー独立しているべきです。すなわち、ネットワークまたはホストは、それがインターネットに接続点の異なるセットに移動すると、その識別子が一定のままであるべきで、そのロケータを変更する必要があるとしても、です。
From an ISP's viewpoint, identifiers identify customer networks and customer hosts. Note that the word "identifier" used here is defined in the context of the Internet routing system; the definition may well be different when the word "identifier" is used in other contexts. As an example, a non-routable, provider-independent IP prefix for an enterprise network could serve as an identifier for that enterprise. This block of IP addresses can be used to route packets inside the enterprise network. However, they are independent from the DFZ topology, which is why they are not globally routable on the Internet.
ISPの観点からは、識別子は、顧客のネットワークと顧客のホストを識別します。ここで使用される用語「識別子」は、インターネットルーティングシステムのコンテキストで定義されていることに留意されたいです。単語「識別子」は、他のコンテキストで使用されたときに定義がうまく異なる場合があります。一例として、企業ネットワークのためのルーティング不可能な、プロバイダに依存しないIPプレフィックスは、その企業の識別子として役立つことができます。 IPアドレスのこのブロックは、企業ネットワーク内のルートパケットに使用することができます。しかし、彼らは、インターネット上でグローバルにルーティング可能ではない理由ですDFZトポロジーから独立しています。
Note that in cases such as the last example, the definition of locators and identifiers can be context-dependent. Following the example further, a PI address may be routable in an enterprise but not the global network. If allowed to be visible in the global network, such addresses might act as identifiers from a backbone operator's point of view but locators from an enterprise operator's point of view.
例えば最後の例のような場合には、ロケータと識別子の定義は、文脈に依存することができることに留意されたいです。さらなる例に続いて、PIアドレスは、企業内のルーティング可能ではなく、グローバルなネットワークであってもよいです。グローバルネットワークで表示されるように許可された場合は、そのようなアドレスは、ビューの企業のオペレータの視点から眺めたがロケータのバックボーンオペレータの視点からの識別子として機能することがあります。
In today's Internet architecture, IP addresses have been used as both locators and identifiers. Combined with the use of CIDR to perform route aggregation, a problem arises for either providers or customers (or both).
今日のインターネットのアーキテクチャでは、IPアドレスがロケータと識別子の両方として使用されています。ルート集約を実行するためにCIDRの使用と組み合わせることで、問題がプロバイダや顧客（あるいはその両方）のいずれかのために発生します。
Consider, for example, a campus network C that received prefix x.y.z/24 from provider P1. When C multihomes with a second provider P2, both P1 and P2 must announce x.y.z/24 so that C can be reached through both providers. In this example, the prefix x.y.z/24 serves both as an identifier for C, as well as a (non-aggregatable) locator for C's two attachment points to the transit system.
例えば、プロバイダP1から接頭X.Y.Z / 24を受信したキャンパスネットワークCを考えます。第二プロバイダP2とするときCのマルチホームは、P1とP2の両方がので、Cが両方のプロバイダを介して到達することができるX.Y.Z / 24を発表しなければなりません。この例では、プレフィックスX.Y.Z / 24 Cの識別子、並びに輸送システムにCの2つの取り付け点について（非集約）ロケータの両方として機能します。
As far as the DFZ RIB is concerned, the above example shows that customer multihoming blurs the distinction between PA and PI prefixes. Although C received a PA prefix x.y.z/24 from P1, C's multihoming forced this prefix to be announced globally (equivalent to a PI prefix), and forced the prefix's original owner, provider P1, to de-aggregate. As a result, today's multihoming practice leads to a growth of the routing table size in proportion to the number of multihomed customers. The only practical way to scale a routing system today is topological aggregation, which gets destroyed by customer multihoming.
限りDFZのRIBに関しては、上記の例では、顧客のマルチホーミングはPAおよびPIプレフィックスの間の区別をあいまいにすることを示しています。 Cは、P1からPAプレフィックスX.Y.Z / 24を受信したが、Cのマルチホーミングは、グローバルに発表されるこのプレフィックス（PIプレフィックスに相当する）の強制、および脱凝集のために、接頭辞の元の所有者、プロバイダP1を強制しました。その結果、今日のマルチホーミングの練習は、マルチホームの顧客の数に比例して、ルーティングテーブルサイズの成長につながります。今日のルーティングシステムを拡張するための唯一の実用的な方法は、顧客のマルチホーミングによって破壊されますトポロジカル集約、です。
Although multihoming may blur the PA/PI distinction, there exists a big difference between PA and PI prefixes when a customer changes its provider(s). If the customer has used a PA prefix from a former provider P1, the prefix is supposed to be returned to P1 upon completion of the change. The customer is supposed to get a new prefix from its new provider, i.e., renumbering its network. It is necessary for providers to reclaim their PA prefixes from former customers in order to keep the topological aggregatiblity of their prefixes. On the other hand, renumbering is considered very painful, if not impossible, by many Internet users, especially large enterprise customers. It is not uncommon for IP addresses in such enterprises to penetrate deeply into various parts of the networking infrastructure, ranging from applications to network management (e.g., policy databases, firewall configurations, etc.). This shows how fragile the system becomes due to the overloading of IP addresses as both locators and identifiers; significant enterprise operations could be disrupted due to the otherwise simple operation of switching IP address prefix assignment.
マルチホーミングは、PA / PIの区別をあいまいかもしれないが、顧客がそのプロバイダ（複数可）を変更した場合、PAおよびPIプレフィックスの間には大きな差があります。顧客が旧プロバイダP1からPAの接頭辞を使用している場合、接頭辞は、変更の完了時にP1に返すことになっています。顧客は、すなわち、そのネットワークを再番号付け、その新しいプロバイダから新しいプレフィクスを取得することになっています。プロバイダーは接頭辞のトポロジカルaggregatiblityを維持するために、かつての顧客から自分のPAプレフィックスを再利用することが必要です。一方、リナンバリングは、多くのインターネットユーザー、特に大企業のお客様により、非常に痛い、不可能ではないと考えられています。これは、ネットワーク管理アプリケーションに至るまで、ネットワークインフラストラクチャの様々な部分に深く浸透するような企業内のIPアドレスは珍しいことではない（例えば、ポリシーデータベース、ファイアウォール設定、等）。これは、システムがロケータと識別子の両方としてIPアドレスのオーバーロードのためになるとどのように壊れやすく示しています。重要な企業の業務が原因IPアドレスのプレフィックスの割り当てを切り替えるそう簡単な操作を中断することができます。
In today's practice, traffic engineering (TE) is achieved by de-aggregating IP prefixes. One can effectively adjust the traffic volume along specific routing paths by adjusting the prefix lengths and the number of prefixes announced through those paths. Thus, the very means of TE practice directly conflicts with constraining the routing table growth.
今日の練習では、トラフィックエンジニアリング（TE）は、解凝集IPプレフィックスによって達成されます。一つは、効果的プレフィックス長およびそれらのパスを介して発表プレフィックスの数を調整することにより、特定のルーティング経路に沿ってトラフィック量を調整することができます。このように、TEの練習の非常手段が直接ルーティングテーブルの成長を制約と競合します。
On the surface, traffic engineering induced prefix de-aggregation seems orthogonal to the locator-identifier overloading problem. However, this may not necessarily be true. Had all the IP prefixes been topologically aggregatable to start with, it would make re-aggregation possible or easier, when the finer granularity prefix announcements propagate further away from their origins.
表面には、トラフィックエンジニアリング誘発プレフィックスデ集約はロケータ識別子の過負荷問題に直交するようです。しかし、これは必ずしも真実ではないかもしれません。すべてのIPプレフィックスで始まることがトポロジカルに集約されていたより細かい粒度の接頭語のアナウンスが遠く、その起源から伝播するとき、それは、再凝集可能または容易になるだろう。
There are two kinds of routing convergence issues, eBGP (global routing) convergence and IGP (enterprise or provider) routing convergence. Upon isolated topological events, eBGP convergence does not suffer from extensive path explorations in most cases [PathExp], and convergence delay is largely determined by the minimum route advertisement interval (MRAI) timer [RFC4098], except those cases when a route is withdrawn. Route withdrawals tend to suffer from path explorations and hence slow convergence; one participant's experience suggests that the withdrawal delays often last up to a couple of minutes. One may argue that, if the destination becomes unreachable, a long convergence delay would not bring further damage to applications. However, there are often cases where a more specific route (a longer prefix) has failed, yet the destination can still be reached through an aggregated route (a shorter prefix). In these cases, the long convergence delay does impact application performance.
収束ルーティング収束の問題をルーティングする、のeBGP（グローバルルーティング）収束とIGP（企業またはプロバイダ）の2種類があります。単離されたトポロジカルなイベントの際に、のeBGP収束[PathExp】ほとんどの場合、広範経路探査を被らない、収束遅延は、主経路が引き抜かれるような場合を除いて、最小経路広告間隔（MRAI）タイマー[RFC4098]によって決定されます。ルートの引き出しには、パスの探査、したがって遅い収束に苦しむ傾向にあります。 1人の参加者の経験は、撤退の遅延は、多くの場合、数分まで続くことを示唆しています。一つは、宛先が到達不能になった場合、長い収束遅延がアプリケーションへのさらなる損傷をもたらすことはないだろう、と主張していることがあります。しかし、より具体的なルート（長い接頭辞）が失敗した例がしばしばありますが、まだ先はまだ集約ルート（短いプレフィックス）を介して到達することができます。これらのケースでは、長い収束遅延が影響、アプリケーションのパフォーマンスを行います。
While IGPs are designed to and do converge more quickly than BGP might, the workshop participants were concerned that, in addition to the various special purpose routes that IGPs must carry, the rapid growth of the DFZ RIB size can effectively slow down IGP convergence. The IGP convergence delay can be due to multiple factors, including
IGPをするように設計されており、より迅速にBGPよりも収束しないが、ワークショップの参加者は懸念していたのIGPを運ばなければならない様々な特殊目的のルートに加えて、DFZのRIBサイズの急速な成長を効果的IGPの収束を遅らせることができるかもしれない、ということ。 IGP収束遅延を含む、複数の要因に起因することができ
3. The large size of the internal RIB, often twice as big as the DFZ RIB, which can lead to both longer route computation time and longer FIB loading time.
3.長い経路計算時間と長いFIBのロード時間の両方につながることができDFZ RIB、できるだけ頻繁2倍の大き内部RIBの大型サイズ。
The workshop participants hold different views regarding (1) the severity of the routing convergence problem; and (2) whether it is an architectural problem, or an implementation issue. However, people generally agree that if we solve the routing scalability problem, that will certainly help reduce the convergence delay or make the problem a much easier one to handle because of the reduced number of routes to process.
ワークショップの参加者は、ルーティング収束問題の（1）重症度に関する異なるビューを保持します。そして（2）それは建築の問題、あるいは実装の問題であるかどうか。しかし、人々は一般的ならば、我々は確かにあるため処理するための経路数の減少の収束遅延を減らすか、問題処理する方がはるかに簡単になります1ルーティングのスケーラビリティの問題を、解決することに同意します。
Today's rapid growth of the DFZ RIB is driven by a few major factors, including multihoming and traffic engineering, in addition to the organic growth of the Internet's user base. There is a powerful incentive to deploy each of the above features, as they bring direct benefits to the parties who make use of them. However, the beneficiaries may not bear the direct costs of the resulting routing table size increase, and there is no measurable or enforceable constraint to limit such increase.
DFZ RIBの今日の急速な成長は、インターネットのユーザーベースの有機的成長に加えて、マルチホーミングとトラフィックエンジニアリング、など、いくつかの主要な要因によって駆動されます。彼らはそれらを利用して関係者に直接利益をもたらすとして、上記の各機能を展開するための強力なインセンティブがあります。しかし、受益者は、得られたルーティングテーブルサイズの増加の直接的な費用を負担しないことがあり、そのような増加を制限する測定可能または強制力の制約は存在しません。
For example, suppose that a service provider has two bandwidth-constrained transoceanic links and wants to split its prefix announcements in order to fully load each link. The origin AS benefits from performing the de-aggregation. However, if the de-aggregated announcements propagate globally, the cost is born by all other ASs. That is, the costs of this type of TE practice are not contained to the beneficiaries. Multihoming provides a similar example (in this case, the multihomed site achieves a benefit, but the global Internet incurs the cost of carrying the additional prefix(es)).
例えば、サービスプロバイダは、2つの帯域幅に制約の大洋横断のリンクがあり、完全に各リンクをロードするために、そのプレフィックスのアナウンスを分割したいとします。デ・集約を行いから恩恵AS起源。デ集計の発表が世界的に伝播する場合は、コストが他のすべてのASによって生まれています。つまり、TEの練習のこのタイプの費用は受益者に含まれていません。マルチホーミングは、（この場合には、マルチホームサイトが利益を達成したが、グローバルなインターネットは、追加の接頭語（ES）を運ぶのコストが発生）同様の例を提供します。
The misalignment of cost and benefit in the current routing system has been a driver for acceleration of the routing system size growth.
現在のルーティングシステムにおけるコストと利益のずれは、ルーティングシステムのサイズの成長を促進するためのドライバでした。
Mobility was among the most frequently mentioned issues at the workshop. It is expected that billions of mobile gadgets may be connected to the Internet in the near future. There was also a discussion on network mobility as deployed in the Connexion service provided by Boeing over the last few years. However, at this time it seems unclear (1) whether the Boeing-like network mobility support would cause a scaling issue in the routing system, and (2) exactly what would be the impact of billions of mobile hosts on the global routing system. These discussions were covered in Section 5 of this report.
モビリティは、ワークショップで最も頻繁に言及した課題の一つでした。モバイルガジェットの十億が近い将来にインターネットに接続することができることが期待されます。過去数年間でボーイングが提供するConnexionのサービスに展開としてネットワークモビリティに関する議論もありました。しかし、この時点では、（1）ボーイングのようなネットワークモビリティサポートは、ルーティングシステムでスケーリング問題を引き起こすかどうかは不明だが、および（2）グローバルルーティングシステム上のモバイルホストの数十億の影響だろうまさに。これらの議論は、このレポートのセクション5で覆われていました。
Routing security is another issue that was brought up a number of times during the workshop. The consensus from the workshop participants was that, however important routing security may be, it was out of scope for this workshop, whose main goal was to produce a problem statement about addressing and routing scalability. It was duly considered that security must be one of the top design goals when we get to a solution development stage. It was also noted that, if we continue to allow the routing table to grow indefinitely, then it may be impossible to add security enhancements in the future.
ルーティングのセキュリティはワークショップで回数を育てた別の問題です。ワークショップ参加者からのコンセンサスは、それがその主な目標のアドレッシングとスケーラビリティのルーティングに関する問題文を生成するためにだったこのワークショップ、の範囲外だった、しかし、重要なルーティング、セキュリティがであってもよいということでした。これは、正式に私たちがソリューション開発段階に到達すると、セキュリティがトップ設計目標の一つでなければならないと考えられました。それはまた、我々は、ルーティングテーブルが無限に成長できるように続けば、将来的にセキュリティ機能を追加することは不可能かもしれ、と述べました。
The first step in solving a problem is recognizing its existence as well as its importance. However, recognizing the severity of the routing scaling issue can be a challenge by itself, because there does not exist a specific hard limit on routing system scalability that can be easily demonstrated, nor is there any specific answer to the question of how much time we may have in developing a solution. Nevertheless, a general consensus among the workshop participants is that we seem to be running out of time. The current RIB scaling leads to both accelerated hardware cost increases, as explained in Section 4, as well as pressure for shorter depreciation cycles, which in turn also translates to cost increases.
問題を解決する最初のステップは、その存在だけでなく、その重要性が認識されます。簡単に立証することができ、システムのスケーラビリティをルーティング上の特定のハードリミットが存在しない、またどのくらいの時間、私たちの質問に対する具体的な答えがあるのでしかし、ルーティングスケーリング問題の深刻さを認識することは、それ自体で挑戦することができますソリューションの開発に持っていることがあります。それにもかかわらず、ワークショップ参加者の間で一般的なコンセンサスは、我々は時間が不足しているように見えるということです。今度は、コスト増加に変換短い償却サイクル、圧力ならびに、セクション4で説明したように、現在のRIBスケーリングは、両方の加速ハードウェアコストの増加につながります。
Any common problem statement may admit multiple different solutions. This section provides a set of considerations, as identified from the workshop discussion, over the solution space. Given the heterogeneity among customers and providers of the global Internet, and the elasticity of the problem, none of these considerations should inherently preclude any specific solution. Consequently, although the following considerations were initially deemed as constraints on solutions, we have instead opted to adopt the term 'criteria' to be used in guiding solution evaluations.
任意の共通の問題文は、複数の異なるソリューションを認めることがあります。解空間上で、ワークショップの議論から識別されるようにこのセクションでは、検討事項のセットを提供します。顧客およびグローバルなインターネットのプロバイダー間の異質、及び問題の弾力性を考えると、これらの考慮事項はいずれも本質的に任意の具体的な解決策を排除するべきではありません。次の考慮事項が最初のソリューションの制約とみなしたが結果的に、我々は、代わりにソリューション評価を導くに使用される用語「基準」を採用することを選択しました。
Clearly, any proposed solution must solve the problem at hand, and our number one problem concerns the scalability of the Internet's routing and addressing system(s) as outlined in previous sections. Under the assumption of continued growth of the Internet user population, continued increases of multihoming and RFC 2547 VPN [RFC2547] deployment, the solution must enable the routing system to scale gracefully, as measured by the number of o DFZ Internet routes, and
明らかに、任意の提案された解決策は、当面の問題を解決しなければならない、と私たちのナンバーワンの問題は、前のセクションで説明したようインターネットのルーティングのスケーラビリティおよびアドレッシングシステム（複数可）に関するものです。インターネットユーザ人口、マルチホーミング及びRFC 2547の継続的な増加VPN [RFC2547]の展開の継続的な成長の仮定の下で、溶液は、O DFZインターネットルートの数によって測定されるように、正常にスケーリングするルーティングシステムを有効にしなければなりません
o Internal routes.
内部のルートO。
In addition, scalable support for traffic engineering (TE) must be considered as a business necessity, not an option. Capacity planning involves placing circuits based on traffic demand over a relatively long time scale, while TE must work more immediately to match the traffic load to the existing capacity and to match the routing policy requirements.
また、トラフィックエンジニアリング（TE）のためのスケーラブルなサポートは、ビジネスの必要性ではなく、オプションとして考えなければなりません。 TEは、既存の容量にトラフィック負荷を一致させるために、よりすぐに働かなければならないとルーティングポリシーの要件に合致するようにしながら、キャパシティプランニングは、比較的長い時間スケールを超えるトラフィック需要に基づいて回路を置くことが含まれます。
It was recognized that different parties in the Internet may have different specific TE requirements. For example,
これは、インターネットで異なる当事者が異なる特定のTE要件を持っていることが認められました。例えば、
o End site TE: based on locally determined performance or cost policies, end sites may wish to control the traffic volume exiting to, or entering from specific providers.
OエンドサイトTEは：ローカル決定性能やコストポリシーに基づいて、エンドサイトはに出て行くトラフィック量を制御することを望むかもしれない、あるいは特定のプロバイダから入ります。
o Small ISP to transit ISP TE: operators may face tight resource constraints and wish to influence the volume of entering traffic from both customers and providers along specific routing paths to best utilize the limited resources.
トランジットISP TEに小ISP O：オペレータは、厳しい資源制約に直面し、最高の限られた資源を利用するために、特定のルーティング経路に沿って、顧客とプロバイダの両方からのトラフィックに入るのボリュームに影響を与えることを望むかもしれません。
o Large ISP TE: given the densely connected nature of the Internet topology, a given destination normally can be reached through different routing paths. An operator may wish to be able to adjust the traffic volume sent to each of its peers based on business relations with its neighbor ASs.
O大ISP TE：インターネットトポロジーの密接続性質が与えられると、与えられた宛先は、通常、異なるルーティング経路を介して到達することができます。オペレータは、その近隣のASとのビジネス関係に基づいて、そのピアのそれぞれに送信されるトラフィック量を調整できるようにしたいと思うかもしれません。
At this time, it remains an open issue whether a scalable TE solution would be necessarily inside the routing protocol, or can be accomplished through means that are external to the routing system.
このとき、スケーラブルTE溶液がルーティングプロトコルの内側に必ずしもであるかどうか未解決の問題のままで、またはルーティングシステムの外部にある手段によって達成することができます。
The workshop attendees concluded that one important reason for uncontrolled routing growth was the misalignment of incentives. New entries are added to the routing system to provide benefit to specific parties, while the cost is born by everyone in the global routing system. The consensus of the workshop was that any proposed solutions should strive to provide incentives to reward practices that reduce the overall system cost, and punish the "bad" behavior that imposes undue burden on the global system.
ワークショップの参加者は、制御されないルーティング成長の一つの重要な理由は、インセンティブのミスアライメントであると結論づけました。新しいエントリはコストがグローバルルーティングシステム内の誰もが生まれている間に、特定の当事者に利益を提供するために、ルーティングシステムに追加されます。ワークショップのコンセンサスはどんな提案されたソリューションは、システム全体のコストを削減実践に報いるためのインセンティブを提供するために努力していて、グローバルなシステム上に過度の負担を強いる「悪い」行動を処罰すべきであるということでした。
Given the global scale and distributed nature of the Internet, there can no longer (ever) be a flag day on the Internet. To bootstrap the deployment of new solutions, the solutions should provide incentives to first movers. That is, even when a single party starts to deploy the new solution, there should be measurable benefits to balance the costs.
地球規模およびインターネットの分散性を考えると、もはや（これまで）は、インターネット上の旗の日はあり得ません。新しいソリューションの展開をブートストラップするには、解決策は、最初の発動機へのインセンティブを提供する必要があります。これは、単一の当事者が新しいソリューションを展開するために開始した場合であっても、コストのバランスをとるために、測定可能なメリットがあるはずです。
Independent of what kind of solutions the IETF develops, if any, it is unlikely that the resulting routing system would stay constant in size. Instead, the workshop participants believed the routing system will continue to grow, and that ISPs will continue to go through system and hardware upgrade cycles. Many attendees expressed a desire that the scaling properties of the system can allow the hardware to keep up with the Internet growth at a rate that is comparable to the current costs, for example, allowing one to keep a 5-year hardware depreciation cycle, as opposed to a situation where scaling leads to accelerated cost increases.
IETFが開発ソリューションの種類とは無関係に、もしあれば、結果のルーティングシステムのサイズが一定にとどまることはほとんどありません。代わりに、ワークショップの参加者は、ルーティングシステムは成長を続け、およびISPがシステムおよびハードウェアのアップグレードサイクルを通過し続けることになると信じていました。多くの参加者は、前述したように、システムのスケーリング特性は、ハードウェアが5年間のハードウェアの減価償却サイクルを維持するために1をできるように、例えば、現在のコストに匹敵する速度でインターネットの成長に追いつくできるようにすることができます希望を表明しました加速、コストの増加につながるのスケーリング状況に反対しました。
Although there does not exist a specific hard deadline, the unanimous consensus among the workshop participants is that the solution development must start now. If one assumes that the solution specification can get ready within a 1 - 2 year time frame, that will be followed by another 2-year certification cycle. As a result, even in the best case scenario, we are facing a 3 - 5 year time frame in getting the solutions deployed.
特定のハード期限が存在しませんが、ワークショップ参加者の間で全会一致の合意は、ソリューションの開発は今開始しなければならないということです。 1は、ソリューションの仕様が1以内に準備ができていることを前提とした場合 - 2年の時間枠、それはまた別の2年間の認証サイクルが続きます。展開されたソリューションを得ることに5年の時間枠 - その結果、でも最良のシナリオでは、我々は3に直面しています。
The routing scalability problem is a shared one between IPv4 and IPv6, as IPv6 simply inherited IPv4's CIDR-style "Provider-based Addressing". The proposed solutions should, and are also expected to, solve the problem for both IPv4 and IPv6.
IPv6はIPv4の単にのCIDRスタイルの「プロバイダベースのアドレス指定」を継承したとして、ルーティングスケーラビリティの問題は、IPv4とIPv6の間で共有されるものです。提案された解決策は、また、IPv4とIPv6の両方の問題を解決することが期待されている必要があります。
Backwards compatibility with the existing IPv4 and IPv6 protocol stack is a necessity. Although a wide deployment of IPv6 is yet to happen, there has been substantial investment into IPv6 implementation and deployment by various parties. IPv6 is considered a legacy with shipped code. Thus, a highly desired feature of any proposed solution is to avoid imposing backwards-incompatible changes on end hosts (either IPv4 or IPv6).
後方既存のIPv4およびIPv6プロトコルスタックとの互換性が必要です。 IPv6の幅広い展開が起こることをまだですが、様々な関係者によるIPv6の実装と展開にかなりの投資がありました。 IPv6が出荷されたコードとレガシーと考えられています。したがって、任意の提案された解決策の非常に望ましい特徴は、エンドホスト上の互換性のない変更（IPv4またはIPv6のいずれか）を課すことを回避することです。
In the routing system itself, the solutions must allow incremental changes from the current operational Internet. The solutions should be backward compatible with the routing protocols in use today, including BGP, OSPF, IS-IS, and others, possibly with incremental enhancements.
ルーティングシステム自体では、解決策は、現在の動作インターネットからの増分変更を許可する必要があります。解決策は、おそらく、増分の機能強化で、BGP、OSPF、IS-IS、およびその他を含む、使用中のルーティング・プロトコル今日、との下位互換性がある必要があります。
The above backward-compatibility considerations should not constrain the exploration of the solution space. We need to first find right solutions, and look into their backward-compatibility issues after that. This way enables us to gain a full understanding of the tradeoffs, and what potential gains, if any, that we may achieve by relaxing the backward-compatibility concerns.
上記の下位互換性の考慮事項は、解空間の探索を制約するべきではありません。私たちは、最初に適切なソリューションを見つけ、その後その下位互換性の問題を検討する必要があります。この方法では、もしあれば、我々は下位互換性の問題を緩和することにより達成することができるという、トレードオフ、そしてどのような潜在的な利益の完全な理解を得るために私たちを可能にします。
As a rule of thumb for successful deployment, for any new design, its chance of success is higher if it makes fewer changes to the existing system.
それは、既存のシステムに少数の変更を行った場合の成功の展開のための経験則として、任意の新しいデザインのために、成功のその可能性が高いです。
Security should be considered from day one of solution development. If nothing else, the solutions must not make securing the routing system any worse than the situation today. It is highly desirable to have a solution that makes it more difficult to inject false routing information, and makes it easier to filter out DoS traffic.
セキュリティは、ソリューション開発の初日から考慮されるべきです。何もない場合は、ソリューションは、今日の状況よりも任意の悪化したルーティングシステムを確保してはなりません。より困難偽のルーティング情報を注入することができます解決策を持っていることが非常に望ましい、そしてそれが簡単にDoSトラフィックをフィルタリングすることができます。
However, securing the routing system is not considered a requirement for the solution development. Security is important; having a working system in the first place is even more important.
しかしながら、ルーティングシステムを確保するソリューション開発のための要件とは見なされません。セキュリティが重要です。最初の場所での作業システムを持つことはさらに重要です。
A number of other criteria were also raised that fall into various different categories. They are summarized below.
他の基準の数はまた、様々な異なるカテゴリに分類されること提起されました。彼らは、以下に要約されています。
o Site renumbering forced by the routing system should be avoided.
Oルーティングシステムによって強制的にリナンバリングサイトは避けるべきです。
o Site reconfiguration driven by the routing system should be minimized.
Oルーティングシステムによって駆動されるサイトの再構成が最小限にすべきです。
o The solutions should not force ISPs to reveal internal topology.
Oソリューションは、内部トポロジーを明らかにするのISPを強制するべきではありません。
o Routing convergence delay must be under control.
Oルーティング収束遅延は、制御下でなければなりません。
o End-to-end data delivery paths should be stable enough for good Voice over IP (VoIP) performance.
Oエンドツーエンドのデータ配信パスが良いボイスオーバーIP（VoIP）のパフォーマンスのために十分に安定でなければなりません。
As the old saying goes, every coin has two sides. If we let the routing table continue to grow at its present rate, rapid hardware and software upgrade and replacement cycles for deployed core routing equipment may become cost prohibitive. In the worst case, the routing table growth may exceed our ability to engineer the global routing system in a cost-effective way. On the other hand, solutions for stopping or substantially slowing down the growth in the Internet routing table will necessarily bring their own costs, perhaps showing up elsewhere and in different forms. Examples of such tradeoffs are presented in Section 6, where we examined the gains and costs of a few different approaches to scalable multihoming support (SHIM6, GSE, and a general tunneling approach). A major task in the solution development is to understand who may have to give up what, and whether that makes a worthy tradeoff.
古い格言が進むにつれ、全てのコインは2つの側面があります。私たちは、ルーティングテーブルが展開コアルーティング機器のためにその存在率、迅速なハードウェアとソフトウェアのアップグレードと交換サイクルで成長を継続させる場合のコストは法外になることがあります。最悪の場合には、ルーティングテーブルの成長は、費用対効果の高い方法でグローバルルーティングシステムを設計する当社の能力を超えることがあります。一方、停止または実質的にインターネットルーティングテーブルの成長を減速のためのソリューションは、必ずしも、おそらく他の場所と異なる形で現れて、自分のコストをもたらすでしょう。そのようなトレードオフの例には、我々は、スケーラブルなマルチホーミングのサポート（SHIM6、GSE、および一般的なトンネリングアプローチ）にはいくつかの異なるアプローチの利益とコストを調べた第6節で提示されています。ソリューション開発における主要な課題は何を放棄する必要があります誰が理解することです、それは立派なトレードオフになりますか。
Before ending this discussion on the solution criteria, it is worth mentioning the shortest presentation at the workshop, which was made by Tony Li (the presentation slides can be found from Appendix D). He asked a fundamental question: what is at stake? It is the Internet itself. If the routing system does not scale with the continued growth of the Internet, eventually the costs might spiral out of control, the digital divide widen, and the Internet growth slow down, stop, or retreat. Compared to this problem, he considered that none of the criteria mentioned so far (except solving the problem) was important enough to block the development and deployment of an effective solution.
ソリューション基準にこの議論を終了する前に、トニー・リー（プレゼンテーションのスライドは、付録Dから見つけることができる）で行われた、ワークショップでの最短のプレゼンテーションを言及する価値があります。彼は基本的な質問を：危機に瀕して何ですか？これは、インターネットそのものです。ルーティングシステムは、インターネットの継続的な成長に合わせて拡張しない場合は、最終的にはコストが制御不能にスパイラルかもしれませんが、デジタルデバイドを広げると、インターネットの成長は、遅く停止、または後退。この問題に比べて、彼は（問題の解決を除いて）これまでに述べた基準のいずれにも効果的なソリューションの開発と展開を阻止するために十分に重要ではなかったことを考えました。
The workshop attendees would like to make the following recommendations:
ワークショップの参加者は、以下の提言をしたいと思います。
First of all, the workshop participants would like to reiterate the importance of solving the routing scalability problem. They noted that the concern over the scalability and flexibility of the routing and addressing system has been with us for a very long time, and the current growth rate of the DFZ RIB is exceeding our ability to engineer the routing infrastructure in an economically feasible way. We need to start developing a long-term solution that can last for the foreseeable future.
まず、ワークショップの参加者は、ルーティングのスケーラビリティの問題を解決することの重要性をあらためて表明したいと思います。彼らは、拡張性とルーティングの柔軟性およびアドレッシングシステムに対する懸念は非常に長い時間のための私達とされていることに注目し、DFZ RIBの現在の成長率は、経済的に実現可能な方法でルーティングインフラストラクチャを設計する当社の能力を超えています。私たちは、予見可能な将来のために続くことができる長期的なソリューションの開発を開始する必要があります。
Second, because the participants of this workshop consisted of mostly large service providers and major router vendors, the workshop participants recommend that IAB/IESG organize additional workshops or use other venues of communication to reach out to other stakeholders, such as content providers, retail providers, and enterprise operators, both to communicate to them the outcome of this workshop, and to solicit the routing/addressing problems they are facing today, and their requirements on the solution development.
このワークショップの参加者は、主に大規模なサービスプロバイダや主要なルータベンダから成っているので第二に、ワークショップの参加者は、リテールプロバイダー、IAB / IESGは、追加のワークショップを整理したり、そのようなコンテンツプロバイダなどの他の利害関係者に手を差し伸べるために通信の他の会場を使用することをお勧めします、およびエンタープライズ事業者、彼らにこのワークショップの成果を伝えるために、ルーティング/アドレッシング彼らが今日直面している問題、およびソリューション開発にその要件を勧誘するために、両方の。
Third, the workshop participants recommend conducting the solution development in an open, transparent way, with broad-ranging participation from the larger networking community. A majority of the participants indicated their willingness to commit resources toward developing a solution. We must also invite the participation from the research community in this process. The locator-identifier split represents a fundamental architectural issue, and the IAB should lead the investigation into understanding of both how to make this architectural change and the overall impact of the change.
第三に、ワークショップの参加者は、より大きなネットワークコミュニティからの幅広い参加を得て、オープン、透明な方法でソリューション開発を行ってお勧めします。参加者の大半は、ソリューションの開発に向けたリソースをコミットする意向を示しました。また、このプロセスの研究コミュニティからの参加を招待する必要があります。ロケータ識別子の分割は基本的なアーキテクチャの問題を表しており、IABは、このアーキテクチャの変更と変化の全体的な影響を作成する方法の両方の理解に調査を導くべきです。
Fourth, given the goal of developing a long-term solution, and the fact that development and deployment cycles will necessarily take some time, it may be helpful (or even necessary) to buy some time through engineering feasible short- or intermediate-term solutions (e.g., FIB compression).
第四に、長期的な解決策を開発するという目標、および開発と展開サイクルは、必ずしもいくつかの時間がかかるだろうという事実を考えると、エンジニアリング実現可能な短期または中期ソリューションを通じていくつかの時間を買うために役立つ（あるいは必要）であってもよいです（例えば、FIB圧縮）。
Fifth, the workshop participants believe the next step is to develop a roadmap from here to the solution deployment. The IAB and IESG are expected to take on the leadership role in this roadmap development, and to leverage on the momentum from this successful workshop to move forward quickly. The roadmap should provide clearly defined short-, medium-, and long-term objectives to guide the solution development process, so that the community as a whole can proceed in an orchestrated way, seeing exactly where we are going when engineering necessary short-term fixes.
第五に、ワークショップの参加者は、次のステップは、ここからソリューション展開へのロードマップを開発することであると信じています。 IABとIESGは、このロードマップの開発で指導的役割を担うために、かつ迅速に前進するために、この成功したワークショップから勢いに活用することが期待されます。ロードマップは、必要に応じて、短期のエンジニアリングときに我々が行っている場所を正確に見て、全体としてコミュニティが画策方法で進めることができるように、ソリューションの開発プロセスを導くために明確に定義された短期、中期、長期の目標を提供する必要があります修正。
Finally, the workshop participants also made a number of suggestions that the IETF might consider when examining the solution space. These suggestions are captured in Appendix A.
最後に、ワークショップの参加者はまた、解空間を調べるときIETFが考えるかもしれない提案の数を作りました。これらの提案は、付録Aに捕獲されています
While the security of the routing system is of great concern, this document introduces no new protocol or protocol usage and as such presents no new security issues.
ルーティングシステムのセキュリティが大きな懸念のですが、この文書には、新たなセキュリティ問題を全く新しいプロトコルやプロトコルの使用法を紹介していないと、このようなプレゼントなど。
Jari Arkko, Vince Fuller, Darrel Lewis, Tony Li, Eric Rescorla, and Ted Seely made many insightful comments on earlier versions of this document. Finally, many thanks to Wouter Wijngaards for the fine notes he took during the workshop.
ヤリArkko、ビンス・フラー、ダレル・ルイス、トニー・リー、エリックレスコラ、およびテッドシーリーはこのドキュメントの以前のバージョンに多くの洞察に満ちたコメントが寄せられています。最後に、彼はワークショップ中に取った細かい注意についてはWouter Wijngaardsに感謝します。
[RFC1955] Hinden, R., "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.
"IPNGのためのインターネットルーティングのための新しいスキームとアドレッシング（ENCAPS）" [RFC1955] HindenとR.、RFC 1955、1996年6月。
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
[RFC2547]ローゼン、E.およびY. Rekhter、 "BGP / MPLS VPNの"、RFC 2547、1999年3月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[RFC4098] Berkowitz, H., Davies, E., Hares, S., Krishnaswamy, P., and M. Lepp, "Terminology for Benchmarking BGP Device Convergence in the Control Plane", RFC 4098, June 2005.
[RFC4098]バーコウィッツ、H.、デイビス、E.、野兎、S.、Krishnaswamy、P.、およびM. Lepp、 "コントロールプレーンにおけるベンチマークBGPデバイスConvergenceの用語"、RFC 4098、2005年6月。
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V. Gill, "IPv4 Multihoming Practices and Limitations", RFC 4116, July 2005.
[RFC4116] Abley、J.、Lindqvist、K.、デイビス、E.、ブラック、B.、およびV.ギル、 "IPv4のマルチホーミングプラクティスと制限"、RFC 4116、2005年7月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]ベイカー、F.、リア、E.、およびR. Droms、 "国旗の日なしでIPv6ネットワークを再番号付けのための手順"、RFC 4192、2005年9月。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[RFC4632]フラー、V.およびT.李、 "クラスレスドメイン間ルーティング（CIDR）：インターネットアドレスの割り当てと集計プラン"、BCP 122、RFC 4632、2006年8月。
[IDR-REQS] Doria, A. and E. Davies, "Analysis of IDR requirements and History", Work in Progress, February 2007.
[IDR-REQS]ドリア、A.とE.デイヴィス、 "IDRの要件と歴史の分析"、進歩、2007年2月での作業。
[ARIN] "American Registry for Internet Numbers", http://www.arin.net/index.shtml.
[ARIN] "インターネット番号のためのアメリカのレジストリ"、http://www.arin.net/index.shtml。
[PIPA] Karrenberg, D., "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", RIPE-387 http://www.ripe.net/docs/ipv4-policies.html, 2006.
[PIPA] Karrenberg、D.、 "RIPE NCCサービス地域のIPv4アドレス割り振りおよび割り当てポリシー"、http://www.ripe.net/docs/ipv4-policies.html、2006から387 RIPE。
[SHIM6] "Site Multihoming by IPv6 Intermediation (shim6)", http://www.ietf.org/html.charters/shim6-charter.html.
、http://www.ietf.org/html.charters/shim6-charter.html [SHIM6 "IPv6の仲介（SHIM6）によってサイトマルチホーミング"。
[EID] Chiappa, J., "Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture", http://www.chiappa.net/~jnc/tech/endpoints.txt, 1999.
[EID] Chiappa、J.、 "エンドポイントとエンドポイント名：インターネットアーキテクチャの提案の強化"、http://www.chiappa.net/~jnc/tech/endpoints.txt、1999。
[GSE] O'Dell, M., "GSE - An Alternate Addressing Architecture for IPv6", Work in Progress, 1997.
[GSE]オデル、M.、 "GSE - IPv6のアーキテクチャを代替アドレス"、進歩、1997年ワーク。
[dGSE] Zhang, L., "An Overview of Multihoming and Open Issues in GSE", IETF Journal, http://www.isoc.org/tools/blogs/ ietfjournal/?p=98#more-98, 2006.
[dGSE]チャン、L.、 "GSEでマルチホーミングと残された問題の概要"、IETFジャーナル、http://www.isoc.org/tools/blogs/ ietfjournal /？p = 98件以上-98、2006。
[PathExp] Oliveira, R. and et. al., "Quantifying Path Exploration in the Internet", Internet Measurement Conference (IMC) 2006, http://www.cs.ucla.edu/~rveloso/papers/ imc175f-oliveira.pdf.
【PathExp]オリベイラ、R.およびEt。アル。、 "インターネットにおける定量化パスの探査"、インターネット測定コンファレンス（IMC）2006、http://www.cs.ucla.edu/~rveloso/papers/ imc175f-oliveira.pdf。
[DynPrefix] Oliveira, R. and et. al., "Measurement of Highly Active Prefixes in BGP", IEEE GLOBECOM 2005 http://www.cs.ucla.edu/~rveloso/papers/activity.pdf.
【DynPrefix]オリベイラ、R.およびEt。ら、 "BGPで高活性プレフィックスの測定"、IEEEのGLOBECOM 2005 http://www.cs.ucla.edu/~rveloso/papers/activity.pdf。
[BHB06] Boothe, P., Hielbert, J., and R. Bush, "Short-Lived Prefix Hijacking on the Internet", NANOG 36 http://www.nanog.org/mtg-0602/pdf/boothe.pdf, 2006.
【BHB06】ブース、P.、Hielbert、J.、およびR.ブッシュ、 "インターネット上の短命プレフィックスハイジャック"、NANOG 36 http://www.nanog.org/mtg-0602/pdf/boothe.pdf 2006年。
[ROFL] Caesar, M. and et. al., "ROFL: Routing on Flat Labels", SIGCOMM 2006, http://www.sigcomm.org/sigcomm2006/ discussion/showpaper.php?paper_id=34, 2006.
【ROFL]シーザー、M.およびEt。ら、 "ROFL：フラットラベルにルーティング"。SIGCOMM 2006、http://www.sigcomm.org/sigcomm2006/議論/ showpaper.php paper_id = 34、2006？。
[CNIR] Abraham, I. and et. al., "Compact Name-Independent Routing with Minimum Stretch", ACM Symposium on Parallel Algorithms and Architectures, http://citeseer.ist.psu.edu/710757.html, 2004.
【CNIR]アブラハム、I.およびEt。ら、「最小ストレッチコンパクト名前に依存しないルーティング」、ACMシンポジウム並列アルゴリズムとアーキテクチャ、http://citeseer.ist.psu.edu/710757.html、2004年。
[BGT04] Bu, T., Gao, L., and D. Towsley, "On Characterizing BGP Routing Table Growth", J. Computer and Telecomm Networking V45N1, 2004.
【BGT04]のBu、T.、ガオ、L.、及びD. Towsley、 "BGPルーティングテーブルの成長を特徴付ける上"、J.コンピュータとテレコムネットワークV45N1 2004。
[Fuller] Fuller, V., "Scaling issues with ipv6 routing+ multihoming", http://www.iab.org/about/workshops/ routingandaddressing/vaf-iab-raws.pdf, 2006.
[フラー]フラー、V.、 "IPv6のルーティング+マルチホーミングとスケーリングの問題"、http://www.iab.org/about/workshops/ routingandaddressing / VAF-IAB-raws.pdf、2006。
[H03] Huston, G., "Analyzing the Internet's BGP Routing Table", http://www.potaroo.net/papers/ipj/ 2001-v4-n1-bgp/bgp.pdf, 2003.
[H03]ヒューストン、G.、 "インターネットのBGPルーティングテーブルの分析"、http://www.potaroo.net/papers/ipj/ 2001-V4-N1-BGP / bgp.pdf、2003。
[BGP2005] Huston, G., "2005 -- A BGP Year in Review", http:// www.apnic.net/meetings/21/docs/sigs/routing/ routing-pres-huston-routing-update.pdf.
[BGP2005]ヒューストン、G.、 "2005 - ReviewのBGP年" は、http：// www.apnic.net/meetings/21/docs/sigs/routing/ルーティング-PRES - ヒューストン - ルーティングupdate.pdf 。
[DFZ] Huston, G., "Growth of the BGP Table - 1994 to Present", http://bgp.potaroo.net, 2006.
[DFZ]ヒューストン、G.、 "BGPテーブルの成長 - 現在までの1994"、http://bgp.potaroo.net、2006。
[GIH] Huston, G., "Wither Routing?", http://www.potaroo.net/ispcol/2006-11/raw.html, 2006.
[GIH]ヒューストン、G.、 "ウィザールーティング？"、http://www.potaroo.net/ispcol/2006-11/raw.html、2006。
[ATNAC2006] Huston, G. and G. Armitage, "Projecting Future IPv4 Router Requirements from Trends in Dynamic BGP Behaviour", http://www.potaroo.net/papers/phd/ atnac-2006/bgp-atnac2006.pdf, 2006.
[ATNAC2006]ヒューストン、G.とG.アーミテージ、 "ダイナミックBGP行動の動向から今後のIPv4ルーターの要件を投写する"、http://www.potaroo.net/papers/phd/ atnac-2006 / BGP-atnac2006.pdf、 2006。
[CIDRRPT] "The CIDR Report", http://www.cidr-report.org.
[CIDRRPT] "CIDRレポート"、http://www.cidr-report.org。
[ML] "Moore's Law", Wikipedia http://en.wikipedia.org/wiki/Moore's_law, 2006.
[ML] "ムーアの法則"、ウィキペディアhttp://en.wikipedia.org/wiki/Moore's_law、2006。
[Molinero] Molinero-Fernandez, P., "Technology trends in routers and switches", PhD thesis, Stanford University http:// klamath.stanford.edu/~molinero/thesis/html/ pmf_thesis_node5.html, 2005.
[Molineroに] Molineroに-フェルナンデス、P.、 "ルータやスイッチにおける技術動向"、博士論文、スタンフォード大学はhttp：// klamath.stanford.edu/~molinero/thesis/html/ pmf_thesis_node5.html、2005。
[DRAM] Landler, P., "DRAM Productivity and Capacity/Demand Model", Global Economic Workshop http:// www.sematech.org/meetings/archives/GES/19990514/docs/ 07_econ.pdf, 1999.
[DRAM]レントラー、P.、 "DRAM生産性とキャパシティ/需要モデル"、世界経済ワークショップはhttp：// www.sematech.org/meetings/archives/GES/19990514/docs/ 07_econ.pdf、1999。
Appendix A. Suggestions for Specific Steps
具体的な手順については、付録A.提案
At the end of the workshop there was a lively round-table discussion regarding specific steps that IETF may consider undertaking towards a quick solution development, as well as potential issues to avoid. Those steps included:
ワークショップの終わりに回避するために、IETFは、迅速なソリューション開発に向けて取り組みを考慮することができる具体的な手順だけでなく、潜在的な問題について活発なラウンドテーブルディスカッションがありました。これらのステップが含まれます：
o Finding a home (mailing list) to continue the discussion started from the workshop with wider participation. [Editor's note: Done -- This action has been completed. The list is ram@iab.org.]
議論を継続するホーム（メーリングリスト）を見つけるoをより広く参加してのワークショップから始まりました。 [編集者注：完了 - このアクションは完了しました。リストはram@iab.orgあります。]
o Considering a special process to expedite solution development, avoiding the lengthy protocol standardization cycles. For example, IESG may charter special design teams for the solution investigation.
O長いプロトコルの標準化のサイクルを避け、ソリューション開発を促進するための特別なプロセスを考えます。たとえば、ソリューションの調査のためのIESGの5月のチャーター特別な設計チーム。
o If a working group is to be formed, care must be taken to ensure that the scope of the charter is narrow and specific enough to allow quick progress, and that the WG chair be forceful enough to keep the WG activity focused. There was also a discussion on which area this new WG should belong to; both routing area ADs and Internet area ADs are willing to host it.
ワーキンググループが形成される場合には、O、ケアは、憲章の範囲は、迅速な進行を可能にする狭いと十分に固有であり、WGの議長は、WGの活動が集中維持するのに十分強力であることを保証するために注意しなければなりません。この新しいWGが所属すべき領域上の議論もありました。両方のルーティングエリアの広告とインターネット面積広告はそれをホストするために喜んでいます。
o It is desirable that the solutions be developed in an open environment and free from any Intellectual Property Right claims.
Oソリューションは、オープンな環境で開発し、任意の知的財産権の主張から自由にすることが望ましいです。
Finally, given the perceived severity of the problem at hand, the workshop participants trust that IAB/IESG/IETF will take prompt actions. However, if that were not to happen, operators and vendors would be most likely to act on their own and get a solution deployed.
最後に、当面の問題の認知重大度与えられ、ワークショップの参加者は、IAB / IESG / IETFプロンプト行動を取ることを信頼しています。それが起こることをされていない場合は、事業者やベンダーが独自に行動し、配備されたソリューションを取得する可能性が最も高いだろう。
Appendix B. Workshop Participants
付録B.ワークショップ参加者
Loa Anderson (IAB) Jari Arkko (IESG) Ron Bonica Ross Callon (IESG) Brian Carpenter (IAB) David Conrad (IANA) Leslie Daigle (IAB Chair) Elwyn Davies (IAB) Terry Davis Weisi Dong Aaron Falk (IRTF Chair) Kevin Fall (IAB) Dino Farinacci Vince Fuller Vijay Gill
ロア・アンダーソン（IAB）ヤリArkko（IESG）ロン・BonicaロスCallon（IESG）ブライアン・カーペンター（IAB）デヴィッド・コンラッド（IANA）レスリーDaigle氏（IAB議長）エルウィン・デイヴィス（IAB）テリー・デービスWeisiドンアーロンフォーク（IRTF議長）ケビン・秋（IAB）ディノファリナッチビンスフラービジェイギル
Russ Housley (IESG) Geoff Huston Daniel Karrenberg Dorian Kim Olaf Kolkman (IAB) Darrel Lewis Tony Li Kurtis Lindqvist (IAB) Peter Lothberg David Meyer (IAB) Christopher Morrow Dave Oran (IAB) Phil Roberts (IAB Executive Director) Jason Schiller Peter Schoenmaker Ted Seely Mark Townsley (IESG) Iljitsch van Beijnum Ruediger Volk Magnus Westerlund (IESG) Lixia Zhang (IAB)
ラスHousley（IESG）ジェフ・ヒューストンダニエルKarrenbergドリアンキム・オラフKolkman（IAB）ダレル・ルイストニー・リーカーティスLindqvist（IAB）ピーター・ロスバーグデビッド・マイヤー（IAB）クリストファー・モローデイヴ・オラン（IAB）フィル・ロバーツ（IABエグゼクティブ・ディレクター）ジェイソン・シラーピーターSchoenmakerテッド・シーリーマークTownsley（IESG）IljitschバンBeijnum Ruedigerボルクマグヌスウェスター（IESG）Lixiaチャン（IAB）
Appendix C. Workshop Agenda
付録C.ワークショップアジェンダ
IAB Routing and Addressing Workshop Agenda October 18-19 Amsterdam, Netherlands
IABルーティングとアドレッシングワークショップアジェンダ10月18-19アムステルダム、オランダ
DAY 1: the proposed goal is to collect, as complete as possible, a set of scalability problems in the routing and addressing area facing the Internet today.
DAY 1：提案の目標は、できるだけ完全として、スケーラビリティのルーティングに問題と今日のインターネットが直面しているアドレッシング領域のセットを収集することです。
0815-0900: Welcome, framing up for the 2 days Moderator: Leslie Daigle
0815-0900：ようこそ、2日間司会用にフレーミング：レスリーDaigle氏
0900-1200: Morning session Moderator: Elwyn Davies Strawman topics for the morning session: - Scalability - Multihoming support - Traffic Engineering - Routing Table Size: Rate of growth, Dynamics (this is not limited to DFZ, include iBGP) - Causes of the growth - Pains from the growth (perhaps "Impact on routers" can come here?) - How big a problem is BGP slow convergence?
0900-1200：朝のセッションのモデレーター：エルウィン・デイヴィスStrawmanの朝のセッションのトピック： - スケーラビリティ - マルチホーミングサポート - トラフィックエンジニアリング - ルーティングテーブルのサイズ：成長、ダイナミクスのレート（これはiBGPのを含め、DFZに限定されない） - の原因成長 - 成長の痛み（おそらく、「ルータへの影響は、」ここに来ることができますか？） - どのように大きな問題は、BGP遅い収束ですか？
1015-1030: Coffee Break
1015-1030：コーヒーブレイク
1200-1300: Lunch
1200-1300：ランチ
1330-1730: Afternoon session: What are the top 3 routing problems in your network? Moderator: Kurt Erik Lindqvist
1330-1730：午後のセッション：ネットワーク内の上位3ルーティングの問題は何ですか？司会：クルト・エリックLindqvist
1500-1530: Coffee Break
1500-1530：コーヒーブレイク
Dinner at Indrapura (http://www.indrapura.nl), sponsored by Cisco
シスコが主催Indrapuraディナー（http://www.indrapura.nl）、
---------
DAY 2: The proposed goal is to formulate a problem statement
0800-0830: Welcome
0800-0830：ようこそ
0830-1000: Morning session: What's on the table Moderator: Elwyn Davies - shim6 - GSE
0830-1000：午前のセッション：テーブルの司会に何：エルウィン・デイヴィス - SHIM6 - GSE
1000-1030: Coffee Break
1000-1030：コーヒーブレイク
1030-1200: Problem Statement session #1: document the problems Moderator: David Meyer
1030-1200：問題文のセッション＃1：文書化の問題司会：デヴィッド・マイヤーを
1200-1300: Lunch
1200-1300：ランチ
1300-1500: Problem Statement session # 2, cont; Moderator: Dino Farinacci - Constraints on solutions
1300-1500：問題文のセッション＃2、続き。司会：ディノファリナッチ - ソリューションに関する制約
1500-1530: Coffee Break
1500-1530：コーヒーブレイク
1530-1730: Summary and Wrap-up Moderator: Leslie Daigle
1530-1730：概要とラップアップモデレーター：レスリーDaigle氏
Appendix D. Presentations
付録D.プレゼンテーション
The presentations from the workshop can be found on
ワークショップからのプレゼンテーションがで見つけることができます
http://www.iab.org/about/workshops/routingandaddressing
ｈっｔｐ：／／ｗっｗ。いあｂ。おｒｇ／あぼうｔ／をｒｋしょｐｓ／ろうちんがんだっｄれっしんｇ
Authors' Addresses
著者のアドレス
David Meyer (editor)
デヴィッド・メイヤー（EDITORE）
EMail: dmm@1-4-5.net
メールアドレス：dmm@1-4-5.net
Lixia Zhang (editor)
張（編集者）の下で、L I
EMail: lixia@cs.ucla.edu
メールアドレス：lixia@cs.ucla.edu
Kevin Fall (editor)
ケビン・秋（編集者）
EMail: kfall@intel.com
メールアドレス：kfall@intel.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。