[要約] RFC 4984は、IABワークショップでのルーティングとアドレッシングに関する報告書です。その目的は、インターネットのルーティングとアドレッシングの課題を議論し、改善策を提案することです。
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
ルーティングとアドレス指定に関するIABワークショップからのレポート
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.
この文書は、2006年10月18〜19日にオランダのアムステルダムでインターネットアーキテクチャ委員会（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は2006年10月18〜19日にオランダのアムステルダムで「ルーティングとアドレス指定のワークショップ」を開催しました。ワークショップの主な目的は、既存の要因と主要な要因を特定することでした。ルーティングのスケーラビリティへの影響、および一連のフォローオンアクティビティへの入力として機能する簡潔な問題ステートメントを開発する。このドキュメントは、そのワークショップの結果について報告しています。
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.
ワークショップの参加者リストは付録Bに添付されています。アジェンダは付録Cに記載されており、付録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.
このセクションでは、ワークショップからの重要な調査結果の簡潔な要約を示します。ルーティングおよびアドレス指定システムの他の多くの側面が議論されましたが、このセクションで説明した最初の2つの問題は、ワークショップの参加者によって最も重要な問題と見なされました。
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ルーティングテーブルのサイズ（ルーティング情報ベースまたはリブと呼ばれることが多い）とその意味に最も関連しています。これらの意味合いには、DFZリブと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リブへの凝集不可能なプレフィックスの注入につながる可能性があります。接頭辞脱アグレジョンは、一部の非地区に基づいたルーティングテクノロジー（たとえば、フラットラベル[ROF]または名前に依存しないコンパクトルーティングアルゴリズムなど）でのルーティング、[CNIR]など）の一部がないため、制御されないDFZリブの成長につながります。DFZリブの成長を制御する唯一の既知の実用的なアプローチです。次のセクションでは、DFZリブの成長の意味についてのワークショップの議論をレビューします。
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リブが数年間線形速度よりも大きく成長していることを示しました[DFZ]。これにはRIBおよびFIBメモリサイズの要件に明らかな影響がありますが、プレフィックスの脱凝集によって駆動される成長は、ネットワークのコアをエッジの動的な性質にさらします。つまり、凝集は数の増加につながりますDFZに注入されたBGP更新メッセージの（「更新チャーン」と呼ばれることが多い）。したがって、より長いプレフィックスの状態を維持し、FIBを更新するには、追加の処理が必要です。rib骨のサイズは、指定されたアドレス空間サイズと到達可能なホストの数（つまり、o（m*2^32）の数に囲まれていますが、<m>は各BGPルーターの平均ピア数です。）、動的なトポロジーの変化を分配するために必要なプロトコル活動の量はそうではありません。つまり、ネットワークが体験できるBGPアップデートチャーンの量は、本質的に無制限です。また、現在測定されているように、アップデートチャーンは頑丈であることも注目されました[ATNAC2006]。つまり、比較的少数の自律システム（ASS）または接頭辞は、今日観察している更新チャーンの不均衡に大きな割合に責任があります。さらに、チャーンの多くは、おそらくグローバルなルーティングシステムにエッジアスが注入されているため[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.
最後に、ワークショップの参加者は、最新の地域インターネットレジストリ（RIR）ポリシーがプロバイダーに独立している（PI）アドレスを割り当てられている現在の地域インターネットレジストリ（RIR）ポリシーによって悪化する可能性があることがわかりました。これらのアドレスはトポロジカルに集約可能ではないため、上記のチャーンの問題をコアルーティングシステムに持ち込みます。もちろん、数人の参加者が指摘したように、多くの企業はプロバイダーに割り当てられた（PA）[PIPA]アドレス空間が作成する「プロバイダーロック」なしでマルチホームにできるPIアドレスを要求するため、この問題についてはRIRSは実際の選択をしていません。また、一部の企業は、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.
ワークショップの驚くべき結果の1つは、「ムーアの法則」[ML]と費用対効果の高い高性能ルーターを構築する能力との関係について、トニーリーが行った観察でした（付録Dを参照）。「ムーアの法則」とは、最小コンポーネントコストに関して、統合回路のトランジスタ密度が約24か月ごとに2倍になるという経験的観察です。一般的に保持されている知恵は、ムーアの法律が、コアルーターハードウェアが処理するルーティング情報の成長率を上回る歴史的な速度でテクノロジーが拡大し続けることを保証することにより、日を節約するということです。しかし、Liは、ムーアの法律は、コストに関する限り、ハイエンドルーターの構築には適用されないと指摘しました。
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:
ルーティングシステムのスケーラビリティの根底にある基本的な仮定の1つは、Yakov Rekhterによって雄弁に述べられていました（そして、「Rekhter's Law」と呼ばれることもあります）。
"Addressing can follow topology or topology can follow addressing. Choose one."
「アドレス指定は、トポロジーに従うことができます。または、トポロジーはアドレス指定に従うことができます。1つを選択してください。」
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]).
同じアイデアは、Mike O'DellのIPv6 [GSE]の代替アドレスアーキテクチャの設計によって表現されました。ここで、アドレス構造は、ルーティングシステムを拡大する「積極的なトポロジー集計」を可能にするために特別に設計されました。Noel 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 event, this kind of overloading is felt to have had deep implications for the scalability of the global routing system.
ただし、今日のインターネットでRekhterの法律で想定される一致を作成（および維持する）の困難があります。難易度は、「WHO」（輸送層で使用されるエンドポイント識別子）と「WHERE」（ルーティングシステムのロケーター）の両方のセマンティクスを使用してアドレス指定の過負荷から生じます。また、IPアドレスに「How」[GIH]が過負荷になっていることも付け加えます。いずれにせよ、この種の過負荷は、グローバルルーティングシステムのスケーラビリティに深い意味を持っていると感じられています。
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アドレスセマンティクスのいわゆる「ロケーター/識別子過負荷」は、今日見られるルーティングスケーラビリティの問題の原因の1つであると結論付けました。したがって、ルーティングシステムをスケーリングするには「分割」が必要と思われますが、実際にこのような分割をアーキテクトと実装する方法は詳細に調査されていません。
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つの迫りつつあるが「2番目の層」の問題を特定しました。
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.
最初のものは、IPv6の展開に関する一般的な懸念です。一般に、IPv4アドレス空間がIPv4 RIBの成長に効果的な制約があると考えられています。この制約がIPv6の展開により解除され、スケーラブルなルーティング戦略がない場合、今日の迅速なDFZリブサイズの成長問題は、IPv6のはるかに大きなアドレススペースによって悪化する可能性があります。IPv6で今日利用可能な唯一のルーティングパラダイムは、クラスレスドメイン間ルーティング（CIDR）[RFC4632）とプロバイダーに非依存性（PI）アドレス割り当て戦略[PIPA]（およびおそらくSHIM6 [SHIM6]が開発および展開された場合の組み合わせです。）。したがって、IPv4に直面したものよりもはるかに大きくなる可能性のある「沼地」（凝集不可能なアドレス空間）を作成する機会が存在します。要するに、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.
2番目の問題は、ルーティングの収束が遅いことです。特に、懸念は、サービスプロバイダーが持ち運ばなければならないルートの数の増加がルーティングの収束を重大な問題にすることでした。
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.
3番目の問題は、今日のルーティングシステムにおけるコストとメリットの不整合です。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リブの急速な成長でした。2005年のエントリの数は、約150,000のエントリから175,000のエントリ[BGP2005]の範囲でした。この数は2006年10月の時点で200,000に達し[Cidrrpt]、5年以内に370,000以上に増加すると予測されています[Fuller]。一部のワークショップの参加者は、DFZが15年以内に200万のエントリに到達できると予測し、2050年までに1,000万件のマルチホームサイトがある可能性があります。
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ルーターは、1日で最大500,000のBGPアップデートを観察する場合があり、ピーク到着率は1秒あたり1000の更新を超えています。このような更新チャーンの問題は、DFZルートに限定されません。実際、このような内部ルートにはより多くの詳細、仮想プライベートネットワーク（VPN）ルート、およびDFZに表示されない他のルート[ATNAC2006]が含まれることを考えると、大きなISPが運ぶ内部ルートの数も収束時間を脅かします。
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.
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
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を選択する際に追加の敏ility性が得られ、名前を変更する必要性を回避できます。多くのエンドシステムは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).
Multihomingは、サイトが複数のISP [RFC4116]が提供する場合を一般的に指します[RFC4116]。ミッションおよびビジネス上のアプリケーションのインターネットへの依存の増加や、インターネット接続を得るためのコストの一般的な減少など、マルチホームの観察された増加にはいくつかの理由があります。Multihomingはバックアップルーティングを提供します - インターネット接続の冗長性。状況によっては、契約または法律のためにマルチホームが必須です。Multihomingは、PIまたはPAアドレススペースのいずれかを使用して達成でき、マルチホームサイトには一般的に数字があります（一部はそうではありませんが、これは一般に、そのような顧客が静的にルーティングされている場合に発生します）。
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によって宣伝されている場合に発生します。この場合、最も一致するプレフィックス転送ルールが最も長いため、顧客のトラフィックは非プライマリーを介して指示されます。これに応じて、プライマリISPは、顧客のトラフィックを非プライマリーの代わりに（s）の代わりに流れるようにするために、顧客の接頭辞を解除することを余儀なくされます。
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は、3つの主な理由で、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を必要とします。ただし、TE展開の現在の慣行により、DFZリブが増加します。個々のオペレーターは、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への完全な即時移行は、リブとFIBサイズが約4倍に増加すると推定されます。より現実的な仮定に基づいたルーティングテーブルのサイズ、長年にわたって並列IPv4およびIPv6ルーティングのサイズはそれほど明確ではありません。割り当てられたIPv6アドレスのプレフィックスの量が増加しています。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は、一般的にローエンドデバイスで使用されます。リブの保管は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.]
[編集者注：高性能ルーターのリブと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年、ゴードンムーアは、統合回路のトランジスタの密度は、最小コンポーネントコストに関して2年ごとに2倍になる可能性があると予測しました。その後、期間は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.
現在までに、このコストの差は明確に示されていません。しかし、インターネットの帯域幅の成長と個々のリンクの速度の着実な上昇により、ルーターメーカーはより洗練されたシリコン技術を継続的に適用することを余儀なくされました。3年ごとに帯域幅の約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がリブの保管に使用され、低エンドのルーターでは、FIBの保存にも使用されます。歴史的に、DRAM容量は3.3年ごとに約4倍に成長します。これは2年ごとに2.4倍に変換されるため、ドラム容量は実際にはムーアの法律が示唆するよりも速く成長します。ただし、DRAMスピードは年間約10％、または2年ごとに1.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.
FIBをオフチップSRAMに保存することは、人気のあるデザインの決定です。高速インターフェイスの場合、これには低遅延の大容量部品が必要です。このタイプのSRAMのドライバーは、以前はPCキャッシュメモリでした。ただし、このキャッシュメモリは最近、プロセッサダイに直接移動しているため、キャッシュメモリの量が減少しました。今日、オフチップSRAMの主なドライバーは携帯電話であり、ハイエンドルーターの設計には適用されない低電力の小容量部品が必要です。その結果、ルーターの設計に好まれるSRAMSはボリュームパーツではありません。彼らはコスト曲線から落ちており、ムーアの法律を追跡していません。
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に遅れた1つの技術的ステップにすぎません。これは主に帯域幅の成長によって推進されており、すでに価格/パフォーマンス曲線の膝をはるかに超えて技術をプッシュしています。このレベルのテクノロジーはすでにパフォーマンスの目標を達成するための要件であることを考えると、オンチップ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倍に約2倍に増加するため、同様に上昇しています。これにより、新しい機能とチップアーキテクチャが可能になり、必然的に複雑さと人件費の増加につながります。新しいチップ開発がメモリをスケールアップする必要性によってのみ駆動され、メモリ構造がスケーリングされた場合、人件費は固定されたままであると予想されます。残念ながら、メモリ構造は通常、直線的にスケーリングしていないようです。個々のメモリコントローラーには無視できないコストがあり、内部のオンチップ相互接続の記憶の設計につながります。最終的な結果は、チップ開発コストがテープアウトコストの増加に沿って大まかにエスカレートし続け、2年ごとに約1.5倍の継続的なコスト曲線につながると予想できることです。各テクノロジーステップはメモリをほぼ2倍にするため、需要が年間約（2x/1.5x）= 1.3xよりも速く成長すると、テクノロジーの更新が一定のコスト曲線に留まることができないことを意味します。
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.
システム評価の重要なメトリックは、ワットあたりの転送帯域幅の単位 - [（MB/S）/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.
成長率の制御されていない性質を考えると、インターネットのルーティングサブシステムの健康とコストの長期的な見通しについては、ある程度の懸念があります。継続的な成長は、定期的な技術の復seを強制します。ただし、成長率は、ルーター業界で見られる開発コストに基づいて、一定のコストでサポートできるレートを超える可能性があります。ハイエンドルーティングは低容量の技術に基づいているため、より広範なコンピューティング業界の大部分がムーアの法則に基づいて見るコストの利点は直接継承されていません。これにより、転送テーブルでは1.3x/2yr、ルーティングテーブルで1.2x/2yrsの持続可能な成長率が得られます。現在のベースラインの成長が1.3x/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.
ルーティングとアドレス指定は、インターネットアーキテクチャの2つの基本的な部分であるため、それらへの変更は、アプリケーションからパケット転送まで、ほぼすべての「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.
BoeingのConnexion Serviceは、グローバルスケールで添付ファイルポイントをインターネットに変更する可能性のある商用モバイルネットワークの展開を開拓しました。このような飛行中のインターネット接続は、それほど遠くない将来において一般的になる可能性が高いと考えられています。それが起こると、いつでも空中に数千の飛行機ネットワークがある可能性があります。
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リブはすでに200,000を超える接頭辞[CIDRRPT]を処理していることを考えると、それぞれ1回のプレフィックスアナウンスで表される数千のモバイルネットワークが、必ずしも深刻なルーティングのスケーラビリティまたは安定性の懸念を引き起こすとは限りません。ただし、電車や船のネットワークなど、他のタイプのモバイルネットワークが登場すると、この数値が大幅に大きくなる可能性があるかどうかについては、公開されています。このようなモバイルネットワークが一般的になった場合、グローバルルーティングシステムへの影響を評価する必要があります。
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]）は、ホームエージェントを通じて1レベルの間接的なモビリティを処理します。モバイルホストは、ルーティングの観点から、固定ホストとは違いはありません。同じアプローチに従う場合、新しいモバイルデバイスは、ホスト集団のサイズの増加を超えて課題を提示するべきではありません。
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.
ワークショップの参加者は、モバイルデバイスの数の増加が重要である可能性があり、ジェネリックID-Locatorの分離をサポートするスケーラブルなルーティングシステムが開発および導入された場合、グローバルなルーティングのスケーラビリティに過度の影響を与えることなく、数十億のモバイルガジェットをサポートできることを認識しました。および安定性。
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. 1997年にO'Dellが行ったGSEの提案とその長所と短所、および
4. Map-and-Encap [RFC1955], a general indirection-based solution to scalable multihoming support.
4. MAP-and-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 Multihomingのスケーラブルなサポートのためのソリューションスペースを探索するためにチャーターされました。Multi6ワーキンググループによって収集された多数の提案は、一般に2つの主要なカテゴリのいずれかに分類されました。プロバイダーに依存しないアドレスの割り当てを使用するか、複数のアドレスのプレフィックスをマルチホームサイトに割り当てることにより、プロバイダーごとに複数のアドレスのプレフィックスを割り当てることにより、すべてのアドレスは、トポロジカルに集約可能です。
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.
提案の大部分は、サイトごとに複数のアドレスブロックを割り当てる2番目のカテゴリに分類されました。IPアドレスは、高レベルのプロトコルとアプリケーションの識別子として使用されているため、これらの提案は、複数のロケーター（つまり、ISPから受信した複数のアドレス）を識別子にマッピングする責任があるレイヤーに関する基本的な設計決定に直面しています。関連する質問には、複数のアドレスの処理に責任があるノードが含まれます。個々のホストまたはサイトのエッジルーター、またはその両方でマルチアドレススキームを実装できます。エッジルーターによる複数のアドレスを処理すると、サイト全体のトラフィックフローを制御する機能が提供されます。逆に、個々のホストによる複数のアドレスを処理すると、各ホストがプロバイダーを選択するためのさまざまなポリシーを選択する柔軟性を提供します。また、マルチホームサイトのすべてのホストの変更を意味します。
During the process of evaluating all the proposals, two major lessons were learned:
すべての提案を評価する過程で、2つの主要な教訓が学習されました。
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.
o 現在のプラクティスの何かを変更することは困難です。たとえば、プロトコルに追加のヘッダーを挿入すると、IPフラグメンテーション処理に影響を与え、現在の混雑制御は、各TCP接続が単一のルーティングパスに従うことを前提としています。さらに、オペレーターは、サイトごとにトラフィックエンジニアリングを実行する能力を求め、サイトポリシーの仕様はしばしば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アドレスは、ネットワークポリシーの構成に識別子としても使用されています。たとえば、IPアドレスのセマンティクスを変更すると、GSEが提案した識別子として最後の64ビットのみを使用するには、そのようなすべてのアプリケーションとネットワークデバイスの変更が必要になります。
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ワーキンググループの調査から2番目のアプローチを採用しました。つまり、複数のアドレスを使用してマルチホームをサポートしました。SHIM6はホストベースのアプローチを採用しました。ホストIPスタックには、安定した「上層識別子」（ULID）が上層層プロトコルに表示される「SHIM」が含まれていますが、現在機能しているように送信および受信した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レイヤーの上のプロトコルを使用してulidを使用してエンドポイントを識別します（たとえば、TCP接続の場合）。現在の設計では、ロケーターのいずれかを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では、SHIM処理をサポートするために、すべてのホストスタック実装を変更する必要があります。第二に、SHIM層は、識別子と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ソリューションのもう1つの主要な問題は、サイトがプロバイダーを変更した場合に変更の必要性です。マルチホームのサイトには複数のアドレスブロックが割り当てられていますが、それらのどれもサイトの永続的な識別子として扱うことはできません。サイトがプロバイダーの1つを変更した場合、そのプロバイダーのアドレスブロックをサイト全体からパージする必要があります。識別子とロケーターの両方としてIPアドレスを使用する現在の慣行は、さまざまなタイプのポリシー執行デバイス（例：ファイアウォール）に存在するアクセス制御リストにIPアドレスを使用することにより強化されました。Shim6の亜油を政策執行に使用する場合、プロバイダーの変更は、そのような多くのデバイスの再構成を必要とする場合があります。
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]やMap and-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.
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.
sayingにあるように、「コンピューターサイエンスには、余分なレベルの間接的なレベルでは解決できない問題はありません」。GSEの提案は、スケーラブルなマルチホミングに対する間接ベースのソリューションのクラスの特定のインスタンス化と見なすことができます。Map-and-Encap [RFC1955]は、ロケーターの書き換えの代わりにトンネリングを使用してDFZを越え、サポートプロバイダーベースのプレフィックス集約を使用するこの間接ソリューションのより一般的な形式を表します。このクラスのソリューションは、PAおよびPIプレフィックスに関するプロバイダーと顧客の競合を、それぞれを別の名前のスペースに入れて回避するため、ISPはトポロジカルな集計可能なアドレスを使用し、顧客はグローバルにユニークでプロバイダーに依存しない識別子を持つことができます。したがって、スケーラブルなマルチホミングをサポートし、サイトのボーダールーターによってカプセル化が実行される場合、エンドシステムに変更を必要としません。また、両方のアプリケーションの現在の慣行とバックボーン操作に変更を変更する必要はありません。
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.
ただし、効果的なソリューションのすべての利益には、特定の関連費用が伴います。このセクションで前述したように、マッピングサービスを提供する必要があります。このマッピングサービスは、関連する複雑さとコストをもたらすだけでなく、障害の別のポイントを追加し、悪意のある攻撃の潜在的なターゲットになる可能性もあります。ルーティングのスケーラビリティに対するソリューションは、必然的にコスト/利益のトレードオフです。その利益の高い可能性を考えると、この間接的なアプローチは、スケーラブルなルーティングソリューションの検索に特別な注意に値します。
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リブとFIBのサイズ、ルーティング収束時間に対するリブと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リブの成長は、限られたIPv4アドレス空間によって制約されていると一般に考えられています。ただし、この制約の下でさえ、DFZ IPv4リブは加速速度[DFZ]と思われるもので成長しています。IPv6ルーティングアーキテクチャがIPv4アーキテクチャ（大幅に大きいアドレススペースを持つ）と同じであることを考えると、IPv6が広く展開された場合、IPv6のルーティングテーブルの成長は状況を悪化させるだけであると予測することは自然です。
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）の展開の増加は、ルーティングシステムの成長を促進するもう1つの主要な要因と考えられています。ただし、この因子がDFZリブに直接的な影響を与えているかどうかについては、異なる見解があります。一般的な慣行は、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リブの成長を促進する主要な要因であると思われます。以下では、DFZリブへの影響を詳しく説明します。
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を検討してください。2番目のプロバイダーP2を持つCマルチホームの場合、P1とP2の両方がX.Y.Z/24を発表する必要があるため、両方のプロバイダーを介してCに到達できるようにする必要があります。この例では、接頭辞X.Y.Z/24は、Cの識別子として、およびCのTransitシステムへの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リブに関する限り、上記の例は、顧客が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に返されることになっています。顧客は、新しいプロバイダーから新しいプレフィックスを取得することになっています。つまり、ネットワークを変更します。プロバイダーは、プレフィックスのトポロジカルな集計を維持するために、以前の顧客から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.
今日の実践では、IPプレフィックスを凝集させることにより、トラフィックエンジニアリング（TE）が達成されます。プレフィックスの長さとそれらのパスを介して発表されたプレフィックスの数を調整することにより、特定のルーティングパスに沿って交通量を効果的に調整できます。したがって、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.
Routing Convergenceの問題には、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リブサイズの急速な成長がIGPの収束を効果的に減速させる可能性があることを懸念していました。IGP収束遅延は、
1. Delays in detecting physical failures,
1. 物理的障害の検出の遅延、
2. The delay in loading updated information into the FIB, and 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.
2. 更新された情報をFIBにロードする遅延、および3.内部rib骨の大きなサイズは、多くの場合、DFZリブの2倍の大きさであり、これにより、ルート計算時間が長くなり、FIB負荷時間が長くなる可能性があります。
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）それが建築上の問題であるか、実装の問題であるか。ただし、一般的に、ルーティングスケーラビリティの問題を解決すると、収束遅延を減らすか、処理するルートの数が減って問題を処理しやすくすることは確かに役立つことに同意します。
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つの帯域幅に制約されたトランススコアンリンクを持ち、各リンクを完全にロードするためにプレフィックスアナウンスを分割したいとします。脱結分を実行することの利点としての起源。ただし、凝集した発表がグローバルに伝播する場合、コストは他のすべてのお尻によって生まれます。つまり、このタイプのTEプラクティスのコストは、受益者に含まれていません。Multihomingは同様の例を提供します（この場合、Multihomedサイトは利益を達成しますが、グローバルインターネットには追加のプレフィックス（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.
モビリティは、ワークショップで最も頻繁に言及されている問題の1つでした。近い将来、数十億のモバイルガジェットがインターネットに接続される可能性があると予想されます。また、ここ数年にわたってボーイングが提供する接続サービスに展開されたネットワークモビリティに関する議論もありました。ただし、現時点では、（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.
ルーティングセキュリティは、ワークショップ中に何度も育てられた別の問題です。ワークショップの参加者からのコンセンサスは、重要なルーティングセキュリティがどんなに重要であっても、このワークショップの範囲外であった可能性があり、その主な目標は、スケーラビリティのアドレス指定とルーティングに関する問題の声明を作成することでした。ソリューション開発段階に到達したとき、セキュリティはトップデザインの目標の1つでなければならないことが正式に考えられていました。また、ルーティングテーブルが無期限に成長することを引き続き許可し続けると、将来セキュリティの強化を追加することは不可能かもしれません。
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で説明されているように、加速ハードウェアコストの増加と、より短い減価償却サイクルの圧力の両方につながります。これは、コストの増加にも変換されます。
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 ENDサイト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.
o ISP TEを輸送するための小規模なISP：オペレーターは、リソースの緊密な制約に直面し、特定のルーティングパスに沿って顧客とプロバイダーの両方からトラフィックを入力する量に影響を与え、限られたリソースを最適に活用したい場合があります。
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：インターネットトポロジの密に接続された性質を考えると、特定の目的地は通常、異なるルーティングパスを介して到達できます。オペレーターは、近隣のお尻とのビジネス関係に基づいて、各ピアに送信される交通量を調整できることを望む場合があります。
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.
ワークショップの出席者は、制御されていないルーティングの成長の重要な理由の1つは、インセンティブの不整合であると結論付けました。ルーティングシステムに新しいエントリが追加され、特定の関係者に利益をもたらしますが、コストはグローバルルーティングシステムの全員が生まれます。ワークショップのコンセンサスは、提案されたソリューションは、システム全体のコストを削減する慣行に報いるインセンティブを提供するよう努力し、グローバルシステムに過度の負担を課す「悪い」行動を罰するべきであるということでした。
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はシステムとハードウェアのアップグレードサイクルを通過し続けると考えています。多くの参加者は、システムのスケーリングプロパティが現在のコストに匹敵するレートでハードウェアがインターネットの成長に追いつくことができるという要望を表明しました。スケーリングが加速コストの増加につながる状況に反対します。
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〜2年の時間枠内で準備できると仮定した場合、その後に別の2年間の認定サイクルが続きます。その結果、最良のシナリオでさえ、ソリューションを展開する際に3〜5年の時間枠に直面しています。
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つの側面があります。ルーティングテーブルが現在のレートで成長し続けると、展開されたコアルーティング機器の迅速なハードウェアとソフトウェアのアップグレードと交換サイクルがコストがかかる場合があります。最悪の場合、ルーティングテーブルの成長は、費用対効果の高い方法でグローバルルーティングシステムを設計する能力を上回る可能性があります。一方、インターネットルーティングテーブルの成長を停止または実質的に減速するためのソリューションは、必然的に独自のコストをもたらし、おそらく他の場所やさまざまな形で表示されます。このようなトレードオフの例は、セクション6に示されています。ここでは、スケーラブルなマルチホームサポート（SHIM6、GSE、および一般的なトンネルアプローチ）に対するいくつかの異なるアプローチの利益とコストを調べました。ソリューション開発における主要なタスクは、誰が何をあきらめなければならないか、そしてそれが価値のあるトレードオフになるかどうかを理解することです。
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.
ソリューション基準に関するこの議論を終了する前に、Tony Liが作成したワークショップでの最短のプレゼンテーションについて言及する価値があります（プレゼンテーションスライドは付録Dから見つけることができます）。彼は基本的な質問をしました：何が危機にatしていますか？それはインターネット自体です。ルーティングシステムがインターネットの継続的な成長に合わせてスケーリングしない場合、最終的にコストが制御不能になり、デジタル格差が広がり、インターネットの成長が遅くなり、停止、または後退する可能性があります。この問題と比較して、彼は、これまでに言及された基準（問題を解決することを除く）のどれも、効果的なソリューションの開発と展開をブロックするのに十分重要ではないと考えました。
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.
第三に、ワークショップの参加者は、より大きなネットワーキングコミュニティからの広範な参加を伴う、オープンで透明な方法でソリューション開発を実施することを推奨しています。参加者の大半は、ソリューションの開発に向けてリソースをコミットする意欲を示しました。また、このプロセスへの研究コミュニティからの参加を招待する必要があります。Locator-Identifierの分割は基本的なアーキテクチャの問題を表しており、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).
第4に、長期的なソリューションを開発するという目標と、開発と展開のサイクルには必ず時間がかかるという事実を考えると、エンジニアリング可能な短期または中期ソリューションを通じて時間を購入することは役立つ（または必要でさえあります）（例えば、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.
Jari Arkko、Vince Fuller、Darrel Lewis、Tony Li、Eric Rescorla、およびTed Seelyは、この文書の以前のバージョンについて多くの洞察に満ちたコメントをしました。最後に、ワークショップ中に彼が取った素晴らしいメモについてWuter Wijngaardsに感謝します。
[RFC1955] Hinden, R., "New Scheme for Internet Routing and Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.
[RFC1955] Hinden、R。、「IPNGのインターネットルーティングとアドレス指定（capp）の新しいスキーム」、RFC 1955、1996年6月。
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March 1999.
[RFC2547] Rosen、E。およびY. Rekhter、「BGP/MPLS VPNS」、RFC 2547、1999年3月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、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] Berkowitz、H.、Davies、E.、Hares、S.、Krishnaswamy、P。、およびM. Lepp、「コントロールプレーンでのBGPデバイスの収束をベンチマークするための用語」、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] Eabley、J.、Lindqvist、K.、Davies、E.、Black、B。、およびV. Gill、「IPv4 Multihoming Practices and Limations」、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] Baker、F.、Lear、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] Fuller、V。およびT. Li、「クラスレス間ドメインルーティング（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] Doria、A。およびE. Davies、「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 Service RegionのIPv4アドレスの割り当てと割り当てポリシー」、Ripe-387 http://www.ripe.net/docs/ipv4-policies.html、2006。
[SHIM6] "Site Multihoming by IPv6 Intermediation (shim6)", http://www.ietf.org/html.charters/shim6-charter.html.
[SHIM6]「IPv6仲介（SHIM6）によるサイトマルチホーム」、http：//www.ietf.org/html.charters/shim6-charter.html。
[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] O'Dell、M。、「GSE -IPv6の代替アドレス指定アーキテクチャ」、Work in Progress、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] Zhang、L。、「GSEのマルチホームとオープンの問題の概要」、IETF Journal、http：//www.isoc.org/tools/blogs/ ietfjournal/？p = 98＃more-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] Oliveira、R。and et。al。、「インターネットでのパス探索の定量化」、インターネット測定会議（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] Oliveira、R。and et。al。、「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] Boothe、P.、Hielbert、J。、およびR. Bush、「インターネット上の短命のプレフィックスハイジャック」、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] Caesar、M。and et。al。、「Rofl：フラットラベルのルーティング」、Sigcomm 2006、http：//www.sigcomm.org/sigcomm2006/ Discussion/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。al。、「最小ストレッチ付きのコンパクトネームに依存しないルーティング」、並列アルゴリズムとアーキテクチャに関する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.、Gao、L。、およびD. Towsley、「BGPルーティングテーブルの成長を特徴付ける」、J。コンピューターおよびTelecommネットワーキングV45N1、2004。
[Fuller] Fuller, V., "Scaling issues with ipv6 routing+ multihoming", http://www.iab.org/about/workshops/ routingandaddressing/vaf-iab-raws.pdf, 2006.
[Fuller] Fuller、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] Huston、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] Huston、G。、 "2005-レビューのBGP年"、http：// www.apnic.net/meetings/21/docs/sigs/routing/ routing-huston-routing-pdate.pdf。
[DFZ] Huston, G., "Growth of the BGP Table - 1994 to Present", http://bgp.potaroo.net, 2006.
[DFZ] Huston、G。、「BGPテーブルの成長-1994から現在まで」、http：//bgp.potaroo.net、2006。
[GIH] Huston, G., "Wither Routing?", http://www.potaroo.net/ispcol/2006-11/raw.html, 2006.
[Gih] Huston、G。、「Wither Routing？」、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] Huston、G。およびG. Armitage、「動的BGP行動の傾向から将来のIPv4ルーター要件を予測する」、http：//www.potaroo.net/papers/phd/ ATNAC-2006/BGP-ATNAC2006.pdf、2006年。
[CIDRRPT] "The CIDR Report", http://www.cidr-report.org.
[cidrrpt] "The CIDR Report"、http://www.cidr-report.org。
[ML] "Moore's Law", Wikipedia http://en.wikipedia.org/wiki/Moore's_law, 2006.
[ML]「Moore's Law」、Wikipedia 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-Fernandez、P。、「ルーターとスイッチの技術動向」、PhD論文、スタンフォード大学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] Landler、P。、「DRAMの生産性と容量/需要モデル」、Global Economic Workshop http：// www.sematech.org/meetings/ges/ges/ges/19990514/docs/ 07_econ.pdf、1999。
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はソリューション調査のために特別な設計チームをチャーターすることができます。
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が迅速なアクションをとると信じています。ただし、それが発生しない場合、オペレーターとベンダーは自分で行動し、ソリューションを展開する可能性が最も高くなります。
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 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)
Loa Anderson（IAB）Jari Arkko（IESG）Ron Bonica Ross Callon（IESG）Brian Carpenter（IAB）David Conrad（IABチェア）Leslie Daigle（IAB）Terry Davis Weisi Dong Aaron Falk（IRTFチェア）Kevin Fall（IAB）Dino Farinacci Vince Fuller Vijay Gill Russ Housley（IESG）Geoff Huston Daniel Karrenberg Dorian Kim Olaf Kolkman（IAB）Darrel Lewis Li Li Kurtis Lindqvist（IAB）Peter Lothberg David Meyer（IAB）Christopher Morro Molor Phil Roberts（IABエグゼクティブディレクター）ジェイソンシラーピーターシェンメーカーテッドシーリーマークタウンズリー（IESG）イルジッチュヴァンベイニュムーディガーヴォルクマグナスウェスターランド（IESG）リキシアザン（IAB）
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.
1日目：提案されている目標は、可能な限り完全に収集することで、今日のインターネットに面したルーティングおよびアドレス指定エリアのスケーラビリティの問題のセットを収集することです。
0815-0900: Welcome, framing up for the 2 days Moderator: Leslie Daigle
0815-0900：ようこそ、2日間のフレーミングモデレーター：Leslie 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：モーニングセッションモデレーター：エルウィンデイビスストローマンモーニングセッションのトピック： - スケーラビリティ - マルチホームサポート - トラフィックエンジニアリング - ルーティングテーブルサイズ：成長率、ダイナミクス（これはDFZに限定されない、IBGPを含む） - 成長 - 成長による痛み（おそらく「ルーターへの影響」がここに来る可能性がありますか？） - 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のルーティングの問題は何ですか？モデレーター：Kurt Erik Lindqvist
1500-1530: Coffee Break
1500-1530：コーヒーブレイク
Dinner at Indrapura (http://www.indrapura.nl), sponsored by Cisco
インドラプラでのディナー（http://www.indrapura.nl）、Ciscoがスポンサー
---------
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：朝のセッション：テーブルにあるものモデレーター：Elwyn Davies -Shim6 -GSE
1000-1030: Coffee Break
1000-1030：コーヒーブレイク
1030-1200: Problem Statement session #1: document the problems
Moderator: David Meyer
1200-1300: Lunch
1200-1300：昼食
1300-1500: Problem Statement session # 2, cont;
Moderator: Dino Farinacci
- Constraints on solutions
1500-1530: Coffee Break
1500-1530：コーヒーブレイク
1530-1730: Summary and Wrap-up Moderator: Leslie Daigle
The presentations from the workshop can be found on
http://www.iab.org/about/workshops/routingandaddressing
Authors' Addresses
著者のアドレス
David Meyer (editor)
デビッド・マイヤー（編集者）
EMail: dmm@1-4-5.net
Lixia Zhang (editor)
リキシア・チャン（編集者）
EMail: lixia@cs.ucla.edu
Kevin Fall (editor)
ケビンフォール（編集者）
EMail: kfall@intel.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。