RFC2702 日本語訳
2702 Requirements for Traffic Engineering Over MPLS. D. Awduche, J.Malcolm, J. Agogbua, M. O'Dell, J. McManus. September 1999. (Format: TXT=68386 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Awducheがコメントのために要求するワーキンググループD.をネットワークでつないでください: 2702年のJ.マルコムカテゴリ: 情報のJ.のAgogbua M.オデルJ.マクマナスUUNET(MCI Worldcom)1999年9月
Requirements for Traffic Engineering Over MPLS
MPLSの上の交通工学のための要件
Status of this Memo
この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)インターネット協会(1999)。 All rights reserved。
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.
このドキュメントはMultiprotocol Label Switching(MPLS)の上にTraffic Engineeringのための1セットの要件を提示します。 それは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
1.0序論… 2 1.1用語… 3 1.2 組織を記録してください… 3 2.0 交通工学… 4 2.1 交通工学パフォーマンス目標… 4 2.2の交通とリソースは制御されます… 6 現在のIGPの2.3の限界がメカニズムを制御します… 6 3.0MPLSと交通工学… 7 3.1 誘発されたMPLSはグラフ化します… 9 3.2 交通工学の基本的な問題はMPLSの上で.105.0の交通トランク属性と特性を設計しながら、MPLS. 9 4.0の上で能力を交通に増大させました… 10 5.1 双方向の交通トランクス… 11 5.2 交通トランクスにおける基本的な操作… 12 5.3 会計とパフォーマンスモニター… 12
Awduche, et al. Informational [Page 1] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [1ページ]情報のRFC2702MPLS交通工学1999年9月
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
5.4 交通トランクスの基本的な属性… 13 5.5 交通パラメタ属性… 14 5.6 一般的な経路選択と管理属性… 14 5.6 .1は行政上明白な経路を指定しました… 15 5.6 好みの.2階層構造はマルチ経路に統治されます… 15 5.6 .3 リソースクラス親近感属性… 16 5.6 .4適応性属性… 17 5.6 .5 平行な交通トランクスの向こう側に分配をロードしてください… 18 5.7優先権属性… 18 5.8先取り属性… 18 5.9弾力属性… 19 5.10 属性を取り締まります… 20 6.0 リソース属性… 21 6.1の最大の配分乗数… 21 6.2 リソースクラス属性… 22 7.0 規制ベースのルート設定… 22 7.1 規制ベースのルート設定の基本の特徴… 23 7.2 実現問題… 24 8.0結論… 25 9.0 セキュリティ問題… 26 10.0の参照箇所… 26 11.0の承認… 27 12.0人の作者のアドレス… 28 13.0 完全な著作権宣言文… 29
1.0 Introduction
1.0 序論
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 Label Switching(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]).
この比較的簡単なパラダイムから現れている微分されたサービスインターネットの多くの批判的な問題を記述する1セットの強力な構造物について工夫できます。 MPLSの最も重要な初期のアプリケーションの1つがTraffic Engineeringにあるでしょう。 このアプリケーションの重要性は既によく認識されています([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
この原稿は排他的にMPLSのTraffic Engineeringアプリケーションに焦点を合わせられます。 明確に、このドキュメントの目標は大きいインターネットの基幹でTraffic Engineeringのための問題と要件を強調することです。 期待はMPLS仕様、またはそこから引き出された実現が記述するということです。
Awduche, et al. Informational [Page 2] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [2ページ]情報のRFC2702MPLS交通工学1999年9月
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実現について必要である基本的な能力と機能性の記述は提示されます。
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.
焦点がインターネットの基幹にありますが、本書では説明された能力が企業網で等しくTraffic Engineeringに適切であることに注意されるべきです。 一般に、ただ一つの技術的な管理における下少なくとも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の下でTraffic EngineeringとTraffic管理に関係する問題、最も著しく李、Rekhter[3]、および他のものの作品に焦点を合わせました。 [3]では、スケーラブルな微分されたサービスとTraffic Engineeringをインターネットに提供するのにMPLSとRSVPを使う構造は提案されます。 現在の原稿は前述の、そして、同様の努力の補足となります。 それは大きいインターネットの基幹を管理する作者の運用経験を反映します。
1.1 Terminology
1.1 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[11]で説明されるように本書では解釈されることであるべきですか?
1.2 Document Organization
1.2 ドキュメント組織
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はインターネットのTraffic Engineeringの基本機能について論じます。 セクション3 MPLSの交通Engineeringの可能性の概観を提供します。 セクション1〜3は本質的にはバックグラウンドの材料です。 セクション4はMPLSの上にTraffic Engineeringに、基本的な要件の概観を提示します。 セクション5はTraffic Engineeringに適切な交通トランクスの望ましい属性と特性について説明します。 セクション6は彼らを通して交通トランクスとLSPsのroutabilityを抑制するためにリソースに関連づけることができる1セットの属性を提示します。 セクション7はMPLSドメインでの「規制ベースのルーティング」枠組みの導入を支持します。 最終的に、セクション8は結びの言葉を含みます。
Awduche, et al. Informational [Page 3] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [3ページ]情報のRFC2702MPLS交通工学1999年9月
2.0 Traffic Engineering
2.0 交通工学
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.
このセクションは現代のインターネットのAutonomous SystemのTraffic Engineeringの基本機能について説明します。 交通と資源管理に関する現在のIGPsの限界は強調されます。 このセクションは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.
交通Engineering(TE)は操作上のネットワークのパフォーマンスの最適化に関係があります。 一般に、それは、特定のパフォーマンス目標を達成するために技術の適用、インターネットトラフィックの測定、モデル、特殊化、およびコントロールへの科学原理、およびそのような知識とテクニックの応用を包含します。 MPLSに関しておもしろいTraffic Engineeringの局面は、測定とコントロールです。
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.
同時にネットワーク資源利用とトラフィック性能を最適化している間、効率的で信頼できるネットワーク操作を容易にしますインターネットTraffic Engineeringの主要な目標がことである。 交通Engineeringはネットワーク資産の高い費用とインターネットの商業の、そして、競争力がある本質で多くの大きいAutonomous Systemsで必須機能になりました。 これらの要素は最大限度の経営効率の必要性を強調します。
2.1 Traffic Engineering Performance Objectives
2.1 交通工学パフォーマンス目標
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.
交通指向のパフォーマンス目標は交通の流れのQoSを高める局面を含んでいます。1つのクラス、ベストエフォート型インターネットのサービスモデルでは、主要な交通は目的が含む性能を向けました: パケット損失の最小化、遅れの最小化、スループットの最大化、およびサービスの実施は協定を平らにします。 単独のクラスベストエフォート型インターネットのサービスモデルの下では、パケット損失の最小化は最も重要な交通指向のパフォーマンス目標の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
リソース指向のパフォーマンス目標はリソース利用の最適化に関係する局面を含んでいます。 ネットワーク資源の能率的経営は到達のための手段です。
Awduche, et al. Informational [Page 4] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [4ページ]情報のRFC2702MPLS交通工学1999年9月
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.
リソースはパフォーマンス目標を適応させました。 一般に、利用されて、交互の実行可能経路に沿った他の部分集合がunderutilizedされたままで残っていますが、充血して、ネットワーク資源の部分集合が終わるようにならないのを保証するのは特に、望ましいです。 帯域幅は現代のネットワークで重要なリソースです。 したがって、Traffic Engineeringの中枢機能は効率的に帯域幅リソースを管理することです。
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. 交通の流れが効率悪く利用可能資源に写像されるとき。 他のものが残っている間、ネットワーク資源の部分集合が利用され過ぎるようになることを引き起こすのをunderutilizedされました。
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) 容量の拡大、または古典的な混雑制御方法、または)の(iii両方の(ii)アプリケーション。 古典的な混雑制御方法が、要求を規制するのを試みるので、交通は利用可能資源に合います。 輻輳制御のための古典的なテクニックは: 制限、窓のフロー制御、ルータ待ち行列管理、スケジュールベースのコントロール、および他のものを評定してください。 (そこに[8]と参照を見ます。)
The second type of congestion problems, namely those resulting from inefficient resource allocation, can usually be addressed through Traffic Engineering.
通常、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.
明確に、ロードバランシングは重要なネットワークパフォーマンスの最適化方針です。 それにもかかわらず、Traffic Engineeringに提供された能力は、ネットワーク管理者が行き渡っている原価構造とユーティリティか収入モデルを考慮に入れる他の政策を実施できるくらい十分フレキシブルであるべきです。
Awduche, et al. Informational [Page 5] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [5ページ]情報のRFC2702MPLS交通工学1999年9月
2.2 Traffic and Resource Control
2.2 交通と資源管理
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.
操作上のネットワークのパフォーマンスの最適化は基本的に制御の問題です。 交通工学プロセス・モデルでは、Traffic Engineer、または適当なオートマトンがコントローラとして適応型のフィードバック制御系で務めます。 このシステムは1セットの相互接続ネットワーク要素、ネットワーク性能監視システム、および1セットのネットワーク・コンフィギュレーション管理ツールを含んでいます。 Traffic Engineerは必要な状態にネットワークを動かすためにコントロール方針を定式化して、監視システムを通してネットワークの事情を観測して、交通を特徴付けて、コントロール動作を適用します、コントロール方針によると。 将来の傾向と取り除く動作を適用すると予測された望ましくない未来が述べる予期するのに予測のテクニックを使用することによって、親活発にネットワークの現状に対応して行動を取ることによって、これを反動的に達成できます。
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.
可能であるときはいつも、交通工学の過程にかかわる手動の介入のレベルは最小にされるべきです。 上で分配されてスケーラブルなファッションで説明されたコントロール動作の局面を自動化することによって、これを達成できます。
2.3 Limitations of Current IGP Control Mechanisms
現在のIGPの2.3の限界がメカニズムを制御します。
This subsection reviews some of the well known limitations of current IGPs with regard to Traffic Engineering.
この小区分はTraffic Engineeringに関して現在のIGPsのよく知られている限界のいくつかを見直します。
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:
Traffic Engineeringには、既存のインターネット内部のゲートウェイプロトコルによって提供されたコントロール能力は適切ではありません。 これで、そのネットワーク性能問題を訴えるために有効な政策を顕在化するのは難しくなります。本当に、最短パスアルゴリズムに基づくIGPsはインターネットの中のAutonomous Systemsの混雑問題にかなり貢献します。 一般に、SPFアルゴリズムは簡単な添加物に基づいてメートル法で最適化されます。 これらのプロトコルが運転されたトポロジーであるので、帯域幅の有用性と交通の特性はルーティング決定で考えられた要素ではありません。 その結果、混雑が頻繁に起こる、いつ:
Awduche, et al. Informational [Page 6] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [6ページ]情報のRFC2702MPLS交通工学1999年9月
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.
可能な代替パスであるなら過剰生産能力で明白なこれらのシナリオは存在しています。 それが混雑問題のこの局面である、(--準最適の資源配分の兆候) 活発に取り除くそのTraffic Engineering目的。 上に成功でいくらかの記載された混雑の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のように。 任意の仮想のtopologiesがネットワークの物理的なトポロジーの上で食糧を供給されるのを可能にすることによって、オーバレイモデルはデザインスペースを広げています。 仮想のトポロジーはIGPルーティング・プロトコルへの物理的なリンクとして現れる仮想のサーキットから組み立てられます。 オーバレイモデルは交通と資源管理、包含を支持するために追加大任を提供します: (1) VCレベルにおける規制ベースのルーティング、(2)は行政上構成可能な明白なVC経路、(3)経路圧縮、(4)コール許可コントロール機能、(5)交通形成、および交通に機能を取り締まって、VCsの(6)の生存性を支持します。 これらの能力はさまざまなTraffic Engineering方針の実現を可能にします。 例えば、交通を利用され過ぎるリソースから比較的underutilizedされたものに動かすために容易に仮想のサーキットを別ルートで送ることができます。
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.
大きい濃いネットワークにおけるTraffic Engineeringに関しては、現在のオーバレイモデルがある機能性のレベルが少なくとも等しいMPLSを備えているのは望ましいです。 幸い、かなりまっすぐな前進の態度でこれができます。
3.0 MPLS and Traffic Engineering
3.0 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の適用性の概観をTraffic Engineeringに供給します。 その後のセクションはTraffic Engineering必要条件を満たすのに必要である能力のセットについて論じます。
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
潜在的に統合方法と、そして、オーバレイモデルと、現在競争している代替手段より低い費用において利用可能な機能性の大部分を提供できるので、Traffic Engineeringには、MPLSは戦略上重要です。 等しさ、重要に、MPLSは提供します。
Awduche, et al. Informational [Page 7] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [7ページ]情報のRFC2702MPLS交通工学1999年9月
the possibility to automate aspects of the Traffic Engineering function. This last consideration requires further investigation and is beyond the scope of this manuscript.
Traffic Engineering機能の局面を自動化する可能性。 この最後の考慮は、さらなる調査を必要として、この原稿の範囲を超えています。
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交通トランクスの概念はこのドキュメントの残りに手広く使用されます。 李とRekhter[3]によると、交通トランクはLabel Switched Pathの中に置かれる同じクラスの交通の流れの集合です。 本質的には、交通トランクは特定の特性を関連づけることができる交通の抽象的表現です。 発送できる物であると交通トランクスをみなすのは役に立ちます。 すなわち、交通トランク横断を変えることができる経路。 この点で、交通トランクスはATMとFrame Relayネットワークにおいて仮想のサーキットと同様です。 しかしながら、交通トランクと、経路と、本当に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.
Traffic EngineeringのためのMPLSの魅力を以下の要素の結果と考えることができます: (1) 明白なラベルは手動の管理動きで容易に作成できるか、または基本的なプロトコルによる自動化された動作で、潜在的に効率的に(2)LSPsを維持できるというパラダイムを進めるベースの目的地によって抑制されない経路を切り換えて、(3) 交通トランクスをLSPsに例示して、写像できて、(4) それらの行動の特性を調節する交通トランクスに1セットの属性は関連づけることができます; (5) 1セットの属性は(7) リソースに関連づけられて、どれがそれらにもかかわらず、MPLSが交通集合と非集計の両方のために許容する(6)にもかかわらず、古典的な目的地の向こう側にLSPsと交通トランクスのプレースメントを抑制するかが集合だけを許可証に送りながら、IPを基礎づけただけであり、「規制ベースのルーティング」枠組みをMPLSと統合するのは比較的簡単です、MPLSの良い実現がTraffic Engineeringのために競争している代替手段よりかなり低いオーバーヘッドを提供できる(8)ということであるかもしれません。
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の上のTraffic Engineeringのための既存の提案の多くが明白なLSPsを作成する可能性だけに焦点を合わせます。 Traffic Engineeringに、この能力は基本的ですが、それは本当に十分ではありません。 追加増大が、大きい操作上のネットワークのパフォーマンスの最適化につながる方針の実現を伸ばすのに必要です。 必要な増大のいくつかがこの原稿で説明されます。
Awduche, et al. Informational [Page 8] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [8ページ]情報のRFC2702MPLS交通工学1999年9月
3.1 Induced MPLS Graph
3.1 誘発されたMPLSはグラフ化します。
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ドメインでTraffic Engineeringに主要な「誘発されたMPLSグラフ」の概念を紹介します。 誘発されたMPLSグラフはオーバレイモデルの仮想のトポロジーに類似しています。 それは交通トランクスのために物理ネットワークにLSPsの品揃えで論理的に写像されます。
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の1セットと論理的なポイント・ツー・ポイントの接続性をLSRsの間に供給して、したがって誘発されたグラフのリンクとして機能するLSPsの1セットから成ります。ラベルスタックの概念に基づく階層的な誘発された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.
G=(V、E、c)がネットワークの物理的なトポロジーについて表現する能力を与えられたグラフであることをさせてください。 ここで、Vはネットワークにおけるノードのセットです、そして、Eはリンクのセットです。 vとwがG.の下で直接接続されるなら、すなわち、vとVのw、物に関して、Eには(v、w)があります。パラメタ「c」はEに関連している容量と他の規制の1セットです、そして、V.Weは「ベース」ネットワーク形態に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)が誘発されたMPLSグラフであることをさせてください。そこでは、Uは、ネットワークでLSRsのセットを表すVの部分集合、または、より正確に少なくとも1LSPの終点であるLSRsのセットです。 ここで、FはLSPsのセットです、終点としてxとyがあるLSPがあればUのxとyに関して物(x、y)がFにあるように。 パラメタ「d」がF.Evidentlyに関連している要求と制限のセットである、Hは有向グラフです。 HをGの推移性の特性に依存するのを見ることができます。
3.2 The Fundamental Problem of Traffic Engineering Over MPLS
3.2 MPLSの上の交通工学の基本的な問題
There are basically three fundamental problems that relate to Traffic Engineering over MPLS.
基本的に、MPLSの上でTraffic Engineeringに関連する3つの基本的な問題があります。
- The first problem concerns how to map packets onto forwarding
equivalence classes.
- 第1の問題はどう推進同値類にパケットを写像するかに関係があります。
- 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番目の問題はラベルを通して交通トランクスを物理ネットワークトポロジーに写像するのがどう経路を切り換えたかに関係があります。
Awduche, et al. Informational [Page 9] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [9ページ]情報のRFC2702MPLS交通工学1999年9月
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番目のマッピング機能が効率的で信頼できるネットワーク操作をもたらす方法で実行されることを許可する能力に焦点を合わせるでしょう。 これは本当に「ベース」ネットワーク形態(G)に誘発されたMPLSグラフ(H)を写像するという問題です。
4.0 Augmented Capabilities for Traffic Engineering Over MPLS
4.0はMPLSの上の交通工学のために能力を増大させました。
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.
前項は現代のインターネットのTraffic Engineeringの基本機能について調査しました。 また、その活動へのMPLSの適用性について議論しました。 この原稿の残っているセクションはMPLSの上で大きいネットワークでTraffic Engineeringを完全にサポートするのに必要である機能的な能力について説明します。
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.
操作上のネットワークでは、オペレータがダイナミックにオンラインで逆にネットワーク操作を中断しないでこれらの属性を変更できるのは、非常に望ましいです。
5.0 Traffic Trunk Attributes and Characteristics
5.0 トラフィックトランク属性と特性
This section describes the desirable attributes which can be associated with traffic trunks to influence their behavioral characteristics.
このセクションはそれらの行動の特性に影響を及ぼすためにトラフィックトランクスに関連づけることができる望ましい属性について説明します。
Awduche, et al. Informational [Page 10] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [10ページ]情報のRFC2702MPLS交通工学1999年9月
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 VCsと同様の)です。
- 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) トラフィックトランクス、(2)経路プレースメント、およびメインテナンスのパラメタリゼーションはトラフィックトランクスのために統治されます。
5.1 Bidirectional Traffic Trunks
5.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個のトランクが起因するノードから目的地ノードまでトラフィックを運びます。 後方のトランクと呼ばれるもう片方のトランクは目的地ノードから起因するノードまでトラフィックを運びます。 以下の2つの条件が成立するなら、私たちは1個の双方向のトラフィックトランク(BTT)のような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.
- 両方のトラフィックトランクスは創始者ノードと呼ばれる1LSRでの原子動作を通して、または、ネットワークマネージメントステーションでの原子動作を通して例示されます。
- Neither of the composite traffic trunks can exist without the
other. That is, both are instantiated and destroyed together.
- 合成トラフィックトランクスのどちらももう片方なしで存在できません。 すなわち、両方が、一緒に例示されて、破壊されます。
Awduche, et al. Informational [Page 11] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [11ページ]情報のRFC2702MPLS交通工学1999年9月
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.
双方向のトラフィックトランクスが単に管理便利であることに注意されるべきです。 実際には、単方向のトラフィックトランクスだけを使用することでほとんどの交通工学機能を実装することができます。
5.2 Basic Operations on Traffic Trunks
5.2 トラフィックトランクスにおける基本的な操作
The basic operations on traffic trunks significant to Traffic Engineering purposes are summarized below.
Traffic Engineering目的に重要なトラフィックトランクスにおける基本的な操作は以下へまとめられます。
- 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.
上記はトラフィックトランクスにおける基本的な操作であると考えられます。 また、兼業も取り締まりやトラフィック形成のように可能です。
5.3 Accounting and Performance Monitoring
5.3 会計とパフォーマンスモニター
Accounting and performance monitoring capabilities are very important to the billing and traffic characterization functions. Performance statistics obtained from accounting and performance monitoring
会計と性能のモニターしている能力は支払いとトラフィック特殊化機能に非常に重要です。 会計と性能モニターから得られたパフォーマンス統計
Awduche, et al. Informational [Page 12] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [12ページ]情報のRFC2702MPLS交通工学1999年9月
systems can be used for traffic characterization, performance optimization, and capacity planning within the Traffic Engineering realm..
トラフィック特殊化、パフォーマンスの最適化、およびキャパシティプランニングにTraffic Engineering分野の中でシステムを使用できます。
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の上のTraffic Engineeringのための必須の条件であると考えられるべきです。
5.4 Basic Traffic Engineering Attributes of Traffic Trunks
5.4 トラフィックトランクスの基本的な交通工学属性
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ドメインへのイングレスにおける同値類に分類されて、写像されるとき、管理動作でトラフィックトランクスに明らかに属性を割り当てることができますか、または基本的なプロトコルはそれとなくそれらを割り当てることができます。 属性が元々Traffic Engineering目的のためにどう割り当てられたかにかかわらず、行政上そのような属性を変更するのは可能であるべきです。
The basic attributes of traffic trunks particularly significant for Traffic Engineering are itemized below.
Traffic Engineeringには、特に重要なトラフィックトランクスの基本的な属性は以下に箇条書きされます。
- Traffic parameter attributes
- トラフィックパラメタ属性
- Generic Path selection and maintenance attributes
- ジェネリックPath選択とメインテナンス属性
- 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.
彼らがトラフィックトランクスのある2進の関係を言い表すので、優先権と先取りを関係属性と見なすことができます。 概念的に、これらの2進の関係は経路設立と経路メインテナンスの間ネットワーク資源を競争するときトラフィックトランクスが互いに対話する方法を決定します。
Awduche, et al. Informational [Page 13] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [13ページ]情報のRFC2702MPLS交通工学1999年9月
5.5 Traffic parameter attributes
5.5 トラフィックパラメタ属性
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.
帯域幅配分の目的のために、トラフィックトランクのトラフィックパラメタから帯域幅要件のただ一つの正準な値を計算できます。 これらの計算を実行するためのテクニックはよく知られています。 この1つの例が有効な帯域幅の理論です。
5.6 Generic Path Selection and Management Attributes
5.6 ジェネリック経路選択と管理属性
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では、自動的に1セットの規制を条件として経路を計算できる規制ベースのルーティングフレームワークは説明されます。 セクション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.
経路選択と管理過程を誘導するために、1セットの属性が必要です。 トラフィックトランク経路選択と管理に関連している基本的な属性と行動の特性はこの小区分の残りで説明されます。
Awduche, et al. Informational [Page 14] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [14ページ]情報のRFC2702MPLS交通工学1999年9月
5.6.1 Administratively Specified Explicit Paths
5.6.1 行政上指定された明白な経路
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.
しかしながら、行政上指定された明白な経路が「非義務的な」優先規則属性値で選択されるなら、中古ですが、経路は可能であるべきです。 さもなければ、基本的なプロトコルは代わりに代替パスを選ぶことができます。
5.6.2 Hierarchy of Preference Rules For Multi-Paths
5.6.2 マルチ経路への優先規則の階層構造
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.
いくつかの実際的な文脈では、行政上1セットの候補の明白な道を与えられたトラフィックトランクに指定して、経路で好みの関係の階層構造を定義する能力を持っているのは役に立つ場合があります。 経路設立の間、優先規則は、候補リストから適当な経路を選択するために適用されます。 また、失敗シナリオの下では、優先規則は、候補リストから代替パスを選択するために適用されます。
Awduche, et al. Informational [Page 15] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [15ページ]情報のRFC2702MPLS交通工学1999年9月
5.6.3 Resource Class Affinity Attributes
5.6.3 リソースクラス親近感属性
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を見る)のクラスを指定するのにトラフィックトランクに関連しているリソースクラス親近感属性を使用できます。 これらは与えられたトラフィックトランクによって横断された経路に追加規制を課すのに使用できる方針属性です。 tuplesの系列としてトラフィックのためのリソースクラス親近感属性を指定できます:
<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値変数であるかもしれません: (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.
親近感属性が2値変数であるなら、与えられたトラフィックトランクに関連しているリソースクラスの親近感を指定するのに論理式を使用するのは可能であるかもしれません。
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. 明白な除外には、経路プレースメント計算を実行する前に指定されたクラスに属すすべてのリソースを剪定してください。
Awduche, et al. Informational [Page 16] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [16ページ]情報のRFC2702MPLS交通工学1999年9月
5.6.4 Adaptivity Attribute
5.6.4 適応性属性
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.
ネットワークの特性と状態は時間がたつにつれて、変化します。 例えば、新しいリソースは利用可能になります、そして、失敗したリソースは現役に戻されるようになります、そして、割り当てられたリソースは「反-割り当て」られるようになります。 一般に、時々より効率的な経路は利用可能になります。 したがって、Traffic Engineering見解から、トラフィックトランクスがどうこの力動説に応じるかを指定するのに使用できる運営管理コントロールパラメタを持つのが必要です。 いくつかのシナリオでは、ダイナミックにネットワーク状態の変化に対応してあるトラフィックトランクスの経路を変えるのは望ましいかもしれません。 このプロセスは再最適化と呼ばれます。 他のシナリオでは、再最適化は全く望ましくないかもしれません。
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.
Adaptivity属性はトラフィックトランクスに関連している経路メインテナンスパラメタの一部です。 トラフィックトランクに関連している適応性属性は、トランクは再最適化を受けることがあるかどうかを示します。 すなわち、適応性属性は以下の値の1つを取る2値変数です: (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.
正式に、再最適化で発展を述べる適応性が失敗に弾力を含意すると述べることができますが、失敗への弾力は、変化を述べるために再最適化で一般的な適応性を含意しません。
Awduche, et al. Informational [Page 17] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [17ページ]情報のRFC2702MPLS交通工学1999年9月
5.6.5 Load Distribution Across Parallel Traffic Trunks
5.6.5 平行なトラフィックトランクスの向こう側に分配をロードしてください。
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つのノードの間の複数のトラフィックトランクスを例示することによって、この問題を扱うことができます、それぞれのトラフィックトランクが集合トラフィックの割合を運ぶように。 したがって、1組のノードの間までトラフィックを運ぶ複数の平行なトラフィックトランクスへの負荷課題の柔軟な手段が必要です。
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).
明確に、操作上の見解から、平行なトラフィックトランクスが保証される状況で、それぞれのトラフィックトランクによって運ばれるためにトラフィックの相対的比率を示すのに使用できる何らかの属性を持っているのは役に立つでしょう。 そして、指定された割合に従って、基本的なプロトコルはトラフィックトランクスに負荷を写像するでしょう。 また、一般に、パケットの間で注文されるパケットが同じマイクロ流れ(同じソースアドレス、送付先アドレス、およびポートナンバー)に属すと主張するのは望ましいです。
5.7 Priority attribute
5.7 優先権属性
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.
また、プライオリティもトラフィックトランクスの先買いの方針を顕在化できるセットに部分的なオーダーを課すのにそれらを使用できるので先取りを可能にする実装で重要です。
5.8 Preemption attribute
5.8 先取り属性
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
先取り属性は、トラフィックトランクが与えられた経路から別のトラフィックトランクを先取りできるかどうかと、別のトラフィックトランクが特定のトラフィックトランクを先取りできるかどうか決定します。 先取りは適応する両方のトラフィックの役に立ちます、そして、リソースは性能を適応させました。
Awduche, et al. Informational [Page 18] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [18ページ]情報のRFC2702MPLS交通工学1999年9月
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.
先取り属性は指定するのに使用されて、4がトラフィックトランクのためにモードを先取りするということであるかもしれません: (1) (3)の有効にされた先買権所有者、(2)非先買権所有者、先取り可能、および(4)非先取り可能。 先買権所有者の可能にされたトラフィック胴体は先取り可能として指定された低優先度トラフィックトランクスを先取りできます。 トラフィックは、相対的なプライオリティにかかわらずいかなる他のトランクスでも非先取り可能を先取りできないので、指定しました。 可能にされた先買権所有者であるより高い優先権トランクスは先取り可能として指定されたトラフィックトランクを先取りできます。
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」というトラフィックトランクはたとえば、別のトラフィックトランク、「B」を先取りできます、*以下の5のすべての*が保持を条件とさせる場合にだけ: (i) (v) 「A」には、「B」より比較的高い優先度があります、と(ii)「A」は「B」によって利用されたリソースのために主張します、そして、(iii)リソースは同時にある決定基準に基づく「A」と「B」を収容できません、そして、(iv)「A」は可能にされた先買権所有者です、そして、「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.
それは役に立ちますが、先取りは現在のベストエフォート型インターネットのサービスモデルの下における義務的な属性であると考えられません。 しかしながら、差別化されたサービスシナリオでは、先取りの必要性は、より無視できなくなります。 そのうえ、光学層からコストを削減するデータ網要素(ギガビットやテラビットラベル切り換えルータなどの)まで移行します、欠点状態の高い優先権トラフィックトランクスのための回復時間を減少させるのに先買いの戦略を使用できるという現れている光学インターネットワーキングアーキテクチャでは、ことになってください。そこでは、何らかの保護とリストア機能はそうするかもしれません。
5.9 Resilience Attribute
5.9 弾力属性
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実装は、これらの問題を扱うためにメカニズムを組み込まなければならないでしょう。
Awduche, et al. Informational [Page 19] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [19ページ]情報のRFC2702MPLS交通工学1999年9月
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つのノードの間で食糧を供給されて、方法で機能するので何らかのよく定義された方針によると、1LSPの失敗でそれに置かれた交通トランクを残っているLSPsに写像する状況です。
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値変数です。 欠点シナリオの下で取るために詳細な動きを指定するのに「広げられた」弾力属性を使用できます。 例えば、拡張弾力属性は欠点条件のもとで使用する1セットの代替パスを指定するかもしれません、それぞれの指定された経路の相対的選好を決定する規則と同様に。
Resilience attributes mandate close interaction between MPLS and routing.
弾力属性命令はMPLSとルーティングとの相互作用を閉じます。
5.10 Policing attribute
5.10 属性を取り締まること。
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.
取り締まり属性は交通トランクが不従順になると基本的なプロトコルによって取られるべきである行動を決定します。 すなわち、交通トランクが交通パラメタの指定されるとしての契約を超えていると。 一般に、属性を取り締まるのは、非conformant交通トランクが限られたか、タグ付けをされたか、または少しも取り締まり動作なしで単に進められたレートであるかどうかことであることを示すことができます。 取り締まりが使用されているなら、この機能を実行するのにATM ForumのGCRA[11]などの確立したアルゴリズムの適合を使用できます。
Awduche, et al. Informational [Page 20] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [20ページ]情報のRFC2702MPLS交通工学1999年9月
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.
したがって、Traffic Engineering見解から、行政上それぞれの交通トランクのための交通の取り締まりを可能にするか、または無能にすることができるのが必要です。
6.0 Resource Attributes
6.0 リソース属性
Resource attributes are part of the topology state parameters, which are used to constrain the routing of traffic trunks through specific resources.
リソース属性はトポロジー州のパラメタの一部です。(パラメタは、特定のリソースを通して交通トランクスのルーティングを抑制するのに使用されます)。
6.1 Maximum Allocation Multiplier
6.1 最大の配分乗数
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)は配分に利用可能なリソース対交通トランクスの割合を測定する行政上構成可能な属性です。 この属性は帯域幅をリンクするのにおいてほとんど適切です。 しかしながら、また、LSRsに関するリソースをバッファリングするのは適用できます。 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.
より効率的な資源配分政策を実施するのに交通の統計的な特性を利用するのに過剰配分を使用できます。 特に、交通トランクスの電力ピーク負荷が時間内に一致しない状況で過剰配分を使用できます。
Awduche, et al. Informational [Page 21] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [21ページ]情報のRFC2702MPLS交通工学1999年9月
6.2 Resource Class Attribute
6.2 リソースクラス属性
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:
リソースクラス属性の概念は強力な抽象化です。 Traffic Engineering見解から、交通とリソース指向のパフォーマンスの最適化の両方に関して多くの政策を実施するのにそれを使用できます。 明確に、以下のことにリソースクラス属性を使用できます。
1. Apply uniform policies to a set of resources that do not need
to be in the same topological region.
1. 同じ位相的な領域にある必要はない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.
一般に、1つ以上のリソースクラス属性をリソースに割り当てることができます。 例えば、顕著なリソースクラス属性は与えられたネットワークにおけるOC-48リンクのすべてに割り当てられるかもしれません。 追加リソースクラス属性は、ある方法で特定の封じ込め政策、または建築家へのネットワークを実行するためにネットワークの与えられた抽象化ドメインで存在するOC-48リンクの部分集合に割り当てられるかもしれません。
7.0 Constraint-Based Routing
7.0 規制ベースのルート設定
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]を見てください。
Awduche, et al. Informational [Page 22] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [22ページ]情報のRFC2702MPLS交通工学1999年9月
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.
規制ベースのルーティング枠組みは手動の構成のレベルを大いに減少させることができます、そして、介入がTraffic Engineering方針を顕在化するのが必要です。
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.
実際には、Traffic Engineer、オペレータ、またはオートマトンさえ、交通トランクの終点を指定して、1セットのトランクへの業績期待を要約する属性とトランクの行動の特性を割り当てるでしょう。 そして、規制ベースのルーティング枠組みが期待を満たすために実行可能経路を見つけると予想されます。 必要なら、次にサポート・システムが使用できるTraffic Engineerか交通工学が、よい粒状の最適化を実行するために行政上明白なルートを構成しました。
7.1 Basic Features of Constraint-Based Routing
7.1 規制ベースのルート設定の基本の特徴
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:
一般に、規制ベースのルーティング問題がほとんどの現実的な規制に手に負えないのが知られています。 発見的に知られていて、噴出してください。しかしながら、習慣、aで非常に簡単である、(1つが存在しているなら実行可能経路を見つけるのに例えば、[9])を使用できるのを確実にしてください:
Awduche, et al. Informational [Page 23] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [23ページ]情報のRFC2702MPLS交通工学1999年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.
明確に、実行可能経路がただ一つの交通トランクのために存在していると、上の簡単な手順はそれを見つけるでしょう。 結びつきを壊して、さらなる最適化を実行するために付則を指定できます。 一般に、結びつきが壊れるべきであるので、混雑は最小にされます。 しかしながら、複数の交通トランクスが発送されることになっているとき、上のアルゴリズムがいつもマッピングを見つけるかもしれないというわけではないのを示すことができます、可能なマッピングが存在していると。
7.2 Implementation Considerations
7.2 実現問題
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などの現在の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. 現在のIGPsと共存できる各ルータに規制ベースのルーティングの過程を加えることによって。 このシナリオは図1に表現されます。
------------------------------------------
| Management Interface |
------------------------------------------
| | |
------------ ------------------ --------------
| MPLS |<->| Constraint-Based | | Conventional |
| | | Routing Process | | IGP Process |
------------ ------------------ --------------
| |
----------------------- --------------
| Resource Attribute | | Link State |
| Availability Database | | Database |
----------------------- --------------
------------------------------------------ | 管理インタフェース| ------------------------------------------ | | | ------------ ------------------ -------------- | MPLS| <->| 規制ベースです。| | 従来| | | | ルート設定の過程| | IGPの過程| ------------ ------------------ -------------- | | ----------------------- -------------- | リソース属性| | リンク状態| | 有用性データベース| | データベース| ----------------------- --------------
Figure 1. Constraint-Based Routing Process on Layer 3 LSR
図1。 層3のLSRの規制ベースのルート設定の過程
Awduche, et al. Informational [Page 24] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [24ページ]情報のRFC2702MPLS交通工学1999年9月
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:
私たちがここで議論しないLayer3装置で規制ベースのルーティングを実行すると関連している多くの重要な詳細があります。 これらは以下を含んでいます:
- 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.
概要では、規制ベースのルーティングは、自動的に交通トランクスのための1セットの規制を満たす実行可能経路を見つけることによって、操作上のネットワークのパフォーマンスの最適化を助けます。 それは管理明白な経路構成の量を抜本的に減少させることができます、そして、手動の介入がTraffic Engineering目的を達成するのが必要です。
8.0 Conclusion
8.0 結論
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の上にTraffic Engineeringのための1セットの要件を提示しました。 インターネットでMPLSの適用性をTraffic Engineeringに高めるのが目的とされた状態で、多くの能力が説明されました。
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.
1人の極小集合のブロックをMPLSに組み入れて、次に、要件がわかるために機能性を広げるのにネットワークマネージメント上部構造を使用することによってここで説明された問題のいくつかを記述できることに注意されるべきです。 また、規制ベースのルーティング枠組みはコアMPLS仕様の一部である必要はありません。 しかしながら、MPLSは、条件を満たすために規制ベースのルーティング枠組みとのいくつかの相互作用を必要とします。
Awduche, et al. Informational [Page 25] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [25ページ]情報のRFC2702MPLS交通工学1999年9月
9.0 Security Considerations
9.0 セキュリティ問題
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に固有のそれらを超えて新しい安全保障問題を紹介しないで、この技術のために提案された同じメカニズムを使用するかもしれません。 しかしながら、行政上構成可能なパラメタの操作が権限のある機関によって安全な方法で実行されるのは、明確に重要です。
10.0 References
10.0の参照箇所
[1] Rosen, E., Viswanathan, A. and R. Callon, "A Proposed
Architecture for MPLS", Work in Progress.
[1] 「MPLSのための提案された構造」というローゼン、E.、Viswanathan、A.、およびR.Callonは進行中で働いています。
[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.、「Multiprotocolラベルの切り換えのための枠組み」というA.Viswanathanは進行中で働いています。
[3] Li, T. and Y. Rekhter, "Provider Architecture for Differentiated
Services and Traffic Engineering (PASTE)", RFC 2430, October
1998.
[3] 李とT.とY.Rekhter、「微分されたサービスと交通工学(ペースト)のためのプロバイダー構造」、RFC2430、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.は飲み込まれます、「シスコシステムズのタグは構造--概観を切り換え」て、RFC2105、1997年2月。
[5] Zhang, Z., Sanchez, C., Salkewicz, B. and E. Crawley "Quality of
Service Extensions to OSPF", Work in Progress.
[5] 「サービス拡大におけるOSPFへの上質」のチャン、Z.、サンチェス、C.、Salkewicz、B.、およびE.クローリーは進行中で働いています。
[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.、ナイア、F.、Rajagopalan、B.、およびH.Sandick、「QoSのための枠組みはインターネットにルート設定の拠点を置きました」、RFC2386、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.ウィリアムズ、「メカニズムとOSPF拡張子を発送するQoS」、RFC2676、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巻、No.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.リー、M.Hluchyi、およびP.Humblet、「サービスの質規制を条件として掘って、通信ネットワークは中と統合しました」、IEEE Network、1995年7月、pp46-55。
[10] ATM Forum, "Traffic Management Specification: Version 4.0" April
1996.
[10]気圧フォーラム、「管理仕様を取引してください」 バージョン4インチ1996年4月。
Awduche, et al. Informational [Page 26] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [26ページ]情報のRFC2702MPLS交通工学1999年9月
11.0 Acknowledgments
11.0 承認
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.
作者は彼のこのドキュメントの以前の草稿のレビューについてヤコフRekhterに感謝したがっています。 彼らの役立つ提案についてルイスMamakosとビルBarnsに感謝します、そして、また、作者は何らかの役に立つフィードバックを提供するためにカーティスVillamizarに感謝したがっています。
Awduche, et al. Informational [Page 27] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [27ページ]情報のRFC2702MPLS交通工学1999年9月
12.0 Authors' Addresses
12.0 作者のアドレス
Daniel O. Awduche UUNET (MCI Worldcom) 3060 Williams Drive Fairfax, VA 22031
ダニエル・O.Awduche UUNET(MCI Worldcom)3060ウィリアムズ・Driveフェアファクス、ヴァージニア 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 Worldcom)3060ウィリアムズ・Driveフェアファクス、ヴァージニア 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 Worldcom)3060ウィリアムズ・Driveフェアファクス、ヴァージニア 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 Worldcom)3060ウィリアムズ・Driveフェアファクス、ヴァージニア 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 Worldcom)3060ウィリアムズ・Driveフェアファクス、ヴァージニア 22031
Phone: +1 703-206-5607 EMail: jmcmanus@uu.net
以下に電話をしてください。 +1 703-206-5607 メールしてください: jmcmanus@uu.net
Awduche, et al. Informational [Page 28] RFC 2702 MPLS Traffic Engineering September 1999
Awduche、他 [28ページ]情報のRFC2702MPLS交通工学1999年9月
13.0 Full Copyright Statement
13.0 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Awduche, et al. Informational [Page 29]
Awduche、他 情報[29ページ]
一覧
スポンサーリンク
