RFC4984 日本語訳
4984 Report from the IAB Workshop on Routing and Addressing. D. Meyer,Ed., L. Zhang, Ed., K. Fall, Ed.. September 2007. (Format: TXT=96153 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Meyer, Ed.
Request for Comments: 4984 L. Zhang, Ed.
Category: Informational K. Fall, Ed.
September 2007
ワーキンググループのD.マイヤー、エドをネットワークでつないでください。コメントのために以下を要求してください。 4984 エドL.チャン、カテゴリ: エド情報のK.秋、2007年9月
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)によって持たれていたルート設定とAddressing Workshopの結果を報告します、アムステルダム(オランダ)で。 ワークショップの第一の目標は大きい背骨オペレータが今日のインターネット・ルーティングシステムのスケーラビリティに関して直面している問題の共通の理解を開発することでした。 主要なワークショップ調査結果は運転する経路指定テーブルの成長である重要な要因の分析、ルータ技術における規制、および今日のインターネットアドレッシング体系の制限を含んでいます。 これらの調査結果が、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ではなく、講習会参加者のものです。 その上、このワークショップレポートに関連する問題に対する仕事が続行であり、このドキュメントが問題の増加する理解を反映して、この進行中の仕事の結果であるかもしれない潜在的解決策の範囲について議論しないつもりであることに注意してください。
Meyer, et al. Informational [Page 1] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[1ページ]のRFC4984IABワークショップ
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 ワークショップ. . . . . . . . . . . . . . . . 4 2.1からの主要な調査結果。 問題#1: ルート設定システム. . . . 4 2.1.1のもののスケーラビリティ。 DFZの含意は成長. . . . . . . . . . . . 5 2.1.2人にろっ骨を付けます。 DFZの含意は成長. . . . . . . . . . . . 6 2.2をたたきます。 問題#2: IPアドレス意味論. . . 6 2.3の積みすぎ。 他の関心. . . . . . . . . . . . . . . . . . . . . . 7 2.4。 これらの問題はどれくらい緊急ですか? . . . . . . . . . . . . . . 8 3. ルート設定とアドレス指定方式. . . . 8 3.1における現在の圧力。 メージャーは運転する経路指定テーブルの成長. . . . . . . . 8 3.1.1を因数分解します。 番号を付け替え. . . . . . . . . . . . . . . . . 9 3.1る.2を避けます。 マルチホーミング. . . . . . . . . . . . . . . . . . . . . 10 3.1.3。 交通工学. . . . . . . . . . . . . . . . . 10 3.2。 IPv6とルート設定でのその可能性のある衝撃はサイズ. . . 11 4を見送ります。 スケーリング問題. . . . . . 11 4.1に関するムーアの法則の含意。 ムーアの法則. . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1。 ドラム. . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.2。 オフチップSRAM. . . . . . . . . . . . . . . . . . . . 13 4.2。 エンジン. . . . . . . . . . . . . . . . . . . . 13 4.3を進めます。 コスト. . . . . . . . . . . . . . . . . . . . . . . . 14 4.4を欠いてください。 .144.5を加熱して、動かしてください。 概要. . . . . . . . . . . . . . . . . . . . . . . . . 15 5。 地平線. . . . . . . . . . . . . . . . . . . . 15 5.1にあるもの。 絶え間ない成長. . . . . . . . . . . . . . . . . . . . . 15 5.2。 多くのモバイルネットワーク. . . . . . . . . . . . . 16 5.3。 桁はモバイルエッジデバイス. . . 16 6を増やします。 .176.1にアプローチするものを調査してあります。 MULTI6. . . . . . . . . . . . . . . . . . . 17 6.2からのレッスン。 SHIM6: 賛否両論. . . . . . . . . . . . . . . . . . . 18 6.3。 GSE/間接指定解決: コストと利益. . . . . . 19 6.4。 間接指定. . . . . . . . . . . . . . . . . . 20 7のための未来。 問題声明. . . . . . . . . . . . . . . . . . . . . . 21 7.1。 問題#1: スケーラビリティ. . . . . . . . . . . . . 21 7.2を発送します。 問題#2: IPアドレス意味論. . . 22 7.2.1の積みすぎ。 ロケータと識別子. . . . . . . . . 22 7.2.2の定義。 ロケータと識別子積みすぎ. . 23 7.2.3の結果。 交通工学とIPは意味論オーバーロード. . . . . . . . . . . . . . . . . . . . . . . 24 7.3を記述します。 追加設定. . . . . . . . . . . . . . . . . . . . 24 7.3.1。 集合. . . . . . . . . . . . . . . . . 24 7.3.2を発送します。 調節不良のコストと利益. . . . . . . . . . . . 25 7.3.3。 他の関心. . . . . . . . . . . . . . . . . . . . 25 7.4。 問題認識. . . . . . . . . . . . . . . . . . . 26 8。 ソリューション開発. . . . . . . . . . . . . . 26 8.1の評価基準。 スケーラビリティ. . . . . . . . . . . . . . . . . 26 8.2の評価基準。 誘因と経済学. . . . . . . . . . . 27の評価基準
Meyer, et al. Informational [Page 2] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[2ページ]のRFC4984IABワークショップ
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
8.3. タイミング. . . . . . . . . . . . . . . . . . . . 28 8.4の評価基準。 既存のシステム. . . . . . . . . . . . 28 8.5における考慮。 セキュリティ. . . . . . . . . . . . . . . . 29 8.6における考慮。 他の評価基準. . . . . . . . . . . . . . . . . . . . . . 29 8.7。 見返り. . . . . . . . . . . . . . . . 29 9を理解しています。 ワークショップ推薦. . . . . . . . . . . . . . . . . . . 30 10。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 31 11。 承認. . . . . . . . . . . . . . . . . . . . . . . 31 12。 特定のステップ. . . . . . . . . . . 35 付録B.講習会参加者. . . . . . . . . . . . . . . . 35付録C.ワークショップ議題. . . . . . . . . . . . . . . . . . . 36付録D.プレゼンテーション. . . . . . . . . . . . . . . . . . . . 37のための有益な参照. . . . . . . . . . . . . . . . . . . . 31付録A.提案
1. Introduction
1. 序論
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][BGT04]でDefault Free Zone(DFZ)経路指定テーブルサイズの成長を追い立てています。 長い間既存のルーティング構造には重大なスケーラビリティ問題があるかもしれないと認められている間、効果的な解決は、まだ特定されて、開発されていなくて、また配備されていません。
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日にアムステルダム(オランダ)で「ルート設定とアドレシングワークショップ」を開催しました。 ワークショップの主な目標は、ルーティングスケーラビリティに強い影響を持っている存在と潜在的要素を特定して、1セットのフォローオン活動に入力されるように役立つかもしれない簡潔な問題声明を開発することでした。 このドキュメントはそのワークショップからその結果を報告します。
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は講習会参加者によってされた推薦状をまとめます。
Meyer, et al. Informational [Page 3] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[3ページ]のRFC4984IABワークショップ
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.
ワークショップ関係者リストはAppendix Cで議題を見つけることができるAppendix B.で添付されます、そして、Appendix 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ではなく、講習会参加者のものです。
2. Key Findings from the Workshop
2. ワークショップからの主要な調査結果
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経路指定テーブル(頻繁に経路情報基地、またはRIBと呼ばれる)のサイズとその含意に関連する大部分。 しかし、それらの含意が含んでいた、(制限されなかった、)、DFZ RIBとFIB(Forwarding Information基地)の規模、FIBを再計算する費用、RIBを育てることの面前でBGP集合回数に関する心配とFIB規模、およびハードウェアのコストとパワー(そして、したがって、熱の消散)の特性は、インターネットのコアの交通を発送する必要がありました。
2.1. Problem #1: The Scalability of the Routing System
2.1. 問題#1: ルート設定システムのスケーラビリティ
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 合併吸収などのビジネスイベント。
Meyer, et al. Informational [Page 4] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[4ページ]のRFC4984IABワークショップ
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 RIBへの「非-集合-可能」接頭語の注射に通じることができます。 位相的な集合がDFZ RIBの成長を制御する技術を発送するのが非位相的に基づくいくつか(例えば[CNIR]、例えば、ルート設定On Flat Labels[ROFL]かどんな名前から独立しているコンパクトなルーティング・アルゴリズムも)のない唯一の知られている実践的なアプローチであるので、接頭語反-集合は非制御のDFZ RIBの成長につながります。 以下のセクションはDFZ RIBの成長の含意のワークショップ議論を見直します。
2.1.1. Implications of DFZ RIB Growth
2.1.1. 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 RIBが数年の直線的な速度よりすばらしい[DFZ]で成長しているのを示しました。 これはRIBのための要件とFIB記憶容量に明白な影響を与えますが、また、接頭語反-集合によって動かされた成長は縁のダイナミックな本質にネットワークのコアを露出します、すなわち、反-集合がDFZ(頻繁に「UPDATEはかきまぜる」と呼ばれる)に注がれた増加する数のBGP UPDATEメッセージにつながります。 その結果、追加処理が、より長い接頭語のために状態を維持して、FIBをアップデートするのに必要です。 届いているホスト(すなわち、IPv4のための<m>がそれぞれのBGPルータにはいるかもしれない同輩の平均した数であるところのO(m*2^32))の与えられたアドレス空間サイズと数に従ってRIBのサイズは境界がありますが、ダイナミックな位相的な変化を分配するのに必要であるプロトコル活動の量がそうでないことに注意してください。 すなわち、ネットワークが経験できるBGP UPDATE攪乳器の量は本質的には限りないです。 また、UPDATE攪乳器が現在測定されているとして悪党の尾をすることに[ATNAC2006]注意されました。 すなわち、比較的少ない数のAutonomous Systems(ASs)か接頭語が私たちが今日観測するUPDATE攪乳器の不均衡に大きい部分に原因となります。 その上、攪乳器の多くが不要な情報であると判明するかもしれません、ことによるとグローバルなルーティングシステム[DynPrefix]に注がれる縁のASsの不安定性、または帯域幅価格決定モデルの仲裁のため(例えば、[GIH]か[BGP2005]のAS9121の動きの議論を見てください)。
Finally, it was noted by the workshop participants that the UPDATE churn situation may be exacerbated by the current Regional Internet Registry (RIR) policy in which end sites are allocated Provider- Independent (PI) addresses. These addresses are not topologically aggregatable, and as such, bring the churn problem described above into the core routing system. Of course, as noted by several participants, the RIRs have no real choice in this matter, as many enterprises demand PI addresses that allow them to multihome without the "provider lock" that Provider-Allocated (PA) [PIPA] address space creates. Some enterprises also find the renumbering cost associated with PA address assignments unacceptable.
最終的に、講習会参加者によってUPDATE攪乳器状況がProviderの独立している(PI)アドレスが端のサイトに割り当てられる現在のRegionalインターネットRegistry(RIR)方針で悪化させられるかもしれないことに注意されました。 これらのアドレスは位相的にそうではありません。コアルーティングシステムにそういうものとして「集合-可能」して、説明された攪乳器問題をもたらします。 もちろん、RIRsには、数人の関係者によって注意されるようにこの件に関するどんな本当の選択もありません、多くの企業がProviderによって割り当てられた(PA)[PIPA]アドレス空間が作成する「プロバイダー錠」なしで「マルチ-家」にそれらを許容するPIアドレスを要求するとき。 企業の中にはまた、関連している容認できないPAアドレス課題で費用を番号を付け替えるのに見つけるものもあります。
Meyer, et al. Informational [Page 5] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[5ページ]のRFC4984IABワークショップ
2.1.2. Implications of DFZ FIB Growth
2.1.2. DFZ空言の成長の含意
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]と費用対効果に優れて、高い性能のルータを築き上げる私たちの能力との関係に関してトニー・李によってされた観測(Appendix Dを見る)でした。 「ムーアの法則」は集積回路のトランジスタ密度が24カ月毎に最小のコンポーネント費用に関しておよそ倍増するという経験的観察です。 一般的に保持された知恵は技術が、コアルータハードウェアによって扱われたルーティング情報の成長率を凌ぐ歴史的な速度で比例し続けるのを確実にすることによってムーアの法則が成功をもたらすだろうということです。 しかしながら、李は、費用に関する限り、ムーアの法則がビル上位ルータに適用されないと指摘しました。
Moore's Law applies specifically to the high-volume portion of the semiconductor industry, while the low-volume, customized silicon used in core routing is well off Moore's Law's cost curve. In particular, off-chip SRAM is commonly used for storing FIB data, and the driver for low-latency, high-capacity SRAM used to be PC cache memory. However, recently cache memory has been migrating directly onto the processor die, and cell phones are now the primary driver for off- chip SRAM. Given cell phones require low-power, small-capacity parts that are not applicable to high-end routers, the SRAMs that are favored for router design are not volume parts and do not track with Moore's law.
ムーアの法則は特に半導体産業の大容量部分に適用されます、低ボリュームである間コアルーティングで使用されるカスタム設計されたシリコンがよくムーアの法則の費用曲線にあります。 特に、オフチップSRAMは、低遅延(PCキャッシュメモリになるのに使用される高容量SRAM)のためにFIBデータ、およびドライバーを格納するのに一般的に使用されます。 しかしながら、最近、キャッシュメモリは直接プロセッサに移動するのが死んで、現在携帯電話がオフチップSRAMのための第一のドライバーであるということです。 与えられた携帯電話は低パワー(上位ルータに適切です、ルータデザインのために支持されるSRAMsがボリュームの部品でないということでなく、またムーアの法則で追跡しないわずかな容量の部品)を必要とします。
2.2. Problem #2: The Overloading of IP Address Semantics
2.2. 問題#2: IPアドレス意味論の積みすぎ
One of the fundamental assumptions underlying the scalability of routing systems was eloquently stated by Yakov Rekhter (and is sometimes referred to as "Rekhter's Law"), namely:
すなわち、ルーティングシステムのスケーラビリティの基礎となるのがヤコフRekhter(そして、時々「Rekhterの法」と呼ばれる)によって雄弁に述べられたという基本的仮説の1つ、:
"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]).
同じ考えはipv6[GSE]のためにマイク・オデルの代替アドレス構造のデザインによって表されました。そこでは、アドレス構造が、「攻撃的な位相的な集合」がルーティングシステムをスケーリングするのを特に可能にするように設計されました。 また、クリスマスChiappaは手広くこの話題を書き続けました(例えば[EID]見てください)。
There is, however, a difficulty in creating (and maintaining) the kind of congruence envisioned by Rekhter's Law in today's Internet. The difficulty arises from the overloading of addressing with the semantics of both "who" (endpoint identifier, as used by transport layer) and "where" (locators for the routing system); some might also add that IP addresses are also overloaded with "how" [GIH]. In any
しかしながら、今日のインターネットでRekhterの法によって思い描かれた適合の種類を作成することにおける(そして、維持)苦労があります。 困難は(終点識別子で、トランスポート層のそばで中古)の「だれ」と「どこ」の両方の意味論で(ルーティングシステムのためのロケータ)を記述するか積みすぎから起こります。 また、或るものは、また、IPアドレスが「どのように」[GIH]で積みすぎられるかと言い足すかもしれません。 いずれでも
Meyer, et al. Informational [Page 6] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[6ページ]のRFC4984IABワークショップ
event, this kind of overloading is felt to have had deep implications for the scalability of the global routing system.
出来事、この種類の積みすぎはグローバルなルーティングシステムのスケーラビリティのための深い意味を持っていたと感じられます。
A refinement to Rekhter's Law, then, is that for the Internet routing system to scale, an IP address must be assigned in such a way that it is congruent with the Internet's topology. However, identifiers are typically assigned based upon organizational (not topological) structure and have stability as a desirable property, a "natural incongruence" arises. As a result, it is difficult (if not impossible) to make a single number space serve both purposes efficiently.
そして、Rekhterの法への気品はインターネット・ルーティングシステムが比例するように、それがインターネットのトポロジーについて一致しているような方法でIPアドレスを割り当てなければならないということです。 しかしながら、望ましい特性、「自然な不適合」が起こるとき、識別子は、組織的な(位相的でない)構造にベースで通常割り当てられて、安定性を持っています。 その結果、効率的にただ一つの数の宇宙サーブを両方の目的にするのは難しい、そして、(不可能。)です。
Following the logic of the previous paragraphs, workshop participants concluded that the so-called "locator/identifier overload" of the IP address semantics is one of the causes of the routing scalability problem as we see today. Thus, a "split" seems necessary to scale the routing system, although how to actually architect and implement such a split was not explored in detail.
前のパラグラフの理論に従って、講習会参加者は、私たちが今日見るようにIPアドレス意味論のいわゆる「ロケータ/識別子オーバーロード」がルーティングスケーラビリティ問題の原因の1つであると結論を下しました。 したがって、「分裂」はルーティングシステムをスケーリングするのに必要に見えます、実際に建築家と道具に、そのような分裂がどう詳細に探られなかったかということですが。
2.3. Other Concerns
2.3. 他の関心
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で説明された問題に加えて、講習会参加者はしかし、「2番目の層」が押す発行する以下の3を特定しました。
The first one is a general concern with IPv6 deployment. It is commonly believed that the IPv4 address space has put an effective constraint on the IPv4 RIB growth. Once this constraint is lifted by the deployment of IPv6, and in the absence of a scalable routing strategy, the rapid DFZ RIB size growth problem today can potentially be exacerbated by IPv6's much larger address space. The only routing paradigm available today for IPv6 is a combination of Classless Inter-Domain Routing (CIDR) [RFC4632] and Provider-Independent (PI) address allocation strategies [PIPA] (and possibly SHIM6 [SHIM6] when that technology is developed and deployed). Thus, the opportunity exists to create a "swamp" (unaggregatable address space) that can be many orders of magnitude larger than what we faced with IPv4. In short, the advent of IPv6 and its larger address space further underscores both the concerns raised in Section 2.1, and the importance of resolving the architectural issue raised in Section 2.2.
最初の1つはIPv6展開がある一般的な関心です。 IPv4アドレス空間が有効な規制をIPv4 RIBの成長に置いたと一般的に信じられています。 一度、IPv6の展開でこの規制を撤廃します、そして、スケーラブルなルーティング戦略がないとき、IPv6のはるかに大きいアドレス空間で潜在的に今日の急速なDFZ RIBサイズ成長問題を悪化させることができます。 今日IPv6に利用可能な唯一のルーティングパラダイムはClassless Inter-ドメインルート設定(CIDR)[RFC4632]とProviderから独立している(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刷は遅いルーティング集合です。 関心は特に、ルーティング集合がサービスプロバイダーが運ばなければならないルートの数における成長によって重大な問題になるということでした。
Meyer, et al. Informational [Page 7] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[7ページ]のRFC4984IABワークショップ
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は様々なテクノロジーの選択の「ビジネスモデル」影響を通常考えませんが、多くの関係者が、恐らく、時間がその哲学を見直すようになったのを感じました。
2.4. How Urgent Are These Problems?
2.4. これらの問題はどれくらい緊急ですか?
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展開が続くとき、関係者が不気味に迫る「体力の限界に達してください」という明確な期日を知覚したのでなりそうであるのではなく、これまで解決策に抵抗した問題が、より扱いにくくなりそうであって、効果的な解決の開発と展開が必ず少なくとも数年かかるということでした。
3. Current Stresses on the Routing and Addressing System
3. ルート設定とアドレス指定方式における現在の圧力
The primary concern voiced by the workshop participants regarding the state of the current Internet routing system was the rapid growth of the DFZ RIB. The number of entries in 2005 ranged from about 150,000 entries to 175,000 entries [BGP2005]; this number has reached 200,000 as of October 2006 [CIDRRPT], and is projected to increase to 370,000 or more within 5 years [Fuller]. Some workshop participants projected that the DFZ could reach 2 million entries within 15 years, and there might be as many as 10 million multihomed sites by 2050.
現在のインターネット・ルーティングシステムの事情に関して講習会参加者によって声に出された第一の関心はDFZ RIBの急速な成長でした。 2005年のエントリーの数はおよそ15万のエントリーから17万5000のエントリー[BGP2005]まで及びました。 この数は、2006[CIDRRPT]年10月現在20万に達して、5年[よりふくよかな]以内に37万以上まで増加すると予測されます。 何人かの講習会参加者が、DFZが15年以内に200万のエントリーに達することができると予測しました、そして、2050年までに最大1000万の「マルチ-家へ帰」っているサイトがあるかもしれません。
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 UPDATEはかきまぜる)でした。 UPDATEsが頻繁にFIBの再計算とダウンロードを必要とするので、これはルーティング集合に有害な影響力を持っています。 例えば、BGPルータは1日[DynPrefix]で最大50万のBGPアップデートを観測するかもしれません、1秒あたり1000のアップデートの上にピーク到着率がある状態で。 そのようなUPDATE攪乳器問題はDFZルートに制限されません。 本当に、また、大きいISPによって運ばれた内部のルートの数は集合時間を脅かします、そのような内部のルートが、より多くの詳細、Virtual兵士のNetwork(VPN)ルート、およびDFZに現れない他のルート[ATNAC2006]を含んでいるなら。
3.1. Major Factors Driving Routing Table Growth
3.1. メージャーは運転する経路指定テーブルの成長を因数分解します。
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
DFZ RIBの成長は、より多くの接頭語のテーブルへの添加から生じます。 この成長のいくつかが有機的ですが(すなわち、単にインターネットの成長からの結果)、成長の大半がアドレス接頭語の反-集合から生じる、(すなわち、より特定
Meyer, et al. Informational [Page 8] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[8ページ]のRFC4984IABワークショップ
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 交通Engineeringそこでは負荷がそれぞれで受けられた交通の量を調整するために複数のリンクの向こう側に異なったリンクにおけるより特定のルートの選択している広告でバランスをとっています。 そして
o Attempts to prevent prefix-hijacking by other operators who might
advertise more-specifics to steer traffic toward them; there are
several known instances of this behavior today [BHB06].
o 交通をそれらに向かって導くために広告を出すかもしれない他のオペレータによる接頭語ハイジャックの、より多くの詳細を防ぐ試み。 今日のこの振舞い[BHB06]のいくつかの知られている例があります。
3.1.1. Avoiding Renumbering
3.1.1. 番号を付け替えるのを避けます。
The workshop participants noted that customers generally prefer to have PI address space. Doing so gives them additional agility in selecting ISPs and helps them avoid the need to renumber. Many end- systems use DHCP to assign addresses, so a cursory analysis might suggest renumbering might involve modification of a modest number of routers and servers (perhaps rather than end hosts) at a site that was forced to renumber.
講習会参加者は、一般に、顧客が、PIアドレス空間を持っているのを好むことに注意しました。 そうするのは、ISPを選択する際に追加機敏さをそれらに与えて、それらが番号を付け替えさせる必要性を避けるのを助けます。 多くのエンドシステムがアドレスを割り当てるのにDHCPを使用するので、粗略な分析は、番号を付け替えるのが番号を付け替えるために強制されたサイトで穏やかな数のルータとサーバ(恐らく終わりのホストよりむしろ)の変更にかかわるかもしれないのを示すかもしれません。
In reality, however, renumbering can be more cumbersome because IP addresses are often used for other purposes such as access control lists. They are also sometimes hard-coded into applications used in environments where failure of the DNS would be catastrophic (e.g., some remote monitoring applications). Although renumbering may be a mild inconvenience for some sites and guidelines have been developed for renumbering a network without a flag day [RFC4192], for others, the necessary changes are sufficiently difficult so as to make renumbering effectively impossible.
IPアドレスがアクセスコントロールリストなどの他の目的にしばしば使用されるので、しかしながら、番号を付け替えるのはほんとうは、厄介である場合があります。 また、それらも時々一生懸命DNSの失敗が壊滅的である環境(例えばいくつかのリモート監視用途)で使用されるアプリケーションにコード化されています。 番号を付け替えるのはいくつかのサイトへの温和な不便であるかもしれません、そして、旗の日[RFC4192]なしでネットワークに番号を付け替えさせるためにガイドラインを開発してありますが、他のものにとって、必要な改革は、番号を付け替えることを事実上、不可能にするように十分難しいです。
For these reasons, PI address space is sought by a growing number of customers. Current RIR policy reflects this trend, and their policy is to allocate PI prefixes to all customers who claim a need. Routing PI prefixes requires additional entries in the DFZ routing and forwarding tables. At present, ISPs do not typically charge to route PI prefixes. Therefore, the "costs" of the additional prefixes, in terms of routing table entries and processing overhead, is born by the global routing system as a whole, rather than directly by the users of PI space. The workshop participants observed that no strong disincentive exists to discourage the increasing use of PI address space.
これらの理由で、PIアドレス空間は増加している数の顧客によって求められます。 現在のRIR方針はこの傾向を反映します、そして、それらの方針は必要性を要求するすべての顧客への接頭語をPIに割り当てることです。 PIが前に置くルート設定はDFZルーティングとテーブルを進める際に追加エントリーを必要とします。 現在のところ、ISPは、PI接頭語を発送するために通常充電されません。 したがって、経路指定テーブルエントリーと処理オーバヘッドで、追加接頭語の「コスト」は直接PIスペースのユーザでというよりむしろ全体でグローバルなルーティングシステムで生まれます。 講習会参加者は、どんな強い行動を妨げるものもPIアドレス空間の増加する使用に水をさしているために存在しないのを観測しました。
Meyer, et al. Informational [Page 9] RFC 4984 IAB Workshop on Routing & Addressing September 2007
Meyer, et al. Informational [Page 9] RFC 4984 IAB Workshop on Routing & Addressing September 2007
3.1.2. Multihoming
3.1.2. Multihoming
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 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).
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).
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).
3.1.3. Traffic Engineering
3.1.3. Traffic Engineering
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:
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:
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 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 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 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.
Meyer, et al. Informational [Page 10] RFC 4984 IAB Workshop on Routing & Addressing September 2007
Meyer, et al. Informational [Page 10] RFC 4984 IAB Workshop on Routing & Addressing September 2007
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 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).
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.
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.
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.
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.
3.2. IPv6 and Its Potential Impact on Routing Table Size
3.2. IPv6 and Its Potential Impact on Routing Table Size
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.
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.
4. Implications of Moore's Law on the Scaling Problem
4. Implications of Moore's Law on the Scaling Problem
[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.]
[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.]
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.
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.
Meyer, et al. Informational [Page 11] RFC 4984 IAB Workshop on Routing & Addressing September 2007
Meyer, et al. Informational [Page 11] RFC 4984 IAB Workshop on Routing & Addressing September 2007
[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.]
[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.]
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.
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.
4.1. Moore's Law
4.1. Moore's Law
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.
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.
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.
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.
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.
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.
Meyer, et al. Informational [Page 12] RFC 4984 IAB Workshop on Routing & Addressing September 2007
Meyer, et al. Informational [Page 12] RFC 4984 IAB Workshop on Routing & Addressing September 2007
4.1.1. DRAM
4.1.1. DRAM
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.
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.
4.1.2. Off-chip SRAM
4.1.2. Off-chip SRAM
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.
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.
4.2. Forwarding Engines
4.2. Forwarding Engines
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.
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.
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
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
Meyer, et al. Informational [Page 13] RFC 4984 IAB Workshop on Routing & Addressing September 2007
Meyer, et al. Informational [Page 13] RFC 4984 IAB Workshop on Routing & Addressing September 2007
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.
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.
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.
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.
4.3. Chip Costs
4.3. Chip Costs
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.
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.
4.4. Heat and Power
4.4. Heat and Power
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.
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.
Meyer, et al. Informational [Page 14] RFC 4984 IAB Workshop on Routing & Addressing September 2007
Meyer, et al. Informational [Page 14] RFC 4984 IAB Workshop on Routing & Addressing September 2007
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.
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.
[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.]
[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.]
4.5. Summary
4.5. Summary
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.
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.
5. What Is on the Horizon
5. What Is on the Horizon
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.
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.
5.1. Continual Growth
5.1. Continual Growth
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.
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.
Meyer, et al. Informational [Page 15] RFC 4984 IAB Workshop on Routing & Addressing September 2007
Meyer, et al. Informational [Page 15] RFC 4984 IAB Workshop on Routing & Addressing September 2007
5.2. Large Numbers of Mobile Networks
5.2. Large Numbers of Mobile Networks
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'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.
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.
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.
5.3. Orders of Magnitude Increase in Mobile Edge Devices
5.3. Orders of Magnitude Increase in Mobile Edge Devices
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.
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.
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.
The workshop participants recognized that the increase in the number of mobile devices can be significant, and that if a scalable routing system supporting generic identity-locator separation were developed and introduced, billions of mobile gadgets could be supported without bringing undue impact on global routing scalability and stability.
Further investigation is needed to gain a complete understanding of the implications on the global routing system of connecting many new mobile hand-held devices (including mobile sensor networks) to the Internet.
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.
Meyer, et al. Informational [Page 16] RFC 4984 IAB Workshop on Routing & Addressing September 2007
Meyer, et al. Informational [Page 16] RFC 4984 IAB Workshop on Routing & Addressing September 2007
6. What Approaches Have Been Investigated
6. What Approaches Have Been Investigated
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:
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:
1. The MULTI6 working group's exploration of the solution space and
the lessons learned,
1. The MULTI6 working group's exploration of the solution space and the lessons learned,
2. The solution to multihoming being developed by the SHIM6 Working
Group, and its pros and cons,
2. The solution to multihoming being developed by the SHIM6 Working Group, and its pros and cons,
3. The GSE proposal made by O'Dell in 1997, and its pros and cons,
and
3. The GSE proposal made by O'Dell in 1997, and its pros and cons, and
4. Map-and-Encap [RFC1955], a general indirection-based solution to
scalable multihoming support.
4. Map-and-Encap [RFC1955], a general indirection-based solution to scalable multihoming support.
6.1. Lessons from MULTI6
6.1. Lessons from MULTI6
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.
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.
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.
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.
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 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
Meyer, et al. Informational [Page 17] RFC 4984 IAB Workshop on Routing & Addressing September 2007
Meyer, et al. Informational [Page 17] RFC 4984 IAB Workshop on Routing & Addressing September 2007
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.
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.
During the process of evaluating all the proposals, two major lessons were learned:
During the process of evaluating all the proposals, two major lessons were learned:
o Changing anything in the current practice is hard: for example,
inserting an additional header into the protocol would impact IP
fragmentation processing, and the current congestion control
assumes that each TCP connection follows a single routing path.
In addition, operators ask for the ability to perform traffic
engineering on a per-site basis, and specification of site policy
is often interdependent with the IP address structure.
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 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 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.
6.2. SHIM6: Pros and Cons
6.2. SHIM6: Pros and Cons
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.
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.
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.
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 is able to isolate upper layer protocols from multiple IP layer addresses. This enables a multihomed site to use provider-allocated
SHIM6 is able to isolate upper layer protocols from multiple IP layer addresses. This enables a multihomed site to use provider-allocated
Meyer, et al. Informational [Page 18] RFC 4984 IAB Workshop on Routing & Addressing September 2007
Meyer, et al. Informational [Page 18] RFC 4984 IAB Workshop on Routing & Addressing September 2007
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.
それぞれの複数のプロバイダーからの接頭語、1、プロバイダーベースの接頭語集合を容易にするために。 しかしながら、この利得はいくつかの多大な費用と共に来ます。 まず最初に、SHIM6は、詰め物の処理を支持するためにすべてのホストスタック実現への変更を必要とします。 2番目に、詰め物の層は、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つを変えると、それはあて先ブロックから全体のサイトからそのプロバイダーを清めなければなりません。 様々なタイプの方針実施装置(例えば、ファイアウォール)の現在のアクセスコントロールリストにおけるIPアドレスの使用で識別子とロケータの両方としてIPアドレスを使用する現在の習慣を強化してあります。 SHIM6のULIDsが方針実施に使用されるつもりであるなら、プロバイダーの変化はそのような多くの装置の再構成を必要とするかもしれません。
6.3. GSE/Indirection Solutions: Costs and Benefits
6.3. GSE/間接指定解決: コストと利益
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
ワークショップで間接指定のスケーラブルなマルチホーミングの使用について議論しました、一般に、MapやEncapなどのGSE[GSE]と間接指定アプローチ[RFC1955]を含んでいて GSE提案は、識別子とロケータの両方の意味論を持つためにIPv6アドレス構造を変えます。 16バイトのIPv6アドレスの最初のnバイトは、ルート設定Goop(RG)と呼ばれて、排他的にロケータとしてルーティングシステムによって使用されます。 IPv6アドレスのベスト8バイトはエンドシステムの上でインタフェースを指定します。 中くらい(16--n--8)のバイトは、サイトの地方のトポロジーを特定するのに使用されます。 サイトの境界ルータはソースプロバイダーのアドレス集合のソースアドレス部を作るためにそれぞれの出発しているパケットのソースRGを書き直します。 また、彼らは、すべての内部のルータとホストからサイトのRGを隠すためにそれぞれの入って来るパケットの目的地RGを書き直します。 GSEです。
Meyer, et al. Informational [Page 19] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[19ページ]のRFC4984IABワークショップ
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をますますポピュラーな暗号で発生しているアドレス(CGA)の残りと互換性があるようにすることができた範囲[dGSE]としてIPv6アドレスの下側の8バイトを指定します。
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.
すべての識別子/ロケータ分裂提案が与えられた識別子に対応するロケータのセットを返すことができるマッピングサービスを必要とします。 また、さらに、これらの提案はロケータ失敗を検出するというその問題を訴えなければなりません、そして、データを向け直すのは「マルチ-家へ帰」っているサイトのために残っているロケータに注ぎます。 MapとEncap提案はこれらの問題を記述しませんでした。 GSEは、マッピングサービスを提供するのにDNSを使用するよう提案しましたが、それはロケータ失敗回復のために効果的な手段を提供しませんでした。 また、GSEはホストスタック変更を必要とします、上側の層とアプリケーションが全体のIPv6アドレスよりむしろ下側の8バイトしか使用できないとき。
6.4. Future for Indirection
6.4. 間接指定のための未来
As the saying goes, "There is no problem in computer science that cannot be solved by an extra level of indirection". The GSE proposal can be considered a specific instantiation of a class of indirection- based solutions to scalable multihoming. Map-and-Encap [RFC1955] represents a more general form of this indirection solution, which uses tunneling, instead of locator rewriting, to cross the DFZ and support provider-based prefix aggregation. This class of solutions avoids the provider and customer conflicts regarding PA and PI prefixes by putting each in a separate name space, so that ISPs can use topologically aggregatable addresses while customers can have their globally unique and provider-independent identifiers. Thus, it supports scalable multihoming, and requires no changes to the end systems when the encapsulation is performed by the border routers of a site. It also requires no changes to the current practice of both applications as well as backbone operations.
諺にもあるとおり、「余分なレベルの間接指定で解決できないコンピュータサイエンスには問題が全くありません」。 間接指定スケーラブルなマルチホーミングのベースの解決のクラスの特定の具体化であることをGSE提案を検討できます。 地図とEncap[RFC1955]は、ロケータの書き直しの代わりにDFZに交差して、プロバイダーベースの接頭語集合を支持するためにこの間接指定解決の、より一般的な書式を表します。(解決はトンネリングを使用します)。 このクラスの解決策は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.
しかしながら、効果的な解決のすべての獲得が、ある関連コストで伴われます。 より早くこのセクションで述べられるように、マッピングサービスを提供しなければなりません。 このマッピングサービスがそれと共に関連複雑さと費用をもたらすだけではありませんが、それは、また、失敗のもう1ポイントを加えて、また、悪意ある攻撃のための仮想ターゲットであるかもしれません。 ルーティングスケーラビリティのどんな解決策も必ず費用/利益見返りです。 利得の高い可能性を考えて、この間接指定アプローチは私たちのスケーラブルなルーティング解決の検索における特別な注意に値します。
Meyer, et al. Informational [Page 20] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[20ページ]のRFC4984IABワークショップ
7. Problem Statements
7. 問題声明
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.
講習会参加者は、インターネットコミュニティの異なった角度から今日のグローバルなルーティングシステムを見て、問題セットの異なった局面に異なったプライオリティを割り当てる異なったクラスの利害関係者が存在することに注意しました。 このセクションでの最優先する問題声明はこのワークショップの関係者のコンセンサスです、主として大きいネットワーク・オペレータといくつかのルータ業者の代理をして。 関係者の異なったグループが異なったリストを作り出すか、または異なったプライオリティでありそうであるのがありそうです。 例えば、番号を付け替えるのなしでプロバイダーを変える自由で、エンドユーザと企業のネットワーク・オペレータのワークショップで優先権リストの上部を組み立てるかもしれません。
7.1. Problem #1: Routing Scalability
7.1. 問題#1: ルート設定スケーラビリティ
The workshop participants believe that routing scalability is the most important problem facing the Internet today and must be solved, although the time frame in which these problems need solutions was not directly specified. The routing scalability problem includes the size of the DFZ RIB and FIB, the implications of the growth of the RIB and FIB on routing convergence times, and the cost, power (and hence, heat dissipation) and ASIC real estate requirements of core router hardware.
講習会参加者をルーティングスケーラビリティが今日インターネットに直面するのにおいて最も重要な問題であると信じて、解決しなければなりません、これらの問題が解決策を必要とする時間枠は直接指定されませんでしたが。 ルーティングスケーラビリティ問題はコアルータハードウェアのDFZ RIBとFIBの規模、ルーティング集合回数におけるRIBとFIBの成長の含意、費用、パワー(したがって、消散を加熱する)、およびASIC不動産要件を含んでいます。
It is commonly believed that the IPv4 RIB growth has been constrained by the limited IPv4 address space. However, even under this constraint, the DFZ IPv4 RIB has been growing at what appears to be an accelerating rate [DFZ]. Given that the IPv6 routing architecture is the same as the IPv4 architecture (with substantially larger address space), if/when IPv6 becomes widely deployed, it is natural to predict that routing table growth for IPv6 will only exacerbate the situation.
IPv4 RIBの成長が限られたIPv4アドレス空間によって抑制されたと一般的に信じられています。 しかしながら、この規制でさえ、DFZ IPv4 RIBは加速レート[DFZ]であるように見えることで成長しています。 IPv6ルーティング構造が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
Virtualの兵士のNetwork/仮想のルート設定とForwarding(VPN/VRF)の増加する展開はルーティングシステムの成長を追い立てる別の重要な要因であると考えられます。 または、しかしながら、この要素がそうしたかどうかに関して異なった視点がある、持っていない、DFZ RIBへの直接的な衝撃。 一般的な習慣は、特定のルータがVPN接続を扱うのを代表として派遣することになっています、その結果、背骨ルータが必ず成立するというわけではありません。
Meyer, et al. Informational [Page 21] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[21ページ]のRFC4984IABワークショップ
state for individual VPNs. Nevertheless, VPNs do represent scalability challenges in network operations.
個々のVPNsのための状態。 それにもかかわらず、VPNsはネットワーク操作におけるスケーラビリティ挑戦を表します。
7.2. Problem #2: The Overloading of IP Address Semantics
7.2. 問題#2: IPアドレス意味論の積みすぎ
As we have reported in Section 3, multihoming, along with traffic engineering, appear to be the major factors driving the growth of the DFZ RIB. Below, we elaborate their impact on the DFZ RIB.
私たちが詳細に報告したとき、セクション3(交通工学に伴うマルチホーミング)は、DFZ RIBの成長を追い立てながら、重要な要因であるように見えます。 以下では、私たちがDFZ RIBへのそれらの影響について詳しく説明します。
7.2.1. Definition of Locator and Identifier
7.2.1. ロケータと識別子の定義
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アドレスは世界的なネットワークではなく、企業で発送可能であるかもしれません。 世界的なネットワークで目に見えるのが許容されているなら、そのようなアドレスは背骨オペレータの観点にもかかわらず、ロケータからの識別子として企業のオペレータの観点から機能するかもしれません。
Meyer, et al. Informational [Page 22] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[22ページ]のRFC4984IABワークショップ
7.2.2. Consequence of Locator and Identifier Overloading
7.2.2. ロケータと識別子積みすぎの結果
In today's Internet architecture, IP addresses have been used as both locators and identifiers. Combined with the use of CIDR to perform route aggregation, a problem arises for either providers or customers (or both).
今日のインターネット構造では、IPアドレスはロケータと識別子の両方として使用されました。 ルート集合を実行するCIDRの使用に結合されていて、問題はプロバイダーか顧客のどちらかのために起こります(ともに)。
Consider, for example, a campus network C that received prefix x.y.z/24 from provider P1. When C multihomes with a second provider P2, both P1 and P2 must announce x.y.z/24 so that C can be reached through both providers. In this example, the prefix x.y.z/24 serves both as an identifier for C, as well as a (non-aggregatable) locator for C's two attachment points to the transit system.
例えば、キャンパスがプロバイダーP1からの接頭語x.y.z/24を受けたネットワークCであると考えてください。 したがって、P2、P1とP2の両方がそうしなければならない2番目のプロバイダーがあるCの「マルチ-家」がx.y.z/24を発表するとき、そのCに両方のプロバイダーを通して達することができます。 この例では、接頭語x.y.z/24はC識別子として両方に役立ちます、輸送システムへのCの2つの付着点への(非「集合-可能」)のロケータと同様に。
As far as the DFZ RIB is concerned, the above example shows that customer multihoming blurs the distinction between PA and PI prefixes. Although C received a PA prefix x.y.z/24 from P1, C's multihoming forced this prefix to be announced globally (equivalent to a PI prefix), and forced the prefix's original owner, provider P1, to de-aggregate. As a result, today's multihoming practice leads to a growth of the routing table size in proportion to the number of multihomed customers. The only practical way to scale a routing system today is topological aggregation, which gets destroyed by customer multihoming.
DFZ RIBに関する限り、上記の例は、顧客マルチホーミングがPAとPI接頭語の区別をぼかすのを示します。 CはP1からのPA接頭語x.y.z/24を受けましたが、Cのマルチホーミングによって、この接頭語がグローバル(PI接頭語に同等な)に発表させられて、接頭語の最初の所有者(プロバイダーP1)は反-やむを得ず集めました。 その結果、今日のマルチホーミング習慣は「マルチ-家へ帰」っている顧客の数に比例して経路指定テーブルサイズの成長につながります。 今日ルーティングシステムをスケーリングする唯一の実用的な方法が位相的な集合です。(その集合は顧客マルチホーミングで破壊されます)。
Although multihoming may blur the PA/PI distinction, there exists a big difference between PA and PI prefixes when a customer changes its provider(s). If the customer has used a PA prefix from a former provider P1, the prefix is supposed to be returned to P1 upon completion of the change. The customer is supposed to get a new prefix from its new provider, i.e., renumbering its network. It is necessary for providers to reclaim their PA prefixes from former customers in order to keep the topological aggregatiblity of their prefixes. On the other hand, renumbering is considered very painful, if not impossible, by many Internet users, especially large enterprise customers. It is not uncommon for IP addresses in such enterprises to penetrate deeply into various parts of the networking infrastructure, ranging from applications to network management (e.g., policy databases, firewall configurations, etc.). This shows how fragile the system becomes due to the overloading of IP addresses as both locators and identifiers; significant enterprise operations could be disrupted due to the otherwise simple operation of switching IP address prefix assignment.
マルチホーミングはPA/PI区別をぼかすかもしれませんが、顧客がプロバイダーを変えるPAとPI接頭語の間の大差は存在しています。 P1、顧客が前のプロバイダーからPA接頭語を使用したなら、変化の完成のときに接頭語によってP1に返されるべきです。 すなわち、顧客は、ネットワークに番号を付け替えさせながら、新しいプロバイダーから新しい接頭語を得るべきです。 元顧客からそれらのPA接頭語を取り戻すのが、彼らの接頭語の位相的なaggregatiblityを保つのにプロバイダーに必要です。 他方では、番号を付け替えることは非常に苦痛であるか、または不可能であると多くのインターネットユーザ、特に大きい法人顧客によって考えられます。 そのような企業におけるIPアドレスが深くネットワークインフラストラクチャの様々な部分に浸み込むのは、珍しくはありません、アプリケーションからネットワークマネージメント(例えば、方針データベース、ファイアウォール構成など)まで及んで。 これは、システムがIPアドレスの積みすぎのためロケータと識別子の両方としてどれくらいこわれやすくなるかを示します。 重要な企業操作は切り換えIPアドレス接頭語課題のそうでなければ、簡単な操作のため中断できました。
Meyer, et al. Informational [Page 23] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[23ページ]のRFC4984IABワークショップ
7.2.3. Traffic Engineering and IP Address Semantics Overload
7.2.3. 工学とIPアドレス意味論が積みすぎる交通
In today's practice, traffic engineering (TE) is achieved by de- aggregating IP prefixes. One can effectively adjust the traffic volume along specific routing paths by adjusting the prefix lengths and the number of prefixes announced through those paths. Thus, the very means of TE practice directly conflicts with constraining the routing table growth.
今日の習慣では、交通工学(TE)は反-集合IP接頭語によって達成されます。 事実上、1つは、特定のルーティング経路に沿ってそれらの経路を通して発表された接頭語の接頭語の長さと数を調整することによって、交通量を調整できます。 したがって、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接頭語がまず第一に位相的に「集合-可能」することであったなら、再集合を可能であるか、より簡単にするでしょう、よりよい粒状接頭語発表がそれらの起源からさらに遠く伝播されるとき。
7.3. Additional Issues
7.3. 追加設定
7.3.1. Routing Convergence
7.3.1. ルート設定集合
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.
2種類のルーティング集合問題、eBGP(グローバルなルーティング)集合、およびIGP(企業かプロバイダー)ルーティング集合があります。 孤立している位相的な出来事では、多くの場合[PathExp]、eBGP集合は大規模な経路探検に苦しみません、そして、最小のルート広告間隔(MRAI)タイマ[RFC4098]で集合遅れは主に決定しています、ルートがよそよそしくそれらのケースを除いて。 ルート退出は、経路探検としたがって、遅い集合に苦しむ傾向があります。 1人の関係者の経験は、退出遅れがしばしば2、3分まで持続するのを示します。 目的地が手が届かなくなるなら長い集合遅れがさらなる損害をアプリケーションにもたらさないと主張するかもしれません。 しかしながら、ケースが、より特定のルート(より長い接頭語)が失敗したところにしばしばあります、しかし、集められたルート(より短い接頭語)で目的地にまだ達することができます。 これらの場合では、長い集合遅れは衝撃アプリケーション性能をします。
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
DFZ RIBサイズの急速な成長はIGPsが運ばなければならない様々な専用ルートに加えて事実上遅くIGP集合をそうすることができることを心配していて、IGPsが設計されていて、BGP力、講習会参加者より急速に一点に集めます。 IGP集合遅れは重複因子、包含のためであることができます。
1. Delays in detecting physical failures,
1. 物理的な失敗を検出する遅れ
2. The delay in loading updated information into the FIB, and
2. そしてローディングの遅れが情報をFIBにアップデートした。
Meyer, et al. Informational [Page 24] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[24ページ]のRFC4984IABワークショップ
3. The large size of the internal RIB, often twice as big as the DFZ
RIB, which can lead to both longer route computation time and
longer FIB loading time.
3. しばしばより長い経路計算時間と、より長いFIBローディング時間の両方に通じることができるDFZ RIBの2倍大きく内部のRIBの大判。
The workshop participants hold different views regarding (1) the severity of the routing convergence problem; and (2) whether it is an architectural problem, or an implementation issue. However, people generally agree that if we solve the routing scalability problem, that will certainly help reduce the convergence delay or make the problem a much easier one to handle because of the reduced number of routes to process.
講習会参加者は(1) ルーティング集合問題の厳しさに関する異なった意見を保持します。 (2) そして、それは、建築問題、または導入問題ですか? しかしながら、一般に、人々は、私たちがルーティングスケーラビリティ問題を解決すると、確かに、それが、集合遅れを減少させるか、または処理するために問題をルートの減少している数のためにはるかに扱いやすいものにするのを助けるのに同意します。
7.3.2. Misaligned Costs and Benefits
7.3.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個の抑制された帯域幅の大洋横断のリンクを持って、各リンクを完全に積み込むために接頭語発表を分けたがっていると仮定してください。 起源ASは反-集合を実行するのから利益を得ます。 しかしながら、反-集められた発表がグローバルに伝播されるなら、費用は他のすべてのASsによって負担されます。 すなわち、このタイプのTE習慣のコストは受益者に含まれていません。 マルチホーミングは同様の例を提供します(この場合、「マルチ-家へ帰」っているサイトが利益を実現しますが、世界的なインターネットは追加接頭語(es)を運ぶ費用を被ります)。
The misalignment of cost and benefit in the current routing system has been a driver for acceleration of the routing system size growth.
現在のルーティングシステムの費用と利益の調整不良はルーティングシステムサイズの成長の加速のためのドライバーです。
7.3.3. Other Concerns
7.3.3. 他の関心
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
移動性がワークショップに最も頻繁に言及された問題の中にありました。 何十億個のモバイル機械装置が近い将来インターネットに接続されるかもしれないと予想されます。 また、ネットワークの移動性についての議論がここ数年間にわたるボーイングによって提供されたConnexionサービスで配備されるようにありました。 しかしながら、このとき、それは(1) ボーイングのようなネットワーク移動性サポートがルーティングシステムのスケーリング問題を引き起こすだろうかどうかと、(2) まさに何がグローバルへの何十億人のモバイルホストの影響であるかが不明瞭に見えます。
Meyer, et al. Informational [Page 25] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[25ページ]のRFC4984IABワークショップ
routing system. These discussions were covered in Section 5 of this report.
システムを発送します。 これらの議論はこのレポートのセクション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つであるに違いないと正しく考えられました。 また、次に、私たちが経路指定テーブルをずっと無期限に成長させるなら将来セキュリティ増進を加えるのが不可能であるかもしれないことに注意されました。
7.4. Problem Recognition
7.4. 問題認識
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.
問題を解くことにおける第一歩は、また、存在が重要性であると認めています。 しかしながら、ルーティングスケーリング問題の厳しさを認識するのは、それ自体で挑戦であるかもしれません、容易に示すことができるルーティングシステムスケーラビリティにおける特定の困難な限界が存在していなくて、また私たちが解決策を見いだす際にどのくらいの時間を持ってもよいかに関する少しの特定の質問の答もないので。 それにもかかわらず、講習会参加者の全体的な合意は私たちが、時間を使い果たしているように思えるということです。 両方に先導について合わせて調整する現在のRIBはハードウェアコスト増を加速しました、セクション4で説明されるように、また、増加かかるために順番に翻訳されるより短い減価償却サイクルの間の圧力と同様に。
8. Criteria for Solution Development
8. ソリューション開発の評価基準
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.
どんな共有する問題声明も複数の異なった解決策を認めるかもしれません。 このセクションは解決策スペースの上のワークショップ議論から特定されるように1セットの問題を提供します。 世界的なインターネットの顧客とプロバイダーの中の異種性、および問題の弾性を考えて、これらの問題のいずれも本来少しの特定の解決策も排除するべきではありません。 その結果、以下の問題は初めは規制として解決策で考えられましたが、私たちは、誘導している解決策評価に使用されるために'評価基準'という用語を採用するために代わりに選びました。
8.1. Criteria on Scalability
8.1. スケーラビリティの評価基準
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
明確に、どんな提案された解決策も当面の問題を解決しなければなりません、そして、私たちのナンバーワンの問題は前項で概説されているようにインターネットのルーティングとアドレス指定方式のスケーラビリティに関係があります。 インターネットユーザの母集団の継続成長、マルチホーミングとRFC2547VPN[RFC2547]展開の継続的な増加の仮定で、解決策は、ルーティングシステムが優雅に比例するのを可能にしなければなりません、数で測定されるように
Meyer, et al. Informational [Page 26] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[26ページ]のRFC4984IABワークショップ
o DFZ Internet routes, and
o そしてDFZインターネットルート。
o Internal routes.
o 内部のルート。
In addition, scalable support for traffic engineering (TE) must be considered as a business necessity, not an option. Capacity planning involves placing circuits based on traffic demand over a relatively long time scale, while TE must work more immediately to match the traffic load to the existing capacity and to match the routing policy requirements.
さらに、オプションではなく、ビジネスの必要性であると交通工学(TE)のスケーラブルなサポートをみなさなければなりません。 キャパシティプランニングは、交通需要に比較的長いタイムスケールの上基づくサーキットを置くことを伴います、TEが、よりすぐに、既存の容量にトラヒック負荷を合わせて、ルーティング方針要件を合わせるために働かなければなりませんが。
It was recognized that different parties in the Internet may have different specific TE requirements. For example,
インターネットの異なったパーティーには異なった特定のTE要件があるかもしれないと認められました。 例えば
o End site TE: based on locally determined performance or cost
policies, end sites may wish to control the traffic volume exiting
to, or entering from specific providers.
o サイトTEを終わらせてください: 局所的に決定している性能か費用方針に基づいて、特定のプロバイダーから出るか、または入って、端のサイトは交通量を制御したがっているかもしれません。
o Small ISP to transit ISP TE: operators may face tight resource
constraints and wish to influence the volume of entering traffic
from both customers and providers along specific routing paths to
best utilize the limited resources.
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: インターネットトポロジーの密に接続された自然を考えて、通常、与えられた目的地に異なったルーティング経路を通して達することができます。 オペレータは隣人ASsとのビジネス関係に基づく同輩各人に送られた交通量を調整できるようになりたがっているかもしれません。
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解決策は必ずルーティング・プロトコルにはあるだろうか、またはルーティングシステムに外部であることの手段で達成できるかが残っています。
8.2. Criteria on Incentives and Economics
8.2. 誘因と経済学の評価基準
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
グローバルなスケールと分配されたインターネットの性質を考えて、旗の日が(かつて)もうインターネットにあるはずがありません。 新しい解決策の展開を独力で進むために、解決策は最初に、動く人に動機を与えるべきです。 独身のパーティーが展開し始めてさえいると、それはそうです。
Meyer, et al. Informational [Page 27] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[27ページ]のRFC4984IABワークショップ
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が成長して、システムが、続けるシステムとハードウェアアップグレードサイクルを通して行き続けているルーティングを信じていました。 多くの出席者がハードウェアが例えば1つが5年のハードウェア減価償却サイクルを保つのを許容しながら現在のコストに匹敵するレートでシステムのスケーリング特性でインターネットの成長について行くことができるという願望を述べました、加速している費用に先導について合わせて調整するのが増加する状況と対照的に。
8.3. Criteria on Timing
8.3. タイミングの評価基準
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.
特定の困難な締め切りは存在していませんが、講習会参加者の満場一致のコンセンサスは解決策開発が今始まらなければならないということです。 --人が、解決策仕様がa1の中に用意されることができると仮定するなら2年間の時間枠、別の2年の証明が意志のあとに続いているのは循環します。 最も良いケースシナリオでさえ、私たちは3に直面しています--解決策を配備させることにおける5年間の時間枠。
8.4. Consideration on Existing Systems
8.4. 既存のシステムにおける考慮
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、-、そして、ことによると増加の増進の他のもの。
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
上の後方の互換性問題は解決策スペースの探検を抑制するべきではありません。 私たちは、最初に正しい解決を見つけるのが必要であり、後のそれらの後方の互換性の問題を調べます。
Meyer, et al. Informational [Page 28] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[28ページ]のRFC4984IABワークショップ
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.
原則として、既存のシステムへの、より少ない変更を行うなら、うまくいっている展開、どんな新案のための親指ではも、勝算は、より高いです。
8.5. Consideration on Security
8.5. セキュリティにおける考慮
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.
セキュリティは解決策開発の1日目から考えられるべきです。 他に何もであるなら、解決策で、ルーティングシステムを固定するのは今日、状況より少しも悪くなってはいけません。 誤ったルーティング情報を注入するのをより難しくして、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.
しかしながら、ルーティングシステムを固定するのは解決策開発のための要件であると考えられません。 セキュリティは重要です。 第一に働くシステムを持っているのはさらに重要です。
8.6. Other Criteria
8.6. 他の評価基準
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)性能において、終わりから端へのデータ配送経路は十分安定しているべきです。
8.7. Understanding the Tradeoff
8.7. 見返りを理解しています。
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
古いことわざが行くように、あらゆるコインには2つの側があります。 私たちが経路指定テーブルに現在の速度で成長し続けさせるなら、配備されたコアルーティング設備のための急速なハードウェア、ソフトウェアの更新、および交換サイクルは費用禁止になるかもしれません。 最悪の場合には、経路指定テーブルの成長は費用対効果に優れた方法でグローバルなルーティングシステムを設計する私たちの能力を超えるかもしれません。 他方では、止まるか、またはかなりインターネット経路指定テーブルでの成長を減速させる解決策は必ずそれら自身のコストをもたらすでしょう、恐らくほかの場所と異なったフォームに現れて。そのような見返りに関する例はそうです。
Meyer, et al. Informational [Page 29] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[29ページ]のRFC4984IABワークショップ
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.
セクション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.
解決策評価基準についてのこの議論を終わらせる前に、ワークショップで最も短いプレゼンテーションについて言及する価値があります(Appendix Dからプレゼンテーションスライドを見つけることができます)。(ワークショップはトニー・李によってされました)。 彼は基本的な質問をしました: 何が危機にひんしていますか? それはインターネット自体です。 ルーティングシステムがインターネットの継続成長で比例しないで、結局、コストが制御しきれないほどらせん形になるかもしれなくて、デジタル格差が広くなって、インターネットの成長が減速するなら、止まるか、または後退してください。 この問題と比べて、彼は、今までのところ(問題を解決するのを除いて)言及されている評価基準のいずれも効果的な解決の開発と展開を妨げることができるくらいには重要でないと考えました。
9. Workshop Recommendations
9. ワークショップ推薦
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.
2番目に; このワークショップの関係者がほとんど大きいサービスプロバイダーと一流のルータ業者から成ったので、講習会参加者は、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
3番目、講習会参加者は、開いていて、見え透いた方法で解決策開発を行うのを推薦します、より大きいネットワーク共同体からの広範囲に及ぶ参加で。 関係者の大部分が解決策を見いだすことに向かってリソースを遂行する彼らの意欲を示しました。 また、私たちは研究団体からこの過程で参加を招待しなければなりません。 ロケータ識別子分裂は基本的な構造的な問題、およびIABを表します。
Meyer, et al. Informational [Page 30] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[30ページ]のRFC4984IABワークショップ
should lead the investigation into understanding of both how to make this architectural change and the overall impact of the change.
調査をどうこの建築変更を行うか、そして、変化の総合的な衝撃の両方の理解に導くべきです。
Fourth, given the goal of developing a long-term solution, and the fact that development and deployment cycles will necessarily take some time, it may be helpful (or even necessary) to buy some time through engineering feasible short- or intermediate-term solutions (e.g., FIB compression).
長期的な解決法を開発するという目標、および開発と展開サイクルが必ずある程度時間がかかるという事実を考えて、いつか工学を通して可能な短いか中間的用語の解決策(例えば、FIB圧縮)を買うのは、4番目に、役立っているのと(必要さえ。)であるかもしれません。
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.
5番目に、講習会参加者は、次のステップがここから解決策展開まで道路地図を開発することであると信じています。 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が、解決策スペースを調べると考えるかもしれないという多くの提案をしました。 Appendix Aでこれらの提案を得ます。
10. Security Considerations
10. セキュリティ問題
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.
ルーティングシステムのセキュリティは大きな心配のものですが、このドキュメントは、どんな新しいプロトコルもプロトコル用法も導入しないで、またそういうものとしてどんな新しい安全保障問題も提示しません。
11. Acknowledgments
11. 承認
Jari Arkko, Vince Fuller, Darrel Lewis, Tony Li, Eric Rescorla, and Ted Seely made many insightful comments on earlier versions of this document. Finally, many thanks to Wouter Wijngaards for the fine notes he took during the workshop.
ヤリArkko、ビンス・フラー、ダレル・ルイス、トニー・李、エリック・レスコラ、およびテッド・シーリはこのドキュメントの以前のバージョンの多くの洞察に満ちたコメントをしました。 最終的に、彼がワークショップの間に取った詳しいノートのためにWouter Wijngaardsをありがとうございます。
12. Informative References
12. 有益な参照
[RFC1955] Hinden, R., "New Scheme for Internet Routing and
Addressing (ENCAPS) for IPNG", RFC 1955, June 1996.
[RFC1955] Hinden、R.、「インターネットルート設定とIPNGのために(ENCAPS)を記述することの新しい計画」、RFC1955、1996年6月。
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
March 1999.
1999年の[RFC2547]ローゼンとE.とY.Rekhter、「BGP/MPLS VPNs」、RFC2547行進。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
Meyer, et al. Informational [Page 31] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[31ページ]のRFC4984IABワークショップ
[RFC4098] Berkowitz, H., Davies, E., Hares, S., Krishnaswamy, P.,
and M. Lepp, "Terminology for Benchmarking BGP Device
Convergence in the Control Plane", RFC 4098, June 2005.
[RFC4098] バーコウィッツ、H.、デイヴィース、E.、野兎、S.、Krishnaswamy、P.、およびM.レップ、「制御飛行機でのベンチマーキングBGP装置集合のための用語」、RFC4098(2005年6月)。
[RFC4116] Abley, J., Lindqvist, K., Davies, E., Black, B., and V.
Gill, "IPv4 Multihoming Practices and Limitations",
RFC 4116, July 2005.
エラと、[RFC4116] Abley、J.、リンクヴィスト、K.、デイヴィース、E.、黒、B.、およびRFC4116、2005年7月対「IPv4マルチホーミング習慣と制限」
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day",
RFC 4192, September 2005.
[RFC4192] ベイカー、F.、リア、E.、およびR.Droms、「国旗制定記念日なしでIPv6ネットワークに番号を付け替えさせるための手順」、RFC4192(2005年9月)。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.
[RFC4632] フラーとV.とT.李、「以下を掘る(CIDR)階級のない相互ドメイン」 「インターネットアドレス課題と集合は計画している」BCP122、RFC4632、2006年8月。
[IDR-REQS] Doria, A. and E. Davies, "Analysis of IDR requirements
and History", Work in Progress, February 2007.
[IDR-REQS] ドーリアとA.とE.デイヴィース、「IDR要件と歴史の分析」、Progress、2007年2月のWork。
[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.、「IPv4は熟しているNCCサービス領域に配分と課題方針を記述する」熟している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] オデル、M.、「IPv6"のための交互のアドレッシング体系、処理中の作業、GSE--1997。」
[dGSE] Zhang, L., "An Overview of Multihoming and Open Issues
in GSE", IETF Journal, http://www.isoc.org/tools/blogs/
ietfjournal/?p=98#more-98, 2006.
[dGSE] チャン、L.、「GSEのマルチホーミングと未解決の問題の概観」、IETF Journal、 http://www.isoc.org/tools/blogs/ ietfjournal/--p=98 98、#より多くの2006。
[PathExp] Oliveira, R. and et. al., "Quantifying Path Exploration
in the Internet", Internet Measurement Conference (IMC)
2006, http://www.cs.ucla.edu/~rveloso/papers/
imc175f-oliveira.pdf.
[PathExp]オリベイラ、R.、およびetアル、「経路探検を定量化する、インターネット、」、インターネットMeasurementコンファレンス(IMC)2006、 http://www.cs.ucla.edu/~rveloso/papers/ imc175f-oliveira.pdf。
Meyer, et al. Informational [Page 32] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[32ページ]のRFC4984IABワークショップ
[DynPrefix] Oliveira, R. and et. al., "Measurement of Highly Active
Prefixes in BGP", IEEE GLOBECOM 2005
http://www.cs.ucla.edu/~rveloso/papers/activity.pdf.
[DynPrefix]オリベイラ、R.、およびetアル、「BGPでの非常にアクティブな接頭語の測定」、IEEE GLOBECOM2005 http://www.cs.ucla.edu/~rveloso/papers/activity.pdf 。
[BHB06] Boothe, P., Hielbert, J., and R. Bush, "Short-Lived
Prefix Hijacking on the Internet", NANOG 36
http://www.nanog.org/mtg-0602/pdf/boothe.pdf, 2006.
[BHB06]ブースとP.とHielbert、J.とR.ブッシュ、「インターネットの短命な接頭語ハイジャック」NANOG36 http://www.nanog.org/mtg-0602/pdf/boothe.pdf 、2006。
[ROFL] Caesar, M. and et. al., "ROFL: Routing on Flat Labels",
SIGCOMM 2006, http://www.sigcomm.org/sigcomm2006/
discussion/showpaper.php?paper_id=34, 2006.
[ROFL]シーザー、M.、およびetアル、「ROFL:」 「Flat Labelsにおけるルート設定」、SIGCOMM2006、 http://www.sigcomm.org/sigcomm2006/ 議論/showpaper.php--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アルParallel AlgorithmsとArchitectures、 http://citeseer.ist.psu.edu/710757.html の上の「コンパクトな名前無党派は最小の伸びで掘る」ACM Symposium、2004。
[BGT04] Bu, T., Gao, L., and D. Towsley, "On Characterizing BGP
Routing Table Growth", J. Computer and Telecomm
Networking V45N1, 2004.
[BGT04] BuとT.とカオ、L.とD.Towsleyと「BGP経路指定テーブルの成長を特徴付け」て、J.コンピュータとTelecommネットワークV45N1、2004
[Fuller] Fuller, V., "Scaling issues with ipv6 routing+
multihoming", http://www.iab.org/about/workshops/
routingandaddressing/vaf-iab-raws.pdf, 2006.
V. [よりふくよか]のフラー、 http://www.iab.org/about/workshops/ routingandaddressing/vaf-iab-raws.pdf、「ipv6ルーティング+マルチホーミングの問題をスケーリングすること」での2006。
[H03] Huston, G., "Analyzing the Internet's BGP Routing
Table", http://www.potaroo.net/papers/ipj/
2001-v4-n1-bgp/bgp.pdf, 2003.
G. [H03]ヒューストン、 http://www.potaroo.net/papers/ipj/ 2001-v4-n1-bgp/bgp.pdf、「インターネットのBGP経路指定テーブルを分析すること」での2003。
[BGP2005] Huston, G., "2005 -- A BGP Year in Review", http://
www.apnic.net/meetings/21/docs/sigs/routing/
routing-pres-huston-routing-update.pdf.
[BGP2005]ヒューストン、G.、http://www.apnic.net/ミーティング/21/docs/sigs/は/ルーティングpres-hustonルーティングupdate.pdfを発送して「2005--BGP年は中で回顧する」。
[DFZ] Huston, G., "Growth of the BGP Table - 1994 to Present",
http://bgp.potaroo.net, 2006.
[DFZ] ヒューストン、G.、「提示するBGPテーブルの成長--1994」、 http://bgp.potaroo.net 、2006。
[GIH] Huston, G., "Wither Routing?",
http://www.potaroo.net/ispcol/2006-11/raw.html, 2006.
[GIH] ヒューストン、G.、「ルート設定?萎ませてください」、 http://www.potaroo.net/ispcol/2006-11/raw.html 、2006。
[ATNAC2006] Huston, G. and G. Armitage, "Projecting Future IPv4
Router Requirements from Trends in Dynamic BGP
Behaviour", http://www.potaroo.net/papers/phd/
atnac-2006/bgp-atnac2006.pdf, 2006.
[ATNAC2006] ヒューストンとG.とG.アーミテージ、「ダイナミックなBGPのふるまいにおける傾向からの映し出している将来のIPv4ルータ要件」、 http://www.potaroo.net/papers/phd/ atnac-2006/bgp-atnac2006.pdf、2006
[CIDRRPT] "The CIDR Report", http://www.cidr-report.org.
[CIDRRPT] 「CIDRレポート」、 http://www.cidr-report.org 。
Meyer, et al. Informational [Page 33] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[33ページ]のRFC4984IABワークショップ
[ML] "Moore's Law",
Wikipedia http://en.wikipedia.org/wiki/Moore's_law,
2006.
[ミリリットル] 「ムーアの法則」、ウィキぺディア http://en.wikipedia.org/wiki/Moore の_法、2006。
[Molinero] Molinero-Fernandez, P., "Technology trends in routers
and switches", PhD thesis, Stanford University http://
klamath.stanford.edu/~molinero/thesis/html/
pmf_thesis_node5.html, 2005.
[Molinero]Molinero-フェルナンデス、P.、「ルータとスイッチの技術動向」、博士論文、スタンフォード大学http://klamath.stanford.edu/~molinero/論文/html/pmf_論文_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.、「ドラムの生産性と容量/要求はモデル化する」Global Economic Workshop http://www.sematech.org/ミーティング/アーカイブ/GES/19990514/docs/07_econ.pdf、1999
Meyer, et al. Informational [Page 34] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[34ページ]のRFC4984IABワークショップ
Appendix A. Suggestions for Specific Steps
特定のステップのための付録A.提案
At the end of the workshop there was a lively round-table discussion regarding specific steps that IETF may consider undertaking towards a quick solution development, as well as potential issues to avoid. Those steps included:
ワークショップの端のときに、IETFが、迅速な解決策開発、および潜在的問題に向かった仕事が避けると考えるかもしれない特定のステップに関して活気がある討論会がありました。 それらのステップは:だった
o Finding a home (mailing list) to continue the discussion started
from the workshop with wider participation. [Editor's note: Done
-- This action has been completed. The list is ram@iab.org.]
o 議論を続けるために家(メーリングリスト)を見つけると、ワークショップは、より広い参加で始まりました。 [編集者注: しました--この操作は完了しました。 リストは ram@iab.org です。]
o Considering a special process to expedite solution development,
avoiding the lengthy protocol standardization cycles. For
example, IESG may charter special design teams for the solution
investigation.
o 特殊処理が解決策開発を速めると考える場合、長いプロトコル標準化を避けるのは循環します。 例えば、IESGは解決策調査のために特別なデザインチームをチャーターするかもしれません。
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が属すはずであるどの領域であったか。 ルーティング領域ADsとインターネット領域ADsの両方が、それを接待しても構わないと思っています。
o It is desirable that the solutions be developed in an open
environment and free from any Intellectual Property Right claims.
o 解決策には、オープンな環境で開発されてどんなIntellectual Property Rightクレームもないのは、望ましいです。
Finally, given the perceived severity of the problem at hand, the workshop participants trust that IAB/IESG/IETF will take prompt actions. However, if that were not to happen, operators and vendors would be most likely to act on their own and get a solution deployed.
最終的に、当面の問題の知覚された厳しさを考えて、講習会参加者は、IAB/IESG/IETFが迅速な行動を取ると信じます。 業者は、しかしながら、それがそうしないつもりであったならオペレータが起こって、それら自身のに影響し、解決策を最も配備させそうでしょう。
Appendix B. Workshop Participants
付録B.講習会参加者
Loa Anderson (IAB) Jari Arkko (IESG) Ron Bonica Ross Callon (IESG) Brian Carpenter (IAB) David Conrad (IANA) Leslie Daigle (IAB Chair) Elwyn Davies (IAB) Terry Davis Weisi Dong Aaron Falk (IRTF Chair) Kevin Fall (IAB) Dino Farinacci Vince Fuller Vijay Gill
Loaアンダーソン(IAB)ヤリArkko(IESG)ロンBonicaロスCallon(IESG)ブライアン大工の(IAB)デヴィッド・コンラッド(IANA)レスリー・Daigle(IAB議長)Elwynデイヴィース(IAB)・Terryデイヴィス・Weisiドングアーロン・フォーク(IRTF議長)ケビンFall(IAB)恐竜ファリナッチビンスフラービジェイエラ
Meyer, et al. Informational [Page 35] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[35ページ]のRFC4984IABワークショップ
Russ Housley (IESG) Geoff Huston Daniel Karrenberg Dorian Kim Olaf Kolkman (IAB) Darrel Lewis Tony Li Kurtis Lindqvist (IAB) Peter Lothberg David Meyer (IAB) Christopher Morrow Dave Oran (IAB) Phil Roberts (IAB Executive Director) Jason Schiller Peter Schoenmaker Ted Seely Mark Townsley (IESG) Iljitsch van Beijnum Ruediger Volk Magnus Westerlund (IESG) Lixia Zhang (IAB)
ラスHousley(IESG)ジェフヒューストンダニエルKarrenbergドリアンキムオラフKolkman(IAB)ダレル・ルイス・トニー・李・カーティス・リンクヴィスト(IAB)・ピーター・Lothbergデヴィッド・マイヤー(IAB)・クリストファー・モロー・デーヴ・オラン(IAB)・フィル・ロバーツ(IAB事務局長)ジェイソンシラーピーターSchoenmakerテッドシーリマークTownsley(IESG)IljitschバンBeijnumルーディガーVolkマグヌスWesterlund(IESG)Lixiaチャン(IAB)
Appendix C. Workshop Agenda
付録C.ワークショップ議題
IAB Routing and Addressing Workshop Agenda
October 18-19
Amsterdam, Netherlands
IABルート設定とワークショップ議題October 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日目: 提案された目標は集まることです、できるだけ完全です、ルーティングと領域を記述することにおける、1セットのスケーラビリティ問題が今日インターネットに直面していて。
0815-0900: Welcome, framing up for the 2 days
Moderator: Leslie Daigle
0815-0900: ようこそ、2日間Moderatorの書く準備をします: レスリー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: 前場Moderator: 前場のためのElwynデイヴィースStrawman話題: - スケーラビリティ--マルチホーミングサポート--交通Engineering--ルート設定Table Size: 成長率(Dynamics(これはDFZに制限されないで、iBGPを含めてください)(成長の原因))は成長から痛みます(恐らく、「ルータへの影響」はここに来ることができますか?)。 - BGPの遅い集合はどれくらい大きい問題ですか?
Meyer, et al. Informational [Page 36] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[36ページ]のRFC4984IABワークショップ
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つの最高ルーティング問題が何ですか? 議長: カート・エリック・リンクヴィスト
1500-1530: Coffee Break
1500-1530: コーヒー中断
Dinner at Indrapura (http://www.indrapura.nl), sponsored by Cisco
シスコによって後援されたIndrapura( http://www.indrapura.nl )の夕食
--------- DAY 2: The proposed goal is to formulate a problem statement
--------- 2日目: 提案された目標は問題声明を定式化することです。
0800-0830: Welcome
0800-0830: 歓迎
0830-1000: Morning session: What's on the table
Moderator: Elwyn Davies
- shim6
- GSE
0830-1000: 前場: 放送内容、テーブルModerator: Elwynデイヴィース--shim6--GSE
1000-1030: Coffee Break
1000-1030: コーヒー中断
1030-1200: Problem Statement session #1: document the problems
Moderator: David Meyer
1030-1200: 問題Statementセッション#1: 問題Moderatorを記録してください: デヴィッド・マイヤー
1200-1300: Lunch
1200-1300: 昼食
1300-1500: Problem Statement session # 2, cont;
Moderator: Dino Farinacci
- Constraints on solutions
1300-1500: 問題Statementセッション#2、cont。 議長: ディーノ・ファリナッチ--解決策における規制
1500-1530: Coffee Break
1500-1530: コーヒー中断
1530-1730: Summary and Wrap-up
Moderator: Leslie Daigle
1530-1730: 概要と結論議長: レスリーDaigle
Appendix D. Presentations
付録D.プレゼンテーション
The presentations from the workshop can be found on
ワークショップからのプレゼンテーションがオンであることがわかることができます。
http://www.iab.org/about/workshops/routingandaddressing
http://www.iab.org/about/workshops/routingandaddressing
Meyer, et al. Informational [Page 37] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[37ページ]のRFC4984IABワークショップ
Authors' Addresses
作者のアドレス
David Meyer (editor)
デヴィッド・マイヤー(エディタ)
EMail: dmm@1-4-5.net
メール: dmm@1-4-5.net
Lixia Zhang (editor)
Lixiaチャン(エディタ)
EMail: lixia@cs.ucla.edu
メール: lixia@cs.ucla.edu
Kevin Fall (editor)
ケビンFall(エディタ)
EMail: kfall@intel.com
メール: kfall@intel.com
Meyer, et al. Informational [Page 38] RFC 4984 IAB Workshop on Routing & Addressing September 2007
マイヤー、他 ルート設定と2007年9月を記述することに関する情報[38ページ]のRFC4984IABワークショップ
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を記述してください。
Meyer, et al. Informational [Page 39]
マイヤー、他 情報[39ページ]
一覧
スポンサーリンク
