[要約] RFC 6115は、ルーティングアーキテクチャに関する推奨事項を提供するものであり、インターネットのスケーラビリティとパフォーマンスの向上を目的としています。
Internet Research Task Force (IRTF) T. Li, Ed.
Request for Comments: 6115 Cisco Systems
Category: Informational February 2011
ISSN: 2070-1721
Recommendation for a Routing Architecture
ルーティングアーキテクチャの推奨
Abstract
概要
It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multihoming, and inter-domain traffic engineering. This document presents, as a recommendation of future directions for the IETF, solutions that could aid the future scalability of the Internet. To this end, this document surveys many of the proposals that were brought forward for discussion in this activity, as well as some of the subsequent analysis and the architectural recommendation of the chairs. This document is a product of the Routing Research Group.
インターネットのルーティングとアドレス指定アーキテクチャは、スケーラビリティ、マルチホーム、およびドメイン間トラフィックエンジニアリングの課題に直面していることが一般的に認識されています。このドキュメントは、IETFの将来の方向性の推奨として、インターネットの将来のスケーラビリティを支援できるソリューションを提示します。この目的のために、この文書は、この活動で議論のために提起された提案の多くと、その後の分析と椅子の建築的推奨の一部を調査します。このドキュメントは、ルーティング研究グループの製品です。
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 individual opinion(s) of one or more members 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）のルーティング研究グループの1人以上のメンバーの個々の意見を表しています。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/rfc6115.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6115で取得できます。
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Background to This Document . . . . . . . . . . . . . . . 5
1.2. Areas of Group Consensus . . . . . . . . . . . . . . . . . 6
1.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7
2. Locator/ID Separation Protocol (LISP) . . . . . . . . . . . . 8
2.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.4. References . . . . . . . . . . . . . . . . . . . . . . 10
2.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 11
3. Routing Architecture for the Next Generation Internet
(RANGI) . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.4. References . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Internet Vastly Improved Plumbing (Ivip) . . . . . . . . . . . 16
4.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.1. Key Ideas . . . . . . . . . . . . . . . . . . . . . . 16
4.1.2. Extensions . . . . . . . . . . . . . . . . . . . . . . 17
4.1.2.1. TTR Mobility . . . . . . . . . . . . . . . . . . . 17
4.1.2.2. Modified Header Forwarding . . . . . . . . . . . . 18
4.1.3. Gains . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.4. Costs . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.5. References . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Hierarchical IPv4 Framework (hIPv4) . . . . . . . . . . . . . 21
5.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1.3. Costs and Issues . . . . . . . . . . . . . . . . . . . 23
5.1.4. References . . . . . . . . . . . . . . . . . . . . . . 23
5.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 25
6. Name Overlay (NOL) Service for Scalable Internet Routing . . . 25
6.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 25
6.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1.4. References . . . . . . . . . . . . . . . . . . . . . . 27
6.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 28
7. Compact Routing in a Locator Identifier Mapping System (CRM) . 29
7.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 30
7.1.4. References . . . . . . . . . . . . . . . . . . . . . . 30
7.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 31
8. Layered Mapping System (LMS) . . . . . . . . . . . . . . . . . 32
8.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1.1. Key Ideas . . . . . . . . . . . . . . . . . . . . . . 32
8.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1.4. References . . . . . . . . . . . . . . . . . . . . . . 33
8.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 34
9. Two-Phased Mapping . . . . . . . . . . . . . . . . . . . . . . 34
9.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.1.1. Considerations . . . . . . . . . . . . . . . . . . . . 34
9.1.2. Basics of a Two-Phased Mapping . . . . . . . . . . . . 35
9.1.3. Gains . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 36
9.1.5. References . . . . . . . . . . . . . . . . . . . . . . 36
9.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. Global Locator, Local Locator, and Identifier Split
(GLI-Split) . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 36
10.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1.4. References . . . . . . . . . . . . . . . . . . . . . . 38
10.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 39
11. Tunneled Inter-Domain Routing (TIDR) . . . . . . . . . . . . . 40
11.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.1.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . . 40
11.1.2. Gains . . . . . . . . . . . . . . . . . . . . . . . . 40
11.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 41
11.1.4. References . . . . . . . . . . . . . . . . . . . . . . 41
11.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 41
11.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 42
12. Identifier-Locator Network Protocol (ILNP) . . . . . . . . . . 42
12.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 42
12.1.1. Key Ideas . . . . . . . . . . . . . . . . . . . . . . 42
12.1.2. Benefits . . . . . . . . . . . . . . . . . . . . . . . 43
12.1.3. Costs . . . . . . . . . . . . . . . . . . . . . . . . 44
12.1.4. References . . . . . . . . . . . . . . . . . . . . . . 45
12.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 45
12.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 46
13. Enhanced Efficiency of Mapping Distribution Protocols in
Map-and-Encap Schemes (EEMDP) . . . . . . . . . . . . . . . . 48
13.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 48
13.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 48
13.1.2. Management of Mapping Distribution of Subprefixes
Spread across Multiple ETRs . . . . . . . . . . . . . 48
13.1.3. Management of Mapping Distribution for Scenarios
with Hierarchy of ETRs and Multihoming . . . . . . . . 49
13.1.4. References . . . . . . . . . . . . . . . . . . . . . . 50
13.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 50
13.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 51
14. Evolution . . . . . . . . . . . . . . . . . . . . . . . . . . 52
14.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 52
14.1.1. Need for Evolution . . . . . . . . . . . . . . . . . . 52
14.1.2. Relation to Other RRG Proposals . . . . . . . . . . . 53
14.1.3. Aggregation with Increasing Scopes . . . . . . . . . . 53
14.1.4. References . . . . . . . . . . . . . . . . . . . . . . 55
14.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 55
14.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 56
15. Name-Based Sockets . . . . . . . . . . . . . . . . . . . . . . 56
15.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 56
15.1.1. References . . . . . . . . . . . . . . . . . . . . . . 58
15.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 58
15.2.1. Deployment . . . . . . . . . . . . . . . . . . . . . . 59
15.2.2. Edge-networks . . . . . . . . . . . . . . . . . . . . 59
15.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 59
16. Routing and Addressing in Networks with Global Enterprise
Recursion (IRON-RANGER) . . . . . . . . . . . . . . . . . . . 59
16.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 59
16.1.1. Gains . . . . . . . . . . . . . . . . . . . . . . . . 60
16.1.2. Costs . . . . . . . . . . . . . . . . . . . . . . . . 61
16.1.3. References . . . . . . . . . . . . . . . . . . . . . . 61
16.2. Critique . . . . . . . . . . . . . . . . . . . . . . . . . 61
16.3. Rebuttal . . . . . . . . . . . . . . . . . . . . . . . . . 62
17. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 63
17.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 64
17.2. Recommendation to the IETF . . . . . . . . . . . . . . . . 65
17.3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 65
18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 66
19. Security Considerations . . . . . . . . . . . . . . . . . . . 66
20. Informative References . . . . . . . . . . . . . . . . . . . . 66
It is commonly recognized that the Internet routing and addressing architecture is facing challenges in scalability, multihoming, and inter-domain traffic engineering. The problem being addressed has been documented in [Scalability_PS], and the design goals that we have discussed can be found in [RRG_Design_Goals].
インターネットのルーティングとアドレス指定アーキテクチャは、スケーラビリティ、マルチホーム、およびドメイン間トラフィックエンジニアリングの課題に直面していることが一般的に認識されています。対処されている問題は[scalability_ps]に文書化されており、私たちが議論した設計目標は[rrg_design_goals]に記載されています。
This document surveys many of the proposals that were brought forward for discussion in this activity. For some of the proposals, this document also includes additional analysis showing some of the concerns with specific proposals, and how some of those concerns may be addressed. Readers are cautioned not to draw any conclusions about the degree of interest or endorsement by the Routing Research Group (RRG) from the presence of any proposals in this document, or the amount of analysis devoted to specific proposals.
この文書は、この活動で議論のために提起された提案の多くを調査します。提案のいくつかについては、このドキュメントには、特定の提案に関する懸念の一部と、それらの懸念の一部がどのように対処されるかを示す追加の分析も含まれています。読者は、この文書の提案の存在から、ルーティング研究グループ（RRG）による関心の程度または承認に関する結論、または特定の提案に捧げられた分析の量を導き出さないことを警告しています。
The RRG was chartered to research and recommend a new routing architecture for the Internet. The goal was to explore many alternatives and build consensus around a single proposal. The only constraint on the group's process was that the process be open and the group set forth with the usual discussion of proposals and trying to build consensus around them. There were no explicit contingencies in the group's process for the eventuality that the group did not reach consensus.
RRGは、インターネット用の新しいルーティングアーキテクチャを調査し、推奨するためにチャーターされました。目標は、多くの代替案を探求し、単一の提案に関するコンセンサスを構築することでした。グループのプロセスに対する唯一の制約は、プロセスが開かれており、グループが提案の通常の議論とそれらの周りのコンセンサスを構築しようとすることであることでした。グループがコンセンサスに達しなかったという最終性のためのグループのプロセスには、明示的な偶発性はありませんでした。
The group met at every IETF meeting from March 2007 to March 2010 and discussed many proposals, both in person and via its mailing list. Unfortunately, the group did not reach consensus. Rather than lose the contributions and progress that had been made, the chairs (Lixia Zhang and Tony Li) elected to collect the proposals of the group and some of the debate concerning the proposals and make a recommendation from those proposals. Thus, the recommendation reflects the opinions of the chairs and not necessarily the consensus of the group.
このグループは、2007年3月から2010年3月までのすべてのIETF会議で会合を開き、直接とメーリングリストの両方で多くの提案について議論しました。残念ながら、グループはコンセンサスに達しませんでした。椅子（リキシア・チャンとトニー・リー）は、貢献と進歩を失うのではなく、グループの提案と提案に関する議論のいくつかを収集し、それらの提案から推薦することを選択しました。したがって、推奨は椅子の意見を反映しており、必ずしもグループのコンセンサスではありません。
The group was able to reach consensus on a number of items that are included below. The proposals included here were collected in an open call amongst the group. Once the proposals were collected, the group was solicited to submit critiques of each proposal. The group was asked to self-organize to produce a single critique for each proposal. In cases where there were several critiques submitted, the editor selected one. The proponents of each proposal then were given the opportunity to write a rebuttal of the critique. Finally, the group again had the opportunity to write a counterpoint of the rebuttal. No counterpoints were submitted. For pragmatic reasons, each submission was severely constrained in length.
グループは、以下に含まれる多くのアイテムについてコンセンサスに達することができました。ここに含まれる提案は、グループ間の公開呼び出しで収集されました。提案が収集されると、グループは各提案の批判を提出するよう求められました。グループは、各提案に対して単一の批評を生み出すために自己組織化するように求められました。いくつかの批評が提出された場合、編集者は1つを選択しました。その後、各提案の支持者には、批評の反論を書く機会が与えられました。最後に、グループは再び反論のカウンターポイントを書く機会がありました。カウンターポイントは提出されませんでした。実用的な理由で、各提出は長さが厳しく制限されていました。
All of the proposals were given the opportunity to progress their documents to RFC status; however, not all of them have chosen to pursue this path. As a result, some of the references in this document may become inaccessible. This is unfortunately unavoidable.
すべての提案には、ドキュメントをRFCステータスに進める機会が与えられました。しかし、それらのすべてがこの道を追求することを選択したわけではありません。その結果、このドキュメントの参照の一部はアクセスできない場合があります。これは残念ながら避けられません。
The group did reach consensus that the overall document should be published. The document has been reviewed by many of the active members of the Research Group.
グループは、文書全体を公開すべきであるというコンセンサスに達しました。この文書は、研究グループのアクティブメンバーの多くによってレビューされています。
The group was also able to reach broad and clear consensus on some terminology and several important technical points. For the sake of posterity, these are recorded here:
グループはまた、いくつかの用語といくつかの重要な技術的ポイントについて、広範かつ明確なコンセンサスに到達することができました。後世のために、これらはここに記録されています。
1. A "node" is either a host or a router.
1. 「ノード」はホストまたはルーターのいずれかです。
2. A "router" is any device that forwards packets at the network layer (e.g., IPv4, IPv6) of the Internet architecture.
2. 「ルーター」は、インターネットアーキテクチャのネットワークレイヤー（IPv4、IPv6など）にパケットを転送する任意のデバイスです。
3. A "host" is a device that can send/receive packets to/from the network, but does not forward packets.
3. 「ホスト」は、ネットワークからパケットを送信/受信できるが、パケットを転送しないデバイスです。
4. A "bridge" is a device that forwards packets at the link layer (e.g., Ethernet) of the Internet architecture. An Ethernet switch or Ethernet hub are examples of bridges.
4. 「ブリッジ」は、インターネットアーキテクチャのリンクレイヤー（イーサネットなど）にパケットを転送するデバイスです。イーサネットスイッチまたはイーサネットハブは、ブリッジの例です。
5. An "address" is an object that combines aspects of identity with topological location. IPv4 and IPv6 addresses are current examples.
5. 「アドレス」とは、アイデンティティの側面とトポロジーロケーションを組み合わせたオブジェクトです。IPv4およびIPv6アドレスは現在の例です。
6. A "locator" is a structured topology-dependent name that is not used for node identification and is not a path. Two related meanings are current, depending on the class of things being named:
6. 「ロケーター」は、ノード識別には使用されておらず、パスではない構造化されたトポロジ依存名です。2つの関連する意味は、名前が付けられているもののクラスに応じて最新です。
1. The topology-dependent name of a node's interface.
1. ノードのインターフェイスのトポロジ依存名。
2. The topology-dependent name of a single subnetwork OR topology-dependent name of a group of related subnetworks that share a single aggregate. An IP routing prefix is a current example of the latter.
2. 単一のサブネットワークまたはトポロジー依存の名前のトポロジ依存名は、単一の集計を共有する関連するサブネットワークのグループの名前です。IPルーティングプレフィックスは、後者の現在の例です。
7. An "identifier" is a topology-independent name for a logical node. Depending upon instantiation, a "logical node" might be a single physical device, a cluster of devices acting as a single node, or a single virtual partition of a single physical device. An OSI End System Identifier (ESID) is an example of an identifier. A Fully Qualified Domain Name (FQDN) that precisely names one logical node is another example. (Note well that not all FQDNs meet this definition.)
7. 「識別子」は、論理ノードのトポロジに依存しない名前です。インスタンス化に応じて、「論理ノード」は、単一の物理デバイス、単一のノードとして機能するデバイスのクラスター、または単一の物理デバイスの単一の仮想パーティションである可能性があります。OSIエンドシステム識別子（ESID）は、識別子の例です。1つの論理ノードに正確に名前を付ける完全に適格なドメイン名（FQDN）が別の例です。（すべてのFQDNがこの定義を満たしているわけではないことに注意してください。）
8. Various other names (i.e., other than addresses, locators, or identifiers), each of which has the sole purpose of identifying a component of a logical system or physical device, might exist at various protocol layers in the Internet architecture.
8. それぞれが論理システムまたは物理デバイスのコンポーネントを識別することを唯一の目的とする他のさまざまな名前（つまり、アドレス、ロケーター、または識別子以外）は、インターネットアーキテクチャのさまざまなプロトコル層に存在する可能性があります。
9. The Research Group has rough consensus that separating identity from location is desirable and technically feasible. However, the Research Group does NOT have consensus on the best engineering approach to such an identity/location split.
9. 研究グループには、アイデンティティを場所から分離することが望ましく、技術的に実行可能であるという大まかなコンセンサスがあります。ただし、研究グループは、このようなアイデンティティ/場所分割に対する最良のエンジニアリングアプローチについてコンセンサスを持っていません。
10. The Research Group has consensus that the Internet needs to support multihoming in a manner that scales well and does not have prohibitive costs.
10. 研究グループは、インターネットが十分に拡大し、法外なコストを持っていない方法でマルチホームをサポートする必要があるというコンセンサスを持っています。
11. Any IETF solution to Internet scaling has to not only support multihoming, but address the real-world constraints of the end customers (large and small).
11. インターネットスケーリングに対するIETFソリューションは、マルチホームをサポートするだけでなく、エンド顧客の実際の制約（大小）に対処する必要があります。
This section lists some of the most common abbreviations used in the remainder of this document.
このセクションでは、このドキュメントの残りの部分で使用される最も一般的な略語の一部をリストします。
DFZ Default-Free Zone
DFZデフォルトフリーゾーン
EID Endpoint IDentifier or Endpoint Interface iDentifier: The precise definition varies depending on the proposal.
EIDエンドポイント識別子またはエンドポイントインターフェイス識別子：正確な定義は、提案によって異なります。
ETR Egress Tunnel Router: In a system that tunnels traffic across the existing infrastructure by encapsulating it, the device close to the actual ultimate destination that decapsulates the traffic before forwarding it to the ultimate destination.
ETR Egress Tunnel Router：既存のインフラストラクチャをカプセル化することにより、既存のインフラストラクチャ全体にトラフィックをトンネルするシステムでは、トラフィックを最終的な目的地に転送する前に、実際の最終目的地に近いデバイスです。
FIB Forwarding Information Base: The forwarding table, used in the
FIB転送情報ベース：で使用される転送テーブル
data plane of routers to select the next hop for each packet.
ルーターのデータ平面各パケットの次のホップを選択します。
ITR Ingress Tunnel Router: In a system that tunnels traffic across the existing infrastructure by encapsulating it, the device close to the actual original source that encapsulates the traffic before using the tunnel to send it to the appropriate ETR.
ITRイングレストンネルルーター：既存のインフラストラクチャをカプセル化することにより、既存のインフラストラクチャ全体にトラフィックをトンネルするシステムでは、トンネルを使用して適切なETRに送信する前にトラフィックをカプセル化する実際の元のソースに近いデバイスです。
PA Provider-Aggregatable: Address space that can be aggregated as part of a service provider's routing advertisements.
PAプロバイダー総合：サービスプロバイダーのルーティング広告の一部として集約できるアドレススペース。
PI Provider-Independent: Address space assigned by an Internet registry independent of any service provider.
PIプロバイダーに依存しない：インターネットレジストリによって割り当てられたアドレススペースは、あらゆるサービスプロバイダーから独立しています。
PMTUD Path Maximum Transmission Unit Discovery: The process or mechanism that determines the largest packet that can be sent between a given source and destination without being either i) fragmented (IPv4 only), or ii) discarded (if not fragmentable) because it is too large to be sent down one link in the path from the source to the destination.
PMTUDパス最大送信ユニットの発見：I）断片化（IPv4のみ）、またはii）のいずれかで特定のソースと宛先の間で送信できる最大のパケットを決定するプロセスまたはメカニズム（断片化できない場合）ソースから宛先へのパス内の1つのリンクを1つ送信します。
RIB Routing Information Base. The routing table, used in the control plane of routers to exchange routing information and construct the FIB.
リブルーティング情報ベース。ルーターのコントロールプレーンで使用されるルーティングテーブルは、ルーティング情報を交換してFIBを構築します。
RIR Regional Internet Registry.
RIRリージョナルインターネットレジストリ。
RLOC Routing LOCator: The precise definition varies depending on the proposal.
RLOCルーティングロケーター：正確な定義は、提案によって異なります。
xTR Tunnel Router: In some systems, the term used to describe a device which can function as both an ITR and an ETR.
XTRトンネルルーター：一部のシステムでは、ITRとETRの両方として機能できるデバイスを記述するために使用される用語。
Implements a locator/identifier separation mechanism using encapsulation between routers at the "edge" of the Internet. Such a separation allows topological aggregation of the routable addresses (locators) while providing stable and portable numbering of end systems (identifiers).
インターネットの「エッジ」でルーター間のカプセル化を使用して、ロケーター/識別子分離メカニズムを実装します。このような分離により、routableアドレス（ロケーター）のトポロジカルな集約が可能になり、エンドシステム（識別子）の安定したポータブル番号が提供されます。
o topological aggregation of locator space (RLOCs) used for routing, which greatly reduces both the overall size and the "churn rate" of the information needed to operate the Internet global routing system
o ルーティングに使用されるロケータースペース（RLOC）のトポロジー的集約は、インターネットグローバルルーティングシステムの運用に必要な情報の全体的なサイズと「チャーン率」の両方を大幅に削減します
o separate identifier space (EIDs) for end systems, effectively allowing "PI for all" (no renumbering cost for connectivity changes) without adding state to the global routing system
o エンドシステム用の個別の識別子スペース（EIDS）は、グローバルルーティングシステムに状態を追加せずに「すべてのためのPI」（接続の変更に変更費用なし）を効果的に許可することを可能にします
o improved traffic engineering capabilities that explicitly do not add state to the global routing system and whose deployment will allow active removal of the more-specific state that is currently used
o グローバルルーティングシステムに明示的に状態を追加せず、現在使用されているより特定の状態を積極的に削除できるようになるトラフィックエンジニアリング機能の改善
o no changes required to end systems
o システムを終了するために変更は必要ありません
o no changes to Internet "core" routers
o インターネット「コア」ルーターに変更はありません
o minimal and straightforward changes to "edge" routers
o 「エッジ」ルーターの最小限で簡単な変更
o day-one advantages for early adopters
o 早期採用者にとっての1日の利点
o defined router-to-router protocol
o 定義されたルーター間プロトコル
o defined database mapping system
o 定義されたデータベースマッピングシステム
o defined deployment plan
o 定義された展開計画
o defined interoperability/interworking mechanisms
o 定義された相互運用性/インターワーキングメカニズム
o defined scalable end-host mobility mechanisms
o 定義されたスケーラブルなエンドホストモビリティメカニズム
o prototype implementation already exists and is undergoing testing
o プロトタイプの実装はすでに存在しており、テストを受けています
o production implementations in progress
o 進行中の生産実装
o mapping system infrastructure (map servers, map resolvers, Alternative Logical Topology (ALT) routers). This is considered a new potential business opportunity.
o マッピングシステムインフラストラクチャ（マップサーバー、マップリゾルバー、代替論理トポロジ（ALT）ルーター）。これは、新しい潜在的なビジネスチャンスと考えられています。
o interworking infrastructure (proxy ITRs). This is considered a new potential business opportunity.
o インターワーキングインフラストラクチャ（Proxy ITRS）。これは、新しい潜在的なビジネスチャンスと考えられています。
o overhead for determining/maintaining locator/path liveness. This is a common issue for all identifier/locator separation proposals.
o ロケーター/パスの責任を決定/維持するためのオーバーヘッド。これは、すべての識別子/ロケーター分離提案の一般的な問題です。
[LISP] [LISP+ALT] [LISP-MS] [LISP-Interworking] [LISP-MN] [LIG] [LOC_ID_Implications]
[lisp] [lisp alt] [lisp-ms] [lisp-interworking] [lisp-mn] [lig] [loc_id_implications]
LISP+ALT distributes mapping information to ITRs via (optional, local, potentially caching) Map Resolvers and with globally distributed query servers: ETRs and optional Map Servers (MSes).
LISP ALTは、マッピング情報を（オプション、ローカル、潜在的にキャッシュ）マップリゾルバーを介してITRSに配布し、グローバルに分散したクエリサーバー：ETRSおよびオプションマップサーバー（MSE）を使用します。
A fundamental problem with any global query server network is that the frequently long paths and greater risk of packet loss may cause ITRs to drop or significantly delay the initial packets of many new sessions. ITRs drop the packet(s) they have no mapping for. After the mapping arrives, the ITR waits for a re-sent packet and will tunnel that packet correctly. These "initial-packet delays" reduce performance and so create a major barrier to voluntary adoption on a wide enough basis to solve the routing scaling problem.
グローバルクエリサーバーネットワークの根本的な問題は、頻繁に長いパスとパケット損失のリスクが高いため、ITRが多くの新しいセッションの初期パケットを削除または大幅に遅らせる可能性があることです。ITRSは、マッピングのないパケットをドロップします。マッピングが到着した後、ITRは再セントパケットを待ち、そのパケットを正しくトンネルします。これらの「初期パケットの遅延」は、パフォーマンスを低下させるため、ルーティングスケーリングの問題を解決するのに十分な広いベースで、自発的な採用に対する大きな障壁を作り出します。
ALT's delays are compounded by its structure being "aggressively aggregated", without regard to the geographic location of the routers. Tunnels between ALT routers will often span intercontinental distances and traverse many Internet routers.
Altの遅延は、ルーターの地理的位置に関係なく、その構造が「積極的に集約」されることによって悪化します。ALTルーター間のトンネルは、多くの場合、大陸間距離にまたがり、多くのインターネットルーターを横断します。
The many levels to which a query typically ascends in the ALT hierarchy before descending towards its destination will often involve excessively long geographic paths and so worsen initial-packet delays.
クエリが通常、その目的地に向かって下る前にALT階層に登る多くのレベルは、しばしば過度に長い地理的経路を伴い、したがって初期パケットの遅延を悪化させます。
No solution has been proposed for these problems or for the contradiction between the need for high aggregation while making the ALT structure robust against single points of failure.
これらの問題については、ALT構造を単一の障害点に対して堅牢にする一方で、高い集約の必要性との間の矛盾について、解決策は提案されていません。
LISP's ITRs' multihoming service restoration depends on their determining the reachability of end-user networks via two or more ETRs. Large numbers of ITRs doing this is inefficient and may overburden ETRs.
LISPのITRSのマルチホームサービスの復元は、2つ以上のETRを介したエンドユーザーネットワークの到達可能性を決定することに依存します。これを行う多数のITRは非効率的であり、ETRを過剰に負担する可能性があります。
Testing reachability of the ETRs is complex and costly -- and insufficient. ITRs cannot test network reachability via each ETR, since the ITRs do not have the address of a device in each ETR's network. So, ETRs must report network unreachability to ITRs.
ETRの到達可能性のテストは複雑で費用がかかり、不十分です。ITRは、各ETRを介して各ETRを介してネットワークの到達可能性をテストすることはできません。ITRには各ETRのネットワーク内のデバイスのアドレスがないためです。したがって、ETRは、ネットワークの到達不能をITRに報告する必要があります。
LISP involves complex communication between ITRs and ETRs, with UDP and 64-bit LISP headers in all traffic packets.
LISPには、すべてのトラフィックパケットにUDPと64ビットのLISPヘッダーを使用して、ITRとETRの間の複雑な通信が含まれます。
The advantage of LISP+ALT is that its ability to handle billions of EIDs is not constrained by the need to transmit or store the mapping to any one location. Such numbers, beyond a few tens of millions of EIDs, will only result if the system is used for mobility. Yet the concerns just mentioned about ALT's structure arise from the millions of ETRs that would be needed just for non-mobile networks.
Lisp Altの利点は、数十億のEIDを処理する能力が、マッピングを1つの場所に送信または保存する必要性によって制約されないことです。数千万人のEIDを超えたこのような数は、システムがモビリティに使用される場合にのみ生じます。しかし、Altの構造について今言及された懸念は、非モバイルネットワークのためだけに必要な数百万のETRから生じます。
In LISP's mobility approach, each Mobile Node (MN) needs an RLOC address to be its own ETR, meaning the MN cannot be behind a NAT. Mapping changes must be sent instantly to all relevant ITRs every time the MN gets a new address -- LISP cannot achieve this.
LISPのモビリティアプローチでは、各モバイルノード（MN）が独自のETRであるためにRLOCアドレスを必要としています。つまり、MNはNATの背後にあることはできません。マッピングの変更は、MNが新しいアドレスを取得するたびに、関連するすべてのITRに即座に送信する必要があります。LISPはこれを達成できません。
In order to enforce ISP filtering of incoming packets by source address, LISP ITRs would have to implement the same filtering on each decapsulated packet. This may be prohibitively expensive.
ソースアドレスによる着信パケットのISPフィルタリングを実施するには、LISP ITRSは、脱カプセル化された各パケットに同じフィルタリングを実装する必要があります。これは非常に高価かもしれません。
LISP monolithically integrates multihoming failure detection and restoration decision-making processes into the Core-Edge Separation (CES) scheme itself. End-user networks must rely on the necessarily limited capabilities that are built into every ITR.
LISPは、マルチホームの故障検出と回復の意思決定プロセスを、コアエッジ分離（CES）スキーム自体に統合します。エンドユーザーネットワークは、すべてのITRに組み込まれている必然的に制限された機能に依存する必要があります。
LISP+ALT may be able to solve the routing scaling problem, but alternative approaches would be superior because they eliminate the initial-packet delay problem and give end-user networks real-time control over ITR tunneling.
Lisp Altはルーティングスケーリングの問題を解決できる可能性がありますが、初期パケットの遅延問題を排除し、ITRトンネルのエンドユーザーネットワークをリアルタイム制御するため、代替アプローチは優れています。
Initial-packet loss/delays turn out not to be a deep issue. Mechanisms for interoperation with the legacy part of the network are needed in any viably deployable design, and LISP has such mechanisms. If needed, initial packets can be sent via those legacy mechanisms until the ITR has a mapping. (Field experience has shown that the caches on those interoperation devices are guaranteed to be populated, as 'crackers' doing address-space sweeps periodically send packets to every available mapping.)
初期パケットの損失/遅延は、深い問題ではないことが判明しました。ネットワークのレガシー部分との相互操作のメカニズムは、経由で展開可能な設計で必要であり、LISPにはそのようなメカニズムがあります。必要に応じて、ITRがマッピングになるまで、これらのレガシーメカニズムを介して初期パケットを送信できます。（フィールドエクスペリエンスにより、これらの相互操作デバイスのキャッシュが、住所空間スイープを行う「クラッカー」が定期的にパケットを利用可能なすべてのマッピングに送信することが保証されていることが示されています。）
On ALT issues, it is not at all mandatory that ALT be the mapping system used in the long term. LISP has a standardized mapping system interface, in part to allow reasonably smooth deployment of whatever new mapping system(s) experience might show are required. At least one other mapping system (LISP-TREE) [LISP-TREE], which avoids ALT's problems (such as query load concentration at high-level nodes), has already been laid out and extensively simulated. Exactly what mixture of mapping system(s) is optimal is not really answerable without more extensive experience, but LISP is designed to allow evolutionary changes to other mapping system(s).
ALTの問題については、ALTが長期的に使用されるマッピングシステムであることはまったく必須ではありません。LISPには、標準化されたマッピングシステムインターフェイスがあります。これは、新しいマッピングシステムのエクスペリエンスが必要になる可能性のあるものを合理的にスムーズに展開できるようにするためです。ALTの問題（高レベルノードでのクエリ負荷濃度など）を回避する、少なくとも1つの他のマッピングシステム（LISP-Tree）[LISP-Tree]は、すでにレイアウトされ、広くシミュレートされています。正確には、マッピングシステムの混合物が最適であることは、より広範なエクスペリエンスなしでは実際には答えられませんが、LISPは他のマッピングシステムの進化的変化を可能にするように設計されています。
As far as ETR reachability goes, a potential problem to which there is a solution with an adequate level of efficiency, complexity, and robustness is not really a problem. LISP has a number of overlapping mechanisms that it is believed will provide adequate reachability detection (along the three axes above), and in field testing to date, they have behaved as expected.
ETRの到達可能性に関する限り、適切なレベルの効率、複雑さ、堅牢性を備えたソリューションがある潜在的な問題は実際には問題ではありません。LISPには、適切な到達可能性検出（上の3つの軸に沿って）を提供すると考えられている多くの重複メカニズムがあり、フィールドテストでは、予想どおりに動作しています。
Operation of LISP devices behind a NAT has already been demonstrated. A number of mechanisms to update correspondent nodes when a mapping is updated have been designed (some are already in use).
NATの背後にあるLISPデバイスの動作はすでに実証されています。マッピングが更新されたときに特派員ノードを更新するための多くのメカニズムが設計されています（いくつかはすでに使用されています）。
Similar to Host Identity Protocol (HIP) [RFC4423], RANGI introduces a host identifier layer between the network layer and the transport layer, and the transport-layer associations (i.e., TCP connections) are no longer bound to IP addresses, but to host identifiers. The major difference from HIP is that the host identifier in RANGI is a 128-bit hierarchical and cryptographic identifier that has organizational structure. As a result, the corresponding ID->locator mapping system for such identifiers has a reasonable business model and clear trust boundaries. In addition, RANGI uses IPv4-embedded IPv6 addresses as locators. The Locator Domain Identifier (LD ID) (i.e., the leftmost 96 bits) of this locator is a provider-assigned /96 IPv6 prefix, while the last four octets of this locator are a local IPv4 address (either public or private). This special locator could be used to realize 6over4 automatic tunneling (borrowing ideas from the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) [RFC5214]), which will reduce the deployment cost of this new routing architecture. Within RANGI, the mappings from FQDN to host identifiers are stored in the DNS system, while the mappings from host identifiers to locators are stored in a distributed ID/locator mapping system (e.g., a hierarchical Distributed Hash Table (DHT) system, or a reverse DNS system).
ホストアイデンティティプロトコル（HIP）[RFC4423]と同様に、Rangiはネットワーク層と輸送層の間にホスト識別子層を導入し、輸送層の関連付け（つまり、TCP接続）はもはやIPアドレスに結合しませんが、ホストにはホストに結合します。識別子。股関節との主な違いは、Rangiのホスト識別子が、組織構造を持つ128ビットの階層的および暗号化識別子であることです。その結果、そのような識別子の対応するID->ロケーターマッピングシステムには、合理的なビジネスモデルと明確な信頼境界があります。さらに、RangiはIPv4-埋め込みIPv6アドレスをロケーターとして使用します。このロケーターのロケータードメイン識別子（LD ID）（つまり、左端96ビット）はプロバイダーが割り当てられた /96 IPv6プレフィックスですが、このロケーターの最後の4オクテットはローカルIPv4アドレス（パブリックまたはプライベート）です。この特別なロケーターは、6Over4自動トンネル（敷地内自動トンネルアドレス指定プロトコル（ISATAP）[RFC5214]からの借入アイデア）を実現するために使用できます。これにより、この新しいルーティングアーキテクチャの展開コストが削減されます。Rangi内では、FQDNからホスト識別子へのマッピングがDNSシステムに保存され、ホスト識別子からロケーターへのマッピングは分散ID/ロケーターマッピングシステムに保存されます（例：階層分散ハッシュテーブル（DHT）システム、またはA A逆DNSシステム）。
RANGI achieves almost all of the goals set forth by RRG as follows:
Rangiは、次のようにRRGによって定められたほぼすべての目標を達成します。
1. Routing Scalability: Scalability is achieved by decoupling identifiers from locators.
1. ルーティングスケーラビリティ：識別子をロケーターから切り離すことにより、スケーラビリティが達成されます。
2. Traffic Engineering: Hosts located in a multihomed site can suggest the upstream ISP for outbound and inbound traffic, while the first-hop Locator Domain Border Router (LDBR; i.e., site border router) has the final decision on the upstream ISP selection.
2. トラフィックエンジニアリング：マルチホームサイトにあるホストは、アウトバウンドおよびインバウンドトラフィックの上流ISPを提案できますが、最初のホップロケータードメインボーダールーター（LDBR、つまり、サイトボーダールーター）は、上流ISP選択に関する最終決定を行います。
3. Mobility and Multihoming: Sessions will not be interrupted due to locator change in cases of mobility or multihoming.
3. モビリティとマルチホーム：モビリティまたはマルチホームの場合のロケーターの変更により、セッションは中断されません。
4. Simplified Renumbering: When changing providers, the local IPv4 addresses of the site do not need to change. Hence, the internal routers within the site don't need renumbering.
4. 簡略化された変更：プロバイダーを変更する場合、サイトのローカルIPv4アドレスを変更する必要はありません。したがって、サイト内の内部ルーターは、変更を必要としません。
5. Decoupling Location and Identifier: Obvious.
5. 分離位置と識別子：明白。
6. Routing Stability: Since the locators are topologically aggregatable and the internal topology within the LD will not be disclosed outside, routing stability could be improved greatly.
6. ルーティングの安定性：ロケーターはトポロジカルに集約可能であり、LD内の内部トポロジは外部で開示されないため、ルーティングの安定性を大幅に改善できます。
7. Routing Security: RANGI reuses the current routing system and does not introduce any new security risks into the routing system.
7. ルーティングセキュリティ：Rangiは現在のルーティングシステムを再利用し、ルーティングシステムに新しいセキュリティリスクを導入しません。
8. Incremental Deployability: RANGI allows an easy transition from IPv4 networks to IPv6 networks. In addition, RANGI proxy allows RANGI-aware hosts to communicate to legacy IPv4 or IPv6 hosts, and vice versa.
8. インクリメンタル展開性：Rangiは、IPv4ネットワークからIPv6ネットワークへの簡単な移行を可能にします。さらに、Rangi Proxyでは、Rangi-AwareホストがLegacy IPv4またはIPv6ホストと通信することができます。その逆も同様です。
1. A host change is required.
1. ホストの変更が必要です。
2. The first-hop LDBR change is required to support site-controlled traffic-engineering capability.
2. 最初のホップLDBRの変更は、サイト制御されたトラフィックエンジニアリング機能をサポートするために必要です。
3. The ID->locator mapping system is a new infrastructure to be deployed.
3. ID->ロケーターマッピングシステムは、展開する新しいインフラストラクチャです。
4. RANGI proxy needs to be deployed for communication between RANGI-aware hosts and legacy hosts.
4. Rangi Proxyは、Rangi-Awareホストとレガシーホスト間のコミュニケーションのために展開する必要があります。
[RFC3007] [RFC4423] [RANGI] [RANGI-PROXY] [RANGI-SLIDES]
[RFC3007] [RFC4423] [rangi] [rangi-proxy] [rangi-slides]
RANGI is an ID/locator split protocol that, like HIP, places a cryptographically signed ID between the network layer (IPv6) and transport. Unlike the HIP ID, the RANGI ID has a hierarchical structure that allows it to support ID->locator lookups. This hierarchical structure addresses two weaknesses of the flat HIP ID: the difficulty of doing the ID->locator lookup, and the administrative scalability of doing firewall filtering on flat IDs. The usage of this hierarchy is overloaded: it serves to make the ID unique, to drive the lookup process, and possibly other things like firewall filtering. More thought is needed as to what constitutes these levels with respect to these various roles.
Rangiは、HIPと同様に、ネットワークレイヤー（IPv6）とトランスポートの間に暗号化されたIDを配置するID/ロケータースプリットプロトコルです。HIP IDとは異なり、Rangi IDには階層構造があり、ID->ロケータールックアップをサポートできるようにします。この階層構造は、フラットヒップIDの2つの弱点に対処します。ID->ロケータールックアップを実行することの難しさと、フラットIDでファイアウォールフィルタリングを行うことの管理スケーラビリティです。この階層の使用は過負荷になります。IDをユニークにし、ルックアッププロセスを駆動し、場合によってはファイアウォールフィルタリングのようなものを駆動するのに役立ちます。これらのさまざまな役割に関して、これらのレベルを構成するものに関して、より多くの考えが必要です。
The RANGI document [RANGI] suggests FQDN->ID lookup through DNS, and separately an ID->locator lookup that may be DNS or may be something else (a hierarchy of DHTs). It would be more efficient if the FQDN lookup produces both ID and locators (as does the Identifier-Locator Network Protocol (ILNP)). Probably DNS alone is sufficient for the ID->locator lookup since individual DNS servers can hold very large numbers of mappings.
Rangiドキュメント[Rangi]は、DNSを介したFQDN-> IDルックアップを提案し、DNSである可能性のあるID->ロケータールックアップ（DHTの階層）である可能性のあるID->ロケータールックアップを提案します。FQDN LookupがIDとロケーターの両方を生成すると、より効率的になります（識別子ロケーターネットワークプロトコル（ILNP）と同様）。個々のDNSサーバーが非常に多数のマッピングを保持できるため、おそらくDNSだけではID->ロケータールックアップに十分です。
RANGI provides strong sender identification, but at the cost of computing crypto. Many hosts (public web servers) may prefer to forgo the crypto at the expense of losing some functionality (receiver mobility or dynamic multihoming load balancing). While RANGI doesn't require that the receiver validate the sender, it may be good to have a mechanism whereby the receiver can signal to the sender that it is not validating, so that the sender can avoid locator changes.
Rangiは強力な送信者の識別を提供しますが、暗号化を計算する犠牲を払っています。多くのホスト（パブリックウェブサーバー）は、いくつかの機能（受信機のモビリティまたは動的なマルチホームの負荷分散）を失うことを犠牲にして、暗号を控えることを好むかもしれません。Rangiは受信者が送信者を検証することを必要としませんが、送信者がロケーターの変更を回避できるように、受信機が検証していないことを送信者に信号を送信できるメカニズムを持つことが良いかもしれません。
Architecturally, there are many advantages to putting the mapping function at the end host (versus at the edge). This simplifies the problems of neighbor aliveness and delayed first packet, and avoids stateful middleboxes. Unfortunately, the early-adopter incentive for host upgrade may not be adequate (HIP's lack of uptake being an example).
建築的には、マッピング機能をエンドホストに配置することには多くの利点があります（エッジで）。これにより、隣人の味の問題が簡素化され、最初のパケットが遅れ、ステートフルなミドルボックスが回避されます。残念ながら、ホストアップグレードの初期採用インセンティブは適切ではない場合があります（HIPの取り込みの欠如は例です）。
RANGI does not have an explicit solution for the mobility race condition (there is no mention of a home-agent-like device). However, host-to-host notification combined with fallback on the ID->locators lookup (assuming adequate dynamic update of the lookup system) may be good enough for the vast majority of mobility situations.
Rangiには、モビリティレースの状態に関する明示的なソリューションがありません（ホームエージェントのようなデバイスについては言及されていません）。ただし、ID-> Locators Lookup（Lookup Systemの適切な動的更新を想定していると仮定）のフォールバックと組み合わせたホストからホストへの通知は、モビリティの状況の大部分にとって十分である可能性があります。
RANGI uses proxies to deal with both legacy IPv6 and IPv4 sites. RANGI proxies have no mechanisms to deal with the edge-to-edge aliveness problem. The edge-to-edge proxy approach dirties up an otherwise clean end-to-end model.
Rangiはプロキシを使用して、Legacy IPv6とIPv4サイトの両方に対処します。Rangi Proxiesには、エッジからエッジまでの高度の問題に対処するメカニズムはありません。エッジツーエッジプロキシアプローチは、それ以外の場合はクリーンなエンドツーエンドモデルを汚します。
RANGI exploits existing IPv6 transition technologies (ISATAP and softwire). These transition technologies are in any event being pursued outside of RRG and do not need to be specified in RANGI drafts per se. RANGI only needs to address how it interoperates with IPv4 and legacy IPv6, which it appears to do adequately well through proxies.
Rangiは、既存のIPv6トランジションテクノロジー（ISATAPおよびSoftwire）を利用します。これらの移行技術は、いずれにせよRRG以外で追求されており、Rangi Drafts自体で指定する必要はありません。Rangiは、Proxiesを通じて適切に行うように見えるIPv4とLegacy IPv6とどのように相互運用するかについてのみ対処する必要があります。
The reason why the ID->locator lookup is separated from the FQDN->ID lookup is: 1) not all applications are tied to FQDNs, and 2) it seems unnecessary to require all devices to possess a FQDN of their own. Basically, RANGI uses DNS to realize the ID->locator mapping system. If there are too many entries to be maintained by the authoritative servers of a given Administrative Domain (AD), Distributed Hash Table (DHT) technology can be used to make these authoritative servers scale better, e.g., the mappings maintained by a given AD will be distributed among a group of authoritative servers in a DHT fashion. As a result, the robustness feature of DHT is inherited naturally into the ID->locator mapping system. Meanwhile, there is no trust issue since each AD authority runs its own DHT ring, which maintains only the mappings for those identifiers that are administrated by that AD authority.
ID->ロケータールックアップがFQDN-> IDルックアップから分離されている理由は次のとおりです。1）すべてのアプリケーションがFQDNSに関連付けられているわけではなく、2）すべてのデバイスに独自のFQDNを所有する必要がないようです。基本的に、RangiはDNSを使用してID-> Locatorマッピングシステムを実現します。特定の管理ドメイン（AD）の権威あるサーバーによって維持されるエントリが多すぎる場合、分散ハッシュテーブル（DHT）テクノロジーを使用して、これらの信頼できるサーバーをより良くすることができます。DHTファッションで権威あるサーバーのグループに配布されます。その結果、DHTの堅牢性の特徴は、ID-> Locatorマッピングシステムに自然に継承されます。一方、各広告機関は独自のDHTリングを実行しているため、信頼の問題はありません。これは、その広告当局によって管理されている識別子のマッピングのみを維持しています。
For host mobility, if communicating entities are RANGI nodes, the mobile node will notify the correspondent node of its new locator once its locator changes due to a mobility or re-homing event. Meanwhile, it should also update its locator information in the ID->locator mapping system in a timely fashion by using the Secure DNS Dynamic Update mechanism defined in [RFC3007]. In case of simultaneous mobility, at least one of the nodes has to resort to the ID->locator mapping system for resolving the correspondent node's new locator so as to continue their communication. If the correspondent node is a legacy host, Transit Proxies, which fulfill a similar function as the home agents in Mobile IP, will relay the packets between the communicating parties.
ホストのモビリティの場合、通信エンティティがRangiノードである場合、モバイルノードは、モビリティまたは再びホーミングイベントのためにロケーターが変更されると、新しいロケーターの特派員ノードに通知されます。一方、[RFC3007]で定義された安全なDNS動的更新メカニズムを使用して、ID-> Locatorマッピングシステムのロケーター情報をタイムリーに更新する必要があります。同時モビリティの場合、ノードの少なくとも1つは、通信を継続するために、特派員ノードの新しいロケーターを解決するためにID->ロケーターマッピングシステムに頼る必要があります。特派員ノードがレガシーホストである場合、モバイルIPのホームエージェントと同様の機能を満たすTransit Proxiesは、通信者間でパケットを中継します。
RANGI uses proxies (e.g., Site Proxy and Transit Proxy) to deal with both legacy IPv6 and IPv4 sites. Since proxies function as RANGI hosts, they can handle Locator Update Notification messages sent from remote RANGI hosts (or even from remote RANGI proxies) correctly. Hence, there is no edge-to-edge aliveness problem. Details will be specified in a later version of RANGI-PROXY.
Rangiは、プロキシ（サイトプロキシおよびトランジットプロキシなど）を使用して、Legacy IPv6とIPv4サイトの両方に対処します。プロキシはRangiホストとして機能するため、リモートRangiホスト（またはリモートRangiプロキシから）から送信されたロケーター更新通知メッセージを正しく処理できます。したがって、エッジからエッジへの問題はありません。詳細は、Rangi-Proxyの後のバージョンで指定されます。
The intention behind RANGI using IPv4-embedded IPv6 addresses as locators is to reduce the total deployment cost of this new Internet architecture and to avoid renumbering the site's internal routers when such a site changes ISPs.
IPv4-埋め込まれたIPv6アドレスをロケーターとして使用するRangiの背後にある意図は、この新しいインターネットアーキテクチャの総展開コストを削減し、そのようなサイトがISPを変更したときにサイトの内部ルーターの名前を変更することを避けることです。
Ivip (pronounced eye-vip, est. 2007-06-15) is a Core-Edge Separation scheme for IPv4 and IPv6. It provides multihoming, portability of address space, and inbound traffic engineering for end-user networks of all sizes and types, including those of corporations, SOHO (Small Office, Home Office), and mobile devices.
IVIP（Eye-VIPと発音、EST。2007-06-15）は、IPv4およびIPv6のコアエッジ分離スキームです。企業、ソーホー（小さなオフィス、ホームオフィス）、モバイルデバイスを含む、あらゆるサイズとタイプのエンドユーザーネットワークのマルチホーム、アドレススペースの移植性、およびインバウンドトラフィックエンジニアリングを提供します。
Ivip meets all the constraints imposed by the need for widespread voluntary adoption [Ivip_Constraints].
IVIPは、広範囲にわたる自発的な採用の必要性によって課されるすべての制約を満たしています[IVIP_Constraints]。
Ivip's global fast-push mapping distribution network is structured like a cross-linked multicast tree. This pushes all mapping changes to full-database query servers (QSDs) within ISPs and end-user networks that have ITRs. Each mapping change is sent to all QSDs within a few seconds. (Note: "QSD" is from Query Server with full Database.)
IVIPのグローバル高速プッシュマッピング配信ネットワークは、架橋マルチキャストツリーのように構成されています。これにより、ITRを持つISPおよびエンドユーザーネットワーク内のすべてのマッピングの変更がフルデータベースクエリサーバー（QSD）にプッシュされます。各マッピングの変更は、数秒以内にすべてのQSDに送信されます。（注：「QSD」は、完全なデータベースを備えたクエリサーバーからのものです。）
ITRs gain mapping information from these local QSDs within a few tens of milliseconds. QSDs notify ITRs of changed mappings with similarly low latency. ITRs tunnel all traffic packets to the correct ETR without significant delay.
ITRは、数十ミリ秒以内にこれらのローカルQSDからマッピング情報を取得します。QSDは、同様に低レイテンシで変更されたマッピングのITRに通知します。ITRSトンネルすべてのトラフィックパケットは、それほど遅滞なく正しいETRになります。
Ivip's mapping consists of a single ETR address for each range of mapped address space. Ivip ITRs do not need to test reachability to ETRs because the mapping is changed in real-time to that of the desired ETR.
IVIPのマッピングは、マッピングされたアドレススペースの各範囲の単一のETRアドレスで構成されています。IVIP ITRは、マッピングが目的のETRのマッピングに変更されるため、ETRに到達可能性をテストする必要はありません。
End-user networks control the mapping, typically by contracting a specialized company to monitor the reachability of their ETRs, and change the mapping to achieve multihoming and/or traffic engineering (TE). So, the mechanisms that control ITR tunneling are controlled by the end-user networks in real-time and are completely separate from the Core-Edge Separation scheme itself.
エンドユーザーネットワークは、通常、専門企業と契約してETRの到達可能性を監視し、マッピングを変更してマルチホームおよび/またはトラフィックエンジニアリング（TE）を達成することにより、マッピングを制御します。したがって、ITRトンネリングを制御するメカニズムは、エンドユーザーネットワークによってリアルタイムで制御され、コアエッジ分離スキーム自体とは完全に分離されています。
ITRs can be implemented in dedicated servers or hardware-based routers. The ITR function can also be integrated into sending hosts. ETRs are relatively simple and only communicate with ITRs rarely -- for Path MTU management with longer packets.
ITRは、専用サーバーまたはハードウェアベースのルーターに実装できます。ITR関数は、ホストの送信に統合することもできます。ETRは比較的単純であり、ITRとのみ通信しません。これは、パケットを長いパケットでMTU管理するためです。
Ivip-mapped ranges of end-user address space need not be subnets. They can be of any length, in units of IPv4 addresses or IPv6 /64s.
エンドユーザーアドレススペースのIVIPマップ範囲はサブネットではありません。それらは、IPv4アドレスまたはIPv6 /64Sの単位で、任意の長さである可能性があります。
Compared to conventional unscalable BGP techniques, and to the use of Core-Edge Separation architectures with non-real-time mapping systems, end-user networks will be able to achieve more flexible and responsive inbound TE. If inbound traffic is split into several streams, each to addresses in different mapped ranges, then real-time mapping changes can be used to steer the streams between multiple ETRs at multiple ISPs.
従来の無防備なBGP技術と、非リアルタイムマッピングシステムを備えたコアエッジ分離アーキテクチャの使用と比較して、エンドユーザーネットワークは、より柔軟で応答性の高いインバウンドTEを実現できます。インバウンドトラフィックがいくつかのストリームに分割され、それぞれが異なるマッピング範囲内のアドレスをアドレス指定する場合、リアルタイムマッピングの変更を使用して、複数のISPで複数のETR間でストリームを操作できます。
Default ITRs in the DFZ (DITRs; similar to LISP's Proxy Tunnel Routers) tunnel packets sent by hosts in networks that lack ITRs. So multihoming, portability, and TE benefits apply to all traffic.
DFZのデフォルトITR（DITRS; LISPのプロキシトンネルルーターに似ています）ITRを欠くネットワークのホストから送信されたトンネルパケット。したがって、マルチホーム、携帯性、およびTEの利点は、すべてのトラフィックに適用されます。
ITRs request mappings either directly from a local QSD or via one or more layers of caching query servers (QSCs), which in turn request it from a local QSD. QSCs are optional but generally desirable since they reduce the query load on QSDs. (Note: "QSC" is from Query Server with Cache.)
ITRSは、ローカルQSDから直接または1つ以上のキャッシュクエリサーバー（QSC）を介してマッピングを要求し、ローカルQSDから要求します。QSCはオプションですが、QSDのクエリ負荷を減らすため、一般的に望ましいです。（注：「QSC」は、キャッシュ付きのクエリサーバーからのものです。）
ETRs may be in ISP or end-user networks. IP-in-IP encapsulation is used, so there is no UDP or any other header. PMTUD (Path MTU Discovery) management with minimal complexity and overhead will handle the problems caused by encapsulation, and adapt smoothly to jumbo frame paths becoming available in the DFZ. The outer header's source address is that of the sending host -- this enables existing ISP Border Router (BR) filtering of source addresses to be extended to encapsulated traffic packets by the simple mechanism of the ETR dropping packets whose inner and outer source address do not match.
ETRは、ISPまたはエンドユーザーネットワークにある場合があります。IP-in-IPカプセル化が使用されるため、UDPまたは他のヘッダーはありません。PMTUD（PATH MTU Discovery）の管理は、最小限の複雑さとオーバーヘッドを備えた管理により、カプセル化によって引き起こされる問題を処理し、DFZで利用可能になるジャンボフレームパスにスムーズに適応します。外側のヘッダーのソースアドレスは送信ホストのアドレスです。これにより、既存のISPボーダールーター（BR）ソースアドレスのフィルタリングを、内側と外側のソースアドレスが存在しないETRドロップパケットの単純なメカニズムによってカプセル化されたトラフィックパケットに拡張できます。マッチ。
The Translating Tunnel Router (TTR) approach to mobility [Ivip_Mobility] is applicable to all Core-Edge Separation techniques and provides scalable IPv4 and IPv6 mobility in which the MN keeps its own mapped IP address(es) no matter how or where it is physically connected, including behind one or more layers of NAT.
モビリティへの翻訳トンネルルーター（TTR）アプローチ[IVIP_Mobility]は、すべてのコアエッジ分離技術に適用され、MNが物理的にどこにもマッピングされたIPアドレスを保持するスケーラブルなIPv4およびIPv6モビリティを提供します。NATの1つ以上の層の後ろを含む接続。
Path lengths are typically optimal or close to optimal, and the MN communicates normally with all other non-mobile hosts (no stack or application changes), and of course other MNs. Mapping changes are only needed when the MN uses a new TTR, which would typically occur if the MN moved more than 1000 km. Mapping changes are not required when the MN changes its physical address(es).
パスの長さは通常、最適または最適に近いものであり、MNは通常、他のすべての非モバイルホスト（スタックまたはアプリケーションの変更なし）、およびもちろん他のMNと通信します。マッピングの変更は、MNが新しいTTRを使用する場合にのみ必要です。これは通常、MNが1000 km以上移動した場合に発生します。MNが物理アドレスを変更する場合、マッピングの変更は必要ありません。
Separate schemes for IPv4 and IPv6 enable tunneling from ITR to ETR without encapsulation. This will remove the encapsulation overhead and PMTUD problems. Both approaches involve modifying all routers between the ITR and ETR to accept a modified form of the IP header. These schemes require new FIB/RIB functionality in DFZ and some other routers but do not alter the BGP functions of DFZ routers.
IPv4とIPv6の個別のスキームは、カプセル化なしにITRからETRへのトンネリングを有効にします。これにより、カプセル化オーバーヘッドとPMTUDの問題が削除されます。どちらのアプローチでも、ITRとETRの間のすべてのルーターを変更して、IPヘッダーの変更されたフォームを受け入れます。これらのスキームは、DFZおよび他のいくつかのルーターで新しいFIB/RIB機能を必要としますが、DFZルーターのBGP関数を変更しません。
o Amenable to widespread voluntary adoption due to no need for host changes, complete support for packets sent from non-upgraded networks and no significant degradation in performance.
o ホストの変更が不要であるため、広範囲にわたる自発的な採用、アップグレードされていないネットワークから送信されるパケットの完全なサポート、およびパフォーマンスの大幅な分解がないため。
o Modular separation of the control of ITR tunneling behavior from the ITRs and the Core-Edge Separation scheme itself: end-user networks control mapping in any way they like, in real-time.
o ITRからのITRトンネル挙動の制御のモジュール分離およびコアエッジ分離スキーム自体：エンドユーザーネットワークは、リアルタイムで好きな方法でマッピングを制御します。
o A small fee per mapping change deters frivolous changes and helps pay for pushing the mapping data to all QSDs. End-user networks that make frequent mapping changes for inbound TE should find these fees attractive considering how it improves their ability to utilize the bandwidth of multiple ISP links.
o マッピングの変更ごとに少額の料金は、軽薄な変更を阻止し、マッピングデータをすべてのQSDにプッシュするために支払うのに役立ちます。インバウンドTEの頻繁なマッピング変更を行うエンドユーザーネットワークは、複数のISPリンクの帯域幅を利用する能力を改善する方法を考慮して、これらの料金を魅力的に見つけるはずです。
o End-user networks will typically pay the cost of Open ITR in the DFZ (OITRD) forwarding to their networks. This provides a business model for OITRD deployment and avoids unfair distribution of costs.
o エンドユーザーネットワークは通常、DFZ（OITRD）のネットワークへの転送でオープンITRのコストを支払います。これにより、OITRD展開のビジネスモデルが提供され、コストの不公平な分配が回避されます。
o Existing source address filtering arrangements at BRs of ISPs and end-user networks are prohibitively expensive to implement directly in ETRs, but with the outer header's source address being the same as the sending host's address, Ivip ETRs inexpensively enforce BR filtering on decapsulated packets.
o ISPSおよびエンドユーザーネットワークのBRSでの既存のソースアドレスフィルタリングの配置は、ETRに直接実装するのに非常に高価ですが、外側のヘッダーのソースアドレスは送信ホストのアドレスと同じであるため、IVIP ETRは脱カプセル化パケットでBRフィルタリングを許可します。
QSDs receive all mapping changes and store a complete copy of the mapping database. However, a worst-case scenario is 10 billion IPv6 mappings, each of 32 bytes, which fits on a consumer hard drive today and should fit in server DRAM by the time such adoption is reached.
QSDはすべてのマッピングの変更を受信し、マッピングデータベースの完全なコピーを保存します。ただし、最悪のシナリオは100億のIPv6マッピングであり、それぞれ32バイトで、今日の消費者ハードドライブに適合し、そのような採用に達するまでにサーバーDRAMに収まるはずです。
The maximum number of non-mobile networks requiring multihoming, etc., is likely to be ~10 million, so most of the 10 billion mappings would be for mobile devices. However, TTR mobility does not involve frequent mapping changes since most MNs only rarely move more than 1000 km.
マルチホミングなどを必要とする非モバイルネットワークの最大数は1,000万人である可能性が高いため、100億マッピングのほとんどはモバイルデバイス用です。ただし、TTRモビリティには、ほとんどのMNSが1000 km以上移動することはめったにないため、頻繁なマッピングの変化は含まれません。
[Ivip_EAF] [Ivip_PMTUD] [Ivip_PLF] [Ivip_Constraints] [Ivip_Mobility] [Ivip_DRTM] [Ivip_Glossary]
[ivip_eaf] [ivip_pmtud] [ivip_plf] [ivip_constraints] [ivip_mobility] [ivip_drtm] [ivip_glossary]
Looked at from the thousand-foot level, Ivip shares the basic design approaches with LISP and a number of other map-and-encap designs based on the Core-Edge Separation. However, the details differ substantially. Ivip's design makes a bold assumption that, with technology advances, one could afford to maintain a real-time distributed global mapping database for all networks and hosts. Ivip proposes that multiple parties collaborate to build a mapping distribution system that pushes all mapping information and updates to local, full-database query servers located in all ISPs within a few seconds. The system has no single point of failure and uses end-to-end authentication.
1000フィートのレベルから見ると、IVIPはLISPと基本的なデザインアプローチと、コアエッジの分離に基づいて他の多くのマップアンドENCAPデザインを共有しています。ただし、詳細は大幅に異なります。IVIPの設計は、テクノロジーの進歩により、すべてのネットワークとホストのリアルタイム分散グローバルマッピングデータベースを維持する余裕があると大胆に仮定します。IVIPは、複数の当事者が協力して、すべてのマッピング情報と更新をすべてのISPに数秒以内にあるローカルフルデータベースサーバーにプッシュするマッピング配信システムを構築することを提案しています。システムには単一の障害点がなく、エンドツーエンド認証を使用します。
A "real time, globally synchronized mapping database" is a critical assumption in Ivip. Using that as a foundation, Ivip design avoids several challenging design issues that others have studied extensively, that include
「リアルタイム、グローバルに同期したマッピングデータベース」は、IVIPの重要な仮定です。IVIPデザインは、それを基盤として使用して、他の人が広範囲に研究したいくつかの挑戦的なデザインの問題を回避します。
1. special considerations of mobility support that add additional complexity to the overall system;
1. システム全体に複雑さを追加するモビリティサポートの特別な考慮事項。
2. prompt detection of ETR failures and notification to all relevant ITRs, which turns out to be a rather difficult problem; and
2. ETR障害の迅速な検出とすべての関連するITRへの通知は、かなり困難な問題であることが判明しました。と
3. development of a partial-mapping lookup sub-system. Ivip assumes the existence of local query servers with a full database with the latest mapping information changes.
3. 部分マッピングルックアップサブシステムの開発。IVIPは、最新のマッピング情報が変更された完全なデータベースを備えたローカルクエリサーバーの存在を想定しています。
To be considered as a viable solution to the Internet routing scalability problem, Ivip faces two fundamental questions. First, whether a global-scale system can achieve real-time synchronized operations as assumed by Ivip is an entirely open question. Past experiences suggest otherwise.
IVIPは、インターネットルーティングスケーラビリティの問題に対する実行可能なソリューションと見なされるために、2つの基本的な質問に直面しています。第一に、IVIPが想定しているように、グローバルスケールシステムがリアルタイム同期操作を実現できるかどうかは、完全に開かれた問題です。過去の経験はそうではないことを示唆しています。
The second question concerns incremental rollout. Ivip represents an ambitious approach, with real-time mapping and local full-database query servers -- which many people regard as impossible. Developing and implementing Ivip may take a fair amount of resources, yet there is an open question regarding how to quantify the gains by first movers -- both those who will provide the Ivip infrastructure and those that will use it. Significant global routing table reduction only happens when a large enough number of parties have adopted Ivip. The same question arises for most other proposals as well.
2番目の質問は、増分ロールアウトに関するものです。IVIPは、リアルタイムマッピングとローカルフルダタベースクエリサーバーを備えた野心的なアプローチを表しています。これは、多くの人が不可能と見なしています。IVIPの開発と実装にはかなりの量のリソースが必要な場合がありますが、IVIPインフラストラクチャを提供する人とそれを使用する人の両方が、最初の発動者による利益を定量化する方法については公開されています。大幅なグローバルルーティングテーブルの削減は、十分な数の当事者がIVIPを採用した場合にのみ発生します。他のほとんどの提案にも同じ質問が生じます。
One belief is that Ivip's more ambitious mapping system makes a good design tradeoff for the greater benefits for end-user networks and for those that develop the infrastructure. Another belief is that this ambitious design is not viable.
1つの信念は、IVIPのより野心的なマッピングシステムは、エンドユーザーネットワークやインフラストラクチャを開発する人々にとってより大きな利点にとって優れたデザイントレードオフになるということです。別の信念は、この野心的なデザインは実行可能ではないということです。
Since the Summary and Critique were written, Ivip's mapping system has been significantly redesigned: DRTM - Distributed Real Time Mapping [Ivip_DRTM].
概要と批評が書かれて以来、IVIPのマッピングシステムは大幅に再設計されています：DRTM-分散リアルタイムマッピング[IVIP_DRTM]。
DRTM makes it easier for ISPs to install their own ITRs. It also facilitates Mapped Address Block (MAB) operating companies -- which need not be ISPs -- leasing Scalable Provider-Independent (SPI) address space to end-user networks with almost no ISP involvement. ISPs need not install ITRs or ETRs. For an ISP to support its customers using SPI space, they need only allow the forwarding of outgoing packets whose source addresses are from SPI space. End-user networks can implement their own ETRs on their existing PA address(es) -- and MAB operating companies make all the initial investments.
DRTMを使用すると、ISPが独自のITRを簡単にインストールできます。また、ISPではないマッピングされたアドレスブロック（MAB）オペレーティング会社を容易にします。これは、ISPの関与がほとんどないエンドユーザーネットワークにスケーラブルプロバイダーに依存しない（SPI）アドレススペースをリースします。ISPはITRまたはETRをインストールする必要はありません。ISPがSPIスペースを使用して顧客をサポートするには、ソースアドレスがSPIスペースからの発信パケットの転送のみを許可する必要があります。エンドユーザーネットワークは、既存のPAアドレス（ES）に独自のETRを実装でき、MAB運営会社はすべての初期投資を行います。
Once SPI adoption becomes widespread, ISPs will be motivated to install their own ITRs to locally tunnel packets that are sent from customer networks and that must be tunneled to SPI-using customers of the same ISP -- rather than letting these packets exit the ISP's network and return in tunnels to ETRs in the network.
SPIの採用が広くなると、ISPは顧客ネットワークから送信されるローカルトンネルパケットに独自のITRをインストールするように動機付けられ、これらのパケットがISPのネットワークを終了できるのではなく、同じISPの顧客をスパイユースする必要があります。トンネルでネットワーク内のETRに戻ります。
There is no need for full-database query servers in ISPs or for any device that stores the full mapping information for all Mapped Address Blocks (MABs). ISPs that want ITRs will install two or more Map Resolver (MR) servers. These are caching query servers which query multiple (typically nearby) query servers that are full-database for the subset of MABs they serve. These "nearby" query servers will be at DITR sites, which will be run by, or for, MAB operating companies who lease MAB space to large numbers of end-user networks. These DITR-site servers will usually be close enough to the MRs to generate replies with sufficiently low delay and risk of packet loss for ITRs to buffer initial packets for a few tens of milliseconds while the mapping arrives.
ISPのフルデータベースクエリサーバーや、すべてのマッピングされたアドレスブロック（MAB）の完全なマッピング情報を保存するデバイスは必要ありません。ITRを必要とするISPは、2つ以上のMAP Resolver（MR）サーバーをインストールします。これらは、提供するMABのサブセットのフルデータベースである複数の（通常は近くの）クエリサーバーをクエリするキャッシュクエリサーバーです。これらの「近くの」クエリサーバーは、DITRサイトで行われます。DITRサイトは、MABのエンドユーザーネットワークにMABスペースをリースするMAB運営会社によって実行されるか、またはMAB運営会社のために実行されます。これらのDITRサイトサーバーは通常、MRSに十分近く、マッピングが到着している間に数十ミリ秒間初期パケットをバッファリングするITRのパケット損失の十分な遅延とリスクを伴う応答を生成するのに十分なほど近くなります。
DRTM will scale to billions of micronets, tens of thousands of MABs, and potentially hundreds of MAB operating companies, without single points of failure or central coordination.
DRTMは、数十億のミクロネット、数万のMAB、および潜在的に数百のMABオペレーティング会社にスケーリングし、単一の障害または中央調整なしに。
The critique implies a threshold of adoption is required before significant routing scaling benefits occur. This is untrue of any Core-Edge Separation proposal, including LISP and Ivip. Both can achieve scalable routing benefits in direct proportion to their level of adoption by providing portability, multihoming, and inbound TE to large numbers of end-user networks.
批評は、重要なルーティングスケーリングの利点が発生する前に、採用のしきい値が必要であることを意味します。これは、LISPやIVIPを含むコアエッジ分離提案の真実ではありません。どちらも、多数のエンドユーザーネットワークに移植性、マルチホーム、およびインバウンドTEを提供することにより、採用レベルに直接比例してスケーラブルなルーティングの利点を達成できます。
Core-Edge Elimination (CEE) architectures require all Internet communications to change to IPv6 with a new locator/identifier separation naming model. This would impose burdens of extra management effort, packets, and session establishment delays on all hosts -- which is a particularly unacceptable burden on battery-operated mobile hosts that rely on wireless links.
コアエッジエリミネーション（CEE）アーキテクチャでは、新しいロケーター/識別子分離命名モデルを使用して、すべてのインターネット通信がIPv6に変更する必要があります。これにより、すべてのホストに追加の管理努力、パケット、セッションの確立の遅れが課せられます。これは、ワイヤレスリンクに依存するバッテリー操作のモバイルホストに特に容認できない負担です。
Core-Edge Separation architectures retain the current, efficient, naming model, require no changes to hosts, and support both IPv4 and IPv6. Ivip is the most promising architecture for future development because its scalable, distributed, real-time mapping system best supports TTR mobility, enables ITRs to be simpler, and gives real-time control of ITR tunneling to the end-user network or to organizations they appoint to control the mapping of their micronets.
コアエッジ分離アーキテクチャは、現在の効率的な命名モデルを保持し、ホストに変更を必要とせず、IPv4とIPv6の両方をサポートします。IVIPは、スケーラブルで分散型のリアルタイムマッピングシステムがTTRモビリティをサポートし、ITRをよりシンプルにすることを可能にし、エンドユーザーネットワークまたは組織へのITRトンネルのリアルタイム制御を提供するため、将来の開発のための最も有望なアーキテクチャです。ミクロネットのマッピングを制御するために任命します。
The Hierarchical IPv4 Framework (hIPv4) adds scalability to the routing architecture by introducing additional hierarchy in the IPv4 address space. The IPv4 addressing scheme is divided into two parts, the Area Locator (ALOC) address space, which is globally unique, and the Endpoint Locator (ELOC) address space, which is only regionally unique. The ALOC and ELOC prefixes are added as a shim header between the IP header and transport protocol header; the shim header is identified with a new protocol number in the IP header. Instead of creating a tunneling (i.e., overlay) solution, a new routing element is needed in the service provider's routing domain (called ALOC realm) -- a Locator Swap Router. The current IPv4 forwarding plane remains intact, and no new routing protocols, mapping systems, or caching solutions are required. The control plane of the ALOC realm routers needs some modification in order for ICMP to be compatible with the hIPv4 framework. When an area (one or several autonomous systems (ASes)) of an ISP has transformed into an ALOC realm, only ALOC prefixes are exchanged with other ALOC realms. Directly attached ELOC prefixes are only inserted to the RIB of the local ALOC realm; ELOC prefixes are not distributed to the DFZ. Multihoming can be achieved in two ways, either the enterprise requests an ALOC prefix from the RIR (this is not recommended) or the enterprise receives the ALOC prefixes from their upstream ISPs. ELOC prefixes are PI addresses and remain intact when an upstream ISP is changed; only the ALOC prefix is replaced. When the RIB of the DFZ is compressed (containing only ALOC prefixes), ingress routers will no longer know the availability of the destination prefix; thus, the endpoints must take more responsibility for their sessions. This can be achieved by using multipath enabled transport protocols, such as SCTP [RFC4960] and Multipath TCP (MPTCP) [MPTCP_Arch], at the endpoints. The multipath transport protocols also provide a session identifier, i.e., verification tag or token; thus, the location and identifier split is carried out -- site mobility, endpoint mobility, and mobile site mobility are achieved. DNS needs to be upgraded: in order to resolve the location of an endpoint, the endpoint must have one ELOC value (current A-record) and at least one ALOC value in DNS (in multihoming solutions there will be several ALOC values for an endpoint).
階層IPv4フレームワーク（HIPV4）は、IPv4アドレス空間に追加の階層を導入することにより、ルーティングアーキテクチャにスケーラビリティを追加します。IPv4アドレス指定スキームは、グローバルに一意のエリアロケーター（ALOC）アドレススペースと、エンドポイントロケーター（ELOC）アドレススペースの2つの部分に分割されます。ALOCおよびELOCプレフィックスは、IPヘッダーとトランスポートプロトコルヘッダーの間にシムヘッダーとして追加されます。シムヘッダーは、IPヘッダーの新しいプロトコル番号で識別されます。トンネリング（つまり、オーバーレイ）ソリューションを作成する代わりに、サービスプロバイダーのルーティングドメイン（ALOC Realmと呼ばれる）（ロケータースワップルーター）に新しいルーティング要素が必要です。現在のIPv4転送面はそのままのままであり、新しいルーティングプロトコル、マッピングシステム、またはキャッシュソリューションは必要ありません。ALOC Realmルーターの制御面では、ICMPがHIPV4フレームワークと互換性を持つためには、いくらかの変更が必要です。ISPの領域（1つまたは複数の自律システム（ASE））がALOCレルムに変換された場合、ALOCプレフィックスのみが他のALOCレルムと交換されます。直接接続されたELOCプレフィックスは、ローカルアロックレルムのrib骨のみに挿入されます。ELOCプレフィックスはDFZに分布していません。マルチホームは、エンタープライズがRIRからALOCプレフィックスを要求するか（これは推奨されない）、またはエンタープライズが上流ISPからALOCプレフィックスを受信する2つの方法で実現できます。ELOCプレフィックスはPIアドレスであり、上流のISPが変更されている場合はそのままのままです。ALOCプレフィックスのみが交換されます。DFZのリブが圧縮されている場合（ALOCプレフィックスのみを含む）、イングレスルーターは宛先プレフィックスの可用性を知りません。したがって、エンドポイントはセッションに対してより多くの責任を負わなければなりません。これは、エンドポイントで、SCTP [RFC4960]やMultiPath TCP（MPTCP）[MPTCP_ARCH]などのマルチパス対応輸送プロトコルを使用することで実現できます。マルチパス輸送プロトコルは、セッション識別子、つまり検証タグまたはトークンも提供します。したがって、サイトのモビリティ、エンドポイントモビリティ、モバイルサイトのモビリティが達成されます。DNSをアップグレードする必要があります。エンドポイントの位置を解決するには、エンドポイントには1つのELOC値（現在のAレコード）が必要です。）。
1. Improved routing scalability: Adding additional hierarchy to the address space enables more hierarchy in the routing architecture. Early adapters of an ALOC realm will no longer carry the current RIB of the DFZ -- only ELOC prefixes of their directly attached networks and ALOC prefixes from other service providers that have migrated are installed in the ALOC realm's RIB.
1. ルーティングのスケーラビリティの改善：アドレス空間に追加の階層を追加すると、ルーティングアーキテクチャでより多くの階層が可能になります。ALOC領域の初期アダプターは、DFZの現在のrib骨を運びません - 移行した他のサービスプロバイダーからの直接接続されたネットワークとALOCプレフィックスのELOCプレフィックスのみがALOCレルムのrib骨に設置されます。
2. Scalable support for traffic engineering: Multipath enabled transport protocols are recommended to achieve dynamic load-balancing of a session. Support for Valiant Load-balancing (VLB) [Valiant] schemes has been added to the framework; more research work is required around VLB switching.
2. トラフィックエンジニアリングのスケーラブルなサポート：マルチパス対応の輸送プロトコルは、セッションの動的な負荷分散を実現するために推奨されます。Valiant Load-Balancing（VLB）[Valiant]スキームのサポートがフレームワークに追加されました。VLBの切り替えには、さらなる研究作業が必要です。
3. Scalable support for multihoming: Only attachment points of a multihomed site are advertised (using the ALOC prefix) in the DFZ. DNS will inform the requester on how many attachment points the destination endpoint has. It is the initiating endpoint's choice/responsibility to choose which attachment point is used for the session; endpoints using multipath-enabled transport protocols can make use of several attachment points for a session.
3. マルチホームのスケーラブルなサポート：DFZのマルチホームサイトのアタッチメントポイントのみが（ALOCプレフィックスを使用）宣伝されています。DNSは、宛先エンドポイントが持っている添付ファイルポイントの数を要求者に通知します。セッションに使用される添付ファイルポイントを選択するのは、エンドポイントの選択/責任を開始することです。マルチパス対応トランスポートプロトコルを使用するエンドポイントは、セッションにいくつかの添付ポイントを使用できます。
4. Simplified Renumbering: When changing provider, the local ELOC prefixes remains intact; only the ALOC prefix is changed at the endpoints. The ALOC prefix is not used for routing or forwarding decisions in the local network.
4. 簡略化された変更：プロバイダーを変更する場合、ローカルELOCプレフィックスはそのままです。ALOCプレフィックスのみがエンドポイントで変更されます。ALOCプレフィックスは、ローカルネットワークでのルーティングまたは転送の決定には使用されません。
5. Decoupling Location and Identifier: The verification tag (SCTP) and token (MPTCP) can be considered to have the characteristics of a session identifier, and thus a session layer is created between the transport and application layers in the TCP/IP model.
5. 分離位置と識別子：検証タグ（SCTP）とトークン（MPTCP）は、セッション識別子の特性を持つと見なすことができ、したがって、TCP/IPモデルの輸送層とアプリケーション層の間にセッション層が作成されます。
6. Routing quality: The hIPv4 framework introduces no tunneling or caching mechanisms. Only a swap of the content in the IPv4 header and locator header at the destination ALOC realm is required; thus, current routing and forwarding algorithms are preserved as such. Valiant Load-balancing might be used as a new forwarding mechanism.
6. ルーティング品質：HIPV4フレームワークでは、トンネルやキャッシュメカニズムが導入されません。宛先ALOCレルムのIPv4ヘッダーとロケーターヘッダーのコンテンツの交換のみが必要です。したがって、現在のルーティングおよび転送アルゴリズムは保存されます。勇敢な負荷分散は、新しい転送メカニズムとして使用される場合があります。
7. Routing Security: Similar as with today's DFZ, except that ELOC prefixes cannot be hijacked (by injecting a longest match prefix) outside an ALOC realm.
7. ルーティングセキュリティ：今日のDFZと同様ですが、ALOCレルムの外側でELOCプレフィックスをハイジャックできないことを除いて（最長の一致プレフィックスを注入することで）。
8. Deployability: The hIPv4 framework is an evolution of the current IPv4 framework and is backwards compatible with the current IPv4 framework. Sessions in a local network and inside an ALOC realm might in the future still use the current IPv4 framework.
8. 展開可能性：HIPV4フレームワークは、現在のIPv4フレームワークの進化であり、現在のIPv4フレームワークとの逆方向に互換性があります。ローカルネットワークおよびALOCレルム内のセッションは、将来、現在のIPv4フレームワークを使用する可能性があります。
1. Upgrade of the stack at an endpoint that is establishing sessions outside the local ALOC realm.
1. ローカルALOCレルムの外側にセッションを確立しているエンドポイントでのスタックのアップグレード。
2. In a multihoming solution, the border routers should be able to apply policy-based routing upon the ALOC value in the locator header.
2. マルチホームソリューションでは、ボーダールーターは、ロケーターヘッダーのALOC値にポリシーベースのルーティングを適用できるはずです。
3. New IP allocation policies must be set by the RIRs.
3. 新しいIP割り当てポリシーは、RIRSによって設定する必要があります。
4. There is a short timeframe before the expected depletion of the IPv4 address space occurs.
4. IPv4アドレススペースが予想される枯渇が発生するまで、短い時間枠があります。
5. Will enterprises give up their current globally unique IPv4 address block allocation they have gained?
5. 企業は、現在のグローバルに一意のIPv4アドレスブロック割り当てを放棄しますか？
6. Coordination with MPTCP is highly desirable.
6. MPTCPとの調整は非常に望ましいです。
[hIPv4] [Valiant]
[hipv4] [Valiant]
hIPv4 is an innovative approach to expanding the IPv4 addressing system in order to resolve the scalable routing problem. This critique does not attempt a full assessment of hIPv4's architecture and mechanisms. The only question addressed here is whether hIPv4 should be chosen for IETF development in preference to, or together with, the only two proposals which appear to be practical solutions for IPv4: Ivip and LISP.
HIPV4は、スケーラブルなルーティングの問題を解決するために、IPv4アドレス指定システムを拡張するための革新的なアプローチです。この批評は、HIPV4のアーキテクチャとメカニズムの完全な評価を試みません。ここで扱われている唯一の質問は、IPv4：IVIPとLISPの実用的なソリューションと思われる2つの提案を好む、またはそれと一緒にIETF開発のためにHIPV4を選択する必要があるかどうかです。
Ivip and LISP appear to have a major advantage over hIPv4 in terms of support for packets sent from non-upgraded hosts/networks. Ivip's DITRs (Default ITRs in the DFZ) and LISP's PTRs (Proxy Tunnel Routers) both accept packets sent by any non-upgraded host/network and tunnel them to the correct ETR -- thus providing the full benefits of portability, multihoming, and inbound TE for these packets as well as those sent by hosts in networks with ITRs. hIPv4 appears to have no such mechanism, so these benefits are only available for communications between two upgraded hosts in upgraded networks.
IVIPとLISPは、アップグレードされていないホスト/ネットワークから送信されたパケットのサポートに関して、HIPV4よりも大きな利点があるようです。IVIPのDITR（DFZのデフォルトITR）とLISPのPTRS（プロキシトンネルルーター）はどちらも、アップグレードされていないホスト/ネットワークから送信されたパケットを受け入れ、それらを正しいETRにトンネルします。これらのパケットと、ITRを使用してネットワークでホストから送信されたパケットのTE。HIPV4にはそのようなメカニズムがないように見えるため、これらの利点は、アップグレードされたネットワークの2つのアップグレードされたホスト間の通信のみで利用できます。
This means that significant benefits for adopters -- the ability to rely on the new system to provide the portability, multihoming, and inbound TE benefits for all, or almost all, their communications -- will only arise after all, or almost all, networks upgrade their networks, hosts, and addressing arrangements. hIPv4's relationship between adoption levels and benefits to any adopter therefore are far less favorable to widespread adoption than those of Core-Edge Separation (CES) architectures such as Ivip and LISP.
これは、採用者にとって大きな利点 - 新しいシステムに依存して、すべての、またはほとんどすべてのコミュニケーションにポータビリティ、マルチホーム、およびインバウンドの利点を提供する能力が、結局、またはほとんどすべてのネットワークのみが発生することを意味します。ネットワーク、ホスト、およびアドレス指定の取り決めをアップグレードします。したがって、HIPV4の養子縁組レベルと養子縁組の利点との関係は、IVIPやLISPなどのコアエッジ分離（CES）アーキテクチャの採用よりも広範囲にわたる採用に対してはるかに有利ではありません。
This results in hIPv4 also being at a disadvantage regarding the achievement of significant routing scaling benefits, which likewise will only result once adoption is close to ubiquitous. Ivip and LISP can provide routing scaling benefits in direct proportion to their level of adoption, since all adopters gain full benefits for all their communications, in a highly scalable manner.
これにより、HIPV4は、重要なルーティングスケーリングの利点の達成に関しても不利になります。同様に、採用がユビキタスに近い場合にのみ結果が得られます。IVIPとLISPは、すべての採用者が非常にスケーラブルな方法ですべての通信に対して完全な利点を獲得するため、採用レベルに直接比例してルーティングスケーリングの利点を提供できます。
hIPv4 requires stack upgrades, which are not required by any CES architecture. Furthermore, a large number of existing IPv4 application protocols convey IP addresses between hosts in a manner that will not work with hIPv4: "There are several applications that are inserting IP address information in the payload of a packet. Some applications use the IP address information to create new sessions or for identification purposes. This section is trying to list the applications that need to be enhanced; however, this is by no means a comprehensive list" [hIPv4].
HIPV4には、CESアーキテクチャでは必要とされないスタックアップグレードが必要です。さらに、多数の既存のIPv4アプリケーションプロトコルは、HIPV4で動作しない方法でホスト間でIPアドレスを伝えます。新しいセッションを作成するか、識別目的で目的とするために。このセクションでは、強化する必要があるアプリケーションをリストしようとしていますが、これは決して包括的なリストではありません」[HIPV4]。
If even a few widely used applications would need to be rewritten to operate successfully with hIPv4, then this would be such a disincentive to adoption to rule out hIPv4 ever being adopted widely enough to solve the routing scaling problem, especially since CES architectures fully support all existing protocols, without the need for altering host stacks.
いくつかの広く使用されているアプリケーションでさえ、HIPV4で正常に動作するために書き直す必要がある場合、これは、特にCESアーキテクチャがすべてを完全にサポートするため、ルーティングスケーリングの問題を完全に解決するのに十分なほど広く採用されているHIPV4を除外するために採用することを非常に阻害するでしょうホストスタックを変更する必要のない既存のプロトコル。
It appears that hIPv4 involves major practical difficulties, which mean that in its current form it is not suitable for IETF development.
HIPV4には大きな実用的な困難が含まれているように見えます。つまり、現在の形ではIETF開発には適していないことを意味します。
No rebuttal was submitted for this proposal.
この提案のために反論は提出されませんでした。
The basic idea is to add a name overlay (NOL) onto the existing TCP/IP stack.
基本的なアイデアは、既存のTCP/IPスタックに名前オーバーレイ（NOL）を追加することです。
Its functions include:
その機能には次のものが含まれます。
1. Managing host name configuration, registration, and authentication;
1. ホスト名の構成、登録、および認証の管理。
2. Initiating and managing transport connection channels (i.e., TCP/IP connections) by name;
2. 名前でトランスポート接続チャネル（つまり、TCP/IP接続）の開始と管理。
3. Keeping application data transport continuity for mobility.
3. モビリティのアプリケーションデータ輸送の継続性を維持します。
At the edge network, we introduce a new type of gateway, a Name Transfer Relay (NTR), which blocks the PI addresses of edge networks into upstream transit networks. NTRs perform address and/or port translation between blocked PI addresses and globally routable addresses, which seem like today's widely used NAT / Network Address Port Translation (NAPT) devices. Both legacy and NOL applications behind a NTR can access the outside as usual. To access the hosts behind a NTR from outside, we need to use NOL to traverse the NTR by name and initiate connections to the hosts behind it.
Edge Networkでは、新しいタイプのゲートウェイ、名前転送リレー（NTR）を導入し、エッジネットワークのPIアドレスをアップストリームトランジットネットワークにブロックします。NTRは、ブロックされたPIアドレスとグローバルにルーティング可能なアドレスとの間のアドレスおよび /またはポート翻訳を実行します。NTRの背後にあるレガシーとNOLの両方のアプリケーションは、通常どおり外部にアクセスできます。外部からNTRの背後にあるホストにアクセスするには、NOLを使用して名前でNTRを通過し、その背後にあるホストへの接続を開始する必要があります。
Different from proposed host-based ID/locator split solutions, such as HIP, Shim6, and name-oriented stack, NOL doesn't need to change the existing TCP/IP stack, sockets, or their packet formats. NOL can coexist with the legacy infrastructure, and the Core-Edge Separation solutions (e.g., APT, LISP, Six/One, Ivip, etc.).
HIP、SHIM6、名前指向のスタックなど、提案されているホストベースのID/ロケータースプリットソリューションとは異なり、NOLは既存のTCP/IPスタック、ソケット、またはパケット形式を変更する必要はありません。NOLは、レガシーインフラストラクチャとコアエッジ分離ソリューション（APT、LISP、6/1、IVIPなど）と共存できます。
1. Reduce routing table size: Prevent edge network PI address from leaking into the transit network by deploying gateway NTRs.
1. ルーティングテーブルサイズの削減：ゲートウェイNTRを展開して、エッジネットワークPIアドレスがトランジットネットワークに漏れないようにします。
2. Traffic Engineering: For legacy and NOL application sessions, the incoming traffic can be directed to a specific NTR by DNS. In addition, for NOL applications, initial sessions can be redirected from one NTR to other appropriate NTRs. These mechanisms provide some support for traffic engineering.
2. トラフィックエンジニアリング：レガシーおよびNOLアプリケーションセッションの場合、着信トラフィックはDNSによって特定のNTRに向けられます。さらに、NOLアプリケーションの場合、初期セッションは1つのNTRから他の適切なNTRにリダイレクトできます。これらのメカニズムは、交通工学をサポートしています。
3. Multihoming: When a PI addressed network connects to the Internet by multihoming with several providers, it can deploy NTRs to prevent the PI addresses from leaking into provider networks.
3. Multihoming：PIアドレス指定されたネットワークが複数のプロバイダーとマルチホミングによってインターネットに接続すると、PIアドレスがプロバイダーネットワークに漏れないようにNTRを展開できます。
4. Transparency: NTRs can be allocated PA addresses from the upstream providers and store them in NTRs' address pool. By DNS query or NOL session, any session that wants to access the hosts behind the NTR can be delegated to a specific PA address in the NTR address pool.
4. 透明性：NTRは、上流のプロバイダーからPAアドレスを割り当て、NTRSのアドレスプールに保存できます。DNSクエリまたはNOLセッションでは、NTRの背後にあるホストにアクセスしたいセッションは、NTRアドレスプールの特定のPAアドレスに委任できます。
5. Mobility: The NOL layer manages the traditional TCP/IP transport connections, and provides application data transport continuity by checkpointing the transport connection at sequence number boundaries.
5. モビリティ：NOLレイヤーは、従来のTCP/IPトランスポート接続を管理し、シーケンス番号境界で輸送接続をチェックポイントすることにより、アプリケーションデータ輸送の連続性を提供します。
6. No need to change TCP/IP stack, sockets, or DNS system.
6. TCP/IPスタック、ソケット、またはDNSシステムを変更する必要はありません。
7. No need for extra mapping system.
7. 追加のマッピングシステムは必要ありません。
8. NTR can be deployed unilaterally, just like NATs.
8. NTRは、NATと同じように、一方的に展開できます。
9. NOL applications can communicate with legacy applications.
9. NOLアプリケーションは、レガシーアプリケーションと通信できます。
10. NOL can be compatible with existing solutions, such as APT, LISP, Ivip, etc.
10. NOLは、APT、LISP、IVIPなどの既存のソリューションと互換性があります。
11. End-user-controlled multipath indirect routing based on distributed NTRs. This will give benefits to the performance-aware applications, such as video streaming, applications on MSN.com, etc.
11. 分散NTRに基づくエンドユーザー制御マルチパス間接ルーティング。これにより、ビデオストリーミング、MSN.comのアプリケーションなど、パフォーマンスが認識されるアプリケーションに利点が得られます。
1. Legacy applications have trouble with initiating access to the servers behind NTR. Such trouble can be resolved by deploying the NOL proxy for legacy hosts, or delegating globally routable PA addresses in the NTR address pool for these servers, or deploying a proxy server outside the NTR.
1. レガシーアプリケーションは、NTRの背後にあるサーバーへのアクセスを開始するのに問題があります。このようなトラブルは、レガシーホストのNOLプロキシを展開するか、これらのサーバーのNTRアドレスプールでグローバルにルーティング可能なPAアドレスを委任するか、NTRの外側にプロキシサーバーを展開することで解決できます。
2. NOL may increase the number of entries in DNS, but it is not drastic because it only increases the number of DNS records at domain granularity not the number of hosts. The name used in NOL, for example, is similar to an email address hostname@example.net. The needed DNS entries and query are just for "example.net", and the NTR knows the "hostnames". Not only will the number of DNS records be increased, but the dynamics of DNS might be agitated as well. However, the scalability and performance of DNS are guaranteed by its naming hierarchy and caching mechanisms.
2. NOLはDNSのエントリの数を増やす可能性がありますが、ホストの数ではなくドメインの粒度でDNSレコードの数のみを増やすため、劇的ではありません。たとえば、NOLで使用される名前は、メールアドレスhostname@example.netに似ています。必要なDNSエントリとクエリは「emple.net」専用であり、NTRは「ホスト名」を知っています。DNSレコードの数が増加するだけでなく、DNSのダイナミクスも動揺する可能性があります。ただし、DNSのスケーラビリティとパフォーマンスは、その命名階層とキャッシュメカニズムによって保証されます。
3. Address translating/rewriting costs on NTRs.
3. NTRの翻訳/書き換えコストを住所します。
No references were submitted.
参照は提出されていません。
1. Applications on hosts need to be rebuilt based on a name overlay library to be NOL-enabled. The legacy software that is not maintained will not be able to benefit from NOL in the Core-Edge Elimination situation. In the Core-Edge Separation scheme, a new gateway NTR is deployed to prevent edge-specific PI prefixes from leaking into the transit core. NOL doesn't impede the legacy endpoints behind the NTR from accessing the outside Internet, but the legacy endpoints cannot access or will have difficultly accessing the endpoints behind a NTR without the help of NOL.
1. ホストのアプリケーションは、NOL対応になるように名前のオーバーレイライブラリに基づいて再構築する必要があります。維持されていないレガシーソフトウェアは、コアエッジエリミネーションの状況ではNOLの恩恵を受けることはできません。コアエッジ分離スキームでは、新しいゲートウェイNTRが展開され、エッジ固有のPIプレフィックスが通過コアに漏れないようにします。NOLは、NTRの背後にあるレガシーエンドポイントを外部インターネットへのアクセスを妨げませんが、レガシーエンドポイントはNOLの助けなしにNTRの背後にあるエンドポイントにアクセスできないか、困難になります。
2. In the case of Core-Edge Elimination, the end site will be assigned multiple PA address spaces, which leads to renumbering troubles when switching to other upstream providers. Upgrading endpoints to support NOL doesn't give any benefits to edge networks. Endpoints have little incentive to use NOL in a Core-Edge Elimination scenario, and the same is true with other host-based ID/locator split proposals. Whether they are IPv4 or IPv6 networks, edge networks prefer PI address space to PA address space.
2. コアエッジの排除の場合、エンドサイトには複数のPAアドレススペースが割り当てられ、他のアップストリームプロバイダーに切り替える際に問題のある問題につながります。NOLをサポートするためのエンドポイントのアップグレードは、Edgeネットワークに利点を与えません。エンドポイントには、コアエッジエリミネーションシナリオでNOLを使用するインセンティブはほとんどなく、他のホストベースのID/ロケータースプリット提案でも同じことが当てはまります。それらがIPv4であろうとIPv6ネットワークであろうと、エッジネットワークはPAアドレススペースをPIアドレススペースに好みます。
3. In the Core-Edge Separation scenario, the additional gateway NTR is to prevent the specific prefixes from the edge networks, just like a NAT or the ITR/ETR of LISP. A NTR gateway can be seen as an extension of NAT (Network Address Translation). Although NATs are deployed widely, upgrading them to support NOL extension or deploying additional new gateway NTRs at the edge networks is on a voluntary basis and has few economic incentives.
3. コアエッジ分離シナリオでは、追加のゲートウェイNTRは、LISPのNATまたはITR/ETRのように、特定のプレフィックスがエッジネットワークからの特定のプレフィックスを防ぐことです。NTRゲートウェイは、NATの拡張（ネットワークアドレス変換）と見なすことができます。NATは広く展開されていますが、NOL拡張をサポートするためにそれらをアップグレードするか、エッジネットワークで追加の新しいゲートウェイNTRを展開することは自発的であり、経済的インセンティブはほとんどありません。
4. The stateful or stateless translation for each packet traversing a NTR will require the cost of the CPU and memory of NTRs, and increase forwarding delay. Thus, it is not appropriate to deploy NTRs at the high-level transit networks where aggregated traffic may cause congestion at the NTRs.
4. NTRを通過する各パケットのステートレレスまたはステートレスの翻訳には、CPUのコストとNTRのメモリが必要になり、転送遅延が増加します。したがって、集約されたトラフィックがNTRで輻輳を引き起こす可能性のある高レベルのトランジットネットワークにNTRを展開することは適切ではありません。
5. In the Core-Edge Separation scenario, the requirement for multihoming and inter-domain traffic engineering will make end sites accessible via multiple different NTRs. For reliability, all of the associations between multiple NTRs and the end site name will be kept in DNS, which may increase the load on DNS.
5. コアエッジ分離シナリオでは、マルチホームおよびドメイン間トラフィックエンジニアリングの要件により、複数の異なるNTRを介してエンドサイトにアクセスできます。信頼性のために、複数のNTRとエンドサイト名との間のすべての関連付けはDNSに保持され、DNSの負荷が増加する可能性があります。
6. To support mobility, it is necessary for DNS to update the corresponding name-NTR mapping records when an end system moves from behind one NTR to another NTR. The NOL-enabled end relies on the NOL layer to preserve the continuity of the transport layer, since the underlying TCP/UDP transport session would be broken when the IP address changed.
6. モビリティをサポートするには、DNSがエンドシステムが1つのNTRの後ろから別のNTRに移動するときに、対応する名前-NTRマッピングレコードを更新する必要があります。NOL対応の端は、IPアドレスが変更されたときに基礎となるTCP/UDP輸送セッションが壊れるため、輸送層の連続性を保持するためにNOL層に依存しています。
NOL resembles neither CEE nor CES as a solution. By supporting application-level sessions through the name overlay layer, NOL can support some solutions in the CEE style. However, NOL is in general closer to CES solutions, i.e., preventing PI prefixes of edge networks from entering into the upstream transit networks. This is done by the NTR, like the ITRs/ETRs in CES solutions, but NOL has no need to define the clear boundary between core and edge networks. NOL is designed to try to provide end users or networks a service that facilitates the adoption of multihoming, multipath routing, and traffic engineering by the indirect routing through NTRs, and that, in the mean time, doesn't accelerate or decelerate the growth of global routing table size.
NOLは、CEEもCESも解決策として似ていません。オーバーレイレイヤーという名前を介してアプリケーションレベルのセッションをサポートすることにより、NOLはCEEスタイルのいくつかのソリューションをサポートできます。ただし、NOLは一般にCESソリューションに近いため、エッジネットワークのPIプレフィックスが上流のトランジットネットワークに入るのを防ぎます。これは、CESソリューションのITRS/ETRのようにNTRによって行われますが、NOLはコアネットワークとエッジネットワークの間の明確な境界を定義する必要はありません。NOLは、エンドユーザーまたはネットワークに、NTRを介した間接ルーティングによるマルチホーム、マルチパスルーティング、トラフィックエンジニアリングの採用を促進するサービスを提供しようとするように設計されており、その間、それは、の成長を加速または減速させません。グローバルルーティングテーブルサイズ。
Some problems are described in the NOL critique. In the original NOL proposal document, the DNS query for a host that is behind a NTR will induce the return of the actual IP addresses of the host and the address of the NTR. This arrangement might cause some difficulties for legacy applications due to the non-standard response from DNS. To resolve this problem, we instead have the NOL service use a new namespace, and have DNS not return NTR IP addresses for the legacy hosts. The names used for NOL are formatted like email addresses, such as "des@example.net". The mapping between "example.net" and the IP address of the corresponding NTR will be registered in DNS. The NOL layer will understand the meaning of the name "des@example.net" , and it will send a query to DNS only for "example.net". DNS will then return IP addresses of the corresponding NTRs. Legacy applications will still use the traditional FQDN name, and DNS will return the actual IP address of the host. However, if the host is behind a NTR, the legacy applications may be unable to access the host.
いくつかの問題はNOL批評に記載されています。元のNOL提案文書では、NTRの背後にあるホストのDNSクエリは、ホストの実際のIPアドレスとNTRのアドレスの返品を誘導します。この配置は、DNSからの非標準的な反応のために、レガシーアプリケーションにいくつかの困難を引き起こす可能性があります。この問題を解決するために、代わりにNOLサービスに新しい名前空間を使用させ、DNSにレガシーホストのNTR IPアドレスを返さないようにします。NOLに使用される名前は、「des@example.net」などのメールアドレスのようにフォーマットされます。「Example.Net」と対応するNTRのIPアドレスの間のマッピングは、DNSに登録されます。NOLレイヤーは、「des@example.net」という名前の意味を理解し、「embles.net」のみでクエリをDNSに送信します。DNSは、対応するNTRのIPアドレスを返します。レガシーアプリケーションは引き続き従来のFQDN名を使用し、DNSはホストの実際のIPアドレスを返します。ただし、ホストがNTRの背後にある場合、レガシーアプリケーションがホストにアクセスできない場合があります。
The stateless address translation or stateful address and port translation may cause a scaling problem with the number of table entries NTR must maintain, and legacy applications cannot initiate sessions with hosts inside the NOL-adopting End User Network (EUN). However, these problems may not be a big barrier for the deployment of NOL or other similar approaches. Many NAT-like boxes, proxy, and firewall devices are widely used at the ingress/egress points of enterprise networks, campus networks, or other stub EUNs. The hosts running as servers can be deployed outside NTRs or can be assigned PA addresses in an NTR-adopting EUN.
ステートレスアドレスの翻訳またはステートフルアドレスおよびポート翻訳は、NTRが維持する必要があるテーブルエントリの数にスケーリングの問題を引き起こす可能性があり、レガシーアプリケーションはNOL採用エンドユーザーネットワーク（EUN）内のホストとセッションを開始できません。ただし、これらの問題は、NOLまたは他の同様のアプローチの展開の大きな障壁ではない場合があります。多くのNATのようなボックス、プロキシ、およびファイアウォールデバイスは、エンタープライズネットワーク、キャンパスネットワーク、またはその他のスタブウンの入り口/出口ポイントで広く使用されています。サーバーとして実行されているホストは、NTRSの外部で展開するか、NTRを採用するEUNにPAアドレスを割り当てることができます。
This proposal (referred to here as "CRM") is to build a highly scalable locator identity mapping system using compact routing principles. This provides the means for dynamic topology adaption to facilitate efficient aggregation [CRM]. Map servers are assigned as cluster heads or landmarks based on their capability to aggregate EID announcements.
この提案（ここでは「CRM」と呼ばれます）は、コンパクトなルーティング原則を使用して、高度にスケーラブルなロケーターIDマッピングシステムを構築することです。これは、効率的な集計を促進するための動的トポロジー適応の手段を提供します[CRM]。MAPサーバーは、EIDアナウンスを集約する機能に基づいて、クラスターヘッドまたはランドマークとして割り当てられます。
o Minimizes the routing table sizes at the system level (i.e., map servers). Provides clear upper bounds for routing stretch that define the packet delivery delay of the map request / first packet.
o システムレベル（つまり、マップサーバー）でルーティングテーブルサイズを最小化します。マップリクエスト /ファーストパケットのパケット配信遅延を定義するルーティングストレッチの明確な上限を提供します。
o Organizes the mapping system based on the EID numbering space, minimizes the administrative overhead of managing the EID space. No need for administratively planned hierarchical address allocation as the system will find convergence into a set of EID allocations.
o EID番号のスペースに基づいてマッピングシステムを整理し、EIDスペースの管理の管理オーバーヘッドを最小限に抑えます。システムが一連のEID割り当てへの収束を見つけるため、管理上計画された階層アドレスの割り当ては必要ありません。
o Availability and robustness of the overall routing system (including xTRs and map servers) are improved because of the potential to use multiple map servers and direct routes without the involvement of map servers.
o マップサーバーの関与なしに複数のMAPサーバーとダイレクトルートを使用する可能性があるため、ルーティングシステム全体の可用性と堅牢性（XTRSおよびMAPサーバーを含む）が改善されます。
The scalability gains will materialize only in large deployments. If the stretch is bounded to those of compact routing (worst-case stretch less or equal to 3, on average, 1+epsilon), then each xTR needs to have memory/cache for the mappings of its cluster.
スケーラビリティゲインは、大規模な展開でのみ実現します。ストレッチがコンパクトなルーティングのストレッチ（平均で3以下の最悪のストレッチ、1 epsilon）に制限されている場合、各XTRにはクラスターのマッピングのメモリ/キャッシュが必要です。
[CRM]
[CRM]
The CRM proposal is not a complete proposal and therefore cannot be considered for further development by the IETF as a scalable routing solution.
CRMの提案は完全な提案ではないため、スケーラブルなルーティングソリューションとしてIETFによるさらなる開発を考慮することはできません。
While Compact Routing principles may be able to improve a mapping overlay structure such as LISP+ALT, there are several objections to this approach.
コンパクトルーティングの原則は、LISP ALTなどのマッピングオーバーレイ構造を改善できる場合がありますが、このアプローチにはいくつかの異議があります。
Firstly, a CRM-modified ALT structure would still be a global query server system. No matter how ALT's path lengths and delays are optimized, there is a problem with a querier -- which could be anywhere in the world -- relying on mapping information from one or ideally two or more authoritative query servers, which could also be anywhere in the world. The delays and risks of packet loss that are inherent in such a system constitute a fundamental problem. This is especially true when multiple, potentially long, traffic streams are received by ITRs and forwarded over the CRM networks for delivery to the destination network. ITRs must use the CRM infrastructure while they are awaiting a map reply. The traffic forwarded on the CRM infrastructure functions as map requests and can present a scalability and performance issue to the infrastructure.
第一に、CRM修飾ALT構造は、グローバルクエリサーバーシステムです。Altのパスの長さと遅延が最適化されていても、1つまたは理想的には2つ以上の権威あるクエリサーバーからの情報をマッピングすることに依存するクエリエに問題があります。世界。このようなシステムに固有のパケット損失の遅延とリスクは、基本的な問題を構成します。これは、複数の、潜在的に長いトラフィックストリームがITRによって受信され、宛先ネットワークへの配信のためにCRMネットワークに転送される場合に特に当てはまります。ITRは、CRMインフラストラクチャを使用して、マップの返信を待っている間に使用する必要があります。CRMインフラストラクチャに転送されたトラフィックは、MAPリクエストとして機能し、インフラストラクチャにスケーラビリティとパフォーマンスの問題を提示することができます。
Secondly, the alterations contemplated in this proposal involve the roles of particular nodes in the network being dynamically assigned as part of the network's self-organizing nature.
第二に、この提案で検討されている変更には、ネットワークの自己組織化の性質の一部として動的に割り当てられているネットワーク内の特定のノードの役割が含まれます。
The discussion of clustering in the middle of page 4 of [CRM] also indicates that particular nodes are responsible for registering EIDs from typically far-distant ETRs, all of which are handling closely related EIDs that this node can aggregate. Since MSes are apparently nodes within the compact routing system, and the process of an MS deciding whether to accept EID registrations is determined as part of the self-organizing properties of the system, there are concerns about how EID registration can be performed securely, when no particular physical node is responsible for it.
[CRM]の4ページの真ん中にあるクラスタリングの議論は、特定のノードが通常の遠方のETRからEIDを登録する責任があることも示しています。これらはすべて、このノードが集約できる密接に関連するEIDを処理しています。MSEはコンパクトルーティングシステム内のノードであるように見えるため、MSがEID登録を受け入れるかどうかを決定するプロセスは、システムの自己組織化特性の一部として決定されるため、EID登録を安全に実行する方法について懸念があります。特定の物理ノードが責任を負いません。
Thirdly, there are concerns about individually owned nodes performing work for other organizations. Such problems of trust and of responsibilities and costs being placed on those who do not directly benefit already exist in the inter-domain routing system and are a challenge for any scalable routing solution.
第三に、他の組織で作業を実行する個人所有のノードについて懸念があります。このような信頼の問題と、直接利益を得ていない人に課せられる責任とコストは、ドメイン間ルーティングシステムにすでに存在し、スケーラブルなルーティングソリューションにとって課題です。
There are simpler solutions to the mapping problem than having an elaborate network of routers. If a global-scale query system is still preferred, then it would be better to have ITRs use local MRs, each of which is dynamically configured to know the IP address of the million or so authoritative Map Server (MS) query servers -- or two million or so assuming they exist in pairs for redundancy.
マッピングの問題には、ルーターの精巧なネットワークを持つよりも、より簡単なソリューションがあります。グローバルスケールクエリシステムがまだ優先されている場合、ITRをローカルMRSを使用する方が良いでしょう。それぞれが、100万ほどの権威あるMAPサーバー（MS）クエリサーバーのIPアドレスを知るように動的に構成されています。それらが冗長性のためにペアに存在すると仮定して200万程度。
It appears that the inherently greater delays and risks of packet loss of global query server systems make them unsuitable mapping solutions for Core-Edge Elimination or Core-Edge Separation architectures. The solution to these problems appears to involve a greater number of widely distributed authoritative query servers, one or more of which will therefore be close enough to each querier that delays and risk of packet loss are reduced to acceptable levels. Such a structure would be suitable for map requests, but perhaps not for handling traffic packets to be delivered to the destination networks.
グローバルクエリサーバーシステムのパケット損失の本質的に大きな遅延とリスクにより、コアエッジエリミネーションまたはコアエッジ分離アーキテクチャのための不適切なマッピングソリューションにより、それらが不適切なマッピングソリューションになっているようです。これらの問題の解決策は、より広く分散された権威あるクエリサーバーの多くを伴うように思われます。したがって、パケット損失の遅延とリスクが許容レベルに減少する各クエリエに十分に近いものがあります。このような構造は、マップリクエストに適していますが、おそらくトラフィックパケットを宛先ネットワークに配信するための処理には適していません。
CRM is most easily understood as an alteration to the routing structure of the LISP+ALT mapping overlay system, by altering or adding to the network's BGP control plane.
CRMは、ネットワークのBGP制御プレーンを変更または追加することにより、LISP ALTマッピングオーバーレイシステムのルーティング構造の変更として最も簡単に理解されます。
CRM's aims include the delivery of initial traffic packets to their destination networks where they also function as map requests. These packet streams may be long and numerous in the fractions of a second to perhaps several seconds that may elapse before the ITR receives the map reply.
CRMの目的には、初期トラフィックパケットの宛先ネットワークへの配信が含まれ、そこでマップリクエストとしても機能します。これらのパケットストリームは、ITRがマップの返信を受信する前に経過する可能性のある1秒から数秒の画分で長く、多数ある場合があります。
Compact Routing principles are used to optimize the path length taken by these query or traffic packets through a significantly modified version of the ALT (or similar) network, while also generally reducing typical or maximum paths taken by the query packets.
コンパクトルーティングの原則は、これらのクエリまたはトラフィックパケットが取得したパス長を最適化して、ALT（または同様の）ネットワークの大幅に変更されたバージョンを介して最適化すると同時に、クエリパケットが取得した典型的または最大パスを削減するために使用されます。
An overlay network is a diversion from the shortest path. However, CMR limits this diversion and provides an upper bound. Landmark routers/servers could deliver more than just the first traffic packet, subject to their CPU capabilities and their network connectivity bandwidths.
オーバーレイネットワークは、最短経路からの転換です。ただし、CMRはこの転換を制限し、上限を提供します。ランドマークルーター/サーバーは、CPU機能とネットワーク接続帯域幅を条件として、最初のトラフィックパケット以上のものを提供できます。
The trust between the landmarks (mapping servers) can be built based on the current BGP relationships. Registration to the landmark nodes needs to be authenticated mutually between the MS and the system that is registering. This part is not documented in the proposal text.
ランドマーク（マッピングサーバー）間の信頼は、現在のBGP関係に基づいて構築できます。ランドマークノードへの登録は、MSと登録されているシステムの間で相互に認証する必要があります。この部分は、提案テキストに文書化されていません。
The layered mapping system proposal builds a hierarchical mapping system to support scalability, analyzes the design constraints, presents an explicit system structure, designs a two-cache mechanism on ingress tunneling router (ITR) to gain low request delay, and facilitates data validation. Tunneling and mapping are done at the core, and no change is needed on edge networks. The mapping system is run by interest groups independent of any ISP, which conforms to an economical model and can be voluntarily adopted by various networks. Mapping systems can also be constructed stepwise, especially in the IPv6 scenario.
階層化されたマッピングシステムの提案は、スケーラビリティをサポートする階層マッピングシステムを構築し、設計制約を分析し、明示的なシステム構造を提示し、イングレストンネリングルーター（ITR）の2キャッシュメカニズムを設計し、低要求遅延を獲得し、データの検証を促進します。トンネルとマッピングはコアで行われ、エッジネットワークには変更は必要ありません。マッピングシステムは、経済的モデルに適合し、さまざまなネットワークで自発的に採用できるISPとは無関係に利益団体によって実行されます。マッピングシステムは、特にIPv6シナリオでも段階的に構築できます。
1. Scalability
1. スケーラビリティ
A. Distributed storage of mapping data avoids central storage of massive amounts of data and restricts updates within local areas.
A.マッピングデータの分散ストレージにより、膨大な量のデータの中央ストレージが回避され、ローカルエリア内の更新が制限されます。
B. The cache mechanism in an ITR reasonably reduces the request loads on the mapping system.
B. ITRのキャッシュメカニズムは、マッピングシステムの要求負荷を合理的に削減します。
2. Deployability
2. 展開可能性
A. No change on edge systems, only tunneling in core routers, and new devices in core networks.
A.エッジシステムの変更はなく、コアルーターのトンネルのみ、コアネットワークの新しいデバイスのみ。
B. The mapping system can be constructed stepwise: a mapping node needn't be constructed if none of its responsible ELOCs is allocated. This makes sense especially for IPv6.
B.マッピングシステムは段階的に構築できます。責任あるELOCが割り当てられていない場合、マッピングノードを構築する必要はありません。これは、特にIPv6にとって理にかなっています。
C. Conforms to a viable economic model: the mapping system operators can profit from their services; core routers and edge networks are willing to join the circle either to avoid router upgrades or realize traffic engineering. Benefits from joining are independent of the scheme's implementation scale.
C.実行可能な経済モデルに準拠しています。マッピングシステムオペレーターはサービスから利益を得ることができます。コアルーターとエッジネットワークは、ルーターのアップグレードを避けたり、トラフィックエンジニアリングを実現したりするために、サークルに参加することをいとわない。参加の利点は、スキームの実装スケールとは無関係です。
3. Low request delay: The low number of layers in the mapping structure and the two-stage cache help achieve low request delay.
3. 低リクエスト遅延：マッピング構造のレイヤー数が少ないと、2段階のキャッシュが低い要求遅延を達成するのに役立ちます。
4. Data consistency: The two-stage cache enables an ITR to update data in the map cache conveniently.
4. データの一貫性：2段階のキャッシュにより、ITRはマップキャッシュのデータを便利に更新できます。
5. Traffic engineering support: Edge networks inform the mapping system of their prioritized mappings with all upstream routers, thus giving the edge networks control over their ingress flows.
5. トラフィックエンジニアリングのサポート：エッジネットワークは、すべての上流ルーターを使用した優先順位付けされたマッピングのマッピングシステムに通知し、エッジネットワークがイングレスフローを制御することを可能にします。
1. Deployment of LMS needs to be further discussed.
1. LMSの展開についてさらに議論する必要があります。
2. The structure of the mapping system needs to be refined according to practical circumstances.
2. マッピングシステムの構造は、実際の状況に応じて洗練する必要があります。
[LMS_Summary] [LMS]
[lms_summary] [lms]
LMS is a mapping mechanism based on Core-Edge Separation. In fact, any proposal that needs a global mapping system with keys with similar properties to that of an "edge address" in a Core-Edge Separation scenario can use such a mechanism. This means that those keys are globally unique (by authorization or just statistically), at the disposal of edge users, and may have several satisfied mappings (with possibly different weights). A proposal to address routing scalability that needs mapping but doesn't specify the mapping mechanism can use LMS to strengthen its infrastructure.
LMSは、コアエッジ分離に基づくマッピングメカニズムです。実際、コアエッジ分離シナリオの「エッジアドレス」のプロパティと同様のキーを持つキーを持つグローバルマッピングシステムが必要な提案は、そのようなメカニズムを使用できます。これは、これらのキーがエッジユーザーを自由に自由に使用して、グローバルに一意である（承認または統計的に）、いくつかの満足したマッピング（おそらく異なる重み付き）を持っている可能性があることを意味します。マッピングが必要であるがマッピングメカニズムを指定していないルーティングスケーラビリティに対処するための提案は、LMSを使用してインフラストラクチャを強化することができます。
The key idea of LMS is similar to that of LISP+ALT: that the mapping system should be hierarchically organized to gain scalability for storage and updates and to achieve quick indexing for lookups. However, LMS advocates an ISP-independent mapping system, and ETRs are not the authorities of mapping data. ETRs or edge-sites report their mapping data to related mapping servers.
LMSの重要なアイデアは、LISP ALTの考え方に似ています。マッピングシステムは、ストレージと更新のスケーラビリティを獲得し、ルックアップの迅速なインデックス作成を実現するために階層的に編成する必要があります。ただし、LMSはISPに依存しないマッピングシステムを提唱しており、ETRはマッピングデータの当局ではありません。ETRまたはエッジサイトは、マッピングデータを関連するマッピングサーバーに報告します。
LMS assumes that mapping servers can be incrementally deployed in that a server may not be constructed if none of its administered edge addresses are allocated, and that mapping servers can charge for their services, which provides the economic incentive for their existence. How this brand-new system can be constructed is still not clear. Explicit layering is only an ideal state, and the proposal analyzes the layering limits and feasibility, rather than provide a practical way for deployment.
LMSは、マッピングサーバーを、管理されたエッジアドレスが割り当てられていない場合、サーバーを構築できない可能性があり、マッピングサーバーがサービスに充電できることを想定しています。この真新しいシステムをどのように構築できるかはまだ明確ではありません。明示的な階層化は理想的な状態にすぎず、提案は、展開の実用的な方法を提供するのではなく、階層式制限と実現可能性を分析します。
The drawbacks of LMS's feasibility analysis also include that it 1) is based on current PC power and may not represent future circumstances (especially for IPv6), and 2) does not consider the variability of address utilization. Some IP address spaces may be effectively allocated and used while some may not, causing some mapping servers to be overloaded while others are poorly utilized. More thoughts are needed as to the flexibility of the layer design.
LMSの実現可能性分析の欠点には、1）現在のPCパワーに基づいており、将来の状況（特にIPv6の場合）を表していない可能性があり、2）はアドレス利用の変動性を考慮していないことも含まれます。一部のIPアドレススペースは効果的に割り当てられ、使用されている場合がありますが、一部のIPアドレススペースは、一部のマッピングサーバーが過負荷になりますが、他のアドレスサーバーが過負荷になります。レイヤー設計の柔軟性については、さらに考えが必要です。
LMS doesn't fit well for mobility. It does not solve the problem when hosts move faster than the mapping updates and propagation between relative mapping servers. On the other hand, mobile hosts' moving across ASes and changing their attachment points (core addresses) is less frequent than hosts' moving within an AS.
LMSはモビリティに適していません。ホストがマッピングの更新と相対マッピングサーバー間の伝播よりも速く移動する場合、問題は解決しません。一方、モバイルホストはASEを横切って添付ポイント（コアアドレス）を変更することは、AS内のホストが移動するよりも頻繁には少なくなります。
Separation needs two planes: Core-Edge Separation (which is to gain routing table scalability) and identity/location separation (which is to achieve mobility). The Global Locator, Local Locator, and Identifier (GLI) scheme does a good clarification of this, and in that case, LMS can be used to provide identity-to-core address mapping. Of course, other schemes may be competent, and LMS can be incorporated with them if the scheme has global keys and needs to map them to other namespaces.
分離には、コアエッジ分離（ルーティングテーブルのスケーラビリティを獲得するため）とアイデンティティ/位置分離（モビリティを実現するため）の2つの平面が必要です。グローバルロケーター、ローカルロケーター、および識別子（GLI）スキームは、これを適切に明確にします。その場合、LMSを使用してアイデンティティ間アドレスマッピングを提供できます。もちろん、他のスキームは有能である可能性があり、スキームにグローバルキーがあり、他の名前空間にマッピングする必要がある場合、LMSを組み込むことができます。
No rebuttal was submitted for this proposal.
この提案のために反論は提出されませんでした。
1. A mapping from prefixes to ETRs is an M:M mapping. Any change of a (prefix, ETR) pair should be updated in a timely manner, which can be a heavy burden to any mapping system if the relation changes frequently.
1. プレフィックスからETRへのマッピングは、M：Mマッピングです。（プレフィックス、ETR）ペアの変更はタイムリーに更新する必要があります。これは、関係が頻繁に変化する場合、あらゆるマッピングシステムにとって大きな負担となる可能性があります。
2. A prefix<->ETR mapping system cannot be deployed efficiently if it is overwhelmed by worldwide dynamics. Therefore, the mapping itself is not scalable with this direct mapping scheme.
2. プレフィックス<-> ETRマッピングシステムは、世界中のダイナミクスに圧倒されていれば効率的に展開することはできません。したがって、マッピング自体は、この直接マッピングスキームではスケーラブルではありません。
1. Introduce an AS number in the middle of the mapping, the phase I mapping is prefix<->AS#, phase II mapping is AS#<->ETRs. This creates a M:1:M mapping model.
1. マッピングの途中でAS番号を紹介すると、フェーズIマッピングはプレフィックス<-> As＃、フェーズIIマッピングは＃<-> ETRSです。これにより、M：1：Mマッピングモデルが作成されます。
2. It is fair to assume that all ASes know their local prefixes (in the IGP) better than other ASes and that it is most likely that local prefixes can be aggregated when they can be mapped to the AS number, which will reduce the number of mapping entries. Also, ASes also know clearly their ETRs on the border between core and edge. So, all mapping information can be collected locally.
2. すべてのASEが他のASEよりもローカルプレフィックス（IGP）をよく知っていること、およびAS数にマッピングできるときにローカルプレフィックスを集約できる可能性が高いと仮定するのは公平です。エントリ。また、ASEはまた、コアとエッジの境界でのETRを明確に知っています。したがって、すべてのマッピング情報はローカルで収集できます。
3. A registry system will take care of the phase I mapping information. Each AS should have a registration agent to notify the registry of the local range of IP address space. This system can be organized as a hierarchical infrastructure like DNS, or alternatively, as a centralized registry like "whois" in each RIR. Phase II mapping information can be distributed between xTRs as a BGP extension.
3. レジストリシステムは、フェーズIマッピング情報を処理します。それぞれが、IPアドレススペースのローカル範囲のレジストリに通知する登録エージェントが必要です。このシステムは、DNSのような階層インフラストラクチャとして、または各RIRの「WHOIS」のような集中レジストリとして編成できます。フェーズIIマッピング情報は、BGP拡張機能としてXTR間で分配できます。
4. The basic forwarding procedure is that the ITR first gets the destination AS number from the phase I mapper (or from cache) when the packet is entering the "core". Then, it will extract the closest ETR for the destination AS number. This is local, since phase II mapping information has been "pushed" to the ITR through BGP updates. Finally, the ITR tunnels the packet to the corresponding ETR.
4. 基本的な転送手順は、ITRが最初に宛先をフェーズIマッパー（またはキャッシュから）から「コア」に入力しているときに数字として取得することです。次に、宛先に最も近いETRを数として抽出します。これはローカルです。これは、フェーズIIマッピング情報がBGPの更新を介してITRに「プッシュ」されているためです。最後に、ITRはパケットを対応するETRにトンネルします。
1. Any prefix reconfiguration (aggregation/deaggregation) within an AS will not be reflected in the mapping system.
1. AS内のプレフィックス再構成（集約/掘削）は、マッピングシステムに反映されません。
2. Local prefixes can be aggregated with a high degree of efficiency.
2. ローカルプレフィックスは、高度な効率で集約できます。
3. Both phase I and phase II mappings can be stable.
3. フェーズIとフェーズIIマッピングの両方が安定している場合があります。
4. A stable mapping system will reduce the update overhead introduced by topology changes and/or routing policy dynamics.
4. 安定したマッピングシステムは、トポロジの変更および/またはルーティングポリシーダイナミクスによって導入された更新オーバーヘッドを削減します。
1. The two-phased mapping scheme introduces an AS number between the mapping prefixes and ETRs.
1. 2段階のマッピングスキームは、マッピングプレフィックスとETRの間にAS数を導入します。
2. The decoupling of direct mapping makes highly dynamic updates stable; therefore, it can be more scalable than any direct mapping designs.
2. 直接マッピングのデカップリングにより、非常に動的な更新が安定します。したがって、直接マッピングデザインよりもスケーラブルになる可能性があります。
3. The two-phased mapping scheme is adaptable to any proposals based on the core/edge split.
3. 2段階のマッピングスキームは、コア/エッジスプリットに基づいた提案に適応できます。
No references were submitted.
参照は提出されていません。
This is a simple idea on how to scale mapping. However, this design is too incomplete to be considered a serious input to RRG. Take the following two issues as example:
これは、マッピングをスケーリングする方法に関する簡単なアイデアです。ただし、この設計は不完全すぎて、RRGへの深刻な入力と見なされません。例として、次の2つの問題を取ります。
First, in this two-phase scheme, an AS is essentially the unit of destinations (i.e., sending ITRs find out destination AS D, then send data to one of D's ETRs). This does not offer much choice for traffic engineering.
第一に、この2フェーズスキームでは、ASは本質的に目的地の単位です（つまり、ITRの送信宛先をDとして検索し、DのETRのいずれかにデータを送信します）。これは、トラフィックエンジニアリングにあまり選択肢がありません。
Second, there is no consideration whatsoever on failure detection and handling.
第二に、障害検出と取り扱いについては何の考慮事項もありません。
No rebuttal was submitted for this proposal.
この提案のために反論は提出されませんでした。
GLI-Split implements a separation between global routing (in the global Internet outside edge networks) and local routing (inside edge networks) using global and local locators (GLs and LLs). In addition, a separate static identifier (ID) is used to identify communication endpoints (e.g., nodes or services) independently of any routing information. Locators and IDs are encoded in IPv6 addresses to enable backwards-compatibility with the IPv6 Internet. The higher-order bits store either a GL or a LL, while the lower- order bits contain the ID. A local mapping system maps IDs to LLs, and a global mapping system maps IDs to GLs. The full GLI-mode requires nodes with upgraded networking stacks and special GLI-gateways. The GLI-gateways perform stateless locator rewriting in IPv6 addresses with the help of the local and global mapping system. Non-upgraded IPv6 nodes can also be accommodated in GLI-domains since an enhanced DHCP service and GLI-gateways compensate for their missing GLI-functionality. This is an important feature for incremental deployability.
GLI-SPLITは、グローバルおよびローカルロケーター（GLSおよびLLS）を使用して、グローバルルーティング（グローバルインターネット外のエッジネットワーク外）とローカルルーティング（内部エッジネットワーク）の分離を実装します。さらに、ルーティング情報とは無関係に通信エンドポイント（ノードやサービスなど）を識別するために、個別の静的識別子（ID）が使用されます。ロケーターとIDはIPv6アドレスでエンコードされ、IPv6インターネットとの逆方向の適合性を有効にします。高次ビットにはGLまたはLLのいずれかが保存されますが、低次ビットにはIDが含まれています。ローカルマッピングシステムは、IDをLLSにマッピングし、グローバルマッピングシステムはIDをGLSにマップします。完全なGLIモードには、アップグレードされたネットワーキングスタックと特別なグリゲートウェイを備えたノードが必要です。Gli-Gatewaysは、ローカルおよびグローバルマッピングシステムの助けを借りて、IPv6アドレスでStateless Locatorの書き換えを実行します。強化されたDHCPサービスとGli-Gatewaysが不足しているGLI機能性を補償するため、UpgradedのIPv6ノードもGLIドメインに対応できます。これは、増分展開の重要な機能です。
The benefits of GLI-Split are:
Gli-Splitの利点は次のとおりです。
o Hierarchical aggregation of routing information in the global Internet through separation of edge and core routing
o エッジとコアルーティングの分離によるグローバルインターネットでのルーティング情報の階層的集約
o Provider changes not visible to nodes inside GLI-domains (renumbering not needed)
o プロバイダーの変更は、グリドメイン内のノードに表示されていません（必要ではない名前を変更します）
o Rearrangement of subnetworks within edge networks not visible to the outside world (better support of large edge networks)
o エッジネットワーク内のサブネットワークの再配置外の世界に見えない（大規模なエッジネットワークのより良いサポート）
o Transport connections survive both types of changes
o 輸送接続は、両方のタイプの変化に耐えます
o Multihoming
o マルチホミング
o Improved traffic engineering for incoming and outgoing traffic
o 着信および発信トラフィックのためのトラフィックエンジニアリングの改善
o Multipath routing and load balancing for hosts
o ホストのマルチパスルーティングとロードバランシング
o Improved resilience
o 回復力の向上
o Improved mobility support without home agents and triangle routing
o ホームエージェントと三角形のルーティングなしでのモビリティサポートの改善
o Interworking with the classic Internet
o 古典的なインターネットとの相互作用
* without triangle routing over proxy routers
* プロキシルーターを介した三角形のルーティングなし
* without stateful NAT
* ステートフルナットなし
These benefits are available for upgraded GLI-nodes, but non-upgraded nodes in GLI-domains partially benefit from these advanced features, too. This offers multiple incentives for early adopters, and they have the option to migrate their nodes gradually from non-GLI-stacks to GLI-stacks.
これらの利点はアップグレードされたGLIノードで利用可能ですが、GLIドメインのアップグレードされていないノードもこれらの高度な機能から部分的に利益を得ています。これにより、早期採用者に複数のインセンティブが提供され、ノードを非GliスタックからGLIスタックに徐々に移行するオプションがあります。
o Local and global mapping system
o ローカルおよびグローバルマッピングシステム
o Modified DHCP or similar mechanism
o 変更されたDHCPまたは同様のメカニズム
o GLI-gateways with stateless locator rewriting in IPv6 addresses
o IPv6アドレスでステートレスロケーターの書き換えを備えたGli-Gateways
o Upgraded stacks (only for full GLI-mode)
o アップグレードされたスタック（完全なGLIモードのみ）
[GLI]
[gli]
GLI-Split makes a clear distinction between two separation planes: the separation between identifier and locator (which is to meet end-users' needs including mobility) and the separation between local and global locator (which makes the global routing table scalable). The distinction is needed since ISPs and hosts have different requirements, with both needing to make the changes inside and outside GLI-domains invisible to their opposites.
GLI-SPLITは、識別子とロケーターの分離（モビリティを含むエンドユーザーのニーズを満たすこと）とローカルとグローバルのロケーターの分離（グローバルルーティングテーブルをスケーラブルにする）の2つの分離面を明確に区別します。ISPとホストにはさまざまな要件があり、両方とも内外のグリドメインを反対に見えないようにする必要があるため、区別が必要です。
A main drawback of GLI-Split is that it puts a burden on hosts. Before routing a packet received from upper layers, network stacks in hosts first need to resolve the DNS name to an IP address; if the IP address is GLI-formed, it may look up the map from the identifier extracted from the IP address to the local locator. If the communication is between different GLI-domains, hosts may further look up the mapping from the identifier to the global locator. Having the local mapping system forward requests to the global mapping system for hosts is just an option. Though host lookup may ease the burden of intermediate nodes, which would otherwise to perform the mapping lookup, the three lookups by hosts in the worst case may lead to large delays unless a very efficient mapping mechanism is devised. The work may also become impractical for low-powered hosts. On one hand, GLI-Split can provide backward compatibility where classic and upgraded IPv6 hosts can communicate. This is its big virtue. On the other hand, the need to upgrade may work against hosts' enthusiasm to change. This is offset against the benefits they would gain.
Gli-Splitの主な欠点は、ホストに負担をかけることです。上層層から受信したパケットをルーティングする前に、ホストのネットワークスタックは最初にDNS名をIPアドレスに解決する必要があります。IPアドレスがGli-Formedの場合、IPアドレスから抽出された識別子からローカルロケーターにマップを検索する場合があります。通信が異なるGLIドメイン間の間である場合、ホストは識別子からグローバルロケーターへのマッピングをさらに検索することができます。ローカルマッピングシステムをホスト用のグローバルマッピングシステムにフォワードリクエストすることは、単なるオプションです。ホストルックアップは、マッピングルックアップを実行するために中間ノードの負担を緩和する可能性がありますが、最悪の場合のホストによる3つのルックアップは、非常に効率的なマッピングメカニズムが考案されない限り、大きな遅延につながる可能性があります。この作業は、低電力ホストにとっても非現実的になる可能性があります。一方では、GLI-Splitは、クラシックおよびアップグレードされたIPv6ホストが通信できる場合に、後方互換性を提供できます。これはその大きな美徳です。一方、アップグレードする必要性は、ホストの変化への熱意に対して機能する可能性があります。これは、彼らが得る利益に対して相殺されます。
GLI-Split provides additional features to improve TE and to improve resilience, e.g., exerting multipath routing. However, the cost is that more burdens are placed on hosts, e.g., they may need more lookup actions and route selections. However, these kinds of tradeoffs between costs and gains exist in most proposals.
Gli-Splitは、TEを改善し、回復力を向上させるための追加機能を提供します。たとえば、マルチパスルーティングを行使します。ただし、コストは、ホストにより多くの負担がかかることです。たとえば、より多くのルックアップアクションやルート選択が必要になる場合があります。ただし、ほとんどの提案には、コストと利益の間のこれらの種類のトレードオフが存在します。
One improvement of GLI-Split is its support for mobility by updating DNS data as GLI-hosts move across GLI-domains. Through this, the GLI-corresponding-node can query DNS to get a valid global locator of the GLI-mobile-node and need not query the global mapping system (unless it wants to do multipath routing), giving more incentives for nodes to become GLI-enabled. The merits of GLI-Split, including simplified-mobility-handover provision, compensate for the costs of this improvement.
GLI-Splitの1つの改善は、GLIホストがGLIドメインを横切って移動するため、DNSデータを更新することにより、モビリティをサポートすることです。これにより、GLIに対応するノードはDNSを照会してGli-Mobileノードの有効なグローバルロケーターを取得し、グローバルマッピングシステムをクエリする必要はありません（マルチパスルーティングを実行したい場合を除く）。グリ対応。単純化されたモビリティハンドオーバーの規定を含むGLI-SPLITのメリットは、この改善のコストを補償します。
GLI-Split claims to use rewriting instead of tunneling for conversions between local and global locators when packets span GLI-domains. The major advantage is that this kind of rewriting needs no extra state, since local and global locators need not map to each other. Many other rewriting mechanisms instead need to maintain extra state. It also avoids the MTU problem faced by the tunneling methods. However, GLI-Split achieves this only by compressing the namespace size of each attribute (identifier and local/global locator). GLI-Split encodes two namespaces (identifier and local/ global locator) into an IPv6 address (each has a size of 2^64 or less), while map-and-encap proposals assume that identifier and locator each occupy a 128-bit space.
グリスプリットは、パケットがグリドメインに及ぶときに、ローカルロケーターとグローバルロケーター間の変換のためにトンネルの代わりに書き換えを使用すると主張しています。主な利点は、この種の書き換えには、地元のロケーターとグローバルなロケーターが互いにマッピングする必要がないため、追加の状態を必要としないことです。代わりに、他の多くの書き換えメカニズムは、追加の状態を維持する必要があります。また、トンネリング方法が直面するMTUの問題も回避します。ただし、GLI-Splitは、各属性（識別子とローカル/グローバルロケーター）の名前空間サイズを圧縮することによってのみこれを実現します。GLI-SPLITは2つの名前空間（識別子とローカル/グローバルロケーター）をIPv6アドレス（それぞれ2^64以下のサイズを持っています）にエンコードしますが、マップアンドエンクの提案は、識別子とロケーターがそれぞれ128ビットスペースを占めると仮定します。
The arguments in the GLI-Split critique are correct. There are only two points that should be clarified here. First, it is not a drawback that hosts perform the mapping lookups. Second, the critique proposed an improvement to the mobility mechanism, which is of a general nature and not specific to GLI-Split.
Gli-Split批評の議論は正しいです。ここで明確にする必要があるポイントは2つしかありません。まず、ホストがマッピングルックアップを実行する欠点ではありません。第二に、批評はモビリティメカニズムの改善を提案しました。これは一般的な性質のものであり、Gli-Splitに固有のものではありません。
1. The additional burden on the hosts is actually a benefit, compared to having the same burden on the gateways. If the gateway would perform the lookups and packets addressed to uncached EIDs arrive, a lookup in the mapping system must be initiated. Until the mapping reply returns, packets must be either dropped, cached, or sent over the mapping system to the destination. All these options are not optimal and have their drawbacks. To avoid these problems in GLI-Split, the hosts perform the lookup. The short additional delay is not a big issue in the hosts because it happens before the first packets are sent. So, no packets are lost or have to be cached. GLI-Split could also easily be adapted to special GLI-hosts (e.g., low-power sensor nodes) that do not have to do any lookup and simply let the gateway do all the work. This functionality is included anyway for backward compatibility with regular IPv6 hosts inside the GLI-domain.
1. ホストの追加の負担は、ゲートウェイに同じ負担をかけることと比較して、実際に利益です。Gatewayが、亀裂のないEidsにアドレス指定されたルックアップとパケットを実行する場合、マッピングシステムのルックアップを開始する必要があります。マッピングの返信が返されるまで、パケットをドロップ、キャッシュ、またはマッピングシステムを介して宛先に送信する必要があります。これらのオプションはすべて最適ではなく、欠点があります。これらの問題をGLI-Splitで回避するために、ホストはルックアップを実行します。短い追加の遅延は、最初のパケットが送信される前に発生するため、ホストの大きな問題ではありません。したがって、パケットが失われたり、キャッシュされたりする必要がありません。Gli-Splitは、検索を行う必要がなく、単にゲートウェイにすべての作業を行わせる必要のない特別なグリホスト（例：低電力センサーノード）に簡単に適応できます。とにかく、この機能は、GLIドメイン内の通常のIPv6ホストとの後方互換性のために含まれています。
2. The critique proposes a DNS-based mobility mechanism as an improvement to GLI-Split. However, this improvement is an alternative mobility approach that can be applied to any routing architecture (including GLI-Split) and also raises some concerns, e.g., the update speed of DNS. Therefore, we prefer to keep this issue out of the discussion.
2. 批評は、GLI-Splitの改善としてDNSベースのモビリティメカニズムを提案しています。ただし、この改善は、あらゆるルーティングアーキテクチャ（GLIスプリットを含む）に適用できる代替モビリティアプローチであり、DNSの更新速度など、いくつかの懸念を引き起こします。したがって、この問題を議論から締め出すことを好みます。
Provides a method for locator/identifier separation using tunnels between routers on the edge of the Internet transit infrastructure. It enriches the BGP protocol for distributing the identifier-to-locator mapping. Using new BGP attributes, "identifier prefixes" are assigned inter-domain routing locators so that they will not be installed in the RIB and will be moved to a new table called the Tunnel Information Base (TIB). Afterwards, when routing a packet to an "identifier prefix", first the TIB will be searched to perform tunneling, and secondly the RIB will be searched for actual routing. After the edge router performs tunneling, all routers in the middle will route this packet until the packet reaches the router at the tail-end of the tunnel.
インターネットトランジットインフラストラクチャの端にあるルーター間のトンネルを使用したロケーター/識別子分離の方法を提供します。識別子からロケーターマッピングを分散するためのBGPプロトコルを濃縮します。新しいBGP属性を使用して、「識別子プレフィックス」にはドメイン間ルーティングロケーターが割り当てられ、リブに設置されず、トンネル情報ベース（TIB）と呼ばれる新しいテーブルに移動します。その後、パケットを「識別子プレフィックス」にルーティングすると、最初にTIBを検索してトンネリングを実行し、次にリブが実際のルーティングを検索します。エッジルーターがトンネリングを実行した後、中央のすべてのルーターは、パケットがトンネルのテールエンドのルーターに到達するまでこのパケットをルーティングします。
o Smooth deployment
o スムーズな展開
o Size reduction of the global RIB
o グローバルリブのサイズ縮小
o Deterministic customer traffic engineering for incoming traffic
o 着信交通のための決定論的な顧客交通工学
o Numerous forwarding decisions for a particular address prefix
o 特定のアドレスプレフィックスの多数の転送決定
o Stops AS number space depletion
o 数スペースの枯渇として停止します
o Improved BGP convergence
o BGP収束の改善
o Protection of the inter-domain routing infrastructure
o ドメイン間ルーティングインフラストラクチャの保護
o Easy separation of control traffic and transit traffic
o 制御トラフィックとトランジットトラフィックの簡単な分離
o Different layer-2 protocol IDs for transit and non-transit traffic
o 輸送および非輸送トラフィック用のさまざまなレイヤー2プロトコルID
o Multihoming resilience o New address families and tunneling techniques
o 新しい住所ファミリとトンネル技術oのマルチホミングレジリエンス
o Support for IPv4 or IPv6, and migration to IPv6
o IPv4またはIPv6のサポート、およびIPv6への移行
o Scalability, stability, and reliability
o スケーラビリティ、安定性、および信頼性
o Faster inter-domain routing
o より高速なドメイン間ルーティング
o Routers on the edge of the inter-domain infrastructure will need to be upgraded to hold the mapping database (i.e., the TIB).
o ドメイン間インフラストラクチャの端にあるルーターは、マッピングデータベース（TIB）を保持するためにアップグレードする必要があります。
o "Mapping updates" will need to be treated differently from usual BGP "routing updates".
o 「マッピングの更新」は、通常のBGP「ルーティングの更新」とは異なる方法で扱われる必要があります。
[TIDR] [TIDR_identifiers] [TIDR_and_LISP] [TIDR_AS_forwarding]
[tidr] [tidr_identifiers] [tidr_and_lisp] [tidr_as_forwarding]
TIDR is a Core-Edge Separation architecture from late 2006 that distributes its mapping information via BGP messages that are passed between DFZ routers.
TIDRは、DFZルーター間で渡されるBGPメッセージを介してマッピング情報を配布する2006年後半からのコアエッジ分離アーキテクチャです。
This means that TIDR cannot solve the most important goal of scalable routing -- to accommodate much larger numbers of end-user network prefixes (millions or billions) without each such prefix directly burdening every DFZ router. Messages advertising routes for TIDR-managed prefixes may be handled with lower priority, but this would only marginally reduce the workload for each DFZ router compared to handling an advertisement of a conventional PI prefix.
これは、TIDRがスケーラブルなルーティングの最も重要な目標を解決できないことを意味します。これは、すべてのDFZルーターに直接負担をかけることなく、はるかに多くのエンドユーザーネットワークプレフィックス（数百万または数十億）に対応するためです。TIDRが管理したプレフィックスのメッセージ広告ルートは、優先度が低い状態で処理される場合がありますが、従来のPIプレフィックスの広告を処理するのと比較して、各DFZルーターのワークロードをわずかに削減するだけです。
Therefore, TIDR cannot be considered for RRG recommendation as a solution to the routing scaling problem.
したがって、TIDRは、ルーティングスケーリングの問題の解決策としてRRG推奨事項を考慮することはできません。
For a TIDR-using network to receive packets sent from any host, every BR of all ISPs must be upgraded to have the new ITR-like functionality. Furthermore, all DFZ routers would need to be altered so they accepted and correctly propagated the routes for end-user network address space, with the new LOCATOR attribute, which contains the ETR address and a REMOTE-PREFERENCE value. Firstly, if they received two such advertisements with different LOCATORs, they would advertise a single route to this prefix containing both. Secondly, for end-user address space (for IPv4) to be more finely divided, the DFZ routers must propagate LOCATOR-containing advertisements for prefixes longer than /24.
TIDR使用ネットワークがホストから送信されたパケットを受信するには、すべてのISPのすべてのBRをアップグレードして、新しいITRのような機能を持つ必要があります。さらに、すべてのDFZルーターを変更する必要があり、ETRアドレスとリモートプレーファレンス値を含む新しいロケーター属性を使用して、エンドユーザーネットワークアドレススペースのルートを受け入れて正しく伝播しました。まず、異なるロケーターを持つ2つのそのような広告を受け取った場合、両方を含むこのプレフィックスに単一のルートを宣伝します。第二に、エンドユーザーアドレス空間（IPv4の場合）をより細かく分割するには、DFZルーターは /24より長いプレフィックスのロケーターを含む広告を伝播する必要があります。
TIDR's ITR-like routers store the full mapping database -- so there would be no delay in obtaining mapping, and therefore no significant delay in tunneling traffic packets.
TIDRのITRのようなルーターは、完全なマッピングデータベースを保存します。そのため、マッピングの取得に遅延はありません。したがって、トラフィックパケットのトンネリングに大きな遅延はありません。
[TIDR] is written as if traffic packets are classified by reference to the RIB, but routers use the FIB for this purpose, and "FIB" does not appear in [TIDR].
[TIDR]は、トラフィックパケットがリブを参照して分類されているかのように書かれていますが、ルーターはこの目的のためにFIBを使用し、「FIB」は[TIDR]には表示されません。
TIDR does not specify a tunneling technique, leaving this to be chosen by the ETR-like function of BRs and specified as part of a second kind of new BGP route advertised by that ETR-like BR. There is no provision for solving the PMTUD problems inherent in encapsulation-based tunneling.
TIDRはトンネリング手法を指定しておらず、これをBRSのETR様関数によって選択し、そのETRのようなBRによって宣伝された2番目の新しいBGPルートの一部として指定されます。カプセル化ベースのトンネリングに固有のPMTUD問題を解決するための規定はありません。
ITR functions must be performed by already busy routers of ISPs, rather than being distributed to other routers or to sending hosts. There is no practical support for mobility. The mapping in each end-user route advertisement includes a REMOTE-PREFERENCE for each ETR-like BR, but this is used by the ITR-like functions of BRs to always select the LOCATOR with the highest value. As currently described, TIDR does not provide inbound load-splitting TE.
ITR関数は、他のルーターに配布されたり、宿主を送信するのではなく、すでに忙しいISPのルーターによって実行する必要があります。モビリティに対する実用的なサポートはありません。各エンドユーザールート広告のマッピングには、各ETRのようなBRのリモートプレーフレンドが含まれていますが、これはBRSのITR様関数によって使用され、常に最高値のロケーターを選択するために使用されます。現在説明したように、TIDRはインバウンド負荷分散TEを提供しません。
Multihoming service restoration is achieved initially by the ETR-like function of the BR at the ISP (whose link to the end-user network has just failed). It looks up the mapping to find the next preferred ETR-like BR's address. The first ETR-like router tunnels the packets to the second ETR-like router in the other ISP. However, if the failure was caused by the first ISP itself being unreachable, then connectivity would not be restored until a revised mapping (with higher REMOTE-PREFERENCE) from the reachable ETR-like BR of the second ISP propagated across the DFZ to all ITR-like routers, or the withdrawn advertisement for the first one reaches the ITR-like router.
マルチホームサービスの復元は、最初にISPでのBRのETR様関数によって達成されます（エンドユーザーネットワークへのリンクが失敗したばかりです）。マッピングを検索して、次に優先されるETRのようなBRのアドレスを見つけます。最初のETRのようなルーターは、他のISPの2番目のETRのようなルーターにパケットをトンネルします。ただし、障害が最初のISP自体が到達不可能であることによって引き起こされた場合、DFZを介してすべてのITRに伝播された2番目のISPの到達可能なETRのようなBRから修正マッピング（より高いリモートプレファレンスを持つ）がすべてのITRに伝播されるまで、接続性は復元されません。 - ルーターのように、または最初のルーターの撤回された広告がITRのようなルーターに到達します。
No rebuttal was submitted for this proposal.
この提案のために反論は提出されませんでした。
o Provides crisp separation of Identifiers from Locators.
o 識別子の鮮明な分離をロケーターから提供します。
o Identifiers name nodes, not interfaces.
o 識別子は、インターフェイスではなく、ノードに名前を付けます。
o Locators name subnetworks, rather than interfaces, so they are equivalent to an IP routing prefix.
o ロケーターはインターフェイスではなくサブネットワークという名前であるため、IPルーティングプレフィックスと同等です。
o Identifiers are never used for network-layer routing, whilst Locators are never used for Node Identity.
o 識別子はネットワーク層ルーティングに使用されることはありませんが、ロケーターはノードIDには使用されません。
o Transport-layer sessions (e.g., TCP session state) use only Identifiers, never Locators, meaning that changes in location have no adverse impact on an IP session.
o 輸送層セッション（TCPセッション状態など）は、識別子のみを使用し、ロケーターのみを使用します。つまり、場所の変化はIPセッションに悪影響を及ぼさないことを意味します。
o The underlying protocol mechanisms support fully scalable site multihoming, node multihoming, site mobility, and node mobility.
o 基礎となるプロトコルメカニズムは、完全にスケーラブルなサイトマルチホーム、ノードマルチホーム、サイトのモビリティ、ノードモビリティをサポートします。
o ILNP enables topological aggregation of location information while providing stable and topology-independent identities for nodes.
o ILNPは、位置情報のトポロジカル集約を可能にしながら、ノードに安定したトポロジに依存しないアイデンティティを提供します。
o In turn, this topological aggregation reduces both the routing prefix "churn" rate and the overall size of the Internet's global routing table, by eliminating the value and need for more-specific routing state currently carried throughout the global (default-free) zone of the routing system.
o 次に、このトポロジの集約により、ルーティングプレフィックスの「チャーン」レートとインターネットのグローバルルーティングテーブルの全体的なサイズの両方が減少します。ルーティングシステム。
o ILNP enables improved traffic engineering capabilities without adding any state to the global routing system. TE capabilities include both provider-driven TE and also end-site-controlled TE.
o ILNPは、グローバルルーティングシステムに状態を追加することなく、トラフィックエンジニアリング機能の改善を可能にします。TE機能には、プロバイダー主導のTEとエンドサイト制御TEの両方が含まれます。
o ILNP's mobility approach:
o ILNPのモビリティアプローチ：
* eliminates the need for special-purpose routers (e.g., home agent and/or foreign agent now required by Mobile IP and NEMO).
* 特殊な目的のルーター（モバイルIPおよびNEMOに必要なホームエージェントおよび/または外国人エージェントなど）の必要性を排除します。
* eliminates "triangle routing" in all cases.
* すべての場合に「三角形ルーティング」を排除します。
* supports both "make before break" and "break before make" layer-3 handoffs.
* 「Before Breed」と「Break Before Make」レイヤー3ハンドオフの両方をサポートします。
o ILNP improves resilience and network availability while reducing the global routing state (as compared with the currently deployed Internet).
o ILNPは、グローバルなルーティング状態を減らしながら、レジリエンスとネットワークの可用性を向上させます（現在展開されているインターネットと比較して）。
o ILNP is incrementally deployable:
o ILNPは徐々に展開可能です：
* No changes are required to existing IPv6 (or IPv4) routers.
* 既存のIPv6（またはIPv4）ルーターに変更は必要ありません。
* Upgraded nodes gain benefits immediately ("day one"); those benefits gain in value as more nodes are upgraded (this follows Metcalfe's Law).
* アップグレードされたノードはすぐに利益を得る（「初日」）。より多くのノードがアップグレードされるにつれて、これらの利点は価値が得られます（これはMetcalfeの法則に従います）。
* The incremental deployment approach is documented.
* 増分展開アプローチが文書化されています。
o ILNP is backwards compatible:
o ILNPは後方互換性があります：
* ILNPv6 is fully backwards compatible with IPv6 (ILNPv4 is fully backwards compatible with IPv4).
* ILNPV6はIPv6と完全に逆方向に互換性があります（ILNPV4はIPv4と完全に逆方向に互換性があります）。
* Reuses existing known-to-scale DNS mechanisms to provide identifier/locator mapping.
* 識別子/ロケーターマッピングを提供するために、既存のスケールに既知のDNSメカニズムを再利用します。
* Existing DNS security mechanisms are reused without change.
* 既存のDNSセキュリティメカニズムは、変更なしで再利用されます。
* Existing IP Security mechanisms are reused with one minor change (IPsec Security Associations replace the current use of IP addresses with the use of Identifier values). NB: IPsec is also backwards compatible.
* 既存のIPセキュリティメカニズムは、1つの小さな変更で再利用されます（IPSECセキュリティアソシエーションは、IPアドレスの現在の使用を識別子値の使用に置き換えます）。NB：IPSECも逆方向に互換性があります。
* The backwards compatibility approach is documented.
* 後方互換性のアプローチが文書化されています。
o No new or additional overhead is required to determine or to maintain locator/path liveness.
o ロケーター/パスの描写を決定または維持するために、新しいまたは追加のオーバーヘッドは必要ありません。
o ILNP does not require locator rewriting (NAT); ILNP permits and tolerates NAT, should that be desirable in some deployment(s).
o ILNPはロケーターの書き換え（NAT）を必要としません。ILNPは、NATを許可し、許容します。これは、一部の展開で望ましい場合です。
o Changes to upstream network providers do not require node or subnetwork renumbering within end-sites.
o アップストリームネットワークプロバイダーへの変更では、エンドサイト内でノードまたはサブネットワークの名前を変更する必要はありません。
o ILNP is compatible with and can facilitate the transition from current single-path TCP to multipath TCP.
o ILNPは、現在のシングルパスTCPからMultiPath TCPへの移行と互換性があり、容易になります。
o ILNP can be implemented such that existing applications (e.g., applications using the BSD Sockets API) do NOT need any changes or modifications to use ILNP.
o ILNPは、既存のアプリケーション（たとえば、BSDソケットAPIを使用したアプリケーションなど）がILNPを使用するために変更や変更を必要としないように実装できます。
o End systems need to be enhanced incrementally to support ILNP in addition to IPv6 (or IPv4 or both).
o IPv6（またはIPv4またはその両方）に加えて、ILNPをサポートするために、ENDシステムを段階的に強化する必要があります。
o DNS servers supporting upgraded end systems also should be upgraded to support new DNS resource records for ILNP. (The DNS protocol and DNS security do not need any changes.)
o アップグレードされたエンドシステムをサポートするDNSサーバーもアップグレードして、ILNPの新しいDNSリソースレコードをサポートする必要があります。（DNSプロトコルとDNSセキュリティには変更は必要ありません。）
[ILNP_Site] [MobiArch1] [MobiArch2] [MILCOM1] [MILCOM2] [DNSnBIND]
[Referral_Obj] [ILNP_Intro] [ILNP_Nonce] [ILNP_DNS] [ILNP_ICMP]
[JSAC_Arch] [RFC4033] [RFC4034] [RFC4035] [RFC5534] [RFC5902]
The primary issue for ILNP is how the deployment incentives and benefits line up with the RRG goal of reducing the rate of growth of entries and churn in the core routing table. If a site is currently using PI space, it can only stop advertising that space when the entire site is ILNP capable. This needs (at least) clear elucidation of the incentives for ILNP which are not related to routing scaling, in order for there to be a path for this to address the RRG needs. Similarly, the incentives for upgrading hosts need to align with the value for those hosts.
ILNPの主な問題は、展開インセンティブと利益が、コアルーティングテーブルでのエントリの成長率を減らし、解約するというRRGの目標とどのように並んでいるかです。サイトが現在PIスペースを使用している場合、サイト全体がILNPの可能性がある場合にのみ、そのスペースの広告を停止できます。これは、RRGのニーズに対処するためのパスがあるために、ルーティングスケーリングに関連していないILNPのインセンティブの（少なくとも）明確な解明を必要とします。同様に、ホストをアップグレードするためのインセンティブは、それらのホストの価値と一致する必要があります。
A closely related question is whether this mechanism actually addresses the sites need for PI addresses. Assuming ILNP is deployed, the site does achieve flexible, resilient, communication using all of its Internet connections. While the proposal addresses the host updates when the host learns of provider changes, there are other aspects of provider change that are not addressed. This includes renumbering routers, subnets, and certain servers. (It is presumed that most servers, once the entire site has moved to ILNP, will not be concerned if their locator changes. However, some servers must have known locators, such as the DNS server.) The issues described in [RFC5887] will be ameliorated, but not resolved. To be able to adopt this proposal, and have sites use it, we need to address these issues. When a site changes points of attachment, only a small amount of DNS provisioning should be required. The LP resource record type is apparently intended to help with this. It is also likely that the use of dynamic DNS will help this.
密接に関連する質問は、このメカニズムが実際にPIアドレスに必要なサイトに対処するかどうかです。ILNPが展開されていると仮定すると、サイトはすべてのインターネット接続を使用して柔軟で回復力のある通信を実現します。提案は、ホストがプロバイダーの変更を知ったときにホストの更新に対処しますが、対処されていないプロバイダーの変更の他の側面があります。これには、ルーター、サブネット、および特定のサーバーの変更が含まれます。（サイト全体がILNPに移動すると、ほとんどのサーバーがロケーターが変更されるかどうかは懸念されないと推定されます。ただし、[RFC5887]に記載されている問題は、DNSサーバーなどの既知のロケーターを持っている必要があります。）改善されますが、解決されません。この提案を採用し、サイトに使用できるようにするには、これらの問題に対処する必要があります。サイトが添付のポイントを変更する場合、少量のDNSプロビジョニングのみが必要です。LPリソースレコードタイプは、明らかにこれを支援することを目的としています。また、動的なDNSの使用がこれに役立つ可能性があります。
The ILNP mechanism is described as being suitable for use in conjunction with mobility. This raises the question of race conditions. To the degree that mobility concerns are valid at this time, it is worth asking how communication can be established if a node is sufficiently mobile that it is moving faster than the DNS update and DNS fetch cycle can effectively propagate changes.
ILNPメカニズムは、モビリティと組み合わせて使用するのに適していると説明されています。これにより、人種の条件の問題が生じます。現時点では、モビリティの懸念が有効であるという程度まで、ノードがDNSアップデートよりも速く動いている場合、DNSフェッチサイクルが変更を効果的に伝播できる場合、ノードが十分に動いている場合、通信を確立できる方法を尋ねる価値があります。
This proposal does presume that all communication using this mechanism is tied to DNS names. While it is true that most communication does start from a DNS name, it is not the case that all exchanges have this property. Some communication initiation and referral can be done with an explicit identifier/locator pair. This does appear to require some extensions to the existing mechanism (for both sides to add locators). In general, some additional clarity on the assumptions regarding DNS, particularly for low-end devices, would seem appropriate.
この提案は、このメカニズムを使用したすべての通信がDNS名に関連付けられていると推測しています。ほとんどの通信がDNS名から始まることは事実ですが、すべての取引所にこのプロパティがあることはそうではありません。通信の開始と紹介は、明示的な識別子/ロケーターペアで実行できます。これには、既存のメカニズムへのいくつかの拡張機能が必要であるように見えます（両側がロケーターを追加するには）。一般に、特にローエンドデバイスの場合、DNSに関する仮定に関するいくつかの追加の明確さは適切と思われます。
One issue that this proposal shares with many others is the question of how to determine which locator pairs (local and remote) are actually functional. This is an issue both for initial communications establishment and for robustly maintaining communication. It is likely that a combination of monitoring of traffic (in the host, where this is tractable), coupled with other active measures, can address this. ICMP is clearly insufficient.
この提案が他の多くと共有する問題の1つは、実際にどのロケーターペア（ローカルおよびリモート）が機能しているかをどのように決定するかという問題です。これは、初期のコミュニケーション施設とコミュニケーションを堅牢に維持するための問題です。他のアクティブな測定値と相まって、トラフィックの監視（これが扱いやすいホスト）の組み合わせがこれに対処できる可能性があります。ICMPは明らかに不十分です。
ILNP eliminates the perceived need for PI addressing and encourages increased DFZ aggregation. Many enterprise users view DFZ scaling issues as too abstruse, so ILNP creates more user-visible incentives to upgrade deployed systems.
ILNPは、PIアドレス指定の認識されている必要性を排除し、DFZ凝集の増加を促進します。多くのエンタープライズユーザーは、DFZのスケーリングの問題をあまりにも抽象的であると見なしているため、ILNPは展開されたシステムをアップグレードするためにより多くのユーザー可視インセンティブを作成します。
ILNP mobility eliminates Duplicate Address Detection (DAD), reducing the layer-3 handoff time significantly when compared to IETF standard Mobile IP, as shown in [MobiArch1] and [MobiArch2]. ICMP location updates separately reduce the layer-3 handoff latency.
ILNPモビリティは、[MOBIARCH1]および[MOBIARCH2]に示すように、IETF標準モバイルIPと比較した場合、重複するアドレス検出（DAD）を排除し、レイヤー-3ハンドオフ時間を大幅に短縮します。ICMPの場所の更新は、レイヤー3ハンドオフレイテンシを個別に減らします。
Also, ILNP enables both host multihoming and site multihoming. Current BGP approaches cannot support host multihoming. Host multihoming is valuable in reducing the site's set of externally visible nodes.
また、ILNPは、ホストのマルチホミングとサイトのマルチホミングの両方を有効にします。現在のBGPアプローチは、ホストのマルチホームをサポートできません。ホストMultihomingは、サイトの外部目に見えるノードのセットを削減する上で価値があります。
Improved mobility support is very important. This is shown by the research literature and also appears in discussions with vendors of mobile devices (smartphones, MP3 players). Several operating system vendors push "updates" with major networking software changes in maintenance releases today. Security concerns mean most hosts receive vendor updates more quickly these days.
モビリティサポートの改善は非常に重要です。これは研究文献によって示されており、モバイルデバイス（スマートフォン、MP3プレーヤー）のベンダーとの議論にも掲載されています。いくつかのオペレーティングシステムベンダーは、今日のメンテナンスリリースの主要なネットワーキングソフトウェアの変更により、「更新」をプッシュします。セキュリティ上の懸念は、ほとんどのホストが最近ベンダーの更新をより迅速に受け取ることを意味します。
ILNP enables a site to hide exterior connectivity changes from interior nodes, using various approaches. One approach deploys unique local address (ULA) prefixes within the site, and has the site border router(s) rewrite the Locator values. The usual NAT issues don't arise because the Locator value is not used above the network-layer. [MILCOM1] [MILCOM2]
ILNPにより、サイトは、さまざまなアプローチを使用して、内部ノードからの外部接続の変化を隠すことができます。1つのアプローチでは、サイト内の一意のローカルアドレス（ULA）プレフィックスを展開し、サイトボーダールーターにロケーター値を書き直します。ロケーターの値がネットワーク層の上に使用されていないため、通常のNATの問題は発生しません。[Milcom1] [Milcom2]
[RFC5902] makes clear that many users desire IPv6 NAT, with site interior obfuscation as a major driver. This makes global-scope PI addressing much less desirable for end sites than formerly.
[RFC5902]は、多くのユーザーがIPv6 NATを望んでいることを明らかにしています。これにより、グローバルスコープPIは、以前よりもエンドサイトでははるかに望ましくなりません。
ILNP-capable nodes can talk existing IP with legacy IP-only nodes, with no loss of current IP capability. So, ILNP-capable nodes will never be worse off.
ILNP対応ノードは、現在のIP機能を損なうことなく、Legacy IPのみのノードで既存のIPを通知できます。したがって、ILNP対応ノードは決して悪化しません。
Secure Dynamic DNS Update is standard and widely supported in deployed hosts and DNS servers. [DNSnBIND] says many sites have deployed this technology without realizing it (e.g., by enabling both the DHCP server and Active Directory of the MS-Windows Server).
Secure Dynamic DNSアップデートは標準であり、展開されたホストとDNSサーバーで広くサポートされています。[dnsnbind]は、多くのサイトがこのテクノロジーを実現せずに展開していると言います（たとえば、MS-WindowsサーバーのDHCPサーバーとActive Directoryの両方を有効にすることにより）。
If a node is as mobile as the critique says, then existing IETF Mobile IP standards also will fail. They also use location updates (e.g., MN -> home agent, MN -> foreign agent).
ノードが批評が言うようにモバイルである場合、既存のIETFモバイルIP標準も失敗します。また、ロケーションの更新（MN->ホームエージェント、MN->外国人エージェントなど）も使用しています。
ILNP also enables new approaches to security that eliminate dependence upon location-dependent Access Control Lists (ACLs) without packet authentication. Instead, security appliances track flows using Identifier values and validate the identifier/locator relationship cryptographically [RFC4033] [RFC4034] [RFC4035] or non-cryptographically by reading the nonce [ILNP_Nonce].
ILNPは、パケット認証なしで位置依存アクセス制御リスト（ACL）への依存を排除するセキュリティへの新しいアプローチも可能にします。代わりに、セキュリティアプライアンスは識別子値を使用してフローを追跡し、識別子/ロケーターの関係を暗号化[RFC4034] [RFC4035] [RFC4035]または非暗号化して非暗号化[ILNP_NONCE]を検証します。
The DNS LP record has a more detailed explanation now. LP records enable a site to change its upstream connectivity by changing the L resource records of a single FQDN covering the whole site, thereby providing scalability.
DNS LPレコードには、より詳細な説明があります。LPレコードにより、サイト全体をカバーする単一のFQDNのLリソースレコードを変更することにより、サイトが上流の接続を変更し、スケーラビリティを提供できます。
DNS-based server load balancing works well with ILNP by using DNS SRV records. DNS SRV records are not new, are widely available in DNS clients and servers, and are widely used today in the IPv4 Internet for server load balancing.
DNSベースのサーバーロードバランシングは、DNS SRVレコードを使用することにより、ILNPでうまく機能します。DNS SRVレコードは新しいものではなく、DNSクライアントとサーバーで広く利用可能であり、現在IPv4インターネットでサーバーロードバランスのために広く使用されています。
Recent ILNP documents discuss referrals in more detail. A node with a binary referral can find the FQDN using DNS PTR records, which can be authenticated [RFC4033] [RFC4034] [RFC4035]. Approaches such as [Referral_Obj] improve user experience and user capability, so are likely to self-deploy.
最近のILNP文書は、紹介についてより詳細に説明しています。バイナリ紹介を備えたノードは、DNS PTRレコードを使用してFQDNを見つけることができます。これは、[RFC4033] [RFC4034] [RFC4035]を認証できます。[referral_obj]などのアプローチは、ユーザーエクスペリエンスとユーザー機能を改善するため、自己展開する可能性があります。
Selection from multiple Locators is identical to an IPv4 system selecting from multiple A records for its correspondent. Deployed IP nodes can track reachability via existing host mechanisms or by using the SHIM6 method. [RFC5534]
複数のロケーターからの選択は、特派員の複数のAレコードから選択するIPv4システムと同じです。展開されたIPノードは、既存のホストメカニズムを介して、またはSHIM6メソッドを使用してリーチ性を追跡できます。[RFC5534]
We present some architectural principles pertaining to the mapping distribution protocols, especially applicable to the map-and-encap (e.g., LISP) type of protocols. These principles enhance the efficiency of the map-and-encap protocols in terms of (1) better utilization of resources (e.g., processing and memory) at Ingress Tunnel Routers (ITRs) and mapping servers, and consequently, (2) reduction of response time (e.g., first-packet delay). We consider how Egress Tunnel Routers (ETRs) can perform aggregation of endpoint ID (EID) address space belonging to their downstream delivery networks, in spite of migration/re-homing of some subprefixes to other ETRs. This aggregation may be useful for reducing the processing load and memory consumption associated with map messages, especially at some resource-constrained ITRs and subsystems of the mapping distribution system. We also consider another architectural concept where the ETRs are organized in a hierarchical manner for the potential benefit of aggregation of their EID address spaces. The two key architectural ideas are discussed in some more detail below. A more complete description can be found in [EEMDP_Considerations] and [EEMDP_Presentation].
マッピング分布プロトコルに関連するいくつかのアーキテクチャの原則、特にマップアンドエンコップ（例えば、LISP）のプロトコルに適用されるものを提示します。これらの原則は、（1）イングレストンネルルーター（ITR）およびマッピングサーバーでのリソース（処理とメモリなど）のより良い利用率の観点から、マップアンドエンコッププロトコルの効率を高め、その結果、（2）応答の減少時間（例：ファーストパケットの遅延）。Egress Tunnelルーター（ETR）が、他のETRへの一部のサブプレフィックスの移行/再ホーミングにもかかわらず、下流の配信ネットワークに属するエンドポイントID（EID）アドレススペースの集約を実行する方法を検討します。この集約は、特にマッピング配信システムの一部のリソース制約のあるITRとサブシステムで、マップメッセージに関連する処理負荷とメモリ消費を削減するのに役立つ可能性があります。また、ETRがEIDアドレススペースの集約の潜在的な利点のために階層的な方法で編成される別の建築概念も検討します。2つの重要なアーキテクチャのアイデアについては、以下でさらに詳しく説明します。より完全な説明は、[eemdp_considerations]および[eemdp_presentation]にあります。
It will be helpful to refer to Figures 1, 2, and 3 in [EEMDP_Considerations] for some of the discussions that follow here below.
[eemdp_consididerations]の図1、2、および3を参照すると、以下の議論のいくつかについては役立ちます。
To assist in this discussion, we start with the high level architecture of a map-and-encap approach (it would be helpful to see Figure 1 in [EEMDP_Considerations]). In this architecture, we have the usual ITRs, ETRs, delivery networks, etc. In addition, we have the ID-Locator Mapping (ILM) servers, which are repositories for complete mapping information, while the ILM-Regional (ILM-R) servers can contain partial and/or regionally relevant mapping information.
この議論を支援するために、マップアンドENCAPアプローチの高レベルアーキテクチャから始めます（[eemdp_considerations]で図1を見ると役立ちます）。このアーキテクチャには、通常のITR、ETR、配信ネットワークなどがあります。さらに、ID-Locatorマッピング（ILM）サーバーがあり、完全なマッピング情報のリポジトリであり、ILM-Regional（ILM-R）があります。サーバーには、部分的および/または地域に関連するマッピング情報を含めることができます。
While a large endpoint address space contained in a prefix may be mostly associated with the delivery networks served by one ETR, some fragments (subprefixes) of that address space may be located elsewhere at other ETRs. Let a/20 denote a prefix that is conceptually viewed as composed of 16 subnets of /24 size that are denoted as a1/24, a2/24, ..., a16/24. For example, a/20 is mostly at ETR1, while only two of its subprefixes a8/24 and a15/24 are elsewhere at ETR3 and ETR2, respectively (see Figure 2 [EEMDP_Considerations]). From the point of view of efficiency of the mapping distribution protocol, it may be beneficial for ETR1 to announce a map for the entire space a/20 (rather than fragment it into a multitude of more-specific prefixes), and provide the necessary exceptions in the map information. Thus, the map message could be in the form of Map:(a/20, ETR1; Exceptions: a8/24, a15/24). In addition, ETR2 and ETR3 announce the maps for a15/24 and a8/24, respectively, and so the ILMs know where the exception EID addresses are located. Now consider a host associated with ITR1 initiating a packet destined for an address a7(1), which is in a7/24 that is not in the exception portion of a/20. Now a question arises as to which of the following approaches would be the best choice:
接頭辞に含まれる大きなエンドポイントアドレススペースは、主に1つのETRが提供する配信ネットワークに関連付けられている場合がありますが、そのアドレススペースの一部のフラグメント（サブプレフィックス）は、他のETRの他の場所に配置できます。A/20は、A1/24、A2/24、...、A16/24として示される/24サイズの16のサブネットで構成される概念的に表示されるプレフィックスを示すとします。たとえば、A/20は主にETR1であり、そのサブプレフィックスA8/24とA15/24の2つのみがETR3とETR2の他の場所にあります（図2 [EEMDP_CONSIDERATIONS]を参照）。マッピング分布プロトコルの効率性の観点から見ると、ETR1がスペースA/20のマップを発表することが有益である可能性があります（多数のより固有の接頭辞に断片化するのではなく）。マップ情報。したがって、マップメッセージは、マップの形式である可能性があります：（A/20、ETR1;例外：A8/24、A15/24）。さらに、ETR2とETR3は、それぞれA15/24とA8/24のマップを発表するため、ILMSは例外EIDアドレスがどこにあるかを知っています。次に、A/20の例外部分にないA7/24にあるアドレスA7（1）に導かれるパケットを開始するITR1に関連付けられたホストを検討します。現在、次のアプローチのどれが最良の選択であるかについて疑問が生じます。
1. ILM-R provides the complete mapping information for a/20 to ITR1 including all maps for relevant exception subprefixes.
1. ILM-Rは、関連する例外サブプレフィックスのすべてのマップを含むA/20の完全なマッピング情報をITR1に提供します。
2. ILM-R provides only the directly relevant map to ITR1, which in this case is (a/20, ETR1).
2. ILM-Rは、ITR1に直接関連するマップのみを提供します。これは、この場合（A/20、ETR1）です。
In the first approach, the advantage is that ITR1 would have the complete mapping for a/20 (including exception subnets), and it would not have to generate queries for subsequent first packets that are destined to any address in a/20, including a8/24 and a15/24. However, the disadvantage is that if there is a significant number of exception subprefixes, then the very first packet destined for a/20 will experience a long delay, and also the processors at ITR1 and ILM-R can experience overload. In addition, the memory usage at ITR1 can be very inefficient. The advantage of the second approach above is that the ILM-R does not overload resources at ITR1, neither in terms of processing or memory usage, but it needs an enhanced map response in of the form Map:(a/20, ETR1, MS=1), where the MS (More Specific) indicator is set to 1 to indicate to ITR1 that not all subnets in a/20 map to ETR1. The key idea is that aggregation is beneficial, and subnet exceptions must be handled with additional messages or indicators in the maps.
最初のアプローチでは、ITR1がA/20（例外サブネットを含む）の完全なマッピングがあり、A8を含むA/20のアドレスに運命づけられている後続の最初のパケットのクエリを生成する必要がないことです。/24およびA15/24。ただし、不利な点は、かなりの数の例外サブペルフィックスがある場合、A/20に導かれる最初のパケットが長い遅延を経験し、ITR1およびILM-Rのプロセッサが過負荷を経験できることです。さらに、ITR1でのメモリ使用は非常に非効率的です。上記の2番目のアプローチの利点は、ILM-RがITR1でリソースを過負荷にしないことです。処理やメモリの使用に関しては、フォームマップのマップ応答を強化する必要があります：（A/20、ETR1、MS= 1）、MS（より具体的な）インジケータは1に設定されて、ITR1にA/20マップのすべてのサブネットがETR1にわかっていないことを示します。重要なアイデアは、集約が有益であり、サブネットの例外はマップ内の追加のメッセージまたはインジケーターを使用して処理する必要があることです。
Now we highlight another architectural concept related to mapping management (please refer to Figure 3 in [EEMDP_Considerations]). Here we consider the possibility that ETRs may be organized in a hierarchical manner. For instance, ETR7 is higher in the hierarchy relative to ETR1, ETR2, and ETR3, and like-wise ETR8 is higher relative to ETR4, ETR5, and ETR6. For instance, ETRs 1 through 3 can relegate the locator role to ETR7 for their EID address space. In essence, they can allow ETR7 to act as the locator for the delivery networks in their purview. ETR7 keeps a local mapping table for mapping the appropriate EID address space to specific ETRs that are hierarchically associated with it in the level below. In this situation, ETR7 can perform EID address space aggregation across ETRs 1 through 3 and can also include its own immediate EID address space for the purpose of that aggregation. The many details related to this approach and special circumstances involving multihoming of subnets are discussed in detail in [EEMDP_Considerations]. The hierarchical organization of ETRs and delivery networks should help in the future growth and scalability of ETRs and mapping distribution networks. This is essentially recursive map-and-encap, and some of the mapping distribution and management functionality will remain local to topologically neighboring delivery networks that are hierarchically underneath ETRs.
次に、マッピング管理に関連する別のアーキテクチャコンセプトを強調しています（[eemdp_considerations]の図3を参照してください）。ここでは、ETRが階層的に編成される可能性を考慮します。たとえば、ETR7はETR1、ETR2、およびETR3と比較して階層で高く、同様に同様にETR8はETR4、ETR5、およびETR6よりも高くなっています。たとえば、ETR 1〜3は、EIDアドレススペースに対してロケーターの役割をETR7に委ねることができます。本質的に、彼らはETR7が範囲で配信ネットワークのロケーターとして機能することを許可することができます。ETR7は、以下のレベルで階層的に関連付けられている特定のETRに適切なEIDアドレススペースをマッピングするためのローカルマッピングテーブルを保持します。この状況では、ETR7はETR 1から3にわたってEIDアドレス空間集約を実行でき、その集合体の目的のために独自のEIDアドレススペースを含めることもできます。このアプローチとサブネットのマルチホームに関する特別な状況に関連する多くの詳細については、[eemdp_consididerations]で詳細に説明します。ETRと配信ネットワークの階層的な組織は、ETRの将来の成長とスケーラビリティとマッピング配信ネットワークのスケーラビリティに役立つはずです。これは本質的に再帰的なマップアンドエンコップであり、マッピング分布および管理機能の一部は、ETRの下に階層的にあるトポロジーに隣接する配信ネットワークからローカルのままです。
[EEMDP_Considerations] [EEMDP_Presentation] [FIBAggregatability]
[eemdp_consididerations] [eemdp_presentation] [fibaggregatability]
The scheme described in [EEMDP_Considerations] represents one approach to mapping overhead reduction, and it is a general idea that is applicable to any proposal that includes prefix or EID aggregation. A somewhat similar idea is also used in Level-3 aggregation in the FIB aggregation proposal [FIBAggregatability]. There can be cases where deaggregation of EID prefixes occur in such a way that the bulk of an EID prefix P would be attached to one locator (say, ETR1) while a few subprefixes under P would be attached to other locators elsewhere (say, ETR2, ETR3, etc.). Ideally, such cases should not happen; however, in reality it can happen as the RIR's address allocations are imperfect. In addition, as new IP address allocations become harder to get, an IPv4 prefix owner might split previously unused subprefixes of that prefix and allocate them to remote sites (homed to other ETRs). Assuming these situations could arise in practice, the nature of the solution would be that the response from the mapping server for the coarser site would include information about the more specifics. The solution as presented seems correct.
[eemdp_considerations]で説明されているスキームは、オーバーヘッドの削減をマッピングするための1つのアプローチを表しており、プレフィックスまたはEidの集約を含む提案に適用できる一般的なアイデアです。FIB凝集提案のレベル3集計では、やや同様のアイデアも使用されています[凝集性]。EIDプレフィックスのディーグレギュレーションが、EIDプレフィックスPの大部分が1つのロケーター（ETR1など）に接続されるように発生する場合がありますが、Pの下のいくつかのサブプルフィックスは他の場所で他のロケーターに取り付けられます（ETR2たとえば、ETR2、ETR3など）。理想的には、そのようなケースは起こらないはずです。ただし、実際には、RIRのアドレスの割り当てが不完全であるため、発生する可能性があります。さらに、新しいIPアドレスの割り当てが取得が難しくなると、IPv4プレフィックスの所有者は、そのプレフィックスの以前に使用されていないサブプレフィックスを分割し、それらをリモートサイトに割り当てる可能性があります（他のETRに拠点）。これらの状況が実際に発生する可能性があると仮定すると、ソリューションの性質は、より粗いサイトのマッピングサーバーからの応答に、より多くの詳細に関する情報が含まれることです。提示されたソリューションは正しいようです。
The proposal mentions that in Approach 1, the ID-Locator Mapping (ILM) system provides the complete mapping information for an aggregate EID prefix to a querying ITR, including all the maps for the relevant exception subprefixes. The sheer number of such more-specifics can be worrisome, for example, in LISP. What if a company's mobile-node EIDs came out of their corporate EID prefix? Approach 2 is far better but still there may be too many entries for a regional ILM to store. In Approach 2, the ILM communicates that there are more specifics but does not communicate their mask-length. A suggested improvement would be that rather than saying that there are more specifics, indicate what their mask-lengths are. There can be multiple mask lengths. This number should be pretty small for IPv4 but can be large for IPv6.
この提案は、アプローチ1では、ID-Locatorマッピング（ILM）システムが、関連する例外サブペルフィックスのすべてのマップを含む、ITRをクエリするための集計EIDプレフィックスの完全なマッピング情報を提供することに言及しています。たとえば、LISPでは、このような種類の膨大な数が気になる可能性があります。企業のモバイルノードEidsが企業のEIDプレフィックスから出てきた場合はどうなりますか？アプローチ2の方がはるかに優れていますが、地域のILMが保存するにはあまりにも多くのエントリがある可能性があります。アプローチ2では、ILMはより多くの詳細があるが、マスクの長さを通信しないことを伝えています。推奨される改善点は、より詳細があると言うのではなく、マスクの長さが何であるかを示すことです。複数のマスクの長さがあります。この数字はIPv4の場合はかなり小さい必要がありますが、IPv6の場合は大きい場合があります。
Later in the proposal, a different problem is addressed, involving a hierarchy of ETRs and how aggregation of EID prefixes from lower-level ETRs can be performed at a higher-level ETR. The various scenarios here are well illustrated and described. This seems like a good idea, and a solution like LISP can support this as specified. As any optimization scheme would inevitably add some complexity; the proposed scheme for enhancing mapping efficiency comes with some of its own overhead. The gain depends on the details of specific EID blocks, i.e., how frequently the situations (such as an ETR that has a bigger EID block with a few holes) arise.
提案の後半では、ETRの階層を含む別の問題に対処し、上位レベルETRからのEIDプレフィックスの集約を高レベルのETRでどのように実行できるかを伴います。ここのさまざまなシナリオは、よく説明され、説明されています。これは良いアイデアのように思えます。LISPのようなソリューションは、指定されたとおりにこれをサポートできます。最適化スキームは必然的に複雑さを追加するためです。マッピング効率を向上させるための提案されたスキームには、独自のオーバーヘッドが伴います。ゲインは、特定のEIDブロックの詳細に依存します。つまり、状況（いくつかの穴のあるより大きなEIDブロックを持つETRなど）が発生する頻度です。
There are two main points in the critique that are addressed here: (1) The gain depends on the details of specific EID blocks, i.e., how frequently the situations arise such as an ETR having a bigger EID block with a few holes, and (2) Approach 2 is lacking an added feature of conveying just the mask-length of the more specifics that exist as part of the current map response.
批評にはここで扱われている2つの主要なポイントがあります。（1）ゲインは、特定のEIDブロックの詳細に依存します。つまり、ETRがいくつかの穴のあるEIDブロックを持っているETRなどの状況が発生する頻度、および（2）アプローチ2には、現在のマップ応答の一部として存在するより多くの詳細の長さの長さだけを伝えるという追加の機能がありません。
Regarding comment (1) above, there are multiple possibilities
regarding how situations can arise, resulting in allocations having
holes in them. An example of one of these possibilities is as
follows. Org-A has historically received multiple /20s, /22s, and
/24s over the course of time that are adjacent to each other. At the
present time, these prefixes would all aggregate to a /16 but for the
fact that just a few of the underlying /24s have been allocated
elsewhere historically to other organizations by an RIR or ISPs. An
example of a second possibility is that Org-A has an allocation of a
/16. It has suballocated a /22 to one of its subsidiaries, and
subsequently sold the subsidiary to another Org-B. For ease of
keeping the /22 subnet up and running without service disruption, the
/22 subprefix is allowed to be transferred in the acquisition
process. Now the /22 subprefix originates from a different AS and is
serviced by a different ETR (as compared to the parent \16 prefix).
We are in the process of performing an analysis of RIR allocation
data and are aware of other studies (notably at UCLA) that are also
performing similar analysis to quantify the frequency of occurrence
of the holes. We feel that the problem that has been addressed is a
realistic one, and the proposed scheme would help reduce the
overheads associated with the mapping distribution system.
Regarding comment (2) above, the suggested modification to Approach 2 would be definitely beneficial. In fact, we feel that it would be fairly straightforward to dynamically use Approach 1 or Approach 2 (with the suggested modification), depending on whether there are only a few (e.g., <=5) or many (e.g., >5) more specifics, respectively. The suggested modification of notifying the mask-length of the more specifics in the map response is indeed very helpful because then the ITR would not have to resend a map-query for EID addresses that match the EID address in the previous query up to at least mask-length bit positions. There can be a two-bit field in the map response that would be interpreted as follows.
上記のコメント（2）に関しては、2つのアプローチ2への提案された変更は間違いなく有益です。実際、アプローチ1またはアプローチ2（提案された変更を含む）を動的に使用することはかなり簡単だと感じています。それぞれ詳細。マップ応答のより多くの詳細のマスクの長さを通知する提案された変更は、少なくとも前のクエリのEIDアドレスと一致するEIDアドレスのMAP-QUERYを再送信する必要がないため、実際に非常に役立ちます。マスク長ビット位置。マップ応答には、次のように解釈される2ビットフィールドがあります。
(a) value 00: there are no more specifics
(a) 値00：これ以上の詳細はありません
(b) value 01: there are more specifics and their exact information follows in additional map-responses
(b) 値01：さらに詳細があり、それらの正確な情報は追加のマップレスポンズで続きます
(c) value 10: there are more-specifics and the mask-length of the next more-specific is indicated in the current map-response.
(c) 値10：より種類があり、次のより固有のマスクの長さは、現在のMAP応答に示されています。
An additional field will be included that will be used to specify the mask-length of the next more-specific in the case of value 10 (case (c) above).
値10（上記の場合（c））の場合、次のより特異的なマスク長を指定するために使用される追加のフィールドが含まれます。
As the Internet continues its rapid growth, router memory size and CPU cycle requirements are outpacing feasible hardware upgrade schedules. We propose to solve this problem by applying aggregation with increasing scopes to gradually evolve the routing system towards a scalable structure. At each evolutionary step, our solution is able to interoperate with the existing system and provide immediate benefits to adopters to enable deployment. This document summarizes the need for an evolutionary design, the relationship between our proposal and other revolutionary proposals, and the steps of aggregation with increasing scopes. Our detailed proposal can be found in [Evolution].
インターネットが急速に成長し続けるにつれて、ルーターのメモリサイズとCPUサイクルの要件は、実行可能なハードウェアアップグレードスケジュールを上回っています。スコープの増加と集約を適用して、ルーティングシステムをスケーラブルな構造に徐々に進化させることにより、この問題を解決することを提案します。進化の各ステップで、私たちのソリューションは既存のシステムと相互運用し、採用者に即時の利点を提供して展開を可能にすることができます。この文書は、進化的設計の必要性、私たちの提案と他の革新的な提案との関係、およびスコープの増加との集約のステップを要約しています。私たちの詳細な提案は[進化]に記載されています。
Multiple different views exist regarding the routing scalability problem. Networks differ vastly in goals, behavior, and resources, giving each a different view of the severity and imminence of the scalability problem. Therefore, we believe that, for any solution to be adopted, it will start with one or a few early adopters and may not ever reach the entire Internet. The evolutionary approach recognizes that changes to the Internet can only be a gradual process with multiple stages. At each stage, adopters are driven by and rewarded with solving an immediate problem. Each solution must be deployable by individual networks who deem it necessary at a time they deem it necessary, without requiring coordination from other networks, and the solution has to bring immediate relief to a single first-mover.
ルーティングスケーラビリティの問題に関して、複数の異なるビューが存在します。ネットワークは目標、行動、リソースが大きく異なり、スケーラビリティの問題の重大度と差し迫った見方をそれぞれに与えます。したがって、あらゆるソリューションを採用するためには、1つまたは数の早期採用者から始まり、インターネット全体に到達しない可能性があると考えています。進化的アプローチは、インターネットの変化は複数の段階を持つ段階的なプロセスにすぎないことを認識しています。各段階で、採用者は即時の問題を解決することで推進され、報われます。それぞれのソリューションは、他のネットワークからの調整を必要とせずに、必要だと判断した時間に必要と思われる個々のネットワークによって展開できる必要があり、ソリューションは単一のファーストモーバーに即座に救済をもたらす必要があります。
Most proposals take a revolutionary approach that expects the entire Internet to eventually move to some new design whose main benefits would not materialize until the vast majority of the system has been upgraded; their incremental deployment plan simply ensures interoperation between upgraded and legacy parts of the system. In contrast, the evolutionary approach depicts a system where changes may happen here and there as needed, but there is no dependency on the system as a whole making a change. Whoever takes a step forward gains the benefit by solving his own problem, without depending on others to take actions. Thus, deployability includes not only interoperability, but also the alignment of costs and gains.
ほとんどの提案は、システムの大部分がアップグレードされるまで主な利点が実現しない新しいデザインに最終的に移動することを期待する革新的なアプローチを採用しています。彼らの増分展開計画は、システムのアップグレードされた部分とレガシー部分との相互操作を保証するだけです。対照的に、進化的アプローチは、必要に応じてあちこちで変化が起こる可能性のあるシステムを描写していますが、システム全体に依存していない場合があります。他の人に依存して行動を起こすことなく、自分の問題を解決することで、一歩前進する人は誰でも利益を得ます。したがって、展開性には相互運用性だけでなく、コストと増加の整合も含まれます。
The main differences between our approach and more revolutionary map-and-encap proposals are: (a) we do not start with a pre-defined boundary between edge and core; and (b) each step brings immediate benefits to individual first-movers. Note that our proposal neither interferes nor prevents any revolutionary host-based solutions such as ILNP from being rolled out. However, host-based solutions do not bring useful impact until a large portion of hosts have been upgraded. Thus, even if a host-based solution is rolled out in the long run, an evolutionary solution is still needed for the near term.
私たちのアプローチとより革新的な地図と概要の提案の主な違いは次のとおりです。（a）EdgeとCoreの間の事前に定義された境界から始まりません。（b）各ステップは、個々の最初のモーバーに即座に利益をもたらします。私たちの提案は、ILNPなどの革新的なホストベースのソリューションが展開されることを妨げたり、妨げたりしないことに注意してください。ただし、ホストベースのソリューションは、ホストの大部分がアップグレードされるまで有用な影響をもたらしません。したがって、ホストベースのソリューションが長期的に展開されたとしても、短期的には進化的ソリューションが依然として必要です。
Aggregating many routing entries to a fewer number is a basic approach to improving routing scalability. Aggregation can take different forms and be done within different scopes. In our design, the aggregation scope starts from a single router, then expands to a single network and neighbor networks. The order of the following steps is not fixed but is merely a suggestion; it is under each individual network's discretion which steps they choose to take based on their evaluation of the severity of the problems and the affordability of the solutions.
多くのルーティングエントリをより少ない数に集約することは、ルーティングのスケーラビリティを改善するための基本的なアプローチです。集約は異なる形を取り、異なるスコープ内で行うことができます。設計では、集約スコープは単一のルーターから始まり、その後、単一のネットワークと近隣ネットワークに拡張されます。次の手順の順序は修正されていませんが、単なる提案です。それぞれのネットワークの裁量の下で、問題の重大度とソリューションの手頃な価格の評価に基づいて、彼らが選択する措置が取ることを選択します。
1. FIB Aggregation (FA) in a single router. A router algorithmically aggregates its FIB entries without changing its RIB or its routing announcements. No coordination among routers is needed, nor any change to existing protocols. This brings scalability relief to individual routers with only a software upgrade.
1. 単一のルーター内のFIB凝集（FA）。ルーターは、rib骨やルーティングアナウンスを変更せずに、FIBエントリをアルゴリズム的に集約します。ルーター間の調整は必要ありませんし、既存のプロトコルの変更も必要ありません。これにより、ソフトウェアのアップグレードのみを使用して、個々のルーターにスケーラビリティリリーフがもたらされます。
2. Enabling 'best external' on Provider Edge routers (PEs), Autonomous System Border Routers (ASBRs), and Route Reflectors (RRs), and turning on next-hop-self on RRs. For hierarchical networks, the RRs in each Point of Presence (PoP) can serve as a default gateway for nodes in the PoP, thus allowing the non-RR nodes in each PoP to maintain smaller routing tables that only include paths that egress that PoP. This is known as 'topology-based mode' Virtual Aggregation, and can be done with existing hardware and configuration changes only. Please see [Evolution_Grow_Presentation] for details.
2. プロバイダーエッジルーター（PES）、自律システムボーダールーター（ASBRS）、およびルートリフレクター（RRS）で「ベスト外部」を有効にし、RRSで次のホップセルフをオンにします。階層ネットワークの場合、各存在ポイント（POP）のRRSは、POPのノードのデフォルトゲートウェイとして機能するため、各POPの非RRノードが、POPを出力するパスのみを含む小さなルーティングテーブルを維持できるようにします。これは「トポロジベースモード」仮想集約として知られており、既存のハードウェアと構成の変更のみで実行できます。詳細については、[evolution_grow_presentation]を参照してください。
3. Virtual Aggregation (VA) in a single network. Within an AS, some fraction of existing routers are designated as Aggregation Point Routers (APRs). These routers are either individually or collectively maintain the full FIB table. Other routers may suppress entries from their FIBs, instead forwarding packets to APRs, which will then tunnel the packets to the correct egress routers. VA can be viewed as an intra-domain map-and-encap system to provide the operators with a control mechanism for the FIB size in their routers.
3. 単一のネットワーク内の仮想集約（VA）。AS内で、既存のルーターの一部が集約点ルーター（APR）として指定されています。これらのルーターは、FIBテーブル全体を個別にまたは集合的に維持しています。他のルーターは、FIBからのエントリを抑制し、代わりにパケットをAPRに転送し、パケットを正しい出力ルーターにトンネルします。VAは、ドメイン内のマップアンドENCAPシステムと見なすことができ、ルーターのFIBサイズの制御メカニズムをオペレーターに提供できます。
4. VA across neighbor networks. When adjacent networks have VA deployed, they can go one step further by piggybacking egress router information on existing BGP announcements, so that packets can be tunneled directly to a neighbor network's egress router. This improves packet delivery performance by performing the encapsulation/decapsulation only once across these neighbor networks, as well as reducing the stretch of the path.
4. 近隣ネットワーク全体のVA。隣接するネットワークがVAを展開した場合、既存のBGPアナウンスに関する出力ルーター情報をピギーバックすることでさらに一歩進むことができ、パケットを近隣ネットワークの出口ルーターに直接トンネリングできます。これにより、これらの近隣ネットワーク全体でカプセル化/脱カプセル化を1回だけ実行することと、パスのストレッチを削減することにより、パケットの配信パフォーマンスが向上します。
5. Reducing RIB Size by separating the control plane from the data plane. Although a router's FIB can be reduced by FA or VA, it usually still needs to maintain the full RIB to produce complete routing announcements to its neighbors. To reduce the RIB size, a network can set up special boxes, which we call controllers, to take over the External BGP (eBGP) sessions from border routers. The controllers receive eBGP announcements, make routing decisions, and then inform other routers in the same network of how to forward packets, while the regular routers just focus on the job of forwarding packets. The controllers, not being part of the data path, can be scaled using commodity hardware.
5. コントロールプレーンをデータプレーンから分離することにより、rib骨のサイズを縮小します。ルーターのFIBはFAまたはVAによって削減される可能性がありますが、通常、隣人への完全なルーティングアナウンスを作成するために完全なrib骨を維持する必要があります。リブのサイズを縮小するために、ネットワークはコントローラーと呼ばれる特別なボックスをセットアップして、ボーダールーターから外部BGP（EBGP）セッションを引き継ぐことができます。コントローラーはEBGPアナウンスを受け取り、ルーティングの決定を下し、同じネットワーク内の他のルーターにパケットを転送する方法を通知しますが、通常のルーターはパケットを転送する仕事に焦点を合わせます。データパスの一部ではないコントローラーは、コモディティハードウェアを使用してスケーリングできます。
6. Insulating forwarding routers from routing churn. For routers with a smaller RIB, the rate of routing churn is naturally reduced. Further reduction can be achieved by not announcing failures of customer prefixes into the core, but handling these failures in a data-driven fashion, e.g., a link failure to an edge network is not reported unless and until there are data packets that are heading towards the failed link.
6. ルーティングチャーンからの転送ルーターを絶縁します。rib骨が小さいルーターの場合、ルーティングチャーンの速度は自然に減少します。顧客の接頭辞の障害をコアに発表することではなく、データ駆動型の方法でこれらの障害を処理することで、さらなる削減を達成できます。失敗したリンク。
[Evolution] [Evolution_Grow_Presentation]
[Evolution] [Evolution_Grow_Presentation]
All of the RRG proposals that scale the routing architecture share one fundamental approach, route aggregation, in different forms, e.g., LISP removes "edge prefixes" using encapsulation at ITRs, and ILNP achieves the goal by locator rewrite. In this evolutionary path proposal, each stage of the evolution applies aggregation with increasing scopes to solve a specific scalability problem, and eventually the path leads towards global routing scalability. For example, it uses FIB aggregation at the single router level, virtual aggregation at the network level, and then between neighboring networks at the inter-domain level.
ルーティングアーキテクチャをスケーリングするすべてのRRG提案は、1つの基本的なアプローチ、ルート集約をさまざまな形式で共有します。たとえば、LISPはITRでのカプセル化を使用して「エッジプレフィックス」を削除し、ILNPはロケーターの書き直しで目標を達成します。この進化のパス提案では、進化の各段階は、特定のスケーラビリティの問題を解決するためにスコープの増加と集約を適用し、最終的にはグローバルなルーティングスケーラビリティにつながります。たとえば、単一のルーターレベルでFIB集約、ネットワークレベルでの仮想集約、およびドメイン間レベルで隣接するネットワーク間で使用します。
Compared to other proposals, this proposal has the lowest hurdle to deployment, because it does not require that all networks move to use a global mapping system or upgrade all hosts, and it is designed for each individual network to get immediate benefits after its own deployment.
他の提案と比較して、この提案は、すべてのネットワークがグローバルマッピングシステムを使用するか、すべてのホストをアップグレードするために移動する必要がないため、展開に対する最も低いハードルを持っています。。
Criticisms of this proposal fall into two types. The first type concerns several potential issues in the technical design as listed below:
この提案に対する批判は、2つのタイプに分類されます。最初のタイプは、以下にリストされている技術設計におけるいくつかの潜在的な問題に関するものです。
1. FIB aggregation, at level-3 and level-4, may introduce extra routable space. Concerns have been raised about the potential routing loops resulting from forwarding otherwise non-routable packets, and the potential impact on Reverse Path Forwarding (RPF) checking. These concerns can be addressed by choosing a lower level of aggregation and by adding null routes to minimize the extra space, at the cost of reduced aggregation gain.
1. FIB凝集は、レベル3およびレベル4で、追加のルーティング可能なスペースを導入する可能性があります。他の方法では不可能なパケットを転送することから生じる潜在的なルーティングループ、およびリバースパス転送（RPF）チェックへの潜在的な影響について懸念が提起されています。これらの懸念は、凝集の低下を犠牲にして余分なスペースを最小限に抑えるためにヌルルートを追加することにより、凝集性を最小限に抑えることにより、nullルートを追加することにより、対処できます。
2. Virtual Aggregation changes the traffic paths in an ISP network, thereby introducing stretch. Changing the traffic path may also impact the reverse path checking practice used to filter out packets from spoofed sources. More analysis is need to identify the potential side-effects of VA and to address these issues.
2. 仮想集約は、ISPネットワーク内のトラフィックパスを変更して、ストレッチを導入します。トラフィックパスを変更すると、スプーフィングされたソースからパケットを除外するために使用されるリバースパスチェックプラクティスにも影響を与える可能性があります。より多くの分析では、VAの潜在的な副作用を特定し、これらの問題に対処する必要があります。
3. The current Virtual Aggregation description is difficult to understand, due to its multiple options for encapsulation and popular prefix configurations, which makes the mechanism look overly complicated. More thought is needed to simplify the design and description.
3. 現在の仮想集約の説明は、カプセル化と一般的なプレフィックス構成の複数のオプションがあるため、メカニズムが非常に複雑に見えるため、理解するのが困難です。デザインと説明を簡素化するには、より多くの考えが必要です。
4. FIB Aggregation and Virtual Aggregation may require additional operational cost. There may be new design trade-offs that the operators need to understand in order to select the best option for their networks. More analysis is needed to identify and quantify all potential operational costs.
4. FIBの集約と仮想集約には、追加の運用コストが必要になる場合があります。ネットワークに最適なオプションを選択するために、オペレーターが理解する必要がある新しい設計トレードオフがあるかもしれません。すべての潜在的な運用コストを特定して定量化するには、さらに分析が必要です。
5. In contrast to a number of other proposals, this solution does not provide mobility support. It remains an open question as to whether the routing system should handle mobility.
5. 他の多くの提案とは対照的に、このソリューションはモビリティサポートを提供しません。ルーティングシステムがモビリティを処理する必要があるかどうかについては、未解決の問題のままです。
The second criticism is whether deploying quick fixes like FIB aggregation would alleviate scalability problems in the short term and reduce the incentives for deploying a new architecture; and whether an evolutionary approach would end up with adding more and more patches to the old architecture, and not lead to a fundamentally new architecture as the proposal had expected. Though this solution may get rolled out more easily and quickly, a new architecture, if/ once deployed, could solve more problems with cleaner solutions.
2番目の批判は、FIB集約のような迅速な修正を展開することで、短期的にスケーラビリティの問題を軽減し、新しいアーキテクチャを展開するためのインセンティブを減らすかどうかです。そして、進化的アプローチが古いアーキテクチャにますます多くのパッチを追加することになり、提案が予想していたように根本的に新しいアーキテクチャにつながることはないかどうか。このソリューションはより簡単かつ迅速に展開される可能性がありますが、新しいアーキテクチャは、展開された場合/展開された場合、よりクリーンなソリューションでより多くの問題を解決する可能性があります。
No rebuttal was submitted for this proposal.
この提案のために反論は提出されませんでした。
Name-based sockets are an evolution of the existing address-based sockets, enabling applications to initiate and receive communication sessions based on the use of domain names in lieu of IP addresses. Name-based sockets move the existing indirection from domain names to IP addresses from its current position in applications down to the IP layer. As a result, applications communicate exclusively based on domain names, while the discovery, selection, and potentially in-session re-selection of IP addresses is centrally performed by the IP stack itself.
名前ベースのソケットは、既存のアドレスベースのソケットの進化であり、アプリケーションがIPアドレスの代わりにドメイン名の使用に基づいて通信セッションを開始および受信できるようにします。名前ベースのソケットは、既存の間接をドメイン名からIPアドレスに移動します。アプリケーションの現在の位置からIPレイヤーまで。その結果、アプリケーションはドメイン名のみに基づいて通信しますが、IPアドレスの発見、選択、および潜在的にセッション内の再選択は、IPスタック自体によって中央に実行されます。
Name-based sockets help mitigate the Internet routing scalability problem by separating naming and addressing more consistently than what is possible with the existing address-based sockets. This supports IP address aggregation because it simplifies the use of IP addresses with high topological significance, as well as the dynamic replacement of IP addresses during network-topological and host-attachment changes.
名前ベースのソケットは、既存のアドレスベースのソケットで可能なものよりも一貫して命名を分離し、アドレス指定することにより、インターネットルーティングのスケーラビリティ問題を軽減するのに役立ちます。これにより、IPアドレスの集約がサポートされます。これは、トポロジカルな有意性が高いIPアドレスの使用と、ネットワークトポロジーおよびホストアタックメントの変更中のIPアドレスの動的置換を簡素化するためです。
A particularly positive effect of name-based sockets on Internet routing scalability is the new incentives for edge network operators to use provider-assigned IP addresses, which are more aggregatable than the typically preferred provider-independent IP addresses. Even though provider-independent IP addresses are harder to get and more expensive than provider-assigned IP addresses, many operators desire provider-independent addresses due to the high indirect cost of provider-assigned IP addresses. This indirect cost is comprised of both difficulties in multihoming, and tedious and largely manual renumbering upon provider changes.
インターネットルーティングのスケーラビリティに対する名前ベースのソケットの特にプラスの効果は、エッジネットワークオペレーターがプロバイダーに割り当てられたIPアドレスを使用する新しいインセンティブです。プロバイダーに依存しないIPアドレスは、プロバイダーに割り当てられたIPアドレスよりも取得が難しく、高価ですが、多くのオペレーターはプロバイダーが割り当てられたIPアドレスの間接コストが高いため、プロバイダーに依存しないアドレスを望んでいます。この間接的なコストは、マルチホームの両方の困難と、プロバイダーの変更に応じて退屈で手動で手作業で構成されています。
Name-based sockets reduce the indirect cost of provider-assigned IP addresses in three ways, and hence make the use of provider-assigned IP addresses more acceptable: (1) They enable fine-grained and responsive multihoming. (2) They simplify renumbering by offering an easy means to replace IP addresses in referrals with domain names. This helps avoiding updates to application and operating system configurations, scripts, and databases during renumbering. (3) They facilitate low-cost solutions that eliminate renumbering altogether. One such low-cost solution is IP address translation, which in combination with name-based sockets loses its adverse impact on applications.
名前ベースのソケットは、プロバイダーが割り当てられたIPアドレスの間接コストを3つの方法で削減し、プロバイダーが割り当てられたIPアドレスをより受け入れやすくします。（2）紹介のIPアドレスをドメイン名に置き換える簡単な手段を提供することにより、変更を簡素化します。これにより、名前を変更中にアプリケーションおよびオペレーティングシステムの構成、スクリプト、およびデータベースの更新を回避するのに役立ちます。（3）彼らは、非買い物を完全に排除する低コストのソリューションを促進します。このような低コストのソリューションの1つは、IPアドレス変換であり、名前ベースのソケットと組み合わせてアプリケーションに悪影響を及ぼします。
The prerequisite for a positive effect of name-based sockets on Internet routing scalability is their adoption in operating systems and applications. Operating systems should be augmented to offer name-based sockets as a new alternative to the existing address-based sockets, and applications should use name-based sockets for their communications. Neither an instantaneous, nor an eventually complete transition to name-based sockets is required, yet the positive effect on Internet routing scalability will grow with the extent of this transition.
インターネットルーティングのスケーラビリティに対する名前ベースのソケットのプラスの効果の前提条件は、オペレーティングシステムとアプリケーションでの採用です。オペレーティングシステムは、既存のアドレスベースのソケットの新しい代替品として名前ベースのソケットを提供するために拡張する必要があり、アプリケーションは通信に名前ベースのソケットを使用する必要があります。瞬間的であり、最終的には名前ベースのソケットへの完全な移行は必要ありませんが、インターネットルーティングのスケーラビリティに対するプラスの効果は、この遷移の範囲で成長します。
Name-based sockets were hence designed with a focus on deployment incentives, comprising both immediate deployment benefits as well as low deployment costs. Name-based sockets provide a benefit to application developers because the alleviation of applications from IP address management responsibilities simplifies and expedites application development. This benefit is immediate owing to the backwards compatibility of name-based sockets with legacy applications and legacy peers. The appeal to application developers, in turn, is an immediate benefit for operating system vendors who adopt name-based sockets.
したがって、名前ベースのソケットは、展開インセンティブに焦点を当てて設計され、即時展開の特典と低い展開コストの両方を含みます。名前ベースのソケットは、IPアドレス管理の責任からのアプリケーションの緩和がアプリケーション開発を簡素化し、促進するため、アプリケーション開発者に利益をもたらします。この利点は、レガシーアプリケーションとレガシーピアとの名前ベースのソケットの後方互換性のために、即時です。次に、アプリケーション開発者へのアピールは、名前ベースのソケットを採用するオペレーティングシステムベンダーにとって即時の利点です。
Name-based sockets furthermore minimize deployment costs: Alternative techniques to separate naming and addressing provide applications with "surrogate IP addresses" that dynamically map onto regular IP addresses. A surrogate IP address is indistinguishable from a regular IP address for applications, but does not have the topological significance of a regular IP address. Mobile IP and the Host Identity Protocol are examples of such separation techniques. Mobile IP uses "home IP addresses" as surrogate IP addresses with reduced topological significance. The Host Identity Protocol uses "host identifiers" as surrogate IP addresses without topological significance. A disadvantage of surrogate IP addresses is their incurred cost in terms of extra administrative overhead and, for some techniques, extra infrastructure. Since surrogate IP addresses must be resolvable to the corresponding regular IP addresses, they must be provisioned in the DNS or similar infrastructure. Mobile IP uses a new infrastructure of home agents for this purpose, while the Host Identity Protocol populates DNS servers with host identities. Name-based sockets avoid this cost because they function without surrogate IP addresses, and hence without the provisioning and infrastructure requirements that accompany surrogate addresses.
さらに、展開コストを最小限に抑える名前ベースのソケット：命名とアドレス指定を分離する代替手法では、通常のIPアドレスに動的にマッピングされる「代理IPアドレス」を提供します。代理IPアドレスは、アプリケーション用の通常のIPアドレスと区別できませんが、通常のIPアドレスのトポロジカルな重要性はありません。モバイルIPとホストIDプロトコルは、このような分離技術の例です。モバイルIPは、「ホームIPアドレス」を代理IPアドレスとして使用します。ホストIDプロトコルは、「ホスト識別子」をトポロジーの重要性なしに代理IPアドレスとして使用します。代理IPアドレスの欠点は、追加の管理オーバーヘッドと、一部のテクニックでは追加のインフラストラクチャの点で発生したコストです。代理IPアドレスは、対応する通常のIPアドレスに対して解決可能である必要があるため、DNSまたは同様のインフラストラクチャでプロビジョニングする必要があります。モバイルIPは、この目的のためにホームエージェントの新しいインフラストラクチャを使用しますが、ホストIDプロトコルはDNSサーバーにホストIDに浸透します。名前ベースのソケットは、サロゲートIPアドレスなしで機能するため、代理アドレスに付随するプロビジョニングおよびインフラストラクチャの要件がないため、このコストを回避します。
Certainly, some edge networks will continue to use provider-independent addresses despite name-based sockets, perhaps simply due to inertia. But name-based sockets will help reduce the number of those networks, and thus have a positive impact on Internet routing scalability.
確かに、一部のエッジネットワークは、おそらく単に慣性のために、名前ベースのソケットにもかかわらず、プロバイダーに依存しないアドレスを引き続き使用します。しかし、名前ベースのソケットは、これらのネットワークの数を減らすのに役立ち、したがって、インターネットルーティングのスケーラビリティにプラスの影響を与えます。
A more comprehensive description of name-based sockets can be found in [Name_Based_Sockets].
名前ベースのソケットのより包括的な説明は、[name_based_sockets]にあります。
[Name_Based_Sockets]
[name_based_sockets]
Name-based sockets contribution to the routing scalability problem is to decrease the reliance on PI addresses, allowing a greater use of PA addresses, and thus a less fragmented routing table. It provides end hosts with an API which makes the applications address-agnostic. The name abstraction allows the hosts to use any type of locator, independent of format or provider. This increases the motivation and usability of PA addresses. Some applications, in particular bootstrapping applications, may still require hard coded IP addresses, and as such will still motivate the use of PI addresses.
ルーティングスケーラビリティの問題への名前ベースのソケットの貢献は、PIアドレスへの依存を減らし、PAアドレスのより多くの使用を可能にすることであり、したがって、断片化されていないルーティングテーブルが得られます。エンドホストにAPIを提供し、アプリケーションをアドレスに依存させるものにします。名前の抽象化により、ホストはフォーマットまたはプロバイダーとは無関係に、あらゆるタイプのロケーターを使用できます。これにより、PAアドレスの動機と使いやすさが向上します。一部のアプリケーション、特にブートストラップアプリケーションでは、ハードコード化されたIPアドレスが必要になる場合があるため、PIアドレスの使用の動機付けが依然として動機付けられます。
The main incentives and drivers are geared towards the transition of applications to the name-based sockets. Adoption by applications will be driven by benefits in terms of reduced application development cost. Legacy applications are expected to migrate to the new API at a slower pace, as the name-based sockets are backwards compatible, this can happen in a per-host fashion. Also, not all applications can be ported to a FQDN dependent infrastructure, e.g., DNS functions. This hurdle is manageable, and may not be a definite obstacle for the transition of a whole domain, but it needs to be taken into account when striving for mobility/multihoming of an entire site. The transition of functions on individual hosts may be trivial, either through upgrades/changes to the OS or as linked libraries. This can still happen incrementally and independently, as compatibility is not affected by the use of name-based sockets.
主なインセンティブとドライバーは、名前ベースのソケットへのアプリケーションの移行に向けられています。アプリケーションによる採用は、アプリケーション開発コストの削減という点で利益によって推進されます。レガシーアプリケーションは、名前ベースのソケットが後方互換性があるため、遅いペースで新しいAPIに移行することが期待されています。これは、ホストあたりの方法で発生する可能性があります。また、すべてのアプリケーションをFQDNに従ったインフラストラクチャ、たとえばDNS関数に移植できるわけではありません。このハードルは管理可能であり、ドメイン全体の移行のための明確な障害ではない場合がありますが、サイト全体のモビリティ/マルチホームを目指して努力する際に考慮する必要があります。個々のホストでの関数の遷移は、OSのアップグレード/変更またはリンクされたライブラリとしての些細なことです。互換性は名前ベースのソケットの使用によって影響を受けることはないため、これは徐々に独立して発生する可能性があります。
Name-based sockets rely on the transition of individual applications and are backwards compatible, so they do not require bilateral upgrades. This allows each host to migrate its applications independently. Name-based sockets may make an individual client agnostic to the networking medium, be it PA/PI IP-addresses or in a the future an entirely different networking medium. However, an entire edge-network, with internal and external services will not be able to make a complete transition in the near future. Hence, even if a substantial fraction of the hosts in an edge-network use name-based sockets, PI addresses may still be required by the edge-network. In short, new services may be implemented using name-based sockets, old services may be ported. Name-based sockets provide an increased motivation to move to PA-addresses as actual provider independence relies less and less on PI-addressing.
名前ベースのソケットは、個々のアプリケーションの移行に依存しており、後方互換性があるため、二国間のアップグレードは必要ありません。これにより、各ホストはアプリケーションを個別に移行できます。名前ベースのソケットは、PA/PI IP Addressesであろうと、まったく異なるネットワーキング媒体であろうと、個々のクライアントをネットワーキング媒体に不可知論します。ただし、内部および外部サービスを備えたエッジネットワーク全体は、近い将来に完全な移行を行うことはできません。したがって、エッジネットワークのホストのかなりの部分が名前ベースのソケットを使用している場合でも、PIアドレスは引き続きEdgeネットワークで必要とされる場合があります。要するに、名前ベースのソケットを使用して新しいサービスを実装することができ、古いサービスが移植される場合があります。名前ベースのソケットは、実際のプロバイダーの独立性がpi-addressingに依存することをますます少なくするため、PAアドレスへの移行の動機を高めます。
No rebuttal was submitted for this proposal.
この提案のために反論は提出されませんでした。
16. Routing and Addressing in Networks with Global Enterprise Recursion (IRON-RANGER)
16. グローバルエンタープライズの再帰を備えたネットワークでのルーティングとアドレス指定（アイアンレンジャー）
RANGER is a locator/identifier separation approach that uses IP-in-IP encapsulation to connect edge networks across transit networks such as the global Internet. End systems use endpoint interface identifier (EID) addresses that may be routable within edge networks but do not appear in transit network routing tables. EID to Routing Locator (RLOC) address bindings are instead maintained in mapping tables and also cached in default router FIBs (i.e., very much the same as for the global DNS and its associated caching resolvers). RANGER enterprise networks are organized in a recursive hierarchy with default mappers connecting lower layers to the next higher layer in the hierarchy. Default mappers forward initial packets and push mapping information to lower-tier routers and end systems through secure redirection.
Rangerは、IP-in-IPカプセル化を使用して、グローバルインターネットなどのトランジットネットワーク全体のエッジネットワークを接続するロケーター/識別子分離アプローチです。エンドシステムは、エッジネットワーク内でルーティング可能であるが、トランジットネットワークルーティングテーブルには表示されない可能性のあるエンドポイントインターフェイス識別子（EID）アドレスを使用します。EIDからルーティングロケーター（RLOC）アドレスバインディングは、代わりにテーブルのマッピングで維持され、デフォルトのルーターFIBでキャッシュされます（つまり、グローバルDNSおよび関連するキャッシュリゾルバーとほぼ同じです）。Ranger Enterprise Networksは、下位層を階層の次の高層に接続するデフォルトマッパーを備えた再帰階層で編成されています。デフォルトのマッパーは、初期パケットを転送し、マッピング情報を低層ルーターにプッシュし、安全なリダイレクトを介してシステムを終了します。
RANGER is an architectural framework derived from the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP).
レンジャーは、敷地内自動トンネルアドレス指定プロトコル（ISATAP）から派生したアーキテクチャフレームワークです。
o provides a scalable routing system alternative in instances where dynamic routing protocols are impractical
o 動的ルーティングプロトコルが非現実的である場合に、スケーラブルなルーティングシステムの代替品を提供します
o naturally supports a recursively-nested "network-of-networks" (or, "enterprise-within-enterprise") hierarchy
o 自然に、再帰的にネストされた「ネットワークオブネットワーク」（または、「エンタープライズ - エンテルプライズ」）階層をサポートします
o uses asymmetric security mechanisms (i.e., secure neighbor discovery) to secure router discovery and the redirection mechanism
o 非対称セキュリティメカニズム（つまり、隣接する発見を安全にする）を使用して、ルーターの発見とリダイレクトメカニズムを保護します
o can quickly detect path failures and pick alternate routes
o パス障害をすばやく検出し、代替ルートを選択できます
o naturally supports provider-independent addressing
o 当然、プロバイダーに依存しないアドレス指定をサポートします
o support for site multihoming and traffic engineering
o サイトのマルチホミングおよび交通工学のサポート
o ingress filtering for multihomed sites
o マルチホームサイトのイングレスフィルタリング
o mobility-agile through explicit cache invalidation (much more reactive than dynamic DNS)
o 明示的なキャッシュの無効化を介したモビリティアジャイル（動的DNSよりもはるかに反応的）
o supports neighbor discovery and neighbor unreachability detection over tunnels
o 隣人の発見と、トンネルを介した隣人の到達不能の検出をサポートします
o no changes to end systems
o エンドシステムに変更はありません
o no changes to most routers
o ほとんどのルーターに変更はありません
o supports IPv6 transition o compatible with true identity/locator split mechanisms such as HIP (i.e., packets contain a HIP Host Identity Tag (HIT) as an end system identifier, IPv6 address as endpoint interface identifier (EID) in the inner IP header and IPv4 address as Routing LOCator (RLOC) in the outer IP header)
o IPv6遷移o hipなどの真のアイデンティティ/ロケータースプリットメカニズムと互換性のあるIPv6トランジションoサポート（つまり、パケットには、エンドシステム識別子としてのヒップホストIDタグ（HIT）、IPv6アドレスが内側IPヘッダーのエンドポイントインターフェイス識別子（EID）、IPv444444は含まれます。外側のIPヘッダーのルーティングロケーター（RLOC）としてアドレス
o prototype code available
o プロトタイプコードが利用可能です
o new code needed in enterprise border routers
o エンタープライズボーダールーターで必要な新しいコード
o locator/path liveness detection using RFC 4861 neighbor unreachability detection (i.e., extra control messages, but data-driven) [RFC4861]
o RFCを使用したロケーター/パスの責任検出4861ネイバーの到達不可能性検出（つまり、追加の制御メッセージですが、データ駆動型）[RFC4861]
[IRON] [RANGER_Scen] [VET] [SEAL] [RFC5201] [RFC5214] [RFC5720]
[鉄] [ranger_scen] [vet] [seal] [rfc5201] [rfc5214] [rfc5720] [rfc5214] [rfc5214]
The RANGER architectural framework is intended to be applicable for a Core-Edge Separation (CES) architecture for scalable routing, using either IPv4 or IPv6 -- or using both in an integrated system which may carry one protocol over the other.
Ranger Architectural Frameworkは、IPv4またはIPv6のいずれかを使用して、または1つのプロトコルを他方よりも積分システムで使用する両方を使用する、スケーラブルなルーティング用のコアエッジ分離（CES）アーキテクチャに適用できることを目的としています。
However, despite [IRON] being readied for publication as an experimental RFC, the framework falls well short of the level of detail required to envisage how it could be used to implement a practical scalable routing solution. For instance, the document contains no specification for a mapping protocol, or how the mapping lookup system would work on a global scale.
ただし、[鉄]は実験的なRFCとして公開されるために準備されているにもかかわらず、フレームワークは、実用的なスケーラブルなルーティングソリューションを実装するためにどのように使用できるかを想定するために必要な詳細レベルには十分にありません。たとえば、ドキュメントには、マッピングプロトコルの仕様や、マッピングルックアップシステムがグローバルスケールで機能する方法が含まれていません。
There is no provision for RANGER's ITR-like routers being able to probe the reachability of end-user networks via multiple ETR-like routers -- nor for any other approach to multihoming service restoration.
RangerのITRのようなルーターが、複数のETR様ルーターを介してエンドユーザーネットワークの到達可能性を調べることも、マルチホームサービスの復元への他のアプローチについても、規定はありません。
Nor is there any provision for inbound TE or support of mobile devices which frequently change their point of attachment.
また、添付ファイルのポイントを頻繁に変更するモバイルデバイスのインバウンドTEまたはサポートの規定もありません。
Therefore, in its current form, RANGER cannot be contemplated as a superior scalable routing solution to some other proposals which are specified in sufficient detail and which appear to be feasible.
したがって、現在の形式では、レンジャーは、十分な詳細で指定され、実現可能であると思われる他の提案に対する優れたスケーラブルなルーティングソリューションとして考えられません。
RANGER uses its own tunneling and PMTUD management protocol: SEAL. Adoption of SEAL in its current form would prevent the proper utilization of jumbo frame paths in the DFZ, which will become the norm in the future. SEAL uses "Packet Too Big" [RFC4443] and "Fragmentation Needed" [RFC0792] messages to the sending host only to fix a preset maximum packet length. To avoid the need for the SEAL layer to fragment packets of this length, this MTU value (for the input of the tunnel) needs to be set significantly below 1500 bytes, assuming the typically ~1500 byte MTU values for paths across the DFZ today. In order to avoid this excessive fragmentation, this value could only be raised to a ~9k byte value at some time in the future where essentially all paths between ITRs and ETRs were jumbo frame capable.
Rangerは独自のトンネルとPMTUD管理プロトコル：SEALを使用しています。現在の形でシールを採用すると、DFZのジャンボフレームパスの適切な利用が妨げられ、将来的には標準になります。シールは、「パケットが大きすぎる」[RFC4443]と「断片化が必要」[RFC0792]メッセージを送信ホストに使用して、プリセットの最大パケット長を修正します。シール層がこの長さのパケットをフラグメントする必要性を回避するために、このMTU値（トンネルの入力の場合）は、今日のDFZ全体のパスの通常1500バイトのMTU値を想定して、1500バイトを大幅に下回る必要があります。この過度の断片化を回避するために、この値は、ITRとETRの間の本質的にすべてのパスがジャンボフレームが有能であった将来のある時点でのみ、約9kバイト値に上げることができました。
The Internet Routing Overlay Network (IRON) [IRON] is a scalable Internet routing architecture that builds on the RANGER recursive enterprise network hierarchy [RFC5720]. IRON bonds together participating RANGER networks using VET [VET] and SEAL [SEAL] to enable secure and scalable routing through automatic tunneling within the Internet core. The IRON-RANGER automatic tunneling abstraction views the entire global Internet DFZ as a virtual Non-Broadcast Multi-Access (NBMA) link similar to ISATAP [RFC5214].
インターネットルーティングオーバーレイネットワーク（Iron）[Iron]は、Ranger Recursive Enterprise Network Hierarchy [RFC5720]に基づいたスケーラブルなインターネットルーティングアーキテクチャです。鉄結合は、VET [VET]とSEAL [SEAL]を使用して参加しているレンジャーネットワークを一緒にして、インターネットコア内の自動トンネリングを介して安全でスケーラブルなルーティングを可能にします。鉄レンジャーの自動トンネル抽象化は、Global Internet DFZ全体を、ISATAPと同様の仮想非ブロードキャストマルチアクセス（NBMA）リンクとして表示します[RFC5214]。
IRON-RANGER is an example of a Core-Edge Separation (CES) system. Instead of a classical mapping database, however, IRON-RANGER uses a hybrid combination of a proactive dynamic routing protocol for distributing highly aggregated Virtual Prefixes (VPs) and an on-demand data driven protocol for distributing more-specific Provider-Independent (PI) prefixes derived from the VPs.
鉄レンジャーは、コアエッジ分離（CES）システムの例です。ただし、古典的なマッピングデータベースの代わりに、Iron Rangerは、高度に集約された仮想プレフィックス（VPS）を分散するためのプロアクティブな動的ルーティングプロトコルのハイブリッド組み合わせと、より特異的プロバイダーに独立した分布（PI）を分散するためのオンデマンドデータ駆動型プロトコルのハイブリッド組み合わせを使用します。VPSから派生したプレフィックス。
The IRON-RANGER hierarchy consists of recursively-nested RANGER enterprise networks joined together by IRON routers that participate in a global BGP instance. The IRON BGP instance is maintained separately from the current Internet BGP Routing LOCator (RLOC) address space (i.e., the set of all public IPv4 prefixes in the Internet). Instead, the IRON BGP instance maintains VPs taken from Endpoint Interface iDentifier (EID) address space, e.g., the IPv6 global unicast address space. To accommodate scaling, only O(10k) -- O(100k) VPs are allocated e.g., using /20 or shorter IPv6 prefixes.
鉄レンジャーの階層は、グローバルなBGPインスタンスに参加する鉄ルーターによって結合された再帰的にネストされたレンジャーエンタープライズネットワークで構成されています。鉄BGPインスタンスは、現在のインターネットBGPルーティングロケーター（RLOC）アドレス空間（つまり、インターネット内のすべてのパブリックIPv4プレフィックスのセット）とは別に維持されます。代わりに、Iron BGPインスタンスは、Endpointインターフェイス識別子（EID）アドレス空間（例えばIPv6グローバルユニキャストアドレススペースから取得したVP）を維持します。スケーリングに対応するために、O（10K）-O（100K）VPSのみが、 /20または短いIPv6プレフィックスを使用して割り当てられます。
IRON routers lease portions of their VPs as Provider-Independent (PI) prefixes for customer equipment (CEs), thereby creating a sustainable business model. CEs that lease PI prefixes propagate address mapping(s) throughout their attached RANGER networks and up to VP-owning IRON router(s) through periodic transmission of "bubbles" with authentication and PI prefix information. Routers in RANGER networks and IRON routers that receive and forward the bubbles securely install PI prefixes in their FIBs, but do not inject them into the RIB. IRON routers therefore keep track of only their customer base via the FIB entries and keep track of only the Internet-wide VP database in the RIB.
Iron Routersは、VPSのプロバイダーに依存しない（PI）プレフィックス（顧客機器（CES）としての一部をリースし、それによって持続可能なビジネスモデルを作成します。PIプレフィックスをリースするCESは、認証とPIプレフィックス情報を使用した「バブル」を定期的に送信することにより、付属のレンジャーネットワーク全体とVP所有の鉄ルーターまでアドレスマッピングを伝播します。レンジャーネットワークのルーターとバブルを受信および転送する鉄ルーターのルーターは、PIプレフィックスをFIBにしっかりと取り付けますが、リブに注入しないでください。したがって、鉄のルーターは、FIBエントリを介して顧客ベースのみを追跡し、リブ内のインターネット全体のVPデータベースのみを追跡します。
IRON routers propagate more-specific prefixes using secure redirection to update router FIBs. Prefix redirection is driven by the data plane and does not affect the control plane. Redirected prefixes are not injected into the RIB, but rather are maintained as FIB soft state that is purged after expiration or route failure. Neighbor unreachability detection is used to detect failure.
鉄ルーターは、安全なリダイレクトを使用してルーターFIBを更新するため、より固有のプレフィックスを伝播します。接頭辞のリダイレクトはデータプレーンによって駆動され、コントロールプレーンに影響しません。リダイレクトされたプレフィックスはrib骨に注入されませんが、有効期限またはルートの故障後にパージされるFIBソフト状態として維持されます。近隣の到達不能検出は、障害を検出するために使用されます。
Secure prefix registrations and redirections are accommodated through the mechanisms of SEAL. Tunnel endpoints using SEAL synchronize sequence numbers, and can therefore discard any packets they receive that are outside of the current sequence number window. Hence, off-path attacks are defeated. These synchronized tunnel endpoints can therefore exchange prefixes with signed certificates that prove prefix ownership in such a way that DoS vectors that attack crypto calculation overhead are eliminated due to the prevention of off-path attacks.
セキュアなプレフィックス登録とリダイレクトは、シールのメカニズムを介して収容されます。シールを使用したトンネルエンドポイントは、シーケンス番号を同期するため、現在のシーケンス番号ウィンドウの外側にある受け取ったパケットを破棄できます。したがって、オフパス攻撃は敗北します。したがって、これらの同期されたトンネルのエンドポイントは、署名済みの証明書とプレフィックスを交換することができます。これは、オフパス攻撃の防止により暗号計算オーバーヘッドを攻撃するDOSベクターが排除されるように、プレフィックスの所有権を証明します。
CEs can move from old RANGER networks and re-inject their PI prefixes into new RANGER networks. This would be accommodated by IRON-RANGER as a site multihoming event while host mobility and true locator-ID separation is accommodated via HIP [RFC5201].
CESは、古いレンジャーネットワークから移動し、PIプレフィックスを新しいレンジャーネットワークに再注入できます。これは、ホストのモビリティと真のロケーター-ID分離が股関節[RFC5201]を介して収容され、サイトのマルチホームイベントとして鉄レンジャーによって収容されます。
As can be seen from the extensive list of proposals above, the group explored a number of possible solutions. Unfortunately, the group did not reach rough consensus on a single best approach. Accordingly, the recommendation has been left to the co-chairs. The remainder of this section describes the rationale and decision of the co-chairs.
上記の提案の広範なリストからわかるように、グループは多くの可能な解決策を調査しました。残念ながら、グループは単一の最良のアプローチについて大まかなコンセンサスに達しませんでした。したがって、推奨は共同議長に任されています。このセクションの残りの部分では、共同議長の理論的根拠と決定について説明します。
As a reminder, the goal of the research group was to develop a recommendation for an approach to a routing and addressing architecture for the Internet. The primary goal of the architecture is to provide improved scalability for the routing subsystem. Specifically, this implies that we should be able to continue to grow the routing subsystem to meet the needs of the Internet without requiring drastic and continuous increases in the amount of state or processing requirements for routers.
リマインダーとして、研究グループの目標は、インターネットのルーティングとアドレス指定へのアプローチの推奨事項を開発することでした。アーキテクチャの主な目標は、ルーティングサブシステムのスケーラビリティを改善することです。具体的には、これは、ルーターの状態量または処理要件の劇的で継続的な増加を必要とせずに、インターネットのニーズを満たすためにルーティングサブシステムを成長させ続けることができるはずです。
There is a general concern that the cost and structure of the routing and addressing architecture as we know it today may become prohibitively expensive with continued growth, with repercussions to the health of the Internet. As such, there is an urgent need to examine and evaluate potential scalability enhancements.
ルーティングとアドレス指定のアーキテクチャのコストと構造が、今日の成長が継続的に高価になり、インターネットの健康に影響を与える可能性があるという一般的な懸念があります。そのため、潜在的なスケーラビリティの向上を調べて評価する必要があります。
For the long term future of the Internet, it has become apparent that IPv6 is going to play a significant role. It has taken more than a decade, but IPv6 is starting to see some non-trivial amount of deployment. This is in part due to the depletion of IPv4 addresses. It therefore seems apparent that the new architecture must be applicable to IPv6. It may or may not be applicable to IPv4, but not addressing the IPv6 portion of the network would simply lead to recreating the routing scalability problem in the IPv6 domain, because the two share a common routing architecture.
インターネットの長期的な未来については、IPv6が重要な役割を果たすことが明らかになりました。10年以上かかりましたが、IPv6では、わずかな量の展開が展開され始めています。これは、IPv4アドレスの枯渇によるものです。したがって、新しいアーキテクチャがIPv6に適用されなければならないことは明らかです。IPv4に適用される場合とそうでない場合がありますが、ネットワークのIPv6部分に対処しないことは、共通のルーティングアーキテクチャを共有するため、IPv6ドメインのルーティングスケーラビリティ問題の再現につながるだけです。
Whatever change we make, we should expect that this is a very long-lived change. The routing architecture of the entire Internet is a loosely coordinated, complex, expensive subsystem, and permanent, pervasive changes to it will require difficult choices during deployment and integration. These cannot be undertaken lightly.
私たちがどんな変化をもたらしたとしても、これは非常に長寿命の変化であると期待すべきです。インターネット全体のルーティングアーキテクチャは、緩やかに調整された複雑で高価なサブシステムであり、それに対する永続的な変化が必要になるには、展開と統合中に難しい選択が必要です。これらを軽く行うことはできません。
By extension, if we are going to the trouble, pain, and expense of making major architectural changes, it follows that we want to make the best changes possible. We should regard any such changes as permanent and we should therefore aim for long term solutions that place the network in the best possible position for ongoing growth. These changes should be cleanly integrated, first-class citizens within the architecture. That is to say that any new elements that are integrated into the architecture should be fundamental primitives, on par with the other existing legacy primitives in the architecture, that interact naturally and logically when in combination with other elements of the architecture.
さらに、主要な建築の変更を加えるためのトラブル、痛み、費用に至る場合、可能な限り最良の変更を加えたいということです。したがって、そのような変更を永続的なものと見なす必要があるため、ネットワークを継続的な成長のために可能な限り最高の位置に置く長期的なソリューションを目指すべきです。これらの変更は、アーキテクチャ内の、きれいに統合された一流の市民である必要があります。つまり、アーキテクチャに統合された新しい要素は、アーキテクチャの他の既存のレガシープリミティブと同等の基本的なプリミティブである必要があります。
Over the history of the Internet, we have been very good about creating temporary, ad-hoc changes, both to the routing architecture and other aspects of the network layer. However, many of these band-aid solutions have come with a significant overhead in terms of long-term maintenance and architectural complexity. This is to be avoided and short-term improvements should eventually be replaced by long-term, permanent solutions.
インターネットの歴史を超えて、私たちは、ルーティングアーキテクチャとネットワークレイヤーの他の側面の両方に、一時的なアドホックな変更を作成することについて非常に優れています。ただし、これらのバンドエイドソリューションの多くは、長期的なメンテナンスと建築の複雑さの点で大きなオーバーヘッドを備えています。これは回避され、短期的な改善は最終的に長期的な永続的なソリューションに置き換える必要があります。
In the particular instance of the routing and addressing architecture today, we feel that the situation requires that we pursue both short-term improvements and long-term solutions. These are not incompatible because we truly intend for the short-term improvements to be completely localized and temporary. The short-term improvements are necessary to give us the time necessary to develop, test, and deploy the long-term solution. As the long-term solution is rolled out and gains traction, the short-term improvements should be of less benefit and can subsequently be withdrawn.
今日のルーティングとアドレス指定のアーキテクチャの特定の例では、状況には短期的な改善と長期的なソリューションの両方を追求する必要があると感じています。短期的な改善が完全にローカライズされて一時的であることを本当に意図しているため、これらは互換性がありません。短期的な改善は、長期ソリューションの開発、テスト、展開に必要な時間を提供するために必要です。長期的な解決策が展開され、牽引力を獲得するため、短期の改善は利益が少なくなり、その後撤回することができます。
The group explored a number of proposed solutions but did not reach consensus on a single best approach. Therefore, in fulfillment of the routing research group's charter, the co-chairs recommend that the IETF pursue work in the following areas:
グループは多くの提案されたソリューションを調査しましたが、単一の最良のアプローチについてコンセンサスに達しませんでした。したがって、ルーティングリサーチグループの憲章を履行するために、共同議長は、IETFが次の分野で作業を追求することを推奨しています。
Evolution [Evolution]
進化[進化]
Identifier-Locator Network Protocol (ILNP) [ILNP_Site]
識別子ロケーターネットワークプロトコル（ILNP）[ILNP_SITE]
Renumbering [RFC5887]
名前を変更[RFC5887]
We selected Evolution because it is a short-term improvement. It can be applied on a per-domain basis, under local administration and has immediate effect. While there is some complexity involved, we feel that this option is constructive for service providers who find the additional complexity to be less painful than upgrading hardware. This improvement can be deployed by domains that feel it necessary, for as long as they feel it is necessary. If this deployment lasts longer than expected, then the implications of that decision are wholly local to the domain.
短期的な改善であるため、進化を選択しました。地元の管理下では、ドメインごとに適用でき、即座に効果があります。複雑さはありますが、このオプションは、ハードウェアをアップグレードするよりも苦痛が少ないことがあるサービスプロバイダーにとって建設的であると感じています。この改善は、必要だと思う限り、必要だと感じるドメインによって展開できます。この展開が予想よりも長く続く場合、その決定の意味はドメインにとって完全にローカルです。
We recommended ILNP because we find it to be a clean solution for the architecture. It separates location from identity in a clear, straightforward way that is consistent with the remainder of the Internet architecture and makes both first-class citizens. Unlike the many map-and-encap proposals, there are no complications due to tunneling, indirection, or semantics that shift over the lifetime of a packet's delivery.
ILNPは、アーキテクチャのためのきれいなソリューションであると思うので、ILNPを推奨しました。これは、インターネットアーキテクチャの残りの部分と一致し、両方のファーストクラスの市民を作る明確で簡単な方法で、場所をアイデンティティから分離します。多くの地図と概要の提案とは異なり、パケットの配信の生涯にわたってシフトするトンネリング、間接、またはセマンティクスによる合併症はありません。
We recommend further work on automating renumbering because even with ILNP, the ability of a domain to change its locators at minimal cost is fundamentally necessary. No routing architecture will be able to scale without some form of abstraction, and domains that change their point of attachment must fundamentally be prepared to change their locators in line with this abstraction. We recognize that [RFC5887] is not a solution so much as a problem statement, and we are simply recommending that the IETF create effective and convenient mechanisms for site renumbering.
ILNPを使用しても、ドメインが最小コストでロケーターを変更する能力が基本的に必要であるため、Nommungingの自動化に関するさらなる作業をお勧めします。ルーティングアーキテクチャは何らかの形の抽象化なしにスケーリングすることはできません。また、添付ファイルを変更するドメインは、この抽象化に沿ってロケーターを根本的に変更する準備をする必要があります。[RFC5887]は問題の声明ほど解決策ではないことを認識しており、IETFがサイトの変更に効果的で便利なメカニズムを作成することを推奨するだけです。
This document presents a small portion of the overall work product of the Routing Research Group, who have developed all of these architectural approaches and many specific proposals within this solution space.
このドキュメントでは、これらのアーキテクチャのアプローチのすべてとこのソリューションスペース内で多くの特定の提案を開発したルーティングリサーチグループの全体的な作業製品のごく一部を提示します。
Space precludes a full treatment of security considerations for all proposals summarized herein. [RFC3552] However, it was a requirement of the research group to provide security that is at least as strong as the existing Internet routing and addressing architecture. Each technical proposal has slightly different security considerations, the details of which are in many of the references cited.
スペースは、ここに要約されているすべての提案のセキュリティに関する考慮事項の完全な扱いを妨げます。[RFC3552]しかし、少なくとも既存のインターネットルーティングとアドレス指定アーキテクチャと同じくらい強力なセキュリティを提供することは、研究グループの要件でした。各技術提案には、セキュリティ上の考慮事項がわずかに異なり、その詳細は引用されている多くの参考文献にあります。
[CRM] Flinck, H., "Compact routing in locator identifier mapping system", <http://www.tschofenig.priv.at/rrg/ CR_mapping_system_0.1.pdf>.
[CRM] Flinck、H。、「ロケーター識別子マッピングシステムのコンパクトルーティング」、<http://www.tschofenig.priv.at/rrg/ cr_mapping_system_0.1.pdf>。
[DNSnBIND] Liu, C. and P. Albitz, "DNS & BIND", 2006, 5th Edition, O'Reilly & Associates, Sebastopol, CA, USA. ISBN 0-596-10057-4.
[Dnsnbind] Liu、C。and P. Albitz、「Dns＆Bind」、2006年、第5版、O'Reilly＆Associates、セバストポル、CA、米国。ISBN 0-596-10057-4。
[EEMDP_Considerations] Sriram, K., Kim, Y., and D. Montgomery, "Enhanced Efficiency of Mapping Distribution Protocols in Scalable Routing and Addressing Architectures", Proceedings of the ICCCN, Zurich, Switzerland, August 2010, <http://www.antd.nist.gov/~ksriram/EEMDP_ICCCN2010.pdf>.
[eemdp_considerations] Sriram、K.、Kim、Y.、およびD. Montgomery、「スケーラブルなルーティングおよびアドレス指定における分布プロトコルのマッピング効率の向上」、ICCCN、チューリッヒ、スイス、スイス、2010年8月、<http：//www.antd.nist.gov/~ksriram/eemdp_icccn2010.pdf>。
[EEMDP_Presentation] Sriram, K., Gleichmann, P., Kim, Y., and D. Montgomery, "Enhanced Efficiency of Mapping Distribution Protocols in Scalable Routing and Addressing Architectures", Presented at the LISP WG meeting, IETF 78, July 2010. Originally presented at the RRG meeting at IETF 72, <http://www.ietf.org/proceedings/78/slides/lisp-6.pdf>.
[eemdp_presentation] Sriram、K.、Gleichmann、P.、Kim、Y.、およびD. Montgomery、「スケーラブルなルーティングおよびアドレス指定の構造における分布プロトコルのマッピング効率の向上」は、LISP WG Meeting、IETF 78、2010年7月に発表された。もともとIETF 72のRRG会議で発表された<http://www.ietf.org/proceedings/78/slides/lisp-6.pdf>。
[Evolution] Zhang, B. and L. Zhang, "Evolution Towards Global Routing Scalability", Work in Progress, October 2009.
[Evolution] Zhang、B。およびL. Zhang、「グローバルルーティングのスケーラビリティに向けた進化」、2009年10月の作業。
[Evolution_Grow_Presentation] Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and L. Zhang, "Virtual Aggregation (VA)", November 2009, <http://www.ietf.org/proceedings/76/slides/grow-5.pdf>.
[Evolution_grow_presentation] Francis、P.、Xu、X.、Ballani、H.、Jen、D.、Raszuk、R。、およびL. Zhang、「仮想集約（VA）」、2009年11月、<http：// www.ietf.org/proceedings/76/slides/grow-5.pdf>。
[FIBAggregatability] Zhang, B., Wang, L., Zhao, X., Liu, Y., and L. Zhang, "An Evaluation Study of Router FIB Aggregatability", November 2009, <http://www.ietf.org/proceedings/76/slides/grow-2.pdf>.
[Fibaggregatability] Zhang、B.、Wang、L.、Zhao、X.、Liu、Y.、およびL. Zhang、「ルーターFIBの集合性の評価研究」、2009年11月、<http：//www.ietf。org/proceedings/76/slides/grow-2.pdf>。
[GLI] Menth, M., Hartmann, M., and D. Klein, "Global Locator, Local Locator, and Identifier Split (GLI-Split)", April 2010, <http://www3.informatik.uni-wuerzburg.de/TR/tr470.pdf>.
[Gli] Menth、M.、Hartmann、M。、およびD. Klein、「グローバルロケーター、ローカルロケーター、識別子分割（Gli-Split）」、2010年4月、<http：//www3.informatik.uni-wuerzburg.de/tr/tr470.pdf>。
[ILNP_DNS] Atkinson, R. and S. Rose, "DNS Resource Records for ILNP", Work in Progress, February 2011.
[ILNP_DNS] Atkinson、R。およびS. Rose、「ILNPのDNSリソースレコード」、Work in Progress、2011年2月。
[ILNP_ICMP] Atkinson, R., "ICMP Locator Update message", Work in Progress, February 2011.
[ILNP_ICMP] Atkinson、R。、「ICMP Locator Update Message」、Work in Progress、2011年2月。
[ILNP_Intro] Atkinson, R., "ILNP Concept of Operations", Work in Progress, February 2011.
[ILNP_INTRO] Atkinson、R。、「ILNP Operations of Operations」、Work in Progress、2011年2月。
[ILNP_Nonce] Atkinson, R., "ILNP Nonce Destination Option", Work in Progress, February 2011.
[ILNP_NONCE] Atkinson、R。、「ILNP Nonce Destination Option」、2011年2月の作業進行中。
[ILNP_Site] Atkinson, R., Bhatti, S., Hailes, S., Rehunathan, D., and M. Lad, "ILNP - Identifier-Locator Network Protocol", updated 06 January 2011, <http://ilnp.cs.st-andrews.ac.uk>.
[ILNP_SITE] Atkinson、R.、Bhatti、S.、Hailes、S.、Rehunathan、D。、およびM. Lad、「ILNP-識別子ロケーターネットワークプロトコル」、2011年1月6日更新<http：// ilnp。Cs.st-andrews.ac.uk>。
[IRON] Templin, F., "The Internet Routing Overlay Network (IRON)", Work in Progress, January 2011.
[鉄] Templin、F。、「インターネットルーティングオーバーレイネットワーク（鉄）」、2011年1月、進行中の作業。
[Ivip_Constraints] Whittle, R., "List of constraints on a successful scalable routing solution which result from the need for widespread voluntary adoption", April 2009, <http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/>.
[IVIP_Constraints] Whittle、R。、「広範囲にわたる自発的な採用の必要性に起因する成功したスケーラブルなルーティングソリューションの制約のリスト」、2009年4月、<http://www.firstpr.com.au/ip/ivip/rrg-2009/制約/>。
[Ivip_DRTM] Whittle, R., "DRTM - Distributed Real Time Mapping for Ivip and LISP", Work in Progress, March 2010.
[IVIP_DRTM] Whittle、R。、「DRTM- IVIPとLISP用のリアルタイムマッピングの分散」、2010年3月、進行中の作業。
[Ivip_EAF] Whittle, R., "Ivip4 ETR Address Forwarding", Work in Progress, January 2010.
[IVIP_EAF] Whittle、R。、「IVIP4 ETRアドレス転送」、2010年1月の作業進行中。
[Ivip_Glossary] Whittle, R., "Glossary of some Ivip and scalable routing terms", Work in Progress, March 2010.
[IVIP_Glossary] Whittle、R。、「IVIPおよびスケーラブルなルーティング用語の用語集」、2010年3月の作業。
[Ivip_Mobility] Whittle, R., "TTR Mobility Extensions for Core-Edge Separation Solutions to the Internet's Routing Scaling Problem", August 2008, <http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf>.
[IVIP_Mobility] Whittle、R。、「インターネットのルーティングスケーリング問題に対するコアエッジ分離ソリューションのためのTTRモビリティ拡張」、2008年8月<http://www.firstpr.com.au/ip/ivip/ttr-mobility。pdf>。
[Ivip_PLF] Whittle, R., "Prefix Label Forwarding (PLF) - Modified Header Forwarding for IPv6", <http://www.firstpr.com.au/ip/ivip/PLF-for-IPv6/>.
[IVIP_PLF] Whittle、R。、 "Prefixラベル転送（PLF） - IPv6の変更されたヘッダー転送"、<http://www.firstpr.com.au/ip/ivip/plf-for-ipv6/>。
[Ivip_PMTUD] Whittle, R., "IPTM - Ivip's approach to solving the problems with encapsulation overhead, MTU, fragmentation and Path MTU Discovery", January 2010, <http://www.firstpr.com.au/ip/ivip/pmtud-frag/>.
[IVIP_PMTUD] Whittle、R。、「IPTM -IVIPのカプセル化オーバーヘッド、MTU、断片化、PATH MTU Discoveryの問題を解決するためのアプローチ」、2010年1月<http://www.firstpr.com.au/ip/ivip/pmtud-frag/>。
[JSAC_Arch] Atkinson, R., Bhatti, S., and S. Hailes, "Evolving the Internet Architecture Through Naming", IEEE Journal on Selected Areas in Communication (JSAC) 28(8), October 2010.
[JSAC_ARCH] Atkinson、R.、Bhatti、S。、およびS. Hailes、「命名を通じてインターネットアーキテクチャの進化」、IEEE Journal on Communication（JSAC）28（8）、2010年10月。
[LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", Work in Progress, February 2010.
[Lig] Farinacci、D。およびD. Meyer、「Lisp Internet Groper（Lig）」、Work in Progress、2010年2月。
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, October 2010.
[lisp] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「Locator/ID分離プロトコル（LISP）」、2010年10月の作業。
[LISP+ALT] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP Alternative Topology (LISP+ALT)", Work in Progress, October 2010.
[Lisp Alt] Fuller、V.、Farinacci、D.、Meyer、D。、およびD. Lewis、「Lisp Alternative Topology（Lisp Alt）」、2010年10月の作業。
[LISP-Interworking] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking LISP with IPv4 and IPv6", Work in Progress, August 2010.
[Lisp-Interworking] Lewis、D.、Meyer、D.、Farinacci、D.、およびV. Fuller、「IPv4とIPv6とのインターワーキングLISP」、2010年8月に進行中。
[LISP-MN] Meyer, D., Lewis, D., and D. Farinacci, "LISP Mobile Node", Work in Progress, October 2010.
[lisp-mn] Meyer、D.、Lewis、D.、およびD. Farinacci、「Lisp Mobile Node」、2010年10月の作業。
[LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server", Work in Progress, October 2010.
[Lisp-MS] Fuller、V.およびD. Farinacci、「Lisp Map Server」、2010年10月の作業。
[LISP-TREE] Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D., and O. Bonaventure, "LISP-TREE: A DNS Hierarchy to Support the LISP Mapping System", IEEE Journal on Selected Areas in Communications, Volume 28, Issue 8, October 2010, <http ://ieeexplore.ieee.org/stamp/ stamp.jsp?tp=&arnumber=5586446>.
[Lisp-Tree] Jakab、L.、Cabellos-Aparicio、A.、Coras、F.、Sauce、D。、およびO. Bonaventure、「Lisp-Tree：LISPマッピングシステムをサポートするDNS階層」、IEEE JournalCommunicationsの選択された領域、第28巻、2010年10月8日、<http：//ieeexplore.ieee.org/stamp/ stamp.jsp？tp =＆arnumber = 5586446>。
[LMS] Letong, S., Xia, Y., ZhiLiang, W., and W. Jianping, "A Layered Mapping System For Scalable Routing", <http:// docs.google.com/ fileview?id=0BwsJc7A4NTgeOTYzMjFlOGEtYzA4OC00NTM0LTg5ZjktN mFkYzBhNWJhMWEy&hl=en>.
[LMS] Letong、S.、Xia、Y.、Zhiliang、W。、およびW. Jianping、「スケーラブルなルーティング用の層状マッピングシステム」、<http：// docs.google.com/ fileview？id = 0bwsjc7a4ntgeotyzmjflogetyza4oc00ntm0n0ltg5zjkhnphhmwy hfkhmwytn= en>。
[LMS_Summary] Sun, C., "A Layered Mapping System (Summary)", <http:// docs.google.com/ Doc?docid=0AQsJc7A4NTgeZGM3Y3o1NzVfNmd3eGRzNGhi&hl=en>.
[lms_summary] Sun、C。、「層状マッピングシステム（要約）」、<http：// docs.google.com/ doc？docid = 0aqsjc7a4ntgezgm3y3o1nzvfnmd3egrznghi＆hl = en>。
[LOC_ID_Implications] Meyer, D. and D. Lewis, "Architectural Implications of Locator/ID Separation", Work in Progress, January 2009.
[loc_id_implications] Meyer、D。およびD. Lewis、「ロケーター/ID分離の建築的意味」、2009年1月の作業。
[MILCOM1] Atkinson, R. and S. Bhatti, "Site-Controlled Secure Multi-homing and Traffic Engineering for IP", IEEE Military Communications Conference (MILCOM) 28, Boston, MA, USA, October 2009.
[Milcom1] Atkinson、R。およびS. Bhatti、「IPのサイト制御された安全なマルチホミングおよび交通工学」、IEEE軍事通信会議（MILCOM）28、ボストン、マサチューセッツ州、2009年10月。
[MILCOM2] Atkinson, R., Bhatti, S., and S. Hailes, "Harmonised Resilience, Multi-homing and Mobility Capability for IP", IEEE Military Communications Conference (MILCOM) 27, San Diego, CA, USA, November 2008.
[Milcom2] Atkinson、R.、Bhatti、S。、およびS. Hailes、「IPの調和のとれた回復力、マルチホーミング、モビリティ能力」、IEEE軍事通信会議（MILCOM）27、サンディエゴ、カリフォルニア州、2008年11月。
[MPTCP_Arch] Ford, A., Raiciu, C., Barre, S., Iyengar, J., and B. Ford, "Architectural Guidelines for Multipath TCP Development", Work in Progress, February 2010.
[MPTCP_ARCH] Ford、A.、Raiciu、C.、Barre、S.、Iyengar、J。、およびB. Ford、「MultiPath TCP開発のための建築ガイドライン」、2010年2月の作業。
[MobiArch1] Atkinson, R., Bhatti, S., and S. Hailes, "Mobility as an Integrated Service through the Use of Naming", ACM International Workshop on Mobility in the Evolving Internet (MobiArch) 2, Kyoto, Japan, August 2007.
[Mobiarch1] Atkinson、R.、Bhatti、S。、およびS. Hailes、「命名の使用による統合サービスとしてのモビリティ」、ACM International Workshop Evolving Internet（Mobiarch）2、京都、日本、8月2007年。
[MobiArch2] Atkinson, R., Bhatti, S., and S. Hailes, "Mobility Through Naming: Impact on DNS", ACM International Workshop on Mobility in the Evolving Internet (MobiArch) 3, Seattle, USA, August 2008.
[Mobiarch2] Atkinson、R.、Bhatti、S。、およびS. Hailes、「命名によるモビリティ：DNSへの影響」、ACM International Workshop Evolving Internet（Mobiarch）3、シアトル、米国、2008年8月。
[Name_Based_Sockets] Vogt, C., "Simplifying Internet Applications Development With A Name-Based Sockets Interface", December 2009, <http ://christianvogt.mailup.net/pub/ vogt-2009-name-based-sockets.pdf>.
[name_based_sockets] vogt、C。、「名前ベースのソケットインターフェイスでインターネットアプリケーション開発を簡素化」、2009年12月、<http：//christianvogt.mailup.net/pub/ vogt-2009-name based-sockets.pdf>。
[RANGER_Scen] Russert, S., Fleischman, E., and F. Templin, "RANGER Scenarios", Work in Progress, July 2010.
[Ranger_scen] Russert、S.、Fleischman、E。、およびF. Templin、「Ranger Sinarios」、2010年7月の作業。
[RANGI] Xu, X., "Routing Architecture for the Next Generation Internet (RANGI)", Work in Progress, August 2010.
[Rangi] Xu、X。、「次世代インターネット（Rangi）のルーティングアーキテクチャ」、2010年8月の作業。
[RANGI-PROXY] Xu, X., "Transition Mechanisms for Routing Architecture for the Next Generation Internet (RANGI)", Work in Progress, July 2009.
[Rangi-Proxy] Xu、X。、「次世代インターネット（Rangi）のルーティングアーキテクチャの遷移メカニズム」、2009年7月、進行中の作業。
[RANGI-SLIDES] Xu, X., "Routing Architecture for the Next-Generation Internet (RANGI)", <http://www.ietf.org/proceedings/76/ slides/RRG-1/RRG-1.htm>.
[Rangi-Slides] Xu、X。、「次世代インターネット（Rangi）のルーティングアーキテクチャ」、<http://www.ietf.org/proceedings/76/ slides/rrg-1/rrg-1.htm>。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B。、「セキュアドメイン名システム（DNS）動的更新」、RFC 3007、2000年11月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティの導入と要件」、RFC 4033、2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ拡張機能のリソースレコード」、RFC 4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティ拡張のプロトコル修正」、RFC 4035、2005年3月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423] Moskowitz、R。およびP. Nikander、「ホストアイデンティティプロトコル（HIP）アーキテクチャ」、RFC 4423、2006年5月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）、RFC 4443、2006年3月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[RFC5201] Moskowitz、R.、Nikander、P.、Jokela、P。、およびT. Henderson、「Host Identity Protocol」、RFC 5201、2008年4月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214] Templin、F.、Gleeson、T。、およびD. Thaler、「敷地内自動トンネルアドレス指定プロトコル（ISATAP）」、RFC 5214、2008年3月。
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming", RFC 5534, June 2009.
[RFC5534] Arkko、J。およびI. Van Beijnum、「IPv6 Multihomingの障害検出およびロケーターペア探査プロトコル」、RFC 5534、2009年6月。
[RFC5720] Templin, F., "Routing and Addressing in Networks with Global Enterprise Recursion (RANGER)", RFC 5720, February 2010.
[RFC5720] Templin、F。、「グローバルエンタープライズリクルシオン（レンジャー）を備えたネットワークでのルーティングとアドレス指定」、RFC 5720、2010年2月。
[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月。
[RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on IPv6 Network Address Translation", RFC 5902, July 2010.
[RFC5902] Thaler、D.、Zhang、L。、およびG. Lebovitz、「IPv6ネットワークアドレス変換に関するIABの考え」、RFC 5902、2010年7月。
[RRG_Design_Goals] Li, T., "Design Goals for Scalable Internet Routing", Work in Progress, January 2011.
[rrg_design_goals] li、T。、「スケーラブルなインターネットルーティングの設計目標」、2011年1月の進行中の作業。
[Referral_Obj] Carpenter, B., Boucadair, M., Halpern, J., Jiang, S., and K. Moore, "A Generic Referral Object for Internet Entities", Work in Progress, October 2009.
[Referral_obj] Carpenter、B.、Boucadair、M.、Halpern、J.、Jiang、S。、およびK. Moore、「インターネットエンティティ向けの一般的な紹介オブジェクト」、2009年10月の進行中。
[SEAL] Templin, F., "The Subnetwork Encapsulation and Adaptation Layer (SEAL)", Work in Progress, January 2011.
[シール]テンプリン、F。、「サブネットワークのカプセル化と適応層（シール）」、2011年1月の作業。
[Scalability_PS] Narten, T., "On the Scalability of Internet Routing", Work in Progress, February 2010.
[Scalability_ps] Narten、T。、「インターネットルーティングのスケーラビリティについて」、2010年2月に進行中の作業。
[TIDR] Adan, J., "Tunneled Inter-domain Routing (TIDR)", Work in Progress, December 2006.
[Tidr] Adan、J。、「トンネリングインタードメインルーティング（TIDR）」、2006年12月、進行中の作業。
[TIDR_AS_forwarding] Adan, J., "yetAnotherProposal: AS-number forwarding", March 2008, <http://www.ops.ietf.org/lists/rrg/2008/msg00716.html>.
[Tidr_as_forwarding] Adan、J。、「Yetanotherproposal：As-Number Forwarding」、2008年3月、<http://www.ops.org/lists/rrg/2008/msg00716.html>。
[TIDR_and_LISP] Adan, J., "LISP etc architecture", December 2007, <http://www.ops.ietf.org/lists/rrg/2007/msg00902.html>.
[Tidr_and_lisp] Adan、J。、「Lisp etc Architecture」、2007年12月、<http://www.ops.ietf.org/lists/rrg/2007/msg00902.html>。
[TIDR_identifiers] Adan, J., "TIDR using the IDENTIFIERS attribute", April 2007, <http://www.ietf.org/mail-archive/web/ram/ current/msg01308.html>.
[Tidr_identifiers] Adan、J。、「識別子属性を使用したTidr」、2007年4月、<http://www.ietf.org/mail-archive/web/ram/ current/msg01308.html>。
[VET] Templin, F., "Virtual Enterprise Traversal (VET)", Work in Progress, January 2011.
[VET] Templin、F。、「仮想エンタープライズトラバーサル（VET）」、2011年1月の作業。
[Valiant] Zhang-Shen, R. and N. McKeown, "Designing a Predictable Internet Backbone Network", November 2004, <http:// conferences.sigcomm.org/hotnets/2004/ HotNets-III%20Proceedings/zhang-shen.pdf>.
[Valiant] Zhang-Shen、R。およびN. McKeown、「予測可能なインターネットバックボーンネットワークの設計」、2004年11月、<http：// conferences.sigcomm.org/hotnets/2004/ hotnets-iii％20proceed/zhang-shen.pdf>。
[hIPv4] Frejborg, P., "Hierarchical IPv4 Framework", Work in Progress, October 2010.
[HIPV4] Frejborg、P。、「階層IPv4フレームワーク」、2010年10月の作業。
Author's Address
著者の連絡先
Tony Li (editor) Cisco Systems 170 West Tasman Dr. San Jose, CA 95134 USA
Tony Li（編集者）Cisco Systems 170 West Tasman Dr. San Jose、CA 95134 USA
Phone: +1 408 853 9317
EMail: tony.li@tony.li