[要約] RFC 3346は、MPLSを使用したトラフィックエンジニアリングの適用性に関する要約であり、MPLSネットワークでのトラフィック制御と最適化の目的を提供します。
Network Working Group J. Boyle
Request for Comments: 3346 PD Nets
Category: Informational V. Gill
AOL Time Warner, Inc.
A. Hannan
RoutingLoop
D. Cooper
Global Crossing
D. Awduche
Movaz Networks
B. Christian
Worldcom
W.S. Lai
AT&T
August 2002
Applicability Statement for Traffic Engineering with MPLS
MPLSを使用した交通工学のアプリケーションステートメント
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) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document describes the applicability of Multiprotocol Label Switching (MPLS) to traffic engineering in IP networks. Special considerations for deployment of MPLS for traffic engineering in operational contexts are discussed and the limitations of the MPLS approach to traffic engineering are highlighted.
このドキュメントでは、IPネットワークのトラフィックエンジニアリングへのマルチプロトコルラベルスイッチング（MPLS）の適用性について説明します。運用コンテキストでのトラフィックエンジニアリングのためのMPLSの展開に関する特別な考慮事項について説明し、交通工学へのMPLSアプローチの制限が強調されています。
Table of Contents
目次
1. Introduction....................................................2
2. Technical Overview of ISP Traffic Engineering...................3
3. Applicability of Internet Traffic Engineering...................4
3.1 Avoidance of Congested Resources................................4
3.2 Resource Utilization in Network Topologies with Parallel Links..5
3.3 Implementing Routing Policies using Affinities..................5
3.4 Re-optimization After Restoration...............................6
4. Implementation Considerations...................................6
4.1 Architectural and Operational Considerations....................6
4.2 Network Management Aspects......................................7
4.3 Capacity Engineering Aspects....................................8
4.4 Network Measurement Aspects.....................................8
5. Limitations.....................................................9
6. Conclusion.....................................................11
7. Security Considerations........................................11
8. References.....................................................11
9. Acknowledgments................................................12
10. Authors' Addresses.............................................13
11. Full Copyright Statement.......................................14
It is generally acknowledged that one of the most significant initial applications of Multiprotocol Label Switching (MPLS) is traffic engineering (TE) [1][2] in IP networks. A significant community of IP service providers have found that traffic engineering of their networks can have tactical and strategic value [2, 3, 4]. To support the traffic engineering application, extensions have been specified for Interior Gateway Protocols (IGP) IS-IS [5] and OSPF [6], and to signaling protocols RSVP [7] and LDP [8]. The extensions for IS-IS, OSPF, and RSVP have all been developed and deployed in large scale in many networks consisting of multi-vendor equipment.
一般に、マルチプロトコルラベルスイッチング（MPLS）の最も重要な初期アプリケーションの1つは、IPネットワークのトラフィックエンジニアリング（TE）[1] [2]であることが認められています。IPサービスプロバイダーの重要なコミュニティは、ネットワークのトラフィックエンジニアリングが戦術的および戦略的価値を持つことができることを発見しました[2、3、4]。トラフィックエンジニアリングアプリケーションをサポートするために、インテリアゲートウェイプロトコル（IGP）IS-IS [5]およびOSPF [6]、およびシグナル伝達プロトコルRSVP [7]およびLDP [8]に拡張機能が指定されています。IS-IS、OSPF、およびRSVPの拡張機能はすべて、マルチベンダー機器で構成される多くのネットワークで大規模に開発および展開されています。
This document discusses the applicability of TE to Internet service provider networks, focusing on the MPLS-based approach. It augments the existing protocol applicability statements and, in particular, relates to the operational applicability of RSVP-TE [9]. Special considerations for deployment of MPLS in operational contexts are discussed and the limitations of this approach to traffic engineering are highlighted.
このドキュメントでは、MPLSベースのアプローチに焦点を当てたTEのインターネットサービスプロバイダーネットワークへの適用性について説明します。既存のプロトコルの適用ステートメントを強化し、特にRSVP-TEの運用上の適用性に関連しています[9]。運用コンテキストでのMPLSの展開に関する特別な考慮事項について説明し、トラフィックエンジニアリングに対するこのアプローチの制限が強調されています。
Traffic engineering (TE) is generally concerned with the performance optimization of operational networks [2]. In contemporary practice, TE means mapping IP traffic flows onto the existing physical network topology in the most effective way to accomplish desired operational objectives. Techniques currently used to accomplish this include, but are not limited to:
トラフィックエンジニアリング（TE）は、一般に、運用ネットワークのパフォーマンス最適化に関係しています[2]。現代の実践では、TEは、IPトラフィックフローを既存の物理ネットワークトポロジにマッピングして、希望する運用目標を達成するための最も効果的な方法でマッピングすることを意味します。現在これを達成するために使用されている手法には含まれますが、以下に限定されません。
1. Manipulation of IGP cost (metrics) 2. Explicit routing using constrained virtual-circuit switching techniques such as ATM or Frame Relay SPVCs 3. Explicit routing using constrained path setup techniques such as MPLS
1. IGPコストの操作（メトリック）2。ATMやフレームリレーSPVCなどの制約付き仮想回路スイッチング技術を使用した明示的なルーティング3. MPLSなどの制約付きパスセットアップ手法を使用した明示的なルーティング
This document is concerned primarily with MPLS techniques. Specifically, it deals with the ability to use paths other than the shortest paths selected by the IGP to achieve a more balanced network utilization, e.g., by moving traffic away from IGP-selected shortest paths onto alternate paths to avoid congestion in the network. This can be achieved by using explicitly signaled LSP-tunnels. The explicit routes to be used may be computed offline and subsequently downloaded and configured on the routers using an appropriate mechanism. Alternatively, the desired characteristics of an LSP (such as endpoints, bandwidth, affinities) may be configured on a router, which will then use an appropriate algorithm to compute a path through the network satisfying the desired characteristics, subject to various types of constraints. Generally, the characteristics associated with LSPs may include:
このドキュメントは、主にMPLS技術に関するものです。具体的には、IGPによって選択された最短パス以外のパスを使用して、よりバランスのとれたネットワーク利用を実現する機能を扱っています。これは、明示的に信号されたLSPタンネルを使用することで実現できます。使用する明示的なルートは、オフラインで計算され、その後、適切なメカニズムを使用してルーターにダウンロードおよび構成されます。あるいは、LSPの目的の特性（エンドポイント、帯域幅、アフィニティなど）をルーターで構成することができます。これにより、適切なアルゴリズムを使用して、さまざまなタイプの制約を条件として、望ましい特性を満たすネットワークを通るパスを計算できます。一般に、LSPに関連する特性には、次のものが含まれます。
o Ingress and egress nodes o Bandwidth required o Priority o Nodes to include or exclude in the path o Affinities to include or exclude in the path o Resilience requirements
o イングレスノードと出口ノードo帯域幅o優先度oノードo nodesがパスo親和性に含める、または除外して、パスoレジリエンス要件に含めるまたは除外する
Affinities are arbitrary, provider-assigned, attributes applied to links and carried in the TE extensions for the IGPs. Affinities impose a class structure on links, which allow different links to be logically grouped together. They can be used to implement various types of policies, or route preferences that allow the inclusion or exclusion of groups of links from the path of LSPs. Affinities are unique to MPLS and the original requirement for them was documented in [2].
親和性は、リンクに適用され、IGPSのTE延長に携帯されている属性、プロバイダーが割り当てられた属性です。アフィニティは、リンクにクラス構造を課します。これにより、異なるリンクを論理的にグループ化できます。これらを使用して、さまざまな種類のポリシーを実装したり、LSPのパスからリンクのグループを含めるか除外できるルート設定を実装できます。親和性はMPLSに固有のものであり、それらの元の要件は[2]に記録されていました。
As mentioned in [2] and [7], traffic engineering with MPLS is appropriate to establish and maintain explicitly routed paths in an IP network for effective traffic placement. LSP-tunnels can be used to forward subsets of traffic through paths that are independent of routes computed by conventional IGP Shortest Path First (SPF) algorithms. This gives network operators significant flexibility in controlling the paths of traffic flows across their networks and allows policies to be implemented that can result in the performance optimization of networks. Examples of scenarios where MPLS-based TE capabilities are applicable in service provider environments are given below. The applicability of MPLS is certainly not restricted to these scenarios.
[2]および[7]で述べたように、MPLSを使用したトラフィックエンジニアリングは、効果的なトラフィック配置のためにIPネットワーク内で明示的にルーティングされたパスを確立および維持するのに適しています。LSP-Tunnelsは、従来のIGP最短パス（SPF）アルゴリズムによって計算されたルートから独立したパスを介してトラフィックのサブセットを転送するために使用できます。これにより、ネットワークオペレーターは、ネットワーク全体のトラフィックフローのパスを制御する際に大きな柔軟性を提供し、ネットワークのパフォーマンス最適化をもたらす可能性のあるポリシーを実装できます。MPLSベースのTE機能がサービスプロバイダー環境に適用できるシナリオの例を以下に示します。MPLSの適用性は、これらのシナリオに限定されていません。
In order to lower the utilization of congested link(s), an operator may utilize TE methods to route a subset of traffic away from those links onto less congested topological elements. These types of techniques are viable when segments of the network are congested while other parts are underutilized.
混雑したリンクの利用を下げるために、オペレーターはTEメソッドを利用して、それらのリンクからトラフィックのサブセットを混雑の少ないトポロジー要素にルーティングすることができます。これらのタイプの手法は、ネットワークのセグメントが混雑している間、他の部品が十分に活用されていない場合に実行可能です。
Operators who do not make extensive use of LSP-tunnels may adopt a tactical approach to MPLS TE in which they create LSP-tunnels only when necessary to address specific congestion problems. For example, an LSP can be created between two nodes (source and destination) that are known to contribute traffic to a congested network element, and explicitly route the LSP through a separate path to divert some traffic away from the congestion. On the other hand, operators who make extensive use of LSP-tunnels, either for measurement or automated traffic control, may decide to explicitly route a subset of the LSPs that traverse the point of congestion onto alternate paths. This can be employed to respond quickly when the bandwidth parameter associated with the LSPs does not accurately represent the actual traffic carried by the LSPs, and the operator determines that changing the bandwidth parameter values might not be effective in addressing the issue or may not have lasting impact.
LSP-Tunnelsを広範囲に使用しないオペレーターは、特定の混雑問題に対処するために必要な場合にのみLSP-Tunnelsを作成するMPLS TEに戦術的なアプローチを採用する場合があります。たとえば、LSPは、混雑したネットワーク要素にトラフィックを寄付することが知られている2つのノード（ソースと宛先）の間に作成し、LSPを別のパスに通って明示的にルーティングして、混雑からトラフィックを迂回させます。一方、測定または自動化されたトラフィックコントロールのために、LSPタンネルを広範囲に使用する演算子は、輻輳の点を代替パスに横断するLSPのサブセットを明示的にルーティングすることを決定する場合があります。これは、LSPに関連付けられている帯域幅パラメーターがLSPSによって運ばれる実際のトラフィックを正確に表していない場合に迅速に応答するために使用できます。また、オペレーターは、帯域幅パラメーター値の変更が問題に対処するのに効果的でないか、持続しない可能性があると判断します。インパクト。
There are other approaches that measure traffic workloads on LSPs and utilize these empirical statistics to configure various characteristics of LSPs. These approaches, for example, can utilize the derived statistics to configure explicit routes for LSPs (also known as offline TE [10]). They can also utilize the statistics to set the values of various LSP attributes such as bandwidths, priority, and affinities (online TE). All of these approaches can be used both tactically and strategically to react to periods of congestion in a network. Congestion may occur as a result of many factors: equipment or facility failure, longer than expected provisioning cycles for new circuits, and unexpected surges in traffic demand.
LSPでトラフィックワークロードを測定し、これらの経験的統計を利用してLSPのさまざまな特性を構成する他のアプローチがあります。たとえば、これらのアプローチは、派生統計を利用して、LSPの明示的なルートを構成することができます（オフラインTE [10]）。また、統計を利用して、帯域幅、優先度、アフィニティ（オンラインTE）などのさまざまなLSP属性の値を設定することもできます。これらのアプローチはすべて、戦術的および戦略的に使用して、ネットワーク内の混雑の期間に反応することができます。多くの要因の結果として輻輳が発生する場合があります。機器または施設の故障、新しい回路の予想以上のプロビジョニングサイクル、および交通需要の予期しない急増です。
In practice, many service provider networks contain multiple parallel links between nodes. An example is transoceanic connectivity which is often provisioned as numerous low-capacity circuits, such as NxDS-3 (N parallel DS-3 circuits) and NxSTM-1 (N parallel STM-1 circuits). Parallel circuits also occur quite often in bandwidth-constrained cities. MPLS TE methods can be applied to effectively distribute the aggregate traffic workload across these parallel circuits.
実際には、多くのサービスプロバイダーネットワークには、ノード間の複数の並列リンクが含まれています。例は、NXDS-3（N平行DS-3回路）やNXSTM-1（N平行STM-1回路）などの多数の低容量回路としてプロビジョニングされることがよくあります。平行回路も帯域幅に制約のある都市で非常に頻繁に発生します。MPLS TEメソッドを適用して、これらの並列回路全体に総トラフィックワークロードを効果的に配布できます。
MPLS-based approaches commonly used in practice to deal with parallel links include using LSP bandwidth parameters to control the proportion of demand traversing each link, explicitly configuring routes for LSP-tunnels to distribute them across the parallel links, and using affinities to map different LSPs onto different links. These types of solutions are also applicable in networks with parallel and replicated topologies, such as an NxOC-3/12/48 topology.
並列リンクを扱うために一般的に実際に使用されるMPLSベースのアプローチには、LSP帯域幅パラメーターを使用して各リンクを通過する需要の割合を制御すること、lsp-tunnelsのルートを平行リンク全体に明示的に構成すること、アフィニティを使用して異なるLSPSをマッピングすることが含まれます。さまざまなリンクに。これらのタイプのソリューションは、NXOC-3/12/48トポロジなどの並列および複製されたトポロジを持つネットワークにも適用されます。
It is sometimes desirable to restrict certain types of traffic to certain types of links, or to explicitly exclude certain types of links in the paths for some types of traffic. This might be needed to accomplish some business policy or network engineering objectives. MPLS resource affinities provide a powerful mechanism to implement these types of objectives.
特定の種類のトラフィックを特定の種類のリンクに制限したり、ある種のトラフィックのパス内の特定の種類のリンクを明示的に除外することが望ましい場合があります。これは、ビジネスポリシーまたはネットワークエンジニアリングの目標を達成するために必要な場合があります。MPLSリソースアフィニティは、これらのタイプの目標を実装するための強力なメカニズムを提供します。
As a concrete example, suppose a global service provider has a flat (non-hierarchical) IGP. MPLS TE affinities can be used to explicitly keep continental traffic (traffic originating and terminating within a continent) from traversing transoceanic resources.
具体的な例として、グローバルサービスプロバイダーにフラット（非階層的）IGPがあると仮定します。MPLS TE親和性を使用して、大陸交通（大陸内でのトラフィックが発信および終了します）を横断的資源を横断することから明示的に維持できます。
Another example of using MPLS TE affinities to exclude certain traffic from a subset of circuits might be to keep inter-regional LSPs off of circuits that are reserved for intra-regional traffic.
MPLS TE親和性を使用して回路のサブセットから特定のトラフィックを除外する別の例は、地域内トラフィックのために予約されている回路から地域間LSPを維持することです。
Still another example is the situation in a heterogeneous network consisting of links with different capacities, e.g., OC-12, OC-48, and OC-192. In such networks, affinities can be used to force some types of traffic to only traverse links with a given capacity, e.g. OC-48.
さらに別の例は、異なる容量のリンク（OC-12、OC-48、OC-192などのリンクからなる不均一なネットワークの状況）です。このようなネットワークでは、アフィニティを使用して、ある種のトラフィックに特定の容量とのみリンクのみを横断するように強制することができます。OC-48。
After the occurrence of a network failure, it may be desirable to calculate a new set paths for LSPs to optimizes performance over the residual topology. This re-optimization is complementary to the fast-reroute operation used to reduce packet losses during routing transients under network restoration. Traffic protection can also be accomplished by associating a primary LSP with a set of secondary LSPs, hot-standby LSPs, or a combination thereof [11].
ネットワーク障害が発生した後、LSPの新しいセットパスを計算して、残留トポロジに対するパフォーマンスを最適化することが望ましい場合があります。この再最適化は、ネットワークの復元下でのルーティングトランジェント中のパケット損失を減らすために使用される高速レアウト操作を補完します。トラフィック保護は、一次LSPを二次LSP、Hot-Standby LSP、またはそれらの組み合わせに関連付けることで達成することもできます[11]。
When deploying TE solutions in a service provider environment, the impact of administrative policies and the selection of nodes that will serve as endpoints for LSP-tunnels should be carefully considered. As noted in [9], when devising a virtual topology for LSP-tunnels, special consideration should be given to the tradeoff between the operational complexity associated with a large number of LSP-tunnels and the control granularity that large numbers of LSP-tunnels allow. In other words, a large number of LSP-tunnels allow greater control over the distribution of traffic across the network, but increases network operational complexity. In large networks, it may be advisable to start with a simple LSP-tunnel virtual topology and then introduce additional complexity based on observed or anticipated traffic flow patterns [9].
サービスプロバイダー環境にTEソリューションを展開する場合、管理ポリシーの影響とLSPタンネルのエンドポイントとして機能するノードの選択を慎重に考慮する必要があります。[9]で述べたように、LSPタンネルの仮想トポロジーを考案する場合、多数のLSPタンネルに関連する運用上の複雑さと多数のLSPタンネルが許す制御粒度との間のトレードオフに特別な考慮を与える必要があります。言い換えれば、多数のLSPタンネルにより、ネットワーク全体のトラフィックの分布をより強く制御できますが、ネットワークの運用の複雑さを増加させます。大規模なネットワークでは、単純なLSP-Tunnel仮想トポロジから始めて、観測されたトラフィックフローパターンに基づいて追加の複雑さを導入することをお勧めします[9]。
Administrative policies should guide the amount of bandwidth to be allocated to an LSP. One may choose to set the bandwidth of a particular LSP to a statistic of the measured observed utilization over an interval of time, e.g., peak rate, or a particular percentile or quartile of the observed utilization. Sufficient over-subscription (of LSPs) or under-reporting bandwidth on the physical links should be used to account for flows that exceed their normal limits on an event-driven basis. Flows should be monitored for trends that indicate when the bandwidth parameter of an LSP should be resized. Flows should be monitored constantly to detect unusual variance from expected levels. If an unpoliced flow greatly exceeds its assigned bandwidth, action should be taken to determine the root cause and remedy the problem. Traffic policing is an option that may be applied to deal with congestion problems, especially when some flows exceed their bandwidth parameters and interfere with other compliant flows. However, it is usually more prudent to apply policing actions at the edge of the network rather than within the core, unless under exceptional circumstances.
管理ポリシーは、LSPに割り当てる帯域幅の量を導く必要があります。特定のLSPの帯域幅を、時間間隔で測定された観測された利用の統計、たとえばピークレート、または観測された使用率の特定のパーセンタイルまたは四分位に設定することを選択できます。物理リンクの十分な過剰サブスクリプションまたは過少報告帯域幅を使用して、イベント駆動型ベースで通常の限界を超えるフローを説明する必要があります。LSPの帯域幅パラメーターのサイズを変更する時期を示す傾向について、フローを監視する必要があります。予想されるレベルから異常な分散を検出するために、フローを常に監視する必要があります。未照射のフローが割り当てられた帯域幅を大きく超えている場合、根本原因を決定し、問題を改善するためのアクションを実行する必要があります。トラフィックポリシングは、特に一部のフローが帯域幅パラメーターを超えて他の準拠のフローを妨害する場合、混雑の問題に対処するために適用される可能性のあるオプションです。ただし、通常、例外的な状況下では、コア内ではなくネットワークの端にポリシングアクションを適用する方が賢明です。
When creating LSPs, a hierarchical network approach may be used to alleviate scalability problems associated with flat full mesh virtual topologies. In general, operational experience has shown that very large flows (between city pairs) are long-lived and have stable characteristics, while smaller flows (edge to edge) are more dynamic and have more fluctuating statistical characteristics. A hierarchical architecture can be devised consisting of core and edge networks in which the core is traffic engineered and serves as an aggregation and transit infrastructure for edge traffic.
LSPを作成する場合、階層ネットワークアプローチを使用して、フラットフルメッシュ仮想トポロジに関連するスケーラビリティの問題を軽減することができます。一般に、運用上の経験は、非常に大きなフロー（都市のペアの間）が長寿命で安定した特性を持っていることを示していますが、より小さな流れ（エッジからエッジ）はより動的であり、より変動する統計的特性を持っています。階層アーキテクチャは、コアがトラフィックエンジニアリングされ、エッジトラフィック用の集約およびトランジットインフラストラクチャとして機能するコアおよびエッジネットワークで構成されて考案できます。
However, over-aggregation of flows can result in a stream so large that it precludes the constraint-based routing algorithm from finding a feasible path through a network. Splitting a flow by using two or more parallel LSPs and distributing the traffic across the LSPs can solve this problem, at the expense of introducing more state in the network.
ただし、フローの過剰な凝集により、ストリームが非常に大きくなる可能性があるため、制約ベースのルーティングアルゴリズムがネットワークを介して実行可能なパスを見つけることを妨げる可能性があります。2つ以上の並列LSPを使用してフローを分割し、LSP全体にトラフィックを配布すると、ネットワーク内のより多くの状態を導入することを犠牲にして、この問題を解決できます。
Failure scenarios should also be addressed when splitting a stream of traffic over several links. It is of little value to establish a finely balanced set of flows over a set of links only to find that upon link failure the balance reacts poorly, or does not revert to the original situation upon restoration.
いくつかのリンクでトラフィックのストリームを分割する場合、障害シナリオにも対処する必要があります。リンクの障害時にバランスの反応が不十分であるか、復元時に元の状況に戻らないことを見つけるためにのみ、リンクのセット上で細かくバランスの取れたフローセットを確立することはほとんど価値がありません。
Networks planning to deploy MPLS for traffic engineering must consider network management aspects, particularly performance and fault management [12]. With the deployment of MPLS in any infrastructure, some additional operational tasks are required, such as constant monitoring to ensure that the performance of the network is not impacted in the end-to-end delivery of traffic. In addition, traffic characteristics, such as latency across an LSP, may also need to be assessed on a regular basis to ensure that service-level guarantees are achieved.
トラフィックエンジニアリング用にMPLSを展開することを計画しているネットワークは、ネットワーク管理の側面、特にパフォーマンスと障害管理を考慮する必要があります[12]。インフラストラクチャにMPLSが展開されると、トラフィックのエンドツーエンド配信でネットワークのパフォーマンスが影響を受けないように、一定の監視など、いくつかの追加の運用タスクが必要です。さらに、LSP全体のレイテンシなどのトラフィック特性も、サービスレベルの保証が達成されることを保証するために、定期的に評価する必要がある場合があります。
Obtaining information on LSP behavior is critical in determining the stability of an MPLS network. When LSPs transition or path changes occur, packets may be dropped which impacts network performance. It should be the goal of any network deploying MPLS to minimize the volatility of LSPs and reduce the root causes that induce this instability. Unfortunately, there are very few, if any, NMS systems that are available at this time with the capability to provide the correct level of management support, particularly root cause analysis. Consequently, most early adopters of MPLS develop their own management systems in-house for the MPLS domain. The lack of availability of commercial network management systems that deal specifically with MPLS-related aspects is a significant impediment to the large-scale deployment of MPLS networks.
LSPの動作に関する情報を取得することは、MPLSネットワークの安定性を決定する上で重要です。LSPの移行またはパスの変更が発生すると、ネットワークのパフォーマンスに影響を与えるパケットが削除される場合があります。これは、MPLSを展開するネットワークの目標であり、LSPのボラティリティを最小限に抑え、この不安定性を誘発する根本原因を減らす必要があります。残念ながら、現時点で利用可能なNMSシステムは、正しいレベルの管理サポート、特に根本原因分析を提供する機能を備えています。その結果、MPLSの初期のほとんどの採用者は、MPLSドメインの社内で独自の管理システムを開発します。MPLS関連の側面を特に扱う商用ネットワーク管理システムの可用性がないことは、MPLSネットワークの大規模な展開にとって大きな障害です。
The performance of an MPLS network is also dependent on the configured values of bandwidth for each LSP. Since congestion is a common cause of performance degradation in operational networks, it is important to proactively avoid these situations. While MPLS was designed to minimize congestion on links by utilizing bandwidth reservations, it is still heavily reliant on user configurable data. If the LSP bandwidth value does not properly represent the traffic demand of that LSP, over-utilization may occur and cause significant congestion within the network. Therefore, it is important to develop, deploy, and maintain a good modeling tool for determining LSP bandwidth size. Lack of this capability may result in sub-optimal network performance.
MPLSネットワークのパフォーマンスは、各LSPの帯域幅の構成値にも依存します。混雑は運用ネットワークのパフォーマンス劣化の一般的な原因であるため、これらの状況を積極的に回避することが重要です。MPLSは、帯域幅の予約を利用することにより、リンクの輻輳を最小限に抑えるように設計されていますが、ユーザー構成可能なデータに依存しています。LSP帯域幅の値がそのLSPのトラフィック需要を適切に表していない場合、過剰利用が発生し、ネットワーク内でかなりのうっ血を引き起こす可能性があります。したがって、LSP帯域幅サイズを決定するための優れたモデリングツールを開発、展開、および維持することが重要です。この機能が不足すると、最適なネットワークパフォーマンスが発生する可能性があります。
Traffic engineering has a goal of ensuring traffic performance objectives for different services. This requires that the different network elements be dimensioned properly to handle the expected load. More specifically, in mapping given user demands onto network resources, network dimensioning involves the sizing of the network elements, such as links, processors, and buffers, so that performance objectives can be met at minimum cost. Major inputs to the dimensioning process are cost models, characterization of user demands and specification of performance objectives.
トラフィックエンジニアリングには、さまざまなサービスのトラフィックパフォーマンス目標を確保することを目標としています。これには、予想される負荷を処理するために、異なるネットワーク要素を適切に寸法化する必要があります。より具体的には、ネットワークリソースに与えられたユーザーの要求をマッピングする際に、ネットワークの寸法には、リンク、プロセッサ、バッファーなどのネットワーク要素のサイジングが含まれているため、パフォーマンス目標を最小コストで満たすことができます。寸法プロセスへの主要な入力は、コストモデル、ユーザーの要求の特性評価、およびパフォーマンス目標の仕様です。
In using MPLS, dimensioning involves the assignment of resources such as bandwidth to a set of pre-selected LSPs for carrying traffic, and mapping the logical network of LSPs onto a physical network of links with capacity constraints. The dimensioning process also determines the link capacity parameters or thresholds associated with the use of some bandwidth reservation scheme for service protection. Service protection controls the QoS for certain service types by restricting access to bandwidth, or by giving priority access to one type of traffic over another. Such methods are essential, e.g., to prevent starvation of low-priority flows, to guarantee a minimum amount of resources for flows with expected short duration, to improve the acceptance probability for flows with high bandwidth requirements, or to maintain network stability by preventing performance degradation in case of a local overload.
MPLSを使用する際に、寸法には、トラフィックを運ぶための事前に選択されたLSPのセットへの帯域幅などのリソースの割り当て、およびLSPの論理ネットワークを容量制約を備えたリンクの物理ネットワークにマッピングすることが含まれます。寸法プロセスは、サービス保護のための帯域幅予約スキームの使用に関連するリンク容量パラメーターまたはしきい値も決定します。サービス保護は、帯域幅へのアクセスを制限するか、あるタイプのトラフィックに別のタイプのトラフィックに優先的にアクセスできるようにすることにより、特定のサービスタイプのQoSを制御します。このような方法は、たとえば、低優先順位のフローの飢vを防ぐ、予想される短い期間のフローの最小限のリソースを保証する、高い帯域幅要件を備えたフローの受け入れ確率を改善するため、またはパフォーマンスを防ぐことでネットワークの安定性を維持するために不可欠です。局所的な過負荷の場合の劣化。
Network measurement entails robust statistics collection and systems development. Knowing *what* to do with these measurements is often where the secret-sauce is. Examples for different applications of measurements are described in [13]. For instance, to ensure that the QoS objectives have been met, performance measurements and performance monitoring are required so that real-time traffic control actions, or policy-based actions, can be taken. Also, to characterize the traffic demands, traffic measurements are used to estimate the offered loads from different service classes and to provide forecasting of future demands for capacity planning purposes. Forecasting and planning may result in capacity augmentation or may lead to the introduction of new technology and architecture.
ネットワーク測定には、堅牢な統計収集とシステムの開発が必要です。これらの測定で何をするかを知ることは、多くの場合、秘密のソースがある場所です。測定のさまざまなアプリケーションの例は[13]で説明されています。たとえば、QoSの目標が満たされていることを確認するために、リアルタイムのトラフィックコントロールアクション、またはポリシーベースのアクションを実行できるように、パフォーマンス測定とパフォーマンス監視が必要です。また、トラフィックの需要を特徴付けるために、トラフィック測定を使用して、さまざまなサービスクラスから提供される負荷を推定し、能力計画の目的で将来の需要の予測を提供します。予測と計画により、容量の増強が得られるか、新しいテクノロジーとアーキテクチャの導入につながる可能性があります。
To avoid QoS degradation at the packet level, measurement-based admission control can be employed by using online measurements of actual usage. This is a form of preventive control to ensure that the QoS requirements of different service classes can be met simultaneously, while maintaining network efficiency at a high level. However, it requires proper network dimensioning to keep the probability for the refusal of connection/flow requests sufficiently low.
パケットレベルでのQoS分解を回避するために、実際の使用法のオンライン測定を使用することで、測定ベースの入場制御を採用できます。これは、さまざまなサービスクラスのQoS要件を同時に満たすことができるようにする予防管理の一形態です。ただし、接続/フロー要求の拒否の確率を十分に低く保つために、適切なネットワーク寸法が必要です。
Significant resources can be expended to gain a proper understanding of how MPLS works. Furthermore, significant engineering and testing resources may need to be invested to identify problems with vendor implementations of MPLS. Initial deployment of MPLS software and the configurations management aspects to support TE can consume significant engineering, operations, and system development resources. Developing automated systems to create router configurations for network elements can require significant software development and hardware resources. Getting to a point where configurations for routers are updated in an automated fashion can be a time consuming process. Tracking manual tweaks to router configurations, or problems associated with these can be an endless task. What this means is that much more is required in the form of various types of tools to simplify and automate the MPLS TE function.
MPLSの仕組みを適切に理解するために、重要なリソースを費やすことができます。さらに、MPLSのベンダー実装に関する問題を特定するには、重要なエンジニアリングおよびテストリソースを投資する必要がある場合があります。MPLSソフトウェアとTEをサポートする構成管理の側面の初期展開は、重要なエンジニアリング、運用、システム開発リソースを消費する可能性があります。ネットワーク要素のルーター構成を作成するための自動化システムを開発するには、重要なソフトウェア開発とハードウェアリソースが必要になる場合があります。ルーターの構成が自動化された方法で更新されるポイントに到達することは、時間のかかるプロセスになる可能性があります。マニュアルの調整をルーター構成の追跡、またはこれらに関連する問題は無限のタスクになる可能性があります。これが意味することは、MPLS TE関数を簡素化および自動化するために、さまざまなタイプのツールの形ではるかに多くが必要であることです。
Certain architectural choices can lead to operational, protocol, and router implementation scalability problems. This is especially true as the number of LSP-tunnels or router configuration data in a network increases, which can be exacerbated by designs incorporating full meshes, which create O(N^2) number of LSPs, where N is the number of network-edge nodes. In these cases, minimizing N through hierarchy, regionalization, or proper selection of tunnel termination points can affect the network's ability to scale. Loss of scale in this sense can be via protocol instability, inability to change network configurations to accommodate growth, inability for router implementations to be updated, hold or properly process configurations, or loss of ability to adequately manage the network.
特定のアーキテクチャの選択は、運用、プロトコル、およびルーターの実装スケーラビリティの問題につながる可能性があります。これは、ネットワーク内のLSPタンネルまたはルーター構成データの数が増加するため、特に当てはまります。これは、完全なメッシュを組み込んだ設計によって悪化する可能性があります。エッジノード。これらの場合、階層、地域化、またはトンネル終端ポイントの適切な選択を通じてnを最小化すると、ネットワークのスケーリング能力に影響を与える可能性があります。この意味での規模の喪失は、プロトコルの不安定性、ネットワーク構成を変更して成長に対応できないこと、ルーターの実装が更新され、保持または適切に構成を処理できないこと、またはネットワークを適切に管理する能力の喪失を介して行うことができます。
Although widely deployed, MPLS TE is a new technology when compared to the classic IP routing protocols such as IS-IS, OSPF, and BGP. MPLS TE also has more configuration and protocol options. As such, some implementations are not battle-hardened and automated testing of various configurations is difficult if not infeasible. Multi-vendor environments are beginning to appear, although additional effort is usually required to ensure full interoperability.
広く展開されていますが、MPLS TEは、IS-IS、OSPF、BGPなどの古典的なIPルーティングプロトコルと比較すると、新しいテクノロジーです。MPLS TEには、より多くの構成およびプロトコルオプションもあります。そのため、一部の実装は戦闘が硬化しておらず、さまざまな構成の自動テストは実行不可能であれば困難です。通常、完全な相互運用性を確保するために追加の努力が必要ですが、マルチベンダー環境が表示され始めています。
Common approaches to TE in service provider environments switch the forwarding paradigm from connectionless to connection oriented. Thus, operational analysis of the network may be complicated in some regards (and improved in others). Inconsistencies in forwarding state result in dropped packets whereas with connectionless methods the packet will either loop and drop, or be misdirected onto another branch in the routing tree.
サービスプロバイダー環境におけるTEへの一般的なアプローチは、転送パラダイムをConnectionlessからConnection志向に切り替えます。したがって、ネットワークの運用分析は、ある程度の点で複雑になる可能性があります（および他のものでは改善されました）。状態を転送する矛盾により、パケットがドロップされますが、コネクションレスメソッドでは、パケットがループしてドロップするか、ルーティングツリーの別のブランチに誤った方向に向けられます。
Currently deployed MPLS TE approaches can be adversely affected by both internal and external router and link failures. This can create a mismatch between the signaled capacity and the traffic an LSP-tunnel carries.
現在展開されているMPLS TEアプローチは、内部および外部ルーターとリンクの両方の障害によって悪影響を受ける可能性があります。これにより、信号容量とLSPトンネルが運ぶトラフィックとの間に不一致を作成できます。
Many routers in service provider environments are already under stress processing the software workload associated with running IGP, BGP, and IPC. Enabling TE in an MPLS environment involves adding traffic engineering databases and processes, adding additional information to be carried by the routing processes, and adding signaling state and processing to these network elements. Additional traffic measurements may also need to be supported. In some environments, this additional load may not be feasible.
サービスプロバイダー環境の多くのルーターは、すでにIGP、BGP、およびIPCの実行に関連するソフトウェアワークロードをストレス処理しています。MPLS環境でTEを有効にするには、トラフィックエンジニアリングデータベースとプロセスを追加し、ルーティングプロセスによって実行される追加情報を追加し、これらのネットワーク要素にシグナリング状態と処理を追加することが含まれます。追加のトラフィック測定もサポートする必要がある場合があります。一部の環境では、この追加の負荷が実行可能ではない場合があります。
MPLS in general and MPLS-TE in particular is not a panacea for lack of network capacity, or lack of proper capacity planning and provisioning in the network dimensioning process. MPLS-TE may cause network traffic to traverse greater distances or to take paths with more network elements, thereby incurring greater latency. Generally, this added inefficiency is done to prevent shortcomings in capacity planning or available resources path to avoid hot spots. The ability of TE to accommodate more traffic on a given topology can also be characterized as a short-term gain during periods of persistent traffic growth. These approaches cannot achieve impossible mappings of traffic onto topologies. Failure to properly capacity plan and execute will lead to congestion, no matter what technology aids are employed.
一般的に、特にMPLS-TEは、ネットワーク容量の欠如、またはネットワーク寸法プロセスでの適切な容量計画とプロビジョニングの欠如の万能薬ではありません。MPLS-TEは、ネットワークトラフィックがより多くの距離を通過するか、より多くのネットワーク要素を備えたパスを取得する可能性があり、それによってより大きな遅延が発生します。一般に、この追加された非効率性は、ホットスポットを避けるために、能力計画または利用可能なリソースパスの欠点を防ぐために行われます。特定のトポロジのより多くのトラフィックに対応するTEの能力は、持続的な交通成長期間中の短期的な利益として特徴付けることもできます。これらのアプローチは、トポロジへのトラフィックの不可能なマッピングを達成することはできません。どのテクノロジーエイズが採用されていても、適切にキャパシティプランと実行を行わないと、混雑につながります。
The applicability of traffic engineering in Internet service provider environments has been discussed in this document. The focus has been on the use of MPLS-based approaches to achieve traffic engineering in this context. The applicability of traffic engineering and associated management and deployment considerations have been described, and the limitations highlighted.
このドキュメントでは、インターネットサービスプロバイダー環境でのトラフィックエンジニアリングの適用性について説明しています。焦点は、この文脈で交通工学を達成するためのMPLSベースのアプローチの使用にあります。交通工学と関連する管理および展開の考慮事項の適用性が説明されており、制限が強調されています。
MPLS combines the ability to monitor point-to-point traffic statistics between two routers and the capability to control the forwarding paths of subsets of traffic through a given network topology. This makes traffic engineering with MPLS applicable and useful for improving network performance by effectively mapping traffic flows onto links within service provider networks. Tools that simplify and automate the MPLS TE functions and activation help to realize the full potential.
MPLSは、2つのルーター間のポイントツーポイントトラフィック統計と、特定のネットワークトポロジを介してトラフィックのサブセットの転送パスを制御する機能を組み合わせています。これにより、MPLSを使用したトラフィックエンジニアリングが適用可能であり、サービスプロバイダーネットワーク内のリンクにトラフィックフローを効果的にマッピングすることにより、ネットワークパフォーマンスを改善するのに役立ちます。MPLS関数とアクティベーションを簡素化および自動化するツールは、最大限の可能性を実現するのに役立ちます。
This document does not introduce new security issues. When deployed in service provider networks, it is mandatory to ensure that only authorized entities are permitted to initiate establishment of LSP-tunnels.
このドキュメントでは、新しいセキュリティの問題は導入されていません。サービスプロバイダーネットワークに展開される場合、LSPタンネルの確立を開始することが許可されたエンティティのみが許可されるようにすることが必須です。
1 Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture," RFC 3031, January 2001.
1 Rosen、E.、Viswanathan、A。and R. Callon、「Multiprotocol Label Switching Architecture」、RFC 3031、2001年1月。
2 Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS," RFC 2702, September 1999.
2 Awduche、D.、Malcolm、J.、Agogbua、J.、O'dell、M。、およびJ. McManus、「MPLSを介した交通工学の要件」、RFC 2702、1999年9月。
3 X. Xiao, A. Hannan, B. Bailey, and L. Ni, "Traffic Engineering with MPLS in the Internet," IEEE Network, March/April 2000.
3 X. Xiao、A。Hannan、B。Bailey、およびL. Ni、「インターネットでMPLSを使用した交通工学」、IEEEネットワーク、2000年3月/4月。
4 V. Springer, C. Pierantozzi, and J. Boyle, "Level3 MPLS Protocol Architecture," Work in Progress.
4 V. Springer、C。Pierantozzi、およびJ. Boyle、「レベル3 MPLSプロトコルアーキテクチャ」、作業進行中。
5 T. Li, and H. Smit, "IS-IS Extensions for Traffic Engineering," Work in Progress.
5 T. Li、およびH. Smit、「IS-IS Traffic Engineering for Traffic Engineering」、進行中の作業。
6 D. Katz, D. Yeung, and K. Kompella, "Traffic Engineering Extensions to OSPF," Work in Progress.
6 D. Katz、D。Yeung、およびK. Kompella、「OSPFへの交通工学拡張」、進行中の作業。
7 Awduche, D., Berger, L., Gan, D.H., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC 3209, December 2001.
7 Awduche、D.、Berger、L.、Gan、D.H.、Li、T.、Srinivasan、V。およびG. Swallow、 "RSVP-TE：LSPトンネルのRSVPへの拡張、RFC 3209、2001年12月。
8 Jamoussi, B. (Editor), "Constraint-Based LSP Setup using LDP," RFC 3212, January 2002.
8 Jamoussi、B。（編集者）、「LDPを使用した制約ベースのLSPセットアップ」、RFC 3212、2002年1月。
9 Awduche, D., Hannan, A. and X. Xiao, "Applicability Statement for Extensions to RSVP for LSP-Tunnels," RFC 3210, December 2001.
9 Awduche、D.、Hannan、A。and X. Xiao、「LSP-TunnelsのRSVPへの拡張のアプリケーションステートメント」、RFC 3210、2001年12月。
10 Awduche, D., Chiu, A., Elwalid, A., Widjaja, I. and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.
10 Awduche、D.、Chiu、A.、Elwalid、A.、Widjaja、I。およびX. Xiao、「インターネットトラフィックエンジニアリングの概要と原則」、RFC 3272、2002年5月。
11 W.S. Lai, D. McDysan, J. Boyle, M. Carlzon, R. Coltun, T. Griffin, E. Kern, and T. Reddington, "Network Hierarchy and Multilayer Survivability," Work in Progress.
11 W.S.ライ、D。マクディサン、J。ボイル、M。カールゾン、R。コルトン、T。グリフィン、E。カーン、およびT.レディントン、「ネットワーク階層と多層の生存性」、進行中の作業。
12 D. Awduche, "MPLS and Traffic Engineering in IP Networks," IEEE Communications Magazine, December 1999.
12 D. Awduche、「IPネットワークのMPLSおよびトラフィックエンジニアリング」、IEEE Communications Magazine、1999年12月。
13 W.S. Lai, B. Christian, R.W. Tibbs, and S. Van den Berghe, "A Framework for Internet Traffic Engineering Measurement," Work in Progress.
13 W.S.Lai、B。Christian、R.W。Tibbs、およびS. van den Berghe、「インターネットトラフィックエンジニアリング測定のフレームワーク」、作業中。
The effectiveness of the MPLS protocols for traffic engineering in service provider networks is in large part due to the experience gained and foresight given by network engineers and developers familiar with traffic engineering with ATM in these environments. In particular, the authors wish to acknowledge the authors of RFC 2702 for the clear articulation of the requirements, as well as the developers and testers of code in deployment today for keeping their focus.
サービスプロバイダーネットワークにおけるトラフィックエンジニアリングのためのMPLSプロトコルの有効性は、これらの環境でATMを使用したTraffic Engineeringに精通しているネットワークエンジニアと開発者によって得られた経験と先見の明のために、主にあります。特に、著者は、RFC 2702の著者が要件の明確な明確な表現について認めたいと考えています。
Jim Boyle Protocol Driven Networks Tel: +1 919-852-5160 EMail: jboyle@pdnets.com
Jim Boyle Protocol駆動型ネットワークTel：1 919-852-5160メール：jboyle@pdnets.com
Vijay Gill AOL Time Warner, Inc. 12100 Sunrise Valley Drive Reston, VA 20191 EMail: vijay@umbc.edu
Vijay Gill Aol Time Warner、Inc。12100 Sunrise Valley Drive Reston、VA 20191 Email：vijay@umbc.edu
Alan Hannan RoutingLoop Intergalactic 112 Falkirk Court Sunnyvale, CA 94087, USA Tel: +1 408-666-2326 EMail: alan@routingloop.com
Alan Hannan Routingloop Intergalactic 112 Falkirk Court Sunnyvale、CA 94087、USA Tel：1 408-666-2326メール：alan@routingloop.com
Dave Cooper Global Crossing 960 Hamlin Court Sunnyvale, CA 94089, USA Tel: +1 916-415-0437 EMail: dcooper@gblx.net
Dave Cooper Global Crossing 960 Hamlin Court Sunnyvale、CA 94089、USA Tel：1 916-415-0437メール：dcooper@gblx.net
Daniel O. Awduche Movaz Networks 7926 Jones Branch Drive, Suite 615 McLean, VA 22102, USA Tel: +1 703-298-5291 EMail: awduche@movaz.com
Daniel O. Awduche Movaz Networks 7926 Jones Branch Drive、Suite 615 McLean、VA 22102、USA Tel：1 703-298-5291メール：awduche@movaz.com
Blaine Christian Worldcom 22001 Loudoun County Parkway, Room D1-2-737 Ashburn, VA 20147, USA Tel: +1 703-886-4425 EMail: blaine@uu.net
Blaine Christian Worldcom 22001 Loudoun County Parkway、Room D1-2-737 Ashburn、VA 20147、USA Tel：1 703-886-4425メール：blaine@uu.net
Wai Sum Lai AT&T 200 Laurel Avenue Middletown, NJ 07748, USA Tel: +1 732-420-3712 EMail: wlai@att.com
ワイサムライAT＆T 200ローレルアベニューミドルタウン、ニュージャージー州07748、米国Tel：1 732-420-3712メール：wlai@att.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。