[要約] 要約：RFC 5439は、MPLS-TEコアネットワークのスケーリングの問題についての分析を提供しています。 目的：このRFCの目的は、MPLS-TEコアネットワークのスケーリングに関連する問題を特定し、解決策を提案することです。
Network Working Group S. Yasukawa
Request for Comments: 5439 NTT
Category: Informational A. Farrel
Old Dog Consulting
O. Komolafe
Cisco Systems
February 2009
An Analysis of Scaling Issues in MPLS-TE Core Networks
MPLS-TEコアネットワークのスケーリング問題の分析
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 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の法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
Traffic engineered Multiprotocol Label Switching (MPLS-TE) is deployed in providers' core networks. As providers plan to grow these networks, they need to understand whether existing protocols and implementations can support the network sizes that they are planning.
トラフィックエンジニアリングマルチプロトコルラベルスイッチング（MPLS-TE）は、プロバイダーのコアネットワークに展開されています。プロバイダーがこれらのネットワークを成長させることを計画しているため、既存のプロトコルと実装が計画しているネットワークサイズをサポートできるかどうかを理解する必要があります。
This document presents an analysis of some of the scaling concerns for the number of Label Switching Paths (LSPs) in MPLS-TE core networks, and examines the value of two techniques (LSP hierarchies and multipoint-to-point LSPs) for improving scaling. The intention is to motivate the development of appropriate deployment techniques and protocol extensions to enable the application of MPLS-TE in large networks.
このドキュメントでは、MPLS-TEコアネットワークのラベルスイッチングパス（LSP）の数に関するスケーリングの懸念事項の分析を提示し、スケーリングを改善するための2つの手法（LSP階層とマルプポイントツーポイントLSP）の値を調べます。意図は、大規模なネットワークでのMPLS-TEの適用を可能にするために、適切な展開技術とプロトコル拡張の開発を動機付けることです。
This document only considers the question of achieving scalability for the support of point-to-point MPLS-TE LSPs. Point-to-multipoint MPLS-TE LSPs are for future study.
このドキュメントは、ポイントツーポイントMPLS-TE LSPのサポートのためにスケーラビリティを達成するという問題のみを考慮します。ポイントツーマルチポイントMPLS-TE LSPは、将来の研究のためです。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Overview ...................................................3
1.2. Glossary of Notation .......................................5
2. Issues of Concern for Scaling ...................................5
2.1. LSP State ..................................................5
2.2. Processing Overhead ........................................6
2.3. RSVP-TE Implications .......................................6
2.4. Management .................................................7
3. Network Topologies ..............................................8
3.1. The Snowflake Network Topology .............................9
3.2. The Ladder Network Topology ...............................11
3.3. Commercial Drivers for Selected Configurations ............14
3.4. Other Network Topologies ..................................15
4. Required Network Sizes .........................................16
4.1. Practical Numbers .........................................16
5. Scaling in Flat Networks .......................................16
5.1. Snowflake Networks ........................................17
5.2. Ladder Networks ...........................................18
6. Scaling Snowflake Networks with Forwarding Adjacencies .........22
6.1. Two-Layer Hierarchy .......................................22
6.1.1. Tuning the Network Topology to Suit the
Two-Layer Hierarchy ................................23
6.2. Alternative Two-Layer Hierarchy ...........................24
6.3. Three-Layer Hierarchy .....................................25
6.4. Issues with Hierarchical LSPs .............................26
7. Scaling Ladder Networks with Forwarding Adjacencies ............27
7.1. Two-Layer Hierarchy .......................................27
7.2. Three-Layer Hierarchy .....................................28
7.3. Issues with Hierarchical LSPs .............................29
8. Scaling Improvements through Multipoint-to-Point LSPs ..........30
8.1. Overview of MP2P LSPs .....................................30
8.2. LSP State: A Better Measure of Scalability ................31
8.3. Scaling Improvements for Snowflake Networks ...............32
8.3.1. Comparison with Other Scenarios ....................33
8.4. Scaling Improvements for Ladder Networks ..................34
8.4.1. Comparison with Other Scenarios ....................36
8.4.2. LSP State Compared with LSP Numbers ................37
8.5. Issues with MP2P LSPs .....................................37
9. Combined Models ................................................39
10. An Alternate Solution .........................................39
10.1. Pros and Cons of the Alternate Solution ..................40
11. Management Considerations .....................................42
12. Security Considerations .......................................42
13. Recommendations ...............................................42
14. Acknowledgements ..............................................43
15. Normative References ..........................................43
16. Informative References ........................................43
Network operators and service providers are examining scaling issues as they look to deploy ever-larger traffic engineered Multiprotocol Label Switching (MPLS-TE) networks. Concerns have been raised about the number of Label Switched Paths (LSPs) that need to be supported at the edge and at the core of the network. The impact on control plane and management plane resources threatens to outweigh the benefits and popularity of MPLS-TE, while the physical limitations of the routers may constrain the deployment options.
ネットワークオペレーターとサービスプロバイダーは、拡大するトラフィックエンジニアリングマルチプロトコルラベルスイッチング（MPLS-TE）ネットワークを展開しようとしているため、スケーリングの問題を調査しています。ネットワークのコアでサポートする必要があるラベルスイッチされたパス（LSP）の数に関する懸念が提起されています。コントロールプレーンと管理プレーンのリソースへの影響は、MPLS-TEの利点と人気を上回ると脅しますが、ルーターの物理的な制限により展開オプションが制約される場合があります。
Historically, it has been assumed that all MPLS-TE scaling issues can be addressed using hierarchical LSP [RFC4206]. However, analysis shows that the improvement gained by LSP hierarchies is not as significant in all topologies and at all points in the network as might have been presumed. Further, additional management issues are introduced to determine the end-points of the hierarchical LSPs and to operate them. Although this does not invalidate the benefits of LSP hierarchies, it does indicate that additional techniques may be desirable in order to fully scale MPLS-TE networks.
歴史的に、すべてのMPLS-TEスケーリングの問題は、階層LSP [RFC4206]を使用して対処できると想定されてきました。ただし、分析では、LSP階層によって得られる改善は、すべてのトポロジおよびネットワーク内のすべてのポイントで推定されているほど重要ではないことが示されています。さらに、階層LSPのエンドポイントを決定し、それらを操作するために、追加の管理上の問題が導入されます。これはLSP階層の利点を無効にしませんが、MPLS-TEネットワークを完全にスケーリングするためには、追加の手法が望ましい場合があることを示しています。
This document examines the scaling properties of two generic MPLS-TE network topologies and investigates the benefits of two scaling techniques.
このドキュメントでは、2つの一般的なMPLS-TEネットワークトポロジのスケーリングプロパティを調べ、2つのスケーリング手法の利点を調査します。
Physical topology scaling concerns are addressed by building networks that are not fully meshed. Network topologies tend to be meshed in the core but tree-shaped at the edges, giving rise to a snowflake design. Alternatively, the core may be more of a ladder shape with tree-shaped edges.
物理的なトポロジのスケーリングの懸念は、完全にはメッシュ化されていないネットワークを構築することによって対処されます。ネットワークトポロジーはコアにメッシュ化される傾向がありますが、エッジでは木の形があり、スノーフレークデザインを生み出します。あるいは、コアは、木型のエッジを備えたはしごの形状である可能性があります。
MPLS-TE, however, establishes a logical full mesh between all edge points in the network, and this is where the scaling problems arise since the structure of the network tends to focus a large number of LSPs within the core of the network.
ただし、MPLS-TEは、ネットワーク内のすべてのエッジポイント間に論理的なフルメッシュを確立します。これは、ネットワークの構造がネットワークのコア内に多数のLSPに焦点を合わせる傾向があるため、スケーリングの問題が発生する場所です。
This document presents two generic network topologies (the snowflake and the ladder) and attempts to parameterize the networks by making some generalities. It introduces terminology for the different scaling parameters and examines how many LSPs might be required to be carried within the core of a network.
このドキュメントは、2つの一般的なネットワークトポロジ（スノーフレークとラダー）を提示し、いくつかの一般性を作成してネットワークをパラメーター化しようとします。さまざまなスケーリングパラメーターの用語を導入し、ネットワークのコア内で実行する必要があるLSPの数を調べます。
Two techniques (hierarchical LSPs and multipoint-to-point LSPs) are introduced and an examination is made of the scaling benefits that they offer as well as of some of the concerns with using these techniques.
2つの手法（階層LSPとマルチポイントツーポイントLSP）が導入されており、これらの手法を使用することに関する懸念の一部と同様に、それらが提供するスケーリングの利点についての試験が行われます。
Of necessity, this document makes many generalizations. Not least among these is a set of assumptions about the symmetry and connectivity of the physical network. It is hoped that these generalizations will not impinge on the usefulness of the overview of the scaling properties that this document attempts to give. Indeed, the symmetry of the example topologies tends to highlight the scaling issues of the different solution models, and this may be useful in exposing the worst case scenarios.
必然的に、このドキュメントは多くの一般化を行います。特に、これらの中には、物理ネットワークの対称性と接続性に関する一連の仮定があります。これらの一般化が、このドキュメントが提供しようとするスケーリングプロパティの概要の有用性を妨げないことが期待されています。実際、トポロジの例の対称性は、異なるソリューションモデルのスケーリングの問題を強調する傾向があり、これは最悪のシナリオを公開するのに役立つ可能性があります。
Although protection mechanisms like Fast Reroute (FRR) [RFC4090] are briefly discussed, the main body of this document considers stable network cases. It should be noted that make-before-break re-optimisation after link failure may result in a significant number of 'duplicate' LSPs. This issue is not addressed in this document.
Fast Reroute（FRR）[RFC4090]などの保護メカニズムについて簡単に説明しますが、このドキュメントの本体では安定したネットワークケースを考慮しています。リンクの障害後の再最適化の前に、かなりの数の「重複」LSPが生じる可能性があることに注意する必要があります。この問題は、このドキュメントでは対処されていません。
It should also be understood that certain deployment models where separate traffic engineered LSPs are used to provide different services (such as layer 3 Virtual Private Networks (VPNs) [RFC4110] or pseudowires [RFC3985]) or different classes of service [RFC3270] may result in 'duplicate' or 'parallel' LSPs running between any pair of provider edge nodes (PEs). This scaling factor is also not considered in this document, but may be easily applied as a linear factor by the reader.
また、別々のトラフィックエンジニアリングLSPが使用されている特定の展開モデル（レイヤー3仮想プライベートネットワーク（VPNS）[RFC4110]や擬似ワイヤ[RFC3985]など）またはさまざまなクラスのサービス[RFC3270]が結果として生じる可能性があることを理解する必要があります[RFC3270]プロバイダーエッジノード（PES）のペア間で実行される「複製」または「パラレル」LSP。このスケーリング係数もこのドキュメントでは考慮されていませんが、読者によって線形係数として簡単に適用される場合があります。
The operation of security mechanisms in MPLS-TE networks [MPLS-SEC] may have an impact on the ability of the network to scale. For example, they may increase both the size and number of control plane messages. Additionally, they may increase the processing overhead as control plane messages are subject to processing algorithms (such as encryption), and security keys need to be managed. Deployers will need to consider the trade-offs between scaling objectives and security objectives in their networks, and should resist the temptation to respond to a degradation of scaling performance by turning off security techniques that have previously been deemed as necessary. Further analysis of the effects of security measures on scalability are not considered further in this document.
MPLS-TEネットワーク[MPLS-SEC]におけるセキュリティメカニズムの動作は、ネットワークがスケーリングする能力に影響を与える可能性があります。たとえば、コントロールプレーンメッセージのサイズと数の両方を増やす場合があります。さらに、コントロールプレーンのメッセージが処理アルゴリズム（暗号化など）の対象となり、セキュリティキーを管理する必要があるため、処理オーバーヘッドが増加する場合があります。展開者は、ネットワークのスケーリング目標とセキュリティ目標の間のトレードオフを考慮する必要があり、以前に必要であると見なされていたセキュリティ技術をオフにすることにより、スケーリングパフォーマンスの劣化に対応する誘惑に抵抗する必要があります。このドキュメントでは、スケーラビリティに対するセキュリティ対策の影響のさらなる分析はさらに考慮されていません。
This document is designed to help service providers discover whether existing protocols and implementations can support the network sizes that they are planning. To do this, it presents an analysis of some of the scaling concerns for MPLS-TE core networks and examines the value of two techniques for improving scaling. This should motivate the development of appropriate deployment techniques and protocol extensions to enable the application of MPLS-TE in large networks.
このドキュメントは、サービスプロバイダーが既存のプロトコルと実装が計画しているネットワークサイズをサポートできるかどうかを発見できるように設計されています。これを行うために、MPLS-TEコアネットワークのスケーリングの懸念のいくつかの分析を提示し、スケーリングを改善するための2つの手法の価値を調べます。これにより、大規模なネットワークでのMPLS-TEの適用を可能にするために、適切な展開技術とプロトコル拡張の開発を動機付けるはずです。
This document only considers the question of achieving scalability for the support of point-to-point MPLS-TE LSPs. Point-to-multipoint MPLS-TE LSPs are for future study.
このドキュメントは、ポイントツーポイントMPLS-TE LSPのサポートのためにスケーラビリティを達成するという問題のみを考慮します。ポイントツーマルチポイントMPLS-TE LSPは、将来の研究のためです。
This document applies consistent notation to define various parameters of the networks that are analyzed. These terms are defined as they are introduced throughout the document, but are grouped together here for quick reference. Refer to the full definitions in the text for detailed explanations.
このドキュメントは、分析されたネットワークのさまざまなパラメーターを定義するために一貫した表記を適用します。これらの用語は、ドキュメント全体で導入されているときに定義されますが、ここでは迅速な参照のためにグループ化されます。詳細な説明については、テキストの完全な定義を参照してください。
n A network level. n = 1 is the core of the network. See Section 3 for more details on the definition of a level. P(n) A node at level n in the network. S(n) The number of nodes at level n. That is, the number of P(n) nodes. L(n) The number of LSPs seen by a P(n) node. X(n) The number of LSP segment states held by a P(n) node. M(n) The number of P(n+1) nodes subtended to a P(n) node. R The number of rungs in a ladder network. E The number of edge nodes (PEs) subtended below (directly or indirectly) a spar-node in a ladder network. K The cost-effectiveness of the network expressed in terms of the ratio of the number of PEs to the number of network nodes.
nネットワークレベル。n = 1はネットワークのコアです。レベルの定義の詳細については、セクション3を参照してください。P（n）ネットワーク内のレベルNのノード。s（n）レベルnでのノードの数。つまり、p（n）ノードの数。l（n）p（n）ノードで見られるLSPの数。x（n）p（n）ノードが保有するLSPセグメント状態の数。m（n）p（n 1）ノードの数は、p（n）ノードに抑制されました。rはしごネットワーク内のラングの数。e下（直接的または間接的に）はしごネットワーク内のスパーノードの下に（直接的または間接的に）抑制されたエッジノードの数（PES）。Kネットワークノードの数に対するPEの数の比率で表されるネットワークの費用対効果。
This section presents some of the issues associated with the support of LSPs at a Label Switching Router (LSR) or within the network. These issues may mean that there is a limit to the number of LSPs that can be supported.
このセクションでは、ラベルスイッチングルーター（LSR）またはネットワーク内でのLSPのサポートに関連する問題の一部を示します。これらの問題は、サポートできるLSPの数に制限があることを意味する場合があります。
LSP state is the data (information) that must be stored at an LSR in order to maintain an LSP. Here, we refer to the information that is necessary to maintain forwarding plane state and the additional information required when LSPs are established through control plane protocols. While the size of the LSP state is implementation-dependent, it is clear that any implementation will require some data in order to maintain LSP state.
LSP状態は、LSPを維持するためにLSRに保存する必要があるデータ（情報）です。ここでは、転送面の状態を維持するために必要な情報と、LSPがコントロールプレーンプロトコルを通じて確立されたときに必要な追加情報を参照します。LSP状態のサイズは実装依存ですが、LSP状態を維持するために、実装にはデータが必要であることは明らかです。
Thus, LSP state becomes a scaling concern because as the number of LSPs at an LSR increases, so the amount of memory required to maintain the LSPs increases in direct proportion. Since the memory capacity of an LSR is limited, there is a related limit placed on the number LSPs that can be supported.
したがって、LSP状態はスケーリングの懸念事項になります。これは、LSRでのLSPの数が増加すると、LSPを維持するために必要なメモリの量が直接比例して増加するためです。LSRのメモリ容量は限られているため、サポートできるLSPS数に関連する制限があります。
Note that techniques to reduce the memory requirements (such as data compression) may serve to increase the number of LSPs that can be supported, but this will only achieve a moderate multiplier and may significantly decrease the ability to process the state rapidly.
メモリ要件を減らすための手法（データ圧縮など）は、サポートできるLSPの数を増やすのに役立つ可能性があることに注意してください。しかし、これは中程度の乗数を達成するだけで、状態を迅速に処理する能力を大幅に低下させる可能性があります。
In this document, we define X(n) as "the number of LSP segment states held by a P(n) node." This definition observes that an LSR at the end of an LSP only has to maintain state in one direction (i.e., into the network), while a transit LSR must maintain state in both directions (i.e., toward both ends of the LSP). Furthermore, in multipoint-to-point (MP2P) LSPs (see Section 8), a transit LSR may need to maintain LSP state for one downstream segment (toward the destination) and multiple upstream segments (from multiple sources). That is, we define LSP segment state as the state necessary to maintain an LSP in one direction to one adjacent node.
このドキュメントでは、x（n）を「p（n）ノードによって保持されているLSPセグメント状態の数」として定義します。この定義は、LSPの終わりにあるLSRは、一方向に状態を維持するだけで（つまり、ネットワークに）状態を維持する必要があることを観察しますが、トランジットLSRは両方向（つまり、LSPの両端に向かって）の状態を維持する必要があります。さらに、マルチポイントツーポイント（MP2P）LSP（セクション8を参照）では、トランジットLSRは、1つのダウンストリームセグメント（目的地に向かって）および複数の上流セグメント（複数のソースから）のLSP状態を維持する必要がある場合があります。つまり、LSPセグメント状態を、LSPを1つの隣接するノードに一方向に維持するために必要な状態として定義します。
Depending largely on implementation issues, the number of LSPs passing through an LSR may impact the processing speed for each LSP. For example, control block search times can increase with the number of control blocks to be searched, and even excellent implementations cannot completely mitigate this fact. Thus, since CPU power is constrained in any LSR, there may be a practical limit to the number of LSPs that can be supported.
主に実装の問題に応じて、LSRを通過するLSPの数は、各LSPの処理速度に影響を与える可能性があります。たとえば、コントロールブロックの検索時間は、検索するコントロールブロックの数とともに増加する可能性があり、優れた実装でさえこの事実を完全に軽減することはできません。したがって、CPU電力は任意のLSRで制約されているため、サポートできるLSPの数には実際的な制限がある可能性があります。
Further processing overhead considerations depend on issues specific to the control plane protocols, and are discussed in the next section.
オーバーヘッドの考慮事項をさらに処理すると、コントロールプレーンのプロトコルに固有の問題に依存し、次のセクションで説明します。
Like many connection-oriented signaling protocols, RSVP-TE (Resource Reservation Protocol - Traffic Engineering) requires that state is held within the network in order to maintain LSPs. The impact of this is described in Section 2.1. Note that RSVP-TE requires that separate information is maintained for upstream and downstream relationships, but does not require any specific implementation of that state.
多くの接続指向のシグナリングプロトコルと同様に、RSVP-TE（リソース予約プロトコル - トラフィックエンジニアリング）では、LSPを維持するために状態がネットワーク内に保持されることが必要です。この影響については、セクション2.1で説明しています。RSVP-TEでは、上流と下流の関係のために個別の情報が維持される必要があるが、その状態の特定の実装は必要ないことに注意してください。
RSVP-TE is a soft-state protocol, which means that protocol messages (refresh messages) must be regularly exchanged between signaling neighbors in order to maintain the state for each LSP that runs between the neighbors. A common period for the transmission (and receipt) of refresh messages is 30 seconds, meaning that each LSR must send and receive one message in each direction (upstream and downstream) every 30 seconds for every LSP it supports. This has the potential to be a significant constraint on the scaling of the network, but various improvements [RFC2961] mean that this refresh processing can be significantly reduced, allowing an implementation to be optimized to remove nearly all concerns about soft-state scaling in a stable network.
RSVP-TEはソフトステートプロトコルです。つまり、プロトコルメッセージ（更新メッセージ）は、近隣の間で実行される各LSPの状態を維持するために、隣人の間で定期的に交換する必要があります。更新メッセージの送信（および領収書）の一般的な期間は30秒です。つまり、各LSRは、サポートするLSPごとに30秒ごとに各方向（上流および下流）に1つのメッセージを送信および受信する必要があります。これは、ネットワークのスケーリングに大きな制約となる可能性がありますが、さまざまな改善[RFC2961]は、この更新処理を大幅に削減できることを意味し、実装を最適化してソフトステートスケーリングに関するほぼすべての懸念を削除することができます。安定したネットワーク。
Observations of existing implementations indicate that there may be a threshold of around 50,000 LSPs above which an LSR struggles to achieve sufficient processing to maintain LSP state. Although refresh reduction [RFC2961] may substantially improve this situation, it has also been observed that under these circumstances the size of the Srefresh may become very large, and the processing required may still cause significant disruption to an LSR.
既存の実装の観察は、LSRがLSP状態を維持するのに十分な処理を達成するのに苦労している約50,000 LSPのしきい値がある可能性があることを示しています。更新削減[RFC2961]はこの状況を大幅に改善する可能性がありますが、これらの状況では、Srefreshのサイズが非常に大きくなり、必要な処理がLSRに大幅な破壊を引き起こす可能性があることも観察されています。
Another approach is to increase the refresh time. There is a correlation between the percentage increase in refresh time and the improvement in performance for the LSR. However, it should be noted that RSVP-TE's soft-state nature depends on regular refresh messages; thus, a degree of functionality is lost by increasing the refresh time. This loss may be partially mitigated by the use of the RSVP-TE Hello message, and can also be reduced by the use of various GMPLS extensions [RFC3473], such as the use of [RFC2961] message acknowledgements on all messages.
別のアプローチは、更新時間を増やすことです。更新時間の増加率とLSRのパフォーマンスの改善との間には相関があります。ただし、RSVP-TEのソフトステートの性質は、定期的な更新メッセージに依存することに注意する必要があります。したがって、更新時間を増やすことにより、程度の機能が失われます。この損失は、RSVP-TE Helloメッセージの使用によって部分的に緩和される可能性があり、すべてのメッセージで[RFC2961]メッセージ確認など、さまざまなGMPLS拡張機能[RFC3473]を使用することで削減することもできます。
RSVP-TE also requires that signaling adjacencies be maintained through the use of Hello message exchanges. Although [RFC3209] suggests that Hello messages should be retransmitted every 5 ms, in practice, values of around 3 seconds are more common. Nevertheless, the support of Hello messages can represent a scaling limitation on an RSVP-TE implementation since one message must be sent and received to/from each signaling adjacency every time period. This can impose limits on the number of neighbors (physical or logical) that an LSR supports, but does not impact the number of LSPs that the LSR can handle.
RSVP-TEでは、Helloメッセージ交換を使用して、シグナリングの隣接を維持する必要があります。[RFC3209]は、Helloメッセージを5ミリ秒ごとに再送信する必要があることを示唆していますが、実際には、約3秒の値がより一般的です。それにもかかわらず、Helloメッセージのサポートは、1つのメッセージを毎回各シグナリング隣接に送信および受信する必要があるため、RSVP-TE実装のスケーリング制限を表すことができます。これにより、LSRがサポートする近隣の数（物理的または論理的）の数に制限を課すことができますが、LSRが処理できるLSPの数には影響しません。
Another practical concern for the scalability of large MPLS-TE networks is the ability to manage the network. This may be constrained by the available tools, the practicality of managing large numbers of LSPs, and the management protocols in use.
大規模なMPLS-TEネットワークのスケーラビリティに関するもう1つの実際的な懸念は、ネットワークを管理する機能です。これは、利用可能なツール、多数のLSPを管理する実用性、および使用中の管理プロトコルによって制約される場合があります。
Management tools are software implementations. Although such implementations should not constrain the control plane protocols, it is realistic to appreciate that network deployments will be limited by the scalability of the available tools. In practice, most existing tools have a limit to the number of LSPs that they can support. While a Network Management System (NMS) may be able to support a large number of LSPs, the number that can be supported by an Element Management System (EMS) (or the number supported by an NMS per-LSR) is more likely to be limited.
管理ツールはソフトウェアの実装です。このような実装は、コントロールプレーンのプロトコルを制約するべきではありませんが、利用可能なツールのスケーラビリティによってネットワークの展開が制限されることを理解することは現実的です。実際には、ほとんどの既存のツールには、サポートできるLSPの数に制限があります。ネットワーク管理システム（NMS）は多数のLSPをサポートできる場合がありますが、要素管理システム（EMS）（またはNMS PER-LSRでサポートされる数）でサポートできる数は、限定。
Similarly, practical constraints may be imposed by the operation of management protocols. For example, an LSR may be swamped by management protocol requests to read information about the LSPs that it supports, and this might impact its ability to sustain those LSPs in the control plane. OAM (Operations, Administration, and Management), alarms, and notifications can further add to the burden placed on an LSR and limit the number of LSPs it can support.
同様に、管理プロトコルの操作により、実用的な制約が課される場合があります。たとえば、LSRは、サポートするLSPに関する情報を読むための管理プロトコル要求によって圧倒される可能性があり、これが制御プレーンでそれらのLSPを維持する能力に影響を与える可能性があります。OAM（運用、管理、および管理）、アラーム、および通知は、LSRに課される負担をさらに追加し、サポートできるLSPの数を制限できます。
All of these considerations encourage a reduction in the number of LSPs supported within the network and at any particular LSR.
これらの考慮事項はすべて、ネットワーク内および特定のLSRでサポートされるLSPの数の減少を促進します。
In order to provide some generic analysis of the potential scaling issues for MPLS-TE networks, this document explores two network topology models. These topologies are selected partly because of their symmetry, which makes them more tractable to a formulaic approach, and partly because they represent generalizations of real deployment models. Section 3.3 provides a discussion of the commercial drivers for deployed topologies and gives more analysis of why it is reasonable to consider these two topologies.
MPLS-TEネットワークの潜在的なスケーリング問題の一般的な分析を提供するために、このドキュメントでは2つのネットワークトポロジモデルを調査します。これらのトポロジは、対称性のために部分的に選択されているため、定型的なアプローチに対してより扱いやすくなり、一部は実際の展開モデルの一般化を表しているためです。セクション3.3では、展開されたトポロジーの商業ドライバーの議論を提供し、これら2つのトポロジを考慮することが合理的である理由のより多くの分析を提供します。
The first topology is the snowflake model. In this type of network, only the very core of the network is meshed. The edges of the network are formed as trees rooted in the core.
最初のトポロジーはスノーフレークモデルです。このタイプのネットワークでは、ネットワークの非常にコアのみがメッシュ化されます。ネットワークのエッジは、コアに根ざした木として形成されます。
The second network topology considered is the ladder model. In this type of network, the core of the network is shaped and meshed in the form of a ladder and trees are attached rooted to the edge of the ladder.
考慮される2番目のネットワークトポロジは、はしごモデルです。このタイプのネットワークでは、ネットワークのコアがはしごの形で形作られ、メッシュ化され、木ははしごの端に根を張ります。
The sections that follow examine these topologies in detail in order to parameterize them.
以下のセクションでは、これらのトポロジをパラメーター化するために詳細に調べます。
The snowflake topologies considered in this document are based on a hierarchy of connectivity within the core network. PE nodes have connectivity to P-nodes as shown in Figure 1. There is no direct connectivity between the PEs. Dual homing of PEs to multiple P-nodes is not considered in this document, although it may be a valuable addition to a network configuration.
このドキュメントで検討されているスノーフレークトポロジは、コアネットワーク内の接続の階層に基づいています。図1に示すように、PEノードにはpノードへの接続性があります。PES間に直接的な接続はありません。このドキュメントでは、複数のPノードへのPESのデュアルホーミングは考慮されていませんが、ネットワーク構成への貴重な追加である可能性があります。
P
/|\
/ | \
/ | \
/ | \
PE PE PE
Figure 1 : PE to P-Node Connectivity
図1：PEからPノード接続性
The relationship between P-nodes is also structured in a hierarchical way. Thus, as shown in Figure 2, multiple P-nodes at one level are connected to a P-node at a higher level. We number the levels such that level 1 is the top level (top in our figure, and nearest to the core of the network) and level (n) is immediately above level (n+1); we denote a P-node at level n as a P(n).
Pノード間の関係も階層的な方法で構成されています。したがって、図2に示すように、1つのレベルの複数のPノードがより高いレベルのPノードに接続されます。レベル1が最上位レベル（図の上部、ネットワークのコアに最も近い）とレベル（n）がレベル（n 1）のすぐ上にあるようなレベルを数えます。レベルnのPノードをA P（N）として示します。
As with PEs, there is no direct connectivity between P(n+1) nodes. Again, dual homing of P(n+1) nodes to multiple P(n) nodes is not considered in this document, although it may be a valuable addition to a network configuration.
PESと同様に、p（n 1）ノード間に直接的な接続はありません。繰り返しますが、このドキュメントでは、P（n 1）ノードの複数のp（n）ノードへのデュアルホーミングは考慮されていませんが、ネットワーク構成への貴重な追加である可能性があります。
P(n)
/|\
/ | \
/ | \
/ | \
P(n+1) P(n+1) P(n+1)
Figure 2 : Relationship between P-Nodes
図2：Pノード間の関係
At the top level, P(1) nodes are connected in a full mesh. In reality, the level 1 part of the network may be slightly less well-connected than this, but assuming a full mesh provides for generality. Thus, the snowflake topology comprises a clique with topologically equivalent trees subtended from each node in the clique.
上部レベルでは、P（1）ノードが完全なメッシュで接続されています。実際には、ネットワークのレベル1部分はこれよりもわずかによく接続されていない場合がありますが、完全なメッシュが一般性を提供すると仮定すると。したがって、スノーフレークトポロジーは、クリーク内の各ノードから地位に包まれたトポロジー的に同等の木を備えたクリークで構成されています。
The key multipliers for scalability are the number of P(1) nodes and the multiplier relationship between P(n) and P(n+1) at each level, down to and including PEs.
スケーラビリティの重要な乗数は、P（1）ノードの数と、各レベルでのP（n）とP（n 1）の間の乗数関係、PEを含むことです。
We define the multiplier M(n) as the number of P(n+1) nodes at level (n+1) attached to any one P(n). Assume that M(n) is constant for all nodes at level n. Since nodes at the same level are not interconnected (except at the top level), and since each P(n+1) node is connected to precisely one P(n) node, M(n) is one less than the degree of the node at level n (that is, the P(n) node is attached to M(n) nodes at level (n+1) and to 1 node at level (n-1)).
乗数m（n）を、1つのp（n）に取り付けられたレベル（n 1）のp（n 1）ノードの数として定義します。レベルnのすべてのノードのm（n）が一定であると仮定します。同じレベルのノードは相互接続されていないため（上部レベルを除く）、各p（n 1）ノードは正確に1つのp（n）ノードに接続されているため、m（n）はノードの程度よりも1小さいレベルn（つまり、p（n）ノードは、レベル（n 1）のm（n）ノードに、レベル（n-1）の1ノードに接続されます）。
We define S(n) as the number of nodes at level (n).
s（n）をレベル（n）のノードの数として定義します。
Thus:
したがって：
S(n) = S(1)*M(1)*M(2)*...*M(n-1)
So the number of PEs can be expressed as:
したがって、PEの数は次のように表現できます。
S(PE) = S(1)*M(1)*M(2)*...*M(n)
where the network has (n) layers of P-nodes.
ネットワークには（n）pノードのレイヤーがあります。
Thus, we may depict an example snowflake network as shown in Figure 3. In this case:
したがって、図3に示すように、スノーフレークネットワークの例を描写する場合があります。この場合、次の場合：
S(1) = 3
M(1) = 3
S(2) = S(1)*M(1) = 9
M(2) = 2
S(PE) = S(1)*M(1)*M(2) = 18
PE PE PE PE PE PE
\ \/ \/ /
PE--P(2) P(2) P(2) P(2)--PE
\ | | /
\| |/
PE--P(2)---P(1)------P(1)---P(2)--PE
/ \ / \
PE \ / PE
\/
P(1)
/|\
/ | \
/ | \
PE--P(2) P(2) P(2)--PE
/ /\ \
PE PE PE PE
Figure 3 : An Example Snowflake Network
図3：スノーフレークネットワークの例
The ladder networks considered in this section are based on an arrangement of routers in the core network that resembles a ladder.
このセクションで検討されているラダーネットワークは、はしごに似たコアネットワーク内のルーターの配置に基づいています。
Ladder networks typically have long and thin cores that are arranged as conventional ladders. That is, they have one or more spars connected by rungs. Each node on a spar may have:
はしごネットワークには、通常、従来のはしごとして配置された長くて薄いコアがあります。つまり、ラングで接続された1つ以上のスパーがあります。スパー上の各ノードには次のようなものがあります。
- connection to one or more other spars, - connection to a tree of other core nodes, - connection to customer nodes.
- 1つ以上の他のスパーへの接続 - 他のコアノードのツリーへの接続 - 顧客ノードへの接続。
Figure 4 shows a simplified example of a ladder network. A core of twelve nodes makes up two spars connected by six rungs.
図4は、はしごネットワークの単純化された例を示しています。12のノードのコアは、6つのラングで接続された2つのスパーを構成します。
PE PE PE PE
PE PE PE | PE | PE PE PE | PE | PE
\| \|/ |/ | \| \|/
PE-P-----P-----P-----P------P-----P--PE
| | | | | |\
| | | | | | PE
| | | | | |
PE-P-----P-----P-----P------P-----P
/| /|\ |\ |\ |\ \
PE PE PE | PE | PE | PE | PE PE
PE PE PE PE
Figure 4 : A Simplified Ladder Network
図4：単純化されたはしごネットワーク
In practice, not all nodes on a spar (call them spar-nodes) need to have subtended PEs. That is, they can exist simply to give connectivity along the spar to other spar-nodes, or across a rung to another spar. Similarly, the connectivity between spars can be more complex with multiple connections from one spar-node to another spar. Lastly, the network may be complicated by the inclusion of more than two spars (or simplified by reduction to a single spar).
実際には、スパー上のすべてのノード（スパーノードと呼ぶ）は、PESを抑える必要があるわけではありません。つまり、他のスパーノードにスパーに沿って接続を与えるか、ラングを越えて別のスパーに接続するために存在することができます。同様に、スパー間の接続性は、あるスパーノードから別のスパーへの複数の接続でより複雑になる可能性があります。最後に、ネットワークは、2つ以上のスパーを含めることで複雑になる可能性があります（または単一のスパーへの削減により単純化されます）。
These variables make the ladder network non-trivial to model. For the sake of simplicity, we will make the following restrictions:
これらの変数により、ラダーネットワークはモデルに違反しません。簡単にするために、次の制限を作成します。
- There are precisely two spars in the core network.
- コアネットワークにはまったく2つのスパーがあります。
- Every spar-node connects to precisely one spar-node on the other spar. That is, each spar-node is attached to precisely one rung.
- すべてのスパーノードは、他のスパーの1つのスパーノードに正確に接続します。つまり、各スパーノードは正確に1つのラングに接続されています。
- Each spar-node connects to either one (end-spar) or two (core-spar) other spar-nodes on the same spar.
- 各スパーノードは、同じSPAR上の1つの（終了）または2つの他のスパーノードのいずれかに接続します。
- Every spar-node has the same number of PEs subtended. This does not mean that there are no P-nodes subtended to the spar-nodes, but does mean that the edge tree subtended to each spar-node is identical.
- すべてのSPARノードには、同じ数のPESが抑制されています。これは、スパーノードに抑制されたpノードがないことを意味するものではありませんが、各スパーノードに抑制されたエッジツリーが同一であることを意味します。
From these restrictions, we are able to quantify a ladder network as follows:
これらの制限から、次のようにはしごネットワークを定量化することができます。
R - The number of rungs. That is, the number of spar-nodes on each spar. S(1) - The number of spar-nodes in the network. S(1)=2*R. E - The number of subtended edge nodes (PEs) to each spar-node.
R-ラングの数。つまり、各スパーのスパーノードの数。S（1） - ネットワーク内のスパーノードの数。S（1）= 2*r。E-各SPARノードへの抑制エッジノード（PES）の数。
The number of rungs may vary considerably. A number less than 3 is unlikely (since that would not be a significantly connected network), and a number greater than 100 seems improbable (because that would represent a very long, thin network).
ラングの数はかなり異なる場合があります。3未満の数はありそうにない（それは大幅に接続されたネットワークではないため）、100を超える数はありそうもないように思われます（それは非常に長くて薄いネットワークを表すため）。
E can be treated as for the snowflake network. That is, we can consider a number of levels of attachment from P(1) nodes, which are the spar-nodes, through P(i) down to P(n), which are the PEs. Practically, we need to only consider n=2 (PEs attached direct to the spar-nodes) and n=3 (one level of P-nodes between the PEs and the spar-nodes).
Eは、スノーフレークネットワークのように扱うことができます。つまり、P（1）ノードからの多くのレベルのアタッチメントを考慮することができます。P（1）ノードは、P（i）を介してP（n）までPESであるP（n）までです。実際には、n = 2（SPARノードに直接接続されているPES）とn = 3（PESとSPARノードの間の1レベルのpノード）のみを考慮する必要があります。
Let M(i) be the ratio of P(i) nodes to P(i-1) nodes, i.e., the connectivity between levels of P-node as defined for the snowflake topology. Hence, the number of nodes at any level (n) is:
m（i）をp（i）ノードとp（i-1）ノードの比、つまり、スノーフレークトポロジーで定義されているpノードのレベル間の接続性とします。したがって、任意のレベル（n）のノードの数は次のとおりです。
S(n) = S(1)*M(1)*M(2)*...*M(n-1)
So the number of PEs subtended to a spar-node is:
したがって、スパーノードに抑制されたPESの数は次のとおりです。
E = M(1)*M(2)*...*M(n)
And the number of PEs can be expressed as:
PEの数は次のように表現できます。
S(PE) = S(1)*M(1)*M(2)*...*M(n)
= S(1)*E
Thus, we may depict an example ladder network as shown in Figure 5. In this case:
したがって、図5に示すように、ラダーネットワークの例を描写する場合があります。この場合：
R = 5
S(1) = 10
M(1) = 2
S(2) = S(1)*M(1) = 20
M(2) = 2
E = M(1)*M(2) = 4
S(PE) = S(1)*E = 40
PE PE PE PE PE PE PE PE PE PE PE PE PE PE PE PE
\| \| \| \| |/ |/ |/ |/
P(2) P(2) P(2) P(2) P(2) P(2) P(2) P(2)
\ \ | \ / | / /
PE \ \ | \ / | / / PE
\ \ \| \/ |/ / /
PE-P(2)---P(1)---P(1)---P(1)---P(1)---P(1)---P(2)-PE
| | | | |
| | | | |
| | | | |
PE-P(2)---P(1)---P(1)---P(1)---P(1)---P(1)---P(2)-PE
/ / / | /\ |\ \ \
PE / / | / \ | \ \ PE
/ / | / \ | \ \
P(2) P(2) P(2) P(2) P(2) P(2) P(2) P(2)
/| /| /| /| |\ |\ |\ |\
PE PE PE PE PE PE PE PE PE PE PE PE PE PE PE PE
Figure 5 : An Example Ladder Network
図5：ラダーネットワークの例
It is reasonable to ask why these two particular network topologies have been chosen.
なぜこれら2つの特定のネットワークトポロジが選択されたのかを尋ねることは合理的です。
The most important consideration is physical scalability. Each node (Label Switching Router - LSR) is only able to support a limited number of physical interfaces. This necessarily reduces the ability to fully mesh a network and leads to the tree-like structure of the network toward the PEs.
最も重要な考慮事項は、物理的なスケーラビリティです。各ノード（ラベルスイッチングルーター-LSR）は、限られた数の物理インターフェイスのみをサポートできます。これにより、必然的にネットワークを完全にメッシュする能力が低下し、ネットワークのような構造がPESに向かっています。
A realistic commercial consideration for an operator is the fact that the only revenue-generating nodes in the network are the PEs. Other nodes are needed only to support connectivity and scalability. Therefore, there is a desire to maximize S(PE) while minimizing the sum of S(n) for all values of (n). This could be achieved by minimizing the number of levels and maximizing the connectivity at each layer, M(n). Ultimately, however, this would produce a network of just interconnected PEs, which is clearly in conflict with the physical scaling situation.
オペレーターの現実的な商業的考慮事項は、ネットワーク内の収益を生み出す唯一のノードがPESであるという事実です。他のノードは、接続性とスケーラビリティをサポートするためにのみ必要です。したがって、（n）のすべての値のs（n）の合計を最小化しながら、s（pe）を最大化するという欲求があります。これは、レベルの数を最小化し、各レイヤーでの接続性を最大化することで実現できます。ただし、最終的には、これにより相互接続されたPESのネットワークが生成されます。これは、物理的なスケーリングの状況と明らかに対立しています。
Therefore, the solution calls for a "few" levels with "relatively large" connectivity at each level. We might say that the cost-effectiveness of the network can be stated as:
したがって、このソリューションでは、各レベルで「比較的大きな」接続性を備えた「少数」レベルを必要とします。ネットワークの費用対効果は次のように述べることができると言うかもしれません。
K = S(PE)/(S(1)+S(2) + ... + S(n)) where n is the level above the PEs We should observe, however, that this equation may be naive in that the cost of a network is not actually a function of the number of routers (since a router chassis is often free or low cost), but is really a function of the cost of the line cards, which is, itself, a product of the capacity of the line cards. Thus, the relatively high connectivity decreases the cost-effectiveness, while a topology that tends to channel data through a network core tends to demand higher capacity (and so, more expensive) line cards.
k = s（pe）/（s（1）s（2）... s（n））ここで、nは、この方程式がaのコストであるという点で素朴である可能性があることを観察すべきpesを超えるレベルです。ネットワークは実際にはルーターの数の関数ではありません（ルーターシャーシはしばしば無料または低コストであるため）が、実際にはラインカードのコストの関数です。カード。したがって、比較的高い接続性は費用対効果を低下させますが、ネットワークコアを介してデータをチャネルする傾向があるトポロジは、より高い容量（そして、より高価な）ラインカードを必要とする傾向があります。
A further consideration is the availability of connectivity (usually fibers) between LSR sites. Although it is always possible to lay new fiber, this may not be cost-effective or timely. The physical shape and topography of the country in which the network is laid is likely to be as much of a problem. If the country is 'long and thin', then a ladder network is likely to be used.
さらなる考慮事項は、LSRサイト間の接続性（通常は繊維）の可用性です。常に新しい繊維を敷設することは可能ですが、これは費用対効果やタイムリーではない場合があります。ネットワークが敷設されている国の物理的な形状と地形は、同じくらい問題になる可能性があります。国が「長くて薄い」場合、はしごネットワークが使用される可能性があります。
This document examines the implications for control plane and data plane scalability of this type of network when MPLS-TE LSPs are used to provide full connectivity between all PEs.
このドキュメントでは、MPLS-TE LSPを使用してすべてのPE間の完全な接続を提供する場合、このタイプのネットワークのコントロールプレーンとデータプレーンのスケーラビリティへの影響を調べます。
As explained in Section 1, this document is using two symmetrical and generalized network topologies for simplicity of modelling. In practice, there are two other topological considerations.
セクション1で説明したように、このドキュメントは、モデリングを簡単にするために、2つの対称的で一般化されたネットワークトポロジを使用しています。実際には、他にも2つのトポロジカルな考慮事項があります。
a. Multihoming It is relatively common for a node at level (n) to be attached to more than one node at level (n-1). This is particularly common at PEs that may be connected to more than one P(n).
a. マルチホームレベル（n）のノードがレベル（n-1）で複数のノードに接続されることは比較的一般的です。これは、複数のp（n）に接続される可能性のあるPESで特に一般的です。
b. Meshing within a level A level in the network will often include links between P-nodes at the same level, including the possibility of links between PEs. This may result in a network that looks like a series of concentric circles with spokes.
b. ネットワーク内のレベルAレベル内のメッシュには、PE間のリンクの可能性を含む、同じレベルのPノード間のリンクが含まれます。これにより、スポークを備えた一連の同心円のように見えるネットワークが生じる可能性があります。
Both of these features are likely to have some impact on the scaling of the networks. However, for the purposes of establishing the ground rules for scaling, this document restricts itself to the consideration of the symmetrical networks described in Sections 2.1 and 2.2. Discussion of other network formats is for future study.
これらの機能は両方とも、ネットワークのスケーリングにある程度の影響を与える可能性があります。ただし、スケーリングの基礎ルールを確立するために、このドキュメントは、セクション2.1および2.2で説明されている対称ネットワークの考慮に制限されています。他のネットワーク形式の議論は、将来の研究のためのものです。
An important question for this evaluation and analysis is the size of the network that operators require. How many PEs are required? What ratio of P to PE is acceptable? How many ports do devices have for physical connectivity? What type of MPLS-TE connectivity between PEs is required?
この評価と分析の重要な質問は、オペレーターが必要とするネットワークのサイズです。いくつのペーが必要ですか？PとPEの比率は許容されますか？物理的な接続のためにデバイスにはいくつのポートがありますか？PE間のどのタイプのMPLS-TE接続が必要ですか？
Although presentation of figures for desired network sizes must be treated with caution because history shows that networks grow beyond all projections, it is useful to set some acceptable lower bounds. That is, we can state that we are interested in networks of at least a certain size.
歴史はネットワークがすべての予測を超えて成長することを示しているため、希望のネットワークサイズの図の提示は慎重に扱わなければなりませんが、許容可能な下限を設定すると便利です。つまり、少なくとも特定のサイズのネットワークに関心があると述べることができます。
The most important features are:
最も重要な機能は次のとおりです。
- The network should have at least 1000 PEs. - Each pair of PEs should be connected by at least one LSP in each direction.
- ネットワークには、少なくとも1000個のPEが必要です。-PEの各ペアは、各方向に少なくとも1つのLSPで接続する必要があります。
In practice, reasonable target numbers are as follows.
実際には、妥当なターゲット数は次のとおりです。
S(PE) >= 1000
Number of levels is 3. That is: 1, 2, and PE.
M(2) <= 20
M(1) <= 20
S(1) <= 100
Before proceeding to examine potential scaling improvements, we need to examine how well the flat networks described in the previous sections scale.
潜在的なスケーリングの改善を調べる前に、前のセクションスケールで説明したフラットネットワークがどれだけうまくいっているかを調べる必要があります。
Consider the requirement for a full mesh of LSPs linking all PEs. That is, each PE has an LSP to and from every other LSP. Thus, if there are S(PE) PEs in the network, there are S(PE)*(S(PE) - 1) LSPs.
すべてのPEをリンクするLSPの完全なメッシュの要件を考慮してください。つまり、各PEには、他のすべてのLSPとの間のLSPがあります。したがって、ネットワークにs（pe）pesがある場合、s（pe）*（s（pe）-1）lspsがあります。
Define L(n) as the number of LSPs handled by a level (n) LSR.
l（n）をレベル（n）LSRによって処理されるLSPの数として定義します。
L(PE) = 2*(S(PE) - 1)
There are a total of S(PE) PEs in the network and, since each PE establishes an LSP with every other PE, it would be expected that there are S(PE) - 1 LSPs incoming to each PE and the same number of LSPs outgoing from the same PE, giving a total of 2(S(PE) - 1) on the incident link. Hence, in a snowflake topology (see Figure 3), since there are M(2) PEs attached to each P(2) node, it may tempting to think that L(2) (the number of LSPs traversing each P(2) node) is simply 2*(S(PE) - 1)*M(2). However, it should be noted that of the S(PE) - 1 LSPs incoming to each PE, M(2) - 1 originated from nodes attached to the same P(2) node, and so this value would count the LSPs between the M(2) PEs attached to each P(2) node twice: once when outgoing from the M(2) - 1 other nodes and once when incoming into a particular PE.
ネットワークには合計S（PE）PEがあり、各PEが他のすべてのPEでLSPを確立するため、各PEにs（PE）-1 LSPがあり、同じ数のLSPがあると予想されます。同じPEから発信し、インシデントリンクに合計2（s（pe）-1）を与えます。したがって、スノーフレークトポロジ（図3を参照）では、各P（2）ノードにM（2）PEが付着しているため、L（2）（各P（2）を通過するLSPの数があると考えるのが魅力的かもしれません。ノード）は単に2*（s（pe）-1）*m（2）です。ただし、各PE、m（2）-1に着信するS（PE）-1 LSPのsp（2）ノードに接続されたノードから発生することに注意する必要があります。したがって、この値は、この値がLSPをカウントします。M（2）各P（2）ノードに2回接続されているPE：M（2）-1の他のノードから発信するとき、1回、特定のPEに着信するとき。
There are a total of M(2)*(M(2) - 1) LSPs between these M(2) PEs and, since this value is erroneously included twice in 2*(S(PE) - 1)*M(2), the correct value is:
これらのM（2）PESの間には合計m（2）*（m（2）-1）LSPがあり、この値は2*（s（s（pe）-1）*m（2）に誤って含まれているため）、正しい値は次のとおりです。
L(2) = 2*M(2)*(S(PE) - 1) - M(2)*(M(2) - 1)
= M(2)*(2*S(PE) - M(2) - 1)
An alternative way of looking at this, that proves extensible for the calculation of L(1), is to observe that each PE subtended to a P(2) node has an LSP in each direction to all S(PE) - M(2) PEs in the rest of the system, and there are M(2) such locally subtended PEs; thus, 2*M(2)*(S(PE) - M(2)). Additionally, there are M(2)*(M(2) - 1) LSPs between the locally subtended PEs. So:
L（1）の計算に対して拡張可能であることが証明されたこれを見る別の方法は、P（2）ノードに従う各PEがすべてのs（PE）-M（2）に各方向にLSPを持っていることを観察することです（2）システムの残りの部分にPEがあり、そのような局所的に帯電したPESがあります。したがって、2*m（2）*（s（pe）-m（2））。さらに、局所的に抑制されたPESの間にM（2）*（M（2）-1）LSPがあります。それで：
L(2) = 2*M(2)*(S(PE) - M(2)) + M(2)*(M(2) - 1)
= M(2)*(2*S(PE) - M(2) - 1)
L(1) can be computed in the same way as this second evaluation of
L(2). Each PE subtended below a P(1) node has an LSP in each
direction to all PEs not below the P(1) node. There are M(1)*M(2)
PEs below the P(1) node, so this accounts for 2*M(1)*M(2)*(S(PE) -
M(1)*M(2)) LSPs. To this, we need to add the number of LSPs that
pass through the P(1) node and that run between the PEs subtended
below the P(1). Consider each P(2): it has M(2) PEs, each of which
has an LSP going to all of the PEs subtended to the other P(2) nodes
subtended to the P(1). There are M(1) - 1 such other P(2) nodes, and
so M(2)*(M(1) - 1) other such PEs. So the number of LSPs from the
PEs below a P(2) node is M(2)*M(2)*(M(1) - 1). And there are M(1)
P(2) nodes below the P(1), giving rise to a total of
M(2)*M(2)*M(1)*(M(1) - 1) LSPs. Thus:
L(1) = 2*M(1)*M(2)*(S(PE) - M(1)*M(2)) + M(2)*M(2)*M(1)*(M(1) - 1)
= M(1)*M(2)*(2*S(PE) - M(2)*(M(1) + 1))
So, for example, with S(1) = 5, M(1) = 10, and M(2) = 20, we see:
したがって、たとえば、s（1）= 5、m（1）= 10、およびm（2）= 20では、次のように表示されます。
S(PE) = 1000
L(PE) = 1998
L(2) = 39580
L(1) = 356000
Alternatively, with S(1) = 10, M(1) = 10, and M(2) = 20, we see:
あるいは、S（1）= 10、M（1）= 10、およびM（2）= 20の場合、次のように表示されます。
S(PE) = 2000
L(PE) = 3998
L(2) = 79580
L(1) = 756000
In both examples, the number of LSPs at the core (P(1)) nodes is probably unacceptably large, even though there are only a relatively modest number of PEs. In fact, L(2) may even be too large in the second example.
どちらの例でも、Core（P（1））ノードのLSPの数は、比較的控えめなPESしかないにもかかわらず、おそらく容認できないほど大きいでしょう。実際、2番目の例ではL（2）が大きすぎる可能性があります。
In ladder networks, L(PE) remains the same at 2*(S(PE) - 1).
はしごネットワークでは、L（PE）は2*（S（PE）-1）で同じままです。
L(2) can be computed using the same mechanism as for the snowflake topology because the subtended tree is the same format. Hence,
l（2）は、サブテン付きツリーが同じ形式であるため、スノーフレークトポロジと同じメカニズムを使用して計算できます。したがって、
L(2) = 2*M(2)*(S(PE) - 1) - M(2)*(M(2) - 1)
But L(1) requires a different computation because each P(1) not only sees LSPs for the subtended PEs, but is also a transit node for some of the LSPs that cross the core (the core is not fully meshed).
ただし、各p（1）は、抑制されたPEのLSPを見るだけでなく、コアを横切るLSPの一部のトランジットノードでもあるため、異なる計算が必要です。
Each P(1) sees:
各p（1）は次のとおりです。
o all of the LSPs between locally attached PEs, o less those LSPs between locally attached PEs that can be served exclusively by the attached P(2) nodes, o all LSPs between locally attached PEs and remote PEs, and o LSPs in transit that pass through the P(1).
o 局所的に接続されたPEの間のすべてのLSP、o付加されたP（2）ノードのみで提供できる局所的に接続されたPE間のLSPは、局所的に付着したPEとリモートPEの間のすべてのLSP、および通過する輸送中のLSPp（1）。
The first three numbers are easily determined and match what we have
seen from the snowflake network. They are:
o E*(E-1)
o M(1)*M(2)*(M(2)-1) = E*(M(2) - 1)
o 2*E*E*(S(1) - 1)
The number of LSPs in transit is more complicated to compute. It is simplified by not considering the ends of the ladders but by examining an arbitrary segment of the middle of the ladder, such as shown in Figure 6. We look to compute and generalize the number of LSPs traversing each core link (labeled a and b in Figure 6) and so determine the number of transit LSPs seen by each P(1).
輸送中のLSPの数は、計算がより複雑です。はしごの端を考慮せずに、図6に示すようにはしごの中央の任意のセグメントを調べることで単純化されます。図6）では、各p（1）で見られる輸送LSPの数を決定します。
: : : : : :
: : : : : :
P(2) P(2) P(2) P(2) P(2) P(2)
\ | \ / | /
\ | \ / | /
\| \/ |/
......P(1)---P(1)---P(1)......
| a | |
| |b |
| | |
......P(1)---P(1)---P(1)......
/| /\ |\
/ | / \ | \
/ | / \ | \
P(2) P(2) P(2) P(2) P(2) P(2)
: : : : : :
: : : : : :
Figure 6 : An Arbitrary Section of a Ladder Network
図6：はしごネットワークの任意のセクション
Of course, the number of LSPs carried on links a and b in Figure 6 depends on how LSPs are routed through the core network. But if we assume a symmetrical routing policy and an even distribution of LSPs across all shortest paths, the result is the same.
もちろん、図6のリンクAとBで運ばれるLSPの数は、LSPがコアネットワークを介してどのようにルーティングされるかによって異なります。しかし、対称的なルーティングポリシーとすべての最短パスにわたってLSPの均等な分布を想定している場合、結果は同じです。
Now we can see that each P(1) sees half of 2a+b LSPs (since each LSP would otherwise be counted twice as it passed through the P(1)), except that some of the LSPs are locally terminated and so are only included once in the sum 2a+b.
これで、各p（1）が2a b LSPの半分を見ることがわかります（それ以外の場合は、各LSPはp（1）を通過したときに2回カウントされるため）。ただし、LSPの一部は局所的に終了しているため、合計2a b。
So L(1) = a + b/2 -
(locally terminated transit LSPs)/2 +
(locally contained LSPs)
Thus:
したがって：
L(1) = a + b/2 -
2*E*E*(S(1) - 1)/2 +
E*(E-1) - E*(M(2) - 1)
= a + b/2 +
E*E*(2 - S(1)) - E*M(2)
So all we have to do is work out a and b.
したがって、私たちがしなければならないのは、Aとbを解決することだけです。
Recall that the ladder length R = S(1)/2, and define X = E*E.
はしごの長さr = s（1）/2がx = e*eを定義していることを思い出してください。
Consider the contribution made by all of the LSPs that make n hops on the ladder to the totals of each of a and b. If the ladder was unbounded, then we could say that in the case of a, there are n*2X LSPs along the spar only, and n(n-1)*2X/n = 2X(n-1) LSPs use a rung and the spar. Thus, the LSPs that make n hops on the ladder contribute (4n-2)X LSPs to a. Note that the edge cases are special because LSPs that make only one hop on the ladder cannot transit a P(1) but only start or end there.
nの各aとbの合計にnをホップするすべてのLSPによる貢献を考えてください。はしごが縛られていない場合、aの場合、スパーに沿ってn*2x lspがあり、n（n-1）*2x/n = 2x（n-1）lspsがラングを使用していると言えます。そしてスパー。したがって、はしごにnをホップするLSPは、（4N-2）x lspsに寄与します。はしごに1つのホップしかないLSPがP（1）を通過できないが、そこで開始または終了するだけであるため、エッジのケースは特別なものであることに注意してください。
So with a ladder of length R = S(1)/2, we could say:
したがって、r = s（1）/2の長さのはしごで、次のように言うことができます。
R
a = SUM[(4i-2)*X] + 2RX
i=2
= 2*X*R*(R+1)
And similarly, considering b in an unbounded ladder, the LSPs that only travel one hop on the LSP are a special case, contributing 2X LSPs, and every other LSP that traverses n hops on the ladder contributes 2n*2X/n = 4X LSPs. So:
同様に、Boundのbを無制限のはしごで考慮すると、LSPに1つのホップを移動するLSPは特別なケースであり、2x LSPに寄与し、梯子にnホップを通過する他のすべてのLSPが2N*2x/n = 4x LSPに寄与します。それで：
R+1 b = 2X + SUM[4X] i=2
r 1 b = 2x合計[4x] i = 2
= 2*X + 4*X*R
In fact, the ladders are bounded, and so the number of LSPs is reduced because of the effect of the ends of the ladders. The links that see the most LSPs are in the middle of the ladder. Consider a ladder of length R; a node in the middle of the ladder is R/2 hops away from the end of the ladder. So we see that the formula for the contribution to the count of spar-only LSPs for a is only valid up to n=R/2, and for spar-and-rung LSPs, up to n=1+R/2. Above these limits, the contribution made by spar-only LSPs decays as (n-R/2)*2X.
実際、はしごは境界が囲まれているため、はしごの端の効果のためにLSPの数が減少します。最も多くのLSPを見るリンクは、はしごの中央にあります。長さrのはしごを考えてみましょう。はしごの中央にあるノードは、はしごの端からR/2ホップです。したがって、AのSPARのみのLSPのカウントへの寄与の式は、n = r/2までのみ有効であり、スパーアンドラングLSPの場合、n = 1 r/2までのものであることがわかります。これらの制限を超えて、SPARのみのLSPSが（N-R/2）*2xとして減衰したことによる貢献。
However, for a first-order approximation, we will use the values of a and b as computed above. This gives us an upper bound of the number of LSPs without using a more complex formula for the reduction made by the effect of the ends of the ladder.
ただし、1次近似の場合、上記のようにAとBの値を使用します。これにより、はしごの端の効果によって行われる削減のためにより複雑な式を使用せずに、LSPの数の上限が得られます。
From this:
これから：
L(1) = a + b/2 +
E*E*(2 - S(1)) - E*M(2)
= 2*X*R*(R+1) +
X + 2*X*R +
E*E*(2 - S(1)) - E*M(2)
= E*E*S(1)*(1 + S(1)/2) +
E*E + E*E*S(1) +
2*E+E - E*E*S(1) - E*M(2)
= E*E*S(1)*(1 + S(1)/2) + 3*E+E - E*M(2)
= E*E*S(1)*S(1)/2 + E*E*S(1) + 3*E*E - E*M(2)
So, for example, with S(1) = 6, M(1) = 10, and M(2) = 17, we see:
したがって、たとえば、s（1）= 6、m（1）= 10、およびm（2）= 17では、次のように表示されます。
E = 170
S(PE) = 1020
L(PE) = 2038
L(2) = 34374
L(1) = 777410
Alternatively, with S(1) = 10, M(1) = 10, and M(2) = 20, we see:
あるいは、S（1）= 10、M（1）= 10、およびM（2）= 20の場合、次のように表示されます。
E = 200
S(PE) = 2000
L(PE) = 3998
L(2) = 79580
L(1) = 2516000
In both examples, the number of LSPs at the core (P(1)) nodes is probably unacceptably large, even though there are only a relatively modest number of PEs. In fact, L(2) may even be too large in the second example.
どちらの例でも、Core（P（1））ノードのLSPの数は、比較的控えめなPESしかないにもかかわらず、おそらく容認できないほど大きいでしょう。実際、2番目の例ではL（2）が大きすぎる可能性があります。
Compare the L(1) values with the total number of LSPs in the system S(PE)*(S(PE) - 1), which is 1039380 and 3998000, respectively.
L（1）値を、それぞれ1039380および3998000であるシステムS（PE）*（S（PE）-1）のLSPの総数と比較してください。
One of the purposes of LSP hierarchies [RFC4206] is to improve the scaling properties of MPLS-TE networks. LSP tunnels (sometimes known as Forwarding Adjacencies (FAs)) may be established to provide connectivity over the core of the network, and multiple edge-to-edge LSPs may be tunneled down a single FA LSP.
LSP階層[RFC4206]の目的の1つは、MPLS-TEネットワークのスケーリング特性を改善することです。LSPトンネル（転送隣接（FAS）と呼ばれることもあります）を確立して、ネットワークのコアを介した接続を提供することができ、複数のエッジからエッジLSPが単一のFA LSPをトンネリングすることができます。
In our network we consider a mesh of FA LSPs between all core nodes at the same level. We consider two possibilities here. In the first, all P(2) nodes are connected to all other P(2) nodes by LSP tunnels, and the PE-to-PE LSPs are tunneled across the core of the network. In the second, an extra layer of LSP hierarchy is introduced by connecting all P(1) nodes in an LSP mesh and tunneling the P(2)-to-P(2) tunnels through these.
ネットワークでは、同じレベルのすべてのコアノード間のFA LSPのメッシュを検討します。ここでは2つの可能性を検討しています。最初に、すべてのp（2）ノードはLSPトンネルによって他のすべてのp（2）ノードに接続され、PE-to-pe LSPはネットワークのコアにトンネル化されます。2番目では、LSPメッシュのすべてのp（1）ノードを接続し、これらを介してp（2）-p（2）トンネルをトンネル化することにより、LSP階層の余分な層が導入されます。
In this hierarchy model, the P(2) nodes are connected by a mesh of tunnels. This means that the P(1) nodes do not see the PE-to-PE LSPs.
この階層モデルでは、p（2）ノードはトンネルのメッシュで接続されています。これは、P（1）ノードにPE-PE LSPが表示されないことを意味します。
It remains the case that:
その場合は残っています：
L(PE) = 2*(S(PE) - 1)
L(2) is slightly increased. It can be computed as the sum of all LSPs for all attached PEs, including the LSPs between the attached PE (this figure is unchanged from Section 5.1, i.e., M(2)*(2*S(PE) - M(2) - 1)), plus the number of FA LSPs providing a mesh to the other P(2) nodes. Since the number of P(2) nodes is S(2), each P(2) node sees 2*(S(2) - 1) FA LSPs. Thus:
L（2）はわずかに増加します。付着したPE間のLSPを含むすべての付着したPEのすべてのLSPの合計として計算できます（この図はセクション5.1、つまりm（2）*（2*s（pe）-m（2）から変化しません。-1））、さらに、他のP（2）ノードにメッシュを提供するFA LSPの数。p（2）ノードの数はs（2）であるため、各p（2）ノードは2*（s（2）-1）fa lspsを表示します。したがって：
L(2) = M(2)*(2*S(PE) - M(2) - 1) + 2*(S(2) - 1)
L(1), however, is significantly reduced and can be computed as the sum of the number of FA LSPs to and from each attached P(2) to each other P(2) in the network, including (but counting only once) the FA LSPs between attached P(2) nodes. In fact, the problem is identical to the L(2) computation in Section 5.1. So:
ただし、L（1）は大幅に減少し、ネットワーク内の各P（2）と互いにP（2）との間のFA LSPの数の合計として計算できます（ただし、1回のみカウント）接続されたP（2）ノード間のFA LSP。実際、この問題は、セクション5.1のL（2）計算と同一です。それで：
L(1) = M(1)*(2*S(2) - M(1) - 1) So, for example, with S(1) = 5, M(1) = 10, and M(2) = 20, we see:
l（1）= m（1）*（2*s（2）-m（1）-1）したがって、たとえば、s（1）= 5、m（1）= 10、およびm（2）= 20、わかります：
S(PE) = 1000
S(2) = 50
L(PE) = 1998
L(2) = 39678
L(1) = 890
Alternatively, with S(1) = 10, M(1) = 10, and M(2) = 20, we see:
あるいは、S（1）= 10、M（1）= 10、およびM（2）= 20の場合、次のように表示されます。
S(PE) = 2000
S(2) = 100
L(PE) = 3998
L(2) = 79778
L(1) = 1890
So, in both examples, potential problems at the core (P(1)) nodes caused by an excessive number of LSPs can be avoided, but any problem with L(2) is made slightly worse, as can be seen from the table below.
したがって、両方の例では、過剰な数のLSPによって引き起こされるコア（P（1））ノードの潜在的な問題は回避できますが、L（2）の問題は、以下の表からわかるように、わずかに悪化しています。。
Example| Count | Unmodified | 2-Layer
| | (Section 5.1) | Hierarchy
-------+-------+---------------+----------
A | L(2) | 39580 | 39678
| L(1) | 356000 | 890
-------+-------+---------------+----------
B | L(2) | 79580 | 79778
| L(1) | 756000 | 1890
Clearly, we can reduce L(2) by selecting appropriate values of S(1), M(1), and M(2). We can do this without negative consequences, since no change will affect L(PE) and since a large percentage increase in L(1) is sustainable now that L(1) is so small.
明らかに、s（1）、m（1）、およびm（2）の適切な値を選択することにより、L（2）を減らすことができます。L（1）が非常に小さいので、L（1）の大部分の増加が持続可能であるため、変更はL（PE）に影響を与えないため、負の結果なしにこれを行うことができます。
Observe that:
それを観察してください：
L(2) = M(2)*(2*S(PE) - M(2) - 1) + 2*(S(2) - 1)
where S(PE) = S(1)*M(1)*M(2) and S(2) = S(1)*M(1). So L(2) scales with M(2)^2 and we can have the most impact by reducing M(2) while keeping S(PE) constant.
ここで、s（pe）= s（1）*m（1）*m（2）およびs（2）= s（1）*m（1）。したがって、l（2）はm（2）^2のスケールであり、S（2）を一定に保ちながらm（2）を減らすことで最も影響を与えることができます。
For example, with S(1) = 10, M(1) = 10, and M(2) = 10, we see:
たとえば、s（1）= 10、m（1）= 10、およびm（2）= 10では、次のように表示されます。
S(PE) = 1000
S(2) = 100
L(PE) = 1998
L(2) = 20088
L(1) = 1890
And similarly, with S(1) = 20, M(1) = 20, and M(2) = 5, we see:
同様に、s（1）= 20、m（1）= 20、およびm（2）= 5では、次のように表示されます。
S(PE) = 2000
S(2) = 400
L(PE) = 3998
L(2) = 20768
L(1) = 15580
These considerable scaling benefits must be offset against the cost-effectiveness of the network. Recall from Section 3.3 that:
これらのかなりのスケーリングの利点は、ネットワークの費用対効果に対して相殺する必要があります。セクション3.3から次のことを思い出してください。
K = S(PE)/(S(1)+S(2) ... + S(n))
where n is the level above the PEs, so that for our network:
ここで、nはPESの上のレベルであるため、ネットワークの場合：
K = S(PE) / (S(1) + S(2))
Thus, in the first example the cost-effectiveness has been halved from 1000/55 to 1000/110. In the second example, it has been reduced to roughly one quarter, changing from 2000/110 to 2000/420.
したがって、最初の例では、費用対効果は1000/55から1000/110に半分になりました。2番目の例では、2000/110年から2000/420年に変更され、約4分の1に削減されました。
So, although the tuning changes may be necessary to reach the desired network size, they come at a considerable cost to the operator.
そのため、希望するネットワークサイズに到達するにはチューニングの変更が必要になる場合がありますが、オペレーターにはかなりのコストがかかります。
An alternative to the two-layer hierarchy presented in Section 6.1 is to provide a full mesh of FA LSPs between P(1) nodes. This technique is only of benefit to any nodes in the core of the level 1 network. It makes no difference to the PE and P(2) nodes since they continue to see only the PE-to-PE LSPs. Furthermore, this approach increases the burden at the P(1) nodes since they have to support all of the PE-to-PE LSPs as in the flat model plus the additional 2*(S(1) - 1) P(1)-to-P(1) FA LSPs. Thus, this approach should only be considered where there is a mesh of P-nodes within the ring of P(1) nodes, and is not considered further in this document.
セクション6.1に示されている2層階層の代わりに、P（1）ノード間のFA LSPの完全なメッシュを提供することです。この手法は、レベル1ネットワークのコアのノードにのみ利益があります。PE-To-PE LSPのみを見続けているため、PEおよびP（2）ノードに違いはありません。さらに、このアプローチは、フラットモデルと追加の2*（s（1）-1）p（1）のようにすべてのPE-pe LSPをサポートする必要があるため、p（1）ノードの負担を増加させます。-po-p（1）fa lsps。したがって、このアプローチは、p（1）ノードのリング内にpノードのメッシュがある場合にのみ考慮し、このドキュメントではさらに考慮されていません。
As demonstrated by Section 6.2, introducing a mesh of FA LSPs at the top level (P(1)) has no benefit, but if we introduce an additional level in the network (P(3) between P(2) and PE) to make a four-level snowflake, we can introduce a new layer of FA LSPs so that we have a full mesh of FA LSPs between all P(3) nodes to carry the PE-to-PE LSPs, and a full mesh of FA LSPs between all P(2) nodes to carry the P(3)-to-P(3) LSPs.
セクション6.2で示されているように、最上位レベルでFA LSPのメッシュを導入する（P（1））は利点はありませんが、ネットワークで追加レベルを導入すると（P（2）とPE）に追加のレベルを導入すると4レベルのスノーフレークを作成すると、すべてのP（3）ノードの間にFA LSPの完全なメッシュがPE-TO-PE LSPを運ぶように、FA LSPの新しい層を導入し、FA LSPの完全なメッシュを導入できます。すべてのp（2）ノード間で、p（3）-p（3）LSPを運ぶ。
The number of PEs is S(PE) = S(1)*M(1)*M(2)*M(3), and the number of PE-to-PE LSPs at a PE remains L(PE) = 2*(S(PE) - 1).
PESの数はS（PE）= S（1）*M（1）*M（2）*M（3）であり、PEでのPE-To-PE LSPの数はL（PE）= 2のままです*（S（PE）-1）。
The number of LSPs at a P(3) can be deduced from Section 6.1. It is the sum of all LSPs for all attached PEs, including the LSPs between the attached PE, plus the number of FA LSPs providing a mesh to the other P(3) nodes.
P（3）でのLSPの数は、セクション6.1から推測できます。これは、接続されたPE間のLSPを含む、付着したすべてのPEのすべてのLSPの合計に加えて、他のP（3）ノードにメッシュを提供するFA LSPの数です。
L(3) = M(3)*(2*S(PE) - M(3) - 1) + 2*(S(3) - 1)
The number of LSPs at P(2) can also be deduced from Section 6.1 since it is the sum of all LSPs for all attached P(3) nodes, including the LSPs between the attached PE plus the number of FA LSPs providing a mesh to the other P(2) nodes.
P（2）のLSPの数は、付着したP（3）ノードのすべてのLSPの合計であるため、セクション6.1から推測することもできます。他のp（2）ノード。
L(2) = M(2)*(2*S(3) - M(2) - 1) + 2*(S(2) - 1)
Finally, L(1) can be copied straight from 6.1.
最後に、L（1）は6.1から直接コピーできます。
L(1) = M(1)*(2*S(2) - M(1) - 1)
For example, with S(1) = 5, M(1) = 5, M(2) = 5, and M(3) = 8, we see:
たとえば、s（1）= 5、m（1）= 5、m（2）= 5、およびm（3）= 8では、次のように表示されます。
S(PE) = 1000
S(3) = 125
S(2) = 25
L(PE) = 1998
L(3) = 16176
L(2) = 1268
L(1) = 220
Similarly, with S(1) = 5, M(1) = 5, M(2) = 8, and M(3) = 10, we see:
同様に、s（1）= 5、m（1）= 5、m（2）= 8、およびm（3）= 10では、次のように表示されます。
S(PE) = 2000
S(3) = 200
S(2) = 25
L(PE) = 3998
L(3) = 40038
L(2) = 3184
L(1) = 220
Clearly, there are considerable scaling improvements with this three-layer hierarchy, and all of the numbers (even L(3) in the second example) are manageable.
明らかに、この3層階層ではかなりのスケーリングの改善があり、すべての数値（2番目の例のL（3）でさえ）が管理可能です。
Of course, the extra level in the network tends to reduce the cost-effectiveness of the networks with values of K = 1000/155 and K = 2000/230 (from 1000/55 and 2000/110) for the examples above. That is a reduction by a factor of 3 in the first case and 2 in the second case. Such a change in cost-effectiveness has to be weighed against the desire to deploy such a large network. If LSP hierarchies are the only scaling tool available, and networks this size are required, the cost-effectiveness may need to be sacrificed.
もちろん、ネットワーク内の追加レベルは、上記の例でK = 1000/155およびK = 2000/230（1000/55および2000/110から）の値を持つネットワークの費用対効果を低下させる傾向があります。これは、最初のケースでは3倍、2番目のケースでは2倍に削減されます。このような費用対効果の変化は、このような大きなネットワークを展開したいという欲求と比較検討する必要があります。LSP階層が利用可能な唯一のスケーリングツールであり、このサイズが必要なネットワークが必要な場合、費用対効果を犠牲にする必要がある場合があります。
A basic observation for hierarchical scaling techniques is that it is hard to have any impact on the number of LSPs that must be supported by the level of P(n) nodes adjacent to the PEs (for example, it is hard to reduce L(3) in Section 6.3). In fact, the only way we can change the number of LSPs supported by these nodes is to change the scaling ratio M(n) in the network -- in other words, to change the number of PEs subtended to any P(n). But such a change has a direct effect on the number of PEs in the network and so the cost-effectiveness is impacted.
階層的なスケーリング手法の基本的な観察は、PEに隣接するP（n）ノードのレベルによってサポートされなければならないLSPの数に影響を与えることが困難であることです（たとえば、Lを減らすことは困難です（3）セクション6.3）。実際、これらのノードでサポートされているLSPの数を変更できる唯一の方法は、ネットワークのスケーリング比M（n）を変更することです。つまり、PESの数をP（n）に変更することです。しかし、このような変更は、ネットワーク内のPEの数に直接的な影響を与えるため、費用対効果が影響を受けます。
Another concern with the hierarchical approach is that it must be configured and managed. This may not seem like a large burden, but it must be recalled that the P(n) nodes are not at the edge of the network -- they are a set of nodes that must be identified so that the FA LSPs can be configured and provisioned. Effectively, the operator must plan and construct a layered network with a ring of P(n) nodes giving access to the level (n) network. This design activity is open to considerable risk as failing to close the ring (i.e., allowing a node to be at both level (n+1) and at level (n)) may cause operational confusion.
階層的アプローチに関するもう1つの懸念は、それが構成および管理する必要があることです。これは大きな負担のようには見えないかもしれませんが、P（n）ノードがネットワークの端にないことを思い出す必要があります。それらは、FA LSPを構成できるように識別しなければならないノードのセットであり、プロビジョニング。事実上、オペレーターは、レベル（n）ネットワークへのアクセスを提供するP（n）ノードのリングを備えた階層ネットワークを計画および構築する必要があります。この設計アクティビティは、リングを閉じることができないため（つまり、ノードをレベル（n 1）とレベル（n）の両方で可能にすることができるため、かなりのリスクがあります。
Protocol techniques (such as IGP automesh [RFC4972]) have been developed to reduce the configuration necessary to build this type of multi-level network. In the case of automesh, the routing protocol is used to advertise the membership of a 'mesh group', and all members of the mesh group can discover each other and connect with LSP tunnels. Thus, the P(n) nodes giving access to level (n) can advertise their existence to each other, and it is not necessary to configure each with information about all of the others. Although this process can help to reduce the configuration overhead, it does not eliminate it, as each member of the mesh group must still be planned and configured for membership.
このタイプのマルチレベルネットワークを構築するために必要な構成を削減するために、プロトコル技術（IGP Automesh [RFC4972]など）が開発されました。Automeshの場合、ルーティングプロトコルを使用して「メッシュグループ」のメンバーシップを宣伝し、メッシュグループのすべてのメンバーが互いに発見し、LSPトンネルとつながることができます。したがって、レベル（n）へのアクセスを与えるP（n）ノードは、その存在を互いに宣伝することができ、他のすべてに関する情報をそれぞれに構成する必要はありません。このプロセスは、構成のオーバーヘッドを削減するのに役立ちますが、メッシュグループの各メンバーは、メンバーシップのために計画および構成する必要があるため、それを排除しません。
An important consideration for the use of hierarchical LSPs is how they can be protected using MPLS Fast Reroute (FRR) [RFC4090]. FRR may provide link protection either by protecting the tunnels as they traverse a broken link or by treating each level (n) tunnel LSP as a link in level (n+1) and providing protection for the level (n+1) LSPs (although in this model, fault detection and propagation time may be an issue). Node protection may be performed in a similar way, but protection of the first and last nodes of a hierarchical LSP is particularly difficult. Additionally, the whole notion of scaling with regard to FRR gives rise to separate concerns that are outside the scope of this document as currently formulated.
階層LSPの使用に関する重要な考慮事項は、MPLS Fast Reroute（FRR）[RFC4090]を使用してそれらを保護する方法です。FRRは、トンネルが壊れたリンクを横断するときにトンネルを保護するか、各レベル（n）トンネルLSPをレベルのリンクとして扱い、レベル（n 1）LSPの保護を提供することにより、リンク保護を提供する場合があります（ただし、これでモデル、障害検出、伝播時間が問題になる可能性があります）。ノード保護は同様の方法で実行される場合がありますが、階層LSPの最初と最後のノードの保護は特に困難です。さらに、FRRに関するスケーリングの概念全体は、現在策定されているこのドキュメントの範囲外にある個別の懸念を引き起こします。
Finally, observe that we have been explaining these techniques using conveniently symmetrical networks. Consider how we would arrange the hierarchical LSPs in a network where some PEs are connected closer to the center of the network than others.
最後に、便利な対称ネットワークを使用してこれらの手法を説明していることを観察します。一部のPESが他のPESよりもネットワークの中心に接続されているネットワーク内の階層LSPをどのように配置するかを検討してください。
In Section 6.2, we observed that there is no value to placing FA LSPs between the P(1) nodes of our example snowflake topologies. This is because those LSPs would be just one hop long and would, in fact, only serve to increase the burden at the P(1) nodes. However, in the ladder model, there is value to this approach. The P(1) nodes are the spar-nodes of the ladder, and they are not all mutually adjacent. That is, the P(1)-to-P(1) hierarchical LSPs can create a full mesh of P(1) nodes where one does not exist in the physical topology.
セクション6.2では、スノーフレークトポロジの例のp（1）ノードの間にfa lspを配置する価値がないことが観察されました。これは、これらのLSPが1つのホップに長く、実際、P（1）ノードの負担を増やすのに役立つためです。ただし、はしごモデルでは、このアプローチには価値があります。p（1）ノードはラダーのスパーノードであり、それらがすべて相互に隣接するわけではありません。つまり、P（1）-P（1）階層LSPは、物理トポロジに存在しないP（1）ノードの完全なメッシュを作成できます。
The number of LSPs seen by a P(1) node is then:
P（1）ノードで見られるLSPの数は次のとおりです。
o all of the tunnels terminating at the P(1) node, o any transit tunnels, and o all of the LSPs due to subtended PEs.
o P（1）ノードで終了するすべてのトンネル、o輸送トンネル、およびoは抑制されたPESによるすべてのLSPで終了します。
This is a substantial reduction; all of the transit LSPs are reduced to just one per remote P(1) that causes any transit LSP. So:
これは大幅な削減です。すべてのトランジットLSPは、トランジットLSPを引き起こすリモートP（1）ごとに1つのみに削減されます。それで：
L(1) = 2*(S(1) - 1) +
O(S(1)*S(1)/2) +
2*E*E*(S(1) - 1) + E*(E-1) - E*(M(2) - 1)
where O(S(1)*S(1)/2) gives an upper bound order of magnitude. So:
ここで、o（s（1）*s（1）/2）は上限の大きさを示します。それで：
L(1) = S(1)*S(1)/2 + 2*S(1) + 2*E*E*(S(1) - 1) - E*M(2) - 2
So, in our two examples:
だから、私たちの2つの例で：
With S(1) = 6, M(1) = 10, and M(2) = 17, we see:
s（1）= 6、m（1）= 10、およびm（2）= 17では、次のように表示されます。
E = 170
S(PE) = 1020
L(PE) = 2038
L(2) = 34374
L(1) = 286138
Alternatively, with S(1) = 10, M(1) = 10, and M(2) = 20, we see:
あるいは、S（1）= 10、M（1）= 10、およびM（2）= 20の場合、次のように表示されます。
E = 200
S(PE) = 2000
L(PE) = 3998
L(2) = 79580
L(1) = 716060
Both of these show significant improvements over the previous L(1) figures of 777410 and 2516000. But the numbers are still too large to manage, and there is no improvement in the L(2) figures.
これらは両方とも、777410および2516000の以前のL（1）の数値で大幅な改善を示しています。しかし、数値はまだ大きすぎて管理するには改善はありません。
We can also apply the three-layer hierarchy to the ladder model. In this case, the number of LSPs between P(1) nodes is not reduced, but tunnels are also set up between all P(2) nodes. Thus, the number of LSPs seen by a P(1) node is:
また、3層階層をはしごモデルに適用することもできます。この場合、p（1）ノード間のLSPの数は減少しませんが、すべてのp（2）ノードの間にトンネルもセットアップされます。したがって、P（1）ノードで見られるLSPの数は次のとおりです。
o all of the tunnels terminating at the P(1) node, o any transit tunnels between P(1) nodes, and o all of the LSPs due to subtended P(2) nodes.
o P（1）ノードで終了するすべてのトンネル、o P（1）ノードの間のトランジットトンネル、およびo細かいP（2）ノードのためにすべてのLSPの間のo。
No PE-to-PE LSPs are seen at the P(1) nodes.
P（1）ノードでは、PE-PE LSPは見られません。
L(1) = 2*(S(1) - 1) +
O(S(1)*S(1)/2) +
2*(S(1) - 1)*M(1)*M(1) + M(1)*(M(1) - 1)
where O(S(1)*S(1)/2) gives an upper bound order of magnitude. So:
ここで、o（s（1）*s（1）/2）は上限の大きさを示します。それで：
L(1) = S(1)*S(1)/2 + 2*S(1) + 2*M(1)*M(1)*S(1) - M(1)(M(1) + 1) - 2
Unfortunately, there is a small increase in the number of LSPs seen by the P(2) nodes. Each P(2) now sees all of the PE-to-PE LSPs that it saw before and is also an end-point for a set of P(2)-to-P(2) tunnels. Thus, L(2) increases to:
残念ながら、P（2）ノードで見られるLSPの数はわずかに増加しています。各P（2）は、以前に見たすべてのPE-ToPE LSPを見ており、P（2）-P（2）トンネルのセットのエンドポイントでもあります。したがって、l（2）は次のように増加します。
L(2) = 2*M(2)*(S(PE) - 1) - M(2)*(M(2) - 1) + 2*(S(1)*M(1) - 1)
So, in our two examples:
だから、私たちの2つの例で：
With S(1) = 6, M(1) = 10, and M(2) = 17, we see:
s（1）= 6、m（1）= 10、およびm（2）= 17では、次のように表示されます。
E = 170
S(PE) = 1020
L(PE) = 2038
L(2) = 34492
L(1) = 1118
Alternatively, with S(1) = 10, M(1) = 10, and M(2) = 20, we see:
あるいは、S（1）= 10、M（1）= 10、およびM（2）= 20の場合、次のように表示されます。
E = 200
S(PE) = 2000
L(PE) = 3998
L(2) = 79778
L(1) = 1958
This represents a very dramatic decrease in LSPs across the core.
これは、コア全体のLSPの非常に劇的な減少を表しています。
The same issues exist for hierarchical LSPs as described in Section 6.4. Although dramatic improvements can be made to the scaling numbers for the number of LSPs at core nodes, this can only be done at the cost of configuring P(2) to P(2) tunnels. The mesh of P(1) tunnels is not enough.
セクション6.4で説明されているように、階層LSPについても同じ問題が存在します。コアノードでのLSPの数のスケーリング数の劇的な改善を行うことができますが、これはP（2）をP（2）トンネルに設定するコストでのみ行うことができます。P（1）トンネルのメッシュでは十分ではありません。
But the sheer number of P(2) to P(2) tunnels that must be configured is a significant management burden that can only be eased by using a technique like automesh [RFC4972].
しかし、構成する必要があるP（2）からP（2）のトンネルの数は、Automesh [RFC4972]のような手法を使用することによってのみ緩和できる重要な管理負担です。
It is significant, however, that the scaling problem at the P(2) nodes cannot be improved by using tunnels and that the only solution to ease this in the hierarchical approach would be to institute another layer of hierarchy (that is, P(3) nodes) between the P(2) nodes and the PEs. This is, of course, a significant expense.
ただし、トンネルを使用してP（2）ノードでのスケーリングの問題を改善できず、階層的アプローチでこれを容易にする唯一のソリューションは、階層の別の層を制定することであることが重要です（つまり、P（3））ノード）p（2）ノードとPESの間。もちろん、これは多額の費用です。
An alternative (or complementary) scaling technique has been proposed using multipoint-to-point (MP2P) LSPs. The fundamental improvement in this case is achieved by reducing the number of LSPs toward the destination as LSPs toward the same destination are merged.
マルチポイントツーポイント（MP2P）LSPを使用して、代替の（または補完的な）スケーリング手法が提案されています。この場合の根本的な改善は、同じ宛先に向かってLSPがマージされているため、宛先に向かってLSPの数を減らすことで達成されます。
This section presents an overview of MP2P LSPs and describes their applicability and scaling benefits.
このセクションでは、MP2P LSPの概要を示し、それらの適用性とスケーリングの利点について説明します。
Note that the MP2P LSPs discussed here are for MPLS-TE and are not the same concept familiar in the Label Distribution Protocol (LDP) described in [RFC5036].
ここで説明するMP2P LSPはMPLS-TEのものであり、[RFC5036]で説明されているラベル分布プロトコル（LDP）で馴染みのある概念ではないことに注意してください。
Traffic flows generally converge toward their destination and this can be utilized by MPLS in constructing an MP2P LSP. With such an LSP, the Label Forwarding Information Base (LFIB) mappings at each LSR are many-to-one so that multiple pairs {incoming interface, incoming label} are mapped to a single pair {outgoing interface, outgoing label}. Obviously, if per-platform labels are used, this mapping may be optimized within an implementation.
一般に、トラフィックフローは目的地に向かって収束し、これはMPLSがMP2P LSPを構築する際に使用できます。このようなLSPを使用すると、各LSRのラベル転送情報ベース（LFIB）マッピングは多目的であるため、複数のペア{着信インターフェイス、着信ラベル}が単一のペア{発信インターフェイス、発信ラベル}にマッピングされます。明らかに、プラットフォームごとのラベルを使用する場合、このマッピングは実装内で最適化される場合があります。
It is important to note that with MP2P MPLS-TE LSPs, the traffic flows are merged. That is, some additional form of identifier is required if de-merging is required. For example, if the payload is IP traffic belonging to the same client network, no additional de-merging information is required since the IP packet contains sufficient data. On the other hand, if the data comes, for example, from a variety of VPN client networks, then the flows will need to be labeled in their own right as point-to-point (P2P) flows, so that traffic can be disambiguated at the egress of the MP2P LSPs.
MP2P MPLS-TE LSPでは、トラフィックフローがマージされていることに注意することが重要です。つまり、脱マルジングが必要な場合は、追加の識別子が必要です。たとえば、ペイロードが同じクライアントネットワークに属するIPトラフィックである場合、IPパケットには十分なデータが含まれているため、追加の除去情報は必要ありません。一方、たとえば、さまざまなVPNクライアントネットワークからデータが来る場合、流れはポイントツーポイント（P2P）フローとして独自の権利をラベル付けする必要があります。MP2P LSPの出口で。
Techniques for establishing MP2P MPLS-TE LSPs and for assigning the correct bandwidth downstream of LSP merge points are out of the scope of this document.
MP2P MPLS-TE LSPを確立し、LSPマージポイントの下流の正しい帯域幅を割り当てるための手法は、このドキュメントの範囲外です。
Consider the network topology shown in Figure 3. Suppose that we establish MP2P LSP tunnels such that there is one tunnel terminating at each PE, and that that tunnel has every other PE as an ingress. Thus, a PE-to-PE MP2P LSP tunnel would have S(PE)-1 ingresses and one egress, and there would be S(PE) such tunnels.
図3に示すネットワークトポロジを考えてみましょう。MP2PLSPトンネルを確立して、各PEに1つのトンネルが終了し、そのトンネルが他のすべてのPEを侵入として持っていると仮定します。したがって、PE-To-PE MP2P LSPトンネルにはS（PE）-1侵入と1つの出口があり、そのようなトンネルがあります。
Note that there still remain 2*(S(PE) - 1) PE-to-PE P2P LSPs that are carried through these tunnels.
これらのトンネルを通して運ばれる2*（S（PE）-1）PE-TO-PE P2P LSPがまだ残っていることに注意してください。
Let's consider the number of LSPs handled at each node in the network.
ネットワーク内の各ノードで処理されるLSPの数を考えてみましょう。
The PEs continue to handle the same number of PE-to-PE P2P LSPs, and must also handle the MP2P LSPs. So:
PEは引き続き同じ数のPE-PE P2P LSPを処理し、MP2P LSPを処理する必要があります。それで：
L(PE) = 2*(S(PE) - 1) + S(PE)
But all P(n) nodes in the network only handle the MP2P LSP tunnels. Nominally, this means that L(n) = S(PE) for all values of n. This would appear to be a great success with the number of LSPs cut to completely manageable levels.
ただし、ネットワーク内のすべてのP（n）ノードは、MP2P LSPトンネルのみを処理します。名目上、これはnのすべての値に対してl（n）= s（pe）を意味します。これは、完全に管理可能なレベルにカットされたLSPの数で大きな成功のように思われます。
However, the number of LSPs is not the only issue (although it may have some impact for some of the scaling concerns listed in Section 4). We are more interested in the amount of LSP state that is maintained by an LSR. This reflects the amount of storage required at the LSR, the amount of protocol processing, and the amount of information that needs to be managed.
ただし、LSPの数だけが問題ではありません（ただし、セクション4にリストされているスケーリングの懸念の一部に何らかの影響を与える可能性があります）。私たちは、LSRによって維持されているLSP状態の量にもっと興味があります。これは、LSRに必要なストレージの量、プロトコル処理の量、および管理する必要がある情報の量を反映しています。
In fact, we were also interested in this measure of scalability in the earlier sections of this document, but in those cases we could see a direct correlation between the number of LSPs and the amount of LSP state since transit LSPs had two pieces of state information (one on the incoming and one on the outgoing interface), and ingress or egress LSPs had just one piece of state.
実際、このドキュメントの以前のセクションでのこのスケーラビリティの尺度にも興味がありましたが、そのような場合、Transit LSPが2つの状態情報を持っていたため、LSPの数とLSP状態の量との間に直接的な相関があることがわかりました。（1つは着信に、もう1つは発信インターフェイスに1つ）、およびIngressまたは出力LSPには、1つの状態しかありませんでした。
We can quantify the amount of LSP state according to the number of LSP segments managed by an LSR. So (as above), in the case of a P2P LSP, an ingress or egress has one segment to maintain, while a transit has two segments. Similarly, for an MP2P LSP, an LSR must maintain one set of state information for each upstream segment (which, we can assume, is in a one-to-one relationship with the number of upstream neighbors) and exactly one downstream segment -- ingresses obviously have no upstream neighbors, and egresses have no downstream segments.
LSRが管理するLSPセグメントの数に従って、LSP状態の量を定量化できます。したがって、（上記のように）P2P LSPの場合、侵入または出口には維持するセグメントが1つありますが、トランジットには2つのセグメントがあります。同様に、MP2P LSPの場合、LSRは各上流セグメントの1つの状態情報セットを維持する必要があります（これは、上流の隣人の数と1対1の関係にあると仮定します）。侵入には明らかに上流の隣人がなく、出口には下流のセグメントもありません。
So we can start again on our examination of the scaling properties of MP2P LSPs using X(n) to represent the amount of LSP state held at each P(n) node.
そのため、各P（n）ノードで保持されているLSP状態の量を表すために、x（n）を使用してMP2P LSPのスケーリング特性の調査から再び開始できます。
At the PEs, there is only connectivity to one other network node: the P(2) node. But note that if P2P LSPs need to be used to allow disambiguation of data at the MP2P LSP egresses, then these P2P LSPs are tunneled within the MP2P LSPs. So X(PE) is:
PESでは、他の1つのネットワークノードへの接続のみがあります：P（2）ノード。ただし、P2P LSPを使用してMP2P LSP脱出でデータの曖昧性を掘り下げることを許可する必要がある場合、これらのP2P LSPはMP2P LSP内でトンネル化されることに注意してください。したがって、x（pe）は次のとおりです。
X(PE) = 2*(S(PE) - 1) if no disambiguation is required,
x（pe）= 2*（s（pe）-1）曖昧性を除去しない場合、
and
と
X(PE) = 4*(S(PE) - 1) if disambiguation is required.
x（pe）= 4*（s（pe）-1）乱縮が必要な場合。
Each P(2) node has M(2) downstream PEs. The P(2) sees a single MP2P LSP targeted at each downstream PE with one downstream segment (to that PE) and M(2) - 1 upstream segments from the other subtended PEs. Additionally, each of these LSPs has an upstream segment from the one upstream P(1). This gives a total of M(2)*(1 + M(2)) LSP segments.
各p（2）ノードには、m（2）下流pesがあります。P（2）は、1つのダウンストリームセグメント（そのPE）とM（2）-1の上流セグメントを、他のサブテンデッドPEからM（2）-1の下流PEで標的とする単一のMP2P LSPを見ます。さらに、これらの各LSPには、1つの上流のP（1）の上流セグメントがあります。これにより、合計M（2）*（1 m（2））LSPセグメントが得られます。
There are also LSPs running from the subtended PEs to every other PE in the network. There are S(PE) - M(2) such PEs, and the P(2) sees one upstream segment for each of these from each subtended PE. It also has one downstream segment for each of these LSPs. This gives (M(2) + 1)*(S(PE) - M(2)) LSP segments.
また、ネットワーク内の他のすべてのPEまで、Subtended PESから実行されているLSPもあります。S（PE）-M（2）そのようなPESがあり、P（2）は、各サブテン付きPEからこれらのそれぞれに1つの上流セグメントを見ます。また、これらのLSPのそれぞれに1つの下流セグメントがあります。これにより、（M（2）1）*（S（PE）-M（2））LSPセグメントが得られます。
Thus:
したがって：
X(2) = M(2)*(1 + M(2)) + (M(2) + 1)*(S(PE) - M(2))
= S(PE)*(M(2) + 1)
Similarly, at each P(1) node there are M(1) downstream P(2) nodes and so a total of M(1)*M(2) downstream PEs. Each P(1) is connected in a full mesh with the other P(1) nodes and so has (S(1) - 1) neighbors.
同様に、各p（1）ノードには、m（1）下流のp（2）ノードがあり、合計m（1）*m（2）下流pesがあります。各p（1）は、他のp（1）ノードと完全なメッシュで接続されているため、（s（1）-1）隣接があります。
The P(1) sees a single MP2P LSP targeted at each downstream PE. This has one downstream segment (to the P(2) to which the PE is connected) and M(1) - 1 upstream segments from the other subtended P(2) nodes. Additionally, each of these LSPs has an upstream segment from each of the P(1) neighbors. This gives a total number of LSP segments of M(1)*M(2)*(M(1) + S(1) - 1).
P（1）は、各下流のPEを標的とする単一のMP2P LSPを見ます。これには、1つの下流セグメント（PEが接続されているP（2））と、他のサブテンドP（2）ノードからのM（1）-1アップストリームセグメントがあります。さらに、これらのLSPのそれぞれには、各P（1）の隣接から上流のセグメントがあります。これにより、m（1）*m（2）*（m（1）s（1）-1）のlspセグメントの総数が得られます。
There are also LSPs running from each of the subtended PEs to every other PE in the network. There are S(PE) - M(1)M(2) such PEs, and the P(1) sees one upstream segment for each of these from each subtended P(2) (since the aggregation from the subtended PEs has already happened at the P(2) nodes). It also has one downstream segment to the appropriate next hop P(1) neighbor for each of these LSPs. This gives (M(1) + 1)*(S(PE) - M(1)*M(2)) LSP segments.
また、ネットワーク内の他のすべてのPEまで、各サブテン付きPESから実行されているLSPもあります。S（PE）-M（1）M（2）そのようなPESがあり、P（1）は各サブテンデッドP（2）からこれらのそれぞれに1つの上流セグメントを見ることができます（サブテン付きPESからの集約はすでに発生しているためP（2）ノード）。また、これらのLSPのそれぞれについて、適切な次のホップP（1）隣接に1つの下流セグメントがあります。これにより（M（1）1）*（S（PE）-M（1）*M（2））LSPセグメントが得られます。
Thus:
したがって：
X(1) = M(1)*M(2)*(M(1) + S(1) - 1) +
(M(1) + 1)*(S(PE) - M(1)*M(2))
= M(1)*M(2)*(S(1) - 2) + S(PE)*(M(1) + 1)
So, for example, with S(1) = 10, M(1) = 10, and M(2) = 10, we see:
したがって、たとえば、s（1）= 10、m（1）= 10、およびm（2）= 10では、次のように表示されます。
S(PE) = 1000
S(2) = 100
X(PE) = 3996 (or 1998)
X(2) = 11000
X(1) = 11800
And similarly, with S(1) = 20, M(1) = 20, and M(2) = 5, we see:
同様に、s（1）= 20、m（1）= 20、およびm（2）= 5では、次のように表示されます。
S(PE) = 2000
S(2) = 400
X(PE) = 5996 (or 2998)
X(2) = 12000
X(1) = 39800
For comparison with the examples in Sections 5 and 6, we need to convert those LSP-based figures to our new measure of LSP state.
セクション5および6の例と比較するには、これらのLSPベースの数値をLSP状態の新しい尺度に変換する必要があります。
Observe that each LSP in Sections 5 and 6 generates two state units at a transit LSR and one at an ingress or egress. So we can provide conversions as follows:
セクション5および6の各LSPは、トランジットLSRで2つの状態ユニットを生成し、1つは入り口または出口で生成することを確認してください。したがって、次のように変換を提供できます。
Section 5 (flat snowflake network)
セクション5（フラットスノーフレークネットワーク）
L(PE) = 2*(S(PE) - 1)
L(2) = M(2)*(2*S(PE) - M(2) - 1)
L(1) = M(1)*M(2)*(2*S(PE) - M(2)*(M(1) + 1))
X(PE) = 2*(S(PE) - 1)
X(2) = 2*M(2)*(2*S(PE) - M(2) - 1)
X(1) = 2*M(1)*M(2)*(2*S(PE) - M(2)*(M(1) + 1))
For the example with S(1) = 10, M(1) = 10, and M(2) = 10, this gives a comparison table as follows:
s（1）= 10、m（1）= 10、およびm（2）= 10の例では、次のような比較表が得られます。
Count | Unmodified | MP2P
------+-------------+----------
X(PE) | 1998 | 3996
X(2) | 39780 | 11000
X(1) | 378000 | 11800
Clearly, this technique is a significant improvement over the flat network within the core of the network, although the PEs are more heavily stressed if disambiguation is required.
明らかに、この手法は、ネットワークのコア内のフラットネットワークよりも大幅な改善ですが、曖昧性を除去する必要がある場合はPESがより重くストレスを受けています。
Section 6.1 (two-layer hierarchy snowflake network)
セクション6.1（2層階層スノーフレークネットワーク）
L(PE) = 2*(S(PE) - 1)
L(2) = M(2)*(2*S(PE) - M(2) - 1) + 2*(S(2) - 1)
L(1) = M(1)*(2*S(2) - M(1) - 1)
X(PE) = 2*(S(PE) - 1)
X(2) = 2*M(2)*(2*S(PE) - M(2) - 1) + 2*(S(2) - 1)
X(1) = 2*M(1)*(2*S(2) - M(1) - 1)
Note that in the computation of X(2) the hierarchical LSPs only add one state at each P(2) node.
x（2）の計算では、階層LSPが各p（2）ノードに1つの状態のみを追加することに注意してください。
For the same example with S(1) = 10, M(1) = 10, and M(2) = 10, this gives a comparison table as follows:
s（1）= 10、m（1）= 10、およびm（2）= 10の同じ例では、次のような比較表が得られます。
Count | 2-Layer | MP2P
| Hierarchy |
------+-------------+----------
X(PE) | 1998 | 3996
X(2) | 39978 | 11000
X(1) | 3780 | 11800
We can observe that the MP2P model is better at P(2), but the hierarchical model is better at P(1).
MP2PモデルはP（2）で優れていることを観察できますが、階層モデルはP（1）で優れています。
In fact, this comparison can be generalized to observe that the MP2P model produces its best effects toward the edge of the network, while the hierarchical model makes most impression at the core. However, the requirement for disambiguation of P2P LSPs tunneled within the MP2P LSPs does cause a double burden at the PEs.
実際、この比較を一般化して、MP2Pモデルがネットワークの端に向かって最良の効果を生み出し、階層モデルがコアで最も印象を与えることを観察することができます。ただし、MP2P LSP内でトンネルを起こしたP2P LSPの曖昧性を除去するための要件は、PESに二重の負担を引き起こします。
MP2P LSPs applied just within the ladder will not make a significant difference, but applying MP2P for all LSPs and at all nodes makes a very big difference without requiring any further configuration.
はしごの中に適用されるMP2P LSPは大きな違いはありませんが、すべてのLSPにMP2Pを適用すると、すべてのノードでそれ以上の構成を必要とせずに非常に大きな違いがあります。
LSP state at a spar-node may be divided into those LSPs' segments that enter or leave the spar-node due to subtended PEs (local LSP segments), and those that enter or leave the spar-node due to remote PEs (remote segments).
SPARノードのLSP状態は、サブテン付きPES（ローカルLSPセグメント）のためにSPARノードに入るまたは離れるLSPSのセグメントと、リモートPES（リモートセグメントのためにスパーノードに入るまたは出る）に分割される場合があります）。
The local segments may be counted as:
ローカルセグメントは次のようにカウントされる場合があります。
o E LSPs targeting local PEs o (S(1)-1)*E*M(1) LSPs targeting remote PEs
o ローカルPES O（S（1）-1）*E*M（1）リモートPEをターゲットとするLSP
The remote segments may be counted as:
リモートセグメントは、次のようにカウントされる場合があります。
o (S(1)-1)*E outgoing LSPs targeting remote PEs
o <= 3*S(1)*E incoming LSPs targeting any PE (there are precisely
P(1) nodes attached to any other P(1) node)
Hence, using X(1) as a measure of LSP state rather than a count of LSPs, we get:
したがって、LSPのカウントではなくLSP状態の尺度としてx（1）を使用すると、次のようになります。
X(1) <= E + (S(1)-1)*E*M(1) + (S(1)-1)*E + 3*S(1)*E
<= (4 + M(1))*S(1)*E - M(1)*E
The number of LSPs at the P(2) nodes is also improved. We may also count the LSP state in the same way so that there are:
P（2）ノードでのLSPの数も改善されています。また、LSP状態を同じように数えることができます。
o M(2) LSPs targeting local PEs, o M(2)*(S(1)*E) LSPs from local PEs to all other PEs, and o S(1)*E - M(2) LSPs to remote PEs.
o M（2）局所PE、o m（2）*（s（1）*e）局所PESから他のすべてのPESへのLSP、およびo s（1）*e -m（2）LSPをリモートPEに標的とするm（2）LSP。
So using X(2) as a measure of LSP state and not a count of LSPs, we have:
したがって、LSPのカウントではなく、LSP状態の尺度としてX（2）を使用して、次のようにしています。
X(2) = M(2) + M(2)*(S(1)*E) + S(1)*E - M(2)
= (M(2) + 1)*S(1)*E
Our examples from Section 5.2 give us the following numbers:
セクション5.2の例は、次の数字を示しています。
With S(1) = 6, M(1) = 10, and M(2) = 17, we see:
s（1）= 6、m（1）= 10、およびm（2）= 17では、次のように表示されます。
E = 170
S(PE) = 1020
X(PE) = 2038
X(2) = 18360
X(1) <= 12580
Alternatively, with S(1) = 10, M(1) = 10, and M(2) = 20, we see:
あるいは、S（1）= 10、M（1）= 10、およびM（2）= 20の場合、次のように表示されます。
E = 200
S(PE) = 2000
X(PE) = 3998
X(2) = 42000
X(1) <= 26000
The use of MP2P compares very favorably with all scaling scenarios. It is the only technique able to reduce the value of X(2), and it does this by a factor of almost two. The impact on X(1) is better than everything except the three-level hierarchy.
MP2Pの使用は、すべてのスケーリングシナリオと非常に好意的に比較されます。これは、x（2）の値を減らすことができる唯一の手法であり、これをほぼ2倍にします。X（1）への影響は、3レベルの階層を除くすべてよりも優れています。
The following table provides a quick cross-reference for the figures for the example ladder networks. Note that the previous figures are modified to provide counts of LSP state rather than LSP numbers. Again, each LSP contributes one state at its end points and two states at transit nodes.
次の表は、ラダーネットワークの例の図のクイック相互参照を示しています。以前の数値は、LSP数ではなくLSP状態のカウントを提供するように変更されていることに注意してください。繰り返しますが、各LSPは、そのエンドポイントで1つの状態と輸送ノードに2つの状態に寄与します。
Thus, for the all cases we have:
したがって、私たちが持っているすべてのケースについて：
X(PE) = 2*(S(PE) - 1) or X(PE) = 4*(S(PE) - 1) if disambiguation is required.
x（pe）= 2*（s（pe）-1）またはx（pe）= 4*（s（pe）-1）曖昧性を除去する必要がある場合。
In the unmodified (flat) case, we have:
変更されていない（フラット）ケースでは、次のようなものがあります。
X(2) = 2*(M(2)*(2*S(PE) - M(2) - 1))
X(1) = 2*(M(1)*M(2)*(2*S(PE) - M(2)*(M(1) + 1)))
In the two-level hierarchy, we have:
2レベルの階層には、次のことがあります。
X(2) = 2*(2*M(2)*(S(PE) - 1) - M(2)*(M(2) - 1))
X(1) = S(1)*S(1) + 2*S(1) + 4*E*E*(S(1) - 1) - 2*E*M(2) - 2
In the three-level hierarchy, we have:
3レベルの階層には、次のようになります。
X(2) = 2*(2*M(2)*(S(PE) - 1) - M(2)*(M(2) - 1)) + 2*(S(1)*M(1) - 1)
X(1) = S(1)*S(1) + 2*S(1) + 4*M(1)*M(1)*S(1) - 2*M(1)(M(1) + 1) - 2
Example A: S(1) = 6, M(1) = 10, and M(2) = 17
Example B: S(1) = 10, M(1) = 10, and M(2) = 20
Example| Count | Unmodified | 2-Level | 3-Level | MP2P
| | | Hierarchy | Hierarchy |
-------+-------+------------+------------+-------------+-------
A | X(2) | 68748 | 68748 | 68866 | 18360
| X(1) | 1554820 | 572266 | 2226 | 12580
-------+-------+------------+------------+-------------+-------
B | X(2) | 159160 | 159160 | 159358 | 42000
| X(1) | 5032000 | 1433998 | 3898 | 26000
Recall that in Section 8.3, the true benefit of MP2P was analyzed with respect to the LSP segment state required, rather than the actual number of LSPs. This proved to be a more accurate comparison of the techniques because the MP2P LSPs require state on each branch of the LSP, so the saving is not linear with the reduced number of LSPs.
セクション8.3では、実際のLSPの数ではなく、必要なLSPセグメント状態に関してMP2Pの真の利点が分析されたことを思い出してください。これは、MP2P LSPがLSPの各ブランチで状態を必要とするため、技術のより正確な比較であることが判明したため、LSPの数が減少して保存は線形ではありません。
A similar analysis could be performed here for the ladder network. The net effect is that it increases the state by an order of two for all transit LSPs in the P2P models, and by a multiplier equal to the degree of a node in the MP2P model.
ここでは、Ladder Networkについても同様の分析を実行できます。最終的な効果は、P2PモデルのすべてのトランジットLSPに対して2つのオーダー、およびMP2Pモデルのノードの程度に等しい乗数によって状態を増加させることです。
A rough estimate shows that, as with snowflake networks, MP2P provides better scaling than the one-level hierarchical model and is considerably better at the core. But MP2P compares less will with the two-level hierarchy especially in the core.
大まかな推定では、Snowflake Networksと同様に、MP2Pは1レベルの階層モデルよりも優れたスケーリングを提供し、コアでかなり優れていることが示されています。しかし、MP2Pは、特にコアの2レベルの階層との意志が少ないと比較されます。
The biggest challenges for MP2P LSPs are the provision of support in the control and data planes. To some extent, support must also be provided in the management plane.
MP2P LSPの最大の課題は、コントロールおよびデータプレーンでのサポートの提供です。ある程度、管理面でもサポートを提供する必要があります。
Control plane support is just a matter of defining the protocols and procedures [MP2P-RSVP], although it must be clearly understood that this will introduce some complexity to the control plane.
コントロールプレーンのサポートは、プロトコルと手順[MP2P-RSVP]を定義するだけの問題ですが、これにより制御プレーンに複雑さが導入されることは明確に理解する必要があります。
Hardware issues may be a little more tricky. For example, the capacity of the upstream segments must never (allowing for statistical over-subscription) exceed the capacity of the downstream segment. Similarly, data planes must be equipped with sufficient buffers to handle incoming packet collisions.
ハードウェアの問題はもう少し難しいかもしれません。たとえば、上流のセグメントの容量は、（統計的過剰サブスクリプションを許可することで）ダウンストリームセグメントの容量を超えてはなりません。同様に、データプレーンには、着信パケット衝突を処理するのに十分なバッファを装備する必要があります。
The management plane will be impacted in several ways. Firstly, the management applications will need to handle LSPs with multiple senders. This means that, although the applications need to process fewer LSPs, they will be more complicated and will, in fact, need to process the same number of ingresses and egresses. Other issues like diagnostics and OAM would also need to be enhanced to support MP2P, but might be borrowed heavily from LDP networks.
管理プレーンはいくつかの方法で影響を受けます。まず、管理アプリケーションは、複数の送信者を使用してLSPを処理する必要があります。これは、アプリケーションがLSPを減らす必要があるが、より複雑になり、実際には同じ数の入り口と出口を処理する必要があることを意味します。診断やOAMなどの他の問題も、MP2Pをサポートするために強化する必要がありますが、LDPネットワークから頻繁に借用される可能性があります。
Lastly, note that when the MP2P solution is used, the receiver (the single egress PE of an MP2P tunnel) cannot use the incoming label as an indicator of the source of the data. Contrast this with P2P LSPs. Depending on deployment, this might not be an issue since the PE-PE connectivity may in any case be a tunnel with inner labels to discriminate the data flows.
最後に、MP2Pソリューションを使用する場合、受信機（MP2Pトンネルの単一出力PE）は、入っているラベルをデータのソースの指標として使用できないことに注意してください。これをP2P LSPとは対照的です。展開に応じて、PE-PE接続性はいずれにせよ、データフローを差別するための内部ラベルを持つトンネルである可能性があるため、これは問題ではない可能性があります。
In other deployments, it may be considered necessary to include additional PE-PE P2P LSPs and tunnel these through the MP2P LSPs. This would require the PEs to support twice as many LSPs. Since PEs are not usually as fully specified as P-routers, this may cause some concern; however, the use of penultimate hop popping on the MP2P LSPs might help to reduce this issue.
他の展開では、追加のPE-PE P2P LSPを含め、MP2P LSPを介してこれらをトンネルする必要があると考える場合があります。これには、PESが2倍のLSPをサポートする必要があります。PESは通常、Pルーターほど完全に指定されていないため、これは懸念を引き起こす可能性があります。ただし、MP2P LSPで最後から2番目のホップを使用することは、この問題を軽減するのに役立つかもしれません。
In all cases, care must be taken not to confuse the reduction in the number of LSPs with a reduction in the LSP state that is required. In fact, the discussion in Section 8.3 is slightly optimistic since LSP state toward the destination will probably need to include sender information and so will increase depending on the number of senders for the MP2P LSP. Section 8.4, on the other hand, counts LSP state rather than LSPs. This issue is clearly dependent on the protocol solution for MP2P RSVP-TE, which is out of scope for this document.
すべての場合において、LSPの数の減少を必要とするLSP状態の減少と混同しないように注意する必要があります。実際、セクション8.3の議論は、目的地に向かってLSP状態を送信者情報を含める必要があるため、MP2P LSPの送信者の数に応じて増加するため、セクション8.3の議論はわずかに楽観的です。一方、セクション8.4は、LSPではなくLSP状態をカウントします。この問題は、このドキュメントの範囲外であるMP2P RSVP-TEのプロトコルソリューションに明らかに依存しています。
MPLS Fast Reroute (FRR) [RFC4090] is an attractive scheme for providing rapid local protection from node or link failures. Such a scheme has, however, not been designed for MP2P at the time of writing, so it remains to be seen how practical it could be, especially in the case of the failure of a merge node. Initial examination of this case suggests that FRR would not be a problem for MP2P, given that each flow can be handled separately.
MPLS Fast Reroute（FRR）[RFC4090]は、ノードまたはリンク障害からの迅速な局所保護を提供するための魅力的なスキームです。ただし、このようなスキームは、執筆時点ではMP2P向けに設計されていないため、特にマージノードの障害の場合、それがどれほど実用的であるかがわかりません。このケースの最初の調査は、各フローを個別に処理できることを考えると、FRRがMP2Pの問題ではないことを示唆しています。
As a final note, observe that the MP2P scenario presented in this document may be optimistic. MP2P LSP merging may be hard to achieve between LSPs with significantly different traffic and Quality of Service (QoS) parameters. Therefore, it may be necessary to increase the number of MP2P LSPs arriving at an egress.
最後のメモとして、このドキュメントに示されているMP2Pシナリオが楽観的である可能性があることに注意してください。MP2P LSPの合併は、大幅に異なるトラフィックとサービス品質（QOS）パラメーターを持つLSP間で達成するのが難しい場合があります。したがって、出口に到着するMP2P LSPの数を増やす必要がある場合があります。
There is nothing to prevent the combination of hierarchical and MP2P solutions within a network.
ネットワーク内の階層ソリューションとMP2Pソリューションの組み合わせを防ぐものは何もありません。
Note that if MP2P LSPs are tunneled through P2P FA LSPs across the core, none of the benefit of LSP merging is seen for the hops during which the MP2P LSPs are tunneled.
MP2P LSPがコアを越えてP2P FA LSPを介してトンネル化されている場合、MP2P LSPがトンネル化されるホップについてLSPマージの利点は見られないことに注意してください。
On the other hand, it is possible to construct solutions where MP2P FA LSPs are constructed within the network, resulting in savings from both modes of operation.
一方、ネットワーク内でMP2P FA LSPが構築されているソリューションを構築することができ、両方の操作モードから節約できます。
A simple solution to reducing the number of LSP tunnels handled by any node in the network has been proposed. In this solution it is observed that part of the problem is caused purely by the total number of LSP in the network, and that this is a function of the number of PEs since a full mesh of PE-PE LSPs is required. The conclusion of this observation is to move the tunnel end-points further into the network so that, instead of having a full mesh of PE-PE tunnels, we have only a full mesh of P(n)-P(n) tunnels.
ネットワーク内のノードによって処理されるLSPトンネルの数を減らすための簡単なソリューションが提案されています。このソリューションでは、問題の一部は純粋にネットワーク内のLSPの総数によって引き起こされ、これはPE-PE LSPの完全なメッシュが必要なためPES数の関数であることが観察されています。この観察結果の結論は、トンネルのエンドポイントをさらにネットワークに移動させることで、PE-PEトンネルの完全なメッシュを持つ代わりに、P（N）-P（N）トンネルの完全なメッシュしかありません。
Obviously, there is no change in the physical network topology, so the PEs remain subtended to the P(n) nodes, and the consequence is that there is no TE on the links between PEs and P(n) nodes.
明らかに、物理ネットワークトポロジに変化はないため、PESはP（n）ノードに依存したままであり、その結果、PESとP（N）ノードのリンクにTEがないことです。
In this case, we have already done the hard work for computing the number of LSPs in the previous sections. The power of the analysis in the earlier sections is demonstrated by its applicability to this new model -- all we need to do is make minor changes to the formulae. This is most simply done by removing a layer from the network. We introduce the term "tunnel end-point" (TEP) and replace the P(n) nodes with TEPs. Thus, the example of a flat snowflake network in Figure 3 becomes as shown in Figure 7. Corresponding changes can be made to all of the sample topologies.
この場合、前のセクションでLSPの数を計算するために努力を既に行っています。以前のセクションでの分析の力は、この新しいモデルへの適用性によって実証されています。私たちがする必要があるのは、式に軽微な変更を加えることです。これは、ネットワークからレイヤーを削除することで最も簡単に行われます。「トンネルエンドポイント」（TEP）という用語を導入し、P（N）ノードをTEPSに置き換えます。したがって、図3のフラットスノーフレークネットワークの例は、図7に示すように、すべてのサンプルトポロジーに対応する変更を加えることができます。
PE PE PE PE PE PE
\ \/ \/ /
PE--TEP TEP TEP TEP--PE
\ | | /
\| |/
PE--TEP---P(1)------P(1)---TEP--PE
/ \ / \
PE \ / PE
\/
P(1)
/|\
/ | \
/ | \
PE--TEP TEP TEP--PE
/ /\ \
PE PE PE PE
Figure 7 : An Example Snowflake Network with Tunnel End-Points
図7：トンネルエンドポイントを備えたスノーフレークネットワークの例
To perform the scaling calculations we need only replace the PE counts in the formulae with TEP counts, and observe that there is one fewer layer in the network. For example, in the flat snowflake network shown in Figure 7, we can see that the number of LSPs seen at a TEP is:
スケーリング計算を実行するには、式のPEカウントをTEPカウントに置き換えるだけで、ネットワーク内のレイヤーが1つ少ないことを観察します。たとえば、図7に示すフラットスノーフレークネットワークでは、TEPで見られるLSPの数は次のとおりです。
L(TEP) = 2*(S(TPE) - 1)
In our sample networks, S(TPE) is typically of the order of 50 or 100 (the original values of S(2)), so L(TEP) is less than 200, which is quite manageable.
サンプルネットワークでは、S（TPE）は通常50または100のオーダー（S（2）の元の値）のオーダーであるため、L（TEP）は200未満であり、非常に管理可能です。
Similarly, the number of LSPs handled by a P(1) node can be derived from the original formula for the number of LSPs seen at a P(2) node, since all we have done is reduce n in P(n) from 2 to 1. So our new formula is:
同様に、P（1）ノードによって処理されるLSPの数は、P（2）ノードで見られるLSPの数の元の式から導出できます。1.だから私たちの新しい式は次のとおりです。
L(1) = M(1)*(2*S(TEP) - M(1) - 1)
With figures for M(1) = 10 and S(TEP) = 100, this gives us L(1) = 1890. This is also very manageable.
M（1）= 10およびS（TEP）= 100の数値では、L（1）= 1890を与えます。これも非常に管理しやすいです。
On the face of it, this alternate solution seems very attractive. Simply by contracting the edges of the tunnels into the network, we have shown a dramatic reduction in the number of tunnels needed, and there is no requirement to apply any additional scaling techniques.
それに直面して、この代替ソリューションは非常に魅力的です。トンネルのエッジをネットワークに収縮させるだけで、必要なトンネルの数が劇的に減少したことを示しました。追加のスケーリング技術を適用する必要はありません。
But what of the PE-P(n) links? In the earlier sections of this document, we have assumed that there was some requirement for PE-PE LSPs with TE properties that extended to the PE-P(n) links at both ends of each LSP. That means that there was a requirement to provide reservation-based QoS on those links, to be able to discriminate traffic flows for priority-based treatment, and to be able to distinguish applications and sources that send data based on the LSPs that carry the data.
しかし、PE-P（n）リンクはどうですか？このドキュメントの以前のセクションでは、各LSPの両端のPE-P（n）リンクに拡張されたTEプロパティを備えたPE-PE LSPには、いくつかの要件があると想定しています。つまり、これらのリンクに予約ベースのQOを提供し、優先順位ベースの治療のためのトラフィックフローを区別し、データを運ぶLSPに基づいてデータを送信するアプリケーションとソースを区別できるようにするための要件があったことを意味します。。
It might be argued that, since the PE-P(n) links do not offer any routing options (each such link provides the only access to the network for a PE), most of the benefits of tunnels are lost on these peripheral links. However, TE is not just about routing. Just as important are the abilities to make resource reservations, to prioritize traffic, and to discriminate between traffic from different applications, customers, or VPNs.
PE-P（n）リンクはルーティングオプションを提供していないため（そのようなリンクごとにPEのネットワークへの唯一のアクセスを提供しないため）、トンネルの利点のほとんどはこれらの周辺リンクで失われていると主張されるかもしれません。ただし、TEはルーティングだけではありません。同様に重要なのは、リソースの予約を行い、トラフィックに優先順位を付け、さまざまなアプリケーション、顧客、またはVPNからのトラフィックを区別する能力です。
Furthermore, in multihoming scenarios where each PE is connected to more than one P(n) or where a PE has multiple links to a single P(n), there may be a desire to pre-select the link to be used and to direct the traffic to that link using a PE-PE LSP. Note that multihoming has not been considered in this document.
さらに、各PEが複数のp（n）に接続されているか、PEが単一のp（n）に複数のリンクを持っているマルチホームシナリオでは、使用するリンクを事前に選択し、指示することを望んでいる可能性がありますPE-PE LSPを使用したそのリンクへのトラフィック。このドキュメントでは、Multihomingが考慮されていないことに注意してください。
Operationally, P(n)-P(n) LSPs offer the additional management overhead that is seen for hierarchical LSPs described in Section 6. That is, the LSPs have to be configured and established through additional configuration or management operations that are not carried out at the PEs. As described in Section 6, automesh [RFC4972] could be used to ease this task. But it must be noted that, as mentioned above, some of the key uses of tunnels require that traffic is classified and placed in an appropriate tunnel according to its traffic class, end-points, originating application, and customer (such as client VPN). This information may not be readily available for each packet at the P(n) nodes since it is PE-based information. Of course, it is possible to conceive of techniques to make this information available, such as assigning a different label for each class of traffic, but this gives rise to the original problem of larger numbers of LSPs.
操作的に、P（N）-P（N）LSPは、セクション6で説明されている階層LSPに見られる追加の管理オーバーヘッドを提供します。つまり、LSPは実行されない追加の構成または管理操作を通じて構成および確立する必要があります。PESで。セクション6で説明されているように、このタスクを容易にするために、Automesh [RFC4972]を使用できます。ただし、上記のように、トンネルの重要な用途では、トラフィッククラス、エンドポイント、発信元のアプリケーション、および顧客（クライアントVPNなど）に従って、トラフィックを分類して適切なトンネルに配置する必要があることに注意する必要があります。。この情報は、PEベースの情報であるため、P（N）ノードの各パケットで容易に利用できない場合があります。もちろん、トラフィックのクラスごとに異なるラベルを割り当てるなど、この情報を利用可能にするための手法を考案することができますが、これにより、より多くのLSPの元の問題が生じます。
Our conclusion is, therefore, that this alternate technique may be suitable for the general distribution of traffic based solely on the destination, or on a combination of the destination and key fields carried in the IP header. In this case, it can provide a very satisfactory answer to the scaling issues in an MPLS-TE network. But if more sophisticated packet classification and discrimination is required, this technique will make the desired function hard to achieve, and the trade-off between scaling and feature-level will swing too far towards solving the scaling issue at the expense of delivery of function to the customer.
したがって、私たちの結論は、この代替手法は、目的地のみに基づいたトラフィックの一般的な配布、またはIPヘッダーに運ばれる宛先とキーフィールドの組み合わせに適している可能性があるということです。この場合、MPLS-TEネットワークのスケーリング問題に対する非常に満足のいく答えを提供できます。しかし、より洗練されたパケットの分類と差別が必要な場合、この手法により、望ましい関数を達成するのが難しくなり、スケーリングと機能レベルのトレードオフは、機能の提供を犠牲にしてスケーリングの問題を解決するためにあまりにも遠くになります。顧客。
The management issues of the models presented in this document have been discussed in-line. No one solution is without its management overhead.
このドキュメントで提示されたモデルの管理上の問題については、インラインで議論されています。管理オーバーヘッドがないソリューションはありません。
Note, however, that scalability of management tools is one of the motivators for this work and that network scaling solutions that reduce the active management of LSPs at the cost of additional effort to manage the more static elements of the network represent a benefit. That is, it is worth the additional effort to set up MP2P or FA LSPs if it means that the network can be scaled to a larger size without being constrained by the management tools.
ただし、管理ツールのスケーラビリティは、この作業の動機付けの1つであり、ネットワークのより静的な要素を管理するための追加の努力を犠牲にしてLSPのアクティブな管理を削減するネットワークスケーリングソリューションを表していることに注意してください。つまり、管理ツールに制約されずにネットワークをより大きなサイズにスケーリングできることを意味する場合、MP2PまたはFA LSPをセットアップするための追加の努力の価値があります。
The MP2P technique may prove harder to debug through OAM methods than the FA LSP approach.
MP2P手法は、FA LSPアプローチよりもOAMメソッドを介してデバッグするのが難しくなる可能性があります。
The techniques described in this document use existing or yet-to-be-defined signaling protocol extensions and are subject to the security provided by those extensions. Note that we are talking about tunneling techniques used within the network and that both approaches are vulnerable to the creation of bogus tunnels that deliver data to an egress or consume network resources.
このドキュメントで説明されている手法は、既存またはまだ定義されているシグナリングプロトコル拡張機能を使用し、それらの拡張機能によって提供されるセキュリティの対象となります。ネットワーク内で使用されているトンネリング技術について話していることに注意してください。両方のアプローチは、出口にデータを提供するか、ネットワークリソースを消費する偽のトンネルの作成に対して脆弱であることに注意してください。
The fact that the MP2P technique may prove harder to debug through OAM methods than the FA LSP approach is a security concern since it is important to be able to detect misconnections.
MP2P手法がFA LSPアプローチよりもOAMメソッドを介してデバッグするのが難しいことが証明される可能性があるという事実は、誤った接続を検出できることが重要であるため、セキュリティの懸念事項です。
General issues of the relationship between scaling and security are covered in Section 1.1, but the details are beyond the scope of this document. Readers are referred to [MPLS-SEC] for details of MPLS security techniques.
スケーリングとセキュリティの関係の一般的な問題はセクション1.1で説明されていますが、詳細はこのドキュメントの範囲を超えています。MPLSセキュリティ手法の詳細については、読者は[MPLS-SEC]に紹介されます。
The analysis in this document suggests that the ability to signal MP2P MPLS-TE LSPs is a desirable addition to the operator's MPLS-TE toolkit.
このドキュメントの分析は、MP2P MPLS-TE LSPをシグナルにする能力が、オペレーターのMPLS-TEツールキットに望ましい追加であることを示唆しています。
At this stage, no further recommendations are made, but it would be valuable to consult more widely to discover:
この段階では、それ以上の推奨事項は行われませんが、発見するためにより広く相談することは価値があります。
- The concerns of other service providers with respect to network scalability.
- ネットワークスケーラビリティに関する他のサービスプロバイダーの懸念。
- More opinions on the realistic constraints to the network parameters listed in Section 4.
- セクション4にリストされているネットワークパラメーターに対する現実的な制約に関するより多くの意見。
- Desirable values for the cost-effectiveness of the network (parameter K).
- ネットワークの費用対効果の望ましい値（パラメーターk）。
- The applicability, manageability, and support for the two techniques described.
- 説明されている2つの手法の適用性、管理可能性、およびサポート。
- The feasibility of combining the two techniques, as discussed in Section 9.
- セクション9で説明したように、2つの手法を組み合わせる可能性。
- The level of concern over the loss of functionality that would occur if the alternate solution described in Section 10 was adopted.
- セクション10で説明されている代替ソリューションが採用された場合に発生する機能の喪失に対する懸念のレベル。
The authors are grateful to Jean-Louis Le Roux for discussions and review input. Thanks to Ben Niven-Jenkins, JP Vasseur, Loa Andersson, Anders Gavler, Ben Campbell, and Tim Polk for their comments. Thanks to Dave Allen for useful discussion of the math.
著者は、議論とレビューの入力について、Jean-Louis Le Rouxに感謝しています。Ben Niven-Jenkins、JP Vasseur、Loa Andersson、Anders Gavler、Ben Campbell、Tim Polkのコメントに感謝します。数学の有益な議論をしてくれたデイブ・アレンに感謝します。
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206] Kompella、K。およびY. Rekhter、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）を備えたラベルスイッチ付きパス（LSP）階層」、2005年10月。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961] Berger、L.、Gan、D.、Swallow、G.、Pan、P.、Tommasi、F.、およびS. Molendini、「RSVP Refrend Overhead Recotion Extensions」、RFC 2961、2001年4月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、12月2001年。
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002.
[RFC3270] Le Faucheur、F.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、 "Multi-protocolラベルスイッチング（MPLS）差別化されたサービスのサポート」、RFC 3270、2002年5月。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC3985] Bryant、S.、ed。、およびP. Pate、ed。、「Pseudo Wire Emulation Edge-to-Edge（PWE3）アーキテクチャ」、RFC 3985、2005年3月。
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[RFC4090] Pan、P.、Ed。、Ed。、Swallow、G.、Ed。、およびA. Atlas、ed。、「LSP TunnelsのRSVP-TEへの拡張速度」、RFC 4090、2005年5月。
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3 Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4110, July 2005.
[RFC4110] Callon、R。およびM. Suzuki、「レイヤー3プロバイダーがプロビジョニングした仮想プライベートネットワーク（PPVPNS）のフレームワーク」、RFC 4110、2005年7月。
[RFC4972] Vasseur, JP., Ed., Leroux, JL., Ed., Yasukawa, S., Previdi, S., Psenak, P., and P. Mabbey, "Routing Extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership", RFC 4972, July 2007.
[RFC4972] Vasseur、JP。、ed。、Leroux、Jl。、ed。、Yasukawa、S.、Previdi、S.、Psenak、P.、およびP. Mabbey、「マルチプロトコルの発見のためのルーティング拡張（MPLS）ラベルスイッチルーター（LSR）トラフィックエンジニアリング（TE）メッシュメンバーシップ "、RFC 4972、2007年7月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、ed。、Minei、I.、ed。、およびB. Thomas、ed。、「LDP仕様」、RFC 5036、2007年10月。
[MP2P-RSVP] Yasukawa, Y., "Supporting Multipoint-to-Point Label Switched Paths in Multiprotocol Label Switching Traffic Engineering", Work in Progress, October 2008.
[MP2P-RSVP] Yasukawa、Y。、「マルチプロトコルラベルスイッチングトラフィックエンジニアリングのマルチポイントからポイントのラベルスイッチ付きパスをサポートする」、2008年10月、作業進行中。
[MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, November 2008.
[MPLS-SEC] Fang、L.、ed。、「MPLSおよびGMPLSネットワークのセキュリティフレームワーク」、2008年11月、Work in Progress。
Authors' Addresses
著者の住所
Seisho Yasukawa NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 4769 EMail: s.yasukawa@hco.ntt.co.jp
Seisho Yasukawa NTT Corporation 9-11、Midori-Cho 3-Chome Musashino-Shi、Tokyo 180-8585日本電話：81 422 59 4769メール：s.yasukawa@hco.ntt.co.jp
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
Adrian Farrel Old Dog Consultingメール：adrian@olddog.co.uk
Olufemi Komolafe Cisco Systems 96 Commercial Street Edinburgh EH6 6LX United Kingdom EMail: femi@cisco.com
Olufemi Komolafe Cisco Systems 96 Commercial Street Edinburgh EH6 6LX United Kingdom Email：femi@cisco.com