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
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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の）数のスケーリングの問題のいくつかの分析を提示し、スケーリングを改善するための二つの技術（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.
この文書では、二つの一般的なネットワークトポロジ（雪の結晶やはしご）を提示し、いくつかの一般論を行うことによってネットワークをパラメータ化しようとします。これは、異なるスケーリングパラメータのための用語を紹介し、ネットワークのコア内に運ばれるために必要となる場合がありますどのように多くの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.
二つの技術（階層の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.
高速リルート（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個の仮想プライベートネットワーク（VPN）[RFC4110]または疑似[RFC3985]のような）異なるサービスを提供することを理解すべきである[RFC3270]をもたらし得ます「重複」またはプロバイダエッジノードの任意の対の間に実行されている「平行」のLSP（PES）です。このスケーリング係数は、この文書では考慮されず、容易にリーダによる線形因子として適用することができます。
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のコアネットワークのためのスケーリングの問題のいくつかの分析を提示し、スケーリングを改善するための二つの技術の値を調べます。これは、大規模ネットワークにおける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のメモリ容量が限られているため、サポートすることができる数のLSP上に配置された関連する限界があります。
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は、一つ（先に向かって）下流セグメントと（複数のソースからの）複数のアップストリームセグメントのLSPの状態を維持する必要があるかもしれません。つまり、私たちが一つの隣接ノードへの一方向にLSPを維持するのに必要な状態としてLSPセグメントの状態を定義しています。
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の状態を維持するために、シグナリングネイバー間で交換されなければならないことを意味し、ソフトステートプロトコルです。リフレッシュメッセージの送信（および受信）のための共通の期間は、各LSRが送信し、各方向（上流および下流）それがサポートするすべてのLSPのために、30秒ごとに一つのメッセージを受信しなければならないことを意味し、30秒です。これは、ネットワークのスケーリングに重大な制約となる可能性がありますが、種々の改良は、[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はまた、シグナリング隣接ハローメッセージ交換の使用によって維持することが必要です。 [RFC3209]はHelloメッセージが5ms毎に再送する必要があることを示唆しているが、実際には、約3秒の値がより一般的です。一つのメッセージが各シグナリング隣接毎時間に/から送受信されなければならないので、それにもかかわらず、Helloメッセージのサポートは、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ネットワークのスケーラビリティのためのもう一つの現実的な懸念は、ネットワークを管理する機能です。これは、使用中に利用可能なツール、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）（又はごとLSR NMSによってサポートされる数）によってサポートできる数である可能性が高いです限られました。
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.
この文書で考慮スノーフレークトポロジは、コアネットワーク内の接続の階層構造に基づいています。 PE間の直接的な接続が存在しない図1に示すように、PEノードはP-ノードへの接続を有しています。それは、ネットワーク構成に貴重加えてもよいが、複数のP-ノードへのPEのデュアルホーミングは、本書では考慮されていません。
P
/|\
/ | \
/ | \
/ | \
PE PE PE
Figure 1 : PE to P-Node Connectivity
図1：P-ノード接続にPE
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）以上であるようなレベルに番号を付けます。我々は、P（n）とレベルnのPノードを表します。
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.
PEと同様に、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)).
我々は、Pの数（N + 1）のいずれかにP（N）に取り付けられたレベルのノード（N + 1）として乗算器M（n）を定義します。 M（n）はレベルnのすべてのノードに対して一定であると仮定する。同じレベルのノードは、（最上位レベル以外）相互接続、及び各P（N + 1）ノードが正確に1つのP（n）のノードに接続されているので、M（n）はの次数より1つ少ないされていないためレベルnのノード（つまり、P（n）のノードがMに取り付けられている（n）がノードレベルで（N + 1）とレベル1つのノード（N-1））。
We define S(n) as the number of nodes at level (n).
我々は、レベル（N）のノードの数として、S（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.
ネットワークは、P-ノード（N）層を有します。
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:
ラダーネットワークは、典型的には、従来の梯子として配置される細長いコアを有します。つまり、彼らはラングによって接続された一つ以上のスパーを持っています。スパー上の各ノードは、持っていることがあります。
- connection to one or more other spars, - connection to a tree of other core nodes, - connection to customer nodes.
- 一回の以上の他のスパーへの接続、 - 顧客ノードへの接続 - 他のコア・ノードのツリーへの接続。
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).
実際には、ないスパー（それらスパー-ノードを呼び出す）上のすべてのノードは、範囲が定められたのPEを持っている必要があります。すなわち、それらは他のスパー・ノードへ、又はラングを横切って別のスパーにスパーに沿って接続性を与えるために単に存在することができます。同様に、スパーとの間の接続は、別のスパーに1桁ノードからの複数の接続を有するより複雑であることができます。最後に、ネットワークは二つ以上のスパー（又は単一のスパーへの還元によって単純化）を含めることによって複雑にされてもよいです。
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.
- 各スパーノードは、いずれか一方（エンドスパー）または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.
- すべてのスパーノードは、範囲が定められたPEの同じ番号を持っています。これは、スパー・ノードに範囲を定めない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 - 各スパーノードに範囲を定められたエッジノード（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は、スノーフレークネットワーク用として処理することができます。つまり、我々は、PESであるP（N）までP（I）を介して、スパー・ノードであるP（1）ノードからアタッチメントのレベルの数を考慮することができます。実際に、我々は、N = 2（スパー・ノードに直接接続PES）およびn = 3（PESとスパー・ノード間の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-1）のノードへのP（I）ノードの割合とする、雪片トポロジについて定義したとおりPノードのレベルの間の接続。従って、任意のレベル（N）のノードの数です。
S(n) = S(1)*M(1)*M(2)*...*M(n-1)
So the number of PEs subtended to a spar-node is:
だから、PEの数はスパーノードにある範囲を定められました。
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）は、物理インターフェイスの限定された数をサポートすることができます。これは、必ずしも完全にメッシュネットワーク能力を低減し、PEの方へのネットワークのツリー構造につながります。
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.
オペレータのための現実的な商業の考慮事項は、ネットワーク内の唯一の収益源となるノードはのPEをしているという事実です。他のノードが接続性と拡張性をサポートするためにのみ必要です。したがって、（N）のすべての値に対してS（N）の和を最小にしながら、S（PE）を最大化することが望まれています。これは、M（n）は、レベルの数を最小限にし、各レイヤでの接続性を最大にすることによって達成することができます。最終的に、しかし、これは明らかに物理的なスケーリング状況と競合しているだけで相互接続されたPEのネットワークを、生成することになります。
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
K = S（PE）/（S（1）+ S（2）+ ... + N S（））nは上記のPEレベルであります
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.
我々は（ルータシャーシは、多くの場合、無料または低コストであるため）ネットワークのコストが実際にルータの数の関数ではないという点で、この式はナイーブであってもよいこと、しかし、確認したが、実際には、コストの関数である必要がありますそれ自体、ラインカードの容量との積であるラインカードの。ネットワークコアを介してデータをチャネルする傾向トポロジは高容量（したがって、より高価な）ラインカードを要求する傾向がある従って、比較的高い接続は、費用対効果を減少させます。
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つの対称と一般ネットワークトポロジを使用しています。実際には、他の二つの位相幾何学的考慮事項があります。
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）に接続することができるのPEで特に一般的です。
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。レベル内噛合ネットワーク内のレベルは、多くの場合、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?
この評価および分析のための重要な問題は、事業者が必要とするネットワークのサイズです。どのように多くのPEを必要としていますか？ PEへのPのどのような比率は許容できるでしょうか？デバイスは、物理的な接続のためにどのように多くのポートを持っていますか？ 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の各対は、各方向に少なくとも一つの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
1、2、およびPE：S（PE）> = 1000レベル番号は3です。 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を有しています。 LSP - S（PE）PEは、ネットワークに存在する場合したがって、S（PE）*（1 S（PE））があります。
Define L(n) as the number of LSPs handled by a level (n) LSR.
レベル（N）LSRによって処理LSPの数としてL（n）を定義します。
L(PE) = 2*(S(PE) - 1)
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を確立するので、S（PE）があることが予想される - 各PEとLSPの同じ番号への着信1つのLSPは2の合計与え、同一のPEから出射（S（PE）を - 1）入射リンク。したがって、スノーフレークトポロジ内（図3参照）、各P（2）ノードに取り付けられたM（2）のPEが存在するので、（2）L（2）（LSPの数は、各Pを通過することを考えるしたくてもよいですノード）単に2 *（S（PE）である - 1）* M（2）。しかし、S（PE）のことに留意すべきである - 各PE、M（2）に着信1つのLSP - 1は、同じP（2）ノードに接続されたノードから発信され、したがってこの値は間LSPを数えることになりますM（2）PEは2回P（2）ノードに取り付けられた：一度M（2）から出射するとき - 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）*（M（2） - 1）この値が誤って2 *で二回含まれているので、これらのM（2）PEと、（S（PE） - 1）の間のLSP * M（2 ）、正しい値です。
L(2) = 2*M(2)*(S(PE) - 1) - M(2)*(M(2) - 1) = M(2)*(2*S(PE) - M(2) - 1)
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）、各PEはPに範囲が定められたことを観察することである（2）ノードは、すべての各方向にLSPを有するS（PE） - M（2 ）システムの残りの部分でのPE、およびM（2）そのような局所的に範囲を定められたPEがあります。従って、2 * M（2）*（S（PE） - M（2））。局所的に範囲が定められたPE間のLSP - また、M（2）*（1 M（2））が存在します。そう：
L(2) = 2*M(2)*(S(PE) - M(2)) + M(2)*(M(2) - 1) = M(2)*(2*S(PE) - M(2) - 1)
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）L（2）のこの第二の評価と同様に計算することができます。各PEは、（1）ノードではないP（1）ノードの下のすべてのPEに各方向のLSPを有するPの下方範囲が定め。 M（1）* M（2 - M（1）* M P（1）ノードの下に（2）のPEので、これは2を占める* M（1）* M（2）*（S（PE）があります））のLSP。このように、我々は、P（1）ノードを通過するLSPの数とP（1）の下に範囲が定められたPE間、その実行を追加する必要があります。各Pを考える（2）：それは、M（2）PEの全てに行くLSPをそれぞれ有するPEは、P（1）に範囲が定められた他のP（2）ノードに範囲を定めました。 1このような他のP（2）ノード、及びそうM（2）*（M（1） - - 1）他のそのようなPEのM（1）があります。そうP（2）ノードの下のPEからのLSPの数がMである（2）* M（2）*（M（1） - 1）。 LSP - 及びM P以下（1）P（2）ノード（1）M（2）* M（2）* M（1）*（1 M（1））の合計を生じさせるがあります。したがって
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))
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
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
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.
両方の例では、コア（P（1））ノードにおけるLSPの数は、PESの比較的控えめな数があるにもかかわらず、おそらく許容できないほど大きいです。実際には、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)
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の一部の中継ノードであるので、しかし、（1）Lは、異なる計算を必要とします。
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によって排他的に配信することができるローカル接続のPE（2）ノード、O輸送中のローカル接続のPEとリモートのPE、及びOのLSPsの間のすべてのLSPを通過する間、これらのLSP P（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)
最初の3つの数字が容易に決定され、私たちは雪の結晶のネットワークから見てきたものと一致しています。それらは：O E *（E-1）、M（1）* M（2）*（M（2）-1）= E×（M（2） - 1）O 2 * Oイー・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の数は、計算がより複雑です。我々は、各コアリンク（標識A及びBを横断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を通過するよう、各LSPは、そうでない場合は二回カウントされますので、（1））、各P（1）LSPの一部を局所的にそう終了していることを除いて、唯一ある2A + B LSPの半分を見ていることがわかります一度和2A + Bに含まれます。
So L(1) = a + b/2 - (locally terminated transit LSPs)/2 + (locally contained LSPs)
なので L(1) = a + b/2 - (ローカルで終了したトランジットLSPs) / 2 + (ローカルで含まれる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のそれぞれの合計にはしごの上にホップ作るLSPのすべての貢献を考えてみましょう。はしごが無制限だったなら、私たちは、n個ある* 2Xのみスパーに沿ったLSP、およびN（N-1）* 2X / N = 2X（N-1）の場合にはLSPのラングを使用することを言うことができますそして、スパー。これにより、n作るLSPは寄与（4N-2）XのLSPに梯子にホップ。ラダーに一つだけのホップを作るの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:
そして同様に、無限のはしごにBを考慮すると、唯一のLSP上で1つのホップを旅行するLSPは、2X LSPを貢献し、特殊なケースであり、他のすべてのLSPのnを横断その梯子の上にホップ2X / N = 4XのLSP * 2N貢献しています。そう：
R+1
b = 2X + SUM[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です。だから我々はのためのスパーのみのLSPのカウントに貢献する式は、n = 1 + R / 2までにN = R / 2、およびラングスパー-と-LSPのためのアップのみ有効であることがわかります。これらの限界を超えると、スパー専用のLSPによって行われた寄与は2X *（N-R / 2）のように減衰します。
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.
上記計算しかし、第一次近似のために、我々は、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.
両方の例では、コア（P（1））ノードにおけるLSPの数は、PESの比較的控えめな数があるにもかかわらず、おそらく許容できないほど大きいです。実際には、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.
それぞれ、1039380および3998000であり、 - システムS（PE）*（1 S（PE））におけるLSPの総数と値（1）Lを比較します。
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ネットワークのスケーリング特性を改善することです。 （時々転送隣接関係（FAS）としても知られる）LSPトンネルは、ネットワークのコアの上に接続性を提供するために確立されてもよいし、複数のエッジ間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のメッシュを考えます。ここでは二つの可能性を検討してください。最初に、全てのP（2）ノードがLSPトンネルによって、他の全てのP（2）ノードに接続され、PE-に-PEのLSPは、ネットワークのコアでトンネリングされています。第二に、LSPの階層の追加の層は、全てがP（1）LSP内のノードがメッシュ接続し、これらを介して、（2）-to-P（2）トンネルPをトンネリングすることによって導入されます。
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（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:
（2）Lはわずかに増加します。これは、（この図には、すなわち、Mセクション5.1から変更されていない添付のPE間のLSPを含む、すべての接続のPEのためのすべてのLSPの合計として計算することができる（2）*（2 * S（PE） - M（2） - 1））、プラスFA LSPの数は、他のP（2）ノードにメッシュを提供します。 FAのLSP - Pの数は、（2）ノードはS（2）、各Pは、（2）ノードは、2 *（1 S（2））を見ているからです。したがって
L(2) = M(2)*(2*S(PE) - M(2) - 1) + 2*(S(2) - 1)
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にそれぞれ取り付けられたP（2）へとからFA LSPの数の和として計算することができる（2）ネットワークにおいて、含む（しかし、一度だけカウント）添付のP（2）ノード間のFAのLSP。実際には、問題は、セクション5.1でL（2）の計算と同一です。そう：
L(1) = M(1)*(2*S(2) - M(1) - 1)
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:
だから、例えば、S（1）= 5、M（1）= 10、およびM（2）= 20、我々は以下を参照してください。
S(PE) = 1000 S(2) = 50 L(PE) = 1998 L(2) = 39678 L(1) = 890
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
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.
だから、両方の実施例において、コア（P（1））での潜在的な問題は、LSPの過剰な数を回避することができるによって引き起こされるノードが、以下の表から分かるように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の適切な値を選択することにより、L（2）を低減することができる（1）、M（1）、及びM（2）。変更がL（PE）に影響を与えませんので、我々は、負の影響なしにこれを行うことができますし、Lで大きな割合の増加ので、（1）（1）非常に小さいので、そのLは現在、持続可能です。
Observe that:
それを守ってください。
L(2) = M(2)*(2*S(PE) - M(2) - 1) + 2*(S(2) - 1)
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に比例し、我々は、一定の（PE）Sを保持したまま（2）Mを還元することによって最も影響を持つことができます。
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
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
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))
K = S（PE）/（S（1）+ S（2）... + S（n））を
where n is the level above the PEs, so that for our network:
nは、上記のPEレベルは、ここで私たちのネットワークのように：
K = S(PE) / (S(1) + S(2))
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年から1055年から110分の1000に半減されています。第2の例では、110分の2000から420分の2000に変更し、約1 1/4に低減されています。
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に提示二層の階層に代わるものは、P（1）ノード間のFA LSPの完全なメッシュを提供することです。この技術は、レベル1のネットワークのコア内の任意のノードにのみ有益です。彼らは唯一のPE-に-PE LSPを参照し続けるので、それはPEとP（2）ノードに違いはありません。彼らはフラットモデルに加え、さらに2 *（S（1） - 1）のようにPE-に-PE LSPのすべてをサポートしなければならないので、このアプローチは、P（1）ノードに負担を増加P（1） -to-P（1）FAのLSP。そこ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との間のP（3）（2）及びPE）に我々はPE-に-PEのLSP、及びFA LSPの完全なメッシュを運ぶために、すべてのP（3）ノード間のFA LSPの完全なメッシュを有するように4レベルスノーフレークを行う、我々はFA LSPの新たな層を導入することができますすべてのPの間（2）ノードは、Pを搬送するために（3）-to-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).
PEの数は、S（PE）= S（1）* M（1）* M（2）* M（3）であり、PE-に-PEのLSP PEでの数は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の和であり、プラスFA LSPの数は、他のP（3）ノードにメッシュを提供します。
L(3) = M(3)*(2*S(PE) - M(3) - 1) + 2*(S(3) - 1)
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のすべてのLSPの合計が取り付けPEプラスメッシュを提供するFA LSPの数との間のLSPを含む（3）ノードであるので、（2）PにおけるLSPの数も6.1から推定することができます他のP（2）ノード。
L(2) = M(2)*(2*S(3) - M(2) - 1) + 2*(S(2) - 1)
L（2）= M（2）*（2 * S（3） - M（2） - 1）+ 2 *（S（2） - 1）
Finally, L(1) can be copied straight from 6.1.
最後に、（1）Lが6.1から真っ直ぐにコピーすることができます。
L(1) = M(1)*(2*S(2) - M(1) - 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
S（PE）= 1000 S（3）= 125のS（2）= 25 L（PE）= 1998 L（3）L = 16176（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
S（PE）= 2000 S（3）= 200のS（2）= 25 L（PE）= 3998 L（3）L = 40038（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.
もちろん、ネットワーク内の余分なレベルは、上記の例のために（1000から1055と110分の2000から）K = 155分の1000及びK = 230分の2000の値を持つネットワークの費用対効果を減少させる傾向があります。すなわち、第一ケース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.
階層スケーリング技術のための基本的な観察は、P（N）のPEに隣接するノード（例えば、Lを減少させることは困難である（3のレベルによってサポートされなければならないLSPの数にいかなる影響を与えることは困難であるということです）6.3節で）。換言すれば、任意のP（N）に範囲が定められたPEの数を変更する - 実際には、我々はこれらのノードによってサポートされるLSPの数を変更することができる唯一の方法は、ネットワーク内の変倍率M（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.
階層的なアプローチのもう一つの懸念は、それが設定され、管理されなければならないということです。これは大きな負担のように見えるかもしれないが、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トンネルで接続することができます。したがって、P（n）のレベル（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高速リルート（FRR）[RFC4090]を使用して保護することができる方法です。 FRRは、それらが壊れたリンクを横切るようにトンネルを保護することにより、またはレベルのリンクとして各レベル（N）トンネルLSPを処理することにより、いずれかのリンク保護を提供することができる（N + 1）と（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.
最後に、私たちは便利な対称ネットワークを使用してこれらの技術を説明されていることを確認します。我々はいくつかのPEが他よりもネットワークの中心に近い接続されたネットワークにおける階層化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）-to-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任意トランジットトンネルO、P（1）ノードで終端するトンネルの全て、及びサブテンドのPEによるLSPのO全。
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)
L（1）= 2 *（S（1） - 1）+ O（S（1）* S（1）/ 2）+ 2 *イー・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
L（1）= S（1）* S（1）/ 2 + 2 * S（1）+ 2 *イー・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
170 E = 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
200 E = 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.の図面しかし、番号がまだ管理するには大きすぎる（1）前Lを超える有意な改善を示し、L（2）図中の改善はありません。
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:
また、ラダーモデルに三層の階層構造を適用することができます。この場合、P間LSPの数は、（1）ノードは減少されず、トンネルは、すべてのP（2）ノード間に設定されています。したがって、Pから見たLSPの数は、（1）ノードです。
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）ノードで終端するトンネルの全て、Pとの間のトランジットトンネルO（1）ノード、及びOサブテンドP（2）ノードによるLSPの全。
No PE-to-PE LSPs are seen at the P(1) nodes.
NOがPE-TO-PEのLSP P（1）ノードにおいて見られません。
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)
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
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-に-PE LSPの全てを見ても、Pのセットのエンドポイントである（2）-to-P（2）トンネル。したがって、L（2）まで上昇します。
L(2) = 2*M(2)*(S(PE) - 1) - M(2)*(M(2) - 1) + 2*(S(1)*M(1) - 1)
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
170 E = 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
200 E = 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のP（2）の膨大な数は、（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.
それは3（Pでスケーリングの問題（2）ノードがトンネルを使用することによって改善することができないこと、および階層的手法でこれを容易にするために唯一の解決策は、階層の別の層（すなわち、Pを制定することであろうことが、重要ですP（2）ノードとPE間の）ノード）。これは、当然のことながら、大きな出費です。
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.
トラフィックは、一般的にその宛先に向かって収束し、これがMP2P LSPを構築する際に、MPLSによって利用することができる流れます。そのような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に示すネットワークトポロジーは、我々は、各PEで終端する1つのトンネルが存在するようにMP2P LSPトンネルを確立することを仮定検討し、そのトンネルは、入力として他のすべてのPEを有すること。したがって、PE-に-PE MP2P LSPトンネルはS（PE）-1 ingressesと一つの出口を有するであろう、及びS（PE）は、トンネルが存在することになります。
Note that there still remain 2*(S(PE) - 1) PE-to-PE P2P LSPs that are carried through these tunnels.
PE-に-PE P2P LSPのこれらのトンネルを通って運ばれること - 静止2 *（1 S（PE））が残っていることに留意されたいです。
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)
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.
（それは、セクション4に記載されているスケーリングの懸念のいくつかのために何らかの影響を持っているかもしれないが）しかし、LSPの数は唯一の問題ではありません。私たちは、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.
実際には、我々はまた、このドキュメントの以前のセクションにおけるスケーラビリティのこの措置に興味を持っていたが、これらの例では、我々は、トランジットのLSPは、状態の2つの情報を持っていたので、LSPの数とLSPの状態の量との間に直接的な相関関係を見ることができました（着信および発信インターフェイスに一対一）、および入力または出力LSPは状態のただ一枚でした。
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状態の量を定量することができます。トランジットは、2つのセグメントを有しているので、（上記のように）、P2P LSPの場合には、入力または出力を維持する一つのセグメントを有しています。同様に、MP2P LSPのために、LSRはそれぞれ上流セグメントと正確に一つの下流のセグメント（我々は仮定することができる、上流の近隣の数と一対一の関係にある）の状態情報の一組を維持しなければなりません - ingressesは明らかに何の上流の隣人を持っていない、とegressesには、下流のセグメントを持っていません。
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:
P（2）ノード：のPEで、一つの他のネットワークノードにのみ接続されています。しかし、P2PのLSPをMP2P LSPのegressesでのデータの曖昧さ回避を可能にするために使用する必要がある場合は、これらの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）下流のPEを有します。他の範囲が定められたのPEから1つの上流セグメント - P（2）（すなわちPEへ）を一度下流セグメントと各下流PEを対象単一MP2PのLSPを見て、M（2）。また、これらの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に範囲を定められたPEから実行しているのLSPもあります。 S（PE）がある - M（2）のPE、およびP（2）各サブテンドPEからこれらのそれぞれに対して1つのアップストリームセグメントを見ます。また、これらのLSPのそれぞれに対して1つのダウンストリームセグメントを有しています。 LSPセグメント - これは（M（2）+ 1）*（M（2）、S（PE））を与えます。
Thus:
したがって
X(2) = M(2)*(1 + M(2)) + (M(2) + 1)*(S(PE) - M(2)) = S(PE)*(M(2) + 1)
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）下流のPE。各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を見ます。他の範囲が定められたP（2）ノードから1つの上流セグメント - これは、1つのダウンストリーム（（2）PEが接続されるPに）セグメントとM（1）を有します。また、これらのLSPの各々は、P（1）近隣の各々の上流セグメントを有しています。これは、MのLSPセグメントの総数を与える（1）* M（2）*（M（1）+ S（1） - 1）。
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に範囲が定められたPEのそれぞれから実行しているのLSPもあります。サブテンドのPEから凝集が既に起こっているので、M（1）M（2）のPE、およびPは、（1）各サブテンディングP（2）（からこれらのそれぞれに対して1つのアップストリームセグメントを見 - S（PE）があります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)
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
S（PE）= 1000 S（2）= 100×（PE）= 3996（または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
S（PE）= 2000 S（2）= 400×（PE）= 5996（または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は、2つの状態遷移LSRにおけるユニットおよび入力または出力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))
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.
曖昧性除去が必要な場合のPEがより強く強調されているが、明らかに、この技術は、ネットワークのコア内のフラットネットワーク上有意な改善です。
Section 6.1 (two-layer hierarchy snowflake network)
6.1節（二層の階層スノーフレークネットワーク）
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)
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）ノードに一つの状態を追加することに留意されたいです。
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).
スパーノードにおけるLSPの状態が入力するかにより範囲が定められたPES（ローカルLSPセグメント）にスパーノードを残すそれらのLSPセグメントに分割し、（遠隔セグメントを入力するかにより、リモートPEにスパーノードを残すものでもよいです）。
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 EのLSPは、ローカルのPES Oを標的（S（1）-1）* E * M（1）LSPは、リモートのPEを標的
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)
O（S（1）-1）*遠隔のPE 0 <= 3 * Sを標的E発信LSPは（1）*任意のPEを標的E着信LSPは（P正確ある（1）他のP（1）ノードに接続されたノード）
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
X（1）<= E +（S（1）-1）* E * F（1）+（S（1）-1）* 3 * E + S（1）E * <=（F + 4（ 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を標的LSPを、O M（2）*（S（1）* E）他のすべてのPEへのローカルのPEからのLSP、およびo S（1）* E - M（2）リモートPEへ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
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
170 E = 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
200 E = 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つの状態とトランジットノードに二つの状態に寄与する。
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)))
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
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×（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
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
実施例A：S（1）= 6、M（1）= 10、およびM（2）= 17実施例B：S（1）= 10、M（1）= 10、および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において、MP2Pの真の利益はなくLSPの実際の数よりも、必要なLSPセグメント状態に関して分析したことを思い出してください。これは、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.
同様の分析は、ラダーネットワークのために、ここで実行することができます。正味の効果は、P2Pモデル内のすべてのトランジットのLSPのために、及びMP2Pモデルにおけるノードの次数に等しい乗算器によって2つの順序によって状態を増大させることです。
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.
概算は、スノーフレークネットワークと同様に、MP2P一レベルの階層型モデルよりも良好なスケーリングを提供し、コアでかなり良好であることを示しています。しかし、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を処理する必要があるが、彼らはより複雑になると、実際には、ingressesとegressesの同じ数を処理する必要がある、ということを意味します。診断およびOAMのような他の問題もMP2Pをサポートするように拡張する必要があるだろうが、自民党のネットワークから重く借りたことがあります。
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.
他の配置では、MP2PのLSPを介して追加のPE-PE P2PのLSPトンネルこれらを含むことが必要であると考えてもよいです。これは、2倍のLSPをサポートするためのPEを必要とします。 PEは、通常、完全にP-ルータとして指定されていないので、これはいくつかの懸念を引き起こす可能性があります。しかし、MP2PのLSPの上ではじける最後から二番目のホップを使用することは、この問題を軽減するのに役立つかもしれません。
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の数の減少を混同しないように注意しなければなりません。先に向けて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高速リルート（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を介してトンネリングされた場合、LSPのマージの利点のいずれもMP2P用の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の完全なメッシュのでPEの数の関数です。この観察の結論ではなく、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.
明らかに、物理的なネットワークトポロジに変化がないので、PEはP（n）はノードに範囲が定められたままであり、結果は全くTEは、PEとP（n）はノード間のリンク上に存在しないことです。
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 TEPSを有する（n）はノードを置き換えます。 7.対応する変更は、サンプルトポロジの全てに対して行うことができる。図に示すような、図3のフラット雪片ネットワークの一例となります。
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:
スケーリング計算を実行するために、我々は唯一のTEP数と式でPE数を交換し、ネットワーク内の1つの少ない層が存在することを確認する必要が。例えば、図7に示すフラット雪片ネットワークにおいて、我々は、TEPで見られるLSPの数であることがわかります。
L(TEP) = 2*(S(TPE) - 1)
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）は、典型的には、そうL（TEP）50又は100（S（2）の元の値）程度である非常に管理されており、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:
我々が行っているすべてが2から減らすN P（N）であるので同様に、Pで扱うLSPの数は、（1）ノードは、P（2）ノードで見られるLSPの数の元の式から誘導することができます1.にだから、私たちの新しい式は次のとおりです。
L(1) = M(1)*(2*S(TEP) - M(1) - 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）この（1）= 1890これはまた、非常に管理することが私たちLを与え、10およびS（TEP）= 100 =。
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のためのいくつかの要求があったと仮定しました。すなわち、トラフィック優先順位に基づく治療のために流れる識別することができるように、これらのリンク上の予約ベースのQoSを提供する必要があったことを意味し、データを搬送する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のためのネットワークへのアクセスのみを提供します）PE-P（n）のリンクは任意のルーティング・オプションを提供していないため、と主張される可能性があります。しかし、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を使用して、そのリンクへのトラフィック。マルチホーミングは、この文書では考慮されていないことに注意してください。
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は、LSPのが行われていない追加の構成または管理操作によって構成され、確立されなければならない、ある項6に記載の階層のLSPのために示されている追加の管理オーバーヘッドを提供しますPEで。第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.
ただし、管理ツールのスケーラビリティは、この作品とネットワークのより静的な要素が利益を表す管理するための追加的な努力のコストで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.
著者は、議論や検討入力用のジャン=ルイ・ル・ルーに感謝しています。ベン・ニーヴン・ジェンキンス、JP Vasseur、ロア・アンダーソン、アンダースGavler、ベン・キャンベル、およびティムポークのおかげで彼らのコメントについて。数学の有益な議論のためのデイブ・アレンに感謝します。
[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は、RFC 4206、2005年10月 "ラベル・パス（LSP）の階層は、一般マルチプロトコルラベルスイッチング（GMPLS）トラフィックエンジニアリング（TE）との交換しました"。
[RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S. Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC 2961, April 2001.
[RFC2961]バーガー、L.、ガン、D.、ツバメ、G.、パン、P.、Tommasi、F.、及びS. Molendini、 "RSVPリフレッシュオーバーヘッド削減拡張"、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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "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]ルFaucheur、F.、ウー、L.、デイビー、B.、Davari、S.、Vaananen、P.、クリシュナン、R.、シュヴァル、P.、およびJ. Heinanen、「マルチプロトコルラベルスイッチング（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]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（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]ブライアント、S.、エド。、およびP.パテ、エド。、 "疑似ワイヤーエミュレーション端から端まで（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]パン、P.、エド。、ツバメ、G.、エド。、およびA.アトラス編、 "高速リルート機能拡張LSPトンネルのための-TEをRSVPする"、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.鈴木、 "レイヤのためのフレームワーク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。、編、ルルー、JL。、編、安川、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]アンデション、L.、エド。、Minei、I.、エド。、およびB.トーマス、エド。、 "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]安川、Y.、進歩、2008年10月に、仕事を「マルチポイント・ツー・ポイントのラベルをサポートするには、トラフィックエンジニアリングをマルチプロトコルラベルスイッチングのパスをスイッチ」。
[MPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", Work in Progress, November 2008.
[MPLS-SEC]牙、L.、エド。、 "MPLSおよびGMPLSネットワークのセキュリティフレームワーク"、進歩、2008年11月の作業。
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
せいしょ やすかわ んっｔ こｒぽらちおん ９ー１１、 みどりーちょ ３ーちょめ むさしのーし、 ときょ １８０ー８５８５ じゃぱん Ｐほね： ＋８１ ４２２ ５９ ４７６９ えまいｌ： ｓ。やすかわ＠ｈこ。んっｔ。こ。ｊｐ
Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk
エードリアンファレル老犬のコンサルティングメール：adrian@olddog.co.uk
Olufemi Komolafe Cisco Systems 96 Commercial Street Edinburgh EH6 6LX United Kingdom EMail: femi@cisco.com
Olufemi Komolafeシスコシステムズ96コマーシャルストリートエジンバラEH6 6LXイギリスメール：femi@cisco.com