Network Working Group D. Awduche
Request for Comments: 2702 J. Malcolm
Category: Informational J. Agogbua
M. O'Dell
J. McManus
UUNET (MCI Worldcom)
September 1999
Requirements for Traffic Engineering Over 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 (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This document presents a set of requirements for Traffic Engineering over Multiprotocol Label Switching (MPLS). It identifies the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. These capabilities can be used to optimize the utilization of network resources and to enhance traffic oriented performance characteristics.
この文書では、マルチプロトコルラベルスイッチング（MPLS）を超えるトラフィックエンジニアリングのための要件のセットを提示します。これは、MPLSドメインにおける効率的で信頼性の高いネットワーク運用を促進する政策を実施するために必要な機能的能力を識別します。これらの機能は、ネットワークリソースの使用率を最適化し、交通指向の性能特性を向上させるために使用することができます。
Table of Contents
目次
1.0 Introduction ............................................. 2
1.1 Terminology .............................................. 3
1.2 Document Organization .................................... 3
2.0 Traffic Engineering ...................................... 4
2.1 Traffic Engineering Performance Objectives ............... 4
2.2 Traffic and Resource Control ............................. 6
2.3 Limitations of Current IGP Control Mechanisms ............ 6
3.0 MPLS and Traffic Engineering ............................. 7
3.1 Induced MPLS Graph ....................................... 9
3.2 The Fundamental Problem of Traffic Engineering Over MPLS . 9
4.0 Augmented Capabilities for Traffic Engineering Over MPLS . 10
5.0 Traffic Trunk Attributes and Characteristics ........... 10
5.1 Bidirectional Traffic Trunks ............................. 11
5.2 Basic Operations on Traffic Trunks ....................... 12
5.3 Accounting and Performance Monitoring .................... 12
5.4 Basic Attributes of Traffic Trunks ....................... 13
5.5 Traffic Parameter Attributes ............................ 14
5.6 Generic Path Selection and Management Attributes ......... 14
5.6.1 Administratively Specified Explicit Paths ................ 15
5.6.2 Hierarchy of Preference Rules for Multi-paths ............ 15
5.6.3 Resource Class Affinity Attributes ....................... 16
5.6.4 Adaptivity Attribute ..................................... 17
5.6.5 Load Distribution Across Parallel Traffic Trunks ......... 18
5.7 Priority Attribute ....................................... 18
5.8 Preemption Attribute ..................................... 18
5.9 Resilience Attribute ..................................... 19
5.10 Policing Attribute ...................................... 20
6.0 Resource Attributes ...................................... 21
6.1 Maximum Allocation Multiplier ............................ 21
6.2 Resource Class Attribute ................................ 22
7.0 Constraint-Based Routing ................................ 22
7.1 Basic Features of Constraint-Based Routing ............... 23
7.2 Implementation Considerations ............................ 24
8.0 Conclusion ............................................. 25
9.0 Security Considerations .................................. 26
10.0 References ............................................. 26
11.0 Acknowledgments .......................................... 27
12.0 Authors' Addresses ....................................... 28
13.0 Full Copyright Statement ................................. 29
Multiprotocol Label Switching (MPLS) [1,2] integrates a label swapping framework with network layer routing. The basic idea involves assigning short fixed length labels to packets at the ingress to an MPLS cloud (based on the concept of forwarding equivalence classes [1,2]). Throughout the interior of the MPLS domain, the labels attached to packets are used to make forwarding decisions (usually without recourse to the original packet headers).
マルチプロトコルラベルスイッチング（MPLS）[1,2]は、ネットワーク層ルーティングをフレームワークを交換ラベルを統合します。基本的な考え方は（同値類[1,2]を転送する概念に基づく）MPLSクラウドへの入力でのパケットに短い固定長ラベルを割り当てることを含みます。 MPLSドメインの内部を通して、パケットに添付ラベルは（通常、元のパケットヘッダに頼ることなく）転送決定を行うために使用されています。
A set of powerful constructs to address many critical issues in the emerging differentiated services Internet can be devised from this relatively simple paradigm. One of the most significant initial applications of MPLS will be in Traffic Engineering. The importance of this application is already well-recognized (see [1,2,3]).
新興の差別化サービスをインターネットで多くの重要な問題に対処するための強力な構文のセットは、この比較的単純なパラダイムから考案することができます。 MPLSの最も重要な最初のアプリケーションの一つは、トラフィックエンジニアリングになります。このアプリケーションの重要性は既に十分に認識されており（[1,2,3]を参照）。
This manuscript is exclusively focused on the Traffic Engineering applications of MPLS. Specifically, the goal of this document is to highlight the issues and requirements for Traffic Engineering in a large Internet backbone. The expectation is that the MPLS specifications, or implementations derived therefrom, will address the realization of these objectives. A description of the basic capabilities and functionality required of an MPLS implementation to accommodate the requirements is also presented.
この原稿は、もっぱらMPLSのトラフィックエンジニアリングアプリケーションに焦点を当てています。具体的には、このドキュメントの目標は、大規模なインターネットバックボーンにトラフィックエンジニアリングのための問題や要件を強調することです。期待がそれに由来するMPLSの仕様、または実装は、これらの目標の実現に取り組むことです。要件に対応するために、MPLSの実装に必要な基本的な機能と機能の説明も提示されています。
It should be noted that even though the focus is on Internet backbones, the capabilities described in this document are equally applicable to Traffic Engineering in enterprise networks. In general, the capabilities can be applied to any label switched network under a single technical administration in which at least two paths exist between two nodes.
フォーカスがインターネットバックボーン上にあるにもかかわらず、このドキュメントで説明する機能は、企業ネットワークにおけるトラフィックエンジニアリングにも同様に適用可能であることに留意すべきです。一般的に、機能は、任意のラベルに適用することができる少なくとも2つのパスが2つのノード間に存在する単一の技術的管理の下網。
Some recent manuscripts have focused on the considerations pertaining to Traffic Engineering and Traffic management under MPLS, most notably the works of Li and Rekhter [3], and others. In [3], an architecture is proposed which employs MPLS and RSVP to provide scalable differentiated services and Traffic Engineering in the Internet. The present manuscript complements the aforementioned and similar efforts. It reflects the authors' operational experience in managing a large Internet backbone.
いくつかの最近の写本は、MPLSトラフィックエンジニアリング下およびトラフィック管理に関する考慮事項、Liと[3] Rekhter、およびその他の最も顕著な作品に焦点を当てています。 [3]、アーキテクチャは、インターネットにスケーラブル差別化サービス及びトラヒックエンジニアリングを提供するMPLSおよびRSVPを採用が提案されています。現在の原稿は、前述と同様の取り組みを補完します。これは、大規模なインターネットバックボーンを管理する上で著者の運用経験を反映しています。
The reader is assumed to be familiar with the MPLS terminology as defined in [1].
読者は、[1]で定義されるようにMPLSの用語に精通していると仮定されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [11].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [11]に記載されているように解釈されます。
The remainder of this document is organized as follows: Section 2 discusses the basic functions of Traffic Engineering in the Internet. Section 3, provides an overview of the traffic Engineering potentials of MPLS. Sections 1 to 3 are essentially background material. Section 4 presents an overview of the fundamental requirements for Traffic Engineering over MPLS. Section 5 describes the desirable attributes and characteristics of traffic trunks which are pertinent to Traffic Engineering. Section 6 presents a set of attributes which can be associated with resources to constrain the routability of traffic trunks and LSPs through them. Section 7 advocates the introduction of a "constraint-based routing" framework in MPLS domains. Finally, Section 8 contains concluding remarks.
このドキュメントの残りは以下の通り構成されています。第2節では、インターネットにおけるトラフィックエンジニアリングの基本的な機能について説明します。第3節では、MPLSのトラフィックエンジニアリングポテンシャルの概要を説明します。セクション1〜3は、本質的にバックグラウンド物質です。第4章では、MPLSを超えるトラフィックエンジニアリングのための基本的な要件の概要を説明します。第5節では、トラフィックエンジニアリングに関連しているトラフィックトランクの望ましい属性や特性について説明します。第6節は、それらを介してトラフィックのトランクとLSPの配線性を制約するためのリソースと関連付けることができる属性のセットを提供します。セクション7は、MPLSドメイン内の「制約ベースのルーティング」の枠組みの導入を提唱します。最後に、第8節は結びの発言が含まれています。
This section describes the basic functions of Traffic Engineering in an Autonomous System in the contemporary Internet. The limitations of current IGPs with respect to traffic and resource control are highlighted. This section serves as motivation for the requirements on MPLS.
このセクションでは、現代のインターネットで自律システムにおけるトラフィックエンジニアリングの基本的な機能について説明します。トラフィックおよびリソース制御に対する電流のIGPの限界が強調表示されます。このセクションでは、MPLS上の要件のための動機として機能します。
Traffic Engineering (TE) is concerned with performance optimization of operational networks. In general, it encompasses the application of technology and scientific principles to the measurement, modeling, characterization, and control of Internet traffic, and the application of such knowledge and techniques to achieve specific performance objectives. The aspects of Traffic Engineering that are of interest concerning MPLS are measurement and control.
トラフィックエンジニアリング（TE）は、運用ネットワークのパフォーマンスの最適化との関係です。一般的には、計測、モデリング、特性評価、およびインターネットトラフィックの制御、および特定の性能目標を達成するために、このような知識や技術の応用への技術および科学の原則の適用を包含する。 MPLSに関する関心のあるトラフィックエンジニアリングの側面は、計測・制御されています。
A major goal of Internet Traffic Engineering is to facilitate efficient and reliable network operations while simultaneously optimizing network resource utilization and traffic performance. Traffic Engineering has become an indispensable function in many large Autonomous Systems because of the high cost of network assets and the commercial and competitive nature of the Internet. These factors emphasize the need for maximal operational efficiency.
インターネットトラフィックエンジニアリングの主要な目標は、同時にネットワークリソースの使用率とトラフィックのパフォーマンスを最適化しながら、効率的で信頼性の高いネットワーク運用を容易にすることです。トラフィックエンジニアリングは、ネットワークの資産の高コストとインターネットの商業および競争力の性質の多くの大規模な自律システムに不可欠な機能となっています。これらの要因は、最大の運用効率の必要性を強調する。
The key performance objectives associated with traffic engineering can be classified as being either:
トラフィックエンジニアリングに関連した主要性能目標は、どちらかに分類することができます。
Traffic oriented performance objectives include the aspects that enhance the QoS of traffic streams. In a single class, best effort Internet service model, the key traffic oriented performance objectives include: minimization of packet loss, minimization of delay, maximization of throughput, and enforcement of service level agreements. Under a single class best effort Internet service model, minimization of packet loss is one of the most important traffic oriented performance objectives. Statistically bounded traffic oriented performance objectives (such as peak to peak packet delay variation, loss ratio, and maximum packet transfer delay) might become useful in the forthcoming differentiated services Internet.
交通指向の性能目標は、トラフィックストリームのQoSを向上させる側面が含まれます。単一のクラス、ベストエフォート型のインターネット・サービス・モデルでは、主要な交通指向の性能目標は、次のとおりです。パケット損失の最小化、遅延の最小化、スループットの最大化、およびサービス・レベル・アグリーメントの施行を。単一のクラスベストエフォート型のインターネット・サービス・モデルでは、パケット損失の最小化が最も重要な交通指向のパフォーマンス目標の一つです。統計的に（例えば、ピークパケット遅延変動、損失率、および最大パケット転送遅延をピークとして）有界交通指向の性能目標は、今後の差別化サービスをインターネットで有用になるかもしれません。
Resource oriented performance objectives include the aspects pertaining to the optimization of resource utilization. Efficient management of network resources is the vehicle for the attainment of resource oriented performance objectives. In particular, it is generally desirable to ensure that subsets of network resources do not become over utilized and congested while other subsets along alternate feasible paths remain underutilized. Bandwidth is a crucial resource in contemporary networks. Therefore, a central function of Traffic Engineering is to efficiently manage bandwidth resources.
リソース指向の性能目標は、リソース使用率の最適化に関連する側面が含まれます。ネットワークリソースの効率的な管理は、リソース指向のパフォーマンス目標の達成のための車両です。特に、ネットワークリソースのサブセットを利用し、代替可能経路に沿った他のサブセットが活用されていないまま輻輳オーバーにならないことを保証することが一般に望ましいです。帯域幅は、現代のネットワークで重要な資源です。そのため、トラフィックエンジニアリングの中心的機能は、効率的な帯域幅のリソースを管理することです。
Minimizing congestion is a primary traffic and resource oriented performance objective. The interest here is on congestion problems that are prolonged rather than on transient congestion resulting from instantaneous bursts. Congestion typically manifests under two scenarios:
混雑を最小にすることが主なトラフィックとリソース指向のパフォーマンスの目的です。ここでの関心は、瞬間のバーストから生じた過渡渋滞にではなく、長期化している輻輳問題です。輻輳は、一般的に2つのシナリオの下で現れます。
1. When network resources are insufficient or inadequate to accommodate offered load.
ネットワークリソースが与えられた負荷に対応するには不十分または不適当である1。
2. When traffic streams are inefficiently mapped onto available resources; causing subsets of network resources to become over-utilized while others remain underutilized.
トラフィックストリームが非効率的に利用可能なリソースにマッピングされる2。他の人が活用されていないままネットワークリソースのサブセットの過剰利用になることを引き起こします。
The first type of congestion problem can be addressed by either: (i) expansion of capacity, or (ii) application of classical congestion control techniques, or (iii) both. Classical congestion control techniques attempt to regulate the demand so that the traffic fits onto available resources. Classical techniques for congestion control include: rate limiting, window flow control, router queue management, schedule-based control, and others; (see [8] and the references therein).
（I）の容量の拡大、または古典的な輻輳制御技術の（ii）のアプリケーション、または（iii）の両方：輻輳問題の第一のタイプのいずれかによって対処することができます。古典的な輻輳制御技術は、トラフィックが利用可能なリソースに収まるように需要を規制しようとします。輻輳制御のためのクラシックの技術が含まれます：レート制限、ウィンドウフロー制御、ルータのキュー管理、スケジュールベースの制御、および他の人を、 （[8]およびその中の参考文献を参照されたいです）。
The second type of congestion problems, namely those resulting from inefficient resource allocation, can usually be addressed through Traffic Engineering.
輻輳問題、非効率的な資源配分に起因する、すなわち、これらの第二のタイプは、通常、トラフィックエンジニアリングによって対処することができます。
In general, congestion resulting from inefficient resource allocation can be reduced by adopting load balancing policies. The objective of such strategies is to minimize maximum congestion or alternatively to minimize maximum resource utilization, through efficient resource allocation. When congestion is minimized through efficient resource allocation, packet loss decreases, transit delay decreases, and aggregate throughput increases. Thereby, the perception of network service quality experienced by end users becomes significantly enhanced.
一般に、非効率的な資源配分に起因する輻輳がロード・バランシング・ポリシーを採用することによって低減することができます。そのような戦略の目的は、最大輻輳を最小限にするために、または代替的に最大リソース利用を最小限に抑えるために、効率的な資源配分を介してです。輻輳が効率的な資源配分を介して最小化される場合、パケットロスが小さく、伝送遅延は減少し、総スループットが増加します。これにより、エンドユーザーが経験するネットワークサービス品質の認識が大幅に強化されてしまいます。
Clearly, load balancing is an important network performance optimization policy. Nevertheless, the capabilities provided for Traffic Engineering should be flexible enough so that network administrators can implement other policies which take into account the prevailing cost structure and the utility or revenue model.
明らかに、負荷分散が重要なネットワークパフォーマンスの最適化の方針です。ネットワーク管理者は、アカウントに実勢コスト構造およびユーティリティや収入モデルを取る他のポリシーを実装することが可能にもかかわらず、トラフィックエンジニアリングのために提供される機能は十分に柔軟であるべきです。
Performance optimization of operational networks is fundamentally a control problem. In the traffic engineering process model, the Traffic Engineer, or a suitable automaton, acts as the controller in an adaptive feedback control system. This system includes a set of interconnected network elements, a network performance monitoring system, and a set of network configuration management tools. The Traffic Engineer formulates a control policy, observes the state of the network through the monitoring system, characterizes the traffic, and applies control actions to drive the network to a desired state, in accordance with the control policy. This can be accomplished reactively by taking action in response to the current state of the network, or pro-actively by using forecasting techniques to anticipate future trends and applying action to obviate the predicted undesirable future states.
運用ネットワークのパフォーマンスの最適化は、基本的に制御問題です。トラフィック・エンジニアリング・プロセス・モデルでは、トラフィックエンジニア、または適切なオートマトンは、適応フィードバック制御システムのコントローラとして機能します。このシステムは、相互接続されたネットワーク要素のセット、ネットワークパフォーマンス監視システム、およびネットワーク構成管理ツールのセットを含みます。トラフィックエンジニアが制御ポリシーを策定、監視システムを介してネットワークの状態を観察するトラフィックを特徴付ける、および制御ポリシーに従って、所望の状態にネットワークを駆動するための制御動作を適用します。これは、今後の動向を予測する予測技術を使用して予測望ましくない未来の状態を回避するためにアクションを適用することによって、ネットワークの現在の状態に応じた行動をとる、または積極的で反動達成することができます。
Ideally, control actions should involve:
理想的には、制御アクションが関与する必要があります。
3. Modification of attributes and constraints associated with resources.
リソースに関連付けられた属性と制約の3。変形。
The level of manual intervention involved in the traffic engineering process should be minimized whenever possible. This can be accomplished by automating aspects of the control actions described above, in a distributed and scalable fashion.
トラフィックエンジニアリングプロセスに関与する手動介入のレベルは、可能な限り最小限にすべきです。これは、分散型でスケーラブルな様式で、上述した制御動作の側面を自動化することによって達成することができます。
This subsection reviews some of the well known limitations of current IGPs with regard to Traffic Engineering.
このサブセクションでは、トラフィックエンジニアリングに関しては、現在のIGPのよく知られた制限のいくつかをレビュー。
The control capabilities offered by existing Internet interior gateway protocols are not adequate for Traffic Engineering. This makes it difficult to actualize effective policies to address network performance problems. Indeed, IGPs based on shortest path algorithms contribute significantly to congestion problems in Autonomous Systems within the Internet. SPF algorithms generally optimize based on a simple additive metric. These protocols are topology driven, so bandwidth availability and traffic characteristics are not factors considered in routing decisions. Consequently, congestion frequently occurs when:
既存のインターネット内部ゲートウェイ・プロトコルによって提供される制御機能は、トラフィックエンジニアリングのために適切ではありません。これは、それが困難なネットワークパフォーマンスの問題に対処するための効果的な政策を実現することができます。確かに、最短経路アルゴリズムに基づいてのIGPは、インターネット内の自律システムにおける輻輳問題に大きく貢献します。 SPFアルゴリズムは、一般的に、単純な加法メトリックに基づいて最適化します。これらのプロトコルは、トポロジードリブンなので、帯域幅の可用性、およびトラフィックの特性は、ルーティングの決定に考慮した要因ではありません。その結果、輻輳が頻繁に発生する場合：
1. the shortest paths of multiple traffic streams converge on specific links or router interfaces, or
1.複数のトラフィックストリームの最短経路は、特定のリンクまたはルータインターフェイス上で収束する、または
2. a given traffic stream is routed through a link or router interface which does not have enough bandwidth to accommodate it.
2.特定のトラフィックストリームは、それに対応するために十分な帯域幅を持っていないリンクやルータのインタフェースを介してルーティングされます。
These scenarios manifest even when feasible alternate paths with excess capacity exist. It is this aspect of congestion problems (-- a symptom of suboptimal resource allocation) that Traffic Engineering aims to vigorously obviate. Equal cost path load sharing can be used to address the second cause for congestion listed above with some degree of success, however it is generally not helpful in alleviating congestion due to the first cause listed above and particularly not in large networks with dense topology.
これらのシナリオは、過剰容量の実現可能な代替経路が存在する場合にも現れます。トラフィックエンジニアリングを激しく解消することを目指していること - （次善のリソース割り当ての症状）これは、輻輳問題のこの局面です。イコールコストパスの負荷分散は、ある程度の成功して上に記載されている渋滞のための第2の原因に対処するために使用することができ、しかし、それは一般的に起因する上で、特にない密なトポロジーを持つ大規模なネットワークにリストされた最初の原因に混雑を緩和するのに有用ではありません。
A popular approach to circumvent the inadequacies of current IGPs is through the use of an overlay model, such as IP over ATM or IP over frame relay. The overlay model extends the design space by enabling arbitrary virtual topologies to be provisioned atop the network's physical topology. The virtual topology is constructed from virtual circuits which appear as physical links to the IGP routing protocols. The overlay model provides additional important services to support traffic and resource control, including: (1) constraint-based routing at the VC level, (2) support for administratively configurable explicit VC paths, (3) path compression, (4) call admission control functions, (5) traffic shaping and traffic policing functions, and (6) survivability of VCs. These capabilities enable the actualization of a variety of Traffic Engineering policies. For example, virtual circuits can easily be rerouted to move traffic from over-utilized resources onto relatively underutilized ones.
現在のIGPの欠点を回避する一般的な方法は、フレームリレー上ATM又はIPオーバーIPなどのオーバレイモデルの使用によるものです。オーバーレイモデルは、ネットワークの物理トポロジ上にプロビジョニングされるように任意の仮想トポロジを有効にすることで、設計空間を拡張します。仮想トポロジがIGPルーティングプロトコルの物理リンクとして表示される仮想回路から構成されています。管理設定明示的なVCパス（2）支持体、（3）パス圧縮、（4）コールアドミッション、VCレベルで（1）制約ベースのルーティング：オーバーレイ・モデルは、以下を含むトラフィックとリソース制御をサポートするための追加の重要なサービスを提供します制御機能、（5）トラフィックシェーピングとトラフィックポリシング機能、およびVCの（6）生存。これらの機能は、トラフィックエンジニアリングポリシーの様々な顕在を有効にします。例えば、仮想回路を容易比較的活用されていないものに過剰利用資源からのトラフィックを移動させるように再ルーティングすることができます。
For Traffic Engineering in large dense networks, it is desirable to equip MPLS with a level of functionality at least commensurate with current overlay models. Fortunately, this can be done in a fairly straight forward manner.
大規模な密なネットワークのトラフィックエンジニアリングのために、現在のオーバーレイモデルと、少なくとも見合った機能のレベルでMPLSを装備することが望ましいです。幸いなことに、これはかなりまっすぐ進む方法で行うことができます。
This section provides an overview of the applicability of MPLS to Traffic Engineering. Subsequent sections discuss the set of capabilities required to meet the Traffic Engineering requirements.
このセクションでは、トラフィックエンジニアリングへのMPLSの適用の概要を説明します。以降のセクションでは、トラフィックエンジニアリングの要件を満たすために必要な機能のセットを議論します。
MPLS is strategically significant for Traffic Engineering because it can potentially provide most of the functionality available from the overlay model, in an integrated manner, and at a lower cost than the currently competing alternatives. Equally importantly, MPLS offers the possibility to automate aspects of the Traffic Engineering function. This last consideration requires further investigation and is beyond the scope of this manuscript.
それは潜在的に統合された方法で、現在は競合する選択肢よりも低コストで、オーバーレイモデルから利用可能な機能のほとんどを提供することができるので、MPLSは、トラフィックエンジニアリングのための戦略的に重要です。同様に重要なのは、MPLSトラフィックエンジニアリング機能の側面を自動化する可能性を提供しています。この最後の考慮事項は、さらなる調査が必要であり、この原稿の範囲を超えています。
A note on terminology: The concept of MPLS traffic trunks is used extensively in the remainder of this document. According to Li and Rekhter [3], a traffic trunk is an aggregation of traffic flows of the same class which are placed inside a Label Switched Path. Essentially, a traffic trunk is an abstract representation of traffic to which specific characteristics can be associated. It is useful to view traffic trunks as objects that can be routed; that is, the path through which a traffic trunk traverses can be changed. In this respect, traffic trunks are similar to virtual circuits in ATM and Frame Relay networks. It is important, however, to emphasize that there is a fundamental distinction between a traffic trunk and the path, and indeed the LSP, through which it traverses. An LSP is a specification of the label switched path through which the traffic traverses. In practice, the terms LSP and traffic trunk are often used synonymously. Additional characteristics of traffic trunks as used in this manuscript are summarized in section 5.0.
用語に関する注記：MPLSトラフィックトランクの概念は、この文書の残りの部分で広く使用されています。 LiおよびRekhterによれば[3]、トラフィックトランクはラベルスイッチパスの内側に配置されている同じクラスのトラフィックフローの集合です。本質的に、トラフィックトランクは、特定の特性を関連付けることができる先のトラフィックの抽象的表現です。ルーティングすることができるオブジェクトとしてトラフィックトランクを表示するのに便利です。つまり、パスがそれを通してトラフィックトランクトラバースを変更することができます。この点で、トラフィックトランクは仮想ATM内の回路やフレームリレーネットワークに似ています。それが横断する通過交通幹線とパスの間に根本的な違い、そして実際LSPがあることを強調することが重要です。 LSPは、ラベルの仕様は、トラフィックが通過する経路を切り替えています。実際には、用語のLSPとトラフィックトランクは、多くの場合、同義的に使用されています。この原稿で使用されるトラフィックトランクの追加の特性は、セクション5.0にまとめられています。
The attractiveness of MPLS for Traffic Engineering can be attributed to the following factors: (1) explicit label switched paths which are not constrained by the destination based forwarding paradigm can be easily created through manual administrative action or through automated action by the underlying protocols, (2) LSPs can potentially be efficiently maintained, (3) traffic trunks can be instantiated and mapped onto LSPs, (4) a set of attributes can be associated with traffic trunks which modulate their behavioral characteristics, (5) a set of attributes can be associated with resources which constrain the placement of LSPs and traffic trunks across them, (6) MPLS allows for both traffic aggregation and disaggregation whereas classical destination only based IP forwarding permits only aggregation, (7) it is relatively easy to integrate a "constraint-based routing" framework with MPLS, (8) a good implementation of MPLS can offer significantly lower overhead than competing alternatives for Traffic Engineering.
トラヒックエンジニアリングのためのMPLSの魅力は、以下の要因に帰することができる：（1）明示的なラベルは、（基本的なプロトコルにより容易に手動管理アクションによって、または自動アクションを使用して作成することができる宛先ベースの転送パラダイムによって制約されていない経路を切り替えます2）のLSPは、潜在的に効率的に維持することができる、（3）トラフィックトランク（4）属性のセットは、それらの動作特性を調節するトラフィックトランクに関連付けることができ、LSPの上にインスタンス化とマッピングすることができる、（5）属性のセットとすることができますそれらを横断するLSPとトラフィックトランクの配置を制約するリソースに関連付けられた、古典的な宛先のみ基づくIP転送のみ凝集を可能にする一方、（6）、MPLS（7）が「CONSTRAINT-を統合することは比較的容易であり、トラフィック凝集および脱凝集の両方を可能にしますベースのルーティング」MPLSとフレームワークは、（8）MPLSの良い実装は、競合の代替よりも有意に低いオーバーヘッドを提供することができトラフィックエンジニアリングのための。
Additionally, through explicit label switched paths, MPLS permits a quasi circuit switching capability to be superimposed on the current Internet routing model. Many of the existing proposals for Traffic Engineering over MPLS focus only on the potential to create explicit LSPs. Although this capability is fundamental for Traffic Engineering, it is not really sufficient. Additional augmentations are required to foster the actualization of policies leading to performance optimization of large operational networks. Some of the necessary augmentations are described in this manuscript.
さらに、明示的なラベルを介してパスを切り替え、MPLSは、現在のインターネットルーティングモデルに重畳する擬似回線交換機能を可能にします。 MPLSを超えるトラフィックエンジニアリングのための既存の提案の多くは、明示的にLSPを作成するための可能性にのみ焦点を当てます。この機能は、トラフィックエンジニアリングの基本ですが、それは本当に十分ではありません。追加の拡張製品は、大規模な運用ネットワークのパフォーマンスの最適化につながる政策の顕在化を促進するために必要とされています。必要に応じて、一部の拡張は、この原稿で説明されています。
This subsection introduces the concept of an "induced MPLS graph" which is central to Traffic Engineering in MPLS domains. An induced MPLS graph is analogous to a virtual topology in an overlay model. It is logically mapped onto the physical network through the selection of LSPs for traffic trunks.
ここでは、MPLSドメイン内のトラフィックエンジニアリングの中心である「誘発MPLSグラフ」の概念を導入しています。誘発MPLSグラフは、オーバーレイモデルで仮想トポロジーに似ています。これは、論理的にトラフィックトランクのLSPの選択により、物理ネットワーク上にマッピングされます。
An induced MPLS graph consists of a set of LSRs which comprise the nodes of the graph and a set of LSPs which provide logical point to point connectivity between the LSRs, and hence serve as the links of the induced graph. it may be possible to construct hierarchical induced MPLS graphs based on the concept of label stacks (see [1]).
誘導されたMPLSのグラフは、グラフのノードとのLSR間の接続を指し、したがって誘起グラフのリンクとして機能する論理ポイントを提供するLSPのセットを含むのLSRのセットからなります。それはラベルスタックの概念に基づく階層誘起MPLSグラフを構築することも可能である（参照[1]）。
Induced MPLS graphs are important because the basic problem of bandwidth management in an MPLS domain is the issue of how to efficiently map an induced MPLS graph onto the physical network topology. The induced MPLS graph abstraction is formalized below.
MPLSドメイン内の帯域幅管理の基本的な問題は、効率的に物理的なネットワークトポロジ上に誘起されるMPLSのグラフをマッピングする方法の問題であるので、誘導されたMPLSグラフが重要です。誘発MPLSグラフの抽象化は、以下の形式化されています。
Let G = (V, E, c) be a capacitated graph depicting the physical topology of the network. Here, V is the set of nodes in the network and E is the set of links; that is, for v and w in V, the object (v,w) is in E if v and w are directly connected under G. The parameter "c" is a set of capacity and other constraints associated with E and V. We will refer to G as the "base" network topology.
ネットワークの物理トポロジを示す能力付与グラフである（C、V、E）Gが=ましょう。ここで、Vは、ネットワーク内のノードの集合であり、Eはリンクの集合です。 V及びWは、直接G.パラメータ「C」の下に接続されている場合、すなわち、Vは、オブジェクト（V、W）VおよびwはE及びV.我々に関連した能力のセットと他の制約がEであります「ベース」ネットワークトポロジーとしてGを参照します。
Let H = (U, F, d) be the induced MPLS graph, where U is a subset of V representing the set of LSRs in the network, or more precisely the set of LSRs that are the endpoints of at least one LSP. Here, F is the set of LSPs, so that for x and y in U, the object (x, y) is in F if there is an LSP with x and y as endpoints. The parameter "d" is the set of demands and restrictions associated with F. Evidently, H is a directed graph. It can be seen that H depends on the transitivity characteristics of G.
H =（U、F、d）はUがネットワーク内のLSRのセットを表すVのサブセットである誘起MPLSグラフ、またはより正確には少なくとも一つのLSPの端点であるのLSRの集合とします。 LSPは、エンドポイントとして、xとyとがある場合、ここで、Fは、LSPのセットは、そのようにすると、Uでxとyのために、オブジェクト（x、y）はFであるています。パラメータ「d」は明らかF.関連付けられた要求と制約の集合であり、Hは、有向グラフです。 HがGの推移特性に依存することがわかります
There are basically three fundamental problems that relate to Traffic Engineering over MPLS.
MPLS上のトラフィックエンジニアリングに関連する基本的に3つの基本的な問題があります。
- The first problem concerns how to map packets onto forwarding equivalence classes.
- 最初の問題は、転送等価クラスへパケットをマッピングする方法に関するものです。
- The second problem concerns how to map forwarding equivalence classes onto traffic trunks.
- 第二の問題は、トラフィックのトランクに転送等価クラスをマッピングする方法に関するものです。
- The third problem concerns how to map traffic trunks onto the physical network topology through label switched paths.
- 第3の問題は、パスをラベルスイッチによって物理的なネットワークトポロジへのトラフィックトランクをマップする方法に関するものです。
This document is not focusing on the first two problems listed. (even-though they are quite important). Instead, the remainder of this manuscript will focus on the capabilities that permit the third mapping function to be performed in a manner resulting in efficient and reliable network operations. This is really the problem of mapping an induced MPLS graph (H) onto the "base" network topology (G).
このドキュメントは、記載された最初の二つの問題に焦点を当てていません。 （彼らは非常に重要であっても-が）。代わりに、この原稿の残りの部分は、第三のマッピング関数は、効率的で信頼性の高いネットワーク・オペレーションをもたらす方法で実行することが可能な機能に焦点を当てます。これは本当に「ベース」ネットワークトポロジ（G）に誘起されるMPLSグラフ（H）のマッピングの問題です。
The previous sections reviewed the basic functions of Traffic Engineering in the contemporary Internet. The applicability of MPLS to that activity was also discussed. The remaining sections of this manuscript describe the functional capabilities required to fully support Traffic Engineering over MPLS in large networks.
前のセクションでは、現代のインターネットでトラフィックエンジニアリングの基本的な機能を検討しました。その活動へのMPLSの適用可能性についても議論しました。この原稿の残りのセクションでは、完全に大規模なネットワークでMPLS上でトラフィックエンジニアリングをサポートするために必要な機能的能力を記述する。
The proposed capabilities consist of:
提案された機能は、で構成されています。
1. A set of attributes associated with traffic trunks which collectively specify their behavioral characteristics.
1.総称して彼らの行動特性を指定するトラフィックトランクに関連付けられた属性のセット。
2. A set of attributes associated with resources which constrain the placement of traffic trunks through them. These can also be viewed as topology attribute constraints.
2.それらを介してトラフィックトランクの配置を制約リソースに関連付けられた属性のセット。また、これらは、トポロジー属性の制約とみなすことができます。
3. A "constraint-based routing" framework which is used to select paths for traffic trunks subject to constraints imposed by items 1) and 2) above. The constraint-based routing framework does not have to be part of MPLS. However, the two need to be tightly integrated together.
3.「制約ベースのルーティング」の項目1によって課される制約を受けるトラフィックトランクのパスを選択するために使用されるフレームワーク）及び2）上記。制約ベースのルーティングフレームワークは、MPLSの一部である必要はありません。しかし、二人は一緒に緊密に統合する必要があります。
The attributes associated with traffic trunks and resources, as well as parameters associated with routing, collectively represent the control variables which can be modified either through administrative action or through automated agents to drive the network to a desired state.
トラフィックトランクおよびリソースに関連付けられた属性、ならびにルーティングに関連するパラメータは、集合的に所望の状態にネットワークを駆動する管理アクションによって、または自動化された薬剤のいずれかを介して変更することができる制御変数を表します。
In an operational network, it is highly desirable that these attributes can be dynamically modified online by an operator without adversely disrupting network operations.
運用ネットワークでは、これらの属性を動的に悪影響ネットワークの運用を中断することなく、オペレータにより、オンラインで変更することができることが非常に望ましいです。
This section describes the desirable attributes which can be associated with traffic trunks to influence their behavioral characteristics.
このセクションでは、彼らの行動特性に影響を与えるために、トラフィックのトランクに関連付けることができ、望ましい属性について説明します。
First, the basic properties of traffic trunks (as used in this manuscript) are summarized below:
まず、交通トランクス（この原稿に使用されるような）の基本的な性質を以下にまとめます。
- A traffic trunk is an *aggregate* of traffic flows belonging to the same class. In some contexts, it may be desirable to relax this definition and allow traffic trunks to include multi-class traffic aggregates.
- トラフィックトランクは、トラフィックの集約* *は、同じクラスに属する流れています。いくつかの状況では、この定義を緩和し、トラフィックトランクが多クラスのトラフィックの凝集体を含めることができるようにすることが望ましいことがあります。
- In a single class service model, such as the current Internet, a traffic trunk could encapsulate all of the traffic between an ingress LSR and an egress LSR, or subsets thereof.
- 単一クラスのサービスモデルでは、このような現在のインターネットのような、トラフィックトランクは、入口LSRと出口LSR、またはそのサブセット間のトラフィックのすべてをカプセル化することができました。
- Traffic trunks are routable objects (similar to ATM VCs).
- 交通トランクは（ATMのVCに似て）ルーティング可能なオブジェクトです。
- A traffic trunk is distinct from the LSP through which it traverses. In operational contexts, a traffic trunk can be moved from one path onto another.
- トラフィックのトランクは、それが横断する通過LSPとは区別されます。運用状況では、トラフィックのトランクは別の上に1本のパスから移動することができます。
- A traffic trunk is unidirectional.
- トラフィックのトランクは一方向です。
In practice, a traffic trunk can be characterized by its ingress and egress LSRs, the forwarding equivalence class which is mapped onto it, and a set of attributes which determine its behavioral characteristics.
実際には、トラフィックトランクはその入口と出口LSRs、その上にマッピングされる転送等価クラス、及びその動作特性を決定する属性の組によって特徴付けることができます。
Two basic issues are of particular significance: (1) parameterization of traffic trunks and (2) path placement and maintenance rules for traffic trunks.
二つの基本的な問題は、特に重要である：トラフィックトランクのトラフィックトランクおよび（2）パスの配置やメンテナンスのルール（1）パラメータ設定。
Although traffic trunks are conceptually unidirectional, in many practical contexts, it is useful to simultaneously instantiate two traffic trunks with the same endpoints, but which carry packets in opposite directions. The two traffic trunks are logically coupled together. One trunk, called the forward trunk, carries traffic from an originating node to a destination node. The other trunk, called the backward trunk, carries traffic from the destination node to the originating node. We refer to the amalgamation of two such traffic trunks as one bidirectional traffic trunk (BTT) if the following two conditions hold:
トラフィックのトランクは、多くの実用的な状況では、概念的には単方向ですが、同時に、同じエンドポイントと2つのトラフィックトランクをインスタンス化するのに便利ですが、これは反対方向にパケットを運びます。 2つのトラフィックトランクは、論理的に互いに結合されています。 1つのトランクは、前方のトランクと呼ばれ、元のノードから宛先ノードへのトラフィックを運びます。後方トランクと呼ばれる他のトランクは、発信元ノードに宛先ノードからトラフィックを運びます。私たちは、1つの双方向トラフィックトランク（BTT）は、次の2つの条件が保持している場合などの2つのようなトラフィックトランクの融合を参照してください。
- Both traffic trunks are instantiated through an atomic action at one LSR, called the originator node, or through an atomic action at a network management station.
- 両方のトラフィックトランクは発信元ノードと呼ばれるものLSRの原子作用を介して、またはネットワーク管理ステーションでアトミック作用によりインスタンス化されています。
- Neither of the composite traffic trunks can exist without the other. That is, both are instantiated and destroyed together.
- 複合交通トランクのどちらも他なしでは存在できます。つまり、両方がインスタンス化されると一緒に破壊しました。
The topological properties of BTTs should also be considered. A BTT can be topologically symmetric or topologically asymmetric. A BTT is said to be "topologically symmetric" if its constituent traffic trunks are routed through the same physical path, even though they operate in opposite directions. If, however, the component traffic trunks are routed through different physical paths, then the BTT is said to be "topologically asymmetric."
BTTSの位相的性質も考慮しなければなりません。 BTTは、位相幾何学的対称または位相幾何学的非対称することができます。 BTTは、彼らが反対方向に作動していても、それを構成するトラフィックトランクが同じ物理パスを介してルーティングされる場合は、「位相幾何学的対称」と言われています。しかし、成分トラフィックトランクが異なる物理的経路を介してルーティングされる場合、BTTがあると言われている「位相幾何学的非対称」。
It should be noted that bidirectional traffic trunks are merely an administrative convenience. In practice, most traffic engineering functions can be implemented using only unidirectional traffic trunks.
双方向のトラフィックトランクが単なる行政便利であることに留意されたいです。実際には、ほとんどのトラフィックエンジニアリング機能は、単方向トラフィックトランクを使用して実装することができます。
The basic operations on traffic trunks significant to Traffic Engineering purposes are summarized below.
トラフィックエンジニアリングの目的への重要な交通トランク上の基本的な操作を以下にまとめます。
- Establish: To create an instance of a traffic trunk.
- 設立：トラフィックトランクのインスタンスを作成します。
- Activate: To cause a traffic trunk to start passing traffic. The establishment and activation of a traffic trunk are logically separate events. They may, however, be implemented or invoked as one atomic action.
- アクティブ化：トラフィックを渡して起動するトラフィックトランクを引き起こします。トラフィックトランクの確立と活性化は、論理的に独立したイベントです。彼らは、しかし、実装または1つのアトミック動作として呼び出すことができます。
- Deactivate: To cause a traffic trunk to stop passing traffic.
- 非アクティブ化：トラフィックを渡して停止するようにトラフィックトランクを引き起こします。
- Modify Attributes: To cause the attributes of a traffic trunk to be modified.
- 属性の変更：トラフィックトランクの属性が変更されるようにするには。
- Reroute: To cause a traffic trunk to change its route. This can be done through administrative action or automatically by the underlying protocols.
- 再ルーティング：トラフィックトランクがそのルートを変更させます。これは、管理アクションによって、または自動的に基本的なプロトコルによって行うことができます。
- Destroy: To remove an instance of a traffic trunk from the network and reclaim all resources allocated to it. Such resources include label space and possibly available bandwidth.
- 破棄：ネットワークからのトラフィックトランクのインスタンスを削除し、それに割り当てられたすべてのリソースを再利用するには。このようなリソースは、ラベルスペースと、おそらく利用可能な帯域幅が含まれます。
The above are considered the basic operations on traffic trunks. Additional operations are also possible such as policing and traffic shaping.
上記は、トラフィックトランク上の基本的な操作と考えられています。追加の操作は、このようなポリシングおよびトラフィックシェーピングなども可能です。
Accounting and performance monitoring capabilities are very important to the billing and traffic characterization functions. Performance statistics obtained from accounting and performance monitoring systems can be used for traffic characterization, performance optimization, and capacity planning within the Traffic Engineering realm..
会計およびパフォーマンス監視機能は、課金およびトラフィック特性機能に非常に重要です。会計およびパフォーマンスの監視システムから取得したパフォーマンス統計情報は、トラフィックエンジニアリングレルム内のトラフィックの特性、パフォーマンスの最適化、およびキャパシティプランニングのために使用することができます。..
The capability to obtain statistics at the traffic trunk level is so important that it should be considered an essential requirement for Traffic Engineering over MPLS.
トラフィックトランクレベルでの統計情報を取得する機能は、MPLSを超えるトラフィックエンジニアリングのための必須要件と見なされるべきであることが重要なのです。
An attribute of a traffic trunk is a parameter assigned to it which influences its behavioral characteristics.
トラフィックトランクの属性は、その行動特性に影響を与え、それに割り当てられたパラメータです。
Attributes can be explicitly assigned to traffic trunks through administration action or they can be implicitly assigned by the underlying protocols when packets are classified and mapped into equivalence classes at the ingress to an MPLS domain. Regardless of how the attributes were originally assigned, for Traffic Engineering purposes, it should be possible to administratively modify such attributes.
属性は、明示的に管理アクションを通過するトラフィックのトランクに割り当てることができるか、パケットがMPLSドメインへの入口で等価クラスに分類され、マップされたとき、彼らは暗黙のうちに基礎となるプロトコルによって割り当てることができます。かかわらず、属性が最初に割り当てられたかの、トラフィックエンジニアリングの目的のために、管理上、このような属性を変更することが可能です。
The basic attributes of traffic trunks particularly significant for Traffic Engineering are itemized below.
トラフィックエンジニアリングのために特に重要な交通トランクの基本的な属性は以下の箇条書きされています。
- Traffic parameter attributes
- トラフィックパラメータの属性
- Generic Path selection and maintenance attributes
- 一般的なパスの選択および維持の属性
- Priority attribute
- Priority属性
- Preemption attribute
- プリエンプション属性
- Resilience attribute
- 回復力属性
- Policing attribute
- ポリシング属性
The combination of traffic parameters and policing attributes is analogous to usage parameter control in ATM networks. Most of the attributes listed above have analogs in well established technologies. Consequently, it should be relatively straight forward to map the traffic trunk attributes onto many existing switching and routing architectures.
トラフィックパラメータおよびポリシング属性の組み合わせは、ATMネットワークの使用量パラメータ制御に似ています。上記の属性の大部分は十分に確立された技術ではアナログを持っています。したがって、トラフィックのトランクは、多くの既存のスイッチングおよびルーティングのアーキテクチャ上に属性をマッピングするために比較的単純でなければなりません。
Priority and preemption can be regarded as relational attributes because they express certain binary relations between traffic trunks. Conceptually, these binary relations determine the manner in which traffic trunks interact with each other as they compete for network resources during path establishment and path maintenance.
彼らは交通トランクの間に一定のバイナリの関係を表現するため、優先順位とプリエンプションは、リレーショナル属性とみなすことができます。概念的には、これらのバイナリの関係は、彼らがパスの確立とパスのメンテナンス時に、ネットワークリソースを奪い合うようトラフィックトランクが相互作用する方法を決定します。
Traffic parameters can be used to capture the characteristics of the traffic streams (or more precisely the forwarding equivalence class) to be transported through the traffic trunk. Such characteristics may include peak rates, average rates, permissible burst size, etc. From a traffic engineering perspective, the traffic parameters are significant because they indicate the resource requirements of the traffic trunk. This is useful for resource allocation and congestion avoidance through anticipatory policies.
トラフィックパラメータは、トラフィックトランクを介して輸送されるトラフィックストリームの特性（又はより正確に転送等価クラス）を捕捉するために使用することができます。彼らは交通トランクのリソース要件を示しているので、このような特性はピーク速度、平均速度、トラフィックエンジニアリングの観点から許容バーストサイズなどを含むことができ、トラフィックパラメータが重要です。これは予期政策を通じて資源配分と輻輳回避のために有用です。
For the purpose of bandwidth allocation, a single canonical value of bandwidth requirements can be computed from a traffic trunk's traffic parameters. Techniques for performing these computations are well known. One example of this is the theory of effective bandwidth.
帯域幅の割り当ての目的のために、帯域幅の要件の単一の標準値は、トラフィックトランクのトラフィックパラメータから計算することができます。これらの計算を実行するための技術はよく知られています。この一例は、有効帯域幅の理論です。
Generic path selection and management attributes define the rules for selecting the route taken by a traffic trunk as well as the rules for maintenance of paths that are already established.
一般的なパスの選択や管理の属性は、トラフィックトランクにより撮影したルートだけでなく、すでに確立されているパスを維持するためのルールを選択するためのルールを定義します。
Paths can be computed automatically by the underlying routing protocols or they can be defined administratively by a network operator. If there are no resource requirements or restrictions associated with a traffic trunk, then a topology driven protocol can be used to select its path. However, if resource requirements or policy restrictions exist, then a constraint-based routing scheme should be used for path selection.
パスは、基礎となるルーティングプロトコルによって自動的に計算することができ、またはそれらは、ネットワークオペレータによって管理的に定義することができます。トラフィックトランクに関連付けられたリソース要件や制約がない場合は、トポロジードリブンプロトコルは、そのパスを選択するために使用することができます。リソース要件またはポリシーの制約が存在する場合は、その後、制約ベースのルーティング方式は、経路選択のために使用されるべきです。
In Section 7, a constraint-based routing framework which can automatically compute paths subject to a set of constraints is described. Issues pertaining to explicit paths instantiated through administrative action are discussed in Section 5.6.1 below.
セクション7で、自動的に制約のセットを受ける経路を計算することができ、制約ベースのルーティングフレームワークについて説明します。管理アクションによってインスタンス化明示的なパスに関連する問題は、以下のセクション5.6.1で説明されています。
Path management concerns all aspects pertaining to the maintenance of paths traversed by traffic trunks. In some operational contexts, it is desirable that an MPLS implementation can dynamically reconfigure itself, to adapt to some notion of change in "system state." Adaptivity and resilience are aspects of dynamic path management.
パス管理は、トラフィックトランクが通過するパスのメンテナンスに関連するすべての側面に関するものです。いくつかの運用状況では、MPLSの実装は動的に変更のいくつかの概念に適応するために、自分自身を再構成することが望ましい「システム状態。」適応性と弾力性は、動的パス管理の側面です。
To guide the path selection and management process, a set of attributes are required. The basic attributes and behavioral characteristics associated with traffic trunk path selection and management are described in the remainder of this sub-section.
パス選択および管理プロセスを導くために、属性のセットが必要とされています。基本属性とトラフィックトランク経路選択と管理に関連する行動特性は、このサブセクションの残りの部分に記載されています。
An administratively specified explicit path for a traffic trunk is one which is configured through operator action. An administratively specified path can be completely specified or partially specified. A path is completely specified if all of the required hops between the endpoints are indicated. A path is partially specified if only a subset of intermediate hops are indicated. In this case, the underlying protocols are required to complete the path. Due to operator errors, an administratively specified path can be inconsistent or illogical. The underlying protocols should be able to detect such inconsistencies and provide appropriate feedback.
トラフィックトランクのための行政指定の明示的なパスは、オペレータの操作を介して設定されたものです。管理指定されたパスが完全に指定された又は部分的に指定することができます。エンドポイント間の必要なホップの全てが示されている場合、パスは完全に指定されています。中間ホップのサブセットのみが示されている場合は、パスを部分的に指定されています。この場合、基礎となるプロトコルは、パスを完了するために必要とされています。オペレータによるエラーを、管理指定されたパスは、矛盾または非論理的であることができます。基本的なプロトコルは、このような矛盾を検出し、適切なフィードバックを提供することができるはずです。
A "path preference rule" attribute should be associated with administratively specified explicit paths. A path preference rule attribute is a binary variable which indicates whether the administratively configured explicit path is "mandatory" or "non-mandatory."
「パス優先ルール」属性管理指定された明示的経路と関連付けられなければなりません。パス優先ルール属性は管理構成明示的なパスが「必須」またはであるかどうかを示す2進変数である「非必須」。
If an administratively specified explicit path is selected with a "mandatory attribute, then that path (and only that path) must be used. If a mandatory path is topological infeasible (e.g. the two endpoints are topologically partitioned), or if the path cannot be instantiated because the available resources are inadequate, then the path setup process fails. In other words, if a path is specified as mandatory, then an alternate path cannot be used regardless of prevailing circumstance. A mandatory path which is successfully instantiated is also implicitly pinned. Once the path is instantiated it cannot be changed except through deletion and instantiation of a new path.
行政指定の明示的なパスは、「必須属性で選択されている場合は、そのパス（とのみそのパス）は必須パスが位相的に実行不可能である場合（例えば、2つのエンドポイントが位相的に分割されている）。使用、またはパスができない場合する必要がありますパスが必須と指定されている場合、利用可能なリソースが不十分であるためにインスタンス化し、パス設定処理が失敗する。換言すれば、その後、代替パスにかかわらず支配的な状況に使用することができない。正常にインスタンス化された必須のパスも暗黙的に固定されパスがインスタンス化されたら。それは新しいパスの削除とインスタンス化を通じて除いて変更することはできません。
However, if an administratively specified explicit path is selected with a "non-mandatory" preference rule attribute value, then the path should be used if feasible. Otherwise, an alternate path can be chosen instead by the underlying protocols.
管理指定された明示的なパスは、「非必須」優先ルール属性値で選択された場合に実現可能な場合は、その後のパスが使用されるべきです。そうでない場合は、代替パスは、基礎となるプロトコルによって代わりに選択することができます。
In some practical contexts, it can be useful to have the ability to administratively specify a set of candidate explicit paths for a given traffic trunk and define a hierarchy of preference relations on the paths. During path establishment, the preference rules are applied to select a suitable path from the candidate list. Also, under failure scenarios the preference rules are applied to select an alternate path from the candidate list.
いくつかの実用的な状況では、管理上与えられたトラフィックトランクの候補明示的なパスのセットを指定し、パスの優先関係の階層を定義する能力を有することが便利です。パス設定時、優先ルールは、候補リストから適切なパスを選択するために適用されます。また、障害シナリオの下で優先ルールは、候補リストから代替パスを選択するために適用されます。
Resource class affinity attributes associated with a traffic trunk can be used to specify the class of resources (see Section 6) which are to be explicitly included or excluded from the path of the traffic trunk. These are policy attributes which can be used to impose additional constraints on the path traversed by a given traffic trunk. Resource class affinity attributes for a traffic can be specified as a sequence of tuples:
トラフィックのトランクに関連付けられたリソースクラスの親和性の属性は、明示的に含めるか、またはトラフィックトランクのパスから除外されるリソース（セクション6を参照）のクラスを指定するために使用することができます。これらは、特定のトラフィックトランクが通過するパスに追加の制約を課すために使用できるポリシー属性です。トラフィックのためのリソースクラスの親和性属性はタプルのシーケンスとして指定することができます。
<resource-class, affinity>; <resource-class, affinity>; ..
<リソースクラス、親和性>。 <リソースクラス、親和性>。 。..
The resource-class parameter identifies a resource class for which an affinity relationship is defined with respect to the traffic trunk. The affinity parameter indicates the affinity relationship; that is, whether members of the resource class are to be included or excluded from the path of the traffic trunk. Specifically, the affinity parameter may be a binary variable which takes one of the following values: (1) explicit inclusion, and (2) explicit exclusion.
リソースクラスのパラメータは、アフィニティ関係がトラフィックトランクに対して定義されているリソース・クラスを識別する。親和性パラメータは、親和性の関係を示しています。それは、リソースクラスのメンバーが含まやトラフィックトランクのパスから除外されるかどうか、です。 （1）明示的に含めること、及び（2）明示的に除外：具体的には、親和性パラメータは、次のいずれかの値をとる2値変数であってもよいです。
If the affinity attribute is a binary variable, it may be possible to use Boolean expressions to specify the resource class affinities associated with a given traffic trunk.
親和性の属性は、バイナリ変数であるならば、与えられたトラフィックのトランクに関連付けられたリソースクラスの親和性を指定するブール式を使用することも可能です。
If no resource class affinity attributes are specified, then a "don't care" affinity relationship is assumed to hold between the traffic trunk and all resources. That is, there is no requirement to explicitly include or exclude any resources from the traffic trunk's path. This should be the default in practice.
何のリソースクラスの親和性の属性が指定されていない場合は、「気にしない」親和性の関係はトラフィックトランクと、すべてのリソースの間で保持すると想定されます。つまり、明示的にトラフィックトランクのパスから任意のリソースを含めるか除外する必要はありません。これが実際にデフォルトにする必要があります。
Resource class affinity attributes are very useful and powerful constructs because they can be used to implement a variety of policies. For example, they can be used to contain certain traffic trunks within specific topological regions of the network.
彼らは政策の多様性を実現するために使用することができるので、リソースクラスの親和性の属性は非常に便利で強力な構文です。例えば、それらは、ネットワークの特定のトポロジー領域内の特定のトラフィックトランクを含むのに使用することができます。
A "constraint-based routing" framework (see section 7.0) can be used to compute an explicit path for a traffic trunk subject to resource class affinity constraints in the following manner:
「制約ベースのルーティング」フレームワークは、次のようにリソースクラス親和性の制約へのトラフィックトランク被写体の明示的なパスを計算するために使用することができる（セクション7.0を参照します）。
1. For explicit inclusion, prune all resources not belonging to the specified classes prior to performing path computation.
明示的に含めるための1は、従来の経路計算を実行する指定されたクラスに属さないすべてのリソースを整理します。
2. For explicit exclusion, prune all resources belonging to the specified classes before performing path placement computations.
明示的に除外2.は、パスの配置の計算を実行する前に、指定されたクラスに属するすべてのリソースを剪定します。
Network characteristics and state change over time. For example, new resources become available, failed resources become reactivated, and allocated resources become deallocated. In general, sometimes more efficient paths become available. Therefore, from a Traffic Engineering perspective, it is necessary to have administrative control parameters that can be used to specify how traffic trunks respond to this dynamism. In some scenarios, it might be desirable to dynamically change the paths of certain traffic trunks in response to changes in network state. This process is called re-optimization. In other scenarios, re-optimization might be very undesirable.
時間をかけてネットワークの特性や状態変化。たとえば、新しいリソースが利用可能になり、失敗したリソースを再なり、割り当てられたリソースが割り当て解除になります。一般的に、時にはより効率的なパスが利用可能になります。そのため、トラフィックエンジニアリングの観点から、トラフィックトランクがこのダイナミズムへの対応方法を指定するために使用することができ、管理者の制御パラメータを持つことが必要です。いくつかのシナリオでは、動的ネットワーク状態の変化に応じて特定のトラフィックトランクのパスを変更することが望ましいかもしれません。このプロセスは、再最適化と呼ばれています。他のシナリオでは、再最適化は非常に望ましくないかもしれません。
An Adaptivity attribute is a part of the path maintenance parameters associated with traffic trunks. The adaptivity attribute associated with a traffic trunk indicates whether the trunk is subject to re-optimization. That is, an adaptivity attribute is a binary variable which takes one of the following values: (1) permit re-optimization and (2) disable re-optimization.
適応性の属性は、トラフィックのトランクに関連付けられたパス保守パラメータの一部です。トラフィックトランクに関連付けられた適応属性は、トランクが再最適化の対象となるかどうかを示します。 （1）許可の再最適化、および（2）の再最適化を無効にする：すなわち、適応属性は、次のいずれかの値をとる2値変数です。
If re-optimization is enabled, then a traffic trunk can be rerouted through different paths by the underlying protocols in response to changes in network state (primarily changes in resource availability). Conversely, if re-optimization is disabled, then the traffic trunk is "pinned" to its established path and cannot be rerouted in response to changes in network state.
再最適化が有効になっている場合、トラフィックトランクは、ネットワーク状態の変化（リソースの可用性に主に変化）に応答して、基礎となるプロトコルによって異なる経路を介して再ルーティングすることができます。再最適化が無効になっている場合は逆に、その後、トラフィックトランクは、その確立されたパスに「固定」され、ネットワーク状態の変化に応じて再ルーティングすることはできません。
Stability is a major concern when re-optimization is permitted. To promote stability, an MPLS implementation should not be too reactive to the evolutionary dynamics of the network. At the same time, it must adapt fast enough so that optimal use can be made of network assets. This implies that the frequency of re-optimization should be administratively configurable to allow for tuning.
再最適化が許可されているときの安定性が主要な関心事です。安定性を促進するために、MPLSの実装では、ネットワークの進化のダイナミクスにあまりにも反応すべきではありません。最適な使用は、ネットワーク資産で作ることができるように、同時に、それは十分に速く適応しなければなりません。これは、再最適化の頻度は、チューニングを可能にするために、管理設定可能でなければならないことを意味しています。
It is to be noted that re-optimization is distinct from resilience. A different attribute is used to specify the resilience characteristics of a traffic trunk (see section 5.9). In practice, it would seem reasonable to expect traffic trunks subject to re-optimization to be implicitly resilient to failures along their paths. However, a traffic trunk which is not subject to re-optimization and whose path is not administratively specified with a "mandatory" attribute can also be required to be resilient to link and node failures along its established path
これは、再最適化は回復力とは区別されることに留意すべきです。別の属性は、トラフィックトランクの反発特性を指定するために使用されている（5.9節を参照してください）。実際には、そのパスに沿って障害に暗黙的に弾力性のあることが再最適化へのトラフィックトランクが対象と予想するのが妥当と思われます。しかし、再最適化し、そのパス管理上「必須」属性で指定されていないの対象ではありませんトラフィックトランクも、その確立されたパスに沿ったリンクやノードの障害に弾力的であることが要求することができます
Formally, it can be stated that adaptivity to state evolution through re-optimization implies resilience to failures, whereas resilience to failures does not imply general adaptivity through re-optimization to state changes.
障害に対する回復力は、状態変化への再最適化により、一般的な適応性を示唆するものではありません。一方、形式的には、再最適化スルー状態進化への適応は、障害に対する回復力を意味することを述べることができます。
Load distribution across multiple parallel traffic trunks between two nodes is an important consideration. In many practical contexts, the aggregate traffic between two nodes may be such that no single link (hence no single path) can carry the load. However, the aggregate flow might be less than the maximum permissible flow across a "min-cut" that partitions the two nodes. In this case, the only feasible solution is to appropriately divide the aggregate traffic into sub-streams and route the sub-streams through multiple paths between the two nodes.
2つのノード間の複数の並列のトラフィックトランク間の負荷分布が重要な考慮事項です。多くの実際的な状況において、2つのノード間の集約トラフィックには単一のリンク（従って単一のパス）負荷を運ぶことができないようにしてもよいです。しかし、集約フローは、2つのノードを仕切る「最小カット」を横切る最大許容流量よりも少ないかもしれません。この場合、唯一の実行可能な解決策は、適切にサブストリームおよびルート2つのノード間の複数のパスを介してサブストリームに集約トラフィックを分割することです。
In an MPLS domain, this problem can be addressed by instantiating multiple traffic trunks between the two nodes, such that each traffic trunk carries a proportion of the aggregate traffic. Therefore, a flexible means of load assignment to multiple parallel traffic trunks carrying traffic between a pair of nodes is required.
MPLSドメインでは、この問題は、各トラフィックトランクが集約トラフィックの割合を運ぶように、2つのノード間の複数のトラフィックトランクをインスタンス化することによって対処することができます。したがって、一対のノード間でトラフィックを搬送する複数の並列トラフィックトランクへの負荷の割り当ての柔軟な手段が必要です。
Specifically, from an operational perspective, in situations where parallel traffic trunks are warranted, it would be useful to have some attribute that can be used to indicate the relative proportion of traffic to be carried by each traffic trunk. The underlying protocols will then map the load onto the traffic trunks according to the specified proportions. It is also, generally desirable to maintain packet ordering between packets belong to the same micro-flow (same source address, destination address, and port number).
具体的には、運用の観点から、並列のトラフィックトランクが保証されている状況では、各トラフィックトランクによって搬送されるトラフィックの相対的な割合を示すために使用することができるいくつかの属性を有することが有用であろう。基本的なプロトコルは、その後、指定された割合に応じてトラフィックトランクに負荷をマップします。同じマイクロ流（同一の送信元アドレス、宛先アドレス、及びポート番号）に属するパケット間のパケット順序を維持するために、また、一般的に望ましいです。
The priority attribute defines the relative importance of traffic trunks. If a constraint-based routing framework is used with MPLS, then priorities become very important because they can be used to determine the order in which path selection is done for traffic trunks at connection establishment and under fault scenarios.
priority属性は、トラフィックトランクの相対的な重要性を定義します。制約ベースのルーティングフレームワークはMPLSで使用される場合、それらは経路選択は、接続確立時および障害シナリオの下でトラフィックトランクのために行われる順序を決定するために使用することができるので、次に優先度が非常に重要になります。
Priorities are also important in implementations permitting preemption because they can be used to impose a partial order on the set of traffic trunks according to which preemptive policies can be actualized.
彼らは先制政策が実現できる応じた交通トランクのセットに半順序を課すために使用することができるので優先順位は、プリエンプションを許可する実装でも重要です。
The preemption attribute determines whether a traffic trunk can preempt another traffic trunk from a given path, and whether another traffic trunk can preempt a specific traffic trunk. Preemption is useful for both traffic oriented and resource oriented performance objectives. Preemption can used to assure that high priority traffic trunks can always be routed through relatively favorable paths within a differentiated services environment.
プリエンプション属性は、トラフィックトランクが指定されたパスから別のトラフィックトランクを先取りできるかどうか、および他のトラフィックトランクが特定のトラフィックトランクを先取りできるかどうかが決まります。プリエンプションは、両方のトラフィック指向とリソース指向の性能目標のために有用です。プリエンプションは、優先順位の高いトラフィックトランクは常に差別化されたサービス環境の中で比較的良好の経路を介してルーティングすることができることを保証するために使用することができます。
Preemption can also be used to implement various prioritized restoration policies following fault events.
プリエンプションはまた、障害イベントを、以下の様々な優先順位復旧ポリシーを実装するために使用することができます。
The preemption attribute can be used to specify four preempt modes for a traffic trunk: (1) preemptor enabled, (2) non-preemptor, (3) preemptable, and (4) non-preemptable. A preemptor enabled traffic trunk can preempt lower priority traffic trunks designated as preemptable. A traffic specified as non-preemptable cannot be preempted by any other trunks, regardless of relative priorities. A traffic trunk designated as preemptable can be preempted by higher priority trunks which are preemptor enabled.
（1）有効preemptor、（2）非preemptor、（3）プリエンプタブル、及び（4）非プリエンプタブル：プリエンプション属性は、トラフィックトランクのための4つのプリエンプトモードを指定するために使用することができます。 preemptor有効トラフィックトランクはプリエンプタブルとして指定された優先度の低いトラフィックトランクを先取りすることができます。非プリエンプタブルとして指定されたトラフィックに関係なく、相対的な優先順位の、任意の他のトランクによってプリエンプトすることができません。優先使用可能として指定されたトラフィックトランクはpreemptorが有効になっている優先順位の高いトランクによってプリエンプトすることができます。
It is trivial to see that some of the preempt modes are mutually exclusive. Using the numbering scheme depicted above, the feasible preempt mode combinations for a given traffic trunk are as follows: (1, 3), (1, 4), (2, 3), and (2, 4). The (2, 4) combination should be the default.
プリエンプトモードの一部が相互に排他的であることを確認するために簡単です。上に示した番号付けスキームを使用して、所与のトラフィックトランクの可能プリエンプトモードの組み合わせは以下の通りである：（1,3）、（1,4）、（2,3）、及び（2,4）。 （2,4）の組合せがデフォルトであるべきです。
A traffic trunk, say "A", can preempt another traffic trunk, say "B", only if *all* of the following five conditions hold: (i) "A" has a relatively higher priority than "B", (ii) "A" contends for a resource utilized by "B", (iii) the resource cannot concurrently accommodate "A" and "B" based on certain decision criteria, (iv) "A" is preemptor enabled, and (v) "B" is preemptable.
（（I）「」「B」よりも相対的に高い優先度を持っている、IIを：トラフィックトランクは、別のトラフィックトランクを先取りする「B」、*以下の5つの条件のすべて*が保持する場合にのみ、と言うことができ、「A」と言います）「A」と、（iii）のリソースが同時に特定の判断基準に基づいて、「A」及び「B」を収容することができない「B」によって利用リソースの競合、（IV）「」preemptor有効であり、および（v） " Bは、」プリエンプトです。
Preemption is not considered a mandatory attribute under the current best effort Internet service model although it is useful. However, in a differentiated services scenario, the need for preemption becomes more compelling. Moreover, in the emerging optical internetworking architectures, where some protection and restoration functions may be migrated from the optical layer to data network elements (such as gigabit and terabit label switching routers) to reduce costs, preemptive strategies can be used to reduce the restoration time for high priority traffic trunks under fault conditions.
それは便利ですが、プリエンプションは、現在のベストエフォート型のインターネット・サービス・モデルの下で必須の属性とはみなされません。しかし、差別化されたサービスのシナリオでは、プリエンプションの必要性がより説得力になります。また、いくつかの保護と回復機能がコストを削減するために（例えば、ギガビットおよびテラビットラベルスイッチングルータなどの）データネットワーク要素に光学層から移行することができる射出光インターネットワーキングアーキテクチャにおいて、プリエンプティブ戦略は、復旧時間を短縮するために使用することができます障害条件の下で優先度の高いトラフィックのトランクのため。
The resilience attribute determines the behavior of a traffic trunk under fault conditions. That is, when a fault occurs along the path through which the traffic trunk traverses. The following basic problems need to be addressed under such circumstances: (1) fault detection, (2) failure notification, (3) recovery and service restoration. Obviously, an MPLS implementation will have to incorporate mechanisms to address these issues.
反発属性は、障害条件の下でトラフィックトランクの動作を決定します。障害がトラフィックトランクが通過する経路に沿って発生した場合には、あります。 （1）障害検出、（2）障害通知、（3）復旧サービス復旧：以下の基本的な問題は、このような状況下で対処する必要があります。明らかに、MPLSの実装では、これらの問題に対処するためのメカニズムを組み込む必要があります。
Many recovery policies can be specified for traffic trunks whose established paths are impacted by faults. The following are examples of feasible schemes:
多くの回復ポリシーは、その設立のパスの障害によって影響を受けるトラフィックトランクに指定することができます。以下の実行可能なスキームの例は以下のとおりです。
1. Do not reroute the traffic trunk. For example, a survivability scheme may already be in place, provisioned through an alternate mechanism, which guarantees service continuity under failure scenarios without the need to reroute traffic trunks. An example of such an alternate scheme (certainly many others exist), is a situation whereby multiple parallel label switched paths are provisioned between two nodes, and function in a manner such that failure of one LSP causes the traffic trunk placed on it to be mapped onto the remaining LSPs according to some well defined policy.
1.トラフィックトランクを再ルーティングしないでください。例えば、生存方式は、既にトラフィックトランクを再ルーティングする必要なく、障害シナリオの下でサービスの連続性を保証する代替の機構を介してプロビジョニングされ、所定の位置にあってもよいです。そのような代替スキームの一例は、（確かに多くの他のものが存在する）、複数の並列標識は、パスを1 LSPの故障がその上に配置されたトラフィックトランクがマッピングさせるように二つのノード、および機能の間でプロビジョニングさ切り換えれる状況でありますいくつかのよく定義されたポリシーに従って残りのLSP上。
2. Reroute through a feasible path with enough resources. If none exists, then do not reroute.
2.十分なリソースを持つ実現可能な経路を通って再ルーティング。が存在しない場合は、再ルーティングされません。
3. Reroute through any available path regardless of resource constraints.
3.かかわらず、資源制約の使用可能な任意の経路を通って再ルーティング。
4. Many other schemes are possible including some which might be combinations of the above.
4.他の多くのスキームは、上記の組み合わせであるかもしれないいくつかを含む可能です。
A "basic" resilience attribute indicates the recovery procedure to be applied to traffic trunks whose paths are impacted by faults. Specifically, a "basic" resilience attribute is a binary variable which determines whether the target traffic trunk is to be rerouted when segments of its path fail. "Extended" resilience attributes can be used to specify detailed actions to be taken under fault scenarios. For example, an extended resilience attribute might specify a set of alternate paths to use under fault conditions, as well as the rules that govern the relative preference of each specified path.
「基本」反発属性は、そのパスの障害によって影響を受けるトラフィックトランクに適用するリカバリ手順を示します。具体的には、「基本」反発属性は、その経路のセグメントが失敗した場合、ターゲットトラフィックトランクが再ルーティングするか否かを判断する2進変数です。 「拡張」反発属性は、障害のシナリオの下で撮影するための詳細なアクションを指定するために使用することができます。例えば、拡張反発属性が指定された各パスの相対的優先度を管理する規則と同様に、故障状態の下で使用する代替パスのセットを指定するかもしれません。
Resilience attributes mandate close interaction between MPLS and routing.
弾力性は、MPLSとルーティングとの間の緊密な相互作用を義務付ける属性。
The policing attribute determines the actions that should be taken by the underlying protocols when a traffic trunk becomes non-compliant. That is, when a traffic trunk exceeds its contract as specified in the traffic parameters. Generally, policing attributes can indicate whether a non-conformant traffic trunk is to be rate limited, tagged, or simply forwarded without any policing action. If policing is used, then adaptations of established algorithms such as the ATM Forum's GCRA [11] can be used to perform this function.
ポリシング属性は、トラフィックトランクは非対応となり基礎となるプロトコルによって取るべきアクションを決定します。これは、トラフィックパラメータで指定されたトラフィックトランクがその契約を超えた場合、です。一般的には、ポリシングの属性は非準拠トラフィックトランクが限定率、タグ付けされた、あるいは単に任意のポリシングアクションずに転送するかどうかを示すことができます。ポリシングが使用される場合、そのようなATMフォーラムのGCRA [11]のように確立されたアルゴリズムの適応は、この機能を実行するために使用することができます。
Policing is necessary in many operational scenarios, but is quite undesirable in some others. In general, it is usually desirable to police at the ingress to a network (to enforce compliance with service level agreements) and to minimize policing within the core, except when capacity constraints dictate otherwise.
ポリシングは、多くの動作シナリオで必要ですが、いくつか他の人には非常に望ましくありません。一般的に、（サービスレベル契約の遵守を強制する）と容量の制約が別途指示する場合を除いて、コア内にポリシングを最小限にするために、ネットワークへの入口で警察に通常望ましいです。
Therefore, from a Traffic Engineering perspective, it is necessary to be able to administratively enable or disable traffic policing for each traffic trunk.
そのため、トラフィックエンジニアリングの観点から、管理上、各トラフィックトランクのトラフィックポリシングを有効または無効にできることが必要です。
Resource attributes are part of the topology state parameters, which are used to constrain the routing of traffic trunks through specific resources.
リソース属性は、特定のリソースを介したトラフィックトランクのルーティングを制約するために使用されているトポロジ状態パラメータの一部です。
The maximum allocation multiplier (MAM) of a resource is an administratively configurable attribute which determines the proportion of the resource that is available for allocation to traffic trunks. This attribute is mostly applicable to link bandwidth. However, it can also be applied to buffer resources on LSRs. The concept of MAM is analogous to the concepts of subscription and booking factors in frame relay and ATM networks.
リソースの最大割当乗数（MAM）は、トラフィックトランクへの割り当てのために利用可能であるリソースの割合を決定する管理設定属性です。この属性は、リンクの帯域幅に主に適用されます。しかし、またのLSR上のリソースをバッファリングするために適用することができます。 MAMの概念は、フレームリレーやATM網におけるサブスクリプションおよび予約の要素の概念に類似しています。
The values of the MAM can be chosen so that a resource can be under-allocated or over-allocated. A resource is said to be under-allocated if the aggregate demands of all traffic trunks (as expressed in the trunk traffic parameters) that can be allocated to it are always less than the capacity of the resource. A resource is said to be over-allocated if the aggregate demands of all traffic trunks allocated to it can exceed the capacity of the resource.
リソースが割り当てられ、下または過剰に割り当てることができるようにMAMの値を選択することができます。リソースは、それに割り当て可能なすべてのトラフィックトランクの総需要が（トランクトラフィックパラメータで表現される）リソースの容量よりも常に小さい場合アンダー割り当てられると言われています。リソースは、それに割り当てられたすべてのトラフィックトランクの総需要は、リソースの容量を超えることができるかどう上に割り当てられていると言われます。
Under-allocation can be used to bound the utilization of resources. However,the situation under MPLS is more complex than in circuit switched schemes because under MPLS, some flows can be routed via conventional hop by hop protocols (also via explicit paths) without consideration for resource constraints.
アンダー割り当てリソースの使用率をバインドするために使用することができます。しかし、MPLS下状況がMPLSの下で、いくつかのフローがリソースの制約を考慮せずに（明示的な経路を介して）ホッププロトコルによって、従来のホップを経由してルーティングすることができるので、回路内のスキームを切り替えるよりも複雑です。
Over-allocation can be used to take advantage of the statistical characteristics of traffic in order to implement more efficient resource allocation policies. In particular, over-allocation can be used in situations where the peak demands of traffic trunks do not coincide in time.
オーバー割り当ては、より効率的な資源配分ポリシーを実装するために、トラフィックの統計的特性を利用するために使用することができます。特に、過剰割り当ては、トラフィックトランクのピーク需要が時間内に一致しない状況で使用することができます。
Resource class attributes are administratively assigned parameters which express some notion of "class" for resources. Resource class attributes can be viewed as "colors" assigned to resources such that the set of resources with the same "color" conceptually belong to the same class. Resource class attributes can be used to implement a variety of policies. The key resources of interest here are links. When applied to links, the resource class attribute effectively becomes an aspect of the "link state" parameters.
リソースクラス属性は、管理リソースのための「クラス」のいくつかの概念を表現するパラメータを割り当てています。リソースクラス属性は、同じ「色」を持つリソースのセットが概念的に同じクラスに属しているようなリソースに割り当てられた「色」とみなすことができます。リソースクラス属性は、ポリシーのさまざまなを実装するために使用することができます。ここでの関心の重要なリソースがリンクされています。リンクに適用された場合、リソースクラス属性は、効果的に「リンク状態」パラメータの様相となります。
The concept of resource class attributes is a powerful abstraction. From a Traffic Engineering perspective, it can be used to implement many policies with regard to both traffic and resource oriented performance optimization. Specifically, resource class attributes can be used to:
リソースクラス属性の概念は、強力な抽象化です。トラフィックエンジニアリングの観点から、トラフィックとリソース指向のパフォーマンスの最適化の両方に関して多くのポリシーを実装するために使用することができます。具体的には、リソースクラスの属性は、次の目的に使用できます。
1. Apply uniform policies to a set of resources that do not need to be in the same topological region.
1.同じトポロジカル地域内にある必要はありませんリソースのセットに均一なポリシーを適用します。
2. Specify the relative preference of sets of resources for path placement of traffic trunks.
2.トラフィックトランクのパス配置のためのリソースのセットの相対的な優先度を指定します。
3. Explicitly restrict the placement of traffic trunks to specific subsets of resources.
3.明示的なリソースの特定のサブセットにトラフィックトランクの配置を制限します。
5. Enforce traffic locality containment policies. That is, policies that seek to contain local traffic within specific topological regions of the network.
5.交通地域封じ込めポリシーを適用。これは、ネットワークの特定のトポロジカル地域内でローカルトラフィックを含むように求める方針です。
Additionally, resource class attributes can be used for identification purposes.
また、リソースクラス属性は識別目的のために使用することができます。
In general, a resource can be assigned more than one resource class attribute. For example, all of the OC-48 links in a given network may be assigned a distinguished resource class attribute. The subsets of OC-48 links which exist with a given abstraction domain of the network may be assigned additional resource class attributes in order to implement specific containment policies, or to architect the network in a certain manner.
一般に、リソースは複数のリソースのクラス属性を割り当てることができます。たとえば、所与のネットワーク内のOC-48リンクの全てを区別リソースクラス属性を割り当てることができます。ネットワークの所与の抽象ドメインに存在OC-48リンクのサブセットが特定の方法でネットワークを特定封じ込めポリシーを実装、または建築家にするために、追加のリソース・クラス属性を割り当てることができます。
This section discusses the issues pertaining to constraint-based routing in MPLS domains. In contemporary terminology, constraint-based routing is often referred to as "QoS Routing" see [5,6,7,10].
このセクションでは、MPLSドメインにする制約ベースのルーティングを関連する問題について説明します。現代的な用語では、制約ベースのルーティングは、多くの場合、ページの「QoSルーティング」と呼ばれている[5,6,7,10]。
This document uses the term "constraint-based routing" however, because it better captures the functionality envisioned, which generally encompasses QoS routing as a subset.
より良い、それは一般的にサブセットとしてのQoSルーティングを含む想定される機能を、キャプチャするため、この文書では、しかし、用語「制約ベースのルーティング」を使用しています。
constraint-based routing enables a demand driven, resource reservation aware, routing paradigm to co-exist with current topology driven hop by hop Internet interior gateway protocols.
制約ベースのルーティングは、ホップインターネットインテリア・ゲートウェイ・プロトコルによって現在のトポロジ駆動ホップと共存するための駆動要求、認識リソース予約、ルーティングパラダイムを可能にします。
A constraint-based routing framework uses the following as input:
制約ベースのルーティングフレームワークは、入力として以下を使用します：
- The attributes associated with traffic trunks.
- トラフィックのトランクに関連付けられた属性。
- The attributes associated with resources.
- リソースに関連付けられた属性。
- Other topology state information.
- その他のトポロジ状態情報。
Based on this information, a constraint-based routing process on each node automatically computes explicit routes for each traffic trunk originating from the node. In this case, an explicit route for each traffic trunk is a specification of a label switched path that satisfies the demand requirements expressed in the trunk's attributes, subject to constraints imposed by resource availability, administrative policy, and other topology state information.
この情報に基づいて、各ノード上の制約ベースのルーティングプロセスは自動的にノードから発信各トラフィックトランクのための明示的なルートを計算します。この場合、各トラフィックトランクの明示的なルートは、ラベルの仕様は、リソースの可用性、管理ポリシー、およびその他のトポロジ状態情報による制約を受けトランクの属性で表現需要の要件を満たすパスを切り替えています。
A constraint-based routing framework can greatly reduce the level of manual configuration and intervention required to actualize Traffic Engineering policies.
制約ベースのルーティングフレームワークは大幅にトラフィックエンジニアリングポリシーを実現するために必要な手動設定と介入のレベルを減らすことができます。
In practice, the Traffic Engineer, an operator, or even an automaton will specify the endpoints of a traffic trunk and assign a set of attributes to the trunk which encapsulate the performance expectations and behavioral characteristics of the trunk. The constraint-based routing framework is then expected to find a feasible path to satisfy the expectations. If necessary, the Traffic Engineer or a traffic engineering support system can then use administratively configured explicit routes to perform fine grained optimization.
実際には、交通エンジニア、オペレータ、あるいはオートマトンは、トラフィックトランクのエンドポイントを指定し、パフォーマンスの期待値とトランクの行動特性をカプセル化トランクに属性セットを割り当てます。制約ベースのルーティングフレームワークは、次に期待を満たすために実現可能な経路を見つけることが期待されます。必要であれば、交通エンジニアやトラフィックエンジニアリング支援システムは、細粒度の最適化を実行するように構成された管理上の明示的なルートを使用することができます。
A constraint-based routing framework should at least have the capability to automatically obtain a basic feasible solution to the traffic trunk path placement problem.
制約ベースのルーティングフレームワークは、少なくとも、自動的にトラフィックトランクパスの配置問題への基本的な実現可能な解を得るための機能を持っている必要があります。
In general, the constraint-based routing problem is known to be intractable for most realistic constraints. However, in practice, a very simple well known heuristic (see e.g. [9]) can be used to find a feasible path if one exists:
一般的には、制約ベースのルーティング問題は、最も現実的な制約のために難治であることが知られています。しかし、実際には、非常に単純な周知のヒューリスティックは、存在する場合可能経路を見つけるために使用することができる（例えば、[9]を参照します）。
- First prune resources that do not satisfy the requirements of the traffic trunk attributes.
- トラフィックトランク属性の要件を満たしていないまずプルーン資源。
- Next, run a shortest path algorithm on the residual graph.
- 次に、残留グラフ上の最短経路アルゴリズムを実行します。
Clearly, if a feasible path exists for a single traffic trunk, then the above simple procedure will find it. Additional rules can be specified to break ties and perform further optimizations. In general, ties should be broken so that congestion is minimized. When multiple traffic trunks are to be routed, however, it can be shown that the above algorithm may not always find a mapping, even when a feasible mapping exists.
実現可能なパスは、単一のトラフィックトランクのために存在している場合、明らかに、上記の簡単な手順は、それを見つけるでしょう。追加の規則はネクタイを破ると、さらに最適化を実行するように指定することができます。輻輳が最小となるように、一般的に、タイは破壊されるべきです。複数のトラフィックトランクをルーティングする場合、しかし、実現可能なマッピングが存在する場合でも、上記のアルゴリズムは常にマッピングが見つからないかもしれないことを示すことができます。
Many commercial implementations of frame relay and ATM switches already support some notion of constraint-based routing. For such devices or for the novel MPLS centric contraptions devised therefrom, it should be relatively easy to extend the current constraint-based routing implementations to accommodate the peculiar requirements of MPLS.
フレームリレーやATMスイッチの多くの商用実装は、すでに制約ベースのルーティングのいくつかの概念をサポートしています。そこ考案中心仕掛けようなデバイスまたは新規MPLSのために、MPLSの特有の要件に対応するために、現在の制約に基づくルーティングの実装を拡張することは比較的容易であるべきです。
For routers that use topology driven hop by hop IGPs, constraint-based routing can be incorporated in at least one of two ways:
ホップのIGPによってトポロジー駆動ホップを使用するルータの場合、制約ベースのルーティングは、2つの方法のうちの少なくとも一方に組み込むことができます。
1. By extending the current IGP protocols such as OSPF and IS-IS to support constraint-based routing. Effort is already underway to provide such extensions to OSPF (see [5,7]).
OSPFなどの現在のIGPプロトコルを拡張し、制約ベースのルーティングをサポートするために、IS-IS 1.。努力が（[5,7]参照）OSPFに、このような拡張を提供するために、すでに進行中です。
2. By adding a constraint-based routing process to each router which can co-exist with current IGPs. This scenario is depicted in Figure 1.
現在のIGPと共存することができ、各ルータに制約ベースのルーティング処理を加えることにより2。このシナリオは、図1に示されています。
------------------------------------------
| Management Interface |
------------------------------------------
| | |
------------ ------------------ --------------
| MPLS |<->| Constraint-Based | | Conventional |
| | | Routing Process | | IGP Process |
------------ ------------------ --------------
| |
----------------------- --------------
| Resource Attribute | | Link State |
| Availability Database | | Database |
----------------------- --------------
Figure 1. Constraint-Based Routing Process on Layer 3 LSR
レイヤ3 LSR上の図1制約ベースのルーティングプロセス
There are many important details associated with implementing constraint-based routing on Layer 3 devices which we do not discuss here. These include the following:
私たちがここで議論していないレイヤ3つのデバイス上の制約ベースのルーティングを実装することに関連する多くの重要な詳細があります。これには次のものがあります。
- Mechanisms for exchange of topology state information (resource availability information, link state information, resource attribute information) between constraint-based routing processes.
- トポロジ状態情報を交換するためのメカニズム制約ベースのルーティングプロセスの間に（リソース利用可能性情報、リンク状態情報、リソース属性情報）。
- Mechanisms for maintenance of topology state information.
- トポロジ状態情報を維持するためのメカニズム。
- Interaction between constraint-based routing processes and conventional IGP processes.
- 制約ベースのルーティングプロセスと従来のIGPプロセス間の相互作用。
- Mechanisms to accommodate the adaptivity requirements of traffic trunks.
- メカニズム交通トランクの適応性の要件に対応します。
- Mechanisms to accommodate the resilience and survivability requirements of traffic trunks.
- メカニズム交通トランクの回復力と生存性要件に対応します。
In summary, constraint-based routing assists in performance optimization of operational networks by automatically finding feasible paths that satisfy a set of constraints for traffic trunks. It can drastically reduce the amount of administrative explicit path configuration and manual intervention required to achieve Traffic Engineering objectives.
要約すると、自動的にトラフィックトランクの一連の制約を満たす実現可能なパスを見つけることによって、運用ネットワークのパフォーマンスの最適化におけるルーティングアシストを制約ベース。これは、大幅にトラフィックエンジニアリングの目的を達成するために必要な管理の明示的なパス構成と手動による介入の量を減らすことができます。
This manuscript presented a set of requirements for Traffic Engineering over MPLS. Many capabilities were described aimed at enhancing the applicability of MPLS to Traffic Engineering in the Internet.
この原稿は、MPLSを超えるトラフィックエンジニアリングのための要件のセットを提示しました。多くの機能は、インターネットにトラフィックエンジニアリングへのMPLSの適用性を高めることを目的とした説明されました。
It should be noted that some of the issues described here can be addressed by incorporating a minimal set of building blocks into MPLS, and then using a network management superstructure to extend the functionality in order to realize the requirements. Also, the constraint-based routing framework does not have to be part of the core MPLS specifications. However, MPLS does require some interaction with a constraint-based routing framework in order to meet the requirements.
ここで説明する問題のいくつかは、MPLSへのビルディングブロックの最小セットを組み込んで、その後の要求を実現するために機能を拡張するために、ネットワーク管理上部構造を使用することによって対処することができることに留意すべきです。また、制約ベースのルーティングフレームワークは、コアMPLS仕様の一部である必要はありません。しかし、MPLSは、要件を満たすために制約ベースのルーティングフレームワークとの何らかの相互作用が必要です。
This document does not introduce new security issues beyond those inherent in MPLS and may use the same mechanisms proposed for this technology. It is, however, specifically important that manipulation of administratively configurable parameters be executed in a secure manner by authorized entities.
この文書では、MPLSに固有のものを超えて、新たなセキュリティ問題を導入しないと、この技術のために提案された同じメカニズムを使用することができます。ただし、管理上設定可能なパラメータの操作が許可されたエンティティによって安全な方法で実行されていることが特に重要です。
[1] Rosen, E., Viswanathan, A. and R. Callon, "A Proposed Architecture for MPLS", Work in Progress.
[1]ローゼン、E.、Viswanathanの、A.およびR. Callon、 "MPLSのために提案されたアーキテクチャ"、ProgressのWork。
[2] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G. and A. Viswanathan, "A Framework for Multiprotocol Label Switching", Work in Progress.
[2] Callon、R.、Doolan、P.、フェルドマン、N.、Fredette、A.、ツバメ、G.およびA. Viswanathanの、 "マルチプロトコルラベルスイッチングのためのフレームワーク"、ProgressのWork。
[3] Li, T. and Y. Rekhter, "Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC 2430, October 1998.
[3]李、T.とY. Rekhter、 "差別化サービスおよびトラフィックエンジニアリングのためのプロバイダのアーキテクチャ（ペースト）"、RFC 2430、1998年10月に。
[4] Rekhter, Y., Davie, B., Katz, D., Rosen, E. and G. Swallow, "Cisco Systems' Tag Switching Architecture - Overview", RFC 2105, February 1997.
[4] Rekhter、Y.、デイビー、B.、カッツ、D.、ローゼン、E.およびG.ツバメ、 "スイッチングアーキテクチャシスコシステムズのタグ - 概要"、RFC 2105、1997年2月。
[5] Zhang, Z., Sanchez, C., Salkewicz, B. and E. Crawley "Quality of Service Extensions to OSPF", Work in Progress.
[5]チャン、Z.、サンチェス、C.、Salkewicz、B.およびE.クローリー "OSPFへのサービス拡張の品質" が進行中で働いています。
[6] Crawley, E., Nair, F., Rajagopalan, B. and H. Sandick, "A Framework for QoS Based Routing in the Internet", RFC 2386, August 1998.
[6]クローリー、E.、Nairさん、F.、Rajagopalan、B.及びH. Sandick、 "インターネットにおけるQoSベースのルーティングのためのフレームワーク"、RFC 2386、1998年8月。
[7] Guerin, R., Kamat, S., Orda, A., Przygienda, T. and D. Williams, "QoS Routing Mechanisms and OSPF Extensions", RFC 2676, August 1999.
[7]ゲラン、R.、Kamat、S.、オルダ、A.、Przygienda、T.およびD.ウィリアムズ、 "QoSルーティングメカニズムとOSPF拡張"、RFC 2676、1999年8月。
[8] C. Yang and A. Reddy, "A Taxonomy for Congestion Control Algorithms in Packet Switching Networks," IEEE Network Magazine, Volume 9, Number 5, July/August 1995.
[8] C.ヤンとA.レディ、「パケット交換網における輻輳制御アルゴリズムのための分類、」IEEEネットワークマガジン、第9巻、ナンバー5、7月/ 1995年8月。
[9] W. Lee, M. Hluchyi, and P. Humblet, "Routing Subject to Quality of Service Constraints in Integrated Communication Networks," IEEE Network, July 1995, pp 46-55.
[9] W.リー、M. Hluchyi、およびP. Humblet、IEEEネットワーク、1995年7月、頁46-55 "統合コミュニケーションネットワークでは、サービス品質の制約にルーティング件名"。
[10] ATM Forum, "Traffic Management Specification: Version 4.0" April 1996.
[10] ATMフォーラム、 "トラフィック管理仕様：バージョン4.0" 1996年4月。
The authors would like to thank Yakov Rekhter for his review of an earlier draft of this document. The authors would also like to thank Louis Mamakos and Bill Barns for their helpful suggestions, and Curtis Villamizar for providing some useful feedback.
作者はこのドキュメントの以前のドラフトの彼のレビューのためのヤコフ・レックターに感謝したいと思います。著者らはまた、いくつかの有用なフィードバックを提供するためのルイMamakosとその有用な提案のためのビル・バーンズ、とカーティスVillamizarに感謝したいと思います。
Daniel O. Awduche UUNET (MCI Worldcom) 3060 Williams Drive Fairfax, VA 22031
ダニエルO. Awduche UUNET（MCIワールドコム）3060ウィリアムズドライブフェアファックス、VA 22031
Phone: +1 703-208-5277 EMail: awduche@uu.net
電話：+1 703-208-5277電子メール：awduche@uu.net
Joe Malcolm UUNET (MCI Worldcom) 3060 Williams Drive Fairfax, VA 22031
ジョー・マルコムUUNET（MCIワールドコム）3060ウィリアムズドライブフェアファックス、VA 22031
Phone: +1 703-206-5895 EMail: jmalcolm@uu.net
電話：+1 703-206-5895電子メール：jmalcolm@uu.net
Johnson Agogbua UUNET (MCI Worldcom) 3060 Williams Drive Fairfax, VA 22031
ジョンソンAgogbua UUNET（MCIワールドコム）3060ウィリアムズドライブフェアファックス、VA 22031
Phone: +1 703-206-5794 EMail: ja@uu.net
電話：+1 703-206-5794電子メール：ja@uu.net
Mike O'Dell UUNET (MCI Worldcom) 3060 Williams Drive Fairfax, VA 22031
マイク・オデルUUNET（MCIワールドコム）3060ウィリアムズドライブフェアファックス、VA 22031
Phone: +1 703-206-5890 EMail: mo@uu.net
電話：+1 703-206-5890電子メール：mo@uu.net
Jim McManus UUNET (MCI Worldcom) 3060 Williams Drive Fairfax, VA 22031
ジム・マクマナスUUNET（MCIワールドコム）3060ウィリアムズドライブフェアファックス、VA 22031
Phone: +1 703-206-5607 EMail: jmcmanus@uu.net
電話：+1 703-206-5607電子メール：jmcmanus@uu.net
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。