[要約] RFC 2702は、MPLS上のトラフィックエンジニアリングの要件についてのガイドラインです。その目的は、MPLSネットワークでのトラフィック制御と最適化を実現するための要件を定義することです。
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
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.
Copyright（c）The Internet Society（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).
Multiprotocolラベルスイッチング（MPLS）[1,2]ラベルスワッピングフレームワークをネットワークレイヤールーティングと統合します。基本的なアイデアには、イングレスのパケットに短い固定長ラベルをMPLSクラウドに割り当てることが含まれます（等価クラス[1,2]の転送の概念に基づいています）。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つは、交通工学にあります。このアプリケーションの重要性はすでに十分に認識されています（[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とRekhter [3]などの作品に焦点を当てています。[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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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）は、運用ネットワークのパフォーマンスの最適化に関係しています。一般に、インターネットトラフィックの測定、モデリング、特性評価、および制御へのテクノロジーと科学原則の適用、および特定のパフォーマンス目標を達成するためのそのような知識と技術の適用を網羅しています。MPLに関して関心のある交通工学の側面は、測定と制御です。
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:
トラフィックエンジニアリングに関連する主要なパフォーマンス目標は、次のいずれかに分類できます。
1. traffic oriented or
1. 交通指向または
2. resource oriented.
2. リソース指向。
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.
トラフィック指向のパフォーマンス目標には、トラフィックストリームのQOを強化する側面が含まれます。単一のクラスであるベストエフェクションインターネットサービスモデルでは、トラフィック指向の主要なパフォーマンス目標には、パケット損失の最小化、遅延の最小化、スループットの最大化、およびサービスレベル契約の執行が含まれます。単一のクラスのベストエフェクションインターネットサービスモデルでは、パケット損失の最小化は、最も重要なトラフィック指向のパフォーマンス目標の1つです。統計的に制限されたトラフィック指向のパフォーマンス目標（ピークからピークまでのパケット遅延変動、損失比、最大パケット転送遅延など）は、今後の差別化されたサービスインターネットで有用になる可能性があります。
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.
2番目のタイプの混雑問題、つまり非効率的なリソース割り当てに起因する問題は、通常、交通工学を通じて対処できます。
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:
理想的には、制御アクションには次のことが含まれる必要があります。
1. Modification of traffic management parameters,
1. トラフィック管理パラメーターの変更、
2. Modification of parameters associated with routing, and
2. ルーティングに関連するパラメーターの変更、および
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: 1. the shortest paths of multiple traffic streams converge on specific links or router interfaces, or
既存のインターネットインテリアゲートウェイプロトコルによって提供される制御機能は、トラフィックエンジニアリングには適していません。これにより、ネットワークのパフォーマンスの問題に対処するための効果的なポリシーを実現することが困難になります。実際、最短のパスアルゴリズムに基づくIGPは、インターネット内の自律システムの混雑問題に大きく貢献しています。SPFアルゴリズムは一般に、単純な添加剤メトリックに基づいて最適化します。これらのプロトコルはトポロジー駆動型であるため、帯域幅の可用性とトラフィック特性は、ルーティングの決定において考慮される要因ではありません。したがって、混雑は次の場合に頻繁に発生します。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.
現在のIGPSの不十分さを回避するための一般的なアプローチは、ATM上のIPやフレームリレーのIPなどのオーバーレイモデルを使用することです。オーバーレイモデルは、任意の仮想トポロジをネットワークの物理トポロジの上にプロビジョニングできるようにすることにより、設計空間を拡張します。仮想トポロジーは、IGPルーティングプロトコルへの物理的リンクとして表示される仮想回路から構築されています。オーバーレイモデルは、次のようなトラフィックとリソース制御をサポートするための追加の重要なサービスを提供します。制御機能、（5）トラフィックの形成および交通警察機能、および（6）VCの生存可能性。これらの機能により、さまざまなトラフィックエンジニアリングポリシーの実現が可能になります。たとえば、仮想回路を簡単に再ルーティングして、過剰に活用されたリソースから比較的活用されていないリソースにトラフィックを移動できます。
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）トラフィックトランクをインスタンス化してLSPにマッピングできます。（6）MPLSは、LSPとトラフィックトランクの配置を制限するリソースに関連付けられています。一方、Classical Destinationに基づいたIP転送のみが集約のみを許可します。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グラフは、グラフのノードを構成するLSRSのセットと、LSR間のポイント接続性への論理ポイントを提供するLSPのセットで構成され、したがって誘導グラフのリンクとして機能します。ラベルスタックの概念に基づいて、階層誘導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.
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.
There are basically three fundamental problems that relate to Traffic Engineering over MPLS.
基本的に、MPLを介した交通工学に関連する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.
- 2番目の問題は、転送等価クラスをトラフィックトランクにマッピングする方法に関するものです。
- 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).
このドキュメントは、リストされている最初の2つの問題に焦点を当てていません。（偶数も非常に重要です）。代わりに、この原稿の残りの部分は、効率的で信頼性の高いネットワーク操作をもたらす方法で3番目のマッピング関数を実行できる機能に焦点を当てます。これは、誘導されたMPLSグラフ（H）を「ベース」ネットワークトポロジ（g）にマッピングする問題です。
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.
前のセクションでは、現代のインターネットでの交通工学の基本的な機能をレビューしました。そのアクティビティへのMPLの適用性についても議論されました。この原稿の残りのセクションでは、大規模なネットワーク内の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の一部である必要はありません。ただし、2つは一緒に統合する必要があります。
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とは異なります。運用上のコンテキストでは、トラフィックトランクをあるパスから別のパスに移動できます。
- 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.
実際には、トラフィックトランクは、その侵入と出口LSR、その上にマッピングされる転送等価クラス、およびその動作特性を決定する属性のセットによって特徴付けられます。
Two basic issues are of particular significance: (1) parameterization of traffic trunks and (2) path placement and maintenance rules for traffic trunks.
2つの基本的な問題は、特に重要です。（1）トラフィックトランクのパラメーター化と（2）トラフィックトランクのパス配置およびメンテナンスルール。
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つのトランクは、宛先ノードから発信元ノードへのトラフィックを運びます。次の2つの条件が保持されている場合、2つのそのようなトラフィックトランクの融合を1つの双方向トラフィックトランク（BTT）と呼びます。
- 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.
- 両方のトラフィックトランクは、オリジネーターノードと呼ばれる1つの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."
BTTのトポロジカル特性も考慮する必要があります。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.
- Reroute：トラフィックトランクがルートを変更するようにします。これは、管理アクションを通じて、または基礎となるプロトコルによって自動的に行うことができます。
- 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
- 優先属性
- 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."
「パス選好ルール」属性は、管理上指定された明示的なパスに関連付ける必要があります。パス選好ルール属性は、管理上構成された明示的なパスが「必須」または「非志願」であるかを示すバイナリ変数です。
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）明示的除外。
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）再最適化を無効にします。
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つのノードをパーティション化する「MINカット」を横切る最大許容フローよりも少ない場合があります。この場合、実行可能な唯一のソリューションは、集約トラフィックをサブストリームに適切に分割し、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.
優先属性は、トラフィックトランクの相対的な重要性を定義します。制約ベースのルーティングフレームワークが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.
Preemption属性を使用して、トラフィックトランクの4つの先制モードを指定できます。（1）プリエンプトールが有効になっている、（2）非領域、（3）プリエンプティブ、および（4）非償還。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.
「a」と言うトラフィックトランクは、次の5つの条件のすべてが *すべて * * "" a "が「b」よりも比較的高い優先度を持っている場合にのみ、別のトラフィックトランクを先取りすることができます。）「a」は「b」で使用されているリソースを主張します。（iii）リソースは、特定の決定基準に基づいて「a」と「b」を同時に収容できません。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.
Resilience属性は、断層条件下でのトラフィックトランクの動作を決定します。つまり、トラフィックトランクが通過する経路に沿って障害が発生した場合です。このような状況では、次の基本的な問題に対処する必要があります。（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. トラフィックトランクを再ルーティングしないでください。たとえば、トラフィックトランクを再ルーティングする必要なく、故障シナリオの下でサービスの継続性を保証する代替メカニズムを通じてプロビジョニングされている生存性スキームが既に導入されている場合があります。このような代替スキームの例（確かに他の多くの人が存在します）は、複数の並列ラベルスイッチされたパスが2つのノード間でプロビジョニングされ、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.
「基本的な」回復力の属性は、障害の影響を受けたパスの交通トランクに適用される回復手順を示します。具体的には、「基本的な」レジリエンス属性は、パスのセグメントが失敗したときにターゲットトラフィックトランクが再ルーティングされるかどうかを決定するバイナリ変数です。「拡張された」レジリエンス属性を使用して、障害シナリオの下で取得する詳細なアクションを指定できます。たとえば、拡張されたレジリエンス属性は、障害条件下で使用する一連の代替パスと、指定された各パスの相対的な選好を支配するルールを指定する場合があります。
Resilience attributes mandate close interaction between MPLS and routing.
Resilience属性は、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の下では、リソースの制約を考慮せずに、HOPプロトコルによる従来のホップ（明示的なパスを介して）を介してルーティングできるため、回路スイッチングスキームよりも複雑です。
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. トラフィックトランクの配置を特定のリソースのサブセットに明示的に制限します。
4. Implement generalized inclusion / exclusion policies.
4. 一般化されたインクルージョン /除外ポリシーを実装します。
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:
ホップIGPSによるトポロジ駆動ホップを使用するルーターの場合、制約ベースのルーティングは、2つの方法の少なくとも1つに組み込むことができます。
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]).
1. OSPFやIS-ISなどの現在のIGPプロトコルを拡張して、制約ベースのルーティングをサポートします。このような拡張をOSPFに提供するための努力はすでに進行中です（[5,7]を参照）。
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.
2. 現在のIGPと共存できる各ルーターに制約ベースのルーティングプロセスを追加します。このシナリオを図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
図1.レイヤー3 LSRの制約ベースのルーティングプロセス
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] Rosen、E.、Viswanathan、A。、およびR. Callon、「MPLSの提案された建築」は進行中です。
[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.、Feldman、N.、Fredette、A.、Swallow、G。and A. Viswanathan、「マルチプロトコルラベルスイッチングのフレームワーク」、進行中の作業。
[3] Li, T. and Y. Rekhter, "Provider Architecture for Differentiated Services and Traffic Engineering (PASTE)", RFC 2430, October 1998.
[3] Li、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.、Davie、B.、Katz、D.、Rosen、E。、およびG. Swallow、「Cisco Systemsのタグスイッチングアーキテクチャ - 概要」、RFC 2105、1997年2月。
[5] Zhang, Z., Sanchez, C., Salkewicz, B. and E. Crawley "Quality of Service Extensions to OSPF", Work in Progress.
[5] Zhang、Z.、Sanchez、C.、Salkewicz、B。、およびE. Crawleyは「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] Crawley、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] Guerin、R.、Kamat、S.、Orda、A.、Przygienda、T。、およびD. Williams、「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. YangおよびA. Reddy、「パケットスイッチングネットワークにおける混雑制御アルゴリズムの分類法」、IEEE Network Magazine、Volume 9、Number 5、1995年7月/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. Lee、M。Hluchyi、およびP. Humblet、「統合通信ネットワークのサービス品質の制約の対象となるルーティング」、IEEE Network、1995年7月、pp 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.
著者は、この文書の以前のドラフトのレビューについてYakov Rekhterに感謝したいと思います。著者はまた、ルイ・ママコスとビル・バーンズの有益な提案に感謝したいと思います。
Daniel O. Awduche UUNET (MCI Worldcom) 3060 Williams Drive Fairfax, VA 22031
ダニエルO.アウドゥシュウーネット（MCIワールドコム）3060ウィリアムズドライブフェアファックス、バージニア州22031
Phone: +1 703-208-5277
EMail: awduche@uu.net
Joe Malcolm UUNET (MCI Worldcom) 3060 Williams Drive Fairfax, VA 22031
Joe Malcolm Uunet（MCI Worldcom）3060 Williams Drive Fairfax、VA 22031
Phone: +1 703-206-5895
EMail: jmalcolm@uu.net
Johnson Agogbua UUNET (MCI Worldcom) 3060 Williams Drive Fairfax, VA 22031
Johnson Agogbua Uunet（MCI Worldcom）3060 Williams Drive Fairfax、VA 22031
Phone: +1 703-206-5794
EMail: ja@uu.net
Mike O'Dell UUNET (MCI Worldcom) 3060 Williams Drive Fairfax, VA 22031
Mike O'Dell Uunet（MCI Worldcom）3060 Williams Drive Fairfax、VA 22031
Phone: +1 703-206-5890
EMail: mo@uu.net
Jim McManus UUNET (MCI Worldcom) 3060 Williams Drive Fairfax, VA 22031
Jim McManus Uunet（MCI Worldcom）3060 Williams Drive Fairfax、VA 22031
Phone: +1 703-206-5607
EMail: jmcmanus@uu.net
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。