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
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.
著作権（C）インターネット協会（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] [2] IPネットワークにおけるトラフィックエンジニアリング（TE）があることを認めています。 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
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選択最短経路からのトラフィックを移動させることによって、例えば、よりバランスのとれたネットワーク利用率を達成するために、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
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].
親和性は、IGPのための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-トンネルは、従来の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-トンネルの大規模な使用をしない事業者は、彼らが唯一必要な特定の輻輳問題に対処するためにLSP-トンネルを作成するMPLS TEに戦術を採用することができます。例えば、LSP離れ渋滞からいくつかのトラフィックを迂回する別の経路を介して2つの混雑ネットワーク要素へのトラフィックを寄与することが知られているノード（ソースおよび宛先）、明示的ルートLSP間で作成することができます。一方、LSP-トンネルの広範な利用するオペレータは、いずれかの測定または自動トラフィック制御のために明示的経路の代替経路上の輻輳点を横断するLSPのサブセットを決定することができます。 LSPに関連した帯域幅パラメータを正確にするLSPによって運ばれる実際のトラフィックを表していない場合に迅速に対応するために用いることができ、オペレータは、帯域幅パラメータの値を変更すると問題に対処するか、持続していない可能性に効果的ではないかもしれないことを決定します影響。
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の様々な特性を設定するには、これらの経験的な統計情報を利用する他のアプローチがあります。これらのアプローチは、例えば、（また、オフラインTEとしても知られている[10]）のLSPの明示的なルートを設定するように誘導された統計情報を利用することができます。彼らはまた、様々なLSPな帯域幅、優先度、および親和性（オンラインTE）などの属性の値を設定する統計情報を利用することができます。これらのアプローチの全ては、ネットワーク内の輻輳に反応するように戦術的および戦略の両方を使用することができます。新しい回路の期待プロビジョニング・サイクルよりも長い機器や施設の故障、交通需要の予期せぬ急増：輻輳が多くの要因の結果として発生する可能性があります。
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をマッピングする親和性を用いて、各リンクを横断需要の割合を制御するために、LSPの帯域幅パラメータを使用することを含みます異なるリンクへ。溶液のこれらのタイプは、NxOC-3/48分の12トポロジーとして平行と複製トポロジを有するネットワークにも適用可能です。
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のセット、または[11]これらの組み合わせを有する一次LSPを関連付けることによって達成することができます。
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-トンネルのエンドポイントとして機能するノードの選択は慎重に検討する必要があります。で述べたように、LSPトンネルの仮想トポロジを工夫する際に、[9]、特別な考慮事項は、LSP-トンネルの多数が許可されていることをLSP-トンネルおよび制御粒度の大きい番号に関連付けられた操作の複雑さとのトレードオフに与えられるべきです。換言すれば、LSP-トンネル多数のネットワーク全体のトラフィックの分布をより細かく制御を可能にするが、ネットワーク運用の複雑さを増大させます。大規模なネットワークでは、[9]は、単純なLSPトンネル仮想トポロジで開始し、次いで観察または予想されるトラフィックフローパターンに基づいて追加の複雑さを導入することが望ましいことがあります。
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の）または過小報告物理リンク上の帯域幅を十分にはイベント駆動型基づいて、それらの通常の限界を超えフローを説明するために使用されるべきです。フローは、LSPの帯域幅パラメータのサイズを変更しなければならない時を示す傾向を監視する必要があります。フローは予想水準から異例の変化を検出するために、常に監視する必要があります。 unpolicedフローが大幅にその割り当てられた帯域幅を超えた場合、アクションは、根本原因を特定し、問題を解決するために取られるべきです。トラフィックポリシングは、一部のフローが自分の帯域幅パラメータを超え、他の対応の流れを妨げる場合は特に、輻輳問題に対処するために適用することができるオプションです。しかし、例外的な状況下でない限り、ネットワークのエッジではなく、コア内ポリシングアクションを適用するために通常より賢明です。
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の遷移または経路変更が発生した場合、パケットは影響を与え、ネットワーク・パフォーマンスを落としてもよいです。これは、LSPの変動性を最小化し、この不安定性を引き起こす根本原因を減らすためにMPLSを展開するネットワークの目標でなければなりません。残念ながら、経営支援、特に根本原因分析の正確なレベルを提供する機能で、この時点で利用可能な非常にいくつか、もしあれば、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のセットに、帯域幅などのリソースの割り当てを含みます。寸法・プロセスは、サービスの保護のためのいくつかの帯域予約方式の使用に関連したリンク容量パラメータまたはしきい値を決定します。サービス保護は、帯域幅へのアクセスを制限することにより、または他のトラフィックの1種類に優先的にアクセスを与えることによって、特定のサービスタイプのためのQoSを制御します。このような方法は、予想される短期間でのフローのためのリソースの最小量を保証するために、優先度の低いフローの飢餓を防ぐために、高帯域幅の要件とフローの合格確率を向上させるために、あるいはパフォーマンスを防止することにより、ネットワークの安定性を維持するために、例えば、必要不可欠です局所的な過負荷の場合に分解。
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要件を同時に満たすことができることを保証するために予防的制御の一形態です。しかし、それは十分に低い接続/フロー要求の拒否のための確率を維持するために適切なネットワーク寸法記入が必要です。
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のベンダー実装の問題を識別するために投資する必要があるかもしれません。 TEをサポートするためのMPLSソフトウェアと設定の管理面の初期展開は重要なエンジニアリング、オペレーション、およびシステム開発のリソースを消費することができます。ネットワーク要素のためのルータの設定を作成するために自動化されたシステムを開発することは重要なソフトウェア開発とハードウェアリソースを必要とすることができます。ルータの設定が自動化された方法で更新されているポイントへの行き方は時間のかかるプロセスになることができます。構成、またはこれらに関連する問題をルータに手動で微調整を追跡することは無限の作業になることができます。これが意味することは、はるかに簡素化し、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がネットワーク - の数であるLSPのO（N ^ 2）数を、作成フルメッシュを組み込む設計によって悪化することができ、ネットワーク増加のルータコンフィギュレーションデータの数としては特に真実でありますエッジノード。これらのケースでは、階層、地域化、またはトンネル終端ポイントの適切な選択を通して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.
広く展開されているが、このようなIS-IS、OSPF、およびBGPなどの古典的なIPルーティングプロトコルと比較すると、MPLS TEは新しい技術です。 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に共通のアプローチはコネクションから指向の接続に転送パラダイムを切り替えます。したがって、ネットワークの運用分析は、いくつかの点で複雑（そして他に改善）することができます。ドロップされたパケット内の転送状態の結果に矛盾がコネクションレスの方法でパケットがループして、ドロップ、またはいずれか一方は、ルーティングツリーの別のブランチに誤って誘導される一方。
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と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は、二つのルータおよび所定のネットワークトポロジを介してトラフィックのサブセットの転送パスを制御する能力との間のポイントツーポイントトラフィックの統計情報を監視する機能を兼ね備えています。これは、効果的にトラフィックをマッピングすることにより、ネットワークパフォーマンスを向上させるために適用して有用であるMPLSとトラフィックエンジニアリングは、サービスプロバイダーネットワーク内のリンク上に流れます。可能性を最大限に実現するために簡素化し、MPLS TE機能や活性化のヘルプを自動化するツール。
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ローゼン、E.、Viswanathanの、A.とR. Callon、 "アーキテクチャをマルチプロトコルラベルスイッチング、" 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.、マルコム、J.、Agogbua、J.、オデル、M.とJ.マクマナス、 "トラフィックエンジニアリングオーバー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.
"インターネットでのMPLSトラフィックエンジニアリングと、" 3 X.シャオ、A.阪南、B.ベイリー、およびL. Niは、IEEEネットワーク、月/ 2000年4月。
4 V. Springer, C. Pierantozzi, and J. Boyle, "Level3 MPLS Protocol Architecture," Work in Progress.
4 V.スプリンガー、C. Pierantozzi、及びJ.ボイル、 "レベル3 MPLSプロトコルアーキテクチャ、" 進行中の作業。
5 T. Li, and H. Smit, "IS-IS Extensions for Traffic Engineering," Work in Progress.
5 T.李、およびH.スミットは、「IS-ISトラフィックエンジニアリングのための拡張機能、」進行中の作業。
6 D. Katz, D. Yeung, and K. Kompella, "Traffic Engineering Extensions to OSPF," Work in Progress.
6 D.カッツ、D.ヨン、および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.、バーガー、L.、ガン、D.H.、李、T.、スリニバサン、V.およびG.ツバメ、 "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.、阪南、A.およびX.シャオ、 "LSP-トンネルのための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.、チウ、A.、Elwalid、A.、Widjaja、I.およびX.シャオ、 "概要とインターネットトラフィックエンジニアリングの原則"、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. McDysan、J.ボイル、M. Carlzon、R. Coltun、T.グリフィン、E.カーン、及びT. Reddington、 "ネットワーク階層多層生存性、" 進行中の作業。
12 D. Awduche, "MPLS and Traffic Engineering in IP Networks," IEEE Communications Magazine, December 1999.
12 D. Awduche、 "MPLSおよびIPネットワークにおけるトラフィックエンジニアリング、" IEEEコミュニケーションズ・マガジン、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.ライ、B.クリスチャン、R.W. Tibbs、およびS.ヴァンデンベルジェ、「インターネットトラフィックエンジニアリング測定のためのフレームワーク、」進行中の作業。
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でのトラフィックエンジニアリングに精通している開発者によって与えられ得た経験と先見性に大部分です。特に、著者は彼らのフォーカスを維持するために、今日の展開では、コードの要件の明確なアーティキュレーションのためのRFC 2702の作者だけでなく、開発者とテスターを確認したいです。
Jim Boyle Protocol Driven Networks Tel: +1 919-852-5160 EMail: jboyle@pdnets.com
+1 919-852-5160 Eメール：：jboyle@pdnets.comジム・ボイルプロトコルは、ネットワークの電話番号を主導します
Vijay Gill AOL Time Warner, Inc. 12100 Sunrise Valley Drive Reston, VA 20191 EMail: vijay@umbc.edu
ビジェイ・ギルAOLタイム・ワーナー社12100日の出バレードライブレストン、バージニア州20191 Eメール：vijay@umbc.edu
Alan Hannan RoutingLoop Intergalactic 112 Falkirk Court Sunnyvale, CA 94087, USA Tel: +1 408-666-2326 EMail: alan@routingloop.com
アラン・阪南RoutingLoop銀河系112フォルカーク裁判所サニーベール、CA 94087、USA電話：+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
デイブ・クーパーグローバル・クロッシング960ハムリン法廷サニーベール、CA 94089、USA電話：+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
ダニエルO. Awduche Movazネットワーク7926ジョーンズ支店ドライブ、スイート615マクリーン、VA 22102、USA電話：+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
ブレインクリスチャン・ワールドコム22001ラウドン郡パークウェイ、ルームD1-2-737アッシュバーン、VA 20147、USA電話：+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ローレルアベニューミドルタウン、NJ 07748、USA電話：+1 732-420-3712電子メール：wlai@att.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。