Internet Research Task Force (IRTF) T. Li, Ed.
Request for Comments: 6227 Cisco Systems, Inc.
Category: Informational May 2011
ISSN: 2070-1721
Design Goals for Scalable Internet Routing
Abstract
抽象
It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, mobility, multi-homing, and inter-domain traffic engineering. The Routing Research Group is investigating an alternate architecture to meet these challenges. This document consists of a prioritized list of design goals for the target architecture.
一般的にインターネットルーティングとアドレス体系は、スケーラビリティ、モビリティ、マルチホーミング、およびドメイン間のトラフィックエンジニアリングにおける課題に直面していることが認識されています。ルーティング研究グループは、これらの課題を満たすために別のアーキテクチャを調査しています。この文書では、ターゲットアーキテクチャの設計目標の優先順位リストで構成されています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Routing Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書はインターネットResearch Task Force（IRTF）の製品です。 IRTFはインターネット関連の研究開発活動の成果を公表しています。これらの結果は、展開に適していない可能性があります。このRFCはインターネットResearch Task Force（IRTF）のルーティング研究グループのコンセンサスを表しています。 IRSGによって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6227.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6227で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
1.2. Priorities .................................................3
2. General Design Goals Collected from the Past ....................3
3. Design Goals for a New Routing Architecture .....................3
3.1. Improved Routing Scalability ...............................3
3.2. Scalable Support for Traffic Engineering ...................4
3.3. Scalable Support for Multi-Homing ..........................4
3.4. Decoupling Location and Identification .....................4
3.5. Scalable Support for Mobility ..............................5
3.6. Simplified Renumbering .....................................5
3.7. Modularity, Composability, and Seamlessness ................6
3.8. Routing Quality ............................................6
3.9. Routing Security ...........................................7
3.10. Deployability .............................................7
3.11. Summary of Priorities .....................................7
4. Security Considerations .........................................7
5. References ......................................................8
5.1. Normative References .......................................8
5.2. Informative References .....................................8
It is commonly recognized that the Internet routing and addressing architecture is facing challenges in inter-domain scalability, mobility, multi-homing, and inter-domain traffic engineering [RFC4984]. The Routing Research Group (RRG) aims to design an alternate architecture to meet these challenges. This document presents a prioritized list of design goals for the target architecture.
一般的にインターネットルーティングとアドレス体系は、ドメイン間のスケーラビリティ、モビリティ、マルチホーミング、およびドメイン間のトラフィックエンジニアリング[RFC4984]で課題に直面していることが認識されています。ルーティング研究グループ（RRG）は、これらの課題に対応するために、代替のアーキテクチャを設計することを目指しています。この文書では、ターゲットアーキテクチャの設計目標の優先順位リストを提示します。
These goals should be taken as guidelines for the design and evaluation of possible architectural solutions. The expectation is that these goals will be applied with good judgment.
これらの目標は、可能な建築ソリューションの設計と評価のためのガイドラインとして取られるべきです。期待は、これらの目標は、適切な判断で適用されるということです。
The goals presented here were initially presented and discussed at the start of the RRG work on a revised routing architecture, and were revisited and finalized after the work on that architecture was complete. As such, this represents both the goals that the RRG started with, and revisions to those goals based on our increased understanding of the space.
ここで紹介する目標は、当初提示し、議論改訂ルーティングアーキテクチャ上のRRG作業の開始時に、そのアーキテクチャ上の作業が完了した後に再訪して確定されたました。そのため、これはRRGは、使用を開始することを目標に、そして宇宙の私達の増加の理解に基づいて、これらの目標の見直しの両方を表します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
Each design goal in this document has been assigned a priority, which is one of the following: 'required', 'strongly desired', or 'desired'.
「必要な」「強く希望」、または「希望」：この文書の各設計目標は、次のいずれかで優先順位を、割り当てられています。
Required: The solution is REQUIRED to support this goal.
必須：ソリューションは、この目標をサポートするために必要です。
Strongly desired: The solution SHOULD support this goal, unless there exist compelling reasons showing that it is unachievable, extremely inefficient, or impractical.
強く希望：それは、実現不可能非常に非効率的、または非現実的であることを示す説得力のある理由が存在しない限り、解決策は、この目標をサポートする必要があります。
Desired: The solution SHOULD support this goal.
希望：解決策は、この目標をサポートする必要があります。
[RFC1958] provides a list of the original architectural principles of the Internet. We incorporate them here by reference, as part of our desired design goals.
[RFC1958]はインターネットのオリジナルの建築原理のリストを提供します。私たちは、所望の設計目標の一環として、参照することによりここに組み入れます。
Long experience with inter-domain routing has shown that the global BGP routing table is continuing to grow rapidly [BGPGrowth]. Carrying this large amount of state in the inter-domain routing protocols is expensive and places undue cost burdens on network participants that do not necessarily get value from the increases in the routing table size. Thus, the first required goal is to provide significant improvement to the scalability of the inter-domain routing subsystem. It is strongly desired to make the routing subsystem scale independently from the growth of the Internet user population. If there is a coupling between the size of the user base and the scale of the routing subsystem, then it will be very difficult to retain any semblance of scalability. If a solution includes support for alternative routes to support faster convergence, the alternative routes should also factor into routing subsystem scalability.
ドメイン間ルーティングとの長年の経験は、グローバルBGPルーティングテーブルが急速に[BGPGrowth]成長を続けていることが示されています。ドメイン間ルーティングプロトコル状態のこの大規模な量を運ぶことは高価であり、必ずしもルーティングテーブルサイズの増加から値を取得していないネットワークの参加者に過度のコスト負担を配置します。このように、最初に必要な目標は、ドメイン間ルーティングサブシステムの拡張性に有意な改善を提供することです。強く、インターネットユーザー人口の増加とは独立したルーティング・サブシステムのスケールを作ることが望まれます。ユーザーベースのサイズ及びルーティングサブシステムの規模との間の結合が存在する場合、スケーラビリティの任意のうわべだけを保持することは非常に困難であろう。溶液が代替ルートがより速い収束をサポートするためのサポートが含まれている場合、代替ルートは、ルーティングサブシステムのスケーラビリティに考慮すべきです。
Traffic engineering is the capability of directing traffic along paths other than those that would be computed by normal IGP/EGP routing. Inter-domain traffic engineering today is frequently accomplished by injecting more-specific prefixes into the global routing table, which results in a negative impact on routing scalability. The additional prefixes injected to enable traffic engineering place an added burden on the scalability of the routing architecture. At the same time, the need for traffic engineering capabilities is essential to network operations. Thus, a scalable solution for inter-domain traffic engineering is strongly desired.
トラフィックエンジニアリングは、通常のIGP / EGPルーティングによって計算されるもの以外の経路に沿ってトラフィックを導く能力です。ドメイン間のトラフィックエンジニアリング今日は、頻繁にスケーラビリティをルーティングへの悪影響につながるグローバルルーティングテーブルへより多くの固有の接頭辞を注入することによって達成されます。追加のプレフィックスは、ルーティングアーキテクチャのスケーラビリティに追加負担トラフィックエンジニアリング場所を有効にするために注入しました。同時に、トラフィックエンジニアリング機能の必要性は、ネットワークの運用に不可欠です。このように、ドメイン間のトラフィックエンジニアリングのためのスケーラブルなソリューションが強く望まれています。
Multi-homing is the capability of an organization to be connected to the Internet via more than one other organization. The current mechanism for supporting multi-homing is to let the organization advertise one prefix or multiple prefixes into the global routing system, again resulting in a negative impact on routing scalability. More scalable solutions for multi-homing are strongly desired.
マルチホーミングは、複数の他の組織を介してインターネットに接続するための組織の機能です。マルチホーミングを支援するための現在の機構は、組織が再びスケーラビリティルーティングに負の影響をもたらす、グローバルルーティングシステムに1つのプレフィックス又は複数のプレフィックスを通知させることです。マルチホーミングのためのよりスケーラブルなソリューションが強く望まれています。
Numerous sources have noted that an IP address embodies both host attachment point information and identification information [IEN1]. This overloading has caused numerous semantic collisions that have limited the flexibility of the Internet architecture. Therefore, it is desired that a solution separate the host location information namespace from the identification namespace.
多数のソースIPアドレスが[IEN1】ホストアタッチメントポイント情報と識別情報の両方を具現することを指摘しています。このオーバーロードは、インターネットアーキテクチャの柔軟性が限られている数多くのセマンティック衝突を起こしています。したがって、溶液は、識別ネームスペースからホスト位置情報名前空間を分離することが望ましいです。
Caution must be taken here to clearly distinguish the decoupling of host location and identification information, and the decoupling of end-site addresses from globally routable prefixes; the latter has been proposed as one of the approaches to a scalable routing architecture. Solutions to both problems, i.e., (1) the decoupling of host location and identification information and (2) a scalable global routing system (whose solution may, or may not, depend on the second decoupling) are required, and it is required that their solutions are compatible with each other.
注意は明らかにホストの場所と識別情報とのデカップリング、およびグローバルにルーティング可能なプレフィックスからのエンドサイトアドレスのデカップリングを区別するために、ここで注意する必要があります。後者は、スケーラブルなルーティングアーキテクチャに対するアプローチの一つとして提案されています。両方の問題に対する解決策は、すなわち、（1）ホストの場所と識別情報と（その溶液、又はず、第二のデカップリングに依存してもよい）、（2）スケーラブルなグローバルルーティングシステムのデカップリングが必要である、とのことが要求されますその解決策は、相互に互換性があります。
Mobility is the capability of a host, network, or organization to change its topological connectivity with respect to the remainder of the Internet, while continuing to receive packets from the Internet. Existing mechanisms to provide mobility support include
モビリティは、インターネットからパケットを受信し続けながら、インターネットの残りの部分に対して、そのトポロジー接続を変更するホスト、ネットワーク、または組織の能力です。モビリティサポートを提供するために、既存のメカニズムは、
1. renumbering the mobile entity as it changes its topological attachment point(s) to the Internet;
それはインターネットへのトポロジー接続ポイント（複数可）を変更するように1移動エンティティをリナンバリング。
2. renumbering and creating a tunnel from the entity's new topological location back to its original location; and
2.リナンバリングと元の場所へのエンティティの新しいトポロジー的位置からトンネルを作成します。そして
3. letting the mobile entity announce its prefixes from its new attachment point(s).
3.モバイルエンティティがその新しいアタッチメントポイント（複数可）からそのプレフィックスを発表させます。
The first approach alone is considered unsatisfactory, as the change of IP address may break existing transport or higher-level connections for those protocols using IP addresses as identifiers. The second requires the deployment of a 'home agent' to keep track of the mobile entity's current location and adds overhead to the routers involved, as well as adding stretch to the path of an inbound packet. Neither of the first two approaches impacts the routing scalability. The third approach, however, injects dynamic updates into the global routing system as the mobile entity moves. Mechanisms that help to provide more efficient and scalable mobility support are desired, especially when they can be coupled with security -- especially privacy -- and support topological changes at a high rate. Ideally, such mechanisms should completely decouple mobility from routing.
IPアドレスの変更が識別子としてIPアドレスを使用して、これらのプロトコルのための既存のトランスポートまたはより高いレベルの接続を破ることとして単独で最初のアプローチは、不満足なものと考えられています。二つ目は、モバイルエンティティの現在の位置を追跡するために「ホーム・エージェント」の導入を必要とし、インバウンドパケットのパスにストレッチを追加するだけでなく、関連するルータにオーバーヘッドが追加されます。最初の二つのアプローチの影響ルーティングのスケーラビリティのいずれ。第三のアプローチは、しかし、移動体の移動に伴って、グローバルルーティングシステムに動的更新を注入します。特にプライバシーを - - と高い割合でトポロジの変更をサポートし、より効率的でスケーラブルなモビリティサポートを提供するのに役立つメカニズムは、それらが、セキュリティと結合することができる場合は特に、望まれています。理想的には、そのようなメカニズムは、完全にルーティングからモビリティを分離すべきです。
Today, many of the end-sites receive their IP address assignments from their Internet Service Providers (ISPs). When such a site changes providers, for routing to scale, the site must renumber into a new address block assigned by its new ISP. This can be costly, error-prone, and painful [RFC5887]. Automated tools, once developed, are expected to provide significant help in reducing the renumbering pain. It is not expected that renumbering will be wholly automated, as some manual reconfiguration is likely to be necessary for changing the last-mile link. However, the overall cost of renumbering should be drastically lowered.
今日では、エンドサイトの多くは、彼らのインターネットサービスプロバイダ（ISP）から自分のIPアドレスの割り当てを受けます。そのようなサイトは、プロバイダを変更すると、スケールにルーティングするために、サイトには、その新しいISPから割り当てられた新しいアドレスブロックに番号を付け直す必要があります。これは、エラーを起こしやすい、と痛い[RFC5887]高価であることができます。一度開発した自動化ツールは、リナンバリングの痛みを減らすのに重要な支援を提供することが期待されています。いくつかの手動再構成がラストマイルリンクを変更するために必要である可能性が高いとしてリナンバリングは完全に自動化されることが予想されていません。しかし、リナンバリングの全体的なコストを大幅に下げるべきです。
In addition to being configured into hosts and routers, where automated renumbering tools can help, IP addresses are also 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 could be catastrophic (e.g., certain remote monitoring applications). Although renumbering may be considered 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. It is strongly desired that a new architecture allow end-sites to renumber their network with significantly less disruption, or, if renumbering can be eliminated, the new architecture must demonstrate how the topology can be economically morphed to fit the addressing.
自動化されたリナンバリングツールは助けることができるホストとルータ、内に構成されることに加えて、IPアドレスも、多くの場合、アクセス制御リストなど、他の目的に使用されています。彼らは、（例えば、特定の遠隔監視アプリケーション）時にはDNSの障害が致命的かもしれない環境で使用されるアプリケーションにハードコーディングされています。リナンバリングは、いくつかのサイトのための穏やかな不便と考えることができる、とガイドラインはフラグ日[RFC4192]せずにネットワークを再番号付けのために開発されているが効果的に不可能リナンバリングになるように、他人のために、必要な変更は十分に困難です。強く、新しいアーキテクチャは、エンドサイトが大幅に少ない混乱してネットワークを再番号付けするために、または、リナンバリングをなくすことができるならば、新しいアーキテクチャは、トポロジが経済的に対処するにフィットするようにモーフィングする方法を実証しなければなら許すことが望ましいです。
A new routing architecture should be modular: it should subdivide into multiple composable, extensible, and orthogonal subsystems. The interfaces between modules should be natural and seamless, without special cases or restrictions. Similarly, the primitives and abstractions in the architecture should be suitably general, with operations equally applicable to abstractions and concrete entities, and without deleterious side-effects that might hinder communication between endpoints in the Internet. These properties are strongly desired in a solution.
新しいルーティングアーキテクチャはモジュラーであるべきである：これは、複数の構成可能、拡張可能、及び直交サブシステムに分割すべきです。モジュール間のインタフェースは、特殊なケースや制限なしで、自然とシームレスにする必要があります。同様に、アーキテクチャのプリミティブと抽象化は、抽象化と具体的エンティティにも同様に適用操作で、およびインターネットにおいてエンドポイント間の通信を妨げる可能性がある有害な副作用なしに、適切に一般的であるべきです。これらの性質が強く溶液中で望まれています。
As an example, if tunneling were used as a part of a solution, tunneling should be completely transparent to both of the endpoints, without requiring new mechanisms for determining the correct maximum datagram size.
トンネリングは、ソリューションの一部として使用された場合、一例として、トンネリングが正しい最大データグラムサイズを決定するための新たな機構を必要とせず、エンドポイントの両方に対して完全に透明であるべきです。
The resulting network should always fully approximate the current best-effort Internet connectivity model, and it should also anticipate changes to that model, e.g., for multiple differentiated and/or guaranteed levels of service in the future.
その結果、ネットワークは常に完全に現在のベストエフォート型のインターネット接続モデルを近似する必要があり、それが将来的にサービスの複数の分化および/または保証レベルのために、例えば、そのモデルへの変更をも予想しなければなりません。
The routing subsystem is responsible for computing a path from any point in the Internet to any other point in the Internet. The quality of the routes that are computed can be measured by a number of metrics, such as convergence, stability, and stretch.
ルーティングサブシステムは、インターネット内の他のポイントにインターネット内の任意の点からの経路を計算するための責任があります。計算される経路の品質は、収束性、安定性、および伸びのようなメトリクスの数によって測定することができます。
The stretch factor is the maximum ratio between the length of a route computed by the routing scheme and that of a shortest path connecting the same pair of nodes [JACM89].
伸長因子は、ルーティング方式と[JACM89]ノードの同じペアを結ぶ最短経路とによって計算経路の長さとの間の最大比です。
A solution is strongly desired to provide routing quality equivalent to what is available today, or better.
溶液は強く、今日、またはより良い利用可能なものに品質と同等のルーティングを提供することが望まれています。
Currently, the routing subsystem is secured through a number of protocol-specific mechanisms of varying strength and applicability. Any new architecture is required to provide at least the same level of security as is deployed as of when the new architecture is deployed.
現在、ルーティングサブシステムは、様々な強度および適用のプロトコル固有の多くの機構を介して固定されています。すべての新しいアーキテクチャは、新しいアーキテクチャが展開されたときのように展開されるよう、セキュリティの少なくとも同じレベルを提供するために必要とされます。
A viable solution is required to be deployable from a technical perspective. Furthermore, given the extensive deployed base of today's Internet, a solution is required to be incrementally deployable. This implies that a solution must continue to support those functions in today's routing subsystem that are actually used. This includes, but is not limited to, the ability to control routing based on policy.
実行可能な解決策は、技術的な観点から展開可能であることが必要です。さらに、今日のインターネットの広範な展開ベース与えられ、溶液は、増分展開可能であることが必要です。これは解決策が実際に使用されている今日のルーティングサブシステムでこれらの機能をサポートし続けなければならないことを意味します。これには、ポリシーに基づいてルーティングを制御する能力が、これらに限定されません。
The following table summarizes the priorities of the design goals discussed above.
次の表は、上述の設計目標の優先順位をまとめました。
+------------------------+------------------+
| Design goal | Priority |
+------------------------+------------------+
| Scalability | Strongly desired |
| Traffic engineering | Strongly desired |
| Multi-homing | Strongly desired |
| Loc/id separation | Desired |
| Mobility | Desired |
| Simplified renumbering | Strongly desired |
| Modularity | Strongly desired |
| Routing quality | Strongly desired |
| Routing security | Required |
| Deployability | Required |
+------------------------+------------------+
All solutions are required to provide security that is at least as strong as the existing Internet routing and addressing architecture. This document does not suggest any default architecture or protocol, and thus this document introduces no new security issues.
すべてのソリューションは、既存のインターネットルーティングとアドレス体系と少なくとも同じくらい強いセキュリティを提供するために必要とされています。このドキュメントは、任意のデフォルトのアーキテクチャやプロトコルを示唆していないので、この文書には、新たなセキュリティ問題を紹介しません。
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]大工、B.、エド。、 "インターネットの建築原則"、RFC 1958、1996年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]ベイカー、F.、リア、E.、およびR. Droms、 "国旗の日なしでIPv6ネットワークを再番号付けのための手順"、RFC 4192、2005年9月。
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007.
[RFC4984]マイヤー、D.、エド。、チャン、L.、エド。、およびK.秋、エド。、 "ルーティングとアドレッシングのIABワークショップからの報告書"、RFC 4984、2007年9月。
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010.
[RFC5887]大工、B.、アトキンソン、R.、およびH.フリンクは、RFC 5887、2010年5月、 "リナンバリングはまだ作業が必要"。
[BGPGrowth] Huston, G., "BGP Routing Table Analysis Reports", <http://bgp.potaroo.net/>.
【BGPGrowth]ヒューストン、G.、 "BGPルーティングテーブル分析レポート"、<http://bgp.potaroo.net/>。
[IEN1] Bennett, C., Edge, S., and A. Hinchley, "Issues in the Interconnection of Datagram Networks", Internet Experiment Note (IEN) 1, INDRA Note 637, PSPWN 76, July 1977, <http://www.postel.org/ien/pdf/ien001.pdf>.
[IEN1]ベネット、C.、エッジ、S.、およびA. Hinchley、 "データグラムネットワークの相互接続での問題"、インターネット実験ノート（IEN）1、INDRA注637、PSPWN 76、1977年7月、<のhttp：/ /www.postel.org/ien/pdf/ien001.pdf>。
[JACM89] Peleg, D. and E. Upfal, "A trade-off between space and efficiency for routing tables", Journal of the ACM Volume 36, Issue 3, July 1989, <http://portal.acm.org/citation.cfm?id=65953>.
【JACM89]ペレグ、D.およびE. Upfal、「ルーティングテーブルのためのスペースと効率とのトレードオフ」、ACMボリューム36のジャーナル、3号、1989年7月、<http://portal.acm.org/ citation.cfm？ID = 65953>。
Author's Address
著者のアドレス
Tony Li (editor) Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA
トニー・リー（編集者）は、Cisco Systems、Inc.の170 W.タスマン博士はカリフォルニア州サンノゼ95134 USA
Phone: +1 408 853 9317 EMail: tli@cisco.com
電話：+1 408 853 9317 Eメール：tli@cisco.com