[要約] RFC 6227は、スケーラブルなインターネットルーティングの設計目標を提案している。その目的は、インターネットの成長に対応し、効率的で持続可能なルーティングアーキテクチャを確立することである。
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.
このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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'.
このドキュメントの各設計目標には、「必須」、「強く望まれている」、または「望ましい」、または「必須」の1つである優先事項が割り当てられています。
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つとして提案されています。両方の問題の解決策、つまり（1）ホストの位置と識別情報の分離、および（2）スケーラブルなグローバルルーティングシステム（ソリューションは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アドレスを識別子として使用して、これらのプロトコルの既存のトランスポートまたは高レベルの接続を破壊する可能性があるため、最初のアプローチのみは不十分であると考えられています。2つ目は、モバイルエンティティの現在の場所を追跡するために「ホームエージェント」の展開を必要とし、関係するルーターにオーバーヘッドを追加し、インバウンドパケットのパスにストレッチを追加します。最初の2つのアプローチのどちらも、ルーティングのスケーラビリティに影響を与えません。ただし、3番目のアプローチでは、モバイルエンティティが移動する際に動的な更新をグローバルルーティングシステムに注入します。より効率的でスケーラブルなモビリティサポートを提供するのに役立つメカニズムは、特にセキュリティ（特にプライバシー）と結び付けられ、トポロジカルの変化を高いレートでサポートできる場合に望まれます。理想的には、そのようなメカニズムはルーティングからモビリティを完全に切り離す必要があります。
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] Carpenter、B.、ed。、「インターネットの建築原理」、RFC 1958、1996年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Baker、F.、Lear、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] Meyer、D.、ed。、Zhang、L.、ed。、およびK. Fall、ed。、「ルーティングとアドレス指定に関するIABワークショップからの報告」、RFC 4984、2007年9月。
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010.
[RFC5887] Carpenter、B.、Atkinson、R。、およびH. Flinck、「Nemumberingまだ仕事が必要」、RFC 5887、2010年5月。
[BGPGrowth] Huston, G., "BGP Routing Table Analysis Reports", <http://bgp.potaroo.net/>.
[BGPGROWTH] Huston、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] Bennett、C.、Edge、S。、およびA. Hinchley、「データグラムネットワークの相互接続の問題」、インターネット実験ノート（IEN）1、Indra Note 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] Peleg、D。およびE. Upfal、「ルーティングテーブルのスペースと効率のトレードオフ」、Journal of the ACM Volume 36、Issue 3、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
Tony Li（編集者）Cisco Systems、Inc。170 W. Tasman Dr. San Jose、CA 95134 USA
Phone: +1 408 853 9317
EMail: tli@cisco.com